Exploit Artifacts redux, plus
As a follow-up to my earlier post where I discussed Stuxnet, I wanted to take a moment to update some of what's come out on this issue in the past 12 days.
Claus wrote a great post that seems pretty comprehensive with respect to the information that's out there and available. He points to the original posts from VirusBlokAda, as well as two posts from F-Secure, the first of which points to the issue targeting SCADA systems. According to the second post:
...the Siemens SIMATIC WinCC database appears to use a hardcoded admin username and password combination that end users are told not to change.
Does that bother anyone?
Okay, all that aside, as always I'm most interested in how we (forensic analysts, incident responders) can use this information to our benefit, particularly during response/analysis activities. This PDF from VirusBlokAda, hosted by F-Secure has some very good information on artifacts associated with this malware. For example, there are two digitally signed driver files, mrxnet.sys and mrxcls.sys (found in the system32\driver directory), as well as several hidden (via attributes) LNK files and a couple of .tmp files. There are also two other files in the system32\inf directory; oem6c.pnf and oem7a.pnf, both of which reportedly contain encrypted data. This MS Threat Encyclopedia entry indicates that these files (and others) may be code that gets injected into lsass.exe. This entry points to online hosts reportedly contacted by the worm/downloader itself, so keep an eye on your DNS logs.
As the two .sys files are drivers, look for references to them both in the Services keys. This also means that entries appear in the Enum\Root keys (thanks to Stefan for the link to ThreatExpert).
This post from Bojan of the SANS ISC has some additional information, particularly that the LNK files themselves are specially-crafted so that the embedded MAC times within the LNK file are all set to 0 (ie, Jan 1, 1970). Outside of that, Bojan says that there is nothing special about the LNK files themselves...but still, that's something.
MS also has a work-around for disabling the display of icons for shortcuts.
So, in summary, what are we looking for? Run RegRipper and see if there are entries in the Services and Enum\Root (I have a legacy.pl plugin, or you can write your own) keys for the drivers. Within the file system (in a timeline), look for the driver files, as well as the .tmp and .pnf files. Should you find those, check the Registry and the appropriate log file (setupapi.log on XP) for a recently connected USB device.
Speaking of artifacts, Rebhip.A looks like a lot of fun...
For those interested, here's some PoC code from Exploit-DB.com.
Addendum: Anyone write a plugin for Rebhip.A yet? Also, I almost missed Pete's post on Stuxnet memory analysis...
Claus wrote a great post that seems pretty comprehensive with respect to the information that's out there and available. He points to the original posts from VirusBlokAda, as well as two posts from F-Secure, the first of which points to the issue targeting SCADA systems. According to the second post:
...the Siemens SIMATIC WinCC database appears to use a hardcoded admin username and password combination that end users are told not to change.
Does that bother anyone?
Okay, all that aside, as always I'm most interested in how we (forensic analysts, incident responders) can use this information to our benefit, particularly during response/analysis activities. This PDF from VirusBlokAda, hosted by F-Secure has some very good information on artifacts associated with this malware. For example, there are two digitally signed driver files, mrxnet.sys and mrxcls.sys (found in the system32\driver directory), as well as several hidden (via attributes) LNK files and a couple of .tmp files. There are also two other files in the system32\inf directory; oem6c.pnf and oem7a.pnf, both of which reportedly contain encrypted data. This MS Threat Encyclopedia entry indicates that these files (and others) may be code that gets injected into lsass.exe. This entry points to online hosts reportedly contacted by the worm/downloader itself, so keep an eye on your DNS logs.
As the two .sys files are drivers, look for references to them both in the Services keys. This also means that entries appear in the Enum\Root keys (thanks to Stefan for the link to ThreatExpert).
This post from Bojan of the SANS ISC has some additional information, particularly that the LNK files themselves are specially-crafted so that the embedded MAC times within the LNK file are all set to 0 (ie, Jan 1, 1970). Outside of that, Bojan says that there is nothing special about the LNK files themselves...but still, that's something.
MS also has a work-around for disabling the display of icons for shortcuts.
So, in summary, what are we looking for? Run RegRipper and see if there are entries in the Services and Enum\Root (I have a legacy.pl plugin, or you can write your own) keys for the drivers. Within the file system (in a timeline), look for the driver files, as well as the .tmp and .pnf files. Should you find those, check the Registry and the appropriate log file (setupapi.log on XP) for a recently connected USB device.
Speaking of artifacts, Rebhip.A looks like a lot of fun...
For those interested, here's some PoC code from Exploit-DB.com.
Addendum: Anyone write a plugin for Rebhip.A yet? Also, I almost missed Pete's post on Stuxnet memory analysis...