Malware scanner #3
Conversation
Draft malware scanner
|
I think, we should first code the reference then add new rules, improvements like string rebuilding from byte-array/base64 |
Update to include dynamic analysis
docs/malware-scanner/README.md
Outdated
| # Dynamic analysis | ||
| A slow but reliable detector looking for jar capabilities, potential malware sign | ||
| - run static analysis to filter known threats |
There was a problem hiding this comment.
Why is static analysis mentioned here under the dynamic section?
docs/malware-scanner/README.md
Outdated
| --- | ||
|
|
||
| # Dynamic analysis |
There was a problem hiding this comment.
Since static always happens, and dynamic is opt-in depending on usage, I think it'd make more sense for this section to come after the static one
docs/malware-scanner/README.md
Outdated
| A slow but reliable detector looking for jar capabilities, potential malware sign | ||
| - run static analysis to filter known threats | ||
| - downloading stuff from the internet (potentially jars, but can be genuine) |
There was a problem hiding this comment.
Phrasing: We should be detecting the capability to download, but not actually execute any logic. Wording is important to be clear that obvious vectors for abuse are addressed.
docs/malware-scanner/README.md
Outdated
| - downloading stuff from the internet (potentially jars, but can be genuine) | ||
| - zip/jar manipulation. | ||
| - able to execute stuff (Runtime.exec()) |
There was a problem hiding this comment.
Phrasing: We should make it VERY clear the scanner does not execute stuff, but detects the ability to do so.
docs/malware-scanner/README.md
Outdated
| - zip/jar manipulation. | ||
| - able to execute stuff (Runtime.exec()) | ||
| - de-obfuscation, static string rebuilding from assets, byte arrays or StringBuilders |
There was a problem hiding this comment.
2 cents: Deobufuscation isn't technically a necessary component with a tool like SSVM. With that, you can pattern match behaviors and ignore obfuscation entirely.
For example lets say in a static approach you want to look for running some evil-cm:
INVOKESTATIC Runtime.getRuntime()
LDC "evil-cmd"
INVOKEVIRTUAL runtime.exec(String)
This works fine up until you have any kind of obfuscation. Consider string encryption: At that point if you want to keep a static approach you need to support every possible string decryption routine to keep your match logic consistent. That's an impossible ask.
In a dynamic setting using a tool like SSVM you can simulate code execution and peek at calls to Runtime.exec. The string it takes has to be the end-result. So you could in SSVM do:
InstanceClass runtime = vm.getSymbols().java_lang_Runtime();
vm.getInterface().setInvoker(runtime, "exec", "(Ljava/lang/String;)Ljava/io/Process;",
ctx -> {
Locals locals = ctx.getLocals();
String command = ops.toString(locals.loadReference(1));
if (command.equals("evil-cmd")) {
String className = ctx.getOwner().getNode().name;
String methodName = ctx.getMethod().getName();
String methodDesc = ctx.getMethod().getDesc();
// method executed with arg deemed malicious, tell detector we found malware here
sink.markMalware("evil-cmd-detection", className, methodName, methodDesc);
}
return Result.CONTINUE;
});- malware ID - match ID (I personally want to call it clue ID) - detection algorithm and interface section separated.
gdude2002
changed the title
What I think the detector/scanner should be.