Sometimes during post-mortem analysis (or during incident response using F-Response) the question you may be faced with or that may be peripheral to your analysis is, was the system infected with some kind of malware? This can particularly useful as some AV products may not detect the malware files themselves, and some malware disables AV products when installed. Also, there have been a number of examples recently where the malware files themselves have random names, so understanding the persistence mechanism (i.e., Registry artifacts) might help narrow things down tremendously, and quickly.
Well, you can use RegRipper to help you figure this all out.
Take for example Trojan.Brisv.A...according to the Symantec write up, when a system is infected, it creates the Software\Microsoft\PIMSRV key in the user's hive. Since this is a unique key, it can be indicative of an infection. This malware also modifies two Registry values within the user's hive specific to Windows Media Player:
Software\Microsoft\MediaPlayer\Preferences\URLAndExitCommandsEnabled; changes the data to "0"
Software\Microsoft\MediaPlayer\Player\Extensions\.mp3\Permissions; changes the data to "21"
So, all someone needs to do is write a plugin for RegRipper that checks for the existence of the first key, as well as the data within the two values.
As it is, the mpmru.pl plugin will retrieve the list of files most recently played via Windows Media Player...what you want to look for (based on the Symantec write up) is a .wma file that was played.
Addendum: To add to this, the MS Malware Protection Center recently posted on a spam-for-hire Trojan with rootkit functionality called Win32/Srizbi. This malware reportedly uses the Run key as its persistence mechanism (which RegRipper already extracts values from), and installs its kernel-mode rootkit in the Services key, which RegRipper also extracts. Further examples, such as Win32/Roron, illustrate other examples of where RegRipper can be used to check the Registry for indications of an infection.
1 comment:
I was able to detect Mebroot/Sinowal using Regripper as well.
It lived under the following locations:
Root: HKLM Path: system\controlset001\enum\root\legacy_{def85c80-216a-43ab-af70-1665edbe2780}
Root: HKLM Path: system\controlset001\services\{def85c80-216a-43ab-af70-1665edbe2780}
Root: HKLM Path: system\currentcontrolset\enum\root\legacy_{def85cd80-216a-43ab-af70-1665edbe2780}
Root: HKLM Path: system\currentcontrolset\services\{def85c80-216a-43ab-af70-1665edbe2780}
Post a Comment