while walking to the bus stop on my way to work one day last week i was thinking about the idea of measure vs. countermeasure (as i sometimes do) and an interesting juxtaposition of concepts popped into my head: non-persistence in malware and the so-called cold boot attack... bonus points if you already know where this is going...
you may recall that i ate some crow way back when i was describing how active stealth could be countered by outside-the-box analysis and then a certain stealthkit that shall not be named came along that used non-persistence to get around that problem... thanks to the work of ed felten and co. it appears i ate the crow a little too soon... non-persistence as a countermeasure depends on the very same assumptions about the volatility of RAM that many encryption implementations depend on - that RAM is volatile enough that it's contents are as good as gone once the system loses power... we now know not only that this assumption is false (there are those who will point out that that much was actually known for quite some time) but also that it's relatively straightforward to exploit...
that means it's technically possible to boot to a dedicated OS on a known-clean medium, dump the contents of memory and detect so-called non-persistent stealth malware using known-malware scanning (for known malware, obviously) or using cross-view diff with a second memory dump taken while the compromised system was still active (for unknown malware)...
this isn't the only countermeasure for non-persistent virtualized stealthkits, but it's a neat one none the less and it shows once again that for every measure there is a countermeasure...
devising a framework for thinking about malware and related issues such as viruses, spyware, worms, rootkits, drm, trojans, botnets, keyloggers, droppers, downloaders, rats, adware, spam, stealth, fud, snake oil, and hype...
Showing posts with label non-persistence. Show all posts
Showing posts with label non-persistence. Show all posts
Sunday, March 09, 2008
what is non-persistence?
non-persistence in malware is a property whereby the malware doesn't get written to a persistent storage medium like the hard disk but instead resides only in RAM...
the primary advantage of this technique is that on-access scanners won't scan it because the condition that triggers on-access scanning is never met, and application whitelisting won't stop it because a non-persistent program requires exotic execution by definition...
a lesser appreciated benefit is that it circumvents outside-the-box analysis because the contents of RAM are supposed to be lost when the computer shuts down... recent developments suggest this benefit might not actually exist, however...
non-persistence can even have some advantages against behaviour blockers under certain circumstances (ex. if the malware injects itself into a process that is already authorized to perform all the behaviours the malware needs to perform then the behaviour blocker won't necessarily raise an alarm (unless it can detect the injection itself)...
on-demand scanning of RAM should be able to identify known non-persistent malware so long as it doesn't use stealth or any other countermeasures, however... further, since the network is nearly the only point of entry for completely non-persistent malware, scanning at the LSP level has a good chance of catching any known exploits it might use to get into the system in the first place...
back to index
the primary advantage of this technique is that on-access scanners won't scan it because the condition that triggers on-access scanning is never met, and application whitelisting won't stop it because a non-persistent program requires exotic execution by definition...
a lesser appreciated benefit is that it circumvents outside-the-box analysis because the contents of RAM are supposed to be lost when the computer shuts down... recent developments suggest this benefit might not actually exist, however...
non-persistence can even have some advantages against behaviour blockers under certain circumstances (ex. if the malware injects itself into a process that is already authorized to perform all the behaviours the malware needs to perform then the behaviour blocker won't necessarily raise an alarm (unless it can detect the injection itself)...
on-demand scanning of RAM should be able to identify known non-persistent malware so long as it doesn't use stealth or any other countermeasures, however... further, since the network is nearly the only point of entry for completely non-persistent malware, scanning at the LSP level has a good chance of catching any known exploits it might use to get into the system in the first place...
back to index
Tags:
definition,
non-persistence
Subscribe to:
Posts (Atom)