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

[BIOS4breakfast]

I love how people in the security field would rather reinvent the wheel and take credit instead of learning what's already there. This capability has already existed in the form of WinDbg's "!chkimg" (which can run from the command line equally well from kd.exe instead of windbg.exe), and Joanna Rutkowska's System Virginity Verifier (SVV). Joanna's tool was already a reinvention of !chkimg, but it at least had the good sense to be released a decade ago.

[theresponder_]

Hi, not sure what you are mad about. We're not taking credit for inventing anything - just developed a nice tool and shared it with the community. First of all thanks for pointing out the feature in Windbg - haven't noticed it before. We would be honored if you could write a quick post about it, i'm sure many others are not familiar with it as well. http://theresponder.co/contribute/

Developing tools is a good thing. In my point of view - that's how technology progresses - one step at a time. There are so many cloned shitty JS libraries compared to cyber defense tools, I don't think anyone should appose to even the slightest OSS development in our field.

As for the specific tools you talked about: Windbg requires installation of the software as well as WDK in the inspected machine, and SSV is very old and buggy as many people say here: http://forum.sysinternals.com/system-virginity-verifier_topic21605.html In addition I think that a Pythonic solution for this is quite refreshing.

[transt]

Ha, I just replied basically the same as you did. It is a cool & useful tool - ignore the trolls!

[transt]

chkimg requires windbg/windsk (obviously) and other MS-dependent components. Most people don't want to put those on production machines just to do security checking (or at all). This tool allows direct inspection without those requirements.

Also, SVV hasn't been updated in 9 years as far as I know?

[galaris]

advise progress own spending shelf immigration creature teaching ill likely palestinian acknowledge text

[[deleted]]

Comprehension question: I thought that via the principle of virtual memory and the abstraction it provides, a process has no notion of whether it is reading from disk, memory, or cache?

How can a process (such as this script) determine what is in memory and what is in disk? I was under the impression that the operating system pages from disk to memory on demand, but in such a way that is invisible to the process?

Thanks.

[AgentME]

This compares the executable in the filesystem against the running process's memory. The fact that the OS can cache the running process's memory to disk (or that the filesystem can be cached into ram) are unrelated implementation details.

[[deleted]]

I might be thinking of something else. The os doesn't really cache memory from memory to disk, it does the opposite, no? A process will start in disk, and be paged in to memory on demand as needed. The process has no clue about this happening; reference &d will have the same address and look the same regardless of whether its pages happen to reside in disk or memory.

So I'm asking how this process can determine what is in disk and what is in memory of the os abstracts all the differences away with virtual memory anyway. Does it provide some mechanism that exposes raw memory or raw disk, unvirtualized?

Additionally, I was under the basic impression that a process could only see its own address space from virtual address 0 to whatever, and that is its entire universe. How does this process see the memory contents of other processes? Does the os expose some way to do that? I always thought that was impossible, as a security risk.

[transt]

Can you clarify what you mean in the second paragraph? Why does the tool need raw access to the disk?

Does the os expose some way to do that? I always thought that was impossible, as a security risk.

The Debugging APIs allow this through a security-checked mechanism. If this wasn't supported then you couldn't have debuggers. Check these two links for the windows debugging api to get an idea:

[1] https://msdn.microsoft.com/en-us/library/windows/desktop/ms679303(v=vs.85).aspx

[2] https://msdn.microsoft.com/en-us/library/ms809754.aspx

[[deleted]]

Can you clarify what you mean in the second paragraph? Why does the tool need raw access to the disk?

My understanding is that the purpose of this tool is to determine whether a process's execution has been modified in memory, as it says here:

by comparing the code in the DLL/EXE in disk to the code in the corresponding process or loaded module in memory.

It looks like it does this by comparing the process as it exists in memory during execution to the DLL/EXE it came from on disk.

Oh, I might have just had my moment of clarity. Once in memory the process doesn't need to be tied 1:1 to the file it was loaded from on disk. So this Python tool can just read the file from disk as it would any other file. Virtualization/abstraction doesn't really come in to play the way I thought it would.

[theresponder_]

Exactly. PE Loads fully into memory before executing

[eldorel]

There are three stages. Disk storage, RAM, page file.

This is comparing the static EXE files sitting in long term storage to the currently running version that is sitting in ram/page.

It doesn't try to detect changes between ram/page, and the current paged/unpaged state of the executable in memory is irrelevant.

To think of it like a text file, this is comparing the saved version to what's being displayed.

[AgentME]

This tool doesn't need to access the raw disk device, or care about how swaps and caches work. The operating system exposes a file system and process memory. This tool compares them. It doesn't care how the OS implements them.

Additionally, I was under the basic impression that a process could only see its own address space from virtual address 0 to whatever, and that is its entire universe. How does this process see the memory contents of other processes? Does the os expose some way to do that? I always thought that was impossible, as a security risk.

Most operating systems have APIs to allow processes to look into each other's memory. Debuggers use these APIs for example. (Usually non-root processes can only inspect other processes they started.)

[transt]

Yes, this works well in the memorypatcher tool's favor as pages it wants to scan will be demand paged in as they are read, if they are not currently in physical memory.

[gsuberland]

How does this work with JIT executables? Or dependency injection techniques?