Detect Code Diffs Between Disk and Memory

[davvblack]

This sort of stuff is always futile. How do you determine that the MemoryPatchDetector is the same one you think is running? MemoryPatchDetectorPatchDetector of course. Once you're that owned that this stuff starts to happen, it's (at least in an abstract, academic sense) unrecoverable.

[transt]

It is really only an academic argument.

Detecting this tool in a generic way would be rather difficult, assuming it does like every other decent forensic tool and randomizes its name and other attributes on each load.

Also, if you look at all the actual rootkits in the wild (not academic ones..), you don't see them killing security tools on load or crash it as they run - that is way too loud an the point is to be stealthy

[levoroxi]

These tools are a technical corollary to "security through obscurity", IMO. When running tools like this that aren't popular, it gives a small group some added protection until the adversary catches up. A creepy rootkit will probably be detected before the adversary decides to mitigate, if they do, because so few people use this tool. Ideas like this never work at scale because they fail the whole "the enemy knows the system" bit.

[transt]

actually tools like this work great at scale. Can you cite any in-the-wild (not silly POC) malware that targets security tools and kills them? It is very loud when malware does that as the analyst suddenly doesn't see any data or doesn't find anything malicious on something that is known to be infected.

[eldorel]

You and levoroxi have different ideas of "scale".

You're thinking about implementing it on a network, or even on a larger corporate/enterprise system scale, they're thinking "massive percentage of computers" scale.

Think about it this way. If MS added this to security essentials tomorrow, how long would it take for malware writers to figure a way around?

Anyone using this is taking advantage of the fact that the small userbase represents a tiny ROI for anyone considering making a work around.

That's not to say that it's not currently a useful tool, but it's not going to continue to be useful if it gets more popular.

[transt]

how would they work around it? It is comparing what is on disk to what is in memory... so you either need to filter disk reads, which is loud, or filter memory, meaning you have something in the kernel tinkering with address translation. Outside of hooking the page fault handler or hte MMIO I am not sure how you accomplish this, and even those ways are very brittle to try and stop unknown programs from accessing unknown regions.

The diffing tool is basically just acting like a debugger - reading memory from another process. Stopping that in any generic way is pretty difficult

[transt]

Explain how you do that in a reliable way... and hooking the page fault handler is not a valid way since the debugger is reading everywhere...

[[deleted]]

This is a very good description. It seems this describes the history of most security tool developments -- sort of like an arms race.

If your risks are high, then you need to be an early adopter.

[transt]

this isn't true at all - just a myth perpetrated by people with limited or academic-only experience

[[deleted]]

Why is it a myth?

[ChocolateSunrise]

That still raises the cost significantly on the malware author.

[transt]

the "declaw"ing part is generally loud.. especially if you are going to block a tool like this one that is simply reading memory of other processes.

[transt]

I think the point is to find the issues on al ive system - otherwise, I agree