tag:blogger.com,1999:blog-36301999733618866602024-03-19T04:08:55.667-06:00MNIN Security BlogCoding, Reversing, ExploitingMichael Hale Lighhttp://www.blogger.com/profile/17377327006242921434noreply@blogger.comBlogger69125tag:blogger.com,1999:blog-3630199973361886660.post-20140406105870763452013-06-05T10:16:00.003-06:002013-06-05T10:18:12.769-06:00How to DoS Authenticode Signature Verification and Spoil Live Forensics with EchoA while back I was looking into some internals of Microsoft's Authenticode and found a way to prevent signature verification by creating a specially named file. Its not a file format parsing bug, as the file can be completely empty. The file must be created under the system32 directory, so you need admin privileges. However, assuming an attacker's goal is to patch signed binaries or introduce new, un-signed binaries onto the system and prevent them from being discovered (at least for a while); then admin access has likely already been obtained. At the very least, when investigators scan the suspect system with signature checking utilities, they'll be quite perplexed with the result. If you perform live forensics by launching various tools in batch mode - you may end up waiting....well, forever...before any results come back.<br />
<br />
<object height="344" width="425"><param name="movie" value="http://www.youtube.com/v/_nNoQ3L1W8w&hl=en&fs=1"></param>
<param name="allowFullScreen" value="true"></param>
<embed src="http://www.youtube.com/v/_nNoQ3L1W8w&hl=en&fs=1" type="application/x-shockwave-flash" allowfullscreen="true" width="425" height="344"></embed></object>
<br />
<br />
<b>What is Affected?</b><br />
<br />
Since I can't call this a vulnerability, I'll just refer to it as a bug - as its an obvious programming flaw. The component is wintrust.dll (Microsoft Trust Verification APIs) and the bug exists on fully updated Windows Vista, Windows Server 2008 and 2008 R2, Windows 7 and Windows 8 Enterprise (32- and 64-bit, all service packs). Although we're talking about a Microsoft DLL, its essentially an API, thus many non-Microsoft products and tools are affected. To name a few:<br />
<ul>
<li>Microsoft sigverif.exe. This is a GUI File Signature Verification included with all Windows installations. It will freeze after enumerating files (but before checking their signatures). </li>
<li>signtool.exe. This is a command-line tool included with Visual Studio. </li>
<li>signdrv.dll. The WMI provider for Signed Drivers.</li>
<li>sigcheck.exe. The popular tool from SysInternals will freeze after printing the version banner, regardless of what options you choose. </li>
<li>Mandiant Redline. A tool for streamlining forensic data acquisition and analysis. On live systems, it will attempt to verify driver signatures before capturing memory. Unfortunately it will freeze on step 1 and never actually get to the memory step. </li>
<li>Any other forensic tools or digital signature verification utilities that use the specific APIs in wintrust.dll. </li>
</ul>
<div>
<b>About the Bug</b></div>
<div>
<br /></div>
<div>
The wintrust.dll file provides APIs to verify authenticode digital signatures. To compute the hash of a file, use the <a href="http://msdn.microsoft.com/en-us/library/windows/desktop/aa379891(v=vs.85).aspx">CryptCATAdminCalcHashFromFileHandle</a> function. To determine which catalog in the catalog database (system32\catroot2) has information on the hashed file, call <a href="http://msdn.microsoft.com/en-us/library/windows/desktop/aa379892(v=vs.85).aspx">CryptCATAdminEnumCatalogFromHash</a>. This API searches recursively for subdirectories named like GUIDs (see the image below). </div>
<br />
<span id="docs-internal-guid-19cb174e-14b8-9cad-a653-5e15a931cf22"><img height="305px;" src="https://lh4.googleusercontent.com/XXC0ZG-qg6gJkg3zReNVm9y7d5i5fJkPp92VjV76gMihWcypvHpGr9xwusDSM6KRCn9GBUnIhLU6BvbJOvP9z6SeHDcJ6RECpymRk2miPLQ5c4UkKX4" width="622px;" /></span><br />
<br />
In Windows XP and 2003 (the non-affected versions), the relevant code block in CryptCATAdminEnumCatalogFromHash looks like this:<br />
<br />
<pre style="background: #f0f0f0; border: 1px dashed #CCCCCC; color: black; font-family: Courier New; font-size: 12px; height: auto; line-height: 20px; overflow: auto; padding: 0px; text-align: left; width: 99%;"><code style="color: black; word-wrap: normal;">pwszSearchString = _CatAdminCreatePath(
pwszSystemCatroot2Dir,
L"{????????????????????????????????????}",
0);
if ( pwszSearchString )
{
hFindFile = FindFirstFileU(pwszSearchString, &FindData);
if ( hFindFile == INVALID_HANDLE_VALUE )
{
//fail
}
}
else
{
do
{
if ( FindData.dwFileAttributes & FILE_ATTRIBUTE_DIRECTORY
&& !_CatAdminAddCatalogsToCache(...) )
{
//fail
}
}
while ( FindNextFileU(hFindFile, &FindData) );
.....
}</code></pre>
<br />
Starting in Windows Vista, the code was shifted around a bit. In particular, the authors moved code into a sub-function called from CryptCATAdminEnumCatalogFromHash; and in doing so they accidentally changed the logic and terminating conditions of the original do/while loop. A pseudo-patch shows the changes that were made:<br />
<div>
<br /></div>
<pre style="background-color: #f0f0f0; background-position: initial initial; background-repeat: initial initial; border: 1px dashed rgb(204, 204, 204); font-family: 'Courier New'; font-size: 12px; height: auto; line-height: 20px; overflow: auto; padding: 0px; text-align: left; width: 99%;"><code style="color: black; word-wrap: normal;">@@ -14,11 +14,12 @@
{
do
{
- if ( FindData.dwFileAttributes & FILE_ATTRIBUTE_DIRECTORY
- && !_CatAdminAddCatalogsToCache(...) )
- {
- //fail
- }
</code><code style="word-wrap: normal;"><span style="color: red;"><b>+ while ( !(FindFileData.dwFileAttributes & FILE_ATTRIBUTE_DIRECTORY) )
+ ;</b></span></code><code style="color: black; word-wrap: normal;">
+ if ( _CatAdminAddCatalogsToCache(...) )
+ Retval = 1;
+ else
+ dwErrCode = GetLastError();
}
while ( FindNextFileU(hFindFile, &FindData) );
.....
</code></pre>
<br />
After this patch, each object (file *or* directory) enumerated by FindFirstFile/FindNextFile that matches the GUID wildcard {????????????????????????????????????} is passed through an inner while loop that tests if the object is a directory (i.e. the FILE_ATTRIBUTE_DIRECTORY flag is set). If so, the inner while loop terminates, _CatAdminAddCatalogsToCache is called, and the next object is tested. However, if the object is a file, the inner while loop will continuously check if the object is still a file. See the highlighted lines in red.<br />
<br />
You can see the disassembly below from the Windows 8 Enterprise x64 wintrust!CryptCATAdminEnumCatalogFromHash file.<br />
<br />
<span id="docs-internal-guid-19cb174e-14c2-9bf0-4d33-f6aa6de64471"><img height="252" src="https://lh3.googleusercontent.com/rvKGc17lQgnRLoxeUgBJBSzN0Z52jIDEyGOArS-OT5eKRpPg4__x8ecUwkH5KxPUDBpDH8e-H538smrh4XTU0RAL9JDyFtWhgWPPCbW1SNXdFc6XM8XZ" width="640" /></span><br />
<br />
<b>Triggering the Bug </b><br />
<br />
To trigger the bug, all you have to do is create a file. It can be done from an administrator shell as shown below, or you can do it from shell code after an exploit:<br />
<br />
C:\> echo "" > C:\WINDOWS\system32\catroot2\{111111111111111111111111111111111111}<br />
<br />
Note the file can be any size. You can fill it with random data or leave it as 0 bytes. The name must start with an open curly brace "{", end with a close curly brace "}" and have 36 characters in between. The characters can be any combination of letters, numbers, etc.<br />
<br />
<b>Conclusion</b><br />
<br />
Microsoft is aware of this issue and plans to fix it in the next major release of Windows. Although its rather funny to see code in a security-related component of the most recent OS version entering an infinite loop for as long as a file is not a directory, it's a stretch to call this a vulnerability because admin-level access is required to trigger it. When performing live forensics, be cognizant of the risks involved - there may be an easter egg waiting in the catroot2 directory!Michael Hale Lighhttp://www.blogger.com/profile/17377327006242921434noreply@blogger.com0tag:blogger.com,1999:blog-3630199973361886660.post-22839399580587252882012-11-09T10:49:00.001-06:002012-11-09T10:49:04.011-06:00Windows Memory Forensics Training by Volatility Developers<span style="font-family: inherit;"><span style="background-color: white; color: #444444; font-size: 13px; line-height: 18px;">We are pleased to announce the first public offering of the Windows Memory Forensics for Analysts training course. This is the only memory forensics course officially designed, sponsored, and taught by the Volatility developers. One of the main reasons we made Volatility open-source is to encourage and facilitate a deeper understanding of how memory analysis works, where the evidence originates, and how to interpret the data collected by the framework's extensive set of plugins. Now you can reap these benefits first hand from the developers of the most powerful, flexible, and innovative memory forensics tool. </span><br style="background-color: white; color: #444444; font-size: 13px; line-height: 18px;" /><span style="background-color: white; color: #444444; font-size: 13px; line-height: 18px;"><br /></span><span style="background-color: white; color: #444444; font-size: 13px; line-height: 18px;"></span><span style="background-color: white; color: #444444; font-size: 13px; line-height: 18px;">Please see the following details about the upcoming training event:</span><br style="background-color: white; color: #444444; font-size: 13px; line-height: 18px;" /><br style="background-color: white; color: #444444; font-size: 13px; line-height: 18px;" /><span style="background-color: white; color: #444444; font-size: 13px; line-height: 18px;">Dates: Monday, December 3rd through Friday, December 7th 2012</span><br style="background-color: white; color: #444444; font-size: 13px; line-height: 18px;" /><span style="background-color: white; color: #444444; font-size: 13px; line-height: 18px;">Location: Reston, Virginia (exact location will be shared upon registration)</span><br style="background-color: white; color: #444444; font-size: 13px; line-height: 18px;" /><span style="background-color: white; color: #444444; font-size: 13px; line-height: 18px;">Instructors: Michael Ligh (</span><a href="http://twitter.com/imhlv2" style="background-color: white; color: #4d469c; font-size: 13px; line-height: 18px; text-decoration: none;">@iMHLv2</a><span style="background-color: white; color: #444444; font-size: 13px; line-height: 18px;">), Andrew Case (</span><a href="http://twitter.com/attrc" style="background-color: white; color: #4d469c; font-size: 13px; line-height: 18px; text-decoration: none;">@attrc)</a><span style="background-color: white; color: #444444; font-size: 13px; line-height: 18px;">, Jamie Levy (</span><a href="http://twitter.com/gleeda" style="background-color: white; color: #4d469c; font-size: 13px; line-height: 18px; text-decoration: none;">@gleeda</a><span style="background-color: white; color: #444444; font-size: 13px; line-height: 18px;">). Please see the</span><a href="http://code.google.com/p/volatility/wiki/VolatilityTeam" style="background-color: white; color: #4d469c; font-size: 13px; line-height: 18px; text-decoration: none;">VolatilityTeam</a><span style="background-color: white; color: #444444; font-size: 13px; line-height: 18px;"> wiki page for brief bios.</span><br style="background-color: white; color: #444444; font-size: 13px; line-height: 18px;" /><br style="background-color: white; color: #444444; font-size: 13px; line-height: 18px;" /><b style="background-color: white; color: #444444; font-size: 13px; line-height: 18px;">Overview:</b><br style="background-color: white; color: #444444; font-size: 13px; line-height: 18px;" /><br style="background-color: white; color: #444444; font-size: 13px; line-height: 18px;" /><span style="background-color: white; color: #444444; font-size: 13px; line-height: 18px;">The ability to perform digital investigations and incident response is becoming a critical skill for many occupations. Unfortunately, digital investigators frequently lack the training or experience to take advantage of the volatile artifacts found in physical memory. Volatile memory contains valuable information about the runtime state of the system, provides the ability to link artifacts from traditional forensic analysis (network, file system, registry), and provides the ability to ascertain investigative leads that have been unbeknownst to most analysts. Malicious adversaries have been leveraging this knowledge disparity to undermine many aspects of the digital investigation process with such things as anti-forensics techniques, memory resident malware, kernel rootkits, encryption (file systems, network traffic, etc), and Trojan defenses. The only way to turn-the-tables and defeat a creative digital human adversary is through talented analysts.</span><br style="background-color: white; color: #444444; font-size: 13px; line-height: 18px;" /><br style="background-color: white; color: #444444; font-size: 13px; line-height: 18px;" /><span style="background-color: white; color: #444444; font-size: 13px; line-height: 18px;">This course will demonstrate why memory forensics is a critical component of the digital investigation process and how investigators can gain the upper hand. The course will consist of lectures on specific topics in Windows memory forensics followed by intense hands-on exercises to put the topics into real world contexts. Exercises will require analysis of malware in memory, kernel-level rootkits, registry artifacts found in memory, signs of data exfiltration, and much more. This course is your opportunity to learn these invaluable skills from the researchers and developers that have pioneered the field. This is also the only memory forensics training class that is authorized to teach Volatility, officially sponsored by The Volatility Project, and taught directly by the Volatility developers.</span><br style="background-color: white; color: #444444; font-size: 13px; line-height: 18px;" /><br style="background-color: white; color: #444444; font-size: 13px; line-height: 18px;" /><b style="background-color: white; color: #444444; font-size: 13px; line-height: 18px;">Who should attend?</b><br style="background-color: white; color: #444444; font-size: 13px; line-height: 18px;" /><br style="background-color: white; color: #444444; font-size: 13px; line-height: 18px;" /><span style="background-color: white; color: #444444; font-size: 13px; line-height: 18px;">This course is intended for malware analysts, reverse engineers, incident responders, digital forensics analysts, law enforcement officers, federal agents, system administrators, corporate investigators, or anyone who wants to develop the skills necessary to combat advanced adversaries.</span><br style="background-color: white; color: #444444; font-size: 13px; line-height: 18px;" /><br style="background-color: white; color: #444444; font-size: 13px; line-height: 18px;" /><b style="background-color: white; color: #444444; font-size: 13px; line-height: 18px;">Course Prerequisites</b></span><br />
<ul style="background-color: white; color: #444444; font-size: 13px; line-height: 18px; list-style-image: initial; list-style-position: initial; margin: 0.5em 0px; padding: 0px 2.5em;">
<li style="border: none; margin: 0px 0px 0.25em; padding: 0.25em 0px;"><span style="font-family: inherit;">It is recommended that students have some experience with the Volatility Framework.</span></li>
<li style="border: none; margin: 0px 0px 0.25em; padding: 0.25em 0px;"><span style="font-family: inherit;">Students should possess a basic knowledge of digital investigation tools and techniques.</span></li>
<li style="border: none; margin: 0px 0px 0.25em; padding: 0.25em 0px;"><span style="font-family: inherit;">Students should be comfortable with general troubleshooting of both Linux and Windows operating systems (setup, configuration, networking)</span></li>
<li style="border: none; margin: 0px 0px 0.25em; padding: 0.25em 0px;"><span style="font-family: inherit;">Students should be familiar with popular system administration tools (i.e. Sysinternals Utilities)</span></li>
<li style="border: none; margin: 0px 0px 0.25em; padding: 0.25em 0px;"><span style="font-family: inherit;">Student should be both familiar and comfortable with using the command line</span></li>
<li style="border: none; margin: 0px 0px 0.25em; padding: 0.25em 0px;"><span style="font-family: inherit;">Student should have a basic understanding of Python or similar scripting language</span></li>
</ul>
<span style="font-family: inherit;"><b style="background-color: white; color: #444444; font-size: 13px; line-height: 18px;">Course Structure</b><br style="background-color: white; color: #444444; font-size: 13px; line-height: 18px;" /><br style="background-color: white; color: #444444; font-size: 13px; line-height: 18px;" /><span style="background-color: white; color: #444444; font-size: 13px; line-height: 18px;">This is a 5-day course composed of both classroom learning and hands-on training exercises and scenarios. All course material, lunches, and coffee breaks will be provided (If you have unique dietary restrictions, please make them known during registration).</span><br style="background-color: white; color: #444444; font-size: 13px; line-height: 18px;" /><br style="background-color: white; color: #444444; font-size: 13px; line-height: 18px;" /><b style="background-color: white; color: #444444; font-size: 13px; line-height: 18px;">Course Requirements</b><br style="background-color: white; color: #444444; font-size: 13px; line-height: 18px;" /><br style="background-color: white; color: #444444; font-size: 13px; line-height: 18px;" /><span style="background-color: white; color: #444444; font-size: 13px; line-height: 18px;">In order to fully participate in the course, students are required to bring a properly pre-configured laptop. Students are encouraged to bring laptops that can run both Linux and Windows, where either instance is virtualized based on student preference. It is the student's responsibility to make sure the laptop is configured prior to the beginning of the course. There is no time built into the course schedule to help people configure machines, so please make sure your laptop has been properly configured before showing up for class.</span><br style="background-color: white; color: #444444; font-size: 13px; line-height: 18px;" /><br style="background-color: white; color: #444444; font-size: 13px; line-height: 18px;" /><span style="background-color: white; color: #444444; font-size: 13px; line-height: 18px;">Minimum Hardware Requirements:</span><br style="background-color: white; color: #444444; font-size: 13px; line-height: 18px;" /><span style="background-color: white; color: #444444; font-size: 13px; line-height: 18px;"> 2.0 GHz CPU</span><br style="background-color: white; color: #444444; font-size: 13px; line-height: 18px;" /><span style="background-color: white; color: #444444; font-size: 13px; line-height: 18px;"> 4 GB of RAM</span><br style="background-color: white; color: #444444; font-size: 13px; line-height: 18px;" /><span style="background-color: white; color: #444444; font-size: 13px; line-height: 18px;"> 20 GB of disk space</span><br style="background-color: white; color: #444444; font-size: 13px; line-height: 18px;" /><span style="background-color: white; color: #444444; font-size: 13px; line-height: 18px;"> DVD-ROM drive</span><br style="background-color: white; color: #444444; font-size: 13px; line-height: 18px;" /><span style="background-color: white; color: #444444; font-size: 13px; line-height: 18px;"> USB 2.0 ports</span><br style="background-color: white; color: #444444; font-size: 13px; line-height: 18px;" /><span style="background-color: white; color: #444444; font-size: 13px; line-height: 18px;"> Wireless Network Interface Card</span><br style="background-color: white; color: #444444; font-size: 13px; line-height: 18px;" /><br style="background-color: white; color: #444444; font-size: 13px; line-height: 18px;" /><span style="background-color: white; color: #444444; font-size: 13px; line-height: 18px;">Software Requirements:</span><br style="background-color: white; color: #444444; font-size: 13px; line-height: 18px;" /><span style="background-color: white; color: #444444; font-size: 13px; line-height: 18px;"> Python 2.6 or 2.7</span><br style="background-color: white; color: #444444; font-size: 13px; line-height: 18px;" /><span style="background-color: white; color: #444444; font-size: 13px; line-height: 18px;"> Microsoft Windows Debugger</span><br style="background-color: white; color: #444444; font-size: 13px; line-height: 18px;" /><span style="background-color: white; color: #444444; font-size: 13px; line-height: 18px;"> VMware Workstation 6/Fusion 3 or higher</span><br style="background-color: white; color: #444444; font-size: 13px; line-height: 18px;" /><span style="background-color: white; color: #444444; font-size: 13px; line-height: 18px;"> 7-Zip (or ability to decompress zip, gzip, rar, etc)</span><br style="background-color: white; color: #444444; font-size: 13px; line-height: 18px;" /><span style="background-color: white; color: #444444; font-size: 13px; line-height: 18px;"> Wireshark</span><br style="background-color: white; color: #444444; font-size: 13px; line-height: 18px;" /><br style="background-color: white; color: #444444; font-size: 13px; line-height: 18px;" /><span style="background-color: white; color: #444444; font-size: 13px; line-height: 18px;">Additional free/open-source tools or libraries may be required to complete hands-on exercises. More information will be shared upon registration.</span><br style="background-color: white; color: #444444; font-size: 13px; line-height: 18px;" /><br style="background-color: white; color: #444444; font-size: 13px; line-height: 18px;" /><b style="background-color: white; color: #444444; font-size: 13px; line-height: 18px;">Course Fee:</b><br style="background-color: white; color: #444444; font-size: 13px; line-height: 18px;" /><br style="background-color: white; color: #444444; font-size: 13px; line-height: 18px;" /><span style="background-color: white; color: #444444; font-size: 13px; line-height: 18px;">The cost of the course is $3500. Law enforcement, government, and educational discounts are available.</span><br style="background-color: white; color: #444444; font-size: 13px; line-height: 18px;" /><br style="background-color: white; color: #444444; font-size: 13px; line-height: 18px;" /><b style="background-color: white; color: #444444; font-size: 13px; line-height: 18px;">Registration: </b><br style="background-color: white; color: #444444; font-size: 13px; line-height: 18px;" /><br style="background-color: white; color: #444444; font-size: 13px; line-height: 18px;" /><span style="background-color: white; color: #444444; font-size: 13px; line-height: 18px;">To obtain information on registration, please email voltraining [ @ ] memoryanalysis.net.</span></span>Michael Hale Lighhttp://www.blogger.com/profile/17377327006242921434noreply@blogger.com0tag:blogger.com,1999:blog-3630199973361886660.post-32033713051323730092012-10-12T10:25:00.002-06:002012-10-12T10:25:11.298-06:00Month of Volatility Plugins - Week 4<span style="background-color: white; color: #666666; font-family: 'Trebuchet MS', Trebuchet, Verdana, sans-serif; font-size: 13px; line-height: 18px;">I was writing to announce the last week of the month of Volatility plugins is finished, and we now have five more in-depth blog posts covering Windows and Linux internals and rootkit detection. These have all been posted on the Volatility Labs blog.</span><br style="background-color: white; color: #666666; font-family: 'Trebuchet MS', Trebuchet, Verdana, sans-serif; font-size: 13px; line-height: 18px;" /><br style="background-color: white; color: #666666; font-family: 'Trebuchet MS', Trebuchet, Verdana, sans-serif; font-size: 13px; line-height: 18px;" /><span style="background-color: white; color: #666666; font-family: 'Trebuchet MS', Trebuchet, Verdana, sans-serif; font-size: 13px; line-height: 18px;">Post 1: Detecting Malware with GDI Timers and Callbacks</span><br style="background-color: white; color: #666666; font-family: 'Trebuchet MS', Trebuchet, Verdana, sans-serif; font-size: 13px; line-height: 18px;" /><br style="background-color: white; color: #666666; font-family: 'Trebuchet MS', Trebuchet, Verdana, sans-serif; font-size: 13px; line-height: 18px;" /><span style="background-color: white; color: #666666; font-family: 'Trebuchet MS', Trebuchet, Verdana, sans-serif; font-size: 13px; line-height: 18px;">This posts covers analyzing malware samples that use timer callbacks to schedule actions.</span><br style="background-color: white; color: #666666; font-family: 'Trebuchet MS', Trebuchet, Verdana, sans-serif; font-size: 13px; line-height: 18px;" /><br style="background-color: white; color: #666666; font-family: 'Trebuchet MS', Trebuchet, Verdana, sans-serif; font-size: 13px; line-height: 18px;" /><span style="background-color: white; color: #666666; font-family: 'Trebuchet MS', Trebuchet, Verdana, sans-serif; font-size: 13px; line-height: 18px;"><a href="http://volatility-labs.blogspot.com/2012/10/movp-41-detecting-malware-with-gdi.html">http://volatility-labs.blogspot.com/2012/10/movp-41-detecting-malware-with-gdi.html</a></span><br style="background-color: white; color: #666666; font-family: 'Trebuchet MS', Trebuchet, Verdana, sans-serif; font-size: 13px; line-height: 18px;" /><br style="background-color: white; color: #666666; font-family: 'Trebuchet MS', Trebuchet, Verdana, sans-serif; font-size: 13px; line-height: 18px;" /><span style="background-color: white; color: #666666; font-family: 'Trebuchet MS', Trebuchet, Verdana, sans-serif; font-size: 13px; line-height: 18px;">Post 2: Taking Screenshots from Memory Dumps</span><br style="background-color: white; color: #666666; font-family: 'Trebuchet MS', Trebuchet, Verdana, sans-serif; font-size: 13px; line-height: 18px;" /><br style="background-color: white; color: #666666; font-family: 'Trebuchet MS', Trebuchet, Verdana, sans-serif; font-size: 13px; line-height: 18px;" /><span style="background-color: white; color: #666666; font-family: 'Trebuchet MS', Trebuchet, Verdana, sans-serif; font-size: 13px; line-height: 18px;">This posts covers the data structures and algorithms required to recreate the state of the screen (a screenshot) at the time of the memory capture. </span><br style="background-color: white; color: #666666; font-family: 'Trebuchet MS', Trebuchet, Verdana, sans-serif; font-size: 13px; line-height: 18px;" /><br style="background-color: white; color: #666666; font-family: 'Trebuchet MS', Trebuchet, Verdana, sans-serif; font-size: 13px; line-height: 18px;" /><span style="background-color: white; color: #666666; font-family: 'Trebuchet MS', Trebuchet, Verdana, sans-serif; font-size: 13px; line-height: 18px;"><a href="http://volatility-labs.blogspot.com/2012/10/movp-43-taking-screenshots-from-memory.html">http://volatility-labs.blogspot.com/2012/10/movp-43-taking-screenshots-from-memory.html</a> </span><br style="background-color: white; color: #666666; font-family: 'Trebuchet MS', Trebuchet, Verdana, sans-serif; font-size: 13px; line-height: 18px;" /><br style="background-color: white; color: #666666; font-family: 'Trebuchet MS', Trebuchet, Verdana, sans-serif; font-size: 13px; line-height: 18px;" /><span style="background-color: white; color: #666666; font-family: 'Trebuchet MS', Trebuchet, Verdana, sans-serif; font-size: 13px; line-height: 18px;">Post 3: Recovering Master Boot Records (MBRs) from Memory</span><br style="background-color: white; color: #666666; font-family: 'Trebuchet MS', Trebuchet, Verdana, sans-serif; font-size: 13px; line-height: 18px;" /><br style="background-color: white; color: #666666; font-family: 'Trebuchet MS', Trebuchet, Verdana, sans-serif; font-size: 13px; line-height: 18px;" /><span style="background-color: white; color: #666666; font-family: 'Trebuchet MS', Trebuchet, Verdana, sans-serif; font-size: 13px; line-height: 18px;">This post covers recovering the MBR from memory and detecting bootkits.</span><br style="background-color: white; color: #666666; font-family: 'Trebuchet MS', Trebuchet, Verdana, sans-serif; font-size: 13px; line-height: 18px;" /><br style="background-color: white; color: #666666; font-family: 'Trebuchet MS', Trebuchet, Verdana, sans-serif; font-size: 13px; line-height: 18px;" /><span style="background-color: white; color: #666666; font-family: 'Trebuchet MS', Trebuchet, Verdana, sans-serif; font-size: 13px; line-height: 18px;"><a href="http://volatility-labs.blogspot.com/2012/10/movp-43-recovering-master-boot-records.html">http://volatility-labs.blogspot.com/2012/10/movp-43-recovering-master-boot-records.html</a> </span><br style="background-color: white; color: #666666; font-family: 'Trebuchet MS', Trebuchet, Verdana, sans-serif; font-size: 13px; line-height: 18px;" /><br style="background-color: white; color: #666666; font-family: 'Trebuchet MS', Trebuchet, Verdana, sans-serif; font-size: 13px; line-height: 18px;" /><span style="background-color: white; color: #666666; font-family: 'Trebuchet MS', Trebuchet, Verdana, sans-serif; font-size: 13px; line-height: 18px;">Post 4: Cache Rules Everything Around Me(mory)</span><br style="background-color: white; color: #666666; font-family: 'Trebuchet MS', Trebuchet, Verdana, sans-serif; font-size: 13px; line-height: 18px;" /><br style="background-color: white; color: #666666; font-family: 'Trebuchet MS', Trebuchet, Verdana, sans-serif; font-size: 13px; line-height: 18px;" /><span style="background-color: white; color: #666666; font-family: 'Trebuchet MS', Trebuchet, Verdana, sans-serif; font-size: 13px; line-height: 18px;">This post covers a new plugin that can recover in-tact files from the Windows Cache Manager. </span><br style="background-color: white; color: #666666; font-family: 'Trebuchet MS', Trebuchet, Verdana, sans-serif; font-size: 13px; line-height: 18px;" /><br style="background-color: white; color: #666666; font-family: 'Trebuchet MS', Trebuchet, Verdana, sans-serif; font-size: 13px; line-height: 18px;" /><span style="background-color: white; color: #666666; font-family: 'Trebuchet MS', Trebuchet, Verdana, sans-serif; font-size: 13px; line-height: 18px;"><a href="http://volatility-labs.blogspot.com/2012/10/movp-44-cache-rules-everything-around.html">http://volatility-labs.blogspot.com/2012/10/movp-44-cache-rules-everything-around.html</a></span><br style="background-color: white; color: #666666; font-family: 'Trebuchet MS', Trebuchet, Verdana, sans-serif; font-size: 13px; line-height: 18px;" /><br style="background-color: white; color: #666666; font-family: 'Trebuchet MS', Trebuchet, Verdana, sans-serif; font-size: 13px; line-height: 18px;" /><span style="background-color: white; color: #666666; font-family: 'Trebuchet MS', Trebuchet, Verdana, sans-serif; font-size: 13px; line-height: 18px;">Post 5: Phalanx 2 Revealed: Using Volatility to Analyze an Advanced Linux Rootkit</span><br style="background-color: white; color: #666666; font-family: 'Trebuchet MS', Trebuchet, Verdana, sans-serif; font-size: 13px; line-height: 18px;" /><br style="background-color: white; color: #666666; font-family: 'Trebuchet MS', Trebuchet, Verdana, sans-serif; font-size: 13px; line-height: 18px;" /><span style="background-color: white; color: #666666; font-family: 'Trebuchet MS', Trebuchet, Verdana, sans-serif; font-size: 13px; line-height: 18px;">This post covers analyzing the Phalax2 rootkit with Volatility and other reversing tools.</span><br style="background-color: white; color: #666666; font-family: 'Trebuchet MS', Trebuchet, Verdana, sans-serif; font-size: 13px; line-height: 18px;" /><br style="background-color: white; color: #666666; font-family: 'Trebuchet MS', Trebuchet, Verdana, sans-serif; font-size: 13px; line-height: 18px;" /><span style="background-color: white; color: #666666; font-family: 'Trebuchet MS', Trebuchet, Verdana, sans-serif; font-size: 13px; line-height: 18px;"><a href="http://volatility-labs.blogspot.com/2012/10/phalanx-2-revealed-using-volatility-to.html">http://volatility-labs.blogspot.com/2012/10/phalanx-2-revealed-using-volatility-to.html</a></span><br style="background-color: white; color: #666666; font-family: 'Trebuchet MS', Trebuchet, Verdana, sans-serif; font-size: 13px; line-height: 18px;" /><br style="background-color: white; color: #666666; font-family: 'Trebuchet MS', Trebuchet, Verdana, sans-serif; font-size: 13px; line-height: 18px;" /><span style="background-color: white; color: #666666; font-family: 'Trebuchet MS', Trebuchet, Verdana, sans-serif; font-size: 13px; line-height: 18px;">This concludes the month of Volatlity, but do not fret, we have already posted a number of other non-MOVP posts and more are coming ;) </span><br />
<span style="background-color: white; color: #666666; font-family: 'Trebuchet MS', Trebuchet, Verdana, sans-serif; font-size: 13px; line-height: 18px;"><br /></span>
<span style="background-color: white; color: #666666; font-family: 'Trebuchet MS', Trebuchet, Verdana, sans-serif; font-size: 13px; line-height: 18px;">Cross posted from </span><span style="color: #666666; font-family: Trebuchet MS, Trebuchet, Verdana, sans-serif; font-size: x-small;"><span style="line-height: 18px;"><a href="http://memoryforensics.blogspot.com/2012/10/week-4-of-month-of-volatility-plugins.html">http://memoryforensics.blogspot.com/2012/10/week-4-of-month-of-volatility-plugins.html</a></span></span>Michael Hale Lighhttp://www.blogger.com/profile/17377327006242921434noreply@blogger.com0tag:blogger.com,1999:blog-3630199973361886660.post-32537547963954849402012-09-28T11:17:00.005-06:002012-10-12T10:23:55.749-06:00Month of Volatility Plugins - Week 3<span style="background-color: white; color: #666666; font-family: 'Trebuchet MS', Trebuchet, Verdana, sans-serif; font-size: 13px; line-height: 18px;">I was writing to announce that week 3 of the month of Volatility plugins is finished, and we now have five more in-depth blog posts covering Windows and Linux internals and rootkit detection as well as a bonus plugin that analyzes Internet Explorer browsing history. These have all been posted on the Volatility Labs blog.</span><br />
<br style="background-color: white; color: #666666; font-family: 'Trebuchet MS', Trebuchet, Verdana, sans-serif; font-size: 13px; line-height: 18px;" />
<span style="background-color: white; color: #666666; font-family: 'Trebuchet MS', Trebuchet, Verdana, sans-serif; font-size: 13px; line-height: 18px;">Post 1: Detecting Malware Hooks in the Windows GUI Subsystem</span><br />
<br style="background-color: white; color: #666666; font-family: 'Trebuchet MS', Trebuchet, Verdana, sans-serif; font-size: 13px; line-height: 18px;" />
<span style="background-color: white; color: #666666; font-family: 'Trebuchet MS', Trebuchet, Verdana, sans-serif; font-size: 13px; line-height: 18px;">This Windows focused post covers detecting malware hooks in the Windows GUI subsystem, including message hooks and event hooks, and what effects these hooks can have on a compromised system.</span><br />
<br style="background-color: white; color: #666666; font-family: 'Trebuchet MS', Trebuchet, Verdana, sans-serif; font-size: 13px; line-height: 18px;" />
<a href="http://volatility-labs.blogspot.com/2012/09/movp-31-detecting-malware-hooks-in.html">http://volatility-labs.blogspot.com/2012/09/movp-31-detecting-malware-hooks-in.htm</a><br />
<br />
<span style="background-color: white; color: #666666; font-family: 'Trebuchet MS', Trebuchet, Verdana, sans-serif; font-size: 13px; line-height: 18px;">Post 2: Shellbags in Memory, SetRegTime, and TrueCrypt Volumes</span><br />
<br style="background-color: white; color: #666666; font-family: 'Trebuchet MS', Trebuchet, Verdana, sans-serif; font-size: 13px; line-height: 18px;" />
<span style="background-color: white; color: #666666; font-family: 'Trebuchet MS', Trebuchet, Verdana, sans-serif; font-size: 13px; line-height: 18px;">This Windows focused post covers finding and recovering shellbags from memory, the forensics importance of shellbags, and analyzes the effects of anti-forensics on shellbag timestamps. It concludes with covering the traces left in shellbags by TrueCrypt.</span><br />
<br style="background-color: white; color: #666666; font-family: 'Trebuchet MS', Trebuchet, Verdana, sans-serif; font-size: 13px; line-height: 18px;" />
<span style="background-color: white; color: #666666; font-family: 'Trebuchet MS', Trebuchet, Verdana, sans-serif; font-size: 13px; line-height: 18px;"><a href="http://volatility-labs.blogspot.com/2012/09/movp-32-shellbags-in-memory-setregtime.html">http://volatility-labs.blogspot.com/2012/09/movp-32-shellbags-in-memory-setregtime.html</a></span><br />
<br />
<span style="background-color: white; color: #666666; font-family: 'Trebuchet MS', Trebuchet, Verdana, sans-serif; font-size: 13px; line-height: 18px;">Post 3: Analyzing USER Handles and the Win32k.sys Gahti </span><br />
<br style="background-color: white; color: #666666; font-family: 'Trebuchet MS', Trebuchet, Verdana, sans-serif; font-size: 13px; line-height: 18px;" />
<span style="background-color: white; color: #666666; font-family: 'Trebuchet MS', Trebuchet, Verdana, sans-serif; font-size: 13px; line-height: 18px;">This Windows focused post introduces two new plugins, one named </span><span style="background-color: white; color: #666666; font-family: 'Courier New', Courier, monospace; font-size: 13px; line-height: 18px;">gahti</span><span style="background-color: white; color: #666666; font-family: 'Trebuchet MS', Trebuchet, Verdana, sans-serif; font-size: 13px; line-height: 18px;"> that determines the various different types of USER objects on a system and another named </span><span style="background-color: white; color: #666666; font-family: 'Courier New', Courier, monospace; font-size: 13px; line-height: 18px;">userhandles</span><span style="background-color: white; color: #666666; font-family: 'Trebuchet MS', Trebuchet, Verdana, sans-serif; font-size: 13px; line-height: 18px;">which traverses the handle table entries and associates them with the owning processes or threads</span><br />
<br style="background-color: white; color: #666666; font-family: 'Trebuchet MS', Trebuchet, Verdana, sans-serif; font-size: 13px; line-height: 18px;" />
<span style="background-color: white; color: #666666; font-family: 'Trebuchet MS', Trebuchet, Verdana, sans-serif; font-size: 13px; line-height: 18px;"><a href="http://volatility-labs.blogspot.com/2012/09/movp-33-analyzing-user-handles-and.html">http://volatility-labs.blogspot.com/2012/09/movp-33-analyzing-user-handles-and.html</a></span><br />
<br style="background-color: white; color: #666666; font-family: 'Trebuchet MS', Trebuchet, Verdana, sans-serif; font-size: 13px; line-height: 18px;" />
<span style="background-color: white; color: #666666; font-family: 'Trebuchet MS', Trebuchet, Verdana, sans-serif; font-size: 13px; line-height: 18px;">Post 4: Recovering tagCLIPDATA: What's In Your Clipboard? </span><br />
<br style="background-color: white; color: #666666; font-family: 'Trebuchet MS', Trebuchet, Verdana, sans-serif; font-size: 13px; line-height: 18px;" />
<span style="background-color: white; color: #666666; font-family: 'Trebuchet MS', Trebuchet, Verdana, sans-serif; font-size: 13px; line-height: 18px;">This Windows focused post covers recovery of the Windows clipboard from physical memory.</span><br />
<br style="background-color: white; color: #666666; font-family: 'Trebuchet MS', Trebuchet, Verdana, sans-serif; font-size: 13px; line-height: 18px;" />
<span style="background-color: white; color: #666666; font-family: 'Trebuchet MS', Trebuchet, Verdana, sans-serif; font-size: 13px; line-height: 18px;"><a href="http://volatility-labs.blogspot.com/2012/09/movp-34-recovering-tagclipdata-whats-in.html">http://volatility-labs.blogspot.com/2012/09/movp-34-recovering-tagclipdata-whats-in.html</a></span><br />
<br />
<span style="background-color: white; color: #666666; font-family: 'Trebuchet MS', Trebuchet, Verdana, sans-serif; font-size: 13px; line-height: 18px;">Post 5: Analyzing the 2008 DFRWS Challenge with Volatility </span><br />
<br style="background-color: white; color: #666666; font-family: 'Trebuchet MS', Trebuchet, Verdana, sans-serif; font-size: 13px; line-height: 18px;" />
<span style="background-color: white; color: #666666; font-family: 'Trebuchet MS', Trebuchet, Verdana, sans-serif; font-size: 13px; line-height: 18px;">This Linux focused post analyzes the 2008 memory challenge with Volatility. It walks through the artifacts produced by the winning team and shows how to recover the same information with Volatility. It then shows plugins in Volatility that can recover artifacts not produced by the winning team.</span><br />
<br style="background-color: white; color: #666666; font-family: 'Trebuchet MS', Trebuchet, Verdana, sans-serif; font-size: 13px; line-height: 18px;" />
<span style="background-color: white; color: #666666; font-family: 'Trebuchet MS', Trebuchet, Verdana, sans-serif; font-size: 13px; line-height: 18px;"><a href="http://volatility-labs.blogspot.com/2012/09/movp-35-analyzing-2008-dfrws-challenge.html">http://volatility-labs.blogspot.com/2012/09/movp-35-analyzing-2008-dfrws-challenge.html</a></span><br />
<br />
<span style="background-color: white; color: #666666; font-family: 'Trebuchet MS', Trebuchet, Verdana, sans-serif; font-size: 13px; line-height: 18px;">Bonus Post: HowTo: Scan for Internet Cache/History and URLs</span><br />
<br style="background-color: white; color: #666666; font-family: 'Trebuchet MS', Trebuchet, Verdana, sans-serif; font-size: 13px; line-height: 18px;" />
<span style="background-color: white; color: #666666; font-family: 'Trebuchet MS', Trebuchet, Verdana, sans-serif; font-size: 13px; line-height: 18px;">This Windows focused post covers how to recover Internet Explorer's cache and history from a memory sample.</span><br />
<br style="background-color: white; color: #666666; font-family: 'Trebuchet MS', Trebuchet, Verdana, sans-serif; font-size: 13px; line-height: 18px;" />
<span style="background-color: white; color: #666666; font-family: 'Trebuchet MS', Trebuchet, Verdana, sans-serif; font-size: 13px; line-height: 18px;"><a href="http://volatility-labs.blogspot.com/2012/09/howto-scan-for-internet-cachehistory.html">http://volatility-labs.blogspot.com/2012/09/howto-scan-for-internet-cachehistory.html</a></span><br />
<br style="background-color: white; color: #666666; font-family: 'Trebuchet MS', Trebuchet, Verdana, sans-serif; font-size: 13px; line-height: 18px;" />
<span style="background-color: white; color: #666666; font-family: 'Trebuchet MS', Trebuchet, Verdana, sans-serif; font-size: 13px; line-height: 18px;">If you have any questions or comments on the posts, please leave a comment on the respective post on the Volatility Labs blog. </span><br />
<span style="background-color: white; color: #666666; font-family: 'Trebuchet MS', Trebuchet, Verdana, sans-serif; font-size: 13px; line-height: 18px;"><br /></span>
<span style="background-color: white; color: #666666; font-family: 'Trebuchet MS', Trebuchet, Verdana, sans-serif; font-size: 13px; line-height: 18px;">Cross-posted from </span><span style="color: #666666; font-family: Trebuchet MS, Trebuchet, Verdana, sans-serif; font-size: x-small;"><span style="line-height: 18px;"><a href="http://memoryforensics.blogspot.com/2012/09/week-3-of-month-of-volatility-plugins.html">http://memoryforensics.blogspot.com/2012/09/week-3-of-month-of-volatility-plugins.html</a></span></span>Michael Hale Lighhttp://www.blogger.com/profile/17377327006242921434noreply@blogger.com0tag:blogger.com,1999:blog-3630199973361886660.post-39302173104631218992012-09-21T09:05:00.001-06:002012-09-21T09:05:47.652-06:00Month of Volatility Plugins - Week 2<span style="background-color: white; color: #666666; font-family: 'Trebuchet MS', Trebuchet, Verdana, sans-serif; font-size: 13px; line-height: 18px;">I was writing to announce that week 2 of the month of Volatility plugins is finished, and we now have five more in-depth blog posts covering Windows and Linux internals and rootkit detection. These have all been posted to the new Volatility Labs blog.</span><br style="background-color: white; color: #666666; font-family: 'Trebuchet MS', Trebuchet, Verdana, sans-serif; font-size: 13px; line-height: 18px;" /><br style="background-color: white; color: #666666; font-family: 'Trebuchet MS', Trebuchet, Verdana, sans-serif; font-size: 13px; line-height: 18px;" /><span style="background-color: white; color: #666666; font-family: 'Trebuchet MS', Trebuchet, Verdana, sans-serif; font-size: 13px; line-height: 18px;">Post 1: Atoms (The New Mutex), Classes and DLL Injection </span><br style="background-color: white; color: #666666; font-family: 'Trebuchet MS', Trebuchet, Verdana, sans-serif; font-size: 13px; line-height: 18px;" /><br style="background-color: white; color: #666666; font-family: 'Trebuchet MS', Trebuchet, Verdana, sans-serif; font-size: 13px; line-height: 18px;" /><span style="background-color: white; color: #666666; font-family: 'Trebuchet MS', Trebuchet, Verdana, sans-serif; font-size: 13px; line-height: 18px;">This Windows focused post covers investigating malware and understanding infections by analyzing the atom tables.</span><br style="background-color: white; color: #666666; font-family: 'Trebuchet MS', Trebuchet, Verdana, sans-serif; font-size: 13px; line-height: 18px;" /><br style="background-color: white; color: #666666; font-family: 'Trebuchet MS', Trebuchet, Verdana, sans-serif; font-size: 13px; line-height: 18px;" /><a href="http://volatility-labs.blogspot.com/2012/09/movp-21-atoms-new-mutex-classes-and-dll.html">http://volatility-labs.blogspot.com/2012/09/movp-21-atoms-new-mutex-classes-and-dll.html</a><br style="background-color: white; color: #666666; font-family: 'Trebuchet MS', Trebuchet, Verdana, sans-serif; font-size: 13px; line-height: 18px;" /><span style="background-color: white; color: #666666; font-family: 'Trebuchet MS', Trebuchet, Verdana, sans-serif; font-size: 13px; line-height: 18px;">Post 2: Malware in your Windows</span><br style="background-color: white; color: #666666; font-family: 'Trebuchet MS', Trebuchet, Verdana, sans-serif; font-size: 13px; line-height: 18px;" /><br style="background-color: white; color: #666666; font-family: 'Trebuchet MS', Trebuchet, Verdana, sans-serif; font-size: 13px; line-height: 18px;" /><span style="background-color: white; color: #666666; font-family: 'Trebuchet MS', Trebuchet, Verdana, sans-serif; font-size: 13px; line-height: 18px;">This Windows focused post covers enumerating and analyzing windows in the GUI subsystem.</span><br style="background-color: white; color: #666666; font-family: 'Trebuchet MS', Trebuchet, Verdana, sans-serif; font-size: 13px; line-height: 18px;" /><br style="background-color: white; color: #666666; font-family: 'Trebuchet MS', Trebuchet, Verdana, sans-serif; font-size: 13px; line-height: 18px;" /><a href="http://volatility-labs.blogspot.com/2012/09/movp-22-malware-in-your-windows.html">http://volatility-labs.blogspot.com/2012/09/movp-22-malware-in-your-windows.html</a><br style="background-color: white; color: #666666; font-family: 'Trebuchet MS', Trebuchet, Verdana, sans-serif; font-size: 13px; line-height: 18px;" /><span style="background-color: white; color: #666666; font-family: 'Trebuchet MS', Trebuchet, Verdana, sans-serif; font-size: 13px; line-height: 18px;">Post 3: Event logs and Service SIDs</span><br style="background-color: white; color: #666666; font-family: 'Trebuchet MS', Trebuchet, Verdana, sans-serif; font-size: 13px; line-height: 18px;" /><br style="background-color: white; color: #666666; font-family: 'Trebuchet MS', Trebuchet, Verdana, sans-serif; font-size: 13px; line-height: 18px;" /><span style="background-color: white; color: #666666; font-family: 'Trebuchet MS', Trebuchet, Verdana, sans-serif; font-size: 13px; line-height: 18px;">This Windows focused post demonstrates recovering event logs from memory and calculating service SIDs.</span><br style="background-color: white; color: #666666; font-family: 'Trebuchet MS', Trebuchet, Verdana, sans-serif; font-size: 13px; line-height: 18px;" /><br style="background-color: white; color: #666666; font-family: 'Trebuchet MS', Trebuchet, Verdana, sans-serif; font-size: 13px; line-height: 18px;" /><a href="http://volatility-labs.blogspot.com/2012/09/movp-23-event-logs-and-service-sids.html">http://volatility-labs.blogspot.com/2012/09/movp-23-event-logs-and-service-sids.html</a><br style="background-color: white; color: #666666; font-family: 'Trebuchet MS', Trebuchet, Verdana, sans-serif; font-size: 13px; line-height: 18px;" /><span style="background-color: white; color: #666666; font-family: 'Trebuchet MS', Trebuchet, Verdana, sans-serif; font-size: 13px; line-height: 18px;">Post 4: Analyzing the Jynx rootkit and LD_PRELOAD </span><br style="background-color: white; color: #666666; font-family: 'Trebuchet MS', Trebuchet, Verdana, sans-serif; font-size: 13px; line-height: 18px;" /><br style="background-color: white; color: #666666; font-family: 'Trebuchet MS', Trebuchet, Verdana, sans-serif; font-size: 13px; line-height: 18px;" /><span style="background-color: white; color: #666666; font-family: 'Trebuchet MS', Trebuchet, Verdana, sans-serif; font-size: 13px; line-height: 18px;">This Linux focused post covers analyzing the Jynx rootkit as well as generic methods for analyzing LD_PRELOAD based rootkits.</span><br style="background-color: white; color: #666666; font-family: 'Trebuchet MS', Trebuchet, Verdana, sans-serif; font-size: 13px; line-height: 18px;" /><br style="background-color: white; color: #666666; font-family: 'Trebuchet MS', Trebuchet, Verdana, sans-serif; font-size: 13px; line-height: 18px;" /><a href="http://volatility-labs.blogspot.com/2012/09/movp-24-analyzing-jynx-rootkit-and.html">http://volatility-labs.blogspot.com/2012/09/movp-24-analyzing-jynx-rootkit-and.html</a><br style="background-color: white; color: #666666; font-family: 'Trebuchet MS', Trebuchet, Verdana, sans-serif; font-size: 13px; line-height: 18px;" /><span style="background-color: white; color: #666666; font-family: 'Trebuchet MS', Trebuchet, Verdana, sans-serif; font-size: 13px; line-height: 18px;">Post 5: Investigating In-Memory Network Data with Volatility </span><br style="background-color: white; color: #666666; font-family: 'Trebuchet MS', Trebuchet, Verdana, sans-serif; font-size: 13px; line-height: 18px;" /><br style="background-color: white; color: #666666; font-family: 'Trebuchet MS', Trebuchet, Verdana, sans-serif; font-size: 13px; line-height: 18px;" /><span style="background-color: white; color: #666666; font-family: 'Trebuchet MS', Trebuchet, Verdana, sans-serif; font-size: 13px; line-height: 18px;">This Linux focused post goes through each of the Linux Volatility plugins related to recovering network data from memory, such as network connections, packets, and the routing cache.</span><br style="background-color: white; color: #666666; font-family: 'Trebuchet MS', Trebuchet, Verdana, sans-serif; font-size: 13px; line-height: 18px;" /><br style="background-color: white; color: #666666; font-family: 'Trebuchet MS', Trebuchet, Verdana, sans-serif; font-size: 13px; line-height: 18px;" /><a href="http://volatility-labs.blogspot.com/2012/09/movp-25-investigating-in-memory-network.html">http://volatility-labs.blogspot.com/2012/09/movp-25-investigating-in-memory-network.html</a><br style="background-color: white; color: #666666; font-family: 'Trebuchet MS', Trebuchet, Verdana, sans-serif; font-size: 13px; line-height: 18px;" /><span style="background-color: white; color: #666666; font-family: 'Trebuchet MS', Trebuchet, Verdana, sans-serif; font-size: 13px; line-height: 18px;">If you have any questions or comments on the posts, please leave a comment on the respective post on the Volatility Labs blog.</span><br />
<span style="background-color: white; color: #666666; font-family: 'Trebuchet MS', Trebuchet, Verdana, sans-serif; font-size: 13px; line-height: 18px;"><br /></span>
<span style="background-color: white; color: #666666; font-family: 'Trebuchet MS', Trebuchet, Verdana, sans-serif; font-size: 13px; line-height: 18px;">Cross-posted from </span><a href="http://memoryforensics.blogspot.com/2012/09/week-2-of-month-of-volatility-plugins.html">http://memoryforensics.blogspot.com/2012/09/week-2-of-month-of-volatility-plugins.html</a><br />
Michael Hale Lighhttp://www.blogger.com/profile/17377327006242921434noreply@blogger.com0tag:blogger.com,1999:blog-3630199973361886660.post-48469406802577458072012-09-14T10:57:00.002-06:002012-09-14T10:57:45.527-06:00Month of Volatility Plugins - Week 1 <span style="background-color: white; color: #666666; font-family: 'Trebuchet MS', Trebuchet, Verdana, sans-serif; font-size: 13px; line-height: 18px;">I was writing to announce that week 1 of the month of Volatility plugins is finished, and we now have five in-depth blog posts covering Windows and Linux internals and rootkit detection. These have all been posted to the new Volatility Labs blog.</span><br />
<br style="background-color: white; color: #666666; font-family: 'Trebuchet MS', Trebuchet, Verdana, sans-serif; font-size: 13px; line-height: 18px;" />
<span style="background-color: white; color: #666666; font-family: 'Trebuchet MS', Trebuchet, Verdana, sans-serif; font-size: 13px; line-height: 18px;">Post 1: Logon Sessions, Processes, and Images</span><br />
<br style="background-color: white; color: #666666; font-family: 'Trebuchet MS', Trebuchet, Verdana, sans-serif; font-size: 13px; line-height: 18px;" />
<span style="background-color: white; color: #666666; font-family: 'Trebuchet MS', Trebuchet, Verdana, sans-serif; font-size: 13px; line-height: 18px;">This Windows focused post covers linking processes to their logon session, detecting hidden processes using session structures, and determining the loaded the drivers mapped into each session.</span><br />
<br style="background-color: white; color: #666666; font-family: 'Trebuchet MS', Trebuchet, Verdana, sans-serif; font-size: 13px; line-height: 18px;" />
<a href="http://volatility-labs.blogspot.com/2012/09/movp-11-logon-sessions-processes-and.html" style="background-color: white; color: #888888; font-family: 'Trebuchet MS', Trebuchet, Verdana, sans-serif; font-size: 13px; line-height: 18px; text-decoration: none;" target="_blank">http://volatility-labs.<wbr></wbr>blogspot.com/2012/09/movp-11-<wbr></wbr>logon-sessions-processes-and.<wbr></wbr>html</a><br />
<br style="background-color: white; color: #666666; font-family: 'Trebuchet MS', Trebuchet, Verdana, sans-serif; font-size: 13px; line-height: 18px;" />
<span style="background-color: white; color: #666666; font-family: 'Trebuchet MS', Trebuchet, Verdana, sans-serif; font-size: 13px; line-height: 18px;">Post 2: Window Stations and Clipboard Malware</span><br />
<br style="background-color: white; color: #666666; font-family: 'Trebuchet MS', Trebuchet, Verdana, sans-serif; font-size: 13px; line-height: 18px;" />
<span style="background-color: white; color: #666666; font-family: 'Trebuchet MS', Trebuchet, Verdana, sans-serif; font-size: 13px; line-height: 18px;">This Windows focused post covers enumerating and analyzing window stations and clipboard monitoring malware.</span><br />
<br style="background-color: white; color: #666666; font-family: 'Trebuchet MS', Trebuchet, Verdana, sans-serif; font-size: 13px; line-height: 18px;" />
<a href="http://volatility-labs.blogspot.com/2012/09/movp-12-window-stations-and-clipboard.html" style="background-color: white; color: #888888; font-family: 'Trebuchet MS', Trebuchet, Verdana, sans-serif; font-size: 13px; line-height: 18px; text-decoration: none;" target="_blank">http://volatility-labs.<wbr></wbr>blogspot.com/2012/09/movp-12-<wbr></wbr>window-stations-and-clipboard.<wbr></wbr>html</a><br />
<br style="background-color: white; color: #666666; font-family: 'Trebuchet MS', Trebuchet, Verdana, sans-serif; font-size: 13px; line-height: 18px;" />
<span style="background-color: white; color: #666666; font-family: 'Trebuchet MS', Trebuchet, Verdana, sans-serif; font-size: 13px; line-height: 18px;">Post 3: Desktops, Heaps, and Ransomware</span><br />
<br style="background-color: white; color: #666666; font-family: 'Trebuchet MS', Trebuchet, Verdana, sans-serif; font-size: 13px; line-height: 18px;" />
<span style="background-color: white; color: #666666; font-family: 'Trebuchet MS', Trebuchet, Verdana, sans-serif; font-size: 13px; line-height: 18px;">This Windows focused post covers finding rogue desktops used to hide applications and created by ransomware, linking threads to desktops, analyzing the desktop heap for memory corruptions, and profiling heap allocations to locate USER objects.</span><br />
<br style="background-color: white; color: #666666; font-family: 'Trebuchet MS', Trebuchet, Verdana, sans-serif; font-size: 13px; line-height: 18px;" />
<a href="http://volatility-labs.blogspot.com/2012/09/movp-13-desktops-heaps-and-ransomware.html" style="background-color: white; color: #888888; font-family: 'Trebuchet MS', Trebuchet, Verdana, sans-serif; font-size: 13px; line-height: 18px; text-decoration: none;" target="_blank">http://volatility-labs.<wbr></wbr>blogspot.com/2012/09/movp-13-<wbr></wbr>desktops-heaps-and-ransomware.<wbr></wbr>html</a><br />
<br style="background-color: white; color: #666666; font-family: 'Trebuchet MS', Trebuchet, Verdana, sans-serif; font-size: 13px; line-height: 18px;" />
<span style="background-color: white; color: #666666; font-family: 'Trebuchet MS', Trebuchet, Verdana, sans-serif; font-size: 13px; line-height: 18px;">Post 4: Average Coder Rootkit, Bash History, and Elevated Processes</span><br />
<br style="background-color: white; color: #666666; font-family: 'Trebuchet MS', Trebuchet, Verdana, sans-serif; font-size: 13px; line-height: 18px;" />
<span style="background-color: white; color: #666666; font-family: 'Trebuchet MS', Trebuchet, Verdana, sans-serif; font-size: 13px; line-height: 18px;">This Linux focused post covers analyzing the Average Coder rootkit, recovering .bash_history from memory, even when faced with anti-forensics, and finding elevated processes.</span><br />
<br style="background-color: white; color: #666666; font-family: 'Trebuchet MS', Trebuchet, Verdana, sans-serif; font-size: 13px; line-height: 18px;" />
<a href="http://volatility-labs.blogspot.com/2012/09/movp-14-average-coder-rootkit-bash.html" style="background-color: white; color: #888888; font-family: 'Trebuchet MS', Trebuchet, Verdana, sans-serif; font-size: 13px; line-height: 18px; text-decoration: none;" target="_blank">http://volatility-labs.<wbr></wbr>blogspot.com/2012/09/movp-14-<wbr></wbr>average-coder-rootkit-bash.<wbr></wbr>html</a><br />
<br style="background-color: white; color: #666666; font-family: 'Trebuchet MS', Trebuchet, Verdana, sans-serif; font-size: 13px; line-height: 18px;" />
<span style="background-color: white; color: #666666; font-family: 'Trebuchet MS', Trebuchet, Verdana, sans-serif; font-size: 13px; line-height: 18px;">Post 5: KBeast Rootkit, Detecting Hidden Modules, and sysfs</span><br />
<br style="background-color: white; color: #666666; font-family: 'Trebuchet MS', Trebuchet, Verdana, sans-serif; font-size: 13px; line-height: 18px;" />
<span style="background-color: white; color: #666666; font-family: 'Trebuchet MS', Trebuchet, Verdana, sans-serif; font-size: 13px; line-height: 18px;">This Linux focused post covers analyzing the KBeast rootkit, finding modules unlinked from the module list, and the forensic values of sysfs.</span><br />
<br style="background-color: white; color: #666666; font-family: 'Trebuchet MS', Trebuchet, Verdana, sans-serif; font-size: 13px; line-height: 18px;" />
<a href="http://volatility-labs.blogspot.com/2012/09/movp-15-kbeast-rootkit-detecting-hidden.html" style="background-color: white; color: #888888; font-family: 'Trebuchet MS', Trebuchet, Verdana, sans-serif; font-size: 13px; line-height: 18px; text-decoration: none;" target="_blank">http://volatility-labs.<wbr></wbr>blogspot.com/2012/09/movp-15-<wbr></wbr>kbeast-rootkit-detecting-<wbr></wbr>hidden.html</a><br />
<br style="background-color: white; color: #666666; font-family: 'Trebuchet MS', Trebuchet, Verdana, sans-serif; font-size: 13px; line-height: 18px;" />
<span style="background-color: white; color: #666666; font-family: 'Trebuchet MS', Trebuchet, Verdana, sans-serif; font-size: 13px; line-height: 18px;">If you have any questions or comments on the posts, please leave a comment on the respective post on the Volatility Labs blog. </span><br />
<span style="background-color: white; color: #666666; font-family: 'Trebuchet MS', Trebuchet, Verdana, sans-serif; font-size: 13px; line-height: 18px;"><br /></span>
<span style="background-color: white; color: #666666; font-family: 'Trebuchet MS', Trebuchet, Verdana, sans-serif; font-size: 13px; line-height: 18px;">Cross-posted from </span><span style="color: #666666; font-family: Trebuchet MS, Trebuchet, Verdana, sans-serif; font-size: x-small;"><span style="line-height: 18px;"><a href="http://memoryforensics.blogspot.com/2012/09/week-1-of-month-of-volatility-plugins.html">http://memoryforensics.blogspot.com/2012/09/week-1-of-month-of-volatility-plugins.html</a></span></span>Michael Hale Lighhttp://www.blogger.com/profile/17377327006242921434noreply@blogger.com0tag:blogger.com,1999:blog-3630199973361886660.post-52566364624885415182012-08-06T09:26:00.000-06:002012-08-06T09:26:38.251-06:00Volatility 2.1 Enters the Digital Atmosphere!<br />
Volatility 2.1 is out! Its open source. Its Python. It supports raw (dd-style) memory dumps, EWF format, hibernation files, acquisition over firewire, and Microsoft crash dumps from 32- and 64-bit Windows XP, Server 2003, Vista, Server 2008, and 7 - all service packs. Its command-line, fully-scriptable with a powerful API that runs on Windows, Linux, and OSX analysis systems. It now includes the malware plugins in the core codebase. It adds the ability to analyze process environment variables, registry shimcache from memory, attacker command history and full console input/ouptut buffers to the already impressive list of 70+ plugins.<br />
<br />
<ul>
<li><a href="https://www.volatilesystems.com/default/volatility">Volatility Homepage</a></li>
<li><a href="http://code.google.com/p/volatility/downloads/list">Volatility 2.1 Downloads</a></li>
<li><a href="http://code.google.com/p/volatility/wiki/FAQ21">Volatility 2.1 FAQ</a></li>
<li><a href="http://code.google.com/p/volatility/wiki/CommandReference21">Volatility 2.1 Command Reference</a></li>
<li><a href="http://code.google.com/p/volatility/wiki/FeaturesByPlugin21">Volatility 2.1 Features By Plugin</a></li>
<li><a href="http://code.google.com/p/volatility/wiki/BasicUsage21">Volatility 2.1 Usage Guide</a></li>
<li><a href="http://code.google.com/p/volatility/wiki/FAQ21#How_can_I_contribute_to_Volatility">Share your thoughts, submit your bugs, and contribute your ideas or code</a></li>
</ul>
<br />
But that's not all - Volatility 2.2 is coming later this year, and there is already an overflowing list of new operating systems support, plugins, and features developed by the Volatility team and a handful of new contributors from the Volatility community. <a href="https://www.volatilesystems.com/default/omfw">Open Memory Forensics Workshop</a> is also right around the corner, where I will personally be releasing a suite of plugins to investigate a realm of memory that many people don't even know exists - and where no forensic malware analysis tools have gone before. Until then, enjoy the 2.1 release!<br />Michael Hale Lighhttp://www.blogger.com/profile/17377327006242921434noreply@blogger.com0tag:blogger.com,1999:blog-3630199973361886660.post-45474595627237195552012-06-28T18:07:00.000-06:002012-08-05T21:02:44.171-06:00QuickPost: Flame & VolatilityAfter reading the very interesting <a href="http://blog.ioactive.com/2012/06/inside-flame-you-say-shell32-i-say.html">Inside Flame</a> article by IOActive's Ruben Santamarta, <a href="https://twitter.com/bradarndt/status/218464958759972864" style="background-color: white;">@bradarndt</a><span style="background-color: white;"> posed the question: can <a href="http://code.google.com/p/volatility/">volatility</a> find flame modules? My first reaction was <i>of course it can</i>...in fact </span><span style="background-color: white;"><a href="http://www.crysys.hu/skywiper/skywiper.pdf">CrySyS Lab</a> used volatility in <u>Section 3.3 Injections</u> of their initial technical report. However, I figured it would be best to check and make sure before replying. In this blog post, I'll cover some simple steps to confirm an infection based on Ruben's VAD/shell32 discovery. </span><br />
<span style="background-color: white;"><br />
<span style="background-color: white;">Another disclaimer: I'll be using an XPSP3 x86 hibernation sample for the analysis. This sample was created and then provided to me by a user on the <a href="http://lists.volatilesystems.com/mailman/listinfo">Volatility mailing list</a>. The sample isn't mine to share, so please don't request a copy. </span></span><br />
<span style="background-color: white;"><br />
<span style="background-color: white;">To get started, I wanted to find out the process id for services.exe. It is said that Flame also injects code into explorer.exe and winlogon.exe, but we just need one for the experiment. Below you can see the pid is 912. </span><br />
<span style="background-color: white;"></span><br />
<span style="font-family: 'Courier New', Courier, monospace; font-size: x-small;">$ <b>python vol.py -f ~/Desktop/flame/hiberfil.sys pslist</b></span><br />
<span style="font-family: 'Courier New', Courier, monospace; font-size: x-small;">Volatile Systems Volatility Framework 2.1_alpha</span><br />
<span style="font-family: 'Courier New', Courier, monospace; font-size: x-small;">Offset(V) Name PID PPID Thds Hnds Sess Wow64 Start Exit </span><br />
<span style="font-family: 'Courier New', Courier, monospace; font-size: x-small;">---------- -------------------- ------ ------ ------ -------- ------ ------ -------------------- --------------------</span><br />
<span style="font-family: 'Courier New', Courier, monospace; font-size: x-small;">0x84fca830 System 4 0 53 334 ------ 0 </span><br />
<span style="font-family: 'Courier New', Courier, monospace; font-size: x-small;">0x84cf29e8 smss.exe 764 4 3 19 ------ 0 2012-06-03 07:47:45 </span><br />
<span style="font-family: 'Courier New', Courier, monospace; font-size: x-small;">0x84eba020 csrss.exe 844 764 11 523 0 0 2012-06-03 07:47:47 </span><br />
<span style="font-family: 'Courier New', Courier, monospace; font-size: x-small;">0x84c16460 winlogon.exe 868 764 18 443 0 0 2012-06-03 07:47:48 </span><br />
<span style="font-family: 'Courier New', Courier, monospace; font-size: x-small;">0x84cae5a8 services.exe <span style="color: red;"><b>912</b></span> 868 37 966 0 0 2012-06-03 07:47:48 </span><br />
<span style="font-family: 'Courier New', Courier, monospace; font-size: x-small;">[snip] </span><br />
<br />
In Ruben's <a href="https://blogger.googleusercontent.com/img/b/R29vZ2xl/AVvXsEg1CawLXFfGqj4APiI3gFgazo2b6XyMF2LkMjQLrUk_c8jsexgkXcD0u_4OuEmU2UCVaoClqgBLxclGyBDZ3iUr4u_uZ89rPSSouS0Rxckv1jXNQR5q8q_ZDPnKgNG7qp_wHljhc9vO7Jf0/s1600/image-blog7.png">2nd to the last screenshot</a>, he shows VirtualAlloc being called with parameters MEM_COMMIT (1000h) and PAGE_EXECUTE_READWRITE (40h). Thus we should be able to find the region using the <a href="http://code.google.com/p/volatility/wiki/CommandReference21#malfind">malfind</a> plugin.<br />
<br />
<span style="font-family: 'Courier New', Courier, monospace; font-size: x-small;">$ <b>python vol.py -f ~/Desktop/flame/hiberfil.sys -p 912 malfind</b></span><br />
<span style="font-family: 'Courier New', Courier, monospace; font-size: x-small;">Volatile Systems Volatility Framework 2.1_alpha</span><span style="font-family: 'Courier New', Courier, monospace; font-size: x-small;"><br /></span><br />
<span style="font-family: 'Courier New', Courier, monospace; font-size: x-small;">Process: services.exe Pid: 912 Address: <b><span style="color: red;">0xe40000</span></b></span><br />
<span style="font-family: 'Courier New', Courier, monospace; font-size: x-small;">Vad Tag: VadS Protection: PAGE_EXECUTE_READWRITE</span><br />
<span style="font-family: 'Courier New', Courier, monospace; font-size: x-small;">Flags: CommitCharge: 1, MemCommit: 1, PrivateMemory: 1, Protection: 6</span><span style="font-family: 'Courier New', Courier, monospace; font-size: x-small;"><br /></span><br />
<span style="font-family: 'Courier New', Courier, monospace; font-size: x-small;">0x00e40000 ba ba 0d f0 00 00 e3 00 30 25 80 7c b7 24 80 7c ........0%.|.$.|</span><br />
<span style="font-family: 'Courier New', Courier, monospace; font-size: x-small;">0x00e40010 b3 1d 90 7c 55 8b ec 51 53 56 57 33 ff 89 7d fc ...|U..QSVW3..}.</span><br />
<span style="font-family: 'Courier New', Courier, monospace; font-size: x-small;">0x00e40020 e8 00 00 00 00 58 89 45 fc 8b 45 fc 6a 64 59 48 .....X.E..E.jdYH</span><br />
<span style="font-family: 'Courier New', Courier, monospace; font-size: x-small;">0x00e40030 49 89 45 fc 74 5b 81 38 ba ba 0d f0 75 f1 8d 70 I.E.t[.8....u..p</span><span style="font-family: 'Courier New', Courier, monospace; font-size: x-small;"><br /></span><br />
<span style="font-family: 'Courier New', Courier, monospace; font-size: x-small;">0xe40000 <b><span style="color: red;">baba0df000</span></b> MOV EDX, 0xf00dba</span><br />
<span style="font-family: 'Courier New', Courier, monospace; font-size: x-small;">0xe40005 00e3 ADD BL, AH</span><br />
<span style="font-family: 'Courier New', Courier, monospace; font-size: x-small;">0xe40007 0030 ADD [EAX], DH</span><br />
<span style="font-family: 'Courier New', Courier, monospace; font-size: x-small;">0xe40009 25807cb724 AND EAX, 0x24b77c80</span><br />
<span style="font-family: 'Courier New', Courier, monospace; font-size: x-small;">0xe4000e 807cb31d90 CMP BYTE [EBX+ESI*4+0x1d], 0x90</span><br />
<span style="font-family: 'Courier New', Courier, monospace; font-size: x-small;">0xe40013 7c55 JL 0xe4006a</span><br />
<span style="font-family: 'Courier New', Courier, monospace; font-size: x-small;">0xe40015 8bec MOV EBP, ESP</span><br />
<span style="font-family: 'Courier New', Courier, monospace; font-size: x-small;">0xe40017 51 PUSH ECX</span><br />
<span style="font-family: 'Courier New', Courier, monospace; font-size: x-small;">0xe40018 53 PUSH EBX</span><br />
<span style="font-family: 'Courier New', Courier, monospace; font-size: x-small;">0xe40019 56 PUSH ESI</span><br />
<span style="font-family: 'Courier New', Courier, monospace; font-size: x-small;">0xe4001a 57 PUSH EDI</span><br />
<span style="font-family: 'Courier New', Courier, monospace; font-size: x-small;">0xe4001b 33ff XOR EDI, EDI</span><br />
<span style="font-family: 'Courier New', Courier, monospace; font-size: x-small;">0xe4001d 897dfc MOV [EBP+0xfffffffc], EDI</span><br />
<span style="font-family: 'Courier New', Courier, monospace; font-size: x-small;">0xe40020 e800000000 CALL 0xe40025</span><br />
<span style="font-family: 'Courier New', Courier, monospace; font-size: x-small;">0xe40025 58 POP EAX</span><br />
<span style="font-family: 'Courier New', Courier, monospace; font-size: x-small;">0xe40026 8945fc MOV [EBP+0xfffffffc], EAX</span><br />
<span style="font-family: 'Courier New', Courier, monospace; font-size: x-small;">0xe40029 8b45fc MOV EAX, [EBP+0xfffffffc]</span><br />
<span style="font-family: 'Courier New', Courier, monospace; font-size: x-small;">0xe4002c 6a64 PUSH 0x64</span><br />
<span style="font-family: 'Courier New', Courier, monospace; font-size: x-small;">0xe4002e 59 POP ECX</span><br />
<span style="font-family: 'Courier New', Courier, monospace; font-size: x-small;">0xe4002f 48 DEC EAX</span><br />
<span style="font-family: 'Courier New', Courier, monospace; font-size: x-small;">0xe40030 49 DEC ECX</span><br />
<span style="font-family: 'Courier New', Courier, monospace; font-size: x-small;">0xe40031 8945fc MOV [EBP+0xfffffffc], EAX</span><br />
<span style="font-family: 'Courier New', Courier, monospace; font-size: x-small;">0xe40034 745b JZ 0xe40091</span><br />
<span style="font-family: 'Courier New', Courier, monospace; font-size: x-small;">0xe40036 8138baba0df0 CMP DWORD [EAX], <span style="color: red;"><b>0xf00dbaba</b></span></span><br />
<span style="font-family: 'Courier New', Courier, monospace; font-size: x-small;">0xe4003c 75f1 JNZ 0xe4002f</span><br />
<br />
Here you can see the virtually allocated region, whose base address in process memory is 0xe40000. I did not previously know the significance of the highlighted 0xf00dbaba, but in Ruben's <a href="https://blogger.googleusercontent.com/img/b/R29vZ2xl/AVvXsEhceNlhHSGKOFg_6gmhp4a1wx18sg202NtZ48Rf4tnt4tVkAcHGA_3oYPZbYYhkTFqRraPTDC2ZVJ6fQa70hLoKicvsA_5diB3hTUH8X6tZ-xZIFXRt1gy4Sg9PBIM69BHpf11RIlHu-udy/s1600/image-blog8.png">last screenshot</a>, he commented it "magic" in IDA. This is probably a good value to quickly scan for and see where else it turns up.<br />
<br />
For this next task, I'll use <a href="http://code.google.com/p/volatility/wiki/CommandReference21#yarascan">yarascan</a> with that 4-byte signature.<br />
<br />
<span style="font-family: 'Courier New', Courier, monospace; font-size: x-small;">$ <b>python vol.py -f ~/Desktop/flame/hiberfil.sys -p 912 yarascan -Y "{ba ba 0d f0}"</b></span><br />
<span style="font-family: 'Courier New', Courier, monospace; font-size: x-small;">Volatile Systems Volatility Framework 2.1_alpha</span><br />
<span style="font-family: 'Courier New', Courier, monospace; font-size: x-small;"></span><br />
<span style="font-family: 'Courier New', Courier, monospace; font-size: x-small;">Rule: r1</span><br />
<span style="font-family: 'Courier New', Courier, monospace; font-size: x-small;">Owner: Process services.exe Pid 912</span><br />
<span style="font-family: 'Courier New', Courier, monospace; font-size: x-small;">0x00e40000 <b><span style="color: red;">ba ba 0d f0</span></b> 00 00 e3 00 30 25 80 7c b7 24 80 7c ........0%.|.$.|</span><br />
<span style="font-family: 'Courier New', Courier, monospace; font-size: x-small;">0x00e40010 b3 1d 90 7c 55 8b ec 51 53 56 57 33 ff 89 7d fc ...|U..QSVW3..}.</span><br />
<span style="font-family: 'Courier New', Courier, monospace; font-size: x-small;">0x00e40020 e8 00 00 00 00 58 89 45 fc 8b 45 fc 6a 64 59 48 .....X.E..E.jdYH</span><br />
<span style="font-family: 'Courier New', Courier, monospace; font-size: x-small;">0x00e40030 49 89 45 fc 74 5b 81 38 ba ba 0d f0 75 f1 8d 70 I.E.t[.8....u..p</span><br />
<span style="font-family: 'Courier New', Courier, monospace; font-size: x-small;">Rule: r1</span><br />
<span style="font-family: 'Courier New', Courier, monospace; font-size: x-small;">Owner: Process services.exe Pid 912</span><br />
<span style="font-family: 'Courier New', Courier, monospace; font-size: x-small;">0x00e40038 <span style="color: red;"><b>ba ba 0d f0</b></span> 75 f1 8d 70 04 8b 0e 6a ff ff 31 8b ....u..p...j..1.</span><br />
<span style="font-family: 'Courier New', Courier, monospace; font-size: x-small;">0x00e40048 d8 ff 50 08 85 c0 75 2c 8b 06 83 7c 07 0c 00 74 ..P...u,...|...t</span><br />
<span style="font-family: 'Courier New', Courier, monospace; font-size: x-small;">0x00e40058 0e ff 75 10 03 c7 ff 75 0c ff 70 08 ff 50 0c 81 ..u....u..p..P..</span><br />
<span style="font-family: 'Courier New', Courier, monospace; font-size: x-small;">0x00e40068 c7 20 02 00 00 81 ff 00 55 00 00 72 db 8b 06 ff ........U..r....</span><br />
<span style="font-family: 'Courier New', Courier, monospace; font-size: x-small;"></span><br />
<span style="font-family: 'Courier New', Courier, monospace; font-size: x-small;">Rule: r1</span><br />
<span style="font-family: 'Courier New', Courier, monospace; font-size: x-small;">Owner: Process services.exe Pid 912</span><br />
<span style="font-family: 'Courier New', Courier, monospace; font-size: x-small;">0x041aa6c5 <span style="color: red;"><b>ba ba 0d f0</b></span> 75 f1 8d 70 04 8b 0e 6a ff ff 31 8b ....u..p...j..1.</span><br />
<span style="font-family: 'Courier New', Courier, monospace; font-size: x-small;">0x041aa6d5 d8 ff 50 08 85 c0 75 2c 8b 06 83 7c 07 0c 00 74 ..P...u,...|...t</span><br />
<span style="font-family: 'Courier New', Courier, monospace; font-size: x-small;">0x041aa6e5 0e ff 75 10 03 c7 ff 75 0c ff 70 08 ff 50 0c 81 ..u....u..p..P..</span><br />
<span style="font-family: 'Courier New', Courier, monospace; font-size: x-small;">0x041aa6f5 c7 20 02 00 00 81 ff 00 55 00 00 72 db 8b 06 ff ........U..r....</span><br />
<span style="font-family: 'Courier New', Courier, monospace; font-size: x-small;">Rule: r1</span><br />
<span style="font-family: 'Courier New', Courier, monospace; font-size: x-small;">Owner: Process services.exe Pid 912</span><br />
<span style="font-family: 'Courier New', Courier, monospace; font-size: x-small;">0x041aacd8 <span style="color: red;"><b>ba ba 0d f0</b></span> 89 48 04 ff b6 18 09 00 00 83 c0 14 .....H..........</span><br />
<span style="font-family: 'Courier New', Courier, monospace; font-size: x-small;">0x041aace8 ff b6 14 09 00 00 89 45 b4 50 ff 56 20 8b 45 b4 .......E.P.V..E.</span><br />
<span style="font-family: 'Courier New', Courier, monospace; font-size: x-small;">0x041aacf8 83 c4 0c 89 47 1c 8b 45 ec 39 58 04 75 09 c7 45 ....G..E.9X.u..E</span><br />
<span style="font-family: 'Courier New', Courier, monospace; font-size: x-small;">0x041aad08 f0 1b 00 ff ff eb 30 8b 4d e8 89 08 8b 4d ec 33 ......0.M....M.3</span><span style="font-family: 'Courier New', Courier, monospace; font-size: x-small;"><br /></span><br />
<span style="font-family: 'Courier New', Courier, monospace; font-size: x-small;">Rule: r1</span><br />
<span style="font-family: 'Courier New', Courier, monospace; font-size: x-small;">Owner: Process services.exe Pid 912</span><br />
<span style="font-family: 'Courier New', Courier, monospace; font-size: x-small;">0x7cb836c5 <span style="color: red;"><b>ba ba 0d f0</b></span> 75 f1 8d 70 04 8b 0e 6a ff ff 31 8b ....u..p...j..1.</span><br />
<span style="font-family: 'Courier New', Courier, monospace; font-size: x-small;">0x7cb836d5 d8 ff 50 08 85 c0 75 2c 8b 06 83 7c 07 0c 00 74 ..P...u,...|...t</span><br />
<span style="font-family: 'Courier New', Courier, monospace; font-size: x-small;">0x7cb836e5 0e ff 75 10 03 c7 ff 75 0c ff 70 08 ff 50 0c 81 ..u....u..p..P..</span><br />
<span style="font-family: 'Courier New', Courier, monospace; font-size: x-small;">0x7cb836f5 c7 20 02 00 00 81 ff 00 55 00 00 72 db 8b 06 ff ........U..r....</span><br />
<span style="font-family: 'Courier New', Courier, monospace; font-size: x-small;">Rule: r1</span><br />
<span style="font-family: 'Courier New', Courier, monospace; font-size: x-small;">Owner: Process services.exe Pid 912</span><br />
<span style="font-family: 'Courier New', Courier, monospace; font-size: x-small;">0x7cb83cd8 <span style="color: red;"><b>ba ba 0d f0</b></span> 89 48 04 ff b6 18 09 00 00 83 c0 14 .....H..........</span><br />
<span style="font-family: 'Courier New', Courier, monospace; font-size: x-small;">0x7cb83ce8 ff b6 14 09 00 00 89 45 b4 50 ff 56 20 8b 45 b4 .......E.P.V..E.</span><br />
<span style="font-family: 'Courier New', Courier, monospace; font-size: x-small;">0x7cb83cf8 83 c4 0c 89 47 1c 8b 45 ec 39 58 04 75 09 c7 45 ....G..E.9X.u..E</span><br />
<span style="font-family: 'Courier New', Courier, monospace; font-size: x-small;">0x7cb83d08 f0 1b 00 ff ff eb 30 8b 4d e8 89 08 8b 4d ec 33 ......0.M....M.3</span><br />
</span><br />
<div>
<span style="background-color: white;"><br /></span></div>
<span style="background-color: white;">
</span><br />
<div>
<span style="background-color: white;">The scan turned up 6 hits, across 3 different VAD regions (so 2 hits in each region). The following output from vadinfo shows details on the 3 regions. You can make the following conclusions: </span></div>
<span style="background-color: white;">
</span><br />
<div>
<span style="background-color: white;"><br /></span></div>
<span style="background-color: white;">
</span><br />
<div>
<span style="background-color: white;">* The first pair of hits (at 0x00e40000 and 0x00e40038) are both inside the VAD that starts at 0xe40000. This is the one we saw in malfind that is private and R/W/E. </span></div>
<span style="background-color: white;">
<div>
<br /></div>
<div>
* The second pair of hits (at 0x041aa6c5 and 0x041aacd8) are both inside the VAD that starts at 0x03f60000, originally a file mapping for xpsp2res.dll. </div>
<div>
<br /></div>
<div>
* The third pair of hits (at 0x7cb836c5 and 0x7cb83cd8) are both inside the VAD that starts at 0x7c9c0000, originally a file mapping for shell32.dll. </div>
<div>
<br /></div>
<div>
<div>
<span style="font-family: 'Courier New', Courier, monospace; font-size: x-small;">$ <b>python vol.py -f ~/Desktop/flame/hiberfil.sys -p 912 vadinfo</b></span></div>
<div>
<span style="font-family: 'Courier New', Courier, monospace; font-size: x-small;"><br /></span></div>
<div>
<span style="font-family: 'Courier New', Courier, monospace; font-size: x-small;">[snip]</span></div>
<div>
<span style="font-family: 'Courier New', Courier, monospace; font-size: x-small;"><br /></span></div>
<div>
<span style="font-family: 'Courier New', Courier, monospace; font-size: x-small;">VAD node @ 0x84e7e788 Start <span style="color: red;"><b>0x00e40000</b></span> End 0x00e40fff Tag VadS</span></div>
<div>
<span style="font-family: 'Courier New', Courier, monospace; font-size: x-small;">Flags: CommitCharge: 1, MemCommit: 1, PrivateMemory: 1, Protection: 6</span></div>
<div>
<span style="font-family: 'Courier New', Courier, monospace; font-size: x-small;">Protection: PAGE_EXECUTE_READWRITE</span></div>
<div>
<span style="font-family: 'Courier New', Courier, monospace; font-size: x-small;"><br /></span></div>
<div>
<span style="font-family: 'Courier New', Courier, monospace; font-size: x-small;">VAD node @ 0x846102d8 Start <span style="color: red;"><b>0x03f60000</b></span> End 0x04224fff Tag Vad </span></div>
<div>
<span style="font-family: 'Courier New', Courier, monospace; font-size: x-small;">Flags: ImageMap: 1, Protection: 7</span></div>
<div>
<span style="font-family: 'Courier New', Courier, monospace; font-size: x-small;">Protection: PAGE_EXECUTE_WRITECOPY</span></div>
<div>
<span style="font-family: 'Courier New', Courier, monospace; font-size: x-small;">ControlArea @84f5a630 Segment e1a79008</span></div>
<div>
<span style="font-family: 'Courier New', Courier, monospace; font-size: x-small;">Dereference list: Flink 00000000, Blink 00000000</span></div>
<div>
<span style="font-family: 'Courier New', Courier, monospace; font-size: x-small;">NumberOfSectionReferences: 0 NumberOfPfnReferences: 708</span></div>
<div>
<span style="font-family: 'Courier New', Courier, monospace; font-size: x-small;">NumberOfMappedViews: 20 NumberOfUserReferences: 20</span></div>
<div>
<span style="font-family: 'Courier New', Courier, monospace; font-size: x-small;">WaitingForDeletion Event: 00000000</span></div>
<div>
<span style="font-family: 'Courier New', Courier, monospace; font-size: x-small;">Control Flags: Accessed: 1, File: 1, HadUserReference: 1, Image: 1</span></div>
<div>
<span style="font-family: 'Courier New', Courier, monospace; font-size: x-small;">FileObject @84b7f278, Name: \WINDOWS\system32\xpsp2res.dll</span></div>
<div>
<span style="font-family: 'Courier New', Courier, monospace; font-size: x-small;">First prototype PTE: e1a79040 Last contiguous PTE: fffffffc</span></div>
<div>
<span style="font-family: 'Courier New', Courier, monospace; font-size: x-small;">Flags2: Inherit: 1</span></div>
<div>
<span style="font-family: 'Courier New', Courier, monospace; font-size: x-small;"><br /></span></div>
<div>
<span style="font-family: 'Courier New', Courier, monospace; font-size: x-small;">VAD node @ 0x84cc5d20 Start <span style="color: red;"><b>0x7c9c0000</b></span> End 0x7cfe7fff Tag Vad </span></div>
<div>
<span style="font-family: 'Courier New', Courier, monospace; font-size: x-small;">Flags: CommitCharge: 1605, ImageMap: 1, Protection: 7</span></div>
<div>
<span style="font-family: 'Courier New', Courier, monospace; font-size: x-small;">Protection: PAGE_EXECUTE_WRITECOPY</span></div>
<div>
<span style="font-family: 'Courier New', Courier, monospace; font-size: x-small;">ControlArea @84dd08f8 Segment e1a69000</span></div>
<div>
<span style="font-family: 'Courier New', Courier, monospace; font-size: x-small;">Dereference list: Flink 00000000, Blink 00000000</span></div>
<div>
<span style="font-family: 'Courier New', Courier, monospace; font-size: x-small;">NumberOfSectionReferences: 1 NumberOfPfnReferences: 2047</span></div>
<div>
<span style="font-family: 'Courier New', Courier, monospace; font-size: x-small;">NumberOfMappedViews: 29 NumberOfUserReferences: 30</span></div>
<div>
<span style="font-family: 'Courier New', Courier, monospace; font-size: x-small;">WaitingForDeletion Event: 00000000</span></div>
<div>
<span style="font-family: 'Courier New', Courier, monospace; font-size: x-small;">Control Flags: Accessed: 1, File: 1, HadUserReference: 1, Image: 1</span></div>
<div>
<span style="font-family: 'Courier New', Courier, monospace; font-size: x-small;">FileObject @84ec4df0, Name: <span style="color: red;"><b>\WINDOWS\system32\shell32.dll</b></span></span></div>
<div>
<span style="font-family: 'Courier New', Courier, monospace; font-size: x-small;">First prototype PTE: e1a69038 Last contiguous PTE: fffffffc</span></div>
<div>
<span style="font-family: 'Courier New', Courier, monospace; font-size: x-small;">Flags2: Inherit: 1</span></div>
</div>
<div>
<br /></div>
<div>
Another view of Flame's interesting file mapping / memory replacement behavior can be seen with the <a href="http://code.google.com/p/volatility/wiki/CommandReference21#ldrmodules">ldrmodules</a> plugin. If shell32.dll was loaded normally via LoadLibrary, it would exist in the PEB's InLoadOrderModuleList, InInitOrderModuleList, and InMemoryOrderModuleList. However, as you can see below, it does not exist in any of those 3 lists. It appears the same as a DLL that *was* loaded with LoadLibrary and then maliciously unlinked with _LIST_ENTRY overwrites. </div>
<div>
<br /></div>
<div>
<div>
<span style="font-family: 'Courier New', Courier, monospace; font-size: x-small;">$ <b>python vol.py -f ~/Desktop/flame/hiberfil.raw -p 912 ldrmodules</b></span></div>
<div>
<span style="font-family: 'Courier New', Courier, monospace; font-size: x-small;">Volatile Systems Volatility Framework 2.1_alpha</span></div>
<div>
<span style="font-family: 'Courier New', Courier, monospace; font-size: x-small;">Pid Process Base InLoad InInit InMem MappedPath</span></div>
<div>
<span style="font-family: 'Courier New', Courier, monospace; font-size: x-small;">-------- -------------------- ---------- ------ ------ ----- ----------</span></div>
<div>
<span style="font-family: 'Courier New', Courier, monospace; font-size: x-small;"> 912 services.exe 0x7c900000 True True True \WINDOWS\system32\ntdll.dll</span></div>
<div>
<span style="font-family: 'Courier New', Courier, monospace; font-size: x-small;"> 912 services.exe 0x7c9c0000 <b><span style="color: red;">False False False</span></b> \WINDOWS\system32\shell32.dll</span></div>
<div>
<span style="font-family: 'Courier New', Courier, monospace; font-size: x-small;">[snip]</span></div>
</div>
<div>
<br /></div>
<div>
To acquire a copy of the Flame DLL (MSSECMGR.OCX), I passed the base address of the fake shell32.dll module to <a href="http://code.google.com/p/volatility/wiki/CommandReference21#dlldump">dlldump</a>. </div>
<div>
<br /></div>
<div>
<div>
<span style="font-family: 'Courier New', Courier, monospace; font-size: x-small;">$ <b>python vol.py -f ~/Desktop/flame/hiberfil.raw dlldump -p 912 -b 0x7c9c0000 -D flame/</b></span></div>
<div>
<span style="font-family: 'Courier New', Courier, monospace; font-size: x-small;">Volatile Systems Volatility Framework 2.1_alpha</span></div>
<div>
<span style="font-family: 'Courier New', Courier, monospace; font-size: x-small;">Dumping UNKNOWN, Process: services.exe, Base: 7c9c0000 output: module.912.48ae5a8.7c9c0000.dll</span></div>
</div>
<div>
<br /></div>
<div>
Now the file can be retrieved and loaded into IDA for further inspection. Its clearly not shell32.dll due to the presence of an export named DDEnumCallback. </div>
<div>
<br /></div>
<div class="separator" style="clear: both; text-align: center;">
<a href="https://blogger.googleusercontent.com/img/b/R29vZ2xl/AVvXsEhZ-FZtuAYxblCmhJ79AqgWE_-gSF4heYoZ6aZvIp9qPc4UfbcC34ukTniomhZF8rq8_Yc5zm0aeSiN2NhumO0k6ke_x6SJrIHWgkKGxmzBuKZ8VhnNjJ6wOb5hYYRXo_4GdhrgHiOSRgFQ/s1600/IDAFlame.png" imageanchor="1" style="margin-left: 1em; margin-right: 1em;"><img border="0" height="246" src="https://blogger.googleusercontent.com/img/b/R29vZ2xl/AVvXsEhZ-FZtuAYxblCmhJ79AqgWE_-gSF4heYoZ6aZvIp9qPc4UfbcC34ukTniomhZF8rq8_Yc5zm0aeSiN2NhumO0k6ke_x6SJrIHWgkKGxmzBuKZ8VhnNjJ6wOb5hYYRXo_4GdhrgHiOSRgFQ/s320/IDAFlame.png" width="320" /></a></div>
<div>
<br /></div>
<div>
Well, this concludes the concise and rather spontaneous blog post. I would like to congratulate both CrySyS Lab and Ruben for their extremely useful write-ups and discoveries. Also thank you to Brad for asking the question and Michael for creating the Flame hibernation image. </div>
<div>
<br /></div>
<br />
<br />
</span>Michael Hale Lighhttp://www.blogger.com/profile/17377327006242921434noreply@blogger.com1tag:blogger.com,1999:blog-3630199973361886660.post-85228321563473045662011-10-13T18:02:00.025-06:002012-08-05T21:03:39.841-06:00Ain't Nuthin But a K(Timer) Thing, BabyLast <a href="http://mnin.blogspot.com/2011/10/zeroaccess-volatility-and-kernel-timers.html">Volatility Friday</a>, I hinted that kernel timers objects (KTIMER) can be enumerated in physical memory dumps to help with analyzing ZeroAccess, Rustock, and other rootkits. This week, we'll discuss a bit more about what exactly timers are used for, how they are installed, and how to detect them - both the wrong way(s) and the right way(s). <a href="http://code.google.com/p/volatility/" style="color: red;">Volatility</a><span style="color: red;"> is the only memory forensics framework giving you ability to work with kernel timers</span>, which is just another reason why I think this tool is unique and exciting.<br />
<br />
<span style="font-weight: bold;">What are Kernel Timers?</span><br />
<br />
<a href="http://msdn.microsoft.com/en-us/library/ff564655%28v=VS.85%29.aspx">Timer Objects and DPCs</a> are most often used by malware for synchronization and notification. A rootkit driver may create a timer to simply be notified when a given time elapses. If you think this is similar to just calling Sleep(), then you're right. However, calling Sleep() puts your thread to sleep and prevents it from performing other actions while you wait. <span style="color: red;">Also, Sleep() doesn't create any interesting forensic artifacts, so its a good thing when malware uses timers instead</span>. But functionality-wise, you can also create timers that reset after expiring. In other words, instead of just being notified once, you can be notified on a periodic basis. Maybe the rootkit wants to check if a DNS host name resolves every 5 minutes, or poll a given registry key for changes every 2 seconds. Timers are great for these types of tasks.<br />
<br />
When you create a timer, you can supply a DPC routine (Deferred Procedure Call) - otherwise known as a callback function. When the timer expires, the system calls your callback function. The address of your callback is stored in the KTIMER structure along with information on when (and how often) to execute the callback. And now you should understand why kernel timers are such useful artifacts for malware analysis. Rootkits will load drivers in kernel memory, but try hard to stay undetected. <span style="color: red;">But their use of timers gives us a clear shot directly to where the rootkit is hiding in memory.</span> All we need to do is find the KTIMERs.<br />
<br />
<span style="font-weight: bold;">ETIMER, KTIMER and Windows API</span><br />
<br />
You may be familiar with the fact that every executive process (EPROCESS) has a nested KPROCESS. Every executive thread (ETHREAD) has a nested KTHREAD. The same is true for timers. Every ETIMER has a nested KTIMER. We need to figure out the difference between these structures and then determine how to find the right ones. Let's take a look at them in Windbg:<br />
<pre>kd> <span style="font-weight: bold;">dt _ETIMER</span>
nt!_ETIMER
+0x000 KeTimer : _KTIMER
+0x028 TimerApc : _KAPC
+0x058 TimerDpc : _KDPC
+0x078 ActiveTimerListEntry : _LIST_ENTRY
+0x080 Lock : Uint4B
+0x084 Period : Int4B
+0x088 ApcAssociated : UChar
+0x089 WakeTimer : UChar
+0x08c WakeTimerListEntry : _LIST_ENTRY
kd> <span style="font-weight: bold;">dt _KTIMER</span>
ntdll!_KTIMER
+0x000 Header : _DISPATCHER_HEADER
+0x010 DueTime : _ULARGE_INTEGER
+0x018 TimerListEntry : _LIST_ENTRY
+0x020 Dpc : Ptr32 _KDPC
+0x024 Period : Int4B</pre>
KTIMER.DueTime and KTIMER.Period store information on when the timer expires. KTIMER.Dpc is a KDPC whose DeferredRoutine points to the registered callback function. As you can see, KTIMER.TimerListEntry is a doubly-linked list that ties the various KTIMERs together. So as we are initially working through this, you may think that by finding all ETIMERs, you'll find all KTIMERs. Right? <span style="color: red;">Keep reading to find out why that's dead wrong. </span><br />
<br />
So which API functions do you use to work with timers? The following Native APIs are implemented in ntdll.dll and call through to the kernel via SSDT. The handles returned by NtCreateTimer and NtOpenTimer are for ETIMER objects, and can be seen in the process's handle table.<br />
<ul>
<li>NtCreateTimer</li>
<li>NtOpenTimer</li>
<li>NtCancelTimer</li>
<li>NtQueryTimer</li>
<li>NtSetTimer</li>
</ul>
The following APIs implemented in ntoskrnl.exe work directly with KTIMER objects:<br />
<ul>
<li>KeInitializeTimerEx</li>
<li>KeClearTimer</li>
<li>KeCancelTimer</li>
<li>KeSetTimer</li>
<li>KeCheckForTimer</li>
</ul>
If open ETIMERs can be seen in a process's handle table, then we can use Volatility's <a href="http://code.google.com/p/volatility/wiki/CommandReference#handles">handles</a> command to view them. Just pass the "-t Timer" parameters like this:<br />
<pre>$ <span style="font-weight: bold;">python vol.py -f mem.dmp handles -t Timer</span>
Volatile Systems Volatility Framework 2.1_alpha
Offset(V) Pid Type Details
0x81fd5638 636 Timer ''
0x820d1a78 636 Timer ''
0x8217fcc0 636 Timer 'userenv: refresh timer for 636:1516'
0x81e406c8 636 Timer 'userenv: refresh timer for 636:1892'
0x823092c0 680 Timer ''
0x81f46200 680 Timer ''
0x8228c608 692 Timer ''
0x81e4f148 692 Timer ''
[...]</pre>
We make several observations from this output. First, timers set by usermode APIs can optionally have names (set with the ObjectAttributes parameter to NtCreateTimer). Second, and more important to our topic at hand is that none of the timers shown belong to kernel drivers (by "belong" I mean that none of the callbacks point to kernel mode functions). And this brings us to our next big discussion. How do we find timers with callbacks in kernel mode? A few options were considered:<br />
1. ETHREAD.ActiveTimerListHead is a LIST_ENTRY of ETIMERs. However, it is only for active timers. Not what we want.<br />
2. KTHREAD.Timer is a KTIMER, but again, not the same as the ones we want (you can walk the KTHREAD.Timer.TimerListEntry and see that there aren't many entries).<br />
3. The nt!KiTimerTableListHead global symbol in ntoskrnl.exe. This is a promising possibility, but unfortunately Microsoft has not been keeping it very consistent across operating system. The KiTimerTableListHead points to a different type of data on 2000, XP, 2003, 2008, and Vista. Sadly, it doesn't even exist on Windows 7.<br />
4. The ETIMER objects in process handle tables. Not what we want (as previously described) because it doesn't contain timers with kernel callbacks.<br />
5. Pool Scanning. Some RE shows that ETIMERs exist in non-paged pools roughly 0x98 bytes in size, with the tag Tim\xE5. If we can find these pools, and thus all ETIMERs, then we'll find all KTIMERs, right?<br />
Here we are again back at the question we've asked twice already. <span style="color: red;">The answer is NO</span>. Although ETIMER contains a nested KTIMER, it is possible to create a timer without allocation of a new ETIMER. For example, the KTIMER can be a variable in a driver's .data section. This is indicated by the fact that API functions such as <a href="http://msdn.microsoft.com/en-us/library/ff552168%28v=VS.85%29.aspx">KeInitializeTimer</a> require the caller to allocate storage for the KTIMER. For example:<br />
<pre>KTIMER Timer;
KeInitializeTimer(&Timer);</pre>
This is in fact how many drivers allocate storage for the timers they use. A real example can be seen in srv.sys:<br />
<pre>.data:0001F990 ; struct _KTIMER ScavengerTimer
.data:0001F990 _ScavengerTimer </pre>
So the significance to this is - scanning for ETIMER objects and trying to reference the nested KTIMER will fail to locate the KTIMER used by srv.sys. KTIMERs don't need to exist in dynamically allocated pools at all.<br />
<br />
<span style="font-weight: bold;">The Best of the Worst </span><br />
<br />
Despite KiTimerTableListHead changing so much across OS versions, its probably our best bet. On Windows 2000, KiTimerTableListHead was an array of 128 LIST_ENTRY structures for KTIMERs. For example it may have looked like this:<br />
<pre>#define TIMER_TABLE_SIZE 128
#define LIST_ENTRY KiTimerTableListHead[TIMER_TABLE_SIZE];</pre>
On Windows XP SP0-SP3 x86 and Windows 2003 SP0, Microsoft expanded the array to 258 LIST_ENTRYs.<br />
<pre>#define TIMER_TABLE_SIZE 256
#define LIST_ENTRY KiTimerTableListHead[TIMER_TABLE_SIZE];</pre>
On Windows XP x64, Windows 2003 SP1-SP2, and Vista SP0-SP2, Microsoft not only expanded it, but changed the type of data it pointed to. It was changed to 512 KTIMER_TABLE_ENTRY structures.<br />
<pre>#define TIMER_TABLE_SIZE 512
typedef struct _KTIMER_TABLE_ENTRY {
LIST_ENTRY Entry;
ULARGE_INTEGER Time;
} KTIMER_TABLE_ENTRY, *PKTIMER_TABLE_ENTRY;
#define KTIMER_TABLE_ENTRY KiTimerTableListHead[TIMER_TABLE_SIZE];</pre>
Starting with Windows 7, there is no more KiTimerTableListHead. The KTIMERs can be found by walking a list pointed to by the KPCR (KPCR.PrcbData.TimerTable.TimerEntries). Credits for finding the Windows 7 list goes to <a href="http://www.moonsols.com/">Matt Suiche</a> who wrote a <a href="http://pastebin.com/FiRsGW3f">Windbg plugin</a> supporting Windows XP and Windows 7.<br />
<span style="color: red;">So despite the variance among data structures, its annoying but certainly not impossible to write a Volatility plugin that supports XP, 2003, 2008, Vista, <span style="font-style: italic;">and</span> 7. In fact, it can be done in less than 150 lines of Python, including comments, and without relying on PDB support!</span> The plugin has been commited to <a href="http://code.google.com/p/malwarecookbook/source/detail?r=111">malware.py</a> and will be considered one of the new plugins fully released with the 2.1 alpha version of the malware plugins later this year.<br />
<div style="font-weight: bold;">
Malware Analysis with Kernel Timers</div>
Here's the moment we've been waiting for! You may recall a snippet of last week's post about detecting ZeroAccess due to its use of timers with a callback function in an unknown region of kernel memory.<br />
<pre>$ <span style="font-weight: bold;">python vol.py -f zeroaccess2.vmem timers</span>
Volatile Systems Volatility Framework 2.1_alpha
Offset DueTime Period(ms) Signaled Routine Module
0x805598e0 0x00000084:0xce8b961c 1000 Yes 0x80523dee ntoskrnl.exe
0x820a1e08 0x00000084:0xdf3c0c1c 30000 Yes 0xb2d2a385 afd.sys
0x81ebf0b8 0x00000084:0xce951f84 0 - 0xf89c23f0 TDI.SYS
[snip]
0x81dbeb78 0x00000131:0x2e896402 0 - 0xf83faf6f NDIS.sys
0x81e8b4f0 0x00000131:0x2e896402 0 - 0xf83faf6f NDIS.sys
0x81eb8e28 0x00000084:0xe5855f6a 0 - 0x80534e48 ntoskrnl.exe
<span style="color: red;">0xb20bbbb0 0x00000084:0xd4de72d2 60000 Yes 0xb20b5990 UNKNOWN</span>
0x8210d910 0x80000000:0x0a7efa36 0 - 0x80534e48 ntoskrnl.exe
0x82274190 0x80000000:0x711befba 0 - 0x80534e48 ntoskrnl.exe
0x81de9690 0x80000000:0x0d0c3e8a 0 - 0x80534e48 ntoskrnl.exe</pre>
Beautiful! The UNKNOWN indicates that the memory can't be attributed to any legitimate kernel driver. How about a Rustock.C variant?<br />
<pre>$ <span style="font-weight: bold;">python volatility.py timers -f rustock-c.vmem </span>
Volatile Systems Volatility Framework 1.4_rc1
Offset DueTime Period(ms) Signaled Routine Module
0xf730a790 0x00000000:0x6db0f0b4 0 - 0xf72fb385 srv.sys
0x80558a40 0x00000000:0x68f10168 1000 Yes 0x80523026 ntoskrnl.exe
0x80559160 0x00000000:0x695c4b3a 0 - 0x80526bac ntoskrnl.exe
<span style="color: red;">0x820822e4 0x00000000:0xa2a56bb0 150000 Yes 0x81c1642f UNKNOWN</span>
0xf842f150 0x00000000:0xb5cb4e80 0 - 0xf841473e Ntfs.sys
0xf70d00e0 0x00000000:0x81eb644c 0 - 0xf70c18de HTTP.sys
0xf70cd808 0x00000000:0x81eb644c 60000 Yes 0xf70b6202 HTTP.sys
0x81e57fb0 0x00000000:0x6a4f7b16 30000 Yes 0xf7b62385 afd.sys
<span style="color: red;">0x81f5f8d4 0x00000000:0x6a517bc8 3435 Yes 0x81c1642f UNKNOWN</span>
0x82055218 0x00000000:0x6cb1d516 10000 Yes 0xf8a126c4 watchdog.sys
0x82022530 0x00000000:0x6cb1d516 10000 Yes 0xf8a126c4 watchdog.sys
0x82007270 0x80000000:0x139ab60a 0 - 0x80534016 ntoskrnl.exe
0x82041b40 0x00000098:0x9f1d5f32 0 - 0xf83fafdf NDIS.sys
0x8207acc0 0x80000000:0x0f13ff2e 0 - 0x80534016 ntoskrnl.exe
<span style="color: red;">0x81f7eaf4 0x00000000:0x6d0082b0 20000 Yes 0x81c1642f UNKNOWN</span>
0x82035308 0x00000000:0x74442ce8 60000 Yes 0xf83fb72c NDIS.sys
0x81f2f158 0x80000000:0x520f0f9e 0 - 0x80534016 ntoskrnl.exe</pre>
Ahah! Rustock registers three different timers, pointing to the same unknown region of memory, but that expire at different time periods.<br />
<span style="font-weight: bold;">What Can't You Do with Volatility?</span><br />
With a bit of research, a little coding, and some malware samples to test with, there isn't much you can't do with Volatility. Timers with callbacks pointing to unknown kernel memory regions are important artifacts that you don't want to miss. Please join me in welcoming the timers plugin to the malware forensic space!Michael Hale Lighhttp://www.blogger.com/profile/17377327006242921434noreply@blogger.com0tag:blogger.com,1999:blog-3630199973361886660.post-35911770406195034932011-10-13T09:03:00.008-06:002012-08-05T21:06:07.164-06:00ZeroAccess, Volatility, and Kernel TimersAs today is Volatility Friday, we'll discuss how to hunt ZeroAccess in memory by following the lead of several others and then writing our own custom plugin. I first want to recognize the work done on this topic by <a href="http://www.kernelmode.info/forum/viewtopic.php?f=13&t=1175#p9090">Frank Boldewin</a>, <a href="http://resources.infosecinstitute.com/step-by-step-tutorial-on-reverse-engineering-malware-the-zeroaccessmaxsmiscer-crimeware-rootkit/">Giuseppe Bonfa</a>, and <a href="http://pxnow.prevx.com/content/blog/zeroaccess_analysis.pdf">Marco Giuliani</a>. They are the ones doing the reverse engineering here - I am just translating their findings and showing how to do things "the Volatility way."<br />
<br />
<span style="font-size: 130%; font-weight: bold;">The First Sample: e6823f932c2b40d2025d78bb78d64458</span><br />
<br />
This is the same sample Frank used in his analysis (see link above) so you will want to read that post first. Frank's course of actions to find ZeroAccess were:<br />
<br />
1) Find the DEVICE_OBJECT that starts with ACPI#PNP[...]<br />
2) Find the DRIVER_OBJECT to which the device belongs (note the driver is unnamed)<br />
3) Take the DriverStart and DriverSize members of the DRIVER_OBJECT to dump the rootkit's kernel code<br />
4) Search for threads executing in the same space as the rootkit's kernel code<br />
5) Find the process with a fake usermode ADS name (i.e. a colon ':' in the name)<br />
6) Dump the malicious process<br />
<br />
Okay so let's get to work with Volatility! We'll follow nearly the same order of operations that Frank used, however to start instead of looking in the \global?? directory for the DEVICE_OBJECT, we'll just use the <a href="http://code.google.com/p/volatility/wiki/CommandReference#devicetree">devicetree</a> plugin.<br />
<pre><span style="font-size: 85%;">$ <span style="font-weight: bold;">python vol.py -f zeroaccess1.vmem devicetree</span>
Volatile Systems Volatility Framework 2.1_alpha
DRV 0x022dba18 '\\Driver\\NetBT'
---| DEV 0x81dc7d30 NetBT_Tcpip_{9B5A1EAD-7852-455F-9740-5E1FCD05D812} FILE_DEVICE_NETWORK
---| DEV 0x82251ca0 NetBt_Wins_Export FILE_DEVICE_NETWORK
---| DEV 0x81eb3030 NetbiosSmb FILE_DEVICE_NETWORK
DRV 0x022e1c08 '\\FileSystem\\MRxDAV'
---| DEV 0x81caca58 WebDavRedirector FILE_DEVICE_NETWORK_FILE_SYSTEM
<span style="color: red; font-weight: bold;">DRV 0x022e3880</span>
<span style="color: red; font-weight: bold;">---| DEV 0x81f3ee48 ACPI#PNP0303#2&da1a3ff&0 FILE_DEVICE_UNKNOWN</span>
DRV 0x022f9f38 '\\Driver\\intelppm'
---| DEV 0x81c8cdd8 (unnamed) FILE_DEVICE_UNKNOWN</span></pre>
There's a unnamed DRIVER_OBJECT at physical offset 0x022e3880 that has a DEVICE_OBJECT at virtual address 0x81f3ee48 with name ACPI#PNP[...]. That seems to correlate with Frank's findings, so it feels like we're on the right track. The next thing I want to do is figure out the DriverStart and DriverSize of the DRIVER_OBJECT. One could easily modify the devicetree plugin to print this information (we'll show how to do it programatically in a minute) but for the time being I'll just use <a href="http://code.google.com/p/volatility/wiki/CommandReference#volshell">volshell</a>. The values displayed will be in decimal.<br />
<pre><span style="font-size: 85%;">$ <span style="font-weight: bold;">python vol.py -f zeroaccess1.vmem volshell</span>
Volatile Systems Volatility Framework 2.1_alpha
Current context: process System, pid=4, ppid=0 DTB=0x319000
To get help, type 'hh()'
In [1]: <span style="font-weight: bold;">dt("_DEVICE_OBJECT", 0x81f3ee48)</span>
[CType _DEVICE_OBJECT] @ 0x81F3EE48
0x0 : Type 3
0x2 : Size 184
0x4 : ReferenceCount 3
0x8 : DriverObject 2181970048
In [2]: <span style="font-weight: bold;">dt("_DRIVER_OBJECT", 2181970048)</span>
[CType _DRIVER_OBJECT] @ 0x820E3880
0x0 : Type 4
0x2 : Size 168
0x4 : DeviceObject 2180247112
0x8 : Flags 18
<span style="color: red; font-weight: bold;">0xc : DriverStart 2987057152</span>
<span style="color: red; font-weight: bold;">0x10 : DriverSize 126976</span>
0x14 : DriverSection 2180702128
0x18 : DriverExtension 2181970216
In [3]: <span style="font-weight: bold;">hex(2987057152)</span>
Out[3]: '0xb20ae000'
In [4]: <span style="font-weight: bold;">hex(126976)</span>
Out[4]: '0x1f000'
</span></pre>
Now that we know the driver's kernel code exists at 0xb20ae000, we can dump it with <a href="http://code.google.com/p/volatility/wiki/CommandReference#moddump">moddump</a>.<br />
<pre><span style="font-size: 85%;">$ <span style="font-weight: bold;">python vol.py -f zeroaccess1.vmem moddump -o 0xb20ae000 -D zeroaccess/</span>
Volatile Systems Volatility Framework 2.1_alpha
Dumping Unknown, Base: b20ae000 output: driver.b20ae000.sys
$ <span style="font-weight: bold;">strings zeroaccess/driver.b20ae000.sys</span>
!This program cannot be run in DOS mode.
X6Rich
.text
`.rdata
@.data
.reloc
PVVV
Ul;Upw
!This program cannot be run in DOS mode.
Rich
.text
RSA1
A8C,
!This program cannot be run in DOS mode.
Rich
.text
PPPTh
ZwCreateFile
ZwTestAlert
ntdll.dll
ExitProcess
KERNEL32.dll
1234567890123456789012345678901234567890123456789012345678901234
CryptAcquireContextW
CryptImportKey
CryptCreateHash
CryptHashData
CryptVerifySignatureW
CryptDestroyHash
CryptReleaseContext
MD5Init
MD5Update
ntp2.usno.navy.mil
ntp.adc.am
tock.usask.ca
ntp.crifo.org
ntp1.arnes.si
ntp.ucsd.edu
ntp.duckcorp.org
wwv.nist.gov
clock.isc.org</span></pre>
Based on the "This program cannot[...]" strings, the driver has multiple embedded PE files, so you can already begin to expect code injection or at least a user mode presence. Hold that thought.<br />
<br />
The 4th step in Frank's analysis was to check for suspicious threads based on their starting or current IP location. You can do this easily with the <a href="http://code.google.com/p/volatility/wiki/CommandReference#threads">threads</a> plugin by filtering for orphan threads (-F OrphanThread).<br />
<pre><span style="font-size: 85%;">$ <span style="font-weight: bold;">python vol.py -f zeroaccess1.vmem threads -F OrphanThread</span>
Volatile Systems Volatility Framework 2.1_alpha
------
ETHREAD: 0x81c6b4a0 Pid: 4 Tid: 908
Tags: OrphanThread,SystemThread
Created: 2011-10-13 14:26:18
Exited: -
Owning Process: 0x823c8830 'System'
Attached Process: 0x823c8830 'System'
State: Waiting:WrQueue
BasePriority: 0x8
Priority: 0x8
TEB: 0x00000000
<span style="color: red; font-weight: bold;">StartAddress: 0xb20b6105</span>
ServiceTable: 0x80552fa0
[0] 0x80501b8c
[1] -
[2] -
[3] -
Win32Thread: 0x00000000
CrossThreadFlags: PS_CROSS_THREAD_FLAGS_SYSTEM
b20b6105: 58 POP EAX
b20b6106: 870424 XCHG [ESP], EAX
b20b6109: ffd0 CALL EAX
b20b610b: 8b0df8bb0bb2 MOV ECX, [0xb20bbbf8]
b20b6111: ff2500920bb2 JMP DWORD [0xb20b9200]
b20b6117: 64a118000000 MOV EAX, [FS:0x18]</span></pre>
As you can see, this thread's StartAddress is 0xb20b6105 - well within range of the ZeroAccess driver. By using the <a href="http://code.google.com/p/volatility/wiki/CommandReference#callbacks">callbacks</a> plugin, you can also see there's a suspicious IoRegisterShutdownNotification routine pointing at approximately the same range in kernel memory.<br />
<pre><span style="font-size: 85%;">$ <span style="font-weight: bold;">python vol.py -f zeroaccess1.vmem callbacks</span>
Volatile Systems Volatility Framework 2.1_alpha
Type Callback Owner
PsSetCreateProcessNotifyRoutine 0xf87ad194 vmci.sys
KeBugCheckCallbackListHead 0xf83e65ef NDIS.sys (Ndis miniport)
KeBugCheckCallbackListHead 0x806d77cc hal.dll (ACPI 1.0 - APIC platform UP)
KeRegisterBugCheckReasonCallback 0xf8b7aab8 mssmbios.sys (SMBiosData)
KeRegisterBugCheckReasonCallback 0xf8b7aa70 mssmbios.sys (SMBiosRegistry)
KeRegisterBugCheckReasonCallback 0xf8b7aa28 mssmbios.sys (SMBiosDataACPI)
KeRegisterBugCheckReasonCallback 0xf82e01be USBPORT.SYS (USBPORT)
KeRegisterBugCheckReasonCallback 0xf82e011e USBPORT.SYS (USBPORT)
KeRegisterBugCheckReasonCallback 0xf82f7522 VIDEOPRT.SYS (Videoprt)
IoRegisterShutdownNotification 0xf88ddc74 Cdfs.SYS (\FileSystem\Cdfs)
IoRegisterShutdownNotification 0xf8bb05be Fs_Rec.SYS (\FileSystem\Fs_Rec)
IoRegisterShutdownNotification 0xf8303c6a VIDEOPRT.SYS (\Driver\VgaSave)
IoRegisterShutdownNotification 0xb2d108fa vmhgfs.sys (\FileSystem\vmhgfs)
IoRegisterShutdownNotification 0xf8bb05be Fs_Rec.SYS (\FileSystem\Fs_Rec)
IoRegisterShutdownNotification 0xf8303c6a VIDEOPRT.SYS (\Driver\mnmdd)
IoRegisterShutdownNotification 0xf8303c6a VIDEOPRT.SYS (\Driver\vmx_svga)
IoRegisterShutdownNotification 0xf8303c6a VIDEOPRT.SYS (\Driver\RDPCDD)
<span style="color: red; font-weight: bold;">IoRegisterShutdownNotification 0xb20b49d0 </span>
IoRegisterShutdownNotification 0xf86aa73a MountMgr.sys (\Driver\MountMgr)
IoRegisterShutdownNotification 0xf8bb05be Fs_Rec.SYS (\FileSystem\Fs_Rec)</span></pre>
Next we'll try and locate ZeroAccess in user mode based on Frank's findings. At first I didn't understand what "Fake Usermode ADS" meant, but when I used the <a href="http://code.google.com/p/volatility/wiki/CommandReference#pslist">pslist</a> and <a href="http://code.google.com/p/volatility/wiki/CommandReference#dlllist">dlllist</a> commands it all started to make sense. The image name from pslist comes from EPROCESS.ImageFileName (in kernel memory) and the info from dlllist comes from the PEB (in user memory). In normal cases, output from the two plugins will match, but in this case you can see the discrepancy:<br />
<pre><span style="font-size: 85%;">$ <span style="font-weight: bold;">python vol.py -f zeroaccess1.vmem pslist</span>
Volatile Systems Volatility Framework 2.1_alpha
Offset(V) Name PID PPID Thds Hnds Time
---------- -------------------- ------ ------ ------ ------ -------------------
0x823c8830 System 4 0 57 398 1970-01-01 00:00:00
0x820df020 smss.exe 376 4 3 19 2010-10-29 17:08:53
0x821a2da0 csrss.exe 600 376 11 342 2010-10-29 17:08:54
[snip]
<span style="color: red; font-weight: bold;">0x820d4b28 3418651033 1148 668 1 5 2011-10-13 14:26:18 </span>
0x81c6ada0 cmd.exe 1244 1664 0 ------ 2011-10-13 14:37:07
$ <span style="font-weight: bold;">python vol.py -f zeroaccess1.vmem dlllist -p 1148</span>
Volatile Systems Volatility Framework 2.1_alpha
************************************************************************
3418651033 pid: 1148
Command line : <span style="color: red; font-weight: bold;">3418651033:1720073012.exe</span>
Service Pack 3
Base Size Path
0x00400000 0x000330 <span style="color: red; font-weight: bold;">C:\WINDOWS\3418651033:1720073012.exe</span>
0x7c900000 0x0af000 C:\WINDOWS\system32\ntdll.dll
0x7c800000 0x0f6000 C:\WINDOWS\system32\kernel32.dll</span></pre>
Kernel memory says the image name is 3418651033 but user memory says its 3418651033:1720073012.exe. Either way, you can dump it with <a href="http://code.google.com/p/volatility/wiki/CommandReference#procexedump">procexedump</a>.<br />
<pre><span style="font-size: 85%;">$ <span style="font-weight: bold;">python vol.py -f zeroaccess1.vmem procexedump -p 1148 -D zeroaccess/</span>
Volatile Systems Volatility Framework 2.1_alpha
************************************************************************
Dumping 3418651033, pid: 1148 output: executable.1148.exe
$ <span style="font-weight: bold;">strings zeroaccess/executable.1148.exe</span>
!This program cannot be run in DOS mode.
Rich
.text
PPPTh
ZwCreateFile
ZwTestAlert
ntdll.dll
ExitProcess
KERNEL32.dll</span></pre>
If you recall the embedded PE strings we viewed from the extracted kernel driver, you'll recognize that this is one of them. One down, one to go. How can we locate the other one - with our only bit of knowledge being that we expect it to be somewhere in user mode memory? How about <a href="http://code.google.com/p/volatility/wiki/CommandReference#malfind">malfind</a>?<br />
<pre><span style="font-size: 85%;">$<span style="font-weight: bold;"> python vol.py -f zeroaccess1.vmem malfind -D zeroaccess/</span>
Process: services.exe Pid 668
VAD: 0x950000-0x954fff Vad PAGE_EXECUTE_READWRITE
0x00950000 4d 5a 90 00 03 00 00 00 04 00 00 00 ff ff 00 00 MZ..............
0x00950010 b8 00 00 00 00 00 00 00 40 00 00 00 00 00 00 00 ........@.......
0x00950020 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 ................
0x00950030 00 00 00 00 00 00 00 00 00 00 00 00 d0 00 00 00 ................
0x00950040 0e 1f ba 0e 00 b4 09 cd 21 b8 01 4c cd 21 54 68 ........!..L.!Th
0x00950050 69 73 20 70 72 6f 67 72 61 6d 20 63 61 6e 6e 6f is.program.canno
0x00950060 74 20 62 65 20 72 75 6e 20 69 6e 20 44 4f 53 20 t.be.run.in.DOS.
0x00950070 6d 6f 64 65 2e 0d 0d 0a 24 00 00 00 00 00 00 00 mode....$.......
Dumped to services.exe.82073020.950000.954fff.dmp
$ <span style="font-weight: bold;">strings zeroaccess/services.exe.82073020.950000.954fff.dmp</span>
!This program cannot be run in DOS mode.
Rich
.text
`.rdata
@.data
ZwCreateFile
ZwTestAlert
ntdll.dll
ExitProcess
KERNEL32.dll
1234567890123456789012345678901234567890123456789012345678901234
RtlImageDirectoryEntryToData
RtlAddressInSectionTable
RtlImageNtHeader
ZwOpenFile</span></pre>
Bingo! There's the other embedded PE that the kernel driver must inject into services.exe.<br />
<br />
<span style="font-size: 130%;"><span style="font-weight: bold;">Building a Custom ZeroAccess Volatility Plugin </span></span><br />
<br />
I'm sure many readers are wondering, how hard is it to automate the actions that we've done. Well, you're in luck...its not too difficult at all. In fact, I've written a sample plugin to assist with your understanding of the Volatility API. Let's get started. First define a class with the name of your plugin. Mine will be "ZeroAccess" and it will inherit from DriverScan (since we want to scan for DRIVER_OBJECTs) and ProcExeDump (since we want to rebuild/dump PE files).<br />
<pre><span style="font-size: 85%;">class ZeroAccess(filescan.DriverScan, procdump.ProcExeDump):
"""Dump the ZeroAccess Driver and Files"""
def __init__(self, config, *args):
# remove all of procdump's options except DUMP_DIR
procdump.ProcExeDump.__init__(self, config, *args)
config.remove_option("UNSAFE")
config.remove_option("PID")
config.remove_option("OFFSET")</span></pre>
Then we add a function to the class that can handle the rebuilding of PE files - most of which was taken from the dlldump source code.<br />
<pre><span style="font-size: 85%;"> def dump_pe(self, space, start, file_name):
"""Dump a PE file to disk"""
if not self._config.DUMP_DIR:
return
full_path = os.path.join(self._config.DUMP_DIR, file_name)
sys.stdout.write("Dumping PE: {0}\n".format(full_path))
of = open(full_path, 'wb')
try:
for chunk in self.get_image(sys.stdout, space, start):
offset, code = chunk
of.seek(offset)
of.write(code)
except ValueError:
pass
of.close()</span></pre>
Most of the heavy lifting will be done in the calculate function. I won't describe each step individually like I did in the <a href="http://mnin.blogspot.com/2011/09/abstract-memory-analysis-zeus.html">Abstract Memory Analysis: Zeus Encryption Keys</a> post, because its already pretty well commented and we described all the steps above.<br />
<pre><span style="font-size: 85%;"> def calculate(self):
space = utils.load_as(self._config)
# enumerate system threads (0x00000010 = PS_CROSS_THREAD_FLAGS_SYSTEM)
system_threads = [t for t in modscan.ThrdScan(self._config).calculate() if t.CrossThreadFlags & 0x00000010]
# find and dump the malicious kernel driver
for item in filescan.DriverScan(self._config).calculate():
# unpack the parameters
(object, driver, extension, object_name) = item
# looking for unnamed driver objects
if driver.DriverName.Length != 0:
continue
# the first and only device should be ACPI#PNP[...]
device = obj.Object("_DEVICE_OBJECT",
offset = driver.DeviceObject, vm = space)
# get the device's object header
object = obj.Object("_OBJECT_HEADER", \
offset = device.obj_offset - \
device.obj_vm.profile.get_obj_offset("_OBJECT_HEADER", "Body"), \
vm = space)
object.kas = space
device_name = object.get_object_name()
# did we find zeroaccess?
if not str(device_name).startswith("ACPI#PNP"):
continue
sys.stdout.write("DriverObject: {0:#x}\n".format(device.DriverObject))
sys.stdout.write(" DriverStart: {0:#x}\n".format(driver.DriverStart))
sys.stdout.write(" DriverSize: {0:#x}\n".format(driver.DriverSize))
sys.stdout.write("DeviceObject: {0:#x} {1}\n".format(device.obj_offset, device_name))
# dump the driver
file_name = "Driver.{0:#x}.sys".format(driver.DriverStart)
self.dump_pe(space, driver.DriverStart, file_name)
# now what we know the memory range, look for bad threads
for thread in system_threads:
if thread.StartAddress > driver.DriverStart and \
thread.StartAddress < driver.DriverStart + driver.DriverSize:
sys.stdout.write("Bad Thread: {0:#x} Tid {1}\n".format(\
thread.obj_offset,
thread.Cid.UniqueThread))
# now find and dump the fake usermode ADS process
for proc in tasks.pslist(space):
for dll in proc.Peb.Ldr.InLoadOrderModuleList.list_of_type(\
"_LDR_DATA_TABLE_ENTRY", "InLoadOrderLinks"):
# look for the ADS name
if str(dll.BaseDllName).find(":") != -1:
sys.stdout.write("Fake ADS EXE: {0} pid {1} base {2:#x}\n".format(\
proc.ImageFileName,
proc.UniqueProcessId,
dll.DllBase))
file_name = "Dll.{0:#x}.{1:#x}.dll".format(proc.obj_offset, dll.DllBase)
self.dump_pe(proc.get_process_address_space(), dll.DllBase, file_name)</span></pre>
<span style="font-size: 130%;"><span style="font-weight: bold;">Testing the ZeroAccess Volatility Plugin </span></span><br />
<br />
Here is some example output from our new plugin:<br />
<pre><span style="font-size: 85%;">$ <span style="font-weight: bold;">python vol.py -f zeroaccess1.vmem zeroaccess -D zeroaccess/</span>
Volatile Systems Volatility Framework 2.1_alpha
DriverObject: 0x820e3880
DriverStart: 0xb20ae000
DriverSize: 0x1f000
DeviceObject: 0x81f3ee48 ACPI#PNP0303#2&da1a3ff&0
Dumping PE: zeroaccess/Driver.0xb20ae000.sys
Bad Thread: 0x1e6b4a0 Tid 908
Fake ADS EXE: 3418651033 pid 1148 base 0x400000
Dumping PE: zeroaccess/Dll.0x820d4b28.0x400000.dll
$ <span style="font-weight: bold;">ls zeroaccess/</span>
Dll.0x820d4b28.0x400000.dll Driver.0xb20ae000.sys</span></pre>
That's it folks! In just a small Python script, we identified the malicious DRIVER_OBJECT, the malicious DEVICE_OBJECT, the Fake Usermode ADS, the "stealth" ETHREAD, and extracted a few of the PE files. Now grab IDA Pro and enjoy reversing the unpacked binaries.<br />
<br />
<span style="font-size: 130%; font-weight: bold;">The Second Sample: 505b071b3eead7ded32a766c98efb6ef</span><br />
<br />
Realizing that there are thousands of ZeroAccess variants floating around, I wanted to try and duplicate the findings on at least one other sample. Here's the output of our new plugin on the next sample we tried:<br />
<pre><span style="font-size: 85%;">$ <span style="font-weight: bold;">python vol.py -f zeroaccess2.vmem zeroaccess -D zeroaccess/</span>
Volatile Systems Volatility Framework 2.1_alpha
DriverObject: 0x81f523f0
DriverStart: 0xb2158000
DriverSize: 0xd000
DeviceObject: 0x81fc2370 ACPI#PNP0303#2&da1a3ff&0
Dumping PE: zeroaccess/Driver.0xb2158000.sys</span></pre>
As you can see, a few of the artifacts were found and extracted, but not all of them. It turns out this sample is quite different than the first. For one, it doesn't use the Fake Usermode ADS. Instead, you can spot the malicious process because its mapped from a suspicious namespace:<br />
<pre><span style="font-size: 85%;">$ <span style="font-weight: bold;">python vol.py -f zeroaccess2.vmem dlllist -p 1136</span>
************************************************************************
svchost.exe pid: 1136
Command line : "<span style="color: red; font-weight: bold;">\\.\globalroot\Device\svchost.exe\svchost.exe</span>"
Service Pack 3
Base Size Path
0x00400000 0x0002d0 <span style="color: red; font-weight: bold;">\\.\globalroot\Device\svchost.exe\svchost.exe</span>
0x7c900000 0x0af000 C:\WINDOWS\system32\ntdll.dll
0x7c800000 0x0f6000 C:\WINDOWS\system32\kernel32.dll</span></pre>
What is \\.\globalroot\Device\svchost.exe? Surely that device doesn't exist on a clean system. Let's check with devicetree again and see if anything looks different than the first ZeroAccess sample:<br />
<pre><span style="font-size: 85%;">$ <span style="font-weight: bold;">python vol.py -f zeroaccess2.vmem devicetree</span>
<span style="color: red; font-weight: bold;">DRV 0x01e109b8 '\\Driver\\03621276'
---| DEV 0x820ec030 svchost.exe FILE_DEVICE_DISK</span><span style="color: red; font-weight: bold;"></span>
DRV 0x01df6718 '\\Driver\\kmixer'
---| DEV 0x825347d0 (unnamed) FILE_DEVICE_KS
<span style="color: red; font-weight: bold;">DRV 0x0214f4c8 '\\Driver\\03621275'
---| DEV 0x81fe8030 (unnamed) FILE_DEVICE_ACPI
DRV 0x021523f0
---| DEV 0x81fc2370 ACPI#PNP0303#2&da1a3ff&0 FILE_DEVICE_UNKNOWN</span><span style="color: red; font-weight: bold;"></span></span></pre>
I've highlighted almost all of the output in red, because...well, almost all if it is malicious. This variant of ZeroAccess creates 3 DRIVER_OBJECTs and 3 DEVICE_OBJECTs. The patterns can be expressed as the following:<br />
<br />
1) a DRIVER_OBJECT with all numbers in the name (03621276) with a DEVICE_OBJECT named svchost.exe and type FILE_DEVICE_DISK<br />
<br />
2) a DRIVER_OBJECT with all numbers in the name (03621275) with an unnamed DEVICE_OBJECT and type FILE_DEVICE_ACPI<br />
<br />
3) an unnamed DRIVER_OBJECT with DEVICE_OBJECT named ACPI#PNP[...] (this is the one we already explored)<br />
<br />
Modifying our new plugin to handle these additional cases is trivial, thus I'll leave it as an exercise to the reader. However, the one thing you may run into is that the DriverStart and DriverSize for the first two DRIVER_OBJECTs has been zeroed out:<br />
<pre><span style="font-size: 85%;">$ <span style="font-weight: bold;">python vol.py -f zeroaccess2.vmem volshell</span>
Volatile Systems Volatility Framework 2.1_alpha
Current context: process System, pid=4, ppid=0 DTB=0x319000
To get help, type 'hh()'
In [1]: <span style="font-weight: bold;">dt("_DEVICE_OBJECT", 0x820ec030)</span>
[CType _DEVICE_OBJECT] @ 0x820EC030
0x0 : Type 3
0x2 : Size 184
0x4 : ReferenceCount 2
0x8 : DriverObject 2176911800
In [2]: <span style="font-weight: bold;">dt("_DRIVER_OBJECT", 2176911800)</span>
[CType _DRIVER_OBJECT] @ 0x81C109B8
0x0 : Type 4
0x2 : Size 168
0x4 : DeviceObject 2182004784
0x8 : Flags 4
<span style="color: red; font-weight: bold;">0xc : DriverStart 0</span>
<span style="color: red; font-weight: bold;">0x10 : DriverSize 0</span>
0x14 : DriverSection 0
0x18 : DriverExtension 2176911968
0x1c : DriverName \Driver\03621276
0x24 : HardwareDatabase 0
0x28 : FastIoDispatch 0
<span style="color: red; font-weight: bold;">0x2c : DriverInit 2176398992</span>
In [3]: <span style="font-weight: bold;">hex(2176398992)</span>
Out[3]: '0x81b93690'</span></pre>
So although the DriverStart and DriverSize members are zero, making it difficult to dump the driver's code, we can still get a hint of where the code exists because the DriverInit value is not zero. We're looking around kernel addresses 0x81b93690. Cross reference that with orphan threads:<br />
<pre><span style="font-size: 85%;">$ <span style="font-weight: bold;">python vol.py -f zeroaccess2.vmem threads -F OrphanThread</span>
Volatile Systems Volatility Framework 2.1_alpha
------
ETHREAD: 0x81fa4bc8 Pid: 4 Tid: 416
Tags: OrphanThread,SystemThread
Created: 2011-10-13 04:29:10
Exited: -
Owning Process: 0x823c8830 'System'
Attached Process: 0x823c8830 'System'
State: Waiting:DelayExecution
BasePriority: 0x8
Priority: 0x8
TEB: 0x00000000
<span style="color: red; font-weight: bold;">StartAddress: 0x81b9a505</span>
ServiceTable: 0x80552fa0
[0] 0x80501b8c
[1] -
[2] -
[3] -
Win32Thread: 0x00000000
CrossThreadFlags: PS_CROSS_THREAD_FLAGS_SYSTEM
81b9a505: 58 POP EAX
81b9a506: 870424 XCHG [ESP], EAX
81b9a509: ffd0 CALL EAX
81b9a50b: 8b0d8cf7b981 MOV ECX, [0x81b9f78c]
81b9a511: ff25a4cdb981 JMP DWORD [0x81b9cda4]
81b9a517: 64a118000000 MOV EAX, [FS:0x18]</span></pre>
The last thing I wanted to point out is the callbacks output. This version of ZeroAccess not only installs the IoRegisterShutdownNotification, but also a CmRegisterCallback - for monitoring or preventing access to certain registry keys.<br />
<pre><span style="font-size: 85%;">$ <span style="font-weight: bold;">python vol.py -f zeroaccess2.vmem callbacks</span>
Volatile Systems Volatility Framework 2.1_alpha
Type Callback Owner
PsSetCreateProcessNotifyRoutine 0xf87ad194 vmci.sys
KeBugCheckCallbackListHead 0xf83e65ef NDIS.sys (Ndis miniport)
KeBugCheckCallbackListHead 0x806d77cc hal.dll (ACPI 1.0 - APIC platform UP)
KeRegisterBugCheckReasonCallback 0xf8b7aab8 mssmbios.sys (SMBiosData)
KeRegisterBugCheckReasonCallback 0xf8b7aa70 mssmbios.sys (SMBiosRegistry)
<span style="color: red; font-weight: bold;">IoRegisterShutdownNotification 0x81b934e0 UNKNOWN (\Driver\03621276)</span>
[snip]
IoRegisterShutdownNotification 0xf8bb05be Fs_Rec.SYS (\FileSystem\Fs_Rec)
IoRegisterShutdownNotification 0xf853c2be ftdisk.sys (\Driver\Ftdisk)
IoRegisterShutdownNotification 0x805cdef4 ntoskrnl.exe (\FileSystem\RAW)
IoRegisterShutdownNotification 0xf83d98f1 Mup.sys (\FileSystem\Mup)
IoRegisterShutdownNotification 0x805f5d66 ntoskrnl.exe (\Driver\WMIxWDM)
<span style="color: red; font-weight: bold;">CmRegisterCallback 0x81b92d60 UNKNOWN (--)</span></span></pre>
<span style="font-size: 130%; font-weight: bold;">ZeroAccess Rogue Kernel Timers</span><br />
<br />
In early January 2011, when Frank Boldewin and I were working on finding artifacts of Rustock.B and Rustuck.C in memory, he suggested that a plugin for analyzing kernel timers be added to Volatility. I drafted up a copy and then forgot about it until he reminded me this week, and guess what - just in time to be useful. I will go into depth on kernel timers next Volatility Friday, but for now you can see yet another strong factor in memory that indicates something suspicious is going on.<br />
<pre><span style="font-size: 85%;">$ <span style="font-weight: bold;">python vol.py -f zeroaccess2.vmem timers</span>
Volatile Systems Volatility Framework 2.1_alpha
Offset DueTime Period(ms) Signaled Routine Module
0x805598e0 0x00000084:0xce8b961c 1000 Yes 0x80523dee ntoskrnl.exe
0x820a1e08 0x00000084:0xdf3c0c1c 30000 Yes 0xb2d2a385 afd.sys
0x81ebf0b8 0x00000084:0xce951f84 0 - 0xf89c23f0 TDI.SYS
0x8055b200 0x00000086:0x1c631c38 0 - 0x80534a2a ntoskrnl.exe
0xf842f270 0x00000084:0xd0fea092 0 - 0xf84111b4 Ntfs.sys
0xb27f3990 0x00000084:0xd36a83fa 0 - 0xb27e4385 srv.sys
0x805516d0 0x00000084:0xda9d7dbc 60000 Yes 0x804f3eae ntoskrnl.exe
0x80550ce0 0x00000084:0xd11d9f24 0 - 0x8053b8fc ntoskrnl.exe
0x80551800 0x00000084:0xcebda77e 1000 Yes 0x804f3716 ntoskrnl.exe
0x82255720 0x80000084:0xb14adbda 0 - 0x80534e48 ntoskrnl.exe
[snip]
0x81dbeb78 0x00000131:0x2e896402 0 - 0xf83faf6f NDIS.sys
0x81e8b4f0 0x00000131:0x2e896402 0 - 0xf83faf6f NDIS.sys
0x81eb8e28 0x00000084:0xe5855f6a 0 - 0x80534e48 ntoskrnl.exe
<span style="color: red; font-weight: bold;">0xb20bbbb0 0x00000084:0xd4de72d2 60000 Yes 0xb20b5990 UNKNOWN</span>
0x8210d910 0x80000000:0x0a7efa36 0 - 0x80534e48 ntoskrnl.exe
0x82274190 0x80000000:0x711befba 0 - 0x80534e48 ntoskrnl.exe
0x81de9690 0x80000000:0x0d0c3e8a 0 - 0x80534e48 ntoskrnl.exe</span></pre>
<span style="font-size: 130%; font-weight: bold;">Conclusion and Source Code</span><br />
<br />
Thanks again to Frank, Guiseppe, and Marco for sharing the results of their analysis and ultimately making this blog post possible (without doing my own RE).<br />
<br />
Download the ZeroAccess Volatility Plugin <a href="http://code.google.com/p/malwarecookbook/source/browse/trunk/zeroaccess/zeroaccess.py">here</a>. Play with it, learn from it, enoy it!Michael Hale Lighhttp://www.blogger.com/profile/17377327006242921434noreply@blogger.com0tag:blogger.com,1999:blog-3630199973361886660.post-50075718584546283092011-09-25T21:39:00.059-06:002012-08-05T21:06:34.344-06:00Abstract Memory Analysis: Zeus Encryption Keys<span style="font-weight: bold;">Community Momentum is Rising!</span><br />
<br />
The amount of research pouring out of the <a href="http://code.google.com/p/volatility">Volatility</a> community recently has been very exciting. Over the past few weeks, we've seen Russ McRee of <span class="st"><a href="http://twitter.com/#%21/holisticinfosec">HolisticInfoSec.org / toolsmith</a> write about <a href="http://holisticinfosec.blogspot.com/2011/09/toolsmith-memory-analysis-with-dumpit.html">Memory Analysis with DumpIt and Volatility</a>. <a href="http://www.reconstructer.org/">Frank Boldewin</a> published a CSI:Internet article titled <a href="http://www.h-online.com/security/features/CSI-Internet-A-trip-into-RAM-1339479.html">A Trip Into RAM</a> that focused on detecting Spyeye. <a href="http://twitter.com/#%21/bradarndt">@bradarndt</a> wrote a lengthy <a href="http://malwarereversing.wordpress.com/2011/09/23/zeus-analysis-in-volatility-2-0/">Zeus Analysis in Volatility 2.0</a> just days after releasing a new plugin called <a href="http://malwarereversing.wordpress.com/2011/09/17/volatility-2-0-plugin-vscan/">Vscan</a> that automatically submits files extracted from memory to online virus scanners. evild3ad also <a href="http://www.evild3ad.com/?p=956">wrote a piece on Zeus</a> just days after providing a nice installation tutorial for <a href="http://www.evild3ad.com/?p=907">Volatility 2.0 on Ubuntu</a>.<br /><br />Last week, Evilcry (<a href="http://twitter.com/#%21/Blackmond_">@Blackmond_</a>) updated his <a href="http://quequero.org/Carberp_Reverse_Engineering#Carberp_Analysis_via_Volatility">Carberp Reverse Engineering</a> post to show some of the many ways to detect Carberp in memory...my favorite being the detection of NT syscall hooks. Several of our primary developers have launched the <a href="http://code.google.com/p/volatility/source/browse/#svn%2Fbranches%2Fwin64-support">64-bit branch of Volatility</a> in preparation for the 2.1 release. <a href="http://twitter.com/#%21/gleeda">@gleeda </a>just published her <a href="http://gleeda.blogspot.com/2011/09/volatility-20-timeliner-registryapi.html">Timeliner, Registry API, Event log plugins</a> and <a href="http://jls-scripts.googlecode.com/files/Timeliner%20Release%20Documentation.pdf">corresponding documentation</a> (also makes a great tutorial on writing your own Volatility plugins).<br /><br />To keep the momentum going, I'll discuss one of the more abstract ways that you can leverage Volatility. </span><span class="st">We'll take a look at how to locate and extract Zeus's RC4 encryption keys, then use the keys to decrypt other configuration data found in memory. </span><span class="st">The plugins we'll discuss were written well over a year ago and kept private due to sensitivity of the key recovery methods. It wasn't exactly a secret previously (<a href="http://blog.threatexpert.com/2010/05/config-decryptor-for-zeus-20.html">ThreatExpert</a> disclosed some juicy details back in May) but it also wasn't common sense knowledge. Earlier today, TrustDefender announced their finding of <a href="http://www.trustdefender.com/zeus-trojan-update-new-variants-based-on-leaked-zeus-source-code.html">Zeus Trojan Update - new variants based on leaked zeus source code</a>. The new versions reportedly use AES instead of RC4 and <span style="font-style: italic;">intentionally try to clear memory of the encryption keys</span>. That means for certain we're not disclosing anything the attackers don't already know.<br /><br /><span style="font-weight: bold;">Zeus Versions</span><br /><br />The earliest variants of Zeus (circa 2006) encrypted configurations using a very simple algorithm that I described in the original report called <a href="http://mnin.org/write/ZeusMalware.pdf">[Prg] Malware Case Study</a>. We won't discuss these versions anymore - they don't use encryption keys so there's nothing fun to try and recover.<br /><br />Near the end of 2008 (I'm going to say at approximately version 1.2.0), Zeus started using unique 256-byte RC4 keys embedded in each binary to decrypt configurations. It prevented analysts from using the key from one sample for decrypting the configuration used by another sample. I designed an unpacker-like tool that ran on live VMs and could extract the key without infecting the system (thus you could loop through hundreds of samples without reverting). Then you could decrypt configurations in a brute-force like manner, by cycling through all of the extracted keys until one "unlocked" it.<br /><br />The sample I'll be using that represents all Zeus versions after 1.2.0 but before 2.x is MD5 </span><a href="http://www.virustotal.com/file-scan/report.html?id=c60a3d4910871bf0f0970bd93947bf26df25d9ac5954f14569ccd3972223a5b3-1235140255">b5709cd23d8ad91d79062ad63e8516ed</a>.<br />
<span class="st"><br />The present day Zeus variants (2.x) still use RC4 encryption, but many also have a hardware-locking feature so that a sample recovered from one machine won't run on another machine (such as a sandbox or analysis system). These variants hide data in randomly generated registry keys and directories on the file system. They also use a separate 256-byte RC4 key for the configuration and for the stolen data files.<br /><br />The sample I'll be using that represents Zeus versions 2.x is MD5 </span><a href="http://www.virustotal.com/file-scan/report.html?id=f56099b52d718608b82660a1644b002494426111010410d39691d0e4fc27c942-1317322040">b93fb47257f052f6bc99f0b96b718cd4</a>.<span class="st"><br /><br /><span style="font-weight: bold;">Recovering keys for Zeus versions > 1.20 and < 2.0 </span><br /><br />These variants of Zeus define a data structure with the 256-byte RC4 key at offset 0x2A. The challenge is finding those exact 256 bytes in a memory dump that is potentially several gigabytes large. Talk about needle in a haystack, right? One of the more obvious solutions is look for patterns among the other structure members and develop a scanner with constraints. For example, if the member at offset 0 was always 0x12345678 and member at offset 4 was always between 0x30 and 0x45, then you have some criteria to start searching. However, that's not the road I took.<br /><br />While reversing some samples, I noticed a pointer to the base of the structure can be found at one of the most unexpected locations. As shown in the image below, after the Zeus "body" is injected into a process and fully unpacks itself, the pointer is in the Import Address Table (IAT) directly after the ws2_32!closesocket entry.<br /></span><a href="https://blogger.googleusercontent.com/img/b/R29vZ2xl/AVvXsEgZU2PlW1UwrL6RhvCYrfnajmiTc2m64e5bddeAVhuRHjYqlmhkl3m8hfPEyhr4k3B4r6b8CfpkCNMuwr18biOFUaeAAx5LQbsRfWejDJzGdPg-dLPZBBuxGv5DPG9JlbNmPNq6gxF0P2kH/s1600/exhibit3-3.png"><img alt="" border="0" id="BLOGGER_PHOTO_ID_5657633280410801138" src="https://blogger.googleusercontent.com/img/b/R29vZ2xl/AVvXsEgZU2PlW1UwrL6RhvCYrfnajmiTc2m64e5bddeAVhuRHjYqlmhkl3m8hfPEyhr4k3B4r6b8CfpkCNMuwr18biOFUaeAAx5LQbsRfWejDJzGdPg-dLPZBBuxGv5DPG9JlbNmPNq6gxF0P2kH/s320/exhibit3-3.png" style="cursor: pointer; display: block; height: 74px; margin: 0px auto 10px; text-align: center; width: 320px;" /></a><span class="st">Whether this was done on purpose by the Zeus authors or accidentally is beyond me. I don't know how things like this happen by accident, nor do I know any reasons to do intentionally. However, since hundreds of thousands of samples were created using the same Zeus builder, they all share the same secret. </span><br />
<br />
Now that we know what we're looking for, let's discuss how to find it. Here is a brief description of the steps:<br />
<br />
<span style="font-weight: bold;">1. Find Zeus</span>. We'll cycle through the active process list. For each process, we'll traverse the VAD tree. For every memory segment, we'll check if there is injected code (i.e. a private, virtually-allocated region with VadS tag and no file mapping). This is all rather simple, since its exactly how <a href="http://code.google.com/p/volatility/wiki/CommandReference#malfind">malfind</a> has located Zeus infections for years.<br />
<br />
<span style="font-weight: bold;">2. Find closesocket in the IAT.</span> This step sounds straight-forward, but its not. Due to Zeus' packing and obfuscation, the names of imported functions are not always available. Thus, we can't parse the IAT looking for "closesocket" as normal PE header tools do. Instead, we leverage Volatility's <a href="http://code.google.com/p/volatility/wiki/CommandReference#impscan">ImpScan</a> plugin, which scans for calls to imported functions using a "reverse lookup" kind of algorithm (described fully in <a href="http://www.amazon.com/dp/0470613033?tag=malwacookb-20&camp=14573&creative=327641&linkCode=as1&creativeASIN=0470613033&adid=0TYYEKYNCMHH9X61WQWH&">Malware Analyst's Cookbook</a> Recipe 16-8: Scanning for Imported Functions with Impscan).<br />
<br />
<span style="font-weight: bold;">3. Find the structure pointer</span>. As previously described, the pointer is the next 4 bytes after the closesocket entry. So we dereference those 4 bytes as a pointer, add 0x2A to reach the RC4 key structure member, and read 256-bytes.<br />
<br />
<span style="font-weight: bold;">4. Write the plugin</span>. Now we know what we need to do. Let's do it! We'll need to import volatility.obj for access to the Object class, volatility.win32.tasks for access to process enumeration, volatility.utils for access to the Hexdump function, and volatility.plugins.malware for the ability to inherit from the ImpScan plugin.<br />
<pre><span style="font-size: 85%;">import volatility.obj as obj
import volatility.utils as utils
import volatility.win32.tasks as tasks
import volatility.plugins.malware as malware</span></pre>
Now we define a class that inherits from malware.ImpScan. The name of our class (ZeusScan1) will automatically become the name of the command that you type, for example "python vol.py zeusscan1"<br />
<pre><span style="font-size: 85%;">class ZeusScan1(malware.ImpScan):
"Scan for and dump Zeus RC4 keys"
def __init__(self, config, *args):
malware.ImpScan.__init__(self, config, *args)</span></pre>
A majority of the work happens in the calculate function. As described above, we begin by iterating through active processes. For each process, we acquire an address space (an object referring to the process's private virtual memory) and also enumerate the loaded DLLs which we'll need to locate ws2_32.dll.<br />
<pre><span style="font-size: 85%;"> def calculate(self):
addr_space = malware.get_malware_space(self._config)
RC4_KEYSIZE = 0x102
# cycle through the active processes
for p in self.filter_tasks(tasks.pslist(addr_space)):
# get the process address space
ps_ad = p.get_process_address_space()
if ps_ad == None:
continue
# enumerate DLLs (inherited from DllList)
mods = self.list_modules(p</span></pre>
Next we traverse the VAD segments and filter by private allocations with no file mapping and 'MZ' at the base. Any segments that satisfy this criteria are almost certainly injected Zeus binaries.<br />
<pre><span style="font-size: 85%;"> # traverse the VAD
for vad in p.VadRoot.traverse():
if vad == None:
continue
# only looking for short VADs (non-memory mapped)
if (vad.Tag != "VadS"):
continue
# only looking for private, virtually-alocated memory
if vad.u.VadFlags.PrivateMemory == 0:
continue
# find the start and end range
start = vad.get_start()
end = vad.get_end()
data = vad.get_data()
# check for PE headers at the base
if data[0:2] != 'MZ':
continue</span></pre>
Now comes Step 2. We need to find where closesocket is located in process memory. This is done by first locating ws2_32.dll and then calling getprocaddress() - an extension to the module that parses its EAT and returns the requested function's virtual address.<br />
<pre><span style="font-size: 85%;"> # locate the winsock2 module
winsock = malware.find_module_by_name(mods, "ws2_32.dll")
if winsock == None:
continue
# resolve the address of closesocket export
closesocket = winsock.getprocaddress("closesocket")
if closesocket == None:
continue</span></pre>
The next thing we do is use call_scan which is inherited from malware.ImpScan. It is a generator that yields tuples in the following order: address of the CALL instruction, constant (IAT entry address), and call destination (the API function address). To clear up any confusion around these values, let's go over a quick example. Say you have the following code in a disassembly ".text:00120408 CALL DWORD PTR:[0010022c] ; kernel32.CreateFileW".<br />
<br />
In the example, 00120408 is the address of the CALL instruction. 0010022c is the constant. If you dereference the constant, you'll find a DWORD sized value that points to kernel32.CreateFileW. So what we're doing is scanning for CALLs that lead to ws2_32!closesocket. We're taking the constant, adding 4 bytes, and then using the DWORD at that location as a pointer to the structure that contains the RC4 key. Without further ado, here's the rest of the code:<br />
<pre><span style="font-size: 85%;"> # scan for calls to imported functions (inherited from ImpScan)
calls = list(self.call_scan(ps_ad, data, start))
for (addr_of_call, const, call_dest) in calls:
if call_dest != closesocket:
continue
# read the DWORD directly after closesocket
struct_base = obj.Object('Pointer', offset = const + 4, vm = ps_ad)
# to be valid, it must point within the vad segment
if (struct_base < start) or (struct_base > (start + end)):
continue
# grab the key data
key = ps_ad.read(struct_base + 0x2a, RC4_KEYSIZE)
# greg's sanity check
if len(key) != RC4_KEYSIZE or key[-2:] != "\x00\x00":
continue
yield p, struct_base, key</span></pre>
We yield 3 values from the calculate function. These 3 values are automatically passed to render_text if you're using text-mode output. Thus we also must define a render_text method in our plugin.<br />
<pre><span style="font-size: 85%;"> def render_text(self, outfd, data):
for p, struct_base, key in data:
hex = "\n".join(["{0:#010x} {1:<48} {2}".format(struct_base + 0x2a + o, h, ''.join(c)) for o, h, c in utils.Hexdump(key)])
outfd.write("Process: {0} {1}\n".format(p.UniqueProcessId, p.ImageFileName))
outfd.write(hex)
outfd.write("\n")</span></pre>
<span style="font-weight: bold;">5. Test the plugin.</span> When you run zeusscan1 against a memory dump infected with one of the these Zeus samples, you'll see output like this:<br />
<pre><span style="font-size: 85%;">$ <span style="font-weight: bold;">python vol.py -f XPSP3-0e4e1fd4.vmem zeusscan1</span>
Volatile Systems Volatility Framework 2.1_alpha
Process: 624 winlogon.exe
0x00ac602a 76 e6 ce 65 3e d9 5e 0c 0a 8f 14 81 f6 dc ee 2f v..e>.^......../
0x00ac603a bd 1a 10 0d 98 63 61 34 9d 8e 75 1c b6 b8 b7 56 .....ca4..u....V
0x00ac604a 4a bb d1 99 37 a2 40 4f e0 77 80 52 3f db c4 73 J...7.@O.w.R?..s
0x00ac605a 69 21 96 eb 0b 28 7f 90 d2 e5 46 d0 39 2a 51 43 i!...(....F.9*QC
0x00ac606a ca 1e a0 62 8c fe c8 15 78 8b 9b d4 2d a4 da ef ...b....x...-...
0x00ac607a 47 66 b1 ec 93 c1 87 e3 a9 b9 4c 9f 6a 86 20 d3 Gf........L.j...
0x00ac608a a5 8d df 72 3b 44 e1 cb 85 92 04 74 f2 84 33 a6 ...r;D.....t..3.
0x00ac609a f3 ae 2b c5 94 f5 7c 50 c9 1b de 83 ad cc 68 60 ..+...|P......h`
0x00ac60aa c2 6e 09 c7 a7 16 fa d6 9e bf b2 ab 32 ed 3c 36 .n..........2.<6
0x00ac60ba 2e b3 91 0e 05 08 af f1 c6 49 82 95 dd ac 5f 3d .........I...._=
0x00ac60ca 29 e8 a8 bc 88 9c 24 c3 17 79 6c f9 fc 1d b4 19 ).....$..yl.....
0x00ac60da b5 f0 89 ff c0 03 d8 48 57 d5 e2 67 35 7b f4 a1 .......HW..g5{..
0x00ac60ea 3a 30 02 be 42 cd e4 31 fb 7d 4d 4b 7a 26 5a 45 :0..B..1.}MKz&ZE
0x00ac60fa 38 64 55 13 54 ba 00 8a f8 07 ea 27 71 e9 53 cf 8dU.T......'q.S.
0x00ac610a f7 70 23 58 06 01 5d 6d e7 4e 5b 22 12 6f 97 aa .p#X..]m.N[".o..
0x00ac611a 59 11 5c d7 25 41 18 7e 2c fd b0 a3 0f 6b 9a 1f Y.\.%A.~,....k..
0x00ac612a 00 00 ..
Process: 668 services.exe
0x0075602a 76 e6 ce 65 3e d9 5e 0c 0a 8f 14 81 f6 dc ee 2f v..e>.^......../
0x0075603a bd 1a 10 0d 98 63 61 34 9d 8e 75 1c b6 b8 b7 56 .....ca4..u....V
0x0075604a 4a bb d1 99 37 a2 40 4f e0 77 80 52 3f db c4 73 J...7.@O.w.R?..s
0x0075605a 69 21 96 eb 0b 28 7f 90 d2 e5 46 d0 39 2a 51 43 i!...(....F.9*QC
0x0075606a ca 1e a0 62 8c fe c8 15 78 8b 9b d4 2d a4 da ef ...b....x...-...
0x0075607a 47 66 b1 ec 93 c1 87 e3 a9 b9 4c 9f 6a 86 20 d3 Gf........L.j...
0x0075608a a5 8d df 72 3b 44 e1 cb 85 92 04 74 f2 84 33 a6 ...r;D.....t..3.
0x0075609a f3 ae 2b c5 94 f5 7c 50 c9 1b de 83 ad cc 68 60 ..+...|P......h`
0x007560aa c2 6e 09 c7 a7 16 fa d6 9e bf b2 ab 32 ed 3c 36 .n..........2.<6
0x007560ba 2e b3 91 0e 05 08 af f1 c6 49 82 95 dd ac 5f 3d .........I...._=
0x007560ca 29 e8 a8 bc 88 9c 24 c3 17 79 6c f9 fc 1d b4 19 ).....$..yl.....
0x007560da b5 f0 89 ff c0 03 d8 48 57 d5 e2 67 35 7b f4 a1 .......HW..g5{..
0x007560ea 3a 30 02 be 42 cd e4 31 fb 7d 4d 4b 7a 26 5a 45 :0..B..1.}MKz&ZE
0x007560fa 38 64 55 13 54 ba 00 8a f8 07 ea 27 71 e9 53 cf 8dU.T......'q.S.
0x0075610a f7 70 23 58 06 01 5d 6d e7 4e 5b 22 12 6f 97 aa .p#X..]m.N[".o..
0x0075611a 59 11 5c d7 25 41 18 7e 2c fd b0 a3 0f 6b 9a 1f Y.\.%A.~,....k..
0x0075612a 00 00 ..</span></pre>
And there you have it. The plugin prints a hexdump of the 256-byte RC4 key unique to the Zeus variant that has infected the machine. Since its the same version of Zeus injected into winlogon.exe and services.exe, the keys you see are going to match.<br />
<br />
<span class="st"><span style="font-weight: bold;">Recovering keys for Zeus versions >= 2.0 </span></span><br />
<br />
<span class="st">Welcome to the real fun. I'm not going to dive deep into the details of recovering RC4 keys from these versions, because Sergei </span><span class="post-author vcard"><span class="fn">Shevchenko already covered the principles in his blog <a href="http://blog.threatexpert.com/2010/05/config-decryptor-for-zeus-20.html">Config Decryptor for ZeuS 2.0</a>. Basically, we're looking for sequences of instructions that reference global variables, which can then lead us to the RC4 key, encrypted configuration data, and other information. In the following disassembly, many of the global variables that we need have been named.<br /></span></span><a href="https://blogger.googleusercontent.com/img/b/R29vZ2xl/AVvXsEhryrUN8VQT78mSiEYndK0TZT4qcHY35oNbjYdhAHzw6DsdKkBAJfiwUGkRSRylVu6hVQ3iddkcGGoakxlsgZN8J9q4dJjKuJPZJXwY1sVGlx176qeROXzRS-UK9VhLhfKhPm8NL0kDsaW3/s1600/Gen.png"><img alt="" border="0" id="BLOGGER_PHOTO_ID_5657871399984177874" src="https://blogger.googleusercontent.com/img/b/R29vZ2xl/AVvXsEhryrUN8VQT78mSiEYndK0TZT4qcHY35oNbjYdhAHzw6DsdKkBAJfiwUGkRSRylVu6hVQ3iddkcGGoakxlsgZN8J9q4dJjKuJPZJXwY1sVGlx176qeROXzRS-UK9VhLhfKhPm8NL0kDsaW3/s320/Gen.png" style="cursor: pointer; display: block; height: 262px; margin: 0px auto 10px; text-align: center; width: 320px;" /></a><br />
The function named "signature_function" can be expressed using wildcards like this:<br />
<pre><span style="font-size: 85%;">PUSH 102h
LEA EAX, [ESP+????????]
PUSH EAX
LEA EAX, [ESP+??]
PUSH EAX
CALL ???????? ; custom_memcpy
MOV EAX, 1E6h
PUSH EAX
PUSH OFFSET ???????? ; real_rc4_key</span></pre>
There may be variations due to compiler differences, so we also should look for this:<br />
<pre><span style="font-size: 85%;">PUSH 102h
LEA EAX, [EBP-????????]
PUSH EAX
LEA EAX, [EBP-????????]
PUSH EAX
CALL ???????? ; custom_memcpy
MOV EAX, 1E6h
PUSH EAX
PUSH OFFSET ???????? ; real_rc4_key</span></pre>
As for the function named "decode_config_data", it can be expressed like this:<br />
<pre><span style="font-size: 85%;">PUSH ESI
MOV EDX, ????0000 ; config size (immediate)
PUSH EDX
PUSH OFFSET ???????? ; config_data
PUSH EAX
CALL ???????? ; custom_memcpy
MOV ESI, ???????? ; last_section_rva
MOV ECX, ???????? ; imagebase</span></pre>
There are several variations of these patterns, once again, due to compiler differences and usage of general purpose registers. But its nothing that <a href="http://code.google.com/p/yara-project/">Yara</a> rules can't handle. By converting the above instructions into opcodes, we have the following signatures:<br />
<pre><span style="font-size: 85%;">zeus_key_sigs = {
'namespace1':'rule z1 {strings: $a = {56 BA ?? ?? 00 00 52 68 ?? ?? ?? ?? 50 E8 ?? ?? ?? ?? 8B 35 ?? ?? ?? ?? 8B 0D ?? ?? ?? ??} condition: $a}',
'namespace5':'rule z5 {strings: $a = {56 BA ?? ?? 00 00 52 68 ?? ?? ?? ?? 50 E8 ?? ?? ?? ?? 8B 0D ?? ?? ?? ?? 03 0D ?? ?? ?? ??} condition: $a}',
'namespace2':'rule z2 {strings: $a = {55 8B EC 51 A1 ?? ?? ?? ?? 8B 0D ?? ?? ?? ?? 56 8D 34 01 A1 ?? ?? ?? ?? 8B 0D ?? ?? ?? ??} condition: $a}',
'namespace3':'rule z3 {strings: $a = {68 02 01 00 00 8D 84 24 ?? ?? ?? ?? 50 8D 44 24 ?? 50 E8 ?? ?? ?? ?? B8 E6 01 00 00 50 68 ?? ?? ?? ??} condition: $a}',
'namespace4':'rule z4 {strings: $a = {68 02 01 00 00 8D 85 ?? ?? ?? ?? 50 8D 85 ?? ?? ?? ?? 50 E8 ?? ?? ?? ?? B8 E6 01 00 00 50 68 ?? ?? ?? ??} condition: $a}'
}</span></pre>
For plugin testing purposes, I created a memory dump infected with <a href="http://code.google.com/p/malwarecookbook/source/browse/trunk/zeusscan/zeus2x4.vmem.zip">4 different 2.x samples</a>. But wait a minute, doesn't Zeus check for mutexes and back off if a system is already infected? Well, yes, it does...but I paused each sample in a debugger after it unpacked and before it could exit (that's easier than creating 4 separate memory dumps).<br />
<br />
Let's give her a whirl! You should see the name of the process housing the injected Zeus code, along with the URL that Zeus contacts for an update, the local system's unique identifier (computer name plus some random characters), the XOR keys, the randomly generated registry keys and value names that Zeus uses for storing data, and the randomly generated file paths and file names for Zeus executables and stolen data files. Oh, and the two RC4 keys ;-)<br />
<pre><span style="font-size: 85%;">$ </span><span style="font-size: 85%; font-weight: bold;">python vol.py -f zeus2x4.vmem zeusscan2</span><span style="font-size: 85%;">
--------------------------------------------------
Process: wuauclt.exe
Pid: 940
Address: 0xD80000
URL: http://193.43.134.14/eu2.bin
Identifier: JASONRESACC69_7875768F16073AAF
Mutant key: 0x17703072
XOR key: 0x2006B8FE
Registry: HKEY_CURRENT_USER\SOFTWARE\Microsoft\Izozo
Value 1: Kealtuuxd
Value 2: Yrdii
Value 3: Kebooqu
Executable: Obyt\ihah.exe
Data file: Ebupzu\uzugl.dat
Config RC4 Key:
0x00000000 4a ba 2c 63 eb 7c fc 45 c4 f3 b6 2d 31 29 21 2e J.,c.|.E...-1)!.
0x00000010 53 0f 3f ef 9a 2a f8 82 96 6b e1 a2 3b 5f 34 fd S.?..*...k..;_4.
0x00000020 a6 02 cc 39 0b 16 40 33 1f a1 dc af 93 9b 5b 94 ...9..@3......[.
0x00000030 68 62 84 46 ca 64 8d 43 13 d4 d9 72 00 5c 2b bc hb.F.d.C...r..+.
0x00000040 f6 d7 88 91 24 9f bd 1e 7a 07 c5 6e 1a 4e 90 92 ....$...z..n.N..
0x00000050 c1 42 0c 75 47 3a 9e 1d c2 ec 0d ed b8 71 b4 ab .B.uG:.......q..
0x00000060 e6 5d e3 14 48 b9 e9 e8 b2 10 ee f4 e2 2f a4 09 .]..H......../..
0x00000070 54 b7 95 be 50 99 8b 87 8f 37 9d fa f2 d5 b1 18 T...P....7......
0x00000080 01 db 3c cf aa 70 e5 15 9c 5a 26 27 de da d8 d6 ..<..p...Z&'....
0x00000090 59 a8 1b 30 cd 6c 78 c0 e7 c6 81 22 86 17 38 a7 Y..0.lx...."..8.
0x000000a0 df 41 ad 4d 44 11 76 a3 52 a9 b3 6d 51 05 c9 b5 .A.MD.v.R..mQ...
0x000000b0 85 49 77 c7 23 f7 3e 8a 03 69 ac 3d 4c 89 ff 58 .Iw.#.>..i.=L..X
0x000000c0 dd 57 5e 97 98 f1 65 c3 7d f0 e0 20 e4 25 7e 7b .W^...e.}.. .%~{
0x000000d0 b0 06 4b a5 c8 80 f9 f5 55 1c 7f 83 73 d1 66 fe ..K.....U...s.f.
0x000000e0 8c 28 19 4f 60 36 0a 8e ce ae fb 0e 74 35 79 56 .(.O`6......t5yV
0x000000f0 a0 08 ea bb 67 d3 d0 6a 12 6f 32 bf d2 04 cb 61 ....g..j.o2....a
0x00000100 00 00 ..
Credential RC4 Key:
0x00000000 6f e4 94 f2 f1 5e 5c c1 8c e8 66 c5 13 2a 23 39 o....^....f..*#9
0x00000010 84 36 6a 83 b2 55 6c 11 5a f3 b6 20 07 6d ba de .6j..Ul.Z.. .m..
0x00000020 52 8e 34 bf 8a 05 0f 64 35 29 cb 5f ff 00 87 fc R.4....d5)._....
0x00000030 b5 5b 67 b8 eb 1a 0e 1f 32 ae 54 3a 88 ed c3 51 .[g.....2.T:...Q
0x00000040 40 14 3e 53 dc 7c a7 0b 79 26 e5 45 99 7d 1c d0 @.>S.|..y&.E.}..
0x00000050 90 8f 80 95 71 58 41 5d f9 af 9e a1 6e ef 25 4e ....qXA]....n.%N
0x00000060 48 2d b1 bd 33 ab d3 b7 4d 10 7e 44 65 7b cd 2f H-..3...M.~De{./
0x00000070 ea 3f 2c ce 9a 9d db 31 b0 69 cf f7 e7 a6 82 a4 .?,....1.i......
0x00000080 ad a3 30 9b 76 f0 f5 ac c2 fb 8b 4f fe 8d a8 04 ..0.v......O....
0x00000090 86 a0 50 4c 4b e2 ec 60 e6 dd c6 42 cc 6b 89 57 ..PLK..`...B.k.W
0x000000a0 d1 d8 78 4a 1d d7 9f e0 7a 75 e3 7f a2 77 85 2b ..xJ....zu...w.+
0x000000b0 59 16 d6 d4 f4 93 ee 9c d2 03 be 2e 06 1b 56 70 Y.............Vp
0x000000c0 d5 73 ca f8 fd 12 37 49 98 46 0d bb 96 c9 18 b9 .s....7I.F......
0x000000d0 81 74 a9 3c 21 c4 da 38 0c 1e 27 0a c7 15 47 68 .t.ji--..8..'...G
0x000000e0 bc f6 91 fa 72 3d 01 e9 22 e1 09 c8 19 c0 aa b3 ....r=..".......
0x000000f0 b4 08 17 3b 61 92 02 63 43 62 d9 df 97 24 28 a5 ...;a..cCb...$(.
0x00000100 00 00 ..</span></pre>
I'll show a preview of the other variants installed on zeus2x4.vmem, but withhold the keys for the sake of brevity.<br />
<pre><span style="font-size: 85%;">--------------------------------------------------
Process: nifek_locked.ex
Pid: 2204
Address: 0x400000
URL: http://zephehooqu.ru/bin/koethood.bin
Identifier: OREO_7875768FD1A71CE9
Mutant key: 0x895B26B0
XOR key: 0x739A94C5
Registry: HKEY_CURRENT_USER\SOFTWARE\Microsoft\Opiss
Value 1: Ypzoarfu
Value 2: Omviacy
Value 3: Otedhay
Executable: Pese\nifek.exe
Data file: Iqpa\ytzea.dat
--------------------------------------------------
Process: vaelh.exe
Pid: 952
Address: 0x400000
URL: http://nahwgwwergwyt.com/gamer/eqtewttetwq.img
Identifier: ZESRA037219_7875768F7BDEA03C
Mutant key: 0x90B18B41
XOR key: 0x569E6C1F
Registry: HKEY_CURRENT_USER\SOFTWARE\Microsoft\Koti
Value 1: Imwiase
Value 2: Qaofl
Value 3: Izsuuqex
Executable: Ammaax\vaelh.exe
Data file: Xuuf\otsip.dat
--------------------------------------------------
Process: anaxu.exe
Pid: 3508
Address: 0x400000
URL: http://basicasco.ru/otp/zero.doc
Identifier: PENNY_74DEB1E33B0FB384
Mutant key: 0x2CB173C4
XOR key: 0xD60F77DA
Registry: HKEY_CURRENT_USER\SOFTWARE\Microsoft\Otve
Value 1: Puyqo
Value 2: Yhahezf
Value 3: Obivq
Executable: Wuebx\anaxu.exe
Data file: Neme\wuwe.dat</span></pre>
<span style="font-weight: bold;">Conclusion </span><br />
<br />
This is just one example of taking memory analysis to the next level and I hope it reminds everyone that Volatility isn't just a tool for carving Windows data structures and finding evidence to correlate with disk, registry, and network artifacts. Volatility is a powerful, flexible tool limited only by your own creativity. Every Friday (or every day, depending on how much trouble you want to get into with your boss) we invite you to stop what you're doing and join the fun of pushing the limits of memory analysis. What do you want to do next?<br />
<br />
View the zeusscan1 source code <a href="http://code.google.com/p/malwarecookbook/source/browse/trunk/zeusscan/zeusscan1.py">here</a>.<br />
View the zeusscan2 source code <a href="http://code.google.com/p/malwarecookbook/source/browse/trunk/zeusscan/zeusscan2.py">here</a>.<br />
To use the plugins, you need <a href="http://code.google.com/p/yara-project/">Yara</a>, the <a href="http://code.google.com/p/volatility/source/checkout">2.1 alpha branch of Volatility</a>, and <a href="http://code.google.com/p/malwarecookbook/source/browse/trunk/malware.py">malware.py</a>.<br />
<br />
Until the next Volatility Friday....Michael Hale Lighhttp://www.blogger.com/profile/17377327006242921434noreply@blogger.com5tag:blogger.com,1999:blog-3630199973361886660.post-13641939607174479102011-09-20T09:31:00.006-06:002012-08-05T21:07:02.296-06:00Detecting Stealth ADS with The Sleuth Kit (TSK)Exploit Monday has an interesting article on <a href="http://www.exploit-monday.com/2011/09/stealth-alternate-data-streams-and.html">Stealth Alternate Data Streams and Other ADS Weirdness</a> - read it if you haven't already. The author points out some ways to disrupt traditional stream detection tools. Since I created my own stream detection tool (see Chapter 10 of <a href="http://www.amazon.com/dp/0470613033?tag=malwacookb-20&camp=14573&creative=327641&linkCode=as1&creativeASIN=0470613033&adid=1AQZDCRT6GW80HTST44Z&">Malware Analyst's Cookbook</a>), I was interested to see how it would fare. The tool is built on <a href="http://www.sleuthkit.org/sleuthkit/docs/api-docs/">The Sleuth Kit API</a>, thus it reads directly from the MFT instead of relying on Windows API functions.<br />
<br />
Here is a basic listing of my C: drive contents:<br />
<pre>C:\>dir
Volume in drive C has no label.
Volume Serial Number is 400B-1E43
Directory of C:\
08/22/2010 01:36 PM 0 AUTOEXEC.BAT
08/22/2010 01:36 PM 0 CONFIG.SYS
08/22/2010 01:38 PM dir Documents and Settings
06/03/2011 02:58 PM dir Program Files
09/20/2011 10:50 AM dir WINDOWS</pre>
Now I'll create a few of the special streams.<br />
<pre>C:\>echo hi > \\?\C:\NUL
C:\>echo hi > \\?\C:\NUL:hidden
C:\>echo hi > test.txt
C:\>echo hi > test.txt:^G^G^G</pre>
Sanity check on the drive contents (we should see two new files):<br />
<pre><span style="font-family: monospace;">C:\>dir
Volume in drive C has no label.
Volume Serial Number is 400B-1E43
Directory of C:\
08/22/2010 01:36 PM 0 AUTOEXEC.BAT
08/22/2010 01:36 PM 0 CONFIG.SYS
08/22/2010 01:38 PM dir Documents and Settings
09/20/2011 10:57 AM 5 NUL
06/03/2011 02:58 PM dir Program Files
09/20/2011 11:21 AM 5 test.txt
09/20/2011 10:50 AM dir WINDOWS</span></pre>
Now let's see how we do! I'll use <a href="http://code.google.com/p/malwarecookbook/source/browse/trunk/10/2/">tsk-xview.exe</a> (note you also need offreg.dll).<br />
<pre>Z:\tools>tsk-xview.exe -r -v
[INFO] High-level enumeration. Please wait.
[INFO] Found 95773 files and dirs
[INFO] Opened \\.\PhysicalDrive0
[INFO] Partition NTFS (0x07) at sector 56
[INFO] Low-level enumeration. Please wait.
[STREAM] C:/NUL:hidden
Inode: 12991-128-3
Size: 8
SIA Created: Tue Sep 20 10:56:14 2011
SIA File Modified: Tue Sep 20 10:57:27 2011
SIA MFT Modified: Tue Sep 20 10:57:27 2011
SIA Accessed: Tue Sep 20 10:57:27 2011
FNI Created: Tue Sep 20 10:56:14 2011
FNI File Modified: Tue Sep 20 10:56:14 2011
FNI MFT Modified: Tue Sep 20 10:56:14 2011
FNI Accessed: Tue Sep 20 10:56:14 2011
[STREAM] C:/test.txt:^^^
Inode: 12994-128-6
Size: 5
SIA Created: Tue Sep 20 10:58:25 2011
SIA File Modified: Tue Sep 20 11:21:17 2011
SIA MFT Modified: Tue Sep 20 11:21:17 2011
SIA Accessed: Tue Sep 20 11:21:17 2011
FNI Created: Tue Sep 20 10:58:25 2011
FNI File Modified: Tue Sep 20 10:58:25 2011
FNI MFT Modified: Tue Sep 20 10:58:25 2011
FNI Accessed: Tue Sep 20 10:58:25 2011</pre>
It detected both streams perfectly, albeit displaying the file name as ^^^ instead of ^G^G^G (it could be more console-friendly and print those chars as hex values).Michael Hale Lighhttp://www.blogger.com/profile/17377327006242921434noreply@blogger.com6tag:blogger.com,1999:blog-3630199973361886660.post-26610669678593579382011-06-03T08:13:00.117-06:002012-08-05T21:07:22.612-06:00Stuxnet's Footprint in Memory with Volatility 2.0In this blog post, we'll examine Stuxnet's footprint in memory using <a href="http://code.google.com/p/volatility/">Volatility 2.0</a>. A talk was given at <a href="https://www.volatilesystems.com/default/omfw">Open Memory Forensics Workshop</a> on this topic (see the online <a href="http://prezi.com/goocmfeuiqdf/tracking-stuxnets-footprint-through-memory/">Prezi</a>) and the details will be shared here for anyone who missed it.<br />
<br />
I picked this topic for two reasons. First, Stuxnet modifies an infected system in such ways that are perfect for showing off many of the new capabilities in Volatility 2.0. We won't cover <span style="font-style: italic;">all</span> of Volatility's commands (for example you won't see idt, gdt, ssdt), because Stunet doesn't mess with those areas of the system, but you'll get a good summary. Second, although many people understand technical malware descriptions, not many people have the "glue" knowledge to translate artifacts that they read about into Volatility commands. Sometimes you can capably determine if a system is infected by hunting for the artifacts eluded to in reports. Thus, many of the artifacts we'll be hunting come from direct quotes in the following articles:<br />
<br />
* [1] Mark Russinovich's <a href="http://blogs.technet.com/b/markrussinovich/archive/2011/03/30/3416253.aspx">Analyzing a Stuxnet Infection with the Sysinternals Tools</a><a href="http://blogs.technet.com/b/markrussinovich/archive/2011/03/30/3416253.aspx">, Part I</a><br />
* [2] Mark Russinovich's <a href="http://blogs.technet.com/b/markrussinovich/archive/2011/04/20/3422035.aspx">Analyzing a Stuxnet Infection with the Sysinternals Tools</a><a href="http://blogs.technet.com/b/markrussinovich/archive/2011/04/20/3422035.aspx">, Part II</a><br />
* [3] Mark Russinovich's <a href="http://blogs.technet.com/b/markrussinovich/archive/2011/05/10/3422212.aspx">Analyzing a Stuxnet Infection with the Sysinternals Tools</a><a href="http://blogs.technet.com/b/markrussinovich/archive/2011/05/10/3422212.aspx">, Part III</a><br />
* [4] Symantec's <a href="http://www.symantec.com/content/en/us/enterprise/media/security_response/whitepapers/w32_stuxnet_dossier.pdf">W32.Stuxnet Dossier</a><br />
* [5] Amr Thabet's <a href="http://ispy.infospyware.net/images/2010/MrxCls-Stuxnet-Loader-Driver-English.pdf">MrxCls - Stuxnet Loader Driver</a><br />
* [6] ESET's <a href="http://www.eset.com/resources/white-papers/Stuxnet_Under_the_Microscope.pdf">Stuxnet Under The Microscope </a><br />
<br />
<span style="color: #3333ff;"><span style="font-size: 180%;"><span style="color: black;">Getting Started</span></span></span><br />
<br />
The memory image we'll be working with is available <a href="http://malwarecookbook.googlecode.com/svn/trunk/stuxnet.vmem.zip">here</a>. The MD5 of the Stuxnet sample is <a href="http://threatexpert.com/report.aspx?md5=74ddc49a7c121a61b8d06c03f92d0c13">74ddc49a7c121a61b8d06c03f92d0c13</a> (link to ThreatExpert).<br />
<br />
Since I plan to run several commands on the same memory image, I'll start by setting environment variables for the file name and profile.<br />
<br />
$ export VOLATILITY_LOCATION=file:///memory/stuxnet.vmem<br />
$ export VOLATILITY_PROFILE=WinXPSP3x86<br />
<br />
Then I made sure to grab the latest <a href="http://code.google.com/p/malwarecookbook/source/browse/trunk/malware.py">malware.py source code</a> and placed it in Volatility's plugins directory.<br />
<br />
<span style="color: #3333ff;"><span style="font-size: 180%;"><span style="color: black;">Artifact 1: Extra lsass.exe</span></span></span><br />
<blockquote>
<span style="color: #3333ff;">"a normal Windows XP installation has just one instance of Lsass.exe that the Winlogon process creates when the system boots (Wininit creates it on Windows Vista and higher). The process tree reveals that the two new Lsass.exe instances were both created by Services.exe...the Service Control Manager, which implies that Stuxnet somehow got its code into the Services.exe process." [1]</span></blockquote>
Based on this statement, you could use the <a href="http://code.google.com/p/volatility/wiki/CommandReference#pslist">pslist</a>, <a href="http://code.google.com/p/volatility/wiki/CommandReference#psscan">psscan</a>, or <a href="http://code.google.com/p/volatility/wiki/CommandReference#pstree">pstree</a> commands. Pslist walks the doubly-linked list of EPROCESS structures starting from PsActiveProcessHead. Psscan uses pool tag scanning. Since we have no reason to believe that Stuxnet uses DKOM for process hiding, I won't use psscan. Pstree inherits from pslist (see the <a href="http://volatility.googlecode.com/files/volatility-2.0-inheritance-graph.pdf">Volatility 2.0 Inheritance Graph</a>) and is probably best since it shows a visual parent/child relationship.<br />
<pre><span style="font-size: 78%;"><span style="font-family: courier new;">$<span style="font-weight: bold;"> ./vol.py pstree</span></span>
<span style="font-family: courier new;">Volatile Systems Volatility Framework 2.0</span>
<span style="font-family: courier new;">Name Pid PPid Thds Hnds Time </span>
<span style="font-family: courier new;"> 0x823C8830:System 4 0 59 403 1970-01-01 00:00:00 </span>
<span style="font-family: courier new;">. 0x820DF020:smss.exe 376 4 3 19 2010-10-29 17:08:53 </span>
<span style="font-family: courier new;">.. 0x821A2DA0:csrss.exe 600 376 11 395 2010-10-29 17:08:54 </span>
<span style="font-family: courier new;">.. 0x81DA5650:winlogon.exe 624 376 19 570 2010-10-29 17:08:54 </span>
<span style="font-family: courier new;">... 0x82073020:services.exe 668 624 21 431 2010-10-29 17:08:54 </span>
<span style="font-family: courier new;">.... 0x81FE52D0:vmtoolsd.exe 1664 668 5 284 2010-10-29 17:09:05 </span>
<span style="font-family: courier new;">..... 0x81C0CDA0:cmd.exe 968 1664 0 ------ 2011-06-03 04:31:35 </span>
<span style="font-family: courier new;">...... 0x81F14938:ipconfig.exe 304 968 0 ------ 2011-06-03 04:31:35 </span>
<span style="font-family: courier new;">.... 0x822843E8:svchost.exe 1032 668 61 1169 2010-10-29 17:08:55 </span>
<span style="font-family: courier new;">..... 0x822B9A10:wuauclt.exe 976 1032 3 133 2010-10-29 17:12:03 </span>
<span style="font-family: courier new;">..... 0x820ECC10:wscntfy.exe 2040 1032 1 28 2010-10-29 17:11:49 </span>
<span style="font-family: courier new;">.... 0x81E61DA0:svchost.exe 940 668 13 312 2010-10-29 17:08:55 </span>
<span style="font-family: courier new;">.... 0x81DB8DA0:svchost.exe 856 668 17 193 2010-10-29 17:08:55 </span>
<span style="font-family: courier new;">..... 0x81FA5390:wmiprvse.exe 1872 856 5 134 2011-06-03 04:25:58 </span>
<span style="font-family: courier new;">.... 0x821A0568:VMUpgradeHelper 1816 668 3 96 2010-10-29 17:09:08 </span>
<span style="font-family: courier new;">.... 0x81FEE8B0:spoolsv.exe 1412 668 10 118 2010-10-29 17:08:56 </span>
<span style="font-family: courier new;">.... 0x81FF7020:svchost.exe 1200 668 14 197 2010-10-29 17:08:55 </span>
<span style="font-family: courier new;"><span style="color: red;"><span style="font-weight: bold;">.... 0x81C47C00:lsass.exe 1928 668 4 65 2011-06-03 04:26:55 </span> </span> </span>
<span style="font-family: courier new;">.... 0x81E18B28:svchost.exe 1080 668 5 80 2010-10-29 17:08:55 </span>
<span style="font-family: courier new;">.... 0x8205ADA0:alg.exe 188 668 6 107 2010-10-29 17:09:09 </span>
<span style="font-family: courier new;">.... 0x823315D8:vmacthlp.exe 844 668 1 25 2010-10-29 17:08:55 </span>
<span style="font-family: courier new;">.... 0x81E0EDA0:jqs.exe 1580 668 5 148 2010-10-29 17:09:05 </span>
<span style="font-family: courier new;"><span style="color: red; font-weight: bold;">.... 0x81C498C8:lsass.exe 868 668 2 23 2011-06-03 04:26:55 </span> </span>
<span style="font-family: courier new;">.... 0x82279998:imapi.exe 756 668 4 116 2010-10-29 17:11:54 </span>
<span style="color: red; font-family: courier new; font-weight: bold;">... 0x81E70020:lsass.exe 680 624 19 342 2010-10-29 17:08:54 </span></span></pre>
As you can see, the two lsass.exe processes that started on 2011-06-03 have a parent pid of 668, which belongs to services.exe. However the real lsass.exe (pid 680) has a parent pid of 624 which belongs to winlogon.exe. Given the method used to start the two malicious lsass.exe processes, their SIDs also match the legit copy...which you can verify with <a href="http://code.google.com/p/volatility/wiki/CommandReference#getsids">getsids</a>.<br />
<pre><span style="font-size: 78%;"><span style="font-family: courier new;">$ <span style="font-weight: bold;">./vol.py getsids -p 680,868,1928</span></span>
<span style="font-family: courier new;">Volatile Systems Volatility Framework 2.0</span>
<span style="font-family: courier new;">lsass.exe (680): S-1-5-18 (Local System)</span>
<span style="font-family: courier new;">lsass.exe (680): S-1-5-32-544 (Administrators)</span>
<span style="font-family: courier new;">lsass.exe (680): S-1-1-0 (Everyone)</span>
<span style="font-family: courier new;">lsass.exe (680): S-1-5-11 (Authenticated Users)
</span><span style="font-family: courier new;">lsass.exe (868): S-1-5-18 (Local System)</span>
<span style="font-family: courier new;">lsass.exe (868): S-1-5-32-544 (Administrators)</span>
<span style="font-family: courier new;">lsass.exe (868): S-1-1-0 (Everyone)</span>
<span style="font-family: courier new;">lsass.exe (868): S-1-5-11 (Authenticated Users)
</span><span style="font-family: courier new;">lsass.exe (1928): S-1-5-18 (Local System)</span>
<span style="font-family: courier new;">lsass.exe (1928): S-1-5-32-544 (Administrators)</span>
<span style="font-family: courier new;">lsass.exe (1928): S-1-1-0 (Everyone)</span>
<span style="font-family: courier new;">lsass.exe (1928): S-1-5-11 (Authenticated Users)</span></span></pre>
<span style="font-size: 180%;">Artifact 2: Process Priority</span><br />
<div style="color: #3333ff; text-align: left;">
<blockquote>
"...some Windows system processes (such as the Session Manager, service controller, and local security authentication server) have a base process priority slightly higher than the default for the Normal class (8)." - Windows Internals 5th Edition pg. 395</blockquote>
</div>
In other words, the legit local security authentication server (lsass.exe) will have a higher priority than normal processes, including those created by Stuxnet. The process base priority is stored in EPROCESS.Pcb.BasePriority. Although there isn't necessarily a plugin already written to extract the BasePriority field, the data is very easy to access in Volatility, as opposed to some GUI tools which only show you select fields from EPROCESS. For example, just use a little <a href="http://code.google.com/p/volatility/wiki/CommandReference#volshell">volshell</a> scripting.<br />
<pre><span style="font-size: 78%;"><span style="font-family: courier new;">$ <span style="font-weight: bold;">./vol.py volshell </span></span>
<span style="font-family: courier new;">Volatile Systems Volatility Framework 2.0
Current context: process System, pid=4, ppid=0 DTB=0x319000
Leopard libedit detected.
Welcome to volshell! Current memory image is:
file:////memory/stuxnet.vmem
To get help, type 'hh()'
In [1]: <span style="font-weight: bold;">for proc in win32.tasks.pslist(self.addrspace):</span>
....: <span style="font-weight: bold;">if proc.UniqueProcessId in (680, 868, 1928):</span>
....: <span style="font-weight: bold;">print "Pid: {0} Priority: {1}".format(proc.UniqueProcessId, proc.Pcb.BasePriority)</span>
....:
<span style="color: red; font-weight: bold;">Pid: 680 Priority: 9</span>
<span style="color: red; font-weight: bold;">Pid: 868 Priority: 8</span>
<span style="color: red; font-weight: bold;">Pid: 1928 Priority: 8</span></span></span></pre>
As you can see, the BasePriority of the legit lsass.exe (pid 680) is 9, whereas the ones created by Stuxnet are 8. It is possible to change the priority by using <a href="http://msdn.microsoft.com/en-us/library/ms686219%28v=vs.85%29.aspx">SetPriorityClass</a>, but Stuxnet doesn't bother to do so. Also, since the base priority of threads is inherited from the base priority of the process which owns the thread (unless <a href="http://msdn.microsoft.com/en-us/library/ms686277%28v=vs.85%29.aspx">SetThreadPriority</a> is called), then the differences should be visible using the <a href="http://code.google.com/p/volatility/wiki/CommandReference#threads">threads</a> command.<br />
<br />
Take a look at a thread owned by the legit lsass.exe (Tid 1768) and a thread owned by a malicious lsass.exe (Tid 764).<br />
<pre><span style="font-size: 78%;"><span style="font-family: courier new;">$ <span style="font-weight: bold;">./vol.py threads </span></span>
<span style="font-family: courier new;">[snip] </span>
<span style="font-family: courier new;">------</span>
<span style="font-family: courier new;">ETHREAD: 0x822722d0 <span style="color: red; font-weight: bold;">Pid: 680</span> <span style="color: red; font-weight: bold;">Tid: 1768</span></span>
<span style="font-family: courier new;">Tags: HookedSSDT</span>
<span style="font-family: courier new;">Created: 2010-10-29 17:09:05 </span>
<span style="font-family: courier new;">Exited: -</span>
<span style="font-family: courier new;">Owning Process: 0x81e70020 'lsass.exe'</span>
<span style="font-family: courier new;">Attached Process: 0x81e70020 'lsass.exe'</span>
<span style="font-family: courier new;">State: Waiting:UserRequest</span>
<span style="font-family: courier new;"><span style="color: red; font-weight: bold;">BasePriority: 0x9
Priority: 0x9</span></span><span style="font-family: courier new;">TEB: 0x7ffa0000</span>
<span style="font-family: courier new;">StartAddress: 0x7c8106e9 </span>
<span style="font-family: courier new;">ServiceTable: 0x80552fa0</span>
<span style="font-family: courier new;"> [0] 0x80501b8c</span>
<span style="font-family: courier new;"> [0x19] NtClose 0xb240f80e PROCMON20.SYS</span>
<span style="font-family: courier new;"> [0x29] NtCreateKey 0xb240f604 PROCMON20.SYS</span>
<span style="font-family: courier new;"> [0x3f] NtDeleteKey 0xb240f4ac PROCMON20.SYS</span>
<span style="font-family: courier new;"> [0x41] NtDeleteValueKey 0xb240f4f2 PROCMON20.SYS</span>
<span style="font-family: courier new;"> [0x47] NtEnumerateKey 0xb240f3f2 PROCMON20.SYS</span>
<span style="font-family: courier new;"> [0x49] NtEnumerateValueKey 0xb240f34e PROCMON20.SYS</span>
<span style="font-family: courier new;"> [0x4f] NtFlushKey 0xb240f446 PROCMON20.SYS</span>
<span style="font-family: courier new;"> [0x62] NtLoadKey 0xb240f972 PROCMON20.SYS</span>
<span style="font-family: courier new;"> [0x77] NtOpenKey 0xb240f7d0 PROCMON20.SYS</span>
<span style="font-family: courier new;"> [0xa0] NtQueryKey 0xb240f03e PROCMON20.SYS</span>
<span style="font-family: courier new;"> [0xb1] NtQueryValueKey 0xb240f166 PROCMON20.SYS</span>
<span style="font-family: courier new;"> [0xf7] NtSetValueKey 0xb240f28a PROCMON20.SYS</span>
<span style="font-family: courier new;"> [0x107] NtUnloadKey 0xb240fac2 PROCMON20.SYS</span>
<span style="font-family: courier new;"> [1] -</span>
<span style="font-family: courier new;"> [2] -</span>
<span style="font-family: courier new;"> [3] -</span>
<span style="font-family: courier new;"> Win32Thread: 0x00000000</span>
<span style="font-family: courier new;"> CrossThreadFlags: </span>
<span style="font-family: courier new;">------</span>
<span style="font-family: courier new;">ETHREAD: 0x81f44730 <span style="color: red; font-weight: bold;">Pid: 1928</span> <span style="color: red; font-weight: bold;">Tid: 764</span></span>
<span style="font-family: courier new;">Tags: HookedSSDT</span>
<span style="font-family: courier new;">Created: 2011-06-03 04:26:55 </span>
<span style="font-family: courier new;">Exited: -</span>
<span style="font-family: courier new;">Owning Process: 0x81c47c00 'lsass.exe'</span>
<span style="font-family: courier new;">Attached Process: 0x81c47c00 'lsass.exe'</span>
<span style="font-family: courier new;">State: Waiting:UserRequest</span>
<span style="color: red; font-family: courier new; font-weight: bold;">BasePriority: 0x8
Priority: 0x8</span><span style="font-family: courier new;">TEB: 0x7ffdb000</span>
<span style="font-family: courier new;">StartAddress: 0x7c8106e9 </span>
<span style="font-family: courier new;">ServiceTable: 0x80552f60</span>
<span style="font-family: courier new;"> [0] 0x80501b8c</span>
<span style="font-family: courier new;"> [0x19] NtClose 0xb240f80e PROCMON20.SYS</span>
<span style="font-family: courier new;"> [0x29] NtCreateKey 0xb240f604 PROCMON20.SYS</span>
<span style="font-family: courier new;"> [0x3f] NtDeleteKey 0xb240f4ac PROCMON20.SYS</span>
<span style="font-family: courier new;"> [0x41] NtDeleteValueKey 0xb240f4f2 PROCMON20.SYS</span>
<span style="font-family: courier new;"> [0x47] NtEnumerateKey 0xb240f3f2 PROCMON20.SYS</span>
<span style="font-family: courier new;"> [0x49] NtEnumerateValueKey 0xb240f34e PROCMON20.SYS</span>
<span style="font-family: courier new;"> [0x4f] NtFlushKey 0xb240f446 PROCMON20.SYS</span>
<span style="font-family: courier new;"> [0x62] NtLoadKey 0xb240f972 PROCMON20.SYS</span>
<span style="font-family: courier new;"> [0x77] NtOpenKey 0xb240f7d0 PROCMON20.SYS</span>
<span style="font-family: courier new;"> [0xa0] NtQueryKey 0xb240f03e PROCMON20.SYS</span>
<span style="font-family: courier new;"> [0xb1] NtQueryValueKey 0xb240f166 PROCMON20.SYS</span>
<span style="font-family: courier new;"> [0xf7] NtSetValueKey 0xb240f28a PROCMON20.SYS</span>
<span style="font-family: courier new;"> [0x107] NtUnloadKey 0xb240fac2 PROCMON20.SYS</span>
<span style="font-family: courier new;"> [1] 0xbf999b80</span>
<span style="font-family: courier new;"> [2] -</span>
<span style="font-family: courier new;"> [3] -</span>
<span style="font-family: courier new;">Win32Thread: 0xe126ceb0</span>
<span style="font-family: courier new;">CrossThreadFlags: </span></span></pre>
The BasePriority 0x9 you see for Tid 1768 is because the parent process (legit lsass.exe) has BasePriority 0x9 (slightly above normal). The BasePriority 0x8 you see for Tid 764 is because the parent process (Stuxnet lsass.exe) has BasePriority 0x8 (Normal).<br />
<br />
This isn't a strong artifact, since threads can dynamically change priority, but its an artifact nonetheless.<br />
<br />
Lastly, it is worth noting that Stuxnet's kernel driver injects DLLs into processes by using the <a href="http://msdn.microsoft.com/en-us/library/ff549659%28v=vs.85%29.aspx">KeStackAttachProcess</a> API. So if you happen to dump memory <span style="font-style: italic;">during</span> one of the injection procedures, you'll also see in the threads output that the owning process is different from the attached process.<br />
<br />
<span style="color: #3333ff;"><span style="font-size: 180%;"><span style="color: black;">Artifact 3: Too Few DLLs</span></span></span><span style="color: #3333ff;"><br /></span><br />
<blockquote>
<span style="color: #3333ff;">"...besides running as children of Services.exe, another suspicious characteristic of the two superfluous processes is the fact that they have very few DLLs loaded..." [1]</span></blockquote>
Based on this statement, you can use <a href="http://code.google.com/p/volatility/wiki/CommandReference#dlllist">dlllist</a> with the -p parameter to focus only on certain processes. In this case, we're interested in comparing pids 680 (legit), 868 (bad), and 1928 (bad).<br />
<pre><span style="font-size: 78%;"><span style="font-family: courier new;">$ <span style="font-weight: bold;">./vol.py dlllist -p 680,868,1928</span></span>
<span style="font-family: courier new;">Volatile Systems Volatility Framework 2.0</span>
<span style="font-family: courier new;">************************************************************************</span>
<span style="font-family: courier new;">lsass.exe pid: 680</span>
<span style="font-family: courier new;">Command line : -</span>
<span style="font-family: courier new;">Service Pack 3</span>
<span style="font-family: courier new;">Base Size Path</span>
<span style="font-family: courier new;">0x01000000 0x006000 </span>
<span style="font-family: courier new;">0x7c900000 0x0af000 C:\WINDOWS\system32\ntdll.dll</span>
<span style="font-family: courier new;">0x7c800000 0x0f6000 C:\WINDOWS\system32\kernel32.dll</span>
<span style="font-family: courier new;">0x77dd0000 0x09b000 C:\WINDOWS\system32\ADVAPI32.dll</span>
<span style="font-family: courier new;">0x77e70000 0x092000 C:\WINDOWS\system32\RPCRT4.dll</span>
<span style="font-family: courier new;">0x77fe0000 0x011000 C:\WINDOWS\system32\Secur32.dll</span>
<span style="font-family: courier new;">0x75730000 0x0b5000 C:\WINDOWS\system32\LSASRV.dll</span>
<span style="color: red; font-family: courier new; font-weight: bold;">[snip - about 60 others]</span><span style="font-family: courier new;">
</span><span style="font-family: courier new;">************************************************************************</span>
<span style="font-family: courier new;">lsass.exe pid: 868</span>
<span style="font-family: courier new;">Command line : "C:\WINDOWS\\system32\\lsass.exe"</span>
<span style="font-family: courier new;">Service Pack 3</span>
<span style="font-family: courier new;">Base Size Path</span>
<span style="font-family: courier new;">0x01000000 0x006000 C:\WINDOWS\system32\lsass.exe</span>
<span style="font-family: courier new;">0x7c900000 0x0af000 C:\WINDOWS\system32\ntdll.dll</span>
<span style="font-family: courier new;">0x7c800000 0x0f6000 C:\WINDOWS\system32\kernel32.dll</span>
<span style="font-family: courier new;">0x77dd0000 0x09b000 C:\WINDOWS\system32\ADVAPI32.dll</span>
<span style="font-family: courier new;">0x77e70000 0x092000 C:\WINDOWS\system32\RPCRT4.dll</span>
<span style="font-family: courier new;">0x77fe0000 0x011000 C:\WINDOWS\system32\Secur32.dll</span>
<span style="font-family: courier new;">0x7e410000 0x091000 C:\WINDOWS\system32\USER32.dll</span>
<span style="font-family: courier new;">0x77f10000 0x049000 C:\WINDOWS\system32\GDI32.dll</span>
<span style="font-family: courier new;">************************************************************************</span>
<span style="font-family: courier new;">lsass.exe pid: 1928</span>
<span style="font-family: courier new;">Command line : "C:\WINDOWS\\system32\\lsass.exe"</span>
<span style="font-family: courier new;">Service Pack 3</span>
<span style="font-family: courier new;">Base Size Path</span>
<span style="font-family: courier new;">0x01000000 0x006000 C:\WINDOWS\system32\lsass.exe</span>
<span style="font-family: courier new;">0x7c900000 0x0af000 C:\WINDOWS\system32\ntdll.dll</span>
<span style="font-family: courier new;">0x7c800000 0x0f6000 C:\WINDOWS\system32\kernel32.dll</span>
<span style="font-family: courier new;">0x77dd0000 0x09b000 C:\WINDOWS\system32\ADVAPI32.dll</span>
<span style="font-family: courier new;">0x77e70000 0x092000 C:\WINDOWS\system32\RPCRT4.dll</span>
<span style="font-family: courier new;">0x77fe0000 0x011000 C:\WINDOWS\system32\Secur32.dll</span>
<span style="font-family: courier new;">0x7e410000 0x091000 C:\WINDOWS\system32\USER32.dll</span>
<span style="font-family: courier new;">0x77f10000 0x049000 C:\WINDOWS\system32\GDI32.dll</span>
<span style="font-family: courier new;">0x00870000 0x138000 C:\WINDOWS\system32\KERNEL32.DLL.ASLR.0360b7ab</span>
<span style="color: red; font-family: courier new; font-weight: bold;">[snip - about 20 others]</span></span></pre>
This output supports Mark's findings that the malicious lsass.exe processes have far fewer DLLs loaded than the legit copy. Its worth mentioning that the malicious processes also have less open files and registry keys - which you can verify with the <a href="http://code.google.com/p/volatility/wiki/CommandReference#handles">handles</a> command (we'll use this command later).<br />
<br />
<span style="color: #3333ff;"><span style="font-size: 180%;"><span style="color: black;">Artifact 4: Injected Code</span></span></span><br />
<span style="color: #3333ff;"></span><br />
<blockquote>
<span style="color: #3333ff;">"No non-Microsoft DLLs show up in the loaded-module lists for Services.exe, Lsass.exe or Explorer.exe, so they are probably hosting injected executable code. [....] Sure enough, the legitimate Lsass has no executable data regions, but both new Lsass processes have regions with Execute and Write permissions in their address spaces at the same location and same size." [1]</span></blockquote>
Based on this statement, you can use <a href="http://code.google.com/p/volatility/wiki/CommandReference#malfind">malfind</a> to automatically locate and extract the injected executable code.<br />
<pre><span style="font-size: 78%;"><span style="font-family: courier new;">$ <span style="font-weight: bold;">./vol.py malfind -D out </span></span>
<span style="font-family: courier new;">Volatile Systems Volatility Framework 2.0</span>
<span style="font-family: courier new;">Name Pid Start End Tag Hits Protect</span>
<span style="font-family: courier new;">lsass.exe 868 <span style="color: red; font-weight: bold;">0x00080000</span> 0x000F9FFF Vad 0 6 (MM_EXECUTE_READWRITE)</span>
<span style="color: red; font-family: courier new; font-weight: bold;">Dumped to: out/lsass.exe.1e498c8.00080000-000f9fff.dmp</span>
<span style="font-family: courier new;">0x00080000 <span style="color: red; font-weight: bold;">4d 5a</span> 90 00 03 00 00 00 04 00 00 00 ff ff 00 00 <span style="color: red; font-weight: bold;">MZ</span>..............</span>
<span style="font-family: courier new;">0x00080010 b8 00 00 00 00 00 00 00 40 00 00 00 00 00 00 00 ........@.......</span>
<span style="font-family: courier new;">0x00080020 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 ................</span>
<span style="font-family: courier new;">0x00080030 00 00 00 00 00 00 00 00 00 00 00 00 08 01 00 00 ................</span>
<span style="font-family: courier new;">0x00080040 0e 1f ba 0e 00 b4 09 cd 21 b8 01 4c cd 21 54 68 ........!..L.!Th</span>
<span style="font-family: courier new;">0x00080050 69 73 20 70 72 6f 67 72 61 6d 20 63 61 6e 6e 6f is program canno</span>
<span style="font-family: courier new;">0x00080060 74 20 62 65 20 72 75 6e 20 69 6e 20 44 4f 53 20 t be run in DOS </span>
<span style="font-family: courier new;">0x00080070 6d 6f 64 65 2e 0d 0d 0a 24 00 00 00 00 00 00 00 mode....$.......</span>
<span style="font-family: courier new;">lsass.exe 1928 <span style="color: red; font-weight: bold;">0x00080000</span> 0x000F9FFF Vad 0 6 (MM_EXECUTE_READWRITE)</span>
<span style="color: red; font-family: courier new; font-weight: bold;">Dumped to: out/lsass.exe.1e47c00.00080000-000f9fff.dmp</span>
<span style="font-family: courier new;">0x00080000 <span style="color: red; font-weight: bold;">4d 5a</span> 90 00 03 00 00 00 04 00 00 00 ff ff 00 00 <span style="color: red; font-weight: bold;">MZ</span>..............</span>
<span style="font-family: courier new;">0x00080010 b8 00 00 00 00 00 00 00 40 00 00 00 00 00 00 00 ........@.......</span>
<span style="font-family: courier new;">0x00080020 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 ................</span>
<span style="font-family: courier new;">0x00080030 00 00 00 00 00 00 00 00 00 00 00 00 08 01 00 00 ................</span>
<span style="font-family: courier new;">0x00080040 0e 1f ba 0e 00 b4 09 cd 21 b8 01 4c cd 21 54 68 ........!..L.!Th</span>
<span style="font-family: courier new;">0x00080050 69 73 20 70 72 6f 67 72 61 6d 20 63 61 6e 6e 6f is program canno</span>
<span style="font-family: courier new;">0x00080060 74 20 62 65 20 72 75 6e 20 69 6e 20 44 4f 53 20 t be run in DOS </span>
<span style="font-family: courier new;">0x00080070 6d 6f 64 65 2e 0d 0d 0a 24 00 00 00 00 00 00 00 mode....$.......</span></span></pre>
Malfind located two suspicious regions, at 0x80000 base address in both processes. They have MM_EXECUTE_READWRITE permissions and start with MZ, meaning a PE is likely stored here. My usual next step is to try and find out where the injected code came from. Is it mapped to some file on disk? You can use <a href="http://code.google.com/p/volatility/wiki/CommandReference#vadinfo">vadinfo</a> to see more granular details about the memory segment:<br />
<pre><span style="font-size: 78%;"><span style="font-family: courier new;">$ <span style="font-weight: bold;">./vol.py vadinfo -p 868 </span></span>
<span style="font-family: courier new;">[snip]</span>
<span style="font-family: courier new;">VAD node @822e7e70 Start 00080000 End 000f9fff Tag Vad </span>
<span style="font-family: courier new;">Flags: </span>
<span style="font-family: courier new;">Commit Charge: 0 Protection: 6</span>
<span style="font-family: courier new;">ControlArea @81de9890 Segment e2b7dbf0</span>
<span style="font-family: courier new;">Dereference list: Flink 00000000, Blink 00000000</span>
<span style="font-family: courier new;">NumberOfSectionReferences: 0 NumberOfPfnReferences: 0</span>
<span style="font-family: courier new;">NumberOfMappedViews: 1 NumberOfUserReferences: 1</span>
<span style="font-family: courier new;">WaitingForDeletion Event: 00000000</span>
<span style="font-family: courier new;">Flags: Commit, HadUserReference</span>
<span style="color: red; font-family: courier new; font-weight: bold;">FileObject: none</span>
<span style="font-family: courier new;">First prototype PTE: e2b7dc30 Last contiguous PTE: e2b7dff8</span>
<span style="font-family: courier new;">Flags2: Inherit</span><span style="font-family: courier new;">
</span></span></pre>
You can tell the memory isn't backed by a file because the FileObject pointer is none/NULL. It would be backed by a file if the PE was loaded via LoadLibrary. More on this in the next artifact.<br />
<br />
<span style="color: #3333ff;"><span style="font-size: 180%;"><span style="color: black;">Artifact 5: Hidden DLLs</span></span></span><br />
<span style="color: #3333ff;"></span><br />
<blockquote>
</blockquote>
<br />
<blockquote>
<span style="color: #3333ff;">"Stuxnet calls LoadLibrary with a specially crafted file name that does not exist on disk and normally causes LoadLibrary to fail. However, W32.Stuxnet has hooked Ntdll.dll to monitor for requests to load specially crafted file names. These specially crafted filenames are mapped to another location instead—a location specified by W32.Stuxnet. That location is generally an area in memory where a .dll file has been decrypted and stored by the threat previously. The filenames used have the pattern of KERNEL32.DLL.ASLR.[HEXADECIMAL]..." [4]</span></blockquote>
Based on this statement, you can use the <a href="http://code.google.com/p/volatility/wiki/CommandReference#dlllist">dlllist</a> command to view the evidence. Even though the file doesn't exist on disk *and* the malware hooks the DLL loading APIs, the file name will still end up in the PEB lists.<br />
<pre><span style="font-size: 78%;"><span style="font-family: courier new;">$<span style="font-weight: bold;"> ./vol.py dlllist | grep ASLR</span></span>
<span style="font-family: courier new;">Volatile Systems Volatility Framework 2.0
Base Size Path</span><span style="font-family: courier new;">0x013f0000 0x138000 C:\WINDOWS\system32\KERNEL32.DLL.ASLR.0360c5e2</span>
<span style="font-family: courier new;">0x00d00000 0x138000 C:\WINDOWS\system32\KERNEL32.DLL.ASLR.0360c8ee</span>
<span style="font-family: courier new;">0x00870000 0x138000 C:\WINDOWS\system32\KERNEL32.DLL.ASLR.0360b7ab</span></span></pre>
For a different perspective, you can use the <a href="http://code.google.com/p/volatility/wiki/CommandReference#ldrmodules">ldrmodules</a> plugin. This is useful if you don't preemptively know to search for "ASLR" or any predictable file name. This plugin compares the PE files in memory with mapped files and the 3 DLL lists in the PEB. This is one of my favorite artifacts, because Stuxnet actually uses 3 different types of code injection - all of which are visible (and distinguishable from each other) by using a simpe command:<br />
<pre><span style="font-size: 78%;"><span style="font-family: courier new;">$ <span style="font-weight: bold;">./vol.py ldrmodules -p 1928</span></span>
<span style="font-family: courier new;">Volatile Systems Volatility Framework 2.0</span>
<span style="font-family: courier new;">Pid Process Base InLoad InInit InMem Path</span>
<span style="font-family: courier new;"> <span style="color: red; font-weight: bold;">1928 lsass.exe 0x00080000 0 0 0 -</span></span>
<span style="font-family: courier new;"> 1928 lsass.exe 0x7C900000 1 1 1 \WINDOWS\system32\ntdll.dll</span>
<span style="font-family: courier new;"> 1928 lsass.exe 0x773D0000 1 1 1 \WINDOWS\WinSxS\x86_Microsoft.Windows.Common-Controls_6595b64144ccf1df_6.0.2600.5512_x-ww_35d4ce83\comctl32.dll</span>
<span style="font-family: courier new;"> 1928 lsass.exe 0x77F60000 1 1 1 \WINDOWS\system32\shlwapi.dll</span>
<span style="font-family: courier new;"> 1928 lsass.exe 0x771B0000 1 1 1 \WINDOWS\system32\wininet.dll</span>
<span style="font-family: courier new;"> 1928 lsass.exe 0x77A80000 1 1 1 \WINDOWS\system32\crypt32.dll</span>
<span style="font-family: courier new;"> 1928 lsass.exe 0x77FE0000 1 1 1 \WINDOWS\system32\secur32.dll</span>
<span style="font-family: courier new;"> 1928 lsass.exe 0x77C00000 1 1 1 \WINDOWS\system32\version.dll</span>
<span style="font-family: courier new;"> <span style="color: red; font-weight: bold;">1928 lsass.exe 0x01000000 1 0 1 -</span></span>
<span style="font-family: courier new;"> 1928 lsass.exe 0x5B860000 1 1 1 \WINDOWS\system32\netapi32.dll</span>
<span style="font-family: courier new;"> 1928 lsass.exe 0x77E70000 1 1 1 \WINDOWS\system32\rpcrt4.dll</span>
<span style="font-family: courier new;"> 1928 lsass.exe 0x71AB0000 1 1 1 \WINDOWS\system32\ws2_32.dll</span>
<span style="font-family: courier new;"> 1928 lsass.exe 0x71AD0000 1 1 1 \WINDOWS\system32\wsock32.dll</span>
<span style="font-family: courier new;"> 1928 lsass.exe 0x774E0000 1 1 1 \WINDOWS\system32\ole32.dll</span>
<span style="font-family: courier new;"> 1928 lsass.exe 0x7E410000 1 1 1 \WINDOWS\system32\user32.dll</span>
<span style="font-family: courier new;"> 1928 lsass.exe 0x77F10000 1 1 1 \WINDOWS\system32\gdi32.dll</span>
<span style="font-family: courier new;"> 1928 lsass.exe 0x77120000 1 1 1 \WINDOWS\system32\oleaut32.dll</span>
<span style="font-family: courier new;"> 1928 lsass.exe 0x76D60000 1 1 1 \WINDOWS\system32\iphlpapi.dll</span>
<span style="font-family: courier new;"> 1928 lsass.exe 0x769C0000 1 1 1 \WINDOWS\system32\userenv.dll</span>
<span style="font-family: courier new;"> 1928 lsass.exe 0x7C800000 1 1 1 \WINDOWS\system32\kernel32.dll</span>
<span style="font-family: courier new;"> 1928 lsass.exe 0x76BF0000 1 1 1 \WINDOWS\system32\psapi.dll</span>
<span style="font-family: courier new;"> 1928 lsass.exe 0x77C10000 1 1 1 \WINDOWS\system32\msvcrt.dll</span>
<span style="font-family: courier new;"> 1928 lsass.exe 0x77DD0000 1 1 1 \WINDOWS\system32\advapi32.dll</span>
<span style="font-family: courier new;"> 1928 lsass.exe 0x7C9C0000 1 1 1 \WINDOWS\system32\shell32.dll</span>
<span style="font-family: courier new;"> <span style="color: red; font-weight: bold;">1928 lsass.exe 0x00870000 1 1 1 -</span></span>
<span style="font-family: courier new;"> 1928 lsass.exe 0x76F20000 1 1 1 \WINDOWS\system32\dnsapi.dll</span>
<span style="font-family: courier new;"> 1928 lsass.exe 0x5D090000 1 1 1 \WINDOWS\system32\comctl32.dll</span>
<span style="font-family: courier new;"> 1928 lsass.exe 0x71AA0000 1 1 1 \WINDOWS\system32\ws2help.dll</span>
<span style="font-family: courier new;"> 1928 lsass.exe 0x77B20000 1 1 1 \WINDOWS\system32\msasn1.dll</span></span></pre>
The three lines in red are either suspicious because an entry is missing from one of the 3 PEB lists or because the path name is blank. From top to bottom, you first see the PE at 0x80000 which we have already identified as injected code in artifact 4. It wasn't loaded with LoadLibrary so its not in any of the 3 PEB lists. Its not backed by a file, so the path is blank. Most likely, this is code injected via <a href="http://msdn.microsoft.com/en-us/library/aa366890%28VS.85%29.aspx">VirtualAlloc</a>(Ex) and <a href="http://msdn.microsoft.com/en-us/library/ms681674%28VS.85%29.aspx">WriteProcessMemory</a>.<br />
<br />
The PE at 0x01000000 is interesting, because there is an entry for it in 2 of the 3 DLL lists (missing from the Init list), yet it isn't backed by a file. In normal cases, a program's main module (the .exe) will be backed by a file. So the question becomes: is 0x01000000 the ImageBase of the main module? To see, you can run ldrmodules using the -v (verbose) flag.<br />
<pre><span style="font-size: 78%;"><span style="font-family: courier new;">$ <span style="font-weight: bold;">./vol.py ldrmodules -p 1928 -v </span></span>
<span style="font-family: courier new;">Volatile Systems Volatility Framework 2.0</span>
<span style="font-family: courier new;">Pid Process Base InLoad InInit InMem Path</span>
<span style="font-family: courier new;">1928 lsass.exe 0x00080000 0 0 0 -</span>
<span style="font-family: courier new;">1928 lsass.exe 0x01000000 1 0 1 -</span>
<span style="font-family: courier new;"> Load Path: C:\WINDOWS\system32\lsass.exe : lsass.exe</span>
<span style="font-family: courier new;"> Mem Path: C:\WINDOWS\system32\lsass.exe : lsass.exe</span>
<span style="font-family: courier new;">1928 lsass.exe 0x00870000 1 1 1 -</span>
<span style="font-family: courier new;"> Load Path: C:\WINDOWS\system32\KERNEL32.DLL.ASLR.0360b7ab : KERNEL32.DLL.ASLR.0360b7ab</span>
<span style="font-family: courier new;"> Init Path: C:\WINDOWS\system32\KERNEL32.DLL.ASLR.0360b7ab : KERNEL32.DLL.ASLR.0360b7ab</span>
<span style="font-family: courier new;"> Mem Path: C:\WINDOWS\system32\KERNEL32.DLL.ASLR.0360b7ab : KERNEL32.DLL.ASLR.0360b7ab</span></span></pre>
This confirms that 0x01000000 is the ImageBase for the main module, C:\WINDOWS\system32\lsass.exe. So then why is the path blank, indicating that the memory isn't backed by a file? We may be looking at a <a href="http://blog.spiderlabs.com/2011/05/analyzing-malware-hollow-processes.html">hollow process</a> situation. You can confirm by using <a href="http://code.google.com/p/volatility/wiki/CommandReference#procexedump">procexedump</a> or <a href="http://code.google.com/p/volatility/wiki/CommandReference#procmemdump">procmemdump</a> to extract whatever exists in this memory region and compare it with the legit lsass.exe.<br />
<pre><span style="font-size: 78%;"><span style="font-family: courier new;">$ <span style="font-weight: bold;">./vol.py procexedump -p 680,868,1928 -D out </span></span>
<span style="font-family: courier new;">Volatile Systems Volatility Framework 2.0</span>
<span style="font-family: courier new;">************************************************************************</span>
<span style="font-family: courier new;">Dumping lsass.exe, pid: 680 output: executable.680.exe</span>
<span style="font-family: courier new;">************************************************************************</span>
<span style="font-family: courier new;">Dumping lsass.exe, pid: 868 output: executable.868.exe</span>
<span style="font-family: courier new;">************************************************************************</span>
<span style="font-family: courier new;">Dumping lsass.exe, pid: 1928 output: executable.1928.exe</span></span></pre>
Here are the strings (ANSI only) from the legit lsass.exe:<br />
<pre><span style="font-size: 78%;"><span style="font-family: courier new;">$ <span style="font-weight: bold;">strings out/executable.680.exe </span></span>
<span style="font-family: courier new;">!This program cannot be run in DOS mode.</span>
<span style="font-family: courier new;">Rich</span>
<span style="font-family: courier new;">.text</span>
<span style="font-family: courier new;">`.data</span>
<span style="font-family: courier new;">.rsrc</span>
<span style="font-family: courier new;">ADVAPI32.dll</span>
<span style="font-family: courier new;">KERNEL32.dll</span>
<span style="font-family: courier new;">NTDLL.DLL</span>
<span style="font-family: courier new;">LSASRV.dll</span>
<span style="font-family: courier new;">SAMSRV.dll</span></span></pre>
Here are the strings from one of the malicious lsass.exe:<br />
<pre><span style="font-size: 78%;"><span style="font-family: courier new;">$ <span style="font-weight: bold;">strings out/executable.868.exe </span></span>
<span style="font-family: courier new;">!This program cannot be run in DOS mode.</span>
<span style="font-family: courier new;">Rich</span>
<span style="font-family: courier new;">.verif</span>
<span style="font-family: courier new;">.text</span>
<span style="font-family: courier new;">.bin</span>
<span style="font-family: courier new;">.reloc</span><span style="font-family: courier new;"></span><span style="font-family: courier new;"></span>
<span style="color: red; font-family: courier new; font-weight: bold;">ZwMapViewOfSection</span> <span style="color: red; font-family: courier new; font-weight: bold;">
ZwCreateSection</span>
<span style="color: red; font-family: courier new; font-weight: bold;">ZwOpenFile</span> <span style="color: red; font-family: courier new; font-weight: bold;">
ZwClose</span>
<span style="color: red; font-family: courier new; font-weight: bold;">ZwQueryAttributesFile</span>
<span style="color: red; font-family: courier new; font-weight: bold;">ZwQuerySection</span>
<span style="font-family: courier new;">TerminateProcess</span>
<span style="font-family: courier new;">GetCurrentProcess</span>
<span style="font-family: courier new;">CloseHandle</span>
<span style="font-family: courier new;">WaitForSingleObject</span>
<span style="font-family: courier new;">OpenProcess</span>
<span style="font-family: courier new;">ExitProcess</span>
<span style="font-family: courier new;">CreateThread</span>
<span style="font-family: courier new;">SetUnhandledExceptionFilter</span>
<span style="font-family: courier new;">SetErrorMode</span>
<span style="font-family: courier new;">KERNEL32.dll</span>
<span style="font-family: courier new;">AdjustTokenPrivileges</span>
<span style="font-family: courier new;">LookupPrivilegeValueW</span>
<span style="font-family: courier new;">OpenProcessToken</span>
<span style="font-family: courier new;">ADVAPI32.dll</span>
<span style="font-family: courier new;">VirtualProtect</span>
<span style="font-family: courier new;">GetModuleHandleW</span>
<span style="font-family: courier new;">GetCurrentThreadId</span>
<span style="font-family: courier new;">GetTickCount</span>
<span style="font-family: courier new;">lstrcpyW</span>
<span style="font-family: courier new;">lstrlenW</span>
<span style="font-family: courier new;">GetProcAddress</span>
<span style="font-family: courier new;">wsprintfW</span>
<span style="font-family: courier new;">USER32.dll</span></span></pre>
As you can see, the content of the alleged lsass.exe binary is clearly different. This is in fact the effect of process hollowing - the second type of code injection used by Stuxnet. The names of the APIs in red are the ones hooked by the malware (see Artifact 6) and the others are probably from the file's Import Address Table.<br />
<br />
Lastly, the PE at 0x00870000 named KERNEL32.DLL.ASLR.0360b7ab also is not backed by a file on disk, but its in all 3 DLL lists. That's because this is the "hidden" DLL that is never written to disk (an attempt to evade antivirus). That is the third type of code injection / DLL hiding implemented by Stuxnet.<br />
<br />
<span style="color: #3333ff;"><span style="font-size: 180%;"><span style="color: black;">Artifact 6: Hooked APIs</span></span></span><span style="color: #3333ff;"><br /></span><br />
<blockquote>
<span style="color: #3333ff;">"The functions hooked for this purpose in Ntdll.dll are:</span><br />
<br />
<span style="color: #3333ff;">* ZwMapViewOfSection</span><br />
<span style="color: #3333ff;">* ZwCreateSection</span><br />
<span style="color: #3333ff;">* ZwOpenFile</span><br />
<span style="color: #3333ff;">* ZwCloseFile</span><br />
<span style="color: #3333ff;">* ZwQueryAttributesFile</span><br />
<span style="color: #3333ff;">* ZwQuerySection" [4]</span></blockquote>
Based on this statement, you can use the <a href="http://code.google.com/p/volatility/wiki/CommandReference#apihooks">apihooks</a> plugin to detect what Symantec is describing.<br />
<pre><span style="font-size: 78%;"><span style="font-family: courier new;">$ <span style="font-weight: bold;">./vol.py apihooks </span></span>
<span style="font-family: courier new;">Volatile Systems Volatility Framework 2.0</span>
<span style="font-family: courier new;">Name Type Target Value</span><span style="font-family: courier new;">
services.exe[668] syscall ntdll.dll!NtClose[0x7c90cfd0] 0x7c900050 MOV EDX, 0x7c900050 (UNKNOWN)
services.exe[668] syscall ntdll.dll!NtCreateSection[0x7c90d160] 0x7c900048 MOV EDX, 0x7c900048 (UNKNOWN)
services.exe[668] syscall ntdll.dll!NtMapViewOfSection[0x7c90d500] 0x7c900044 MOV EDX, 0x7c900044 (UNKNOWN)
services.exe[668] syscall ntdll.dll!NtOpenFile[0x7c90d580] 0x7c90004c MOV EDX, 0x7c90004c (UNKNOWN)
services.exe[668] syscall ntdll.dll!NtQueryAttributesFile[0x7c90d6f0] 0x7c900054 MOV EDX, 0x7c900054 (UNKNOWN)
services.exe[668] syscall ntdll.dll!NtQuerySection[0x7c90d8b0] 0x7c900058 MOV EDX, 0x7c900058 (UNKNOWN)
services.exe[668] syscall ntdll.dll!ZwClose[0x7c90cfd0] 0x7c900050 MOV EDX, 0x7c900050 (UNKNOWN)
services.exe[668] syscall ntdll.dll!ZwCreateSection[0x7c90d160] 0x7c900048 MOV EDX, 0x7c900048 (UNKNOWN)
services.exe[668] syscall ntdll.dll!ZwMapViewOfSection[0x7c90d500] 0x7c900044 MOV EDX, 0x7c900044 (UNKNOWN)
services.exe[668] syscall ntdll.dll!ZwOpenFile[0x7c90d580] 0x7c90004c MOV EDX, 0x7c90004c (UNKNOWN)
services.exe[668] syscall ntdll.dll!ZwQueryAttributesFile[0x7c90d6f0] 0x7c900054 MOV EDX, 0x7c900054 (UNKNOWN)
services.exe[668] syscall ntdll.dll!ZwQuerySection[0x7c90d8b0] 0x7c900058 MOV EDX, 0x7c900058 (UNKNOWN)</span>
<span style="font-family: courier new;">[snip]</span></span></pre>
If there are 6 hooked APIs, why are there 12 lines of output? Since Ntdll.dll exports each function twice (one for Nt* and one for Zw*), the apihooks plugin shows them both. Also, it is apparent that Stuxnet uses the "syscall" hooking technique similar to <a href="http://www.honeynet.org/node/578">Carberp</a> instead of the more common Inline/IAT/EAT hooking. To interactively explore code around the hook address, use the <a href="http://code.google.com/p/volatility/wiki/CommandReference#volshell">volshell</a> command. This time we'll use it to follow the flow of execution when a hooked API is called.<br />
<br />
First you need to break into the shell and switch into the context of a process that has been hooked. Then navigate to the hooked API. I'll start with ZwClose which is at 0x7C90cfd0.<br />
<pre><span style="font-size: 78%;"><span style="font-family: courier new;">$ <span style="font-weight: bold;">./vol.py volshell</span>
Volatile Systems Volatility Framework 2.0
Current context: process System, pid=4, ppid=0 DTB=0x319000
Welcome to volshell! Current memory image is:
file:///memory/stuxnet.vmem
To get help, type 'hh()'
>>> <span style="font-weight: bold;">cc(pid=668)</span>
Current context: process services.exe, pid=668, ppid=624 DTB=0xa940080
>>> <span style="font-weight: bold;">dis(0x7c90cfd0)</span></span>
<span style="color: red; font-family: courier new; font-weight: bold;">0x7c90cfd0 b819000000 MOV EAX, 0x19</span>
<span style="color: red; font-family: courier new; font-weight: bold;">0x7c90cfd5 ba5000907c MOV EDX, 0x7c900050</span>
<span style="color: red; font-family: courier new; font-weight: bold;">0x7c90cfda ffd2 CALL EDX</span>
<span style="color: red; font-family: courier new; font-weight: bold;">0x7c90cfdc c20400 RET 0x4</span>
<span style="font-family: courier new;">0x7c90cfdf 90 NOP</span>
<span style="color: #993399; font-family: courier new; font-weight: bold;">0x7c90cfe0 b81a000000 MOV EAX, 0x1a</span>
<span style="color: #993399; font-family: courier new; font-weight: bold;">0x7c90cfe5 ba0003fe7f MOV EDX, 0x7ffe0300</span>
<span style="color: #993399; font-family: courier new; font-weight: bold;">0x7c90cfea ff12 CALL DWORD [EDX]</span>
<span style="color: #993399; font-family: courier new; font-weight: bold;">0x7c90cfec c20c00 RET 0xc</span>
<span style="color: black; font-family: courier new;">0x7c90cfef 90 NOP</span>
<span style="font-family: courier new;">[snip]</span></span></pre>
When comparing the instructions in red (which belong to ZwClose) with the instructions in purple (which belong to an API not hooked by Stuxnet, you see that a different value is placed in EDX. The clean API calls the DWORD at 0x7ffe0300 (see <a href="http://www.nynaeve.net/?p=48">the system call dispatcher on x86</a>). The hooked API calls 0x7c900050. So that is our next hop when following the rootkit, and what we see next will be interesting.<br />
<pre><span style="font-size: 78%;"><span style="font-family: courier new;">>>> <span style="font-weight: bold;">dis(0x7c900050)</span></span>
<span style="font-family: courier new;">0x7c900050 b203 MOV DL, 0x3</span>
<span style="font-family: courier new;">0x7c900052 eb08 JMP 0x7c90005c</span>
<span style="font-family: courier new;">0x7c900054 b204 MOV DL, 0x4</span>
<span style="font-family: courier new;">0x7c900056 eb04 JMP 0x7c90005c</span>
<span style="font-family: courier new;">0x7c900058 b205 MOV DL, 0x5</span>
<span style="font-family: courier new;">0x7c90005a eb00 JMP 0x7c90005c</span>
<span style="font-family: courier new;">0x7c90005c 52 PUSH EDX</span>
<span style="font-family: courier new;">0x7c90005d e804000000 CALL 0x7c900066</span>
<span style="font-family: courier new;">0x7c900062 <span style="color: red; font-weight: bold;">f2009400</span>5aff2269 ADD [EAX+EAX+0x6922ff5a], DL</span>
<span style="font-family: courier new;">0x7c90006a 6e OUTS DX, [ESI]</span>
<span style="font-family: courier new;">0x7c90006b 20444f53 AND [EDI+ECX*2+0x53], AL</span>
<span style="font-family: courier new;">0x7c90006f 206d6f AND [EBP+0x6f], CH</span>
<span style="font-family: courier new;">0x7c900072 64652e0d0d0a2400 OR EAX, 0x240a0d</span>
<span style="font-family: courier new;">0x7c90007a 0000 ADD [EAX], AL</span>
<span style="font-family: courier new;">0x7c90007c 0000 ADD [EAX], AL</span>
<span style="font-family: courier new;">0x7c90007e 0000 ADD [EAX], AL</span></span></pre>
At 0x7c90005d there is a CALL to 0x7c900066. But according to the disassembly, 0x7c900066 is in the middle of the instruction that starts at 0x7c900062. Its possible that this is an anti-disassembling trick (see the Anti-Disassembling section of <a href="http://dvlabs.tippingpoint.com/blog/2008/08/07/mindshare-anti-reversing-techniques">MindshaRE: Anti-Reversing Techniques</a>) but either way, all we have to do is re-align the disassembly engine by telling it to start at 0x7c900066.<br />
<pre><span style="font-size: 78%;"><span style="font-family: courier new;">>>> <span style="font-weight: bold;">dis(0x7c900066)</span></span>
<span style="font-family: courier new;">0x7c900066 5a POP EDX</span>
<span style="font-family: courier new;">0x7c900067 ff22 JMP DWORD [EDX]</span></span></pre>
Ah, that's better! So when the CALL at 0x7c90005d is executed, its return address (0x7c900062) is pushed onto the stack. The POP EDX instruction at 0x7c900066 then removes that value from the stack and places it in EDX. At 0x7c900067, EDX is dereferenced and called. So the pointer being dereferenced is 0x7c900062. The 4 bytes at that address are highlighted in red above - f2009400. Given endiannes, this is actually 0x009400F2 - our official next hop in following the rootkit.<br />
<pre><span style="font-family: courier new; font-size: 78%;">>>> <span style="font-weight: bold;">dis(0x009400F2)</span>
0x9400f2 5a POP EDX
0x9400f3 84d2 TEST DL, DL
0x9400f5 7425 JZ 0x94011c
0x9400f7 feca DEC DL
0x9400f9 0f8482000000 JZ 0x940181
0x9400ff feca DEC DL
0x940101 0f84bb000000 JZ 0x9401c2
0x940107 feca DEC DL
0x940109 0f84fe000000 JZ 0x94020d
0x94010f feca DEC DL
0x940111 0f8440010000 JZ 0x940257
0x940117 e98c010000 JMP 0x9402a8
0x94011c e8f9010000 CALL 0x94031a</span>
<span style="font-size: 78%;"><span style="font-family: courier new;">[snip]
<span style="color: red; font-weight: bold;">0x9401ad 8d542408 LEA EDX, [ESP+0x8]</span>
<span style="color: red; font-weight: bold;">0x9401b1 cd2e INT 0x2e</span></span></span></pre>
By analyzing the code at this location, you can begin to understand the exact purpose of the hook. However, from Artifact 5 we already know the purpose is to support loading DLLs that don't exist on disk.<br />
<br />
The instructions in red show how the malware eventually calls the requested system service. It uses the IDT instead of the SSDT. Although Windows itself doesn't use the IDT for system service dispatching anymore (that stopped with Windows 2000), the IDT was still kept around for backward capability. This begs the question...are any other DLLs on my system still using the IDT? How unique is the byte pattern for the instructions in red?<br />
<br />
To find out, you can search process memory for 8D 54 24 ?? CD 2E where ?? is a wildcard. In the output below, two memory regions tested positive. 0x00940000 shouldn't be surprising since that's the source of our signature. But 0x013F0000 also contains the pattern.<br />
<pre><span style="font-size: 78%;"><span style="font-family: courier new;">$ <span style="font-weight: bold;">./vol.py malfind -p 668 -D out -Y "{8D 54 24 ?? CD 2E}" </span></span>
<span style="font-family: courier new;">Volatile Systems Volatility Framework 2.0</span>
<span style="font-family: courier new;">Name Pid Start End Tag Hits Protect</span>
<span style="color: red; font-family: courier new; font-weight: bold;">services.exe 668 0x00940000 0x00940FFF Vad 1 6 (MM_EXECUTE_READWRITE)</span>
<span style="font-family: courier new;">Dumped to: out/services.exe.2273020.00940000-00940fff.dmp</span>
<span style="font-family: courier new;">YARA rule: z1</span>
<span style="font-family: courier new;">Hit: 8d542408cd2e</span>
<span style="font-family: courier new;"><span style="color: red; font-weight: bold;">0x00940145</span> 8d 54 24 08 cd 2e eb 0c 5a 8d 54 24 08 64 ff 15 .T$.....Z.T$.d..</span>
<span style="font-family: courier new;">0x00940155 c0 00 00 00 85 c0 75 23 e8 b8 01 00 00 85 d2 74 ......u#.......t</span>
<span style="font-family: courier new;">Hit: 8d542408cd2e</span>
<span style="font-family: courier new;"><span style="color: red; font-weight: bold;">0x009401ad</span> 8d 54 24 08 cd 2e eb 0c 5a 8d 54 24 08 64 ff 15 .T$.....Z.T$.d..</span>
<span style="font-family: courier new;">0x009401bd c0 00 00 00 c3 e8 53 01 00 00 85 d2 74 20 50 57 ......S.....t PW</span>
<span style="font-family: courier new;">Hit: 8d542408cd2e</span>
<span style="font-family: courier new;"><span style="color: red; font-weight: bold;">0x009401f8</span> 8d 54 24 08 cd 2e eb 0c 5a 8d 54 24 08 64 ff 15 .T$.....Z.T$.d..</span>
<span style="font-family: courier new;">0x00940208 c0 00 00 00 c3 81 7c 24 08 ae 82 19 ae 75 03 33 ......|$.....u.3</span>
<span style="font-family: courier new;">Hit: 8d542408cd2e</span>
<span style="font-family: courier new;"><span style="color: red; font-weight: bold;">0x00940242</span> 8d 54 24 08 cd 2e eb 0c 5a 8d 54 24 08 64 ff 15 .T$.....Z.T$.d..</span>
<span style="font-family: courier new;">0x00940252 c0 00 00 00 c3 e8 be 00 00 00 85 d2 74 26 50 52 ............t&PR</span>
<span style="font-family: courier new;">Hit: 8d542408cd2e</span>
<span style="font-family: courier new;"><span style="color: red; font-weight: bold;">0x00940293</span> 8d 54 24 08 cd 2e eb 0c 5a 8d 54 24 08 64 ff 15 .T$.....Z.T$.d..</span>
<span style="font-family: courier new;">0x009402a3 c0 00 00 00 c3 e8 6d 00 00 00 85 d2 52 74 45 8b ......m.....RtE.</span>
<span style="font-family: courier new;">Hit: 8d542408cd2e</span>
<span style="font-family: courier new;"><span style="color: red; font-weight: bold;">0x00940305</span> 8d 54 24 08 cd 2e eb 0c 5a 8d 54 24 08 64 ff 15 .T$.....Z.T$.d..</span>
<span style="font-family: courier new;">0x00940315 c0 00 00 00 c3 50 56 57 51 52 83 ec 1c 8b c4 6a .....PVWQR.....j</span>
<span style="color: red; font-family: courier new; font-weight: bold;">services.exe 668 0x013F0000 0x01527FFF Vad 1 6 (MM_EXECUTE_READWRITE)</span>
<span style="font-family: courier new;">Dumped to: out/services.exe.2273020.013f0000-01527fff.dmp</span>
<span style="font-family: courier new;">YARA rule: z1</span>
<span style="font-family: courier new;">Hit: 8d542408cd2e</span>
<span style="font-family: courier new;"><span style="color: red; font-weight: bold;">0x0144782e</span> 8d 54 24 08 cd 2e eb 0c 5a 8d 54 24 08 64 ff 15 .T$.....Z.T$.d..</span>
<span style="font-family: courier new;">0x0144783e c0 00 00 00 85 c0 75 23 e8 b8 01 00 00 85 d2 74 ......u#.......t</span>
<span style="font-family: courier new;">Hit: 8d542408cd2e</span>
<span style="font-family: courier new;"><span style="color: red; font-weight: bold;">0x01447896</span> 8d 54 24 08 cd 2e eb 0c 5a 8d 54 24 08 64 ff 15 .T$.....Z.T$.d..</span>
<span style="font-family: courier new;">0x014478a6 c0 00 00 00 c3 e8 53 01 00 00 85 d2 74 20 50 57 ......S.....t PW</span>
<span style="font-family: courier new;">Hit: 8d542408cd2e</span>
<span style="font-family: courier new;"><span style="color: red; font-weight: bold;">0x014478e1</span> 8d 54 24 08 cd 2e eb 0c 5a 8d 54 24 08 64 ff 15 .T$.....Z.T$.d..</span>
<span style="font-family: courier new;">0x014478f1 c0 00 00 00 c3 81 7c 24 08 ae 82 19 ae 75 03 33 ......|$.....u.3</span>
<span style="font-family: courier new;">Hit: 8d542408cd2e</span>
<span style="font-family: courier new;"><span style="color: red; font-weight: bold;">0x0144792b</span> 8d 54 24 08 cd 2e eb 0c 5a 8d 54 24 08 64 ff 15 .T$.....Z.T$.d..</span>
<span style="font-family: courier new;">0x0144793b c0 00 00 00 c3 e8 be 00 00 00 85 d2 74 26 50 52 ............t&PR</span>
<span style="font-family: courier new;">Hit: 8d542408cd2e</span>
<span style="font-family: courier new;"><span style="color: red; font-weight: bold;">0x0144797c</span> 8d 54 24 08 cd 2e eb 0c 5a 8d 54 24 08 64 ff 15 .T$.....Z.T$.d..</span>
<span style="font-family: courier new;">0x0144798c c0 00 00 00 c3 e8 6d 00 00 00 85 d2 52 74 45 8b ......m.....RtE.</span>
<span style="font-family: courier new;">Hit: 8d542408cd2e</span>
<span style="font-family: courier new;"><span style="color: red; font-weight: bold;">0x014479ee</span> 8d 54 24 08 cd 2e eb 0c 5a 8d 54 24 08 64 ff 15 .T$.....Z.T$.d..</span>
<span style="font-family: courier new;">0x014479fe c0 00 00 00 c3 50 56 57 51 52 83 ec 1c 8b c4 6a .....PVWQR.....j</span></span></pre>
As you can see, both memory regions have 6 hits, which coincides with the 6 hooked APIs. But why are there two memory regions in the first place? Well, just guessing here but based on the relative size (140KB to 1KB), the 0x013F0000 region contains the code responsible for installing the API hooks. It allocated and copied a smaller 1KB chunk of itself to 0x00940000.<br />
<br />
<span style="color: #3333ff;"><span style="font-size: 180%;"><span style="color: black;">Artifact 7: Patched PE Header</span></span></span><br />
<blockquote style="color: #3333ff;">
"To hook the functions specified above, the malware allocates a memory buffer for code that will dispatch calls to hooked functions, overwrite some data in MZ header of the image with the code that transfers control to the new functions, and hook the original functions by overwriting its bodies..." [6]</blockquote>
In the previous artifact you might remember us tracking an address at 0x7c900050. If ntdll.dll's base is 0x7c900000, then the address we're tracking is in the PE header. In order to hide code in ntdll.dll's PE header without breaking anything, Stuxnet overwrites some inconsequential fields including most of the "This program cannot be run in DOS mode" message.<br />
<br />
To detect the malicious PE header modification, you can use the following yara rule which alerts on any pages of memory that contain a PE header and that do not contain the "This program cannot..." message. The rule was saved to modified_pe_header.yar.<br />
<pre><span style="font-size: 78%;"><span style="font-family: courier new;">rule modified_pe_header { </span>
<span style="font-family: courier new;"> strings:</span>
<span style="font-family: courier new;"> $msg = "This program cannot"</span>
<span style="font-family: courier new;"> condition:</span>
<span style="font-family: courier new;"> uint16(0) == 0x5A4D and </span>
<span style="font-family: courier new;"> uint32(uint32(0x3C)) == 0x00004550 and</span>
<span style="font-family: courier new;"> not $msg</span>
<span style="font-family: courier new;">}</span></span></pre>
Now scan for the memory with malfind:<br />
<pre><span style="font-size: 78%;"><span style="font-family: courier new;">$ <span style="font-weight: bold;">./vol.py malfind -D out -Y modified_pe_header.yar </span></span>
<span style="font-family: courier new;">Volatile Systems Volatility Framework 2.0</span>
<span style="font-family: courier new;">Name Pid Start End Tag Hits Protect</span>
<span style="font-family: courier new;"><span style="color: red; font-weight: bold;">services.exe 668</span> <span style="color: red; font-weight: bold;">0x7C900000</span> 0x7C9AEFFF Vad 1 7 (MM_EXECUTE_WRITECOPY)</span>
<span style="font-family: courier new;">Dumped to: out/services.exe.2273020.7c900000-7c9aefff.dmp</span>
<span style="font-family: courier new;">YARA rule: modified_pe_header</span>
<span style="font-family: courier new;"><span style="color: red; font-weight: bold;">svchost.exe 940 0x7C900000</span> 0x7C9AEFFF Vad 1 7 (MM_EXECUTE_WRITECOPY)</span>
<span style="font-family: courier new;">Dumped to: out/svchost.exe.2061da0.7c900000-7c9aefff.dmp</span>
<span style="font-family: courier new;">YARA rule: modified_pe_header</span>
<span style="font-family: courier new;"><span style="color: red; font-weight: bold;">lsass.exe 1928 0x7C900000</span> 0x7C9AEFFF Vad 1 7 (MM_EXECUTE_WRITECOPY)</span>
<span style="font-family: courier new;">Dumped to: out/lsass.exe.1e47c00.7c900000-7c9aefff.dmp</span>
<span style="font-family: courier new;">YARA rule: modified_pe_header</span></span></pre>
The results tell you Stuxnet has modified ntdll.dll in three processes.<br />
<br />
<span style="font-size: 180%;">Artifact 8: Mutexes</span><br />
<br />
<span style="color: #3333ff;">"Stuxnet communicates between different components via global mutexes." [4]</span><br />
<br />
Based on this statement, you can use the <a href="http://code.google.com/p/volatility/wiki/CommandReference#mutantscan">mutantscan</a> and/or <a href="http://code.google.com/p/volatility/wiki/CommandReference#handles">handles</a> plugins to list mutexes on the system. However, resources indicate that the mutex name can be random (or at least pseudo-random). Without doing the necessary RE to see if there are any detectable patterns in the mutex name, we don't really know what to look for. So how do we find out which mutexes on the system are artifacts of Stuxnet?<br />
<br />
Since Stuxnet injects code into services.exe (based on previous findings), there is a good chance that services.exe has an open handle to the mutex, or mutexes. Let's use the handles plugin to filter by object type (Mutant) and process ID, also ignoring un-named mutexes:<br />
<pre><span style="font-size: 78%;"><span style="font-family: courier new;">$ <span style="font-weight: bold;">./vol.py handles -t Mutant -p 668</span>
Volatile Systems Volatility Framework 2.0
Offset(V) Pid Type Details
0x81ee3968 668 Mutant 'SHIMLIB_LOG_MUTEX'
0x81db23b0 668 Mutant 'ShimCacheMutex'
0x8205fa78 668 Mutant 'PnP_Init_Mutex'
<span style="color: red; font-weight: bold;">0x81fc3cc0 668 Mutant '{5EC171BB-F130-4a19-B782-B6E655E091B2}'</span>
<span style="color: red; font-weight: bold;">0x821b75e0 668 Mutant '{E41362C3-F75C-4ec2-AF49-3CB6BCA591CA}'</span>
<span style="color: red; font-weight: bold;">0x81f08b98 668 Mutant 'PrefetchFileCacheOwner'</span>
0x81f78e90 668 Mutant 'Spooler_Perf_Library_Lock_PID_01F'
0x82287600 668 Mutant '85991EC7-5621-4A6F-9453-DC19BAE9C542'
0x82287600 668 Mutant '85991EC7-5621-4A6F-9453-DC19BAE9C542'</span></span></pre>
I've highlighted three of the Stuxnet artifacts in red. But at this point, pretend you still don't know. One advantage of using mutantscan is that it prints the <a href="http://code.google.com/p/volatility/source/browse/trunk/volatility/plugins/overlays/windows/win7_sp0_x86_vtypes.py#5433">OwnerThread member of each _KMUTANT</a> (if its available). Here is some output to help drive this point home:<br />
<pre><span style="font-size: 78%;"><span style="font-family: courier new;">$ <span style="font-weight: bold;">./vol.py mutantscan -s </span>
Volatile Systems Volatility Framework 2.0
Offset Obj Type #Ptr #Hnd Signal Thread CID Name
0x01e4dbe0 0x823c55e0 2 1 1 0x00000000 '_!SHMSFTHISTORY!_'
0x01e8ab88 0x823c55e0 3 2 1 0x00000000 'c:!documents and settings!administrator!cookies!'
<span style="color: red; font-weight: bold;">0x02108bb0 0x823c55e0 2 1 0 0x81fc0020 668:568 'PrefetchFileCacheOwner'</span>
<span style="color: red; font-weight: bold;">0x021c3cd8 0x823c55e0 4 3 1 0x00000000 '{5EC171BB-F130-4a19-B782-B6E655E091B2}'</span>
<span style="color: red; font-weight: bold;">0x023b75f8 0x823c55e0 2 1 0 0x81c6d180 668:476 '{E41362C3-F75C-4ec2-AF49-3CB6BCA591CA}'</span>
0x0240f300 0x823c55e0 2 1 1 0x00000000 'WPA_LT_MUTEX'
0x0240f350 0x823c55e0 2 1 1 0x00000000 'WPA_RT_MUTEX'
0x0241ef40 0x823c55e0 2 1 1 0x00000000 '.NET CLR Data_Perf_Library_Lock_PID_680'
0x0242d248 0x823c55e0 2 1 0 0x8210d200 1712:1716 'SunJavaUpdateSchedulerMutex'
[snip]</span></span></pre>
Now we know that thread ID 568 owns the PrefetchFileCacheOwner mutex and thread ID 476 owns the one that starts with "{E41362C3". Windows doesn't track creation time for mutex objects, but it does for thread objects. Let's see when the owning threads were created using the <a href="http://code.google.com/p/volatility/wiki/CommandReference#thrdscan">thrdscan</a> command:<br />
<pre><span style="font-size: 78%;"><span style="font-family: courier new;">$ <span style="font-weight: bold;">./vol.py thrdscan</span>
Volatile Systems Volatility Framework 2.0
Offset PID TID Create Time Exit Time StartAddr
---------- ------ ------ ------------------------- ------------------------- ----------
0x021c0020 668 568 <span style="color: red; font-weight: bold;">2011-06-03 04:26:55</span> 0x7c8106e9
0x01e6d180 668 476 <span style="color: red; font-weight: bold;">2011-06-03 04:26:55</span> 0x7c8106e9
[snip]</span></span></pre>
Both threads were created at 04:26:55. The two malicious lsass.exe processes discussed in Artifact 1 were also created at 04:26:55. Now we have a direct temporal relationship between the times when Stuxnet spawned the lsass.exe processes, when it injected code into services.exe (resulting in several new threads), and when the mutexes were created.<br />
<br />
A few things should be noted. The PrefetchFileCacheOwner is probably not one of the "global mutexes used for communication" - it is one of the side-effects of some action performed by the thread. Second, to confirm my findings, I infected the system with Stuxnet again, this time with a breakpoint set on CreateMutexW inside the services.exe process. Before long, the breakpoint triggered twice:<br />
<br />
<a href="https://blogger.googleusercontent.com/img/b/R29vZ2xl/AVvXsEjpepUyFSv13YtbDTPJOsSql_KK2a-eIqRzvU0JtgFYCbTZhp9j0n8l7YX3XkUCPiwKbAIBdqv9ntOInAhbuZRff_ytb-M8ibWPKAR4TjPAwz71Kqu6Aj-nlhGAKD9iYc_u_2TeiGWTWYhF/s1600/globalmutexsvc.png"><img alt="" border="0" id="BLOGGER_PHOTO_ID_5630939832148706530" src="https://blogger.googleusercontent.com/img/b/R29vZ2xl/AVvXsEjpepUyFSv13YtbDTPJOsSql_KK2a-eIqRzvU0JtgFYCbTZhp9j0n8l7YX3XkUCPiwKbAIBdqv9ntOInAhbuZRff_ytb-M8ibWPKAR4TjPAwz71Kqu6Aj-nlhGAKD9iYc_u_2TeiGWTWYhF/s320/globalmutexsvc.png" style="cursor: pointer; display: block; height: 158px; margin: 0px auto 10px; text-align: center; width: 320px;" /></a><br />
<a href="https://blogger.googleusercontent.com/img/b/R29vZ2xl/AVvXsEhHgset9oytSDw8q7dUg9BE6EnYUWBSGH4BNLjO7s98Iju5ACuhG3ixdTjxdQXUqPGTb5qjLO8TetuAdhP7A-EF_ohNqRDdaDV9Bj1APjdk18Jm3O2mW3e2jqMlxsSmbYZwa9Ubi2wK0CE-/s1600/globalmutexsvc2.png"><img alt="" border="0" id="BLOGGER_PHOTO_ID_5631091485321967394" src="https://blogger.googleusercontent.com/img/b/R29vZ2xl/AVvXsEhHgset9oytSDw8q7dUg9BE6EnYUWBSGH4BNLjO7s98Iju5ACuhG3ixdTjxdQXUqPGTb5qjLO8TetuAdhP7A-EF_ohNqRDdaDV9Bj1APjdk18Jm3O2mW3e2jqMlxsSmbYZwa9Ubi2wK0CE-/s320/globalmutexsvc2.png" style="cursor: pointer; display: block; height: 158px; margin: 0px auto 10px; text-align: center; width: 320px;" /></a><br />
That's a wrap for this one!<br />
<br />
<span style="color: #3333ff;"><span style="font-size: 180%;"><span style="color: black;">Artifact 9: File Objects</span></span></span><br />
<blockquote>
<span style="color: #3333ff;">"The final modifications made by the virus include the creation of four additional files in the C:\Windows\Inf directory: Oem7a.pnf, Mdmeric3.pnf, Mdmcpq3.pnf and Oem6c.pnf." [2] </span></blockquote>
Based on this statement, you can use the <a href="http://code.google.com/p/volatility/wiki/CommandReference#handles">handles</a> command to see if any processes currently have open handles to the specified files, or you can use <a href="http://code.google.com/p/volatility/wiki/CommandReference#filescan">filescan</a> to see if any FILE_OBJECT structures still reside in memory after the malware created them.<br />
<pre><span style="font-size: 78%;"><span style="font-family: courier new;">$ <span style="font-weight: bold;">./vol.py handles | grep -i .pnf</span></span>
<span style="font-family: courier new;">Volatile Systems Volatility Framework 2.0</span>
<span style="font-family: courier new;">$</span></span>
<span style="font-size: 78%;"><span style="font-family: courier new;">
$<span style="font-weight: bold;"> ./vol.py filescan | grep -i .pnf</span></span>
<span style="font-family: courier new;">Volatile Systems Volatility Framework 2.0</span>
<span style="font-family: courier new;">0x01dfa028 0x0x823eb040 1 0 R--r-- - '\\WINDOWS\\inf\\oem7A.PNF'</span>
<span style="font-family: courier new;">0x01e0d028 0x0x823eb040 1 0 -WD--- - '\\WINDOWS\\inf\\mdmeric3.PNF'</span>
<span style="font-family: courier new;">0x021b53c8 0x0x823eb040 1 0 RW---- - '\\WINDOWS\\inf\\mdmcpq3.PNF'</span></span></pre>
As you can see, the output of the handles command is empty. Either the process that created the PNF files has terminated, or the process has already called <a href="http://msdn.microsoft.com/en-us/library/ms724211%28v=vs.85%29.aspx">CloseHandle</a>. However, filescan can still locate traces of the activity, which is the whole reason filescan exists in the first place. Kudos to filescan!<br />
<br />
<span style="font-size: 180%;">Artifact 10: Network Connections</span><br />
<blockquote style="color: #3333ff;">
"This function [export #28] is responsible for performing actual data exchange with the C&C server. In the event that there is no iexplore.exe in the system, it calls this function from the address space of the default browser: it starts the default browser as a new process, injects into it the main module, and calls the function performing data exchange.<br />
<br />
The malware communicates to the C&C server through http. A list of URLs is included in the Stuxnet configuration data of Stuxnet:<br />
<ul>
<li>www.mypremierfutbol.com</li>
<li>www.todaysfutbol.com" [6]</li>
</ul>
</blockquote>
This artifact was not present in the initial memory dump. Export #28 (the function referred to in the quote) wasn't called for one reason or another. To elicit the described behavior, I dumped memory a second time, after manually coercing the execution of Export #28. Then using connscan (one of the <a href="http://code.google.com/p/volatility/wiki/CommandReference#Networking">Networking</a> commands) you can see the evidence:<br />
<pre><span style="font-size: 78%;"><span style="font-family: courier new;">$ <span style="font-weight: bold;">./vol.py -f stuxnet2.vmem connscan </span>
Volatile Systems Volatility Framework 2.0
Offset Local Address Remote Address Pid
---------- ------------------------- ------------------------- ------
0x01da9e68 192.168.16.129:1311 128.61.111.9:51442 1280
0x01e4fe68 192.168.16.129:1233 128.61.111.9:21 1280
<span style="color: red; font-weight: bold;">0x01eeebf0 172.16.237.145:1170 72.167.202.5:80 528</span>
0x020bf4e0 172.16.237.145:1045 96.17.106.99:80 1648
0x0242ec28 172.16.237.145:1048 96.17.106.99:80 1708
0x025069e8 172.16.237.145:1090 137.254.16.78:80 152</span></span><span style="font-size: 78%;"><span style="font-family: courier new;">
</span></span></pre>
The connection in red is suspicious because, as shown below, it was created by a browser process and the IP maps back to one of the C&C domains.<br />
<pre><span style="font-size: 78%;"><span style="font-family: courier new;">$<span style="font-weight: bold;"> ./vol.py -f stuxnet2.vmem pslist</span>
Volatile Systems Volatility Framework 2.0
Offset(V) Name PID PPID Thds Hnds Time
---------- -------------------- ------ ------ ------ ------ -------------------
[snip]
0x81af13b8 <span style="color: red; font-weight: bold;">firefox.exe</span> <span style="color: red; font-weight: bold;">528</span> 356 4 112 2011-07-20 16:32:09
$ <span style="font-weight: bold;">host www.mypremierfutbol.com</span>
www.mypremierfutbol.com is an alias for mypremierfutbol.com.
mypremierfutbol.com has address <span style="color: red; font-weight: bold;">72.167.202.5</span></span></span></pre>
Perhaps more interesting than the connection itself is the fact that Stuxnet uses a specific message structure for its C&C packets. Each message starts with a 0x1 constant byte and has the OS major version at offset 2, OS minor version at offset 3, OS service pack at offset 4, and so on. That means an XP SP1 system may look like hex "01??050101" and a Windows 7 SP0 may look like "01??060100". A bit more research can help refine these patters even more and before long you can have a Volatility plugin, consisting of a few lines of Python, that finds Stuxnet C&C packets (before encryption) in process memory.<br />
<br />
<span style="color: #3333ff;"><span style="font-size: 180%;"><span style="color: black;">Artifact 11: Registry Keys</span></span></span><br />
<blockquote>
<span style="color: #3333ff;">"...because we see Lsass.exe drop one of the two Stuxnet drivers, MRxCls.sys, in C:\Windows\System32\Drivers and create its corresponding registry keys" [2]</span></blockquote>
Based on this statement, we can use <a href="http://code.google.com/p/volatility/wiki/CommandReference#printkey">printkey</a> to read the cached registry keys in memory. Service registry keys are in the system hive under ControlSet001\Services\SERVICENAME. So based on the article, we know exactly what to look for:<br />
<pre><span style="font-size: 78%;"><span style="font-family: courier new;">$ <span style="font-weight: bold;">./vol.py printkey -K 'ControlSet001\Services\MrxNet'</span></span>
<span style="font-family: courier new;">Volatile Systems Volatility Framework 2.0</span>
<span style="font-family: courier new;">Legend: (S) = Stable (V) = Volatile</span>
<span style="font-family: courier new;">----------------------------</span>
<span style="font-family: courier new;">Registry: \Device\HarddiskVolume1\WINDOWS\system32\config\system</span>
<span style="font-family: courier new;">Key name: MRxNet (S)</span>
<span style="font-family: courier new;">Last updated: 2011-06-03 04:26:47 </span>
<span style="font-family: courier new;">Subkeys:</span>
<span style="font-family: courier new;"> (V) Enum</span>
<span style="font-family: courier new;">Values:</span>
<span style="font-family: courier new;">REG_SZ Description : (S) MRXNET</span>
<span style="font-family: courier new;">REG_SZ DisplayName : (S) MRXNET</span>
<span style="font-family: courier new;">REG_DWORD ErrorControl : (S) 0</span>
<span style="font-family: courier new;">REG_SZ Group : (S) Network</span>
<span style="font-family: courier new;">REG_SZ ImagePath : (S) <span style="color: red; font-weight: bold;">\??\C:\WINDOWS\system32\Drivers\mrxnet.sys</span></span>
<span style="font-family: courier new;">REG_DWORD Start : (S) 1</span>
<span style="font-family: courier new;">REG_DWORD Type : (S) 1</span>
<span style="font-family: courier new;">$ <span style="font-weight: bold;">./vol.py printkey -K 'ControlSet001\Services\MrxCls'</span></span>
<span style="font-family: courier new;">Volatile Systems Volatility Framework 2.0</span>
<span style="font-family: courier new;">Legend: (S) = Stable (V) = Volatile</span>
<span style="font-family: courier new;">----------------------------</span>
<span style="font-family: courier new;">Registry: </span></span><span style="font-size: 78%;"><span style="font-family: courier new;">\Device\HarddiskVolume1\WINDOWS\system32\config\system</span></span><span style="font-size: 78%;">
<span style="font-family: courier new;">Key name: MRxCls (S)</span>
<span style="font-family: courier new;">Last updated: 2011-06-03 04:26:47 </span>
<span style="font-family: courier new;">Subkeys:</span>
<span style="font-family: courier new;"> (V) Enum</span>
<span style="font-family: courier new;">Values:</span>
<span style="font-family: courier new;">REG_SZ Description : (S) MRXCLS</span>
<span style="font-family: courier new;">REG_SZ DisplayName : (S) MRXCLS</span>
<span style="font-family: courier new;">REG_DWORD ErrorControl : (S) 0</span>
<span style="font-family: courier new;">REG_SZ Group : (S) Network</span>
<span style="font-family: courier new;">REG_SZ ImagePath : (S) <span style="color: red; font-weight: bold;">\??\C:\WINDOWS\system32\Drivers\mrxcls.sys</span></span>
<span style="font-family: courier new;">REG_DWORD Start : (S) 1</span>
<span style="font-family: courier new;">REG_DWORD Type : (S) 1</span>
<span style="font-family: courier new;">REG_BINARY Data : (S) </span>
<span style="font-family: courier new;">0000 8F 1F F7 6D 7D B1 C9 09 9D CC 24 7A C6 9F FB 23 ...m}.....$z...#</span>
<span style="font-family: courier new;">0010 90 BD 9D BF F1 D4 51 92 2A B4 1F 6A 2E A6 4F B3 ......Q.*..j..O.</span>
<span style="font-family: courier new;">0020 CB 69 7C 0B 92 3B 1B C0 D7 75 17 A9 E3 33 48 DC .i|..;...u...3H.</span>
<span style="font-family: courier new;">0030 AD F6 DA EA 2F 87 10 C4 21 81 A5 75 68 00 2E B1 ..../...!..uh...</span>
<span style="font-family: courier new;">0040 C2 7B EB DD BB 72 47 DC 87 91 14 A5 F3 C4 32 B0 .{...rG.......2.</span>
<span style="font-family: courier new;">0050 CC 93 38 36 6B 49 0A F2 6F 1F 1D A1 4A 15 05 80 ..86kI..o...J...</span>
<span style="font-family: courier new;">0060 4B 13 A8 AA 82 41 4B 89 DC 89 24 A2 ED 16 37 F3 K....AK...$...7.</span>
<span style="font-family: courier new;">0070 42 A9 A0 6A 7F 82 CD 90 E5 3C 49 CC B2 97 CA CB B..j.....< span="">
<span style="font-family: courier new;">0080 7B 64 C1 48 B2 4C F5 AE 54 42 74 0F 00 31 FD 80 {d.H.L..TBt..1..</span>
<span style="font-family: courier new;">0090 E8 7E 0E 69 12 42 3A EC 0F 6F 03 B8 46 9C 68 97 .~.i.B:..o..F.h.</span>
<span style="font-family: courier new;">00A0 AC 62 16 FB 1A 1B D9 33 6C E8 F9 93 C3 56 54 A1 .b.....3l....VT.</span>
<span style="font-family: courier new;">00B0 89 7A 7B 77 CE BA 0D 95 A7 0F AB 5E 1C 3C 18 63 .z{w.......^.<.c</span>
<span style="font-family: courier new;">00C0 AE 3E 60 A6 81 BC FA 85 FB 37 A0 0A 57 F9 C9 D3 .>`......7..W...</span>
<span style="font-family: courier new;">00D0 CF 6B 41 D9 6D CD 39 71 C5 11 83 F1 D9 F3 7D B7 .kA.m.9q......}.</span>
<span style="font-family: courier new;">00E0 91 F7 70 46 C2 24 F7 B9 0F 2D B2 60 72 1C 8F F9 ..pF.$...-.`r...</span>
<span style="font-family: courier new;">00F0 98 16 34 52 4B 7D 5F 81 5F 35 FD 8B 3E 78 B1 0B ..4RK}_._5..>x..</span>
<span style="font-family: courier new;">0100 0A 90 5A D8 30 5A 56 90 9A C0 C1 0F EB 95 D5 2F ..Z.0ZV......../</span>
<span style="font-family: courier new;">0110 B7 C5 8D 2B 3F 49 41 8B 86 B4 DB 71 67 69 E6 E8 ...+?IA....qgi..</span>
<span style="font-family: courier new;">0120 69 77 29 77 18 82 11 8B D7 5D 26 E4 5A 5C 2C 46 iw)w.....]&.Z.,F</span>
<span style="font-family: courier new;">0130 C2 F0 02 28 D8 EA 4B 95 9C 3A 3C 12 DA C4 87 21 ...(..K..:<....!</span>
<span style="font-family: courier new;">0140 91 4F D0 6E FA C4 DD B7 C9 AF E2 AE FE 14 0F 53 .O.n...........S</span>
<span style="font-family: courier new;">0150 C4 BA DD 31 1A 38 7B 37 C0 9E 83 FF 2C B2 4C 88 ...1.8{7....,.L.</span>
<span style="font-family: courier new;">0160 33 C1 89 E5 CA 68 31 2D 20 CE 50 64 7B 39 C7 FB 3....h1- .Pd{9..</span>
<span style="font-family: courier new;">0170 B1 9F A9 0D 6C 2A 82 AE 7F 25 43 A7 A2 28 EB 27 ....l*...%C..(.'</span>
<span style="font-family: courier new;">0180 73 C9 45 F9 FD 53 A8 F4 A7 FD B4 90 B2 28 D8 0C s.E..S.......(..</span>
<span style="font-family: courier new;">0190 5A A8 84 D0 7F ED 99 25 18 FE B8 4C 48 66 8D 59 Z......%...LHf.Y</span>
<span style="font-family: courier new;">01A0 40 F6 CC 30 A6 F4 04 E8 76 9C EA 0E F6 A4 4A CE @..0....v.....J.</span>
<span style="font-family: courier new;">01B0 D2 .</span><></span></span></pre>
You can see the timestamp from when the registry keys were last modified, the full path on disk to the service binary (the Stuxnet drivers) and the full contents of the encrypted Data value. According to Thabet [5], after decryption <span style="color: #3333ff;">"This data contains the name of some system processes and filenames for stuxnet files. This data tells the driver the filename of the stuxnet file and the name of the process that stuxnet needs to inject its file into."</span><br />
<br />
Don't forget you can also use the <a href="http://code.google.com/p/volatility/wiki/CommandReference#svcscan">svcscan</a> command to enumerate services.<br />
<pre><span style="font-size: 78%;"><span style="font-family: courier new;">$ <span style="font-weight: bold;">./vol.py -f stuxnet.vmem svcscan | grep -i mrx</span></span>
<span style="font-family: courier new;">Volatile Systems Volatility Framework 2.0</span>
<span style="font-family: courier new;">0x385d28 0x70 -------- 'MRxDAV' 'WebDav Client Redirector' SERVICE_FILE_SYSTEM_DRIVER SERVICE_RUNNING \FileSystem\MRxDAV</span>
<span style="font-family: courier new;">0x385db8 0x71 -------- 'MRxSmb' 'MRxSmb' SERVICE_FILE_SYSTEM_DRIVER SERVICE_RUNNING \FileSystem\MRxSmb</span></span></pre>
Why do we only see legitimate services MRxDAV and MRxSmb? Well, just because there are entries in the ControlSet001\Services registry key, that doesn't mean the malware used the Service Control Manager (services.exe) to create or start the service. For example, you can skip calling <a href="http://msdn.microsoft.com/en-us/library/ms682450%28v=vs.85%29.aspx">CreateService</a> and <a href="http://msdn.microsoft.com/en-us/library/ms686321%28v=vs.85%29.aspx">StartService</a> by creating the registry keys directly and then calling <a href="http://msdn.microsoft.com/en-us/library/ff566470%28v=vs.85%29.aspx">NtLoadDriver</a> (which is exactly what Stuxnet does).<br />
<br />
<span style="font-size: 180%;"><span style="color: black;">Artifact 12: Kernel Drivers</span></span><br />
<blockquote style="color: black;">
<span style="color: #3333ff;">"Mrxnet.sys is the driver that the programmer originally sent me and that implements the rootkit that hides files, and Mrxcls.sys is a second Stuxnet driver file that launches the malware when the system boots." [1]</span></blockquote>
Based on this statement, the two drivers should be visible with the <a href="http://code.google.com/p/volatility/wiki/CommandReference#modules">modules</a> or <a href="http://code.google.com/p/volatility/wiki/CommandReference#modscan">modscan</a> commands.<br />
<pre><span style="font-size: 78%;"><span style="font-family: courier new;">$ <span style="font-weight: bold;">./vol.py modules</span></span>
<span style="font-family: courier new;">[snip]</span>
<span style="font-family: courier new;">0x81f8cb60 \??\C:\WINDOWS\system32\Drivers\mrxcls.sys 0x00f895a000 0x005000 mrxcls.sys</span>
<span style="font-family: courier new;">0x81c2a530 \??\C:\WINDOWS\system32\Drivers\mrxnet.sys 0x00b21d8000 0x003000 mrxnet.sys</span></span></pre>
Feel free to extract the drivers to disk with <a href="http://code.google.com/p/volatility/wiki/CommandReference#moddump">moddump</a> for inspection with strings, IDA Pro, or for scanning with your favorite antivirus.<br />
<br />
<span style="color: #3333ff;"><span style="font-size: 180%;"><span style="color: black;">Artifact 13: Kernel Callbacks</span></span></span><br />
<blockquote>
<span style="color: #3333ff;">"That means Mrxcls.sys called PsSetLoadImageNotifyRoutine</span><span style="color: #3333ff;"> so that Windows would call it whenever an executable image, such as a DLL or device driver, is mapped into memory." [3]</span></blockquote>
Based on this statement, you can use the <a href="http://code.google.com/p/volatility/wiki/CommandReference#callbacks">callbacks</a> command.<br />
<pre><span style="font-size: 78%;"><span style="font-family: courier new;">$<span style="font-weight: bold;"> ./vol.py callbacks</span></span>
<span style="font-family: courier new;">Volatile Systems Volatility Framework 2.0</span>
<span style="font-family: courier new;">Type Callback Owner</span>
<span style="font-family: courier new;">PsSetLoadImageNotifyRoutine 0xb240ce4c PROCMON20.SYS</span>
<span style="font-family: courier new;">PsSetLoadImageNotifyRoutine 0x805f81a6 ntoskrnl.exe</span>
<span style="color: red; font-family: courier new; font-weight: bold;">PsSetLoadImageNotifyRoutine 0xf895ad06 mrxcls.sys</span>
<span style="font-family: courier new;">PsSetCreateThreadNotifyRoutine 0xb240cc9a PROCMON20.SYS</span>
<span style="font-family: courier new;">PsSetCreateProcessNotifyRoutine 0xf87ad194 vmci.sys</span>
<span style="font-family: courier new;">PsSetCreateProcessNotifyRoutine 0xb240cb94 PROCMON20.SYS</span>
<span style="font-family: courier new;">KeBugCheckCallbackListHead 0xf83e65ef NDIS.sys (Ndis miniport)</span>
<span style="font-family: courier new;">KeBugCheckCallbackListHead 0x806d77cc hal.dll (ACPI 1.0 - APIC platform UP)</span>
<span style="font-family: courier new;">KeRegisterBugCheckReasonCallback 0xf8b7aab8 mssmbios.sys (SMBiosData)</span>
<span style="font-family: courier new;">KeRegisterBugCheckReasonCallback 0xf8b7aa70 mssmbios.sys (SMBiosRegistry)</span>
<span style="font-family: courier new;">[snip]</span></span></pre>
The output shows the <a href="http://msdn.microsoft.com/en-us/library/ff559957%28v=vs.85%29.aspx">PsSetLoadImageNotifyRoutine</a> installed by mrxcls.sys. Mark also states <span style="color: #3333ff;">"Ironically, Process Monitor also uses this callback functionality to monitor image loads."</span> [3] which is why you see the PROCMON20.SYS entries as well.<br />
<br />
<span style="color: #3333ff;"><span style="font-size: 180%;"><span style="color: black;">Artifact 14: FileSystem Hooks</span></span></span><br />
<blockquote>
<span style="color: #3333ff;">"The driver also registers to a filesystem registration callback routine in order to hook newly created filesystem objects on the fly." [4]</span></blockquote>
Based on this statement, if the rootkit used <a href="http://msdn.microsoft.com/en-us/library/ff548499%28v=vs.85%29.aspx">IoRegisterFsRegistrationChange</a> to install the file system registration callback routine, then you can use the callbacks plugin to detect it. However, instead it uses <span class="function" title="function"><a href="http://msdn.microsoft.com/en-us/library/ff549511%28v=vs.85%29.aspx">IoRegisterDriverReinitialization</a>, which works a bit differently. In particular, it uses different pool tags, a different structure for storing the callback address, and a different symbol name for the list head (nt!_IopDriverReinitializeQueueHead). </span>Extending the callbacks plugin for this purpose is extremely easy. Just take the information shown in the following screen shot and have a look at the other examples in the malware.py source code.<br />
<br />
<a href="https://blogger.googleusercontent.com/img/b/R29vZ2xl/AVvXsEgI_KF8B6-ajj1AER842iZnDwou3ehrduhKBwzVAU-duKbw_d89riCEPryfz9uQf6DV6dYvDhCoNzINTE4AvShYlOvz8EvY_3IbbCQL6yZdhxtgPjgBLwJSSo4en1gGtCKJOvFbZvGvMJjF/s1600/IoRi.png"><img alt="" border="0" id="BLOGGER_PHOTO_ID_5614132626680948754" src="https://blogger.googleusercontent.com/img/b/R29vZ2xl/AVvXsEgI_KF8B6-ajj1AER842iZnDwou3ehrduhKBwzVAU-duKbw_d89riCEPryfz9uQf6DV6dYvDhCoNzINTE4AvShYlOvz8EvY_3IbbCQL6yZdhxtgPjgBLwJSSo4en1gGtCKJOvFbZvGvMJjF/s320/IoRi.png" style="cursor: pointer; display: block; height: 265px; margin: 0px auto 10px; text-align: center; width: 320px;" /></a><br />
<span style="color: #3333ff;"><span style="font-size: 180%;"><span style="color: black;">Artifact 15: Devices & IRPs</span></span></span><br />
<span style="color: #3333ff;"></span><br />
<blockquote>
<span style="color: #3333ff;">"The driver scans for the following filesystem driver objects:</span><br />
<br />
<span style="color: #3333ff;">* \FileSystem\ntfs</span><br />
<span style="color: #3333ff;">* \FileSystem\fastfat</span><br />
<span style="color: #3333ff;">* \FileSytstem\cdfs</span><br />
<br />
<span style="color: #3333ff;">A new device object is created by Stuxnet and attached to the device chain for each device object managed by these driver objects. [...] By inserting such objects, Stuxnet is able to intercept IRP requests (example: writes, reads, to devices NTFS, FAT, or CD-ROM devices)." [4]</span></blockquote>
Based on this statement, the Stuxnet driver is exploiting Microsoft's layered driver architecture which you can explore with the devicetree plugin. Let's focus on ntfs to start.<br />
<pre><span style="font-size: 78%;"><span style="font-family: courier new;">$ <span style="font-weight: bold;">./vol.py devicetree </span></span>
<span style="font-family: courier new;">Volatile Systems Volatility Framework 2.0
[snip]<span style="color: red; font-weight: bold;"></span>
DRV 0x0253d180 '\\FileSystem\\Ntfs'
DEV 0x8224e020 (unnamed) FILE_DEVICE_DISK_FILE_SYSTEM
ATT 0x8223e6c0 (unnamed) - '\\FileSystem\\sr' FILE_DEVICE_DISK_FILE_SYSTEM
<span style="color: red; font-weight: bold;"> ATT 0x821d52f0 (unnamed) - '\\Driver\\MRxNet' FILE_DEVICE_DISK_FILE_SYSTEM</span>
DEV 0x8224f790 Ntfs FILE_DEVICE_DISK_FILE_SYSTEM
ATT 0x8223edd0 (unnamed) - '\\FileSystem\\sr' FILE_DEVICE_DISK_FILE_SYSTEM
<span style="color: red; font-weight: bold;"> ATT 0x820d2350 (unnamed) - '\\Driver\\MRxNet' FILE_DEVICE_DISK_FILE_SYSTEM</span></span></span></pre>
You can see that the MRxNet driver has created several devices (via <a href="http://msdn.microsoft.com/en-us/library/ff548397%28v=vs.85%29.aspx">IoCreateDevice</a>) and attached them to the device chain of \FileSystem\Ntfs for filtering purposes. The Fastfat file system is not used on the system, so it isn't shown, but Cdfs is:<br />
<pre><span style="font-size: 78%;"><span style="font-family: courier new;">DRV 0x01f9cf38 '\\FileSystem\\Cdfs'
DEV 0x81d9cc88 Cdfs FILE_DEVICE_CD_ROM_FILE_SYSTEM
<span style="color: red; font-weight: bold;"> ATT 0x81ff3d50 (unnamed) - '\\Driver\\MRxNet' FILE_DEVICE_CD_ROM_FILE_SYSTEM</span></span></span></pre>
Stuxnet maintains control over network file systems in addition to local disks and CDROMs. In total, it creates and attaches 11 devices. Other targets include vmhgfs (VMware Host/Guest File System), WebDav, and SMB.<br />
<pre><span style="font-size: 78%;"><span style="font-family: courier new;">DRV 0x023c6268 '\\FileSystem\\Fs_Rec'
DEV 0x82303030 FatCdRomRecognizer FILE_DEVICE_CD_ROM_FILE_SYSTEM
<span style="color: red; font-weight: bold;"> ATT 0x82127b00 (unnamed) - '\\Driver\\MRxNet' FILE_DEVICE_CD_ROM_FILE_SYSTEM</span>
DEV 0x8233a030 FatDiskRecognizer FILE_DEVICE_DISK_FILE_SYSTEM
<span style="color: red; font-weight: bold;"> ATT 0x8230daf0 (unnamed) - '\\Driver\\MRxNet' FILE_DEVICE_DISK_FILE_SYSTEM</span>
DEV 0x8222d918 UdfsDiskRecognizer FILE_DEVICE_DISK_FILE_SYSTEM
<span style="color: red; font-weight: bold;"> ATT 0x81da8bf8 (unnamed) - '\\Driver\\MRxNet' FILE_DEVICE_DISK_FILE_SYSTEM</span>
DEV 0x82259d38 UdfsCdRomRecognizer FILE_DEVICE_CD_ROM_FILE_SYSTEM
<span style="color: red; font-weight: bold;"> ATT 0x821d7530 (unnamed) - '\\Driver\\MRxNet' FILE_DEVICE_CD_ROM_FILE_SYSTEM</span>
DEV 0x81dcd030 CdfsRecognizer FILE_DEVICE_CD_ROM_FILE_SYSTEM
DRV 0x023c6da0 '\\FileSystem\\vmhgfs'
DEV 0x8230d030 hgfsInternal FILE_DEVICE_UNKNOWN
DEV 0x81eba030 HGFS FILE_DEVICE_NETWORK_FILE_SYSTEM
<span style="color: red; font-weight: bold;"> ATT 0x8222d320 (unnamed) - '\\Driver\\MRxNet' FILE_DEVICE_NETWORK_FILE_SYSTEM</span>
DRV 0x023c7030 '\\FileSystem\\MRxSmb'
DEV 0x81d9ad80 LanmanDatagramReceiver FILE_DEVICE_NETWORK_BROWSER
DEV 0x82266c00 LanmanRedirector FILE_DEVICE_NETWORK_FILE_SYSTEM
<span style="color: red; font-weight: bold;"> ATT 0x81da7f10 (unnamed) - '\\Driver\\MRxNet' FILE_DEVICE_NETWORK_FILE_SYSTEM</span>
DRV 0x021ef6e8 '\\FileSystem\\MRxDAV'
DEV 0x81ee4610 WebDavRedirector FILE_DEVICE_NETWORK_FILE_SYSTEM
<span style="color: red; font-weight: bold;"> ATT 0x81d50190 (unnamed) - '\\Driver\\MRxNet' FILE_DEVICE_NETWORK_FILE_SYSTEM</span></span></span></pre>
Also, you can use the <a href="http://code.google.com/p/volatility/wiki/CommandReference#driverirp">driverirp</a> command to analyze which IRPs the Stuxnet drivers handle and which ones they ignore. For example:<br />
<pre><span style="font-size: 78%;"><span style="font-family: courier new;">$ <span style="font-weight: bold;">./vol.py driverirp -r mrxnet</span></span>
<span style="font-family: courier new;">Volatile Systems Volatility Framework 2.0</span>
<span style="font-family: courier new;">DriverStart Name IRP IrpAddr IrpOwner HookAddr HookOwner</span>
<span style="font-family: courier new;">0xb21d8000 'MRxNet' IRP_MJ_CREATE 0xb21d8486 mrxnet.sys - -</span>
<span style="font-family: courier new;">0xb21d8000 'MRxNet' IRP_MJ_CREATE_NAMED_PIPE 0xb21d8486 mrxnet.sys - -</span>
<span style="font-family: courier new;">0xb21d8000 'MRxNet' IRP_MJ_CLOSE 0xb21d8486 mrxnet.sys - -</span>
<span style="font-family: courier new;">0xb21d8000 'MRxNet' IRP_MJ_READ 0xb21d8486 mrxnet.sys - -</span>
<span style="font-family: courier new;">0xb21d8000 'MRxNet' IRP_MJ_WRITE 0xb21d8486 mrxnet.sys - -</span>
<span style="font-family: courier new;">0xb21d8000 'MRxNet' IRP_MJ_QUERY_INFORMATION 0xb21d8486 mrxnet.sys - -</span>
<span style="font-family: courier new;">0xb21d8000 'MRxNet' IRP_MJ_SET_INFORMATION 0xb21d8486 mrxnet.sys - -</span>
<span style="font-family: courier new;">0xb21d8000 'MRxNet' IRP_MJ_QUERY_EA 0xb21d8486 mrxnet.sys - -</span>
<span style="font-family: courier new;">0xb21d8000 'MRxNet' IRP_MJ_SET_EA 0xb21d8486 mrxnet.sys - -</span>
<span style="font-family: courier new;">0xb21d8000 'MRxNet' IRP_MJ_FLUSH_BUFFERS 0xb21d8486 mrxnet.sys - -</span>
<span style="font-family: courier new;">0xb21d8000 'MRxNet' IRP_MJ_QUERY_VOLUME_INFORMATION 0xb21d8486 mrxnet.sys - -</span>
<span style="font-family: courier new;">0xb21d8000 'MRxNet' IRP_MJ_SET_VOLUME_INFORMATION 0xb21d8486 mrxnet.sys - -</span>
<span style="color: red; font-family: courier new; font-weight: bold;">0xb21d8000 'MRxNet' IRP_MJ_DIRECTORY_CONTROL 0xb21d84ec mrxnet.sys 0xb21d97c4 mrxnet.sys</span> <span style="color: red; font-family: courier new; font-weight: bold;">
0xb21d8000 'MRxNet' IRP_MJ_FILE_SYSTEM_CONTROL 0xb21d8496 mrxnet.sys 0xb21d97c4 mrxnet.sys</span>
<span style="font-family: courier new;">0xb21d8000 'MRxNet' IRP_MJ_DEVICE_CONTROL 0xb21d8486 mrxnet.sys - -</span>
<span style="font-family: courier new;">0xb21d8000 'MRxNet' IRP_MJ_INTERNAL_DEVICE_CONTROL 0xb21d8486 mrxnet.sys - -</span>
<span style="font-family: courier new;">0xb21d8000 'MRxNet' IRP_MJ_SHUTDOWN 0xb21d8486 mrxnet.sys - -</span>
<span style="font-family: courier new;">0xb21d8000 'MRxNet' IRP_MJ_LOCK_CONTROL 0xb21d8486 mrxnet.sys - -</span>
<span style="font-family: courier new;">0xb21d8000 'MRxNet' IRP_MJ_CLEANUP 0xb21d8486 mrxnet.sys - -</span>
<span style="font-family: courier new;">0xb21d8000 'MRxNet' IRP_MJ_CREATE_MAILSLOT 0xb21d8486 mrxnet.sys - -</span>
<span style="font-family: courier new;">0xb21d8000 'MRxNet' IRP_MJ_QUERY_SECURITY 0xb21d8486 mrxnet.sys - -</span>
<span style="font-family: courier new;">0xb21d8000 'MRxNet' IRP_MJ_SET_SECURITY 0xb21d8486 mrxnet.sys - -</span>
<span style="font-family: courier new;">0xb21d8000 'MRxNet' IRP_MJ_POWER 0xb21d8486 mrxnet.sys - -</span>
<span style="font-family: courier new;">0xb21d8000 'MRxNet' IRP_MJ_SYSTEM_CONTROL 0xb21d8486 mrxnet.sys - -</span>
<span style="font-family: courier new;">0xb21d8000 'MRxNet' IRP_MJ_DEVICE_CHANGE 0xb21d8486 mrxnet.sys - -</span>
<span style="font-family: courier new;">0xb21d8000 'MRxNet' IRP_MJ_QUERY_QUOTA 0xb21d8486 mrxnet.sys - -</span>
<span style="font-family: courier new;">0xb21d8000 'MRxNet' IRP_MJ_SET_QUOTA 0xb21d8486 mrxnet.sys - -</span>
<span style="font-family: courier new;">0xb21d8000 'MRxNet' IRP_MJ_PNP 0xb21d8486 mrxnet.sys - -</span></span></pre>
The HookAddr and HookOwner column in the output is admittedly a little mis-leading. In this case, the IRPs aren't hooked. The columns are just showing where the next hop of execution leads, based on the instructions at the IRP address. The columns are blank for everything except IRP_MJ_DIRECTORY_CONTROL and IRP_MJ_FILE_SYSTEM_CONTROL. Thus, these two IRPs are handled specially by the rootkit. All other IRPs are probably ignored or passed through.<br />
<br />
<span style="color: #3333ff;"><span style="font-size: 180%;"><span style="color: black;">Artifact 16: PDB Reference</span></span></span><br />
<span style="color: #3333ff;"></span><br />
<blockquote>
<span style="color: #3333ff;">"In the driver file, the project path b:\myrtus\src\objfre_w2k_x86\i386 \guava.pdb was not removed." [4]</span></blockquote>
Based on this statement, you have a unique string to search for in kernel memory. That can be done with Malfind by passing the -K or --kernel flag.<br />
<pre><span style="font-size: 78%;"><span style="font-family: courier new;">$ <span style="font-weight: bold;">./vol.py malfind -D out -K -Y "myrtus"</span></span>
<span style="font-family: courier new;">Volatile Systems Volatility Framework 2.0</span>
<span style="font-family: courier new;">Name Pid Start End Tag Hits Protect</span>
<span style="font-family: courier new;"><span style="color: red; font-weight: bold;">mrxnet.sys</span> - 0xB21D8000 0xB21DB000 - 1 - (Unknown)</span>
<span style="font-family: courier new;">Hit: myrtus</span>
<span style="font-family: courier new;">0xb21d9d9b 6d 79 72 74 75 73 5c 73 72 63 5c 6f 62 6a 66 72 <span style="color: red; font-weight: bold;">myrtus.src.objfr</span></span>
<span style="font-family: courier new;">0xb21d9dab 65 5f 77 32 6b 5f 78 38 36 5c 69 33 38 36 5c 67 <span style="color: red; font-weight: bold;">e_w2k_x86.i386.g</span></span>
<span style="font-family: courier new;">0xb21d9dbb 75 61 76 61 2e 70 64 62 00 00 00 00 00 00 00 00 <span style="color: red; font-weight: bold;">uava.pdb</span>........</span>
<span style="font-family: courier new;">0xb21d9dcb 00 00 00 00 00 30 18 00 00 1c 1a 00 00 fe ff ff .....0..........</span>
<span style="font-family: courier new;">0xb21d9ddb ff 00 00 00 00 d8 ff ff ff 00 00 00 00 fe ff ff ................</span>
<span style="font-family: courier new;">0xb21d9deb ff cb 84 1d b2 cf 84 1d b2 00 00 00 00 fe ff ff ................</span>
<span style="font-family: courier new;">0xb21d9dfb ff 00 00 00 00 d8 ff ff ff 00 00 00 00 fe ff ff ................</span>
<span style="font-family: courier new;">0xb21d9e0b ff 21 85 1d b2 25 85 1d b2 00 00 00 00 fe ff ff .!...%..........</span></span></pre>
We got a hit in mrxnet.sys at 0xb21d9d9b. Easy enough!<br />
<br />
<span style="color: #3333ff;"><span style="font-size: 180%;"><span style="color: black;">Artifact 17 and 18: Windows & Classes</span></span></span><br />
<span style="color: #3333ff;"></span><br />
<blockquote>
<span style="color: #3333ff;">"It registers a window class with the name "AFX64c313" and creates a window corresponding to the class created. The window procedure of the class monitors WM_DEVICE_CHANGE messages sent when there is a change to the hardware configuration of a device or the computer. The window procedure of the class handles only requests with wParam set to DBT_DEVICEARRIVAL." [6]</span></blockquote>
This statement is describing two different, but related artifacts. We'll detect them using a few plugins built on information originally disclosed by Moyix in his blog <a href="http://moyix.blogspot.com/2010/07/gdi-utilities-taking-screenshots-of.html">GDI Utilities: Taking Screenshots from Memory Dumps</a>. One is the creation of a window class (see <a href="http://msdn.microsoft.com/en-us/library/ms633587%28v=VS.85%29.aspx">RegisterClassEx</a>) which results in a new <a href="http://msdn.microsoft.com/en-us/library/ff468795%28v=VS.85%29.aspx">Atom</a>. If you're not familiar with atom tables, they can be extremely useful for various tasks, including malware analysis. I'll save the details for a later discussion. For now, let's check for the malicious class atom:<br />
<pre><span style="font-size: 78%;"><span style="font-family: courier new;">$ <span style="font-weight: bold;">./vol.py atomscan</span>
Volatile Systems Volatility Framework 2.0
Table Atom Refs Flags Name
0xcc05da8 0xc0b1 0x4 0 Performed DropEffect
0xcc05da8 0xc0b7 0x2 0 TargetCLSID
0xcc05da8 0xc0d6 0x1 0 text/richtext
0xcc05da8 0xc0d9 0x1 0 application/base64
<span style="color: red; font-weight: bold;">0xcc05da8 0xc118 0x2 0 AFX64c313</span>
0xcc05da8 0xc010 0x1 RTL_ATOM_PINNED OleDraw
0xcc05da8 0xc033 0x1 RTL_ATOM_PINNED OTHERWINDOWCREATED
0xcc05da8 0xc069 0x17 0 6.0.2600.5512!SysLink</span></span></pre>
The next artifact we're looking for is a window (see <a href="http://msdn.microsoft.com/en-us/library/ms632680%28v=VS.85%29.aspx">CreateWindowEx</a>) of the class AFX64c313. Handles to windows (and all other USER objects) are stored in a completely different handle table than mutexes, files, registry keys, etc. We can filter by USER object type using the -t parameter.<br />
<br />
Note: I don't want to spoil whatever surprises that Okolica and Peterson plan to share at <a href="http://www.dfrws.org/2011/program.shtml">DFRWS 2011 "Extracting the Windows Clipboard from Memory"</a> but using TYPE_CLIPDATA instead of TYPE_WINDOW to this command is *one* of the ways to dump the contents of the clipboard.<br />
<pre><span style="font-size: 78%;"><span style="font-family: courier new;">$ <span style="font-weight: bold;">./vol.py userhandles -t TYPE_WINDOW</span>
Volatile Systems Volatility Framework 2.0
[snip]
<span style="color: red; font-weight: bold;">Process: 668 (services.exe)</span>
Thread: 1420
Type: TYPE_WINDOW (tagWND)
Object: 0xbc951d10
Handle: 0xe00e8
<span style="color: red; font-weight: bold;">Window text: AFX64c313</span>
<span style="color: red; font-weight: bold;">Window procedure: 0x13fe695</span>
<span style="color: red; font-weight: bold;">Class: ['AFX64c313']</span>
Superclass: ['AFX64c313']
Style: WS_MINIMIZEBOX|WS_TABSTOP|WS_DLGFRAME|WS_BORDER|WS_THICKFRAME|WS_CAPTION|WS_SYSMENU|WS_MAXIMIZEBOX|WS_GROUP|WS_OVERLAPPED|WS_CLIPSIBLINGS
ExStyle: WS_EX_LTRREADING|WS_EX_RIGHTSCROLLBAR|WS_EX_WINDOWEDGE|WS_EX_LEFT
<span style="color: red; font-weight: bold;">Visible: No</span>
Coords: left 88, top 116, right 927, bottom 699</span></span></pre>
What you see here, in a nutshell, is a window of the class AFX64c313 owned by services.exe. Although the window is not visible, it contains the text "AFX64c313." The <a href="http://msdn.microsoft.com/en-us/library/ms633573%28v=VS.85%29.aspx">window procedure</a> is located at 0x13fe695 in the memory of services.exe. To explore the function, break into a volshell, change context to the right process, and disassemble.<br />
<pre><span style="font-size: 78%;"><span style="font-family: courier new;">$ <span style="font-weight: bold;">./vol.py volshell</span>
Volatile Systems Volatility Framework 2.0
Current context: process System, pid=4, ppid=0 DTB=0x319000
Welcome to volshell! Current memory image is:
file:///memory/stuxnet.vmem
To get help, type 'hh()'
In [1]: <span style="font-weight: bold;">cc(pid=668)</span>
Current context: process services.exe, pid=668, ppid=624 DTB=0xa940080
In [2]: <span style="font-weight: bold;">dis(0x13fe695)</span>
0x13fe695 55 PUSH EBP
0x13fe696 8bec MOV EBP, ESP
0x13fe698 817d0c19020000 <span style="color: red; font-weight: bold;">CMP DWORD [EBP+0xc], 0x219 ; WM_DEVICECHANGE</span>
0x13fe69f 7514 JNZ 0x13fe6b5
0x13fe6a1 ff7514 PUSH DWORD [EBP+0x14]
0x13fe6a4 ff7510 PUSH DWORD [EBP+0x10]
0x13fe6a7 e810000000 CALL 0x13fe6bc
0x13fe6ac 59 POP ECX
0x13fe6ad 33c0 XOR EAX, EAX
0x13fe6af 59 POP ECX
0x13fe6b0 40 INC EAX
0x13fe6b1 5d POP EBP
0x13fe6b2 c21000 RET 0x10
0x13fe6b5 5d POP EBP
0x13fe6b6 ff25c4534401 JMP DWORD [0x14453c4]
0x13fe6bc 55 PUSH EBP
0x13fe6bd 8bec MOV EBP, ESP
0x13fe6bf 83e4f8 AND ESP, -0x8
0x13fe6c2 64a100000000 MOV EAX, [FS:0x0]
0x13fe6c8 6aff PUSH -0x1
0x13fe6ca 68893d4401 PUSH DWORD 0x1443d89
0x13fe6cf 50 PUSH EAX
0x13fe6d0 64892500000000 MOV [FS:0x0], ESP
0x13fe6d7 83ec6c SUB ESP, 0x6c
0x13fe6da 817d0800800000 <span style="color: red; font-weight: bold;">CMP DWORD [EBP+0x8], 0x8000 ; DBT_DEVICEARRIVAL</span>
0x13fe6e1 53 PUSH EBX
0x13fe6e2 56 PUSH ESI</span></span></pre>
Artifact 17: check! Artifact 18: check. Capabilities you didn't know existed in any memory analysis framework: check! ;=)<span style="font-size: 180%;"><br /></span><br />
<span style="color: #3333ff;"><span style="font-size: 180%;"><span style="color: black;">Artifact 19 (and Beyond...)</span></span></span><br />
<br />
Okay so we didn't quite make it to 20 artifacts with the time allotted, but with the <span style="font-size: 180%;"><span style="color: red;">power of Volatility</span></span>, we've gotten pretty close. 20 is still a small number in relation to how many artifacts Stuxnet actually leaves on a system. We didn't even touch on the RPC server, jobs/tasks, UPX packing, and fake digital certificates. Also, don't forget there are other memory analysis frameworks with different capabilities.<br />
<br />
<span style="color: #3333ff;"><span style="font-size: 180%;"><span style="color: black;">Conclusion</span></span></span><br />
<br />
I hope this has been an informative post for people interested in malware analysis, Stuxnet, Volatility, memory forensics, and related topics. Thank you to the authors of all the quoted articles (the people who did real RE work) and to the Volatility team for completing release 2.0!Michael Hale Lighhttp://www.blogger.com/profile/17377327006242921434noreply@blogger.com6tag:blogger.com,1999:blog-3630199973361886660.post-13383473935964931352011-04-25T22:03:00.011-06:002012-08-05T21:07:45.344-06:00Detecting/Memory Forging Attempt by a RootkitIn my previous post on analyzing threads, I hinted that there would be a separate discussion regarding Rachit Mathur's <a href="http://blogs.mcafee.com/mcafee-labs/memory-forging-attempt-by-a-rootkit">Memory Forging Attempt By A Rootkit</a> article. Well, here it is!<br />
<br />
In his blog, Rachit described a malware sample that prevented live anti-rootkit tools from detecting the malware's IRP hooks. To summarize the malware's technique, it did the following:<br />
<br />
1) Hook KiDebugRoutine<span style="text-decoration: underline;"></span> (see <a href="http://uninformed.org/index.cgi?v=8&a=2">skape & Skywing's explanation</a>) by overwriting the kernel global with a pointer to the rootkit code. For example code showing how to do this, see the <a href="http://code.google.com/p/ngdbg/source/browse/trunk/dbgeng.cpp#393">DbgHookKiDebugRoutine function of the ngdbg</a> project.<br />
<br />
2) Set an on-read hardware breakpoint which triggers on attempts to read the memory of the hooked driver's dispatch table<br />
<br />
3) Return real or fake data from the KiDebugRoutine hook...thus allowing the rootkit to mask its memory modifications when checked by anti-rootkit tools<br />
<br />
The purpose of this blog is to discuss how you can detect the hardware breakpoints that allow this malware to "filter" access to the protected memory. Volatility's threads command can detect hardware breakpoints, but only thread-specific breakpoints using the set of registers located at _ETHREAD.Tcb.TrapFrame. The rootkit we're discussing uses a different set of processor (or affinity)-specific registers.<br />
<br />
Take a look at the following function in the rootkit's driver that actually sets the breakpoints.<br />
<br />
<a href="https://blogger.googleusercontent.com/img/b/R29vZ2xl/AVvXsEhtpB9jxNnal_zSwzZygupPhYbsPqRHqVckuKsnE20BHw0IQn-rxL1xCMS4dTx1UhBiYdDBjEVbUHRQ9YbRR1iLEqPtI2fWAb8BGfNfEw0ZNUM5YJdgiy7wVs8zyoz3FluVH79GYEfjoiw5/s1600/TdssHwBps.png"><img alt="" border="0" id="BLOGGER_PHOTO_ID_5599748745587493426" src="https://blogger.googleusercontent.com/img/b/R29vZ2xl/AVvXsEhtpB9jxNnal_zSwzZygupPhYbsPqRHqVckuKsnE20BHw0IQn-rxL1xCMS4dTx1UhBiYdDBjEVbUHRQ9YbRR1iLEqPtI2fWAb8BGfNfEw0ZNUM5YJdgiy7wVs8zyoz3FluVH79GYEfjoiw5/s400/TdssHwBps.png" style="cursor: pointer; display: block; height: 400px; margin: 0px auto 10px; text-align: center; width: 264px;" /></a>And here's a description of what its doing:<br />
<br />
1) Uses <a href="http://msdn.microsoft.com/en-us/library/ff553001%28v=vs.85%29.aspx">KeQueryActiveProcessors</a> to find out how many processors the victim machine has<br />
<br />
2) Enters a loop that executes once for each processor, up to 32 processors<br />
<br />
3) Calls <a href="http://msdn.microsoft.com/en-us/library/ff553267%28v=vs.85%29.aspx">KeSetSystemAffinityThread</a> to "switch" processors on which the current thread executes (so that the thread can make processor-specific changes)<br />
<br />
4) Finds the processor's KPCR structure by referencing fs:[1Ch] which points to KPCR.SelfPcr (a self-referencing member of the KPCR)<br />
<br />
5) Sets the KPCR.DebugActive member to 1<br />
<br />
6) Move the debug flags 0F0703h into the dr7 control register (see mov dr7, ebx)<br />
<br />
7) Move the address of the protected memory into the dr0 register (see mov dr0, ebx)<br />
<br />
8) If OS MajorVersion is less than 6 (i.e. XP or earlier), then it also writes to the processor-specific set of special registers. Note: writing to dr0 and dr7 on XP will update the special registers anyway.<br />
<br />
Based on the disassembly and these few minutes of rootkit reverse engineering, we can now build a proof-of-concept Volatility plugin that detects the breakpoints.<br />
<pre style="font-family: courier new;"><span style="font-size: 78%;">import volatility.commands as commands
import volatility.utils as utils
import volatility.obj as obj
class TestCommand(commands.command):
"""Check the kernel's debug registers"""
def calculate(self):
addr_space = utils.load_as(self._config)
volmagic = obj.Object('VOLATILITY_MAGIC', 0x0, addr_space)
kpcr = obj.Object("_KPCR", volmagic.KPCR.v(), addr_space)
if kpcr.DebugActive:
if kpcr.Prcb.ProcessorState.SpecialRegisters.KernelDr0 != 0:
print '[*] Infection Possible!'
def render_text(self, outfd, data):
pass</span></pre>
Just drop that code into a file such as volatility/plugins/testcommand.py and off you go. On an infected machine, you should see:<br />
<br />
<span style="font-size: 78%;"><span style="font-family: courier new;">$ python vol.py -f memory.dmp testcommand</span> <span style="font-family: courier new;"><br />[*] infection possible!</span></span><br />
<br />
The code we've written here is simply proof of concept, just to show how easy it is to access members of different data structures using Volatility's object model. The main weaknesses in the current code, should you want to design a more useful one are:<br />
<br />
1) It only checks one processor instead of the maximum 32. For proof of concept purposes, it doesn't really matter which processor is checked since the rootkit "infects" them all, but in real life you'd want to be more robust.<br />
<br />
2) It only checks if dr0 is set, but dr1 dr2 and dr3 could be set by the rootkit instead. Maybe different variants of the same malware use different registers - you never know.Michael Hale Lighhttp://www.blogger.com/profile/17377327006242921434noreply@blogger.com2tag:blogger.com,1999:blog-3630199973361886660.post-63536614599101794782011-04-18T10:54:00.064-06:002012-08-05T21:08:53.347-06:00Investigating Windows Threads with VolatilityThere are various ways of finding objects and data structures in a memory dump. Two of the popular ways include list traversal (or pointer traversal) and pool scanning. Depending on which plugin you use, <a href="http://code.google.com/p/volatility/">Volatility</a> allows you to enumerate processes, sockets, connections, and kernel modules using both of these methods. Regarding threads, however, there is only one plugin, named <a href="http://code.google.com/p/volatility/wiki/CommandReference#thrdscan2">thrdscan2</a>, which uses pool scanning. So does that mean you can't use Volatility to enumerate threads by list traversal? Of course not, Silly! In fact, there are several source files, such as <a href="http://code.google.com/p/volatility/source/browse/branches/Volatility-1.4_rc1/volatility/plugins/ssdt.py#107">ssdt.py</a> by <a href="http://moyix.blogspot.com/">Brendan Dolan-Gavitt</a>, which shows how it's done. Here's a snippet of that code:<br />
<pre style="font-family: courier new;"><span style="font-size: 85%;">for proc in tasks.pslist(addr_space):
for thread in proc.ThreadListHead.list_of_type("_ETHREAD", "ThreadListEntry"):
# print thread.ExitTime</span></pre>
As shown, in the inner <span style="font-style: italic;">for</span> loop, you would reference members of _ETHREAD in an object-oriented manner, just like any other Python class. This gives you the ability to use or print the data in any way you want. For example, if you can't identify the owning driver for a thread's start address (thread.StartAddress), then it might be an <a href="http://mnin.blogspot.com/2009/03/finding-tiggersyzor-infections-and.html">orphan thread</a> left by a rootkit. You may also want to know which threads are using an SSDT (thread.Tcb.ServiceTable) with hooked functions. Plugins for Volatility, which implement both of these checks, are described in <span style="font-weight: bold;">Recipe 17.6 Detecting SSDT Hooks</span> and <span style="font-weight: bold;">Recipe 17.8 Finding Rootkits with Detached Kernel Threads</span> of <a href="http://www.amazon.com/dp/0470613033?tag=malwacookb-20&camp=14573&creative=327641&linkCode=as1&creativeASIN=0470613033&adid=1427ZF6HGNFBMYBT4SNP&">Malware Analyst's Cookbook</a>.<br />
<br />
After careful consideration ;-) I decided that instead of creating an individual plugin for each heuristic, we could simply have one which performs all checks, can be easily extended with other checks, and that more or less breaths some life into the ability to report on threads in physical memory dumps. After all, there are lots of memory forensic tools that can enumerate threads, but output is typically limited to basic information about the thread (such as thread ID, owning process, and start/exit times). From an analysis perspective, after you've found a thread...what's next?<br />
<br />
To help address these issues, I created a new plugin named <a href="http://code.google.com/p/malwarecookbook/source/browse/trunk/malware.py"><span style="font-style: italic;">threads</span></a>. It uses whatever heuristics you give it and associates a descriptive tag to threads found in the memory dump. Then you filter by tag when performing an investigation. For example, you could ask it to only show threads hidden from a debugger. To see the list of possible arguments to the threads command, use it first with -h:<br />
<pre><span style="font-size: 85%;">$ python vol.py -f test.vmem threads -h
Volatile Systems Volatility Framework 1.4_rc1
Usage: Volatility - A memory forensics analysis platform.
Options:
......
-F FILTER, --filter=FILTER
Tags to filter (comma-separated)
-A ALLOW_HOOK, --allow-hook=ALLOW_HOOK
Allow SSDT hooks from these mods (comma-separated)
-p PID, --pid=PID Operate on these Process IDs (comma-separated)
-L, --listtags List all available tags</span></pre>
To list the existing tags and their descriptions, use the -L flag to the plugin:<br />
<pre><span style="font-size: 85%;">$ python vol.py -f test.vmem threads -L
Volatile Systems Volatility Framework 1.4_rc1
Tag Description
-------------- --------------
DkomExit Detect inconsistencies wrt exit times and termination
HwBreakpoints Detect threads with hardware breakpoints
ScannerOnly Detect threads no longer in a linked list
HideFromDebug Detect threads hidden from debuggers
OrphanThread Detect orphan threads
AttachedProcess Detect threads attached to another process
HookedSSDT Detect threads using a hooked SSDT
SystemThread Detect system threads</span></pre>
If available , for the threads that meet your filtering criteria, the plugin will also print the contents of the thread's registers at the time of the memory dump and disassemble code at the thread's start address. Now let's discuss each of the heuristics and see some example output.<br />
<br />
<span style="font-size: 130%;"><span style="font-weight: bold;">The OrphanThread Tag</span></span><br />
<br />
This tag is associated with <span style="font-style: italic;">system</span> <span style="font-style: italic;">threads</span> (see the SystemThread tag) whose StartAddress does not map back to a kernel driver in the PsLoadedModuleList. It can find threads created by a rootkit that unloads or unlinks its .sys in order to hide. Here is example output from the plugin on a memory dump infected with <a href="http://code.google.com/p/malwarecookbook/source/browse/trunk/17/8/tigger.vmem.zip">Tigger</a>.<br />
<pre><span style="font-size: 85%;">$ python vol.py -f tigger.vmem threads -F OrphanThread
Volatile Systems Volatility Framework 1.4_rc1
------
ETHREAD: 0xff1f92b0 Pid: 4 Tid: 1648
Tags: OrphanThread,SystemThread
Created: 2010-08-15 19:26:13
Exited: -
Owning Process: 0x810b1660 System
Attached Process: 0x810b1660 System
State: Waiting:DelayExecution
BasePriority: THREAD_PRIORITY_NORMAL
TEB: 0x00000000
StartAddress: 0xf2edd150
ServiceTable: 0x80552180
[0] 0x80501030
[1] -
[2] -
[3] -
Win32Thread: 0x00000000
CrossThreadFlags: PS_CROSS_THREAD_FLAGS_SYSTEM
f2edd150: 803d782aeff200 CMP BYTE [0xf2ef2a78], 0x0
f2edd157: 7437 JZ 0xf2edd190
f2edd159: 56 PUSH ESI
f2edd15a: bef0d0edf2 MOV ESI, 0xf2edd0f0
f2edd15f: ff35702aeff2 PUSH DWORD [0xf2ef2a70]</span></pre>
There are several key points to note:<br />
<br />
* The start address is 0xf2edd150 and no module name is printed, since it can't be identified<br />
<br />
* The thread is probably still running, because there is a create time but no exit time and the thread's state is waiting<br />
<br />
* This is not a GUI thread, because the SSDT[1] (for the win32k.sys Shadow Table) is not initialized and the Win32Thread pointer is NULL<br />
<br />
<span style="font-size: 130%;"><span style="font-weight: bold;">The SystemThread Tag</span></span><br />
<br />
This tag is associated with threads created by calls to <a href="http://msdn.microsoft.com/en-us/library/ff559932%28v=vs.85%29.aspx">PsCreateSystemThread</a>. You can distinguish these threads because they're owned by the System process, the PS_CROSS_THREAD_FLAGS_SYSTEM bit is set in _ETHREAD.CrossThreadFlags, and in most cases the _TEB (Thread Environment Block) pointer will also be NULL. An interesting thing to note about the PS_CROSS_THREAD_FLAGS_SYSTEM flag is that it can be set for non-system threads, which on some versions of Windows can help prevent the thread or owning process from being terminated. Naturally, some Chinese hacker forums (visit at your own risk) <a href="http://kssd.pediy.com/pediy10/95033.html">site 1</a> and <a href="http://hi.baidu.com/cr0_3/blog/item/951555208f167442925807f7.html">site 2</a> has some source code regarding that fact.<br />
<br />
<span style="font-size: 130%;"><span style="font-weight: bold;">The HookedSSDT Tag</span></span><br />
This tag is associated with threads whose _ETHREAD.Tcb.ServiceTable points to one or more SSDTs with hooked functions. Depending on <span style="font-style: italic;">how</span> a rootkit installs SSDT hooks, the hooks may not apply to all threads. To see which threads are affected and the names of the hooked functions, you can use the following filter (example is using <a href="http://code.google.com/p/malwarecookbook/source/browse/trunk/17/6/be2.vmem.zip">BlackEnergy 2</a>):<br />
<pre><span style="font-size: 85%;">$ python vol.py -f be2.vmem threads -F HookedSSDT
Volatile Systems Volatility Framework 1.4_rc1
------
ETHREAD: 0xff20c6f8 Pid: 1028 Tid: 1284
Tags: HookedSSDT
Created: 2010-08-15 19:22:11
Exited: -
Owning Process: 0x80fbf910 svchost.exe
Attached Process: 0x80fbf910 svchost.exe
State: Waiting:WrLpcReceive
BasePriority: THREAD_PRIORITY_ABOVE_NORMAL
TEB: 0x7ff95000
StartAddress: 0x7c810856
ServiceTable: 0xff1ef008
[0] 0xff3aab90
[0x41] NtDeleteValueKey 0xff0d2487 00004A2A
[0x47] NtEnumerateKey 0xff0d216b 00004A2A
[0x49] NtEnumerateValueKey 0xff0d2267 00004A2A
[0x77] NtOpenKey 0xff0d20c3 00004A2A
[0x7a] NtOpenProcess 0xff0d1e93 00004A2A
[0x80] NtOpenThread 0xff0d1f0b 00004A2A
[0x89] NtProtectVirtualMemory 0xff0d2617 00004A2A
[0xad] NtQuerySystemInformation 0xff0d1da0 00004A2A
[0xba] NtReadVirtualMemory 0xff0d256b 00004A2A
[0xd5] NtSetContextThread 0xff0d2070 00004A2A
[0xf7] NtSetValueKey 0xff0d2397 00004A2A
[0xfe] NtSuspendThread 0xff0d201d 00004A2A
[0x102] NtTerminateThread 0xff0d1fca 00004A2A
[0x115] NtWriteVirtualMemory 0xff0d25c1 00004A2A
[1] -
[2] -
[3] -
Win32Thread: 0x00000000
CrossThreadFlags:
Eip: 0x7c90eb94
eax=0x7509b647 ebx=0x750a3db0 ecx=0x7c914d8f
edx=0x01f7faec esi=0x00000001 edi=0x00000000
eip=0x7c90eb94 esp=0x0168fde8 ebp=0x0168ff34 err=0x00000000
cs=0x1b ss=0x23 ds=0x23 es=0x23 gs=0x00 efl=0x00000246
dr0=0x00000000 dr1=0x00000000 dr2=0x00000000
dr3=0x00000000 dr6=0x00000000 dr7=0x00000000</span></pre>
Notice in the output that the thread's service table is 0xff1ef008. This points to an array of 4 SSDTs. The first one at index [0] is the Native SSDT whose base is 0xff3aab90. It contains 14 hooked functions, all pointing to a driver named 00004A2A.sys. Therefore, when this thread calls any of the 14 functions, it will be routed through a malicious driver.<br />
<br />
The -A or --allow-hook parameter to the threads command allows you to specify the names of drivers that can legitimately set SSDT hooks. For example, if good.sys (an anti-virus driver) hooks the SSDT for all threads and bad.sys (a rootkit) hooks the SSDT for only a few threads, you may want to use the HookedSSDT filter and only focus on threads hooked by bad.sys. In that case just specify --allow-hook=good.sys.<br />
<br />
<span style="font-size: 130%;"><span style="font-weight: bold;">The ScannerOnly Tag</span></span><br />
<br />
This tag is associated with threads identified by the pool scanner only (not by list traversal). This does <span style="font-style: italic;">not</span> mean that a rootkit maliciously unlinked a thread from the list or that the thread is hidden in some way. It most often means that the thread has simply exited (and thus has legitimately been unlinked) or the thread belongs to a process that isn't in the PsActiveProcessHead list. You typically won't set a filter specifically for ScannerOnly, but you will see it frequently paired with other tags - so its good to be aware of what it means.<br />
<br />
<span style="font-size: 130%;"><span style="font-weight: bold;">The DkomExit Tag</span></span><br />
<br />
This tag is associated with threads that are still running but whose ExitTime has been filled in. Of the existing memory analysis tools that print exit times, you'll typically see a date or an empty string (if the ExitTime is all zeros). If a rootkit uses Direct Kernel Object Manipulation (DKOM) and fills in a thread's ExitTime, it will appear as if the thread has exited even if it's still running. Thus relying on the ExitTime alone is something we want to avoid.<br />
<br />
The purpose of the DkomExit check is to cross-reference the ExitTime with other fields in the _ETHREAD structure, that if forged, would <span style="font-style: italic;">probably</span> cause serious problems for the thread. These other fields include the thread's state (see <a href="http://www.nirsoft.net/kernel_struct/vista/KTHREAD_STATE.html">_KTHREAD_STATE</a>) and the thread's flags (see the <a href="http://www.hackchina.com/r/206238/struct.h__html">PS_CROSS_THREAD_FLAGS_*</a> definitions). To evaluate if this technique will yield false positives, we have to consider <span style="font-style: italic;">when</span> the kernel sets each of these fields during a thread's shutdown routine.<br />
<br />
For now, let's assume that most threads terminate via NtTerminateThread or PsTerminateSystemThread. First, both functions call PspTerminateThreadByPointer, which sets the PS_CROSS_THREAD_FLAGS_TERMINATED bit in _ETHREAD.CrossThreadFlags. Second, PspExitThread is called, which uses KeQuerySystemTime to fill in the _ETHREAD.ExitTime. Third, KeTerminateThread is called, which sets the _ETHREAD.Tcb.State to Terminated. So theoretically we should never find an _ETHREAD whose State == Terminated but whose ExitTime is still all zeros and whose CrossThreadFlags does not have the PS_CROSS_THREAD_FLAGS_TERMINATED bit set.<br />
<br />
Right.....? Wrong!<br />
<br />
KeTerminateThread is exported by the NT module and can be called directly by a thread already running in kernel mode. In this case, the first and second steps will be skipped, but the third will be carried out. Here's a call flow diagram showing these possibilities:<br />
<br />
<a href="https://blogger.googleusercontent.com/img/b/R29vZ2xl/AVvXsEjKsDg22GauyYAtifUnaNcnY7IHkRU4sNNwAmOrJPqNCGmM6m9NUVWO04GmBOBX1Bd8rmNZ28_UA724DFkLTJq3itBMbqFYcglcj71fURLrZubPZCU0uf1ztJu_sdPM0n6hRi7uIN_tcoG2/s1600/threads.png"><img alt="" border="0" id="BLOGGER_PHOTO_ID_5597317468171013106" src="https://blogger.googleusercontent.com/img/b/R29vZ2xl/AVvXsEjKsDg22GauyYAtifUnaNcnY7IHkRU4sNNwAmOrJPqNCGmM6m9NUVWO04GmBOBX1Bd8rmNZ28_UA724DFkLTJq3itBMbqFYcglcj71fURLrZubPZCU0uf1ztJu_sdPM0n6hRi7uIN_tcoG2/s320/threads.png" style="cursor: pointer; display: block; height: 320px; margin: 0px auto 10px; text-align: center; width: 279px;" /></a>Out of the first 15-20 memory dumps from an assortment of XP, 2003, Vista, 2008, and 7 machines that I used for testing, there weren't any false positives found for the DkomExit tag. So although its possible to encounter a false positive, it shouldn't happen frequently...and now you have an explanation to go along with it.<br />
<br />
<span style="font-size: 130%;"><span style="font-weight: bold;">The HideFromDebug Tag</span></span><br />
<br />
As described in a <a href="http://www.codeproject.com/KB/security/AntiReverseEngineering.aspx#ThreadHiding">Code Project article on Anti-Reverse Engineering</a> (this may not be the original source), a thread can "hide" from a debugger by passing the HideThreadFromDebugger class to NtSetInformationThread. This doesn't exactly hide the thread, it just prevents debuggers from receiving events generated by the thread. Malware may do this to prevent analysts from catching breakpoints, for example. To detect threads with this special status, we check if the PS_CROSS_THREAD_FLAGS_HIDEFROMDBG bit is set in _ETHREAD.CrossThreadFlags. Here's an example created by running a compiled copy of the source code in the above article.<br />
<pre><span style="font-size: 85%;">$ python vol.py -f Windows7.vmem --profile=Win7SP0x86 threads -F HideFromDebug
Volatile Systems Volatility Framework 1.4_rc1
------
ETHREAD: 0x84f5a158 Pid: 4052 Tid: 4080
Tags: HideFromDebug
Created: -
Exited: -
Owning Process: 0x84b17998 debugtest.exe
Attached Process: 0x84b17998 debugtest.exe
State: Waiting:DelayExecution
BasePriority: THREAD_PRIORITY_NORMAL
TEB: 0x7ffde000
StartAddress: 0x778764d8
ServiceTable: 0x829a99c0
[0] 0x828b06f0
[1] -
[2] -
[3] -
Win32Thread: 0x00000000
CrossThreadFlags: PS_CROSS_THREAD_FLAGS_HIDEFROMDBG
Eip: 0x778764f4
eax=0x00000000 ebx=0x7ffdf000 ecx=0x00000000
edx=0x778764f4 esi=0x0038fed4 edi=0x00000000
eip=0x778764f4 esp=0x0038fe90 ebp=0x0038fef8 err=0x00000000
cs=0x1b ss=0x23 ds=0x23 es=0x23 gs=0x00 efl=0x00000246
dr0=0x00000000 dr1=0x00000000 dr2=0x00000000
dr3=0x00000000 dr6=0x00000000 dr7=0x00000000</span></pre>
<span style="font-size: 130%;"><span style="font-weight: bold;">The HwBreakpoints Tag</span></span><br />
<br />
This tag is associated with threads that have hardware breakpoints set. Hardware breakpoints are usually configured by attaching to a process with a debugger, as shown in the following screen shot.<br />
<br />
<a href="https://blogger.googleusercontent.com/img/b/R29vZ2xl/AVvXsEj90CecvZO04KzUx74EyYihyphenhyphen66R9VUM59l3l0xWnAEkN56-Vyvm7y1_MOYzb7v5tGT6kxU8J7N2k1iJmvIk0ON8IBnvqqzhejBV-skrhEaVXuKZ75AUo57YTJbhPZmxfRPubqWmeFgiekti/s1600/HwBreakpoints.png"><img alt="" border="0" id="BLOGGER_PHOTO_ID_5597108938981705298" src="https://blogger.googleusercontent.com/img/b/R29vZ2xl/AVvXsEj90CecvZO04KzUx74EyYihyphenhyphen66R9VUM59l3l0xWnAEkN56-Vyvm7y1_MOYzb7v5tGT6kxU8J7N2k1iJmvIk0ON8IBnvqqzhejBV-skrhEaVXuKZ75AUo57YTJbhPZmxfRPubqWmeFgiekti/s320/HwBreakpoints.png" style="cursor: pointer; display: block; height: 223px; margin: 0px auto 10px; text-align: center; width: 320px;" /></a>Information about these breakpoints is stored in each thread's <a href="http://www.sandpile.org/ia32/drx.htm">debug registers</a> (Dr0 - Dr7) all of which are accessible by referencing _ETHREAD.Tcb.TrapFrame. User mode programs can't directly access these fields, but they can use the Win32 API function <a href="http://msdn.microsoft.com/en-us/library/ms679362%28v=vs.85%29.aspx">GetThreadContext</a>. Once in kernel mode, this API copies values from the TrapFrame into a <a href="http://msdn.microsoft.com/en-us/library/ms679284%28v=vs.85%29.aspx">CONTEXT</a> structure that the user mode programs <span style="font-style: italic;">can</span> access. So now you know how to find EIP, EAX, ESP, EFLAGS, SS, DS, and all that good stuff...in case there is ever a reason to check those registers in your Volatility plugins ;-)<br />
<br />
As with some of the other topics we've discussed thus far, threads with hardware breakpoints set are not immediately suspicious. However, it's also not something you ordinarily see and its not unheard of to use hardware breakpoints as a stealthy alternative to <a href="http://research.microsoft.com/en-us/projects/detours/">Trampoline</a> style API hooks. Instead of overwriting instructions in a function's prologue, a rootkit could set an On-Execute hardware breakpoint on the address of an API, and then set up an exception handler that gets called when the breakpoint triggers. Here's an example of using the filter:<br />
<pre><span style="font-size: 85%;">$ python vol.py -f Windows7.vmem --profile=Win7SP0x86 threads -F HwBreakpoints
Volatile Systems Volatility Framework 1.4_rc1
------
ETHREAD: 0x8538d030 Pid: 2360 Tid: 1004
Tags: HwBreakpoints
Created: -
Exited: -
Owning Process: 0x84a488e0 calc.exe
Attached Process: 0x84a488e0 calc.exe
State: Waiting:UserRequest
BasePriority: THREAD_PRIORITY_NORMAL
TEB: 0x7ffdd000
StartAddress: 0x778764d8
ServiceTable: 0x829a99c0
[0] 0x828b06f0
[1] -
[2] -
[3] -
Win32Thread: 0x00000000
CrossThreadFlags: PS_CROSS_THREAD_FLAGS_DEADTHREAD
Eip: 0x778764f4
eax=0x00d9235b ebx=0x00000000 ecx=0x00000000
edx=0x00000000 esi=0x000000f4 edi=0x00000000
eip=0x778764f4 esp=0x02ebf7a0 ebp=0x02ebf80c err=0x00000000
cs=0x1b ss=0x23 ds=0x23 es=0x23 gs=0x00 efl=0x00000246
dr0=0x00d99768 dr1=0x00d9977e dr2=0x00000000
dr3=0x00000000 dr6=0xffff0ff0 dr7=0x00700505</span></pre>
Notice the dr0 value is 0x00d99768 and dr1 is 0x00d9977e - both of the addresses shown in the OllyDbg screenshot.<br />
<br />
The breakpoints described in this section are thread-specific, since each thread has its own set of registers. However, there is another set of processor-specific (thus affecting all threads running on the processor...or <a href="http://msdn.microsoft.com/en-us/library/ff553267%28v=vs.85%29.aspx">affinity</a>) registers where kernel breakpoints can be set. This is how the malware in <a href="http://blogs.mcafee.com/mcafee-labs/memory-forging-attempt-by-a-rootkit">Rachit Mathur's Memory forging attempt by a rootkit</a> blog worked, and I will discuss how to detect that in a separate post later on.<br />
<span style="font-size: 130%;"><br /><span style="font-weight: bold;">The AttachedProcess Tag</span></span><br />
<br />
This tag is associated with threads that are "attached" to another process's address space. Through the use of APIs such as <a href="http://msdn.microsoft.com/en-us/library/ff549659%28v=vs.85%29.aspx">KeAttachProcess and KeStackAttachProcess</a>, kernel drivers can easily read/write data in any process's virtual memory. Although there are legitimate reasons why a thread may be executing in the context of a process other than the process that owns the thread, there are also malicious reasons. For example, the following screen shot shows a rootkit using KeAttachProcess so it can write a DLL into services.exe from kernel mode. Then it <a href="http://www.osronline.com/article.cfm?id=75">queues an APC</a> to start executing at the DLL's entry point.<br />
<br />
<a href="https://blogger.googleusercontent.com/img/b/R29vZ2xl/AVvXsEjDt5vFS3OLZ9a7VImffr_x793EbCBMUnJ1L6sAh9OgrY87rYrxNxB2qdLdi5WohI-ucfRpz_vC4J1e1zC0yPyW6PdGOfGtTdwVVmlx9WDOOlV2AFuKH54hn5jVMX4xocIyYhhy40_cGmE6/s1600/KeAttachProcess.png"><img alt="" border="0" id="BLOGGER_PHOTO_ID_5597132394608769026" src="https://blogger.googleusercontent.com/img/b/R29vZ2xl/AVvXsEjDt5vFS3OLZ9a7VImffr_x793EbCBMUnJ1L6sAh9OgrY87rYrxNxB2qdLdi5WohI-ucfRpz_vC4J1e1zC0yPyW6PdGOfGtTdwVVmlx9WDOOlV2AFuKH54hn5jVMX4xocIyYhhy40_cGmE6/s320/KeAttachProcess.png" style="cursor: pointer; display: block; height: 297px; margin: 0px auto 10px; text-align: center; width: 320px;" /></a>Before moving on, note that the rootkit calls KeDetachProcess when its finished writing to the memory of services.exe. For detection, you must acquire memory <span style="font-style: italic;">after</span> a thread calls KeAttachProcess, but <span style="font-style: italic;">before</span> it calls KeDetachProcess. Since all this can go down pretty quickly, there's a slim chance of catching this particular thread "in the act." Another well known malware family, <a href="http://resources.infosecinstitute.com/tdss4-part-2/">TDL4</a> uses a very similar technique (see section 2.3 Injecting payload into processes). However, not all rootkits work the same way. Other malware may attach to a process, scan that process's memory for credit card numbers every 30 seconds, and only detach when the process terminates or the system shuts down. In that case, you'll catch it every time!<br />
<pre><span style="font-size: 85%;">$ python vol.py -f XPSP3.vmem threads -F AttachedProcess
Volatile Systems Volatility Framework 1.4_rc1
------
ETHREAD: 0x81eda7a0 Pid: 4 Tid: 484
Tags: SystemThread,AttachedProcess,</span><wbr><span style="font-size: 85%;">HookedSSDT
Created: 2011-04-18 16:03:38
Exited: -
Owning Process: 0x823c8830 System
Attached Process: 0x81e3c458 services.exe
State: Running
BasePriority: THREAD_PRIORITY_NORMAL
TEB: 0x00000000
StartAddress: 0xb1805f1a windev-5e93-fd3.sys
ServiceTable: 0x80553020
[0] 0x80501bbc
[0x47] NtEnumerateKey 0xb1805944 windev-5e93-fd3.sys
[0x49] NtEnumerateValueKey 0xb1805aca windev-5e93-fd3.sys
[0x91] NtQueryDirectoryFile 0xb18055ee windev-5e93-fd3.sys
[1] -
[2] -
[3] -
Win32Thread: 0x00000000
CrossThreadFlags: PS_CROSS_THREAD_FLAGS_SYSTEM
b1805f1a: 8bff MOV EDI, EDI
b1805f1c: 55 PUSH EBP
b1805f1d: 8bec MOV EBP, ESP
b1805f1f: 51 PUSH ECX
b1805f20: 51 PUSH ECX</span></wbr></pre>
Notice there are actually 3 tags for this thread. It's a system thread, its currently attached to services.exe although the "System" process owns it, and the SSDT has hooked functions. The thread's start address points to a driver named windev-5e93-fd3.sys which is also the module which owns the SSDT hooks, meaning the rootkit's own threads are using the modified SSDT.<br />
<br />
<span style="font-size: 130%;"><span style="font-weight: bold;">Adding new heuristics </span></span><br />
<br />
Adding new heuristics to the threads plugin is easy. All you do is enter your criteria in the <span style="font-family: courier new;">checks</span> dictionary, with your desired tag as the dictionary key and some function or equation (that evaluates to True/False) as the dictionary's value. Here are a few examples:<br />
<br />
<span style="color: black; font-family: courier new; font-size: 85%;">checks['</span><span style="color: black; font-family: courier new; font-size: 85%;">MyNewTag'] = thread.ThisField == 0xdeadbeef</span><span style="font-size: 85%;"><br /></span><span style="font-family: courier new; font-size: 85%;">checks['MyOtherTag'] = do_something(thread)</span><br />
<br />
Once you've done that, just filter for your new tag:<br />
<br />
<span style="font-family: courier new; font-size: 85%;">$ python vol.py -f memory.dmp threads -F MyNewTag</span><br />
<br />
<span style="font-size: 130%;"><span style="font-weight: bold;">Using Volshell on ETHREAD and KTHREAD<br /></span></span>If you need to explore thread-related data structures a little closer, don't forget about <a href="http://code.google.com/p/volatility/wiki/CommandReference#volshell">volshell</a>. This let's you investigate values that aren't printed by existing plugins - without having to write your own plugin. Just break into a shell and use dt() as shown below.<br />
<pre><span style="font-size: 85%;">$ python vol.py -f ds_fuzz_hidden_proc.img volshell
Volatile Systems Volatility Framework 1.4_rc1
Current context: process System, pid=4, ppid=0 DTB=0x319000
Welcome to volshell!
To get help, type 'hh()'
>>> dt("_ETHREAD", 0x8180b798)
[CType _ETHREAD] @ 0x8180B798
0x0 : Tcb 2172696472
0x1c0 : CreateTime 2008-11-26 07:38:25
0x1c8 : ExitTime 2008-11-26 07:40:25
0x1c8 : KeyedWaitChain 2172696928
0x1c8 : LpcReplyChain 2172696928
0x1d0 : ExitStatus 1
0x1d0 : OfsChain 1
......
>>> dt("_KTHREAD", 0x8180b798)
[CType _KTHREAD] @ 0x8180B798
0x0 : Header 2172696472
0x10 : MutantListHead 2172696488
0x18 : InitialStack 0
0x1c : StackLimit 4162211840
0x20 : Teb 0
0x24 : TlsArray 0
0x28 : KernelStack 4162223128
0x2c : DebugActive 0
0x2d : State 4
.......</span></pre>
<span style="font-size: 130%;"><span style="font-weight: bold;">Conclusion<br /></span></span>At the end of the day, we have a new plugin that combines the functionality of two older plugins, plus introduces several new heuristics that can help analyze threads in physical memory dumps. Not all heuristics indicate something malicious, and not all heuristics are fully safe from carefully planned DKOM attacks. Furthermore, this plugin's output requires a greater understanding of Windows internals than other plugins do (for example, it's not as self-explanatory as "connections" which prints IPs and ports). However, used in the correct manner, this plugin can be extremely useful for your malware related investigations.Michael Hale Lighhttp://www.blogger.com/profile/17377327006242921434noreply@blogger.com2tag:blogger.com,1999:blog-3630199973361886660.post-85028262539256196862011-03-30T09:45:00.002-06:002012-08-05T21:09:10.193-06:00Malware Cookbook DVD Tools OnlineThe Malware Cookbook DVD is online for download. Please see book's website for more information: <a href="http://www.malwarecookbook.com/?p=119">http://www.malwarecookbook.com/?p=119</a>Michael Hale Lighhttp://www.blogger.com/profile/17377327006242921434noreply@blogger.com1tag:blogger.com,1999:blog-3630199973361886660.post-69694523097372855912011-03-24T20:10:00.027-06:002012-08-05T21:09:23.812-06:00Volatility's New Netscan ModuleAs described in Recipe 18-1 "Exploring Socket and Connection Objects" of <a href="http://www.amazon.com/dp/0470613033?tag=malwacookb-20&camp=14573&creative=327641&linkCode=as1&creativeASIN=0470613033&adid=12F8AJTGMCGE1NZB23ZY&">Malware Analyst's Cookbook</a>, enumerating network information in Windows XP memory dumps is fairly straightforward. There is a symbol in tcpip.sys named _TCBTable which points to a list of connection structures and a symbol named _AddrObjTable which points to a list of socket structures. However, starting with Vista, the tcpip.sys module no longer contains either symbol. Microsoft also changed the size and layout of the connection and socket structures, and switched the pool tags for the memory allocations that store the structures. Its almost like they were intentionally trying to make our lives difficult. Then again, it probably has more to do with the <a href="http://technet.microsoft.com/en-us/network/bb545475.aspx">Next Generation TCP/IP Stack</a>.<br />
<br />
In January of this year, I contributed a new <a href="http://code.google.com/p/volatility/">Volatility</a> plugin named <a href="http://code.google.com/p/volatility/source/browse/branches/Volatility-1.4_rc1/volatility/plugins/netscan.py">netscan</a> which can list IPv4 and IPv6 connections and sockets, both TCP and UDP, for 32-bit Windows Vista, 2008, and 7 memory dumps. This post describes how I found the information, and how you might do the same if Microsoft decides to completely redesign the TCP/IP stack for future operating systems.<br />
<br />
Regardless of what changes, one thing you can probably take for granted is that netstat.exe will always work. Thus, determining where netstat.exe gets its information is a good start. The following screen shot shows that the Windows 7 netstat.exe calls some functions exported by the iphlpapi.dll module. In particular, for TCPv4 data it calls InternalGetTcpTable2 or InternalGetTcpTableWithOwnerModule. It calls similar functions for TCPv6 data and for UDPv4 and UDPv6.<br />
<br />
<a href="https://blogger.googleusercontent.com/img/b/R29vZ2xl/AVvXsEho8iKoPsa25ry6KgMD5ap6T0hE7TpNubIcr5J62sAnZdcm0BkgBGjsEuTBwA4HTyhCbBsaGS1jJoGmrrHlKDKzJ0zKzIY1GmHs9H0UdOls6wF2RIvsKz_CvfKTx-mmDqTJ2z-Fqw4POBgT/s1600/Netstat.png"><img alt="" border="0" id="BLOGGER_PHOTO_ID_5587852728043666674" src="https://blogger.googleusercontent.com/img/b/R29vZ2xl/AVvXsEho8iKoPsa25ry6KgMD5ap6T0hE7TpNubIcr5J62sAnZdcm0BkgBGjsEuTBwA4HTyhCbBsaGS1jJoGmrrHlKDKzJ0zKzIY1GmHs9H0UdOls6wF2RIvsKz_CvfKTx-mmDqTJ2z-Fqw4POBgT/s320/Netstat.png" style="cursor: pointer; display: block; height: 195px; margin: 0px auto 10px; text-align: center; width: 320px;" /></a>Although InternalGetTcpTable2 is undocumented, it is essentially just a wrapper around the documented <a href="http://msdn.microsoft.com/en-us/library/bb408406%28v=vs.85%29.aspx">GetTcpTable2</a> API which fills in a <a href="http://msdn.microsoft.com/en-us/library/bb485772%28v=vs.85%29.aspx">MIB_TCPTABLE2</a> structure. Each table entry, known as a <a href="http://msdn.microsoft.com/en-us/library/bb485761%28v=vs.85%29.aspx">MIB_TCPROW2 </a>contains the following information:<br />
<pre><span style="font-size: 85%;">typedef struct _MIB_TCPROW2 {
DWORD dwState;
DWORD dwLocalAddr;
DWORD dwLocalPort;
DWORD dwRemoteAddr;
DWORD dwRemotePort;
DWORD dwOwningPid;
TCP_CONNECTION_OFFLOAD_STATE dwOffloadState;
} MIB_TCPROW2, *PMIB_TCPROW2;</span></pre>
So how does GetTcpTable2 get the information to fill these rows/tables? To find out, follow the trail and you'll see that it calls NsiAllocateAndGetTable - a function exported by nsi.dll. The function fills three arrays of structures (AddrTable, StateTable, and OwnerTable) with data. The TcpConnCount argument is filled with the number of structures in each array. GetTcpTable2 then loops through the results and initializes the MIB_TCPROW2 structures.<br />
<br />
<a href="https://blogger.googleusercontent.com/img/b/R29vZ2xl/AVvXsEg9FSuPLuw-Uem5k-eXH50jZovwcDOEkyhgrYcNK-yPsZkxUuWyp_lgZO4yNLTkXCGWROUQdif-CKmKMLbVj0PAPeFwvF_AHDJL2GV6a8O2EYM0xHo40Hotovy91pTf4eGIgNnE7h-yRAPQ/s1600/Iphlpapi.png"><img alt="" border="0" id="BLOGGER_PHOTO_ID_5587860843926109522" src="https://blogger.googleusercontent.com/img/b/R29vZ2xl/AVvXsEg9FSuPLuw-Uem5k-eXH50jZovwcDOEkyhgrYcNK-yPsZkxUuWyp_lgZO4yNLTkXCGWROUQdif-CKmKMLbVj0PAPeFwvF_AHDJL2GV6a8O2EYM0xHo40Hotovy91pTf4eGIgNnE7h-yRAPQ/s320/Iphlpapi.png" style="cursor: pointer; display: block; height: 285px; margin: 0px auto 10px; text-align: center; width: 320px;" /></a> NsiAllocateAndGetTable leads to two other functions, which are both contained within nsi.dll - NsiEnumerateObjectsAllParameters and NsiEnumerateObjectsAllParametersEx. Here we see a handle to "\\\\.\\Nsi" opened and an IOCTL of 12001Bh sent with NtDeviceIoControlFile. The Input (and Output) buffer for the I/O operation points to memory allocated to store the three arrays of structures described earlier, among other things. I'll call this structure NSI_PARAMS. We must now track this buffer into kernel mode to find out how its filled. The driver which owns "\\\\.\\Nsi" is nsiproxy.sys, so we continue the search there.<br />
<br />
Inside the dispatch routine for nsiproxy.sys, there is a switch statement with the IoControlCode as the case. The disassembly below shows 120023h (maximum IoControlCode) being moved into EBX, which is then decremented by 1 until the result is 0 - a common shortcut that compilers use for switch statements. The memory buffer is moved into EDX and NsippEnumerateObjectsAllParameters is called.<br />
<pre class="wiki"><span style="font-size: 85%;"><span style="font-family: courier new;">.text:00012EA0 mov ebx, [ecx+</span><span style="font-family: courier new;">IO_STACK_LOCATION.Parameters.DeviceIoControl.IoControlCode]</span>
<span style="font-family: courier new;">.text:00012EA3 cmp ebx, 120023h</span>
<span style="font-family: courier new;">.text:00012EA9 push edi</span>
<span style="font-family: courier new;">.text:00012EAA mov edi, [ecx+</span><span style="font-family: courier new;">IO_STACK_LOCATION.Parameters.DeviceIoControl.InputBufferLength]</span>
<span style="font-family: courier new;">.text:00012EAD mov [ebp+Irql], edx</span>
<span style="font-family: courier new;">.text:00012EB0 mov edx, [ecx+</span><span style="font-family: courier new;">IO_STACK_LOCATION.Parameters.DeviceIoControl.Type3InputBuffer]</span>
<span style="font-family: courier new;">[snip]</span>
<span style="font-family: courier new;">.text:00012EF1 push esi ; int</span>
<span style="font-family: courier new;">.text:00012EF2 push [ebp+8] ; pOutputBuffer</span>
<span style="font-family: courier new;">.text:00012EF5 push edi ; InputBufferLength</span>
<span style="font-family: courier new;">.text:00012EF6 push edx ; Type3InputBuffer</span>
<span style="font-family: courier new;">.text:00012EF7 call _NsippEnumerateObjectsAllParameters</span></span></pre>
NsippEnumerateObjectsAllParameters passes control to a similarly named function - NsiEnumerateObjectsAllParametersEx - but not the same one we discussed earlier from nsi.dll. This second one is exported by netio.sys. What more could you expect from a module named nsiproxy.sys? As the name suggests, nsiproxy.sys sits between nsi.dll in user mode and netio.sys in kernel mode.<br />
<br />
Tracking the three arrays of structures (AddrTable, StateTable, and OwnerTable) becomes a little convoluted at this point, because netio.sys calls a function named NsipConvertNaEnumerateObjectsAllParametersRequestToNmRequest, which takes several members of the NSI_PARAMS structure and moves them to different offsets of a new structure which I'll call NM_REQUEST. After doing so, it passes a pointer to the NM_REQUEST structure to TcpEnumerateAllConnections in tcpip.sys. As you can see in the following screen shot, depending on your command line arguments to netstat.exe, TcpEnumerateConnections(AF_INET, ...) will be called for IPv4 connections, TcpEnumerateConnections(AF_INET6, ...) will be called for IPv6 connections, and TcpEnumerateListeners will be called for both IPv4 and IPv6 sockets.<br />
<br />
<a href="https://blogger.googleusercontent.com/img/b/R29vZ2xl/AVvXsEhIc_OKfWUdaknG3m4SUBuUiDb5GfpVkXWfpaNGZXvcWFrZ-VbKMdb6wUr0qfue_K4oY-DcwpR3PxZ4MqzaPOpj8lfjS3-8UICafSJ624J6r2mdtzhAHV0KUNyB09M2m8B3DBSn5tL012da/s1600/Tcpip.png"><img alt="" border="0" id="BLOGGER_PHOTO_ID_5588016907615490034" src="https://blogger.googleusercontent.com/img/b/R29vZ2xl/AVvXsEhIc_OKfWUdaknG3m4SUBuUiDb5GfpVkXWfpaNGZXvcWFrZ-VbKMdb6wUr0qfue_K4oY-DcwpR3PxZ4MqzaPOpj8lfjS3-8UICafSJ624J6r2mdtzhAHV0KUNyB09M2m8B3DBSn5tL012da/s320/Tcpip.png" style="cursor: pointer; display: block; height: 252px; margin: 0px auto 10px; text-align: center; width: 320px;" /></a>The authoritative source of networking information can't be too far away at this point. In fact, right inside the last functions I mentioned, there are some symbols which tcpip.sys uses to locate lists of connections and sockets. Take the "lists" keyword lightly, as they are not singly-linked lists or doubly-linked lists as they have been in the past. Instead, connections are stored in a hash table (i.e. RtlInitWeakEnumerationHashTable) and sockets are stored in a bitmap port pool. You can read more about the Windows implementation of bitmap (RTL_BITMAP) in OSR's <a href="http://www.osronline.com/article.cfm?article=523">Kernel Mode Basics: An Introduction to Bitmaps</a>.<br />
<br />
When you parse the hash tables and bitmaps, you'll find the primary connections and socket structures. From there, its just a matter of using WinDbg's !pool command (see <a href="http://analyze-v.com/?p=734">Scott Noone's Interpreting !pool results</a>) to learn how to locate the structures in a physical memory dump. I found that TCP connections were in pools tagged with TcpE (the E is for Endpoint), TCP sockets were in pools tagged with TcpL (the L is for Listener), and UDP endpoints and sockets are in pools tagged with UdpA. The <a href="http://code.google.com/p/volatility/wiki/Scanners">Volatility object scanning framework</a> makes it very easy to take the output from !pool and create a pool scanner plugin.<br />
<br />
For a summary of the path we've taken from netstat.exe into tcpip.sys, see the following diagram. Also note that rootkits on a live system can place hooks in any of these modules to hide connections or sockets on a live system.<br />
<br />
<a href="https://blogger.googleusercontent.com/img/b/R29vZ2xl/AVvXsEhKttjiFpeTW-GLYRhjDJ8VK3Ehe884HXM3QzNpMIRHHRvpg8mB4iFBGJw5GC1Ijn2fJan1TPnm6WBq20XfPMyJcox14wJvaBU0GhDuFDADkpMoszvQHKkAgC1PhyphenhyphenFQZk1etLg_-6kfEryq/s1600/netstat-diag.png"><img alt="" border="0" id="BLOGGER_PHOTO_ID_5588032018951851202" src="https://blogger.googleusercontent.com/img/b/R29vZ2xl/AVvXsEhKttjiFpeTW-GLYRhjDJ8VK3Ehe884HXM3QzNpMIRHHRvpg8mB4iFBGJw5GC1Ijn2fJan1TPnm6WBq20XfPMyJcox14wJvaBU0GhDuFDADkpMoszvQHKkAgC1PhyphenhyphenFQZk1etLg_-6kfEryq/s320/netstat-diag.png" style="cursor: pointer; display: block; height: 320px; margin: 0px auto 10px; text-align: center; width: 253px;" /></a>Finally, Volatility's <a href="http://code.google.com/p/volatility/wiki/CommandReference#netscan">command reference</a> shows example output from the netscan plugin. Contrary to popular belief, the long awaited Volatility 1.4 has not yet been released, although the netscan code is already showing up in <a href="http://cci.cocolog-nifty.com/blog/2011/03/memory-forensic.html">other memory forensics tools</a> (see Windows7\ConnScan.EnScript). Its definitely interesting to see the influence that Volatility has on the industry.Michael Hale Lighhttp://www.blogger.com/profile/17377327006242921434noreply@blogger.com8tag:blogger.com,1999:blog-3630199973361886660.post-47512480519819805282011-03-18T11:54:00.009-06:002012-08-05T21:09:43.124-06:00The Mis-leading 'Active' in PsActiveProcessHead and ActiveProcessLinksOn Windows, <a href="http://www.google.com/search?q=psactiveprocesshead">the nt!PsActiveProcessHead symbol</a> points to a doubly-linked list of EPROCESS objects. It is very well documented as being the primary source of "current" or "active" processes. However, while using <a href="http://code.google.com/p/volatility/">Volatility</a> to analyze a Windows 7 memory dump, <a href="http://gleeda.blogspot.com/">Gleeda</a> and I discovered that the <a href="http://code.google.com/p/volatility/wiki/CommandReference#pslist">pslist command</a> was showing something odd. In fact, I noticed the odd behavior a while back and never got a chance to look into it. The odd thing was that the pslist included info for some terminated processes. But shouldn't everything in PsActiveProcessHead and ActiveProcessLinks be, well...active?<br />
<br />
For example, take a look at the following output. The MSBuild.exe and 4 copies of vcpkgsrv.exe are all in the doubly-linked list, but none of them are still running.<br />
<br />
<span style="font-family: courier new; font-size: 85%;">$ python vol.py -f Windows7.vmem --profile=Win7SP0x86 pslist</span><span style="font-size: 85%;"><br /></span><span style="font-family: courier new; font-size: 85%;">Volatile Systems Volatility Framework 1.4_rc1</span><span style="font-size: 85%;"><br /></span><span style="font-family: courier new; font-size: 85%;">Name Pid PPid Thds Hnds Time</span><span style="font-size: 85%;"><br /></span><span style="font-family: courier new; font-size: 85%;">System 4 0 94 467 2011-02-16 14:18:23</span><span style="font-size: 85%;"><br /></span><span style="font-family: courier new; font-size: 85%;">smss.exe 256 4 2 29 2011-02-16 14:18:23</span><span style="font-size: 85%;"><br /></span><span style="font-family: courier new; font-size: 85%;">csrss.exe 344 336 10 718 2011-02-16 14:18:33</span><span style="font-size: 85%;"><br /></span><span style="font-family: courier new; font-size: 85%;">[snip]</span><span style="font-size: 85%;"><br /></span><span style="font-family: courier new; font-size: 85%;">svchost.exe 3388 512 14 346 2011-02-16 14:20:58</span><span style="font-size: 85%;"><br /></span><span style="font-family: courier new; font-size: 85%;">devenv.exe 3640 1148 20 713 2011-02-16 14:21:29</span><span style="font-size: 85%;"><br /></span><span style="font-family: courier new; font-size: 85%;">MSBuild.exe 2732 3640 0 ------ 2011-02-16 14:30:01</span><span style="font-size: 85%;"><br /></span><span style="font-family: courier new; font-size: 85%;">vcpkgsrv.exe 3900 3640 0 ------ 2011-02-16 14:39:52</span><span style="font-size: 85%;"><br /></span><span style="font-family: courier new; font-size: 85%;">vcpkgsrv.exe 3496 3640 0 ------ 2011-02-16 14:52:28</span><span style="font-size: 85%;"><br /></span><span style="font-family: courier new; font-size: 85%;">vcpkgsrv.exe 3984 3640 0 ------ 2011-02-16 14:52:38</span><span style="font-size: 85%;"><br /></span><span style="font-family: courier new; font-size: 85%;">vcpkgsrv.exe 188 3640 0 ------ 2011-02-16 14:56:19</span><span style="font-size: 85%;"><br /></span><span style="font-family: courier new; font-size: 85%;">[snip]</span><br />
<br />
To make sure the output is accurate, I cross-referenced the data with WinDbg on the machine from which the memory dump was acquired. Using a command presented in Chapter 14 of Malware Analyst's Cookbook (and later enhanced by <a href="http://www.msuiche.net/">Matthieu Suiche</a>), I asked the debugger to print information on the objects in PsActiveProcessHead. Sure enough, it too shows that these inactive processes are still in the active process list:<br />
<br />
<span style="font-family: courier new; font-size: 85%;">kd> !list "-t nt!_EPROCESS.ActiveProcessLinks.Flink -e -x \"dt nt!_EPROCESS ImageFileName\"(poi(nt!PsActiveProcessHead)-@@c++(#FIELD_OFFSET(nt!_EPROCESS,ActiveProcessLinks)))"</span><span style="font-size: 85%;"><br /></span><span style="font-family: courier new; font-size: 85%;">[snip]</span><span style="font-size: 85%;"><br /></span><span style="font-family: courier new; font-size: 85%;">kd> dt nt!_EPROCESS ImageFileName 0xffffffff8435ba58</span><span style="font-size: 85%;"><br /></span><span style="font-family: courier new; font-size: 85%;">+0x16c ImageFileName : [15] "MSBuild.exe"</span><span style="font-size: 85%;"><br /></span><span style="font-family: courier new; font-size: 85%;">kd> dt nt!_EPROCESS ImageFileName 0xffffffff8436e548</span><span style="font-size: 85%;"><br /></span><span style="font-family: courier new; font-size: 85%;">+0x16c ImageFileName : [15] "vcpkgsrv.exe"</span><span style="font-size: 85%;"><br /></span><span style="font-family: courier new; font-size: 85%;">kd> dt nt!_EPROCESS ImageFileName 0xffffffff86177030</span><span style="font-size: 85%;"><br /></span><span style="font-family: courier new; font-size: 85%;">+0x16c ImageFileName : [15] "vcpkgsrv.exe"</span><span style="font-size: 85%;"><br /></span><span style="font-family: courier new; font-size: 85%;">kd> dt nt!_EPROCESS ImageFileName 0xffffffff843c0380</span><span style="font-size: 85%;"><br /></span><span style="font-family: courier new; font-size: 85%;">+0x16c ImageFileName : [15] "vcpkgsrv.exe"</span><span style="font-size: 85%;"><br /></span><span style="font-family: courier new; font-size: 85%;">kd> dt nt!_EPROCESS ImageFileName 0xffffffff854d91a8</span><span style="font-size: 85%;"><br /></span><span style="font-family: courier new; font-size: 85%;">+0x16c ImageFileName : [15] "vcpkgsrv.exe"</span><span style="font-size: 85%;"><br /></span><span style="font-family: courier new; font-size: 85%;">[snip]</span><br />
<br />
How do I know that these processes are not actually running? Well for one, Volatility reports zero threads and an invalid EPROCESS.ObjectTable (handle table) pointer. Plus tools like <a href="http://technet.microsoft.com/en-us/sysinternals/bb896653">SysInternals Process Explorer</a> don't show anything about them.<br />
<br />
So the questions are:<br />
<br />
1) When do processes get removed from the PsActiveProcessHead<br />
2) What are the conditions (if any) that must be met before removal takes place<br />
<br />
Until recently, I thought that the answer to number 1 was obvious - a process is removed from PsActiveProcessHead immediately after it terminates. But that's not the case. I searched a bit in <a href="http://www.amazon.com/Windows%C3%82%C2%AE-Internals-Including-Windows-PRO-Developer/dp/0735625301">Windows Internals 5th Edition</a>, which discusses process creation in great detail. However, it doesn't cover too much of process termination. Instead I used the trusty <a href="http://www.hex-rays.com/idapro/">IDA Pro</a> to find which function is responsible for removing a process. It happens inside nt!PspProcessDelete:<br />
<br />
<a href="https://blogger.googleusercontent.com/img/b/R29vZ2xl/AVvXsEjHFas-s2ZOd-jjV2EkpOK5z8taByaOf7YjtDaKPZURipBpCeXEAtyNxGzN1CgfVVViWhecpjCgqzIhnm5HpEmHB8TO-r8-a9YJNWTTKzRrARY516g1UFizd7Cy1ilTS373C-xtJ5wVf1sk/s1600/PspDeleteProcess.png"><img alt="" border="0" id="BLOGGER_PHOTO_ID_5585492604967611586" src="https://blogger.googleusercontent.com/img/b/R29vZ2xl/AVvXsEjHFas-s2ZOd-jjV2EkpOK5z8taByaOf7YjtDaKPZURipBpCeXEAtyNxGzN1CgfVVViWhecpjCgqzIhnm5HpEmHB8TO-r8-a9YJNWTTKzRrARY516g1UFizd7Cy1ilTS373C-xtJ5wVf1sk/s320/PspDeleteProcess.png" style="cursor: pointer; display: block; height: 212px; margin: 0px auto 10px; text-align: center; width: 320px;" /></a>Now the question changes to "when is PspProcessDelete called." It isn't called directly by any function. Rather, it is moved into the <a href="http://www.ivanlef0u.tuxfamily.org/?p=79">DeleteProcedure member of an OBJECT_TYPE_INITIALIZER</a> structure when the kernel first defines the default behaviors for all EPROCESS objects. This happens in nt!PspInitPhase0:<br />
<br />
<a href="https://blogger.googleusercontent.com/img/b/R29vZ2xl/AVvXsEhghXt02JhcZOSoXG2TyOJzuBxTFTaPQhNeXVrRljV96FB8ugyIt9mY-eZsoAboWT1bSSF7bqNbruEERzMhcZ5wQrcoOxWt7SH2OCsobBqbCTybN96HmZ5Hw71EpwRJbwpV_rAXF8RIt9h7/s1600/PspInitPhase0.png"><img alt="" border="0" id="BLOGGER_PHOTO_ID_5585495247939093282" src="https://blogger.googleusercontent.com/img/b/R29vZ2xl/AVvXsEhghXt02JhcZOSoXG2TyOJzuBxTFTaPQhNeXVrRljV96FB8ugyIt9mY-eZsoAboWT1bSSF7bqNbruEERzMhcZ5wQrcoOxWt7SH2OCsobBqbCTybN96HmZ5Hw71EpwRJbwpV_rAXF8RIt9h7/s320/PspInitPhase0.png" style="cursor: pointer; display: block; height: 167px; margin: 0px auto 10px; text-align: center; width: 320px;" /></a>After seeing these clues, the <a href="http://www.osronline.com/DDKx/kmarch/objects_16av.htm">life cycle of an object</a> came into mind. Also as described in Windows Internals, the Object Manager tracks handles and references to an object, and only allows the object to be freed when the reference count reaches zero. And now it makes sense how a process can terminate but stay in the PsActiveProcessHead linked list. Here's a description of what I believe to be the most likely explanation:<br />
<br />
1) Process A (the parent) creates Process B with an API such as <a href="http://msdn.microsoft.com/en-us/library/ms682425%28v=vs.85%29.aspx">CreateProcess</a>. The <a href="http://msdn.microsoft.com/en-us/library/ms684873%28v=vs.85%29.aspx">PROCESS_INFORMATION</a> parameter to this API is filled with a handle to Process B if the creation is successful.<br />
<br />
2) Process B is terminated, either on its own or as the result of a user killing it. At this point, the thread count reaches zero, the EPROCESS.ObjectTable is set to NULL, and the EPROCESS.ExitTime is filled in.<br />
<br />
3) Process A fails to call CloseHandle to decrement the reference count on Process B. Thus, the DeleteProcedure for Process B is never called and it is never removed from PsActiveProcessHead.<br />
<br />
To test out my theory, I wrote a simple program that looks like this:<br />
<br />
<span style="font-family: courier new; font-size: 85%;">void main (void)</span><span style="font-size: 85%;"><br /></span><span style="font-family: courier new; font-size: 85%;">{</span><span style="font-size: 85%;"><br /></span><span style="font-family: courier new; font-size: 85%;"> STARTUPINFOA StartupInfo;</span><span style="font-size: 85%;"><br /></span><span style="font-family: courier new; font-size: 85%;"> PROCESS_INFORMATION ProcessInfo;</span><span style="font-size: 85%;"><br /></span><span style="font-family: courier new; font-size: 85%;"> ZeroMemory(&StartupInfo, sizeof(STARTUPINFOA));</span><span style="font-size: 85%;"><br /></span><span style="font-family: courier new; font-size: 85%;"> ZeroMemory(&ProcessInfo, sizeof(PROCESS_INFORMATION));</span><span style="font-size: 85%;"><br /></span><span style="font-family: courier new; font-size: 85%;"> StartupInfo.cb = sizeof(STARTUPINFOA);</span><span style="font-size: 85%;"><br /></span><span style="font-family: courier new; font-size: 85%;"> CreateProcessA(NULL, "notepad.exe", NULL, NULL, FALSE, 0, NULL, NULL, &StartupInfo, &ProcessInfo);</span><span style="font-size: 85%;"><br /></span><span style="font-family: courier new; font-size: 85%;"> getchar(); //block until user presses a key</span><span style="font-size: 85%;"><br /></span><span style="font-family: courier new; font-size: 85%;"> CloseHandle(ProcessInfo.hThread);</span><span style="font-size: 85%;"><br /></span><span style="font-family: courier new; font-size: 85%;"> CloseHandle(ProcessInfo.hProcess);</span><span style="font-size: 85%;"><br /></span><span style="font-family: courier new; font-size: 85%;">}</span><br />
<br />
The program creates a child process (notepad.exe) and remains running. This gives you a chance to use tools and verify the two new processes were created. Then you can close notepad.exe and watch it disappear from Process Explorer, but remain in PsActiveProcessHead (via the WinDbg command or Volatility's pslist). It is only when you type a character into my sample program that it progresses past the getchar() call. At this point, it closes its handle to notepad.exe, the reference count reaches zero, the EPROCESS object is marked for deletion, and it is removed from PsActiveProcessHead.<br />
<br />
Before today, I would have said that <a href="http://code.google.com/p/volatility/wiki/CommandReference#psscan2">an object scanning technique</a> was the only way to identify terminated processes in a memory dump, but now we have another. Of course, it takes some getting lucky - for example a malware sample that launches various child processes and never closes the handles even after the child processes die.<br />
<br />
And that, my friends, is the story of the mis-leading 'Active' in PsActiveProcessHead and ActiveProcessLinks!Michael Hale Lighhttp://www.blogger.com/profile/17377327006242921434noreply@blogger.com5tag:blogger.com,1999:blog-3630199973361886660.post-81702635218882801582010-10-25T19:31:00.007-06:002012-08-05T21:49:21.258-06:00Malware Analyst's Cookbook and WebsiteI'm pleased to announce the availability of <a href="http://www.amazon.com/gp/product/0470613033/">Malware Analyst's Cookbook.</a> At nearly 700 pages, the book contains hundreds of recipes describing malware analysis tools and techniques. Many of the tools are exclusive to the DVD which is distributed with the book (note: the DVD is not available for the Kindle version). The book's errata, bug reports, and future code releases will be posted at <a href="http://www.malwarecookbook.com/">www.malwarecookbook.com</a>.<br />
<a href="http://ecx.images-amazon.com/images/I/51GypJuvi6L._BO2,204,203,200_PIsitb-sticker-arrow-click,TopRight,35,-76_AA300_SH20_OU01_.jpg"><br /></a>Here is a list of the recipes:<br />
<br />
Anonymizing Your Activities<br />
<ul>
<li> Anonymous Web Browsing with Tor</li>
<li> Wrapping Wget and Network Clients with Torsocks</li>
<li> Multi-platform Tor-enabled Downloader in Python</li>
<li> Forwarding Traffic Through Open Proxies</li>
<li> Using SSH Tunnels to Proxy Connections</li>
<li> Privacy-enhanced Web Browsing with Privoxy</li>
<li> Anonymous Surfing with Anonymous.org</li>
<li> Internet Access Through Cellular Networks</li>
<li> Using VPNs with Anonymizer Universal</li>
</ul>
Honeypots<br />
<ul>
<li> Collecting Malware Samples with Nepenthes</li>
<li> Real-time Attack Monitoring with IRC Logging</li>
<li> Accepting Nepenthes Submissions over HTTP in Python</li>
<li> Collecting Malware Samples with Dionaea</li>
<li> Accepting Dionaea Submissions over HTTP in Python</li>
<li> Real-time Event Notification and Binary Sharing with XMPP</li>
<li> Analyzing and Replaying Attacks Logged by Dionaea</li>
<li> Passive Identification of Remote Systems with p0f</li>
<li> Graphing Dionaea Attack Patterns with SQLite3 and Gnuplot</li>
</ul>
Malware Classification<br />
<ul>
<li> Examining Existing ClamAV Signatures</li>
<li> Creating a Custom ClamAV Database</li>
<li> Converting ClamAV Signatures to YARA</li>
<li> Identifying Packers with YARA and PEiD</li>
<li> Detecting Malware Capabilities with YARA</li>
<li> File Type Identification and Hashing in Python</li>
<li> Writing a Multiple-AV Scanner in Python</li>
<li> Detecting Malicious PE Files in Python</li>
<li> Finding Similar Malware with ssdeep</li>
<li> Detecting Self-modifying Code with ssdeep</li>
<li> Comparing Binaries with IDA and BinDiff</li>
</ul>
Sandboxes and Multi-AV Scanners<br />
<ul>
<li> Scanning Files with VirusTotal</li>
<li> Scanning Files with Jotti</li>
<li> Scanning Files with NoVirusThanks</li>
<li> Database-enabled Multi-AV Uploader in Python</li>
<li> Analyzing Malware with ThreatExpert</li>
<li> Analyzing Malware with CWSandbox</li>
<li> Analyzing malware with Anubis</li>
<li> Writing AutoIT Scripts for Joebox</li>
<li> Defeating Path-dependent Malware with Joebox</li>
<li> Defeating Process-dependent DLLs with Joebox</li>
<li> Setting an Active HTTP Proxy with Joebox</li>
<li> Scanning for Artifacts with Sandbox Results</li>
</ul>
Domains and IP Addresses<br />
<ul>
<li> Researching Domains with WHOIS</li>
<li> Resolving DNS Hostnames</li>
<li> Obtaining IP WHOIS Records</li>
<li> Querying Passive DNS with BFK</li>
<li> Checking DNS Records with Robtex</li>
<li> Performing a Reverse IP Search with DomainTools</li>
<li> Initiating Zone Transfers with dig</li>
<li> Brute-forcing Subdomains with dnsmap</li>
<li> Mapping IP Addresses to ASNs via Shadowserver</li>
<li> Checking IP Reputation with RBLs</li>
<li> Detecting Fast Flux with Passive DNS and TTLs</li>
<li> Tracking Fast Flux Domains with Tracker</li>
<li> Static Maps with Maxmind, Matplotlib and pygoeip</li>
<li> Interactive Maps with Google Charts API</li>
</ul>
Malicious Documents and URLs<br />
<ul>
<li> Analyzing JavaScript with Spidermonkey</li>
<li> Automatically Decoding JavaScript with Jsunpack</li>
<li> Optimizing Jsunpack-n Decodings for Speed and Completeness</li>
<li> Triggering Exploits by Emulating Browser DOM Elements</li>
<li> Extracting JavaScript from PDF Files with pdf.py</li>
<li> Triggering Exploits by Faking PDF Software Versions</li>
<li> Leveraging Didier Stevens's PDF Tools</li>
<li> Determining which Vulnerabilities a PDF File Exploits</li>
<li> Disassembling Shellcode with DiStorm</li>
<li> Emulating Shellcode with Libemu</li>
<li> Analyzing Microsoft Office Files with OfficeMalScanner</li>
<li> Debugging Office Shellcode with DisView and MalHost-Setup</li>
<li> Extracting HTTP Files from Packet Captures with Jsunpack</li>
<li> Graphing URL Relationships with Jsunpack</li>
</ul>
Malware Labs<br />
<ul>
<li> Routing TCP/IP Connections in Your Lab</li>
<li> Capturing and Analyzing Network Traffic</li>
<li> Simulating the Internet with INetSim</li>
<li> Manipulating HTTP/HTTPS with Burp Proxy</li>
<li> Using Joe Stewart's Truman</li>
<li> Preserving Physical Systems with Deep Freeze</li>
<li> Cloning and Imaging Disks with FOG</li>
<li> Automating FOG Tasks with the MySQL Database</li>
</ul>
Automation<br />
<ul>
<li> Automated Malware Analysis with VirtualBox</li>
<li> Working with VirtualBox Disk and Memory Images</li>
<li> Automated Malware Analysis with VMware</li>
<li> Capturing Packets with TShark via Python</li>
<li> Collecting Network Logs with INetSim via Python</li>
<li> Analyzing Memory Files with Volatility</li>
<li> Putting All the Sandbox Pieces Together</li>
<li> Automated Analysis with Zero Wine and QEMU</li>
<li> Automated Analysis with Sandboxie and Buster</li>
</ul>
Dynamic Analysis<br />
<ul>
<li> Logging API Calls with Process Monitor</li>
<li> Change Detection with Regshot</li>
<li> Receiving File System Change Notifications</li>
<li> Receiving Registry Change Notifications</li>
<li> Handle Table Diffing</li>
<li> Exploring Code Injection with HandleDiff</li>
<li> Watching Bankpatch.C Disable Windows File Protection</li>
<li> Building an API Monitor with Microsoft Detours</li>
<li> Following Child Processes with your API Monitor</li>
<li> Capturing Process, Thread, and Image Load Events</li>
<li> Preventing Processes from Terminating</li>
<li> Preventing Malware from Deleting Files</li>
<li> Preventing Drivers from Loading</li>
<li> Using the Data Preservation Module</li>
<li> Creating a Custom Command Shell with ReactOS</li>
</ul>
Malware Forensics<br />
<ul>
<li> Discovering Alternate Data Streams with TSK</li>
<li> Detecting Hidden Files and Directories with TSK</li>
<li> Finding Hidden Registry Data with Microsoft's Offline API</li>
<li> Bypassing Poison Ivy's Locked Files</li>
<li> Bypassing Conficker's File System ACL Restrictions</li>
<li> Scanning for Rootkits with GMER</li>
<li> Detecting HTML Injection by Inspecting IE's DOM</li>
<li> Registry Forensics with RegRipper Plug-ins</li>
<li> Detecting Rogue Installed PKI Certificates</li>
<li> Examining Malware that Leaks Data into the Registry</li>
</ul>
Debugging Malware<br />
<ul>
<li> Opening and Attaching to Processes</li>
<li> Configuring a JIT Debugger for Shellcode Analysis</li>
<li> Getting Familiar with the Debugger GUI</li>
<li> Exploring Process Memory and Resources</li>
<li> Controlling Program Execution</li>
<li> Setting and Catching Breakpoints</li>
<li> Using Conditional Log Breakpoints</li>
<li> Debugging with Python Scripts and PyCommands</li>
<li> Detecting Shellcode in Binary Files</li>
<li> Investigating Silentbanker's API Hooks</li>
<li> Manipulating Process Memory with WinAppDbg Tools</li>
<li> Designing a Python API Monitor with WinAppDbg</li>
</ul>
De-Obfuscation<br />
<ul>
<li> Reversing XOR Algorithms in Python</li>
<li> Detecting XOR Encoded Data with yaratize</li>
<li> Decoding Base64 with Special Alphabets</li>
<li> Isolating Encrypted Data in Packet Captures</li>
<li> Finding Crypto with SnD Reverser Tool, FindCrypt, and Kanal</li>
<li> Porting OpenSSL Symbols with Zynamics BinDiff</li>
<li> Decrypting Data in Python with PyCrypto</li>
<li> Finding OEP in Packed Malware</li>
<li> Dumping Process Memory with LordPE</li>
<li> Rebuilding Import Tables with ImpREC</li>
<li> Cracking Domain Generation Algorithms</li>
<li> Decoding Strings with x86emu and Python</li>
</ul>
Working with DLLs<br />
<ul>
<li> Enumerating DLL Exports</li>
<li> Executing DLLs with rundll3exe</li>
<li> Bypassing Host Process Restrictions</li>
<li> Calling DLL Exports Remotely with rundll32ex</li>
<li> Debugging DLLs with LOADDLL.EXE</li>
<li> Catching Breakpoints on DLL Entry Points</li>
<li> Executing DLLs as a Windows Service</li>
<li> Converting DLLs to Standalone Executables</li>
</ul>
Kernel Debugging<br />
<ul>
<li> Local Debugging with LiveKd</li>
<li> Enabling the Kernel's Debug Boot Switch</li>
<li> Debug a VMware Workstation Guest (on Windows)</li>
<li> Debug a Parallels Guests (on Mac OS X)</li>
<li> Introduction to WinDbg Commands and Controls</li>
<li> Exploring Processes and Process Contexts</li>
<li> Exploring Kernel Memory</li>
<li> Catching Breakpoints on Driver Load</li>
<li> Unpacking Drivers to OEP</li>
<li> Dumping and Rebuilding Kernel Drivers</li>
<li> Detecting Rootkits with WinDbg Scripts</li>
<li> Kernel Debugging with IDA Pro</li>
</ul>
Memory Forensics with Volatility<br />
<ul>
<li> Dumping Memory with MoonSols Windows Memory Toolkit</li>
<li> Remote, Read-only Memory Acquisition with F-Response</li>
<li> Accessing Virtual Machine Memory Files</li>
<li> Volatility in a Nutshell</li>
<li> Investigating Processes in Memory Dumps</li>
<li> Detecting DKOM Attacks with psscan</li>
<li> Exploring csrss.exe's Alternate Process Listings</li>
<li> Recognizing Process Context Tricks</li>
</ul>
Memory Forensics: Code Injection & Extraction<br />
<ul>
<li> Hunting Suspicious Loaded DLLs</li>
<li> Detecting Unlinked DLLs with ldr_modules</li>
<li> Exploring Virtual Address Descriptors (VAD)</li>
<li> Translating Page Protections</li>
<li> Finding Artifacts in Process Memory</li>
<li> Identifying Injected Code with Malfind and YARA</li>
<li> Rebuilding Executable Images from Memory</li>
<li> Scanning for Imported Functions with impscan</li>
<li> Dumping Suspicious Kernel Modules</li>
</ul>
Memory Forensics: Rootkits<br />
<ul>
<li> Detecting IAT hooks</li>
<li> Detecting EAT hooks</li>
<li> Detecting Inline API hooks</li>
<li> Detecting Interrupt Descriptor Table (IDT) Hooks</li>
<li> Detecting Driver IRP Hooks</li>
<li> Detecting SSDT Hooks</li>
<li> Automating Damn Near Everything with ssdt_ex</li>
<li> Finding Rootkits with Detached Kernel Threads</li>
<li> Identifying System-wide Notification Routines</li>
<li> Locating Rogue Service Processes with svcscan</li>
<li> Scanning for Mutex Objects with mutantscan</li>
</ul>
Memory Forensics: Network and Registry<br />
<ul>
<li> Exploring Socket and Connection Objects</li>
<li> Analyzing the Network Artifacts Left by Zeus</li>
<li> Detecting Attempts to Hide TCP/IP Activity</li>
<li> Detecting Raw Sockets and Promiscuous NICs</li>
<li> Analyzing Registry Artifacts with Memory Registry Tools</li>
<li> Sorting Keys by Last Written Timestamp</li>
<li> Using Volatility with RegRipper</li>
</ul>Michael Hale Lighhttp://www.blogger.com/profile/17377327006242921434noreply@blogger.com9tag:blogger.com,1999:blog-3630199973361886660.post-59767598415463379232009-12-12T09:34:00.018-06:002012-08-05T21:49:00.920-06:00New and Updated Volatility Plug-ins Part III just landed in Kuala Lumpur, Malaysia for a private <a href="http://mnin.blogspot.com/2009/09/idefense-malware-training-in-nyc-and.html">iDefense Malware Analysis Course</a>. On the 20 hour flight to this far, far away land where airport taxi drivers are fully-suited and have brand new Mercedes Benz, I did what any normal person would have done - update a Volatility plugin, watch a movie, take a nap, write a new Volatility plugin, watch a movie, take a nap, etc.<br />
<br />
First, I wanted to congratulate <a href="https://www.volatilesystems.com/default/volatility">AAron Walters</a> and <a href="http://www.cc.gatech.edu/~brendan/">Brendan Dolan-Gavitt</a> for giving such an informative talk at the <a href="http://taosecurity.blogspot.com/2009/12/thanks-for-great-incident-detection.html">Incident Detection Summit</a> about the current and future direction of the Volatility project. Unfortunately I missed the entire conference, but according to a post on the <a href="http://vrt-sourcefire.blogspot.com/2009/12/i-hope-youre-happy-bejtlichyou-cost-me.html">Sourcefire VRT blog</a> and some <a href="http://twitter.com/search?q=sansids">interesting Tweets</a> from other attendees, it appears to have been a great time. It even made one person spoil his pants:<br />
<br />
<a href="https://blogger.googleusercontent.com/img/b/R29vZ2xl/AVvXsEh9-pk2bqg47bpQ0p8HStBYjIfu0ecTJ1QQL73ij4jOSb9OXowRtZl6aOoR_KS0j3dpYSnbJQ1Xj8uUqD3FH6Gv0zvouBsiJ_cKnjLBAB-FjAHl_D4NyyhYxA-Q962b36JxRVxUg_devOxD/s1600-h/Snapz+Pro+XScreenSnapz001.png" onblur="try {parent.deselectBloggerImageGracefully();} catch(e) {}"><img alt="" border="0" id="BLOGGER_PHOTO_ID_5414387818905086610" src="https://blogger.googleusercontent.com/img/b/R29vZ2xl/AVvXsEh9-pk2bqg47bpQ0p8HStBYjIfu0ecTJ1QQL73ij4jOSb9OXowRtZl6aOoR_KS0j3dpYSnbJQ1Xj8uUqD3FH6Gv0zvouBsiJ_cKnjLBAB-FjAHl_D4NyyhYxA-Q962b36JxRVxUg_devOxD/s320/Snapz+Pro+XScreenSnapz001.png" style="cursor: pointer; display: block; height: 150px; margin: 0px auto 10px; text-align: center; width: 320px;" /></a>Although this has never happened to me personally, I completely understand. My advice to <a href="http://taosecurity.blogspot.com/">Bejtlich</a> if he finds his way to this post is to organize the distribution of <a href="http://www.charmin.com/en_US/wet-wipes-freshmates.php">Charmin Freshmates</a> (they come in travel sizes too) along with the conference agendas in order to prevent serious disasters in the future.<br />
<br />
Well there's no easy way to flow from that topic to the next, so...<br />
<br />
<span style="font-weight: bold;">Change Number One:</span><br />
<br />
The new version of malfind2 uses <a href="http://code.google.com/p/yara-project/">YARA</a> to scan all process memory, regardless of whether its classified as hidden/injected in the usual manner (i.e. VAD tags/permissions). Now you can find bad stuff in mapped files, loaded DLLs, or memory segments that the process allocated itself (i.e. not the result of another process calling VirtualAllocEx). All you need to do is create some YARA signatures and pass the path to your rules file on command line, like this:<br />
<br />
<span style="font-family: courier new; font-size: 85%;">$ python volatility malfind2 -d out_dir -f zeus.vmem -y rules.yar</span><span style="font-size: 85%;"><br /></span><span style="font-family: courier new; font-size: 85%;">#</span><span style="font-size: 85%;"><br /></span><span style="font-family: courier new; font-size: 85%;"># alg.exe (Pid: 1320)</span><span style="font-size: 85%;"><br /></span><span style="font-family: courier new; font-size: 85%;">#</span><span style="font-size: 85%;"><br /></span><span style="font-family: courier new; font-size: 85%;">[!] Range: 0x006b0000 - 0x006d7fff (Tag: VadS, Protection: 0x18)</span><span style="font-size: 85%;"><br /></span><span style="font-family: courier new; font-size: 85%;">Dumping to out_dir/malfind.1320.6b0000-6d7fff.dmp</span><span style="font-size: 85%;"><br /></span><span style="font-family: courier new; font-size: 85%;">PE sections: [.odkx, .itiz, .ryd, .rsrc, ]</span><span style="font-size: 85%;"><br /></span><span style="font-family: courier new; font-size: 85%;">YARA rule: passwords</span><span style="font-size: 85%;"><br /></span><span style="font-family: courier new; font-size: 85%;">Hit: IE Cookies:</span><span style="font-size: 85%;"><br /></span><span style="font-family: courier new; font-size: 85%;">0x006b1081 49 45 20 43 6f 6f 6b 69 65 73 3a 0a 00 00 00 4d IE Cookies:....M</span><span style="font-size: 85%;"><br /></span><span style="font-family: courier new; font-size: 85%;">YARA rule: loginstrings</span><span style="font-size: 85%;"><br /></span><span style="font-family: courier new; font-size: 85%;">Hit: &email=</span><span style="font-size: 85%;"><br /></span><span style="font-family: courier new; font-size: 85%;">0x006c7fa0 26 65 6d 61 69 6c 3d 00 62 74 6e 3d 00 00 00 00 &email=.btn=....</span><span style="font-size: 85%;"><br /></span><span style="font-family: courier new; font-size: 85%;">YARA rule: zbot</span><span style="font-size: 85%;"><br /></span><span style="font-family: courier new; font-size: 85%;">Description: This is just an example</span><span style="font-size: 85%;"><br /></span><span style="font-family: courier new; font-size: 85%;">Hit: =-=-PaNdA</span><span style="font-size: 85%;"><br /></span><span style="font-family: courier new; font-size: 85%;">0x006b1d20 3d 2d 3d 2d 50 61 4e 64 41 21 24 32 2b 29 28 2a =-=-PaNdA!$2+)(*</span><br />
<br />
You can see in the last YARA hit that a description is available. This is making use of the new meta tags in YARA 1.3. Although malfind2 works great with YARA, pydasm, and pefile, it no longer requires anything besides the core Volatility files. I did this because some people have trouble installing Python modules on Windows for various reasons. If you're one of those people and you've even read all the <a href="http://code.google.com/p/volatility/wiki/DocFiles">new Volatility documentation</a>, now you can still detect, dump, and see a hexdump preview of hidden/injected code segments. However, you'll suffer from lack of disassembly and strong pattern scanning (I once suffered from this and needed to be taken to the hospital!).<br />
<br />
<span style="font-weight: bold;">Change Number Two:</span><br />
<br />
The older usermode_hooks.py and kernel_hooks.py plugins have been combined into a single plugin named apihooks.py. The usage is still basically the same:<br />
<br />
<span style="font-family: courier new; font-size: 85%;">$ python volatility apihooks -d out_dir -f coreflood.vmem [-p PID]</span><span style="font-size: 85%;"><br /></span><span style="font-family: courier new; font-size: 85%;">Type Process PID Hooked Module Hooked Function From => To/Instruction Hooking Module</span><span style="font-size: 85%;"><br /></span><span style="font-family: courier new; font-size: 85%;">IAT IEXPLORE.EXE 248 USERENV.dll ADVAPI32.dll!RegSetValueExW [0x769c11f8] => 0x7ff82080 </span><span style="font-size: 85%;"><br /></span><span style="font-family: courier new; font-size: 85%;">IAT IEXPLORE.EXE 248 USERENV.dll KERNEL32.dll!LoadLibraryW [0x769c12ac] => 0x7ff82ac0 </span><span style="font-size: 85%;"><br /></span><span style="font-family: courier new; font-size: 85%;">IAT IEXPLORE.EXE 248 USERENV.dll KERNEL32.dll!CreateFileW [0x769c12b8] => 0x7ff82240 </span><span style="font-size: 85%;"><br /></span><span style="font-family: courier new; font-size: 85%;">IAT IEXPLORE.EXE 248 USERENV.dll KERNEL32.dll!GetProcAddress [0x769c1380] => 0x7ff82360 </span><span style="font-size: 85%;"><br /></span><span style="font-family: courier new; font-size: 85%;">IAT IEXPLORE.EXE 248 USERENV.dll KERNEL32.dll!LoadLibraryA [0x769c138c] => 0x7ff82a50 </span><span style="font-size: 85%;"><br /></span><span style="font-family: courier new; font-size: 85%;">[...]</span><span style="font-size: 85%;"><br /></span><span style="font-family: courier new; font-size: 85%;">Total IAT hooks in user space: 287</span><span style="font-size: 85%;"><br /></span><span style="font-family: courier new; font-size: 85%;">Total EAT hooks in user space: 0</span><span style="font-size: 85%;"><br /></span><span style="font-family: courier new; font-size: 85%;">Total INLINE hooks in user space: 0</span><br />
<br />
The output is much easier to read when its not pasted into a blog post, I promise. Basically it is showing that there are multiple IAT hooks inside the IEXPLORE.EXE process with Pid 248. In particular, the IAT entries in USERENV.dll which should be pointing at functions in KERNEL32.dll and ADVAPI32.dll are actually pointing at some memory in the 0x7ff82xxx range. Guess what tool you can use to dump that memory range?<br />
<br />
To scan kernel modules, just pass the -k flag, like this:<br />
<br />
<span style="font-family: courier new; font-size: 85%;">$ python volatility apihooks -d out_dir -f skynet.vmem -k</span><span style="font-size: 85%;"><br /></span><span style="font-family: courier new; font-size: 85%;">Type Hooked Module Hooked Function From => To/Instruction</span><span style="font-size: 85%;"><br /></span><span style="font-family: courier new; font-size: 85%;">INLINE ntoskrnl.exe IofCallDriver 0x804e37c5 => jmp 0x8217f20b </span><span style="font-size: 85%;"><br /></span><span style="font-family: courier new; font-size: 85%;">INLINE ntoskrnl.exe IofCompleteRequest 0x804e3bf6 => jmp 0x820babc3 </span><span style="font-size: 85%;"><br /></span><span style="font-family: courier new; font-size: 85%;">Total IAT hooks in kernel space: 0</span><span style="font-size: 85%;"><br /></span><span style="font-family: courier new; font-size: 85%;">Total EAT hooks in kernel space: 0</span><span style="font-size: 85%;"><br /></span><span style="font-family: courier new; font-size: 85%;">Total INLINE hooks in kernel space: 2</span><br />
<br />
<span style="font-weight: bold;">Change Number Three:</span><br />
<br />
A new plugin by the name of ldr_modules.py can detect unlinked LDR_MODULE entries. This is a technique implemented by <a href="http://www.battleforums.com/forums/diablo-hacking/104427-cloakdll-cpp.html">CloakDll</a>, <a href="http://rootkit.com/board_project_fused.php?did=proj22">NtIllusion</a>, and its also discussed with source code examples on an <a href="http://www.openrce.org/blog/view/844/How_to_hide_dll">OpenRCE post</a>. In short, the PEB for a process contains 3 doubly-linked lists containing the loaded modules in different orders (load order, memory order, initialization order). If you unlink a module from all 3 lists, it will essentially be hidden from tools like listdlls.exe, Process Explorer, Process Hacker, etc.<br />
<br />
When DLLs are loaded with LoadLibrary, they are essentially mapped into memory (see CreateFileMapping/MapViewOfFile) and this leaves a noteworthy artifact on the system, besides the 3 lists in the PEB. The VAD entry for the memory range where the DLL is loaded contains a CONTROL_AREA structure, and this contains a FILE_OBJECT structure that identifies the full path of the mapped file. The new ldr_modules.py plugin enumerates the base addresses for memory mapped executable files using the VAD API from Volatility and makes sure that there is a corresponding entry in the 3 lists of the PEB. If any are missing, it has probably been unlinked.<br />
<br />
There are two main arguments about using this method for detection. First, a rookit can use DKOM and directly overwrite the FILE_OBJECT struture after unlinking from the PEB. Then it will appear as if there is no memory mapped file. However, this would require a kernel rootkit rather than one that works completely in user mode, requiring more work on the attacker's part to produce reliable and portable code. Second, its possible to load DLLs into a process without using LoadLibrary (see <a href="http://www.harmonysecurity.com/files/HS-P005_ReflectiveDllInjection.pdf">Reflective DLL Injection</a>) which doesn't create a mapped file in the VAD or any entries in the PEB. However, as AAron Walters <a href="http://volatility.tumblr.com/post/57441548/reflective-dll-injection">hinted a while back</a>, it leaves various other artifacts that are easily detectable using malfind2.<br />
<br />
To test the plugin, I compiled a program called unlinker.exe that unlinks the 3 PEB entries for kernel32.dll. Although kernel32.dll isn't malicious, its fine for the demo. You can view the basic module counts for processes like this:<br />
<br />
<span style="font-family: courier new; font-size: 85%;">$ python volatility ldr_modules -f unlinkedldr.bin</span><span style="font-size: 85%;"><br /></span><span style="font-family: courier new; font-size: 85%;">Pid Name PEB nLoad nMem nInit nMapped</span><span style="font-size: 85%;"><br /></span><span style="font-family: courier new; font-size: 85%;">248 smss.exe 0x7ffde000 2 2 1 2 </span><span style="font-size: 85%;"><br /></span><span style="font-family: courier new; font-size: 85%;">294 csrss.exe 0x7ffdf000 14 14 13 18 </span><span style="font-size: 85%;"><br /></span><span style="font-family: courier new; font-size: 85%;">2ac winlogon.exe 0x7ffdd000 78 78 77 0 </span><span style="font-size: 85%;"><br /></span><span style="font-family: courier new; font-size: 85%;">2e0 services.exe 0x7ffdf000 26 26 25 26 </span><span style="font-size: 85%;"><br /></span><span style="font-family: courier new; font-size: 85%;">2ec lsass.exe 0x7ffde000 58 58 57 0 </span><span style="font-size: 85%;"><br /></span><span style="font-family: courier new; font-size: 85%;">388 svchost.exe 0x7ffdb000 47 47 46 47 </span><span style="font-size: 85%;"><br /></span><span style="font-family: courier new; font-size: 85%;">3d8 svchost.exe 0x7ffdd000 38 38 37 38 </span><span style="font-size: 85%;"><br /></span><span style="font-family: courier new; font-size: 85%;">[...]</span><span style="font-size: 85%;"><br /></span><span style="font-family: courier new; font-size: 85%;">ac4 unlinker.exe 0x7ffd4000 2 2 1 3</span><br />
<br />
Here you can see that the LoadOrder list and MemoryOrder list both contain 2 entries. The InitOrder list contains 1 entry - but its normal for the InitOrder list to contain 1 less entry than the LoadOrder and MemoryOrder lists (the InitOrder does not contain the process EXE whereas the other two do). Then you see that there are 3 memory mapped executable files in unlinker.exe. What is the full path to the extra mapped executable file that isn't accounted for in the LoadOrder or MemoryOrder lists?<br />
<br />
<span style="font-family: courier new; font-size: 85%;">$ python volatility ldr_modules -f unlinkedldr.bin -v</span><span style="font-size: 85%;"><br /></span><span style="font-family: courier new; font-size: 85%;">ac4 unlinker.exe 0x7ffd4000 2 2 1 3 </span><span style="font-size: 85%;"><br /></span><span style="font-family: courier new; font-size: 85%;">InLoadOrderModuleList</span><span style="font-size: 85%;"><br /></span><span style="font-family: courier new; font-size: 85%;">No. Map? Offset Base Size Path</span><span style="font-size: 85%;"><br /></span><span style="font-family: courier new; font-size: 85%;">[1 ] [x] 0x251ec0 0x400000 0x11000 C:\unlinker.exe</span><span style="font-size: 85%;"><br /></span><span style="font-family: courier new; font-size: 85%;">[2 ] [x] 0x251f18 0x7c900000 0xb2000 C:\WINDOWS\system32\ntdll.dll</span><span style="font-size: 85%;"><br /></span><span style="font-family: courier new; font-size: 85%;">InMemoryOrderModuleList</span><span style="font-size: 85%;"><br /></span><span style="font-family: courier new; font-size: 85%;">No. Map? Offset Base Size Path</span><span style="font-size: 85%;"><br /></span><span style="font-family: courier new; font-size: 85%;">[1 ] [x] 0x251ec8 0x400000 0x11000 C:\unlinker.exe</span><span style="font-size: 85%;"><br /></span><span style="font-family: courier new; font-size: 85%;">[2 ] [x] 0x251f20 0x7c900000 0xb2000 C:\WINDOWS\system32\ntdll.dll</span><span style="font-size: 85%;"><br /></span><span style="font-family: courier new; font-size: 85%;">InInitializationOrderModuleList</span><span style="font-size: 85%;"><br /></span><span style="font-family: courier new; font-size: 85%;">No. Map? Offset Base Size Path</span><span style="font-size: 85%;"><br /></span><span style="font-family: courier new; font-size: 85%;">[1 ] [x] 0x251f28 0x7c900000 0xb2000 C:\WINDOWS\system32\ntdll.dll</span><span style="font-size: 85%;"><br /></span><span style="font-family: courier new; font-size: 85%;">Mapped Files</span><span style="font-size: 85%;"><br /></span><span style="font-family: courier new; font-size: 85%;">No. Load? Mem? Init? 0xBase Name </span><span style="font-size: 85%;"><br /></span><span style="color: red; font-family: courier new; font-size: 85%;">[ 1] [x] [x] [ ] 0x400000 \unlinker.exe</span><span style="font-size: 85%;"><br /></span><span style="font-family: courier new; font-size: 85%;">[ 2] [x] [x] [x] 0x7c900000 \WINDOWS\system32\ntdll.dll</span><span style="font-size: 85%;"><br /></span><span style="color: red; font-family: courier new; font-size: 85%;">[ 3] [ ] [ ] [ ] 0x7c800000 \WINDOWS\system32\kernel32.dll</span><br />
<br />
With the verbose output (-v flag), you can list the individual modules along with their base addresses and sizes. Each of the 3 lists contain a checkbox in the Map column which indicates if the DLL is a memory mapped file or not (they all should be). The most interesting output is in the Mapped Files section where it shows which mapped files exist in the 3 PEB lists. For the EXE itself (\unlinker.exe), its missing an 'x' for the InitOrder list, but as we said before - this is normal. For kernel32.dll, its missing an 'x' in all 3 lists, and that's how we know its been unlinked.<br />
<br />
<span style="font-weight: bold;">Change Number Four:</span><br />
<br />
In the future when I change or release new plugins, they will be included in a single download called <a href="http://mhl-malware-scripts.googlecode.com/files/vap-0.1.zip">Volatility Analyst Pack</a>. Right now it contains malfind2, ldr_modules, apihooks, idt, driverirp, and orphan_threads. The older downloads are still available in the deprecated section of the Google Code repository.<br />
<br />
Please let me know if you have suggestions for improvement or run into any issues using the plugins.Michael Hale Lighhttp://www.blogger.com/profile/17377327006242921434noreply@blogger.com6tag:blogger.com,1999:blog-3630199973361886660.post-66867449342964108882009-09-03T12:10:00.006-06:002012-08-05T21:48:48.793-06:00iDefense Malware Training in NYC and LondonI would like to announce the next two dates for <a href="http://labs.idefense.com/">iDefense</a> malware training courses:<br />
<br />
September 23 - 25 2009 (9am to 5pm) NYC<br />
October 28-30 2009 (9am to 5pm) London<br />
<br />
The cost is $3500/person. You'll get lots of hands-on technical training from myself and <a href="http://nnl-labs.com/">Greg Sinclair</a>. As a pre-requisite, you should complete <a href="http://www.giac.org/certifications/security/grem.php">SANS GREM</a> or a course of similar quality, or have 1-2 years experience with malware analysis. It would really help if you had your own license for IDA Pro (otherwise you can use the trial/limited 4.9 version), however almost all of the tools we use are free, very inexpensive, or home-made.<br />
<br />
Here is a high-level description of the topics. If you want a more detailed agenda, or any other information about the course, please email me: michael (dot) ligh @ mnin (dot) org.<br />
<br />
* Windows internals for reverse engineers<br />
* Low level programming (reading/writing assembly)<br />
* High level programming (Native and Win32 API, driver development, Python)<br />
* Analyzing non-executable files (Javascript, MS Office documents, PDF, Flash)<br />
* Dynamic analysis (Change detection, building a custom API monitor, pcap inspection)<br />
* Static analysis (PE/COFF, working with IDA and plug-ins)<br />
* Using a debugger to analyze malware (user programs with Immunity Debugger and kernel drivers with WinDbg)<br />
* Packing and unpacking (dump and rebuild exes/dlls packed with both common and custom packers)<br />
* Anti-RCE (ways to defeat debugger detection, VM detection, Emu detection)<br />
* Code injection and rootkits (10+ injection techniques w/ source code, user mode rootkits, kernel mode rootkits)<br />
* Stealth malware (methods to hide on disk, memory, and network - plus how to detect)<br />
* Analyzing info stealers (HTML injection, key logging, password/credential theft)<br />
* Memory forensics (hunting malware in memory, extending Volatility, case studies with new tools)<br />
* Scripting debuggers (decrypting strings, computing CnC hostnames, decrypting configurations)<br />
* Analyzing VB and Delphi malware<br />
<br />
Also, just so you know, here are some topics that the class does NOT teach:<br />
<br />
* OSX/Unix malware<br />
* Mobile malware<br />
* Hardware/firmware rootkits<br />
* Investigating IPs, domains, etc<br />
<br />
We will study specific families of malware (CoreFlood, Mebroot, Zeus, Laqma, Silent Banker, Kraken, Waledac, Gozi, Limbo, Tigger, and Conficker to name a few), as well as generic malware of Chinese descent and several home-made trojans that we built to demonstrate certain things.Michael Hale Lighhttp://www.blogger.com/profile/17377327006242921434noreply@blogger.com2tag:blogger.com,1999:blog-3630199973361886660.post-34776932204017169702009-08-01T14:17:00.007-06:002012-08-05T21:48:30.522-06:00Making Fun of Your MalwareThe slides from my talk with Matt Richard at Defcon 17 <a href="http://mhl-malware-scripts.googlecode.com/files/Making%20fun%20of%20your%20malware.pdf">have now been posted online</a>. Unfortunately, its not one of those slide decks that you can just read and get the full benefit of the talk. If you missed it and want to LOL, wait for the audio/video to be released.<br />
<br />
<a href="http://mhl-malware-scripts.googlecode.com/files/Making%20fun%20of%20your%20malware.pdf" onblur="try {parent.deselectBloggerImageGracefully();} catch(e) {}"><img alt="" border="0" id="BLOGGER_PHOTO_ID_5365160457990998514" src="https://blogger.googleusercontent.com/img/b/R29vZ2xl/AVvXsEgmzTe7BjQHAGqyxmSLIZEvzDdaBwDASpgfvWS7_4y3ACw2Z8AWRxwDhkJv-npXNY0jXEvH9kb5FEhQBnvtxUtiZcu_UZlu0gS4F7yKVuawBjAh__DqnHiFLVFPu2w7f0quIi-Ok5-za_OF/s320/screen-capture.png" style="cursor: pointer; display: block; height: 240px; margin: 0px auto 10px; text-align: center; width: 320px;" /></a><span style="text-decoration: underline;"><br /></span>Here is the demo showing how we performed credential recovery for Silent Banker, because the authors forgot to seed the random number generator:<br />
<br />
<a href="http://mhl-malware-scripts.googlecode.com/files/silentbanker_sbgold.mov.zip">http://mhl-malware-scripts.googlecode.com/files/silentbanker_sbgold.mov.zip</a><br />
<br />
Here is the demo showing a new Volatility plug-in that rebuilds the IAT for packed malware, even if the original PE header is wiped out of memory:<br />
<br />
<a href="http://mhl-malware-scripts.googlecode.com/files/coreflood_fixiat.mov.zip">http://mhl-malware-scripts.googlecode.com/files/coreflood_fixiat.mov.zip</a><br />
<br />
Here is the demo showing how to detect SSDT hooks, extract the malicious kernel driver, create an IDB of the driver, and automatically label the rootkit functions in the IDB - all in one step. This plug-in extends <a href="http://moyix.blogspot.com/2008/08/auditing-system-call-table.html">Brendan Dolan-Gavitt's ssdt.py</a> for the additional features.<br />
<br />
<a href="http://mhl-malware-scripts.googlecode.com/files/laqma_ssdt_ex.mov.zip">http://mhl-malware-scripts.googlecode.com/files/laqma_ssdt_ex.mov.zip</a><br />
<br />
Enjoy. I will release the actual plug-ins later on.Michael Hale Lighhttp://www.blogger.com/profile/17377327006242921434noreply@blogger.com0tag:blogger.com,1999:blog-3630199973361886660.post-36201267788895575692009-07-20T09:51:00.013-06:002012-08-05T21:48:08.711-06:00New and Updated Volatility Plug-insHere is a Volatility plug-in for printing the Interrupt Descriptor Table (IDT) addresses:<br />
<br />
<a href="http://mhl-malware-scripts.googlecode.com/files/idt.py">http://mhl-malware-scripts.googlecode.com/files/idt.py</a><br />
<br />
It only prints the IDT for one processor, so if anyone wants to update it to handle multiple processors, then feel free. Also if the system's KPCR is located at an address other than 0xFFDFF000 (see <a href="http://moyix.blogspot.com/2008/04/finding-kernel-global-variables-in.html">Brendan Dolan Gavitt's blog</a> or <a href="http://www.rootkit.com/vault/Opc0de/GetVarXP.pdf">Edgar Barbosa's paper</a>), then you'll need to add the correct address to the script.<br />
<br />
In order to test the script, I used <a href="http://www.rootkit.com/vault/hoglund/basic_interrupt.zip">Greg Hoglund's basic_interrupt.zip from rootkit.com</a>. Below you can see that interrupt #46 (0x2E) is pointing inside the basic_int.sys driver.<br />
<span style="font-size: 85%;"><br /><span style="font-family: courier new;"># python volatility idt -f ../hooked_int.bin</span><br /><span style="font-family: courier new;">IDT# ISR unused_lo segment_type system_segment_flag DPL P</span><br /><span style="font-family: courier new;">0 0008:804df350 0 0e 0 0 1</span><br /><span style="font-family: courier new;">1 0008:804df4cb 0 0e 0 0 1</span><br /><span style="font-family: courier new;">[...]</span><br /><span style="font-family: courier new;">46 0008:f8bcd550 0 0e 0 3 1</span><br /><br /><span style="font-family: courier new;"># python volatility modules -f ../hooked_int.bin</span><br /><span style="font-family: courier new;">File Base Size Name</span><br /><span style="font-family: courier new;">\WINDOWS\system32\ntoskrnl.exe 0x00804d7000 0x216700 ntoskrnl.exe</span><br /><span style="font-family: courier new;">\WINDOWS\system32\hal.dll 0x00806ee000 0x020300 hal.dll</span><br /><span style="font-family: courier new;">\??\C:\BASIC_INT.sys 0x00f8bcd000 0x001000 BASIC_INT.sys</span></span><br />
<br />
Here is a Volatility plug-in for printing driver IRP function addresses:<br />
<br />
<a href="http://mhl-malware-scripts.googlecode.com/files/driverirp.py">http://mhl-malware-scripts.googlecode.com/files/driverirp.py</a><br />
<br />
The script requires <a href="http://computer.forensikblog.de/files/volatility_plugins/volatility_driverscan-current.zip">Andreas Schuster's driverscan.py plug-in</a>. It works by over-riding the object_action method of the PoolScanDriver class. Thanks to Andreas for providing the framework. Thanks to <a href="http://www.4tphi.net/~awalters/">AAron Walters</a> for showing me how to over-ride the scanner methods.<br />
<br />
In order to test the script, I used Jamie Butler's <a href="http://www.rootkit.com/vault/fuzen_op/TCPIRPHook.zip">TCPIRPHook.zip from rootkit.com</a>. Below you can see that the IRP_MJ_DEVICE_CONTROL function for Tcpip.sys is hooked by irphook.sys.<br />
<br />
<span style="font-family: courier new; font-size: 85%;"># python volatility driverirp -f ../irphook.bin<br />0x0218a830 0x823b45b8 7 0 0xb2ef3000 361600 Tcpip Tcpip \Driver\Tcpip<br /> [0] [IRP_MJ_CREATE] => 0xb2ef94f9<br /> [1] [IRP_MJ_CREATE_NAMED_PIPE] => 0xb2ef94f9<br /> [2] [IRP_MJ_CLOSE] => 0xb2ef94f9<br /> [3] [IRP_MJ_READ] => 0xb2ef94f9<br /> [4] [IRP_MJ_WRITE] => 0xb2ef94f9<br /> [5] [IRP_MJ_QUERY_INFORMATION] => 0xb2ef94f9<br /> [6] [IRP_MJ_SET_INFORMATION] => 0xb2ef94f9<br /> [7] [IRP_MJ_QUERY_EA] => 0xb2ef94f9<br /> [8] [IRP_MJ_SET_EA] => 0xb2ef94f9<br /> [9] [IRP_MJ_FLUSH_BUFFERS] => 0xb2ef94f9<br /> [10] [IRP_MJ_QUERY_VOLUME_INFORMATION] => 0xb2ef94f9<br /> [11] [IRP_MJ_SET_VOLUME_INFORMATION] => 0xb2ef94f9<br /> [12] [IRP_MJ_DIRECTORY_CONTROL] => 0xb2ef94f9<br /> [13] [IRP_MJ_FILE_SYSTEM_CONTROL] => 0xb2ef94f9<br /> <span style="color: red; font-weight: bold;">[14] [IRP_MJ_DEVICE_CONTROL] => 0xf8b615d0</span><br /><br /># python volatility modules -f ../irphook.bin<br />File Base Size Name<br />\WINDOWS\system32\ntoskrnl.exe 0x00804d7000 0x216700 ntoskrnl.exe<br />\WINDOWS\system32\hal.dll 0x00806ee000 0x020300 hal.dll<br /><span style="color: red; font-weight: bold;">\??\c:\irphook.sys 0x00f8b61000 0x001000 irphook.sys</span></span><br />
<br />
I updated the usermode hook detection plug-in so that it uses pydasm in a cleaner, more reasonable method. Instead of checking the instruction string against a regex, it checks the opcode type and operand type using constants declared in the libdasm source code. Here is a copy of the new version:<br />
<br />
<a href="http://mhl-malware-scripts.googlecode.com/files/usermode_hooks2.py">http://mhl-malware-scripts.googlecode.com/files/usermode_hooks2.py</a><br />
<br />
Also, as I mentioned in my <a href="http://mnin.blogspot.com/2009/05/volatility-plug-in-for-iateatinline.html">original post about usermode hooks</a>, it can be (and has now been) ported to kernel mode. Here is a copy of the version that detects IAT, EAT, and in-line hooks in kernel drivers instead of usermode modules:<br />
<br />
<a href="http://mhl-malware-scripts.googlecode.com/files/kernel_hooks.py">http://mhl-malware-scripts.googlecode.com/files/kernel_hooks.py</a><br />
<br />
I tested the script against a sample of the <a href="http://www.trustedsource.org/blog/260/Generic-Rootkitd-Strikes-Again-in-New-Variant">Skynet trojan</a>. Below you can see that kernel_hooks.py detects the in-line hooks in ntoskrnl.exe functions.<br />
<br />
<span style="font-family: courier new; font-size: 85%;"># python volatility kernel_hooks -f ../skynet.bin -d outdir<br />Type: INLINE, Hooked driver: ntoskrnl.exe (0x804d7000 - 0x806ed780), Hooked function: <span style="color: red; font-weight: bold;">IofCallDriver</span> => jmp 0x8217f20b, Hooking driver:<br />Type: INLINE, Hooked driver: ntoskrnl.exe (0x804d7000 - 0x806ed780), Hooked function: <span style="color: red; font-weight: bold;">IofCompleteRequest</span> => jmp 0x820babc3, Hooking driver:</span><br />
<br />
According to the write-up by McAfee, Skynet hooks two other functions using the in-line technique: NtFlushInstructionCache and NtEnumerateKey. The kernel_hooks.py does not currently detect these two, because they are not actually exported by ntoskrnl.exe, and the plug-in finds functions by walking the EAT. The addresses of the two functions are exposed through their corresponding SSDT entries, however, so its possible to find them that way and use the same check_inline function from kernel_hooks.py to inspect.<br />
<br />
I also updated the "threads without modules" plug-in. As described in the <a href="http://mnin.blogspot.com/2009/03/finding-tiggersyzor-infections-and.html">original post on my blog</a>, it detects hidden system/kernel threads. Using the new version, you don't have to make any adjustments to files in the Volatility core distribution anymore. Its more user-friendly now that it just over-rides the object_action method of the PoolScanThreadFast2 class in order to change the scanner's behavior.<br />
<br />
<a href="http://mhl-malware-scripts.googlecode.com/files/orphan_threads.py">http://mhl-malware-scripts.googlecode.com/files/orphan_threads.py</a><br />
<br />
The output of this script still looks the same as before (sample shown for a memory dump of Tigger trojan):<br />
<br />
<span style="font-family: courier new; font-size: 85%;"># python volatility orphan_threads -f ../tigger.vmem<br />PID TID Offset StartAddress<br />------ ------ --------- ------------<br />4 248 0x2029da8 0xf623f54e<br />4 996 0x206fb90 0xf6240393<br />4 1372 0x2095700 0xf623ea46<br />4 564 0x209d3f8 0xf6240150</span><br />
<br />
Last but not least, I updated the <a href="http://mnin.blogspot.com/2009/01/malfind-volatility-plug-in.html">malfind plug-in for detecting hidden/injected code</a> in usermode processes. You can find the latest version here:<br />
<br />
<a href="http://mhl-malware-scripts.googlecode.com/files/malfind2.py">http://mhl-malware-scripts.googlecode.com/files/malfind2.py</a><br />
<br />
The new version includes the following changes:<br />
<ol>
<li>If it finds a PE file in the suspicious memory segment, it fixes up the ImageBase to match the address of the start of the memory region (in case you plan on opening the dumped EXE/DLL in IDA)</li>
<li>If it finds shell code or non-executable data in the suspicious memory segment, it also prints a hexdump (aside from just a disassembly) </li>
<li>It no longer makes external calls to volatility using the commands.getoutput() method. Instead, it accesses the desired functions using the volatility API, which greatly enhances speed. It went from 1 minute and 48 seconds <span style="color: red;">down to just 4 seconds</span>!! The change also makes it easier to use on Windows, because no path adjustments are needed.</li>
</ol>
Here's an example of what to see when processing a memory dump infected with Zeus. Note that it extracts a PE file from the memory.<br />
<br />
<span style="font-family: courier new; font-size: 85%;"># python volatility malfind2 -f ../zeus.vmem -d outdir<br /><br />#<br /># svchost.exe (Pid: 972)<br />#<br /><br />[!] Range: 0x00890000 - 0x008b7fff<br />Memory extracted to outdir2/malfind.972.890000-8b7fff.dmp<br />PE sections: {.odkx, .itiz, .ryd, .rsrc, }<br /><br />#<br /># svchost.exe (Pid: 1064)<br />#<br /><br />[!] Range: 0x01f00000 - 0x01f27fff<br />Memory extracted to outdir2/malfind.1064.1f00000-1f27fff.dmp<br />PE sections: {.odkx, .itiz, .ryd, .rsrc, }</span><br />
<br />
Here's an example of what to see when processing a memory dump infected with Silent Banker. In this case, the suspicious memory is a trampoline for one of the trojan's API function hooks.<br />
<br />
<span style="font-family: courier new; font-size: 85%;">[!] Range: 0x01650000 - 0x01650fff<br />Memory extracted to outdir3/malfind.1876.1650000-1650fff.dmp<br />Hexdump:<br />0x01650000 58 68 05 00 66 01 68 00 00 00 00 68 00 00 80 7c Xh..f.h....h...|<br />0x01650010 68 68 18 0b 10 50 68 8f 9f 0a 10 c3 00 00 00 00 hh...Ph.........<br />0x01650020 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 ................<br />0x01650030 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 ................<br /><br />Disassembly:<br />0x01650000 pop eax<br />0x01650001 push dword 0x1660005<br />0x01650006 push dword 0x0<br />0x0165000b push dword 0x7c800000<br />0x01650010 push dword 0x100b1868<br />0x01650015 push eax<br />0x01650016 push dword 0x100a9f8f<br />0x0165001b ret </span><br />
<br />
Here's an example of what to see when processing a memory dump infected with CoreFlood. The suspicious memory in this case is the start of the code segment of the PE file (<a href="http://mnin.blogspot.com/2008/11/recovering-coreflood-binaries-with.html">as mentioned in the original blog</a>, CoreFlood strips its PE header).<br />
<br />
<span style="font-family: courier new; font-size: 85%;">[!] Range: 0x7ff80000 - 0x7ffadfff<br />Memory extracted to outdir4/malfind.248.7ff80000-7ffadfff.dmp<br />Hexdump:<br />0x7ff80000 81 ec 20 01 00 00 53 8b 9c 24 30 01 00 00 8b c3 .. ...S..$0.....<br />0x7ff80010 24 04 55 f6 d8 56 57 8b bc 24 34 01 00 00 68 05 $.U..VW..$4...h.<br />0x7ff80020 01 00 00 8d 4c 24 2c 51 1b c0 25 27 0c 00 00 33 ....L$,Q..%'...3<br />0x7ff80030 f6 8b ef 89 44 24 18 89 74 24 1c ff 15 b0 e1 f9 ....D$..t$......<br /><br />Disassembly:<br />0x7ff80000 sub esp,0x120<br />0x7ff80006 push ebx<br />0x7ff80007 mov ebx,[esp+0x130]<br />0x7ff8000e mov eax,ebx<br />0x7ff80010 and al,0x4<br />0x7ff80012 push ebp<br />0x7ff80013 neg al<br />0x7ff80015 push esi<br />0x7ff80016 push edi<br />0x7ff80017 mov edi,[esp+0x134]<br />0x7ff8001e push dword 0x105<br />0x7ff80023 lea ecx,[esp+0x2c]<br />0x7ff80027 push ecx<br />0x7ff80028 sbb eax,eax<br />0x7ff8002a and eax,0xc27<br />0x7ff8002f xor esi,esi<br />0x7ff80031 mov ebp,edi<br />0x7ff80033 mov [esp+0x18],eax<br />0x7ff80037 mov [esp+0x1c],esi<br />0x7ff8003b call [0x7ff9e1b0]</span><br />
<br />
Here 's an example of what to see when processing a memory dump infected with the Skynet trojan mentioned above. In this case, the suspicious memory holds a command and control IP address and the name of one of the files that it hides on disk using the rootkit.<br />
<br />
<span style="font-family: courier new; font-size: 85%;">#<br /># svchost.exe (Pid: 876)<br />#<br /><br />[!] Range: 0x02410000 - 0x02414fff<br />Memory extracted to outdir5/malfind.876.2410000-2414fff.dmp<br />Hexdump:<br />0x02410000 18 00 00 00 68 74 74 70 73 3a 2f 2f 32 31 33 2e ....<span style="color: red;">https://213.</span><br />0x02410010 31 33 33 2e 31 31 30 2e 32 31 2f 00 06 00 00 00 <span style="color: red;">133.110.21/</span>.....<br />0x02410020 31 30 31 32 30 00 02 00 00 00 30 00 00 4e 00 00 10120.....0..N..<br />0x02410030 4d 5a 90 00 03 00 00 00 04 00 00 00 ff ff 00 00 MZ..............<br /><br />[!] Range: 0x02430000 - 0x02434fff<br />Memory extracted to outdir5/malfind.876.2430000-2434fff.dmp<br />Hexdump:<br />0x02430000 00 00 00 10 00 00 00 00 53 4b 59 4e 45 54 63 6d ........<span style="color: red;">SKYNETcm</span><br />0x02430010 64 2e 64 6c 6c 00 00 00 00 00 00 00 00 00 00 00 <span style="color: red;">d.dll</span>...........<br />0x02430020 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 ................<br />0x02430030 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 ................</span><br />
<br />
Please let me know if you have questions or comments about these plug-ins, and if you're interested in helping to build several others.Michael Hale Lighhttp://www.blogger.com/profile/17377327006242921434noreply@blogger.com2tag:blogger.com,1999:blog-3630199973361886660.post-71437582682165504402009-07-20T05:23:00.003-06:002012-08-05T21:47:47.532-06:00iDefense Malware Analysis Training in ShanghaiI just returned home from a trip to Shanghai, China where I taught a 5-day course on malware analysis. Its the second time that iDefense offered this training course outside of the US (first time was at <a href="http://mnin.blogspot.com/2008/10/advanced-malware-analysis-iccyber.html">ICCYBER Brazil in 2008</a>). The students ranged from professors at Chinese universities to forensic investigators from one of the very few forensic companies in China. A lot of the students came familiar with assembly language, debuggers, IDA, and basic unpacking, so we spent most of the time with more advanced topics and new tools. After the training, I spent a week in China with my wife, so it was a great trip altogether.<br />
<br />
Our next training in the US will be held in NYC in late August. The next international training is scheduled for London in late October. If you're interested in either course, send me an email.<br />
<br />
<a href="https://blogger.googleusercontent.com/img/b/R29vZ2xl/AVvXsEg6Y1b8hEjRpwmyAIeThiNnKZ3McWbliGW7M8QEe9VBS74RusofOLyUR1gWsFc8yiWJwQVwq9gTfRYlHNpK3Wuy0G1cdNqLt855oNFFdMm6B4zjwEqq5P6rQIzvQHsOusycpmBqLU5xv2ov/s1600-h/IMG_0176.JPG" onblur="try {parent.deselectBloggerImageGracefully();} catch(e) {}"><img alt="" border="0" id="BLOGGER_PHOTO_ID_5360509520401665394" src="https://blogger.googleusercontent.com/img/b/R29vZ2xl/AVvXsEg6Y1b8hEjRpwmyAIeThiNnKZ3McWbliGW7M8QEe9VBS74RusofOLyUR1gWsFc8yiWJwQVwq9gTfRYlHNpK3Wuy0G1cdNqLt855oNFFdMm6B4zjwEqq5P6rQIzvQHsOusycpmBqLU5xv2ov/s400/IMG_0176.JPG" style="cursor: pointer; display: block; height: 228px; margin: 0px auto 10px; text-align: center; width: 400px;" /></a>Michael Hale Lighhttp://www.blogger.com/profile/17377327006242921434noreply@blogger.com1tag:blogger.com,1999:blog-3630199973361886660.post-50714450134293258172009-05-22T22:12:00.019-06:002012-08-05T21:47:33.256-06:00Volatility Plug-in for IAT/EAT/Inline Hook DetectionI released a new <a href="https://www.volatilesystems.com/default/volatility">Volatility</a> plug-in called <a href="http://code.google.com/p/mhl-malware-scripts/usermode_hooks2.py">usermode_hooks.py</a> to detect IAT/EAT/Inline rootkit hooks in usermode processes.<br />
<br />
To use it, make sure you have <a href="http://dkbza.org/pydasm.html">pydasm</a> and <a href="http://code.google.com/p/pefile/">pefile</a> installed. Then place usermode_hooks.py in your memory_plugins directory. Call it like this:<br />
<br />
# volatility usermode_hooks -d outputdir -p 1202 mem.dmp<br />
# volatility usermode_hooks -d outputdir -f mem.dmp<br />
<br />
The first only looks in the process with pid 1202 for hooks, whereas the second one looks in all processes.<br />
<br />
Its normal for the script to generate a lot of "Memory Not Accessible" warnings. These messages come from executable.py in the Volatility core and are for auditing purposes. It happens because not every page is available when we try to extract the EXE and every loaded DLL. Just apply a command line filter like this:<br />
<br />
# volatility usermode_hooks -d outputdir -f mem.dmp | egrep -v "Memory Not Accessible"<br />
<br />
Since Windows has a lot of legit reasons for hooks, the script can generate a lot of false positives. The good news is, the most common ones are already whitelisted in the script and if you find others, its just Python, so you can add them yourself really quick. Here are some of the defaults:<br />
<br />
* IAT hooks that point inside ntdll.dll<br />
* IAT and Inline hooks that point inside Microsoft C runtime libraries<br />
* IAT hooks of WMI.dll functions that point inside advapi32.dll<br />
* IAT hooks of SCHANNEL.dll functions that point inside secur32.dll<br />
* IAT hooks that point inside the Shim Engine (ShimEng.dll)<br />
<br />
In order to demonstrate the IAT hook detection, I ran the script against a memory dump with Zeus installed. Zeus hooks the IAT of most processes and to be most effective - it also hooks the IAT of all DLLs loaded into the process. If you're interested in more Zeus details, check out my <a href="http://www.securescience.net/FILES/securescience/10378/pubMalwareCaseStudy.pdf">malware case study with Secure Science Corporation</a> from 2006. Here is about 1/20th of the output from Zeus hooks:<br />
<br />
<a href="https://blogger.googleusercontent.com/img/b/R29vZ2xl/AVvXsEhEPaCL4kq4ih1EFH93jgkCO68zHVyCS-W0vTy9gr4nID49YimwtOLJhIeLqhUNhFS7zfeVRgVqSu0oWlXiSJWJX8QMfd-HWU_JbIvCO24sNMDZ0V5fp2TBD2ioESUvrF9VfZKIt_Assj4w/s1600-h/screen-capture.png" onblur="try {parent.deselectBloggerImageGracefully();} catch(e) {}"><img alt="" border="0" id="BLOGGER_PHOTO_ID_5339047010714460786" src="https://blogger.googleusercontent.com/img/b/R29vZ2xl/AVvXsEhEPaCL4kq4ih1EFH93jgkCO68zHVyCS-W0vTy9gr4nID49YimwtOLJhIeLqhUNhFS7zfeVRgVqSu0oWlXiSJWJX8QMfd-HWU_JbIvCO24sNMDZ0V5fp2TBD2ioESUvrF9VfZKIt_Assj4w/s400/screen-capture.png" style="cursor: pointer; display: block; height: 95px; margin: 0px auto 10px; text-align: center; width: 400px;" /></a>From the output, you can see that usermode_hooks.py also prints an alert for any EXE or DLL with a TLS segment, which often indicates an anti-debugging mechanism. For the hooked IAT entries, the item to the left of the arrow (in square brackets) is the address of the IAT entry in the hooked module. The item to the right of the arrow is the address of the rootkit code. For the first line, 0x100130c in services.exe should store the address for ntdll.dll!NtQueryDirectoryFile. However, it points to 0x785388 instead, which is not inside ntdll.dll. In fact, its not in any module, just an allocated heap segment where the injected Zeus code exists.<br />
<br />
For detecting suspicious executable heap segments and injected code, remember there is also the <a href="http://mnin.blogspot.com/2009/01/malfind-volatility-plug-in.html">malfind plug-in for Volatility</a>. By combining usermode_hooks.py and malfind.py, you can easily find out which functions a trojan hooks and extract the rootkit code (or rebuild the exe/dll) that exists at the hooked address in memory.<br />
<br />
In order to demonstrate the inline hook detection, I ran usermode_hooks.py against a memory image with Silent Banker installed. Inline hooks (i.e. trampoline or detours) are the ones where the first few bytes of a function's prologue gets changed into a JMP that points to rootkit code. This is how most trojans work if they do inline hooking and also how most API hooking libraries work, such as <a href="http://research.microsoft.com/en-us/projects/detours/">Microsoft Detours</a>, <a href="http://codefromthe70s.org/mhook22.aspx">Mhook</a>, and <a href="http://www.nektra.com/products/deviare/index.php">Devaire</a>. Here is the output from Silent Banker:<br />
<br />
<a href="https://blogger.googleusercontent.com/img/b/R29vZ2xl/AVvXsEhtdz1x0EAvCysX2-PZ2WURH0CLuII3nATjTe_7Lgznh9KRExxr4od8pevd2AgcZc2y7NuELCITvy0Z2X4BHIEz3dfLpmLADUeHHvNA14j8Gk0Ut0SZteDmqsEAbPu3laB4EK9UD6nDoZPC/s1600-h/screen-capture-1.png" onblur="try {parent.deselectBloggerImageGracefully();} catch(e) {}"><img alt="" border="0" id="BLOGGER_PHOTO_ID_5339051434755447442" src="https://blogger.googleusercontent.com/img/b/R29vZ2xl/AVvXsEhtdz1x0EAvCysX2-PZ2WURH0CLuII3nATjTe_7Lgznh9KRExxr4od8pevd2AgcZc2y7NuELCITvy0Z2X4BHIEz3dfLpmLADUeHHvNA14j8Gk0Ut0SZteDmqsEAbPu3laB4EK9UD6nDoZPC/s400/screen-capture-1.png" style="cursor: pointer; display: block; height: 169px; margin: 0px auto 10px; text-align: center; width: 400px;" /></a>For the inline hooks, the item to the left of the arrow is the virtual address of the hooked function in the process memory. To the right of the arrow is a dissassembly of the first instruction, which shows the rogue JMP to rootkit code. If you're interested in the purpose of each hook, with reverse engineered C source code of the rootkit functions, see <a href="http://www.amazon.com/Cyber-Fraud-Tactics-Techniques-Procedures/dp/1420091271/ref=sr_1_1?ie=UTF8&s=books&qid=1243095160&sr=8-1">Cyber Fraud: Tactics, Techniques, and Procedures</a> by Rick Howard and other authors from the iDefense team.<br />
<br />
Now let's take a look at Laqma - a Trojan that uses inline hooks but without the JMP instruction. Laqma uses a PUSH<span style="font-style: italic;"> </span>instruction followed by a RET. The 4 bytes PUSHed onto the stack is where the code resumes after the RET, so its just like a JMP but with a different instruction set. The iDefense book also includes a full chapter on Laqma. Here is the output:<br />
<br />
<a href="https://blogger.googleusercontent.com/img/b/R29vZ2xl/AVvXsEhpDdjvfFm1RsPPoDAZum7Ekd-sIvZCYn_m6D77nwtLfI2HAKM9zSOf5F2-JEVcAoGmZDgNwcXN0F6NFE1rybtyyFhyiyLtiYQ5jTqYRdQ45BhDdbkycrReC9NT5qKMi7EqLn3-eQVQhu6b/s1600-h/screen-capture-2.png" onblur="try {parent.deselectBloggerImageGracefully();} catch(e) {}"><img alt="" border="0" id="BLOGGER_PHOTO_ID_5339055180732040130" src="https://blogger.googleusercontent.com/img/b/R29vZ2xl/AVvXsEhpDdjvfFm1RsPPoDAZum7Ekd-sIvZCYn_m6D77nwtLfI2HAKM9zSOf5F2-JEVcAoGmZDgNwcXN0F6NFE1rybtyyFhyiyLtiYQ5jTqYRdQ45BhDdbkycrReC9NT5qKMi7EqLn3-eQVQhu6b/s400/screen-capture-2.png" style="cursor: pointer; display: block; height: 148px; margin: 0px auto 10px; text-align: center; width: 400px;" /></a>CoreFlood is another big API hooking trojan (c'mon what trojan doesn't hook API functions - its the cool thing to do). CoreFlood likes IAT hooks.<br />
<br />
<a href="https://blogger.googleusercontent.com/img/b/R29vZ2xl/AVvXsEiLWEHfDwdlxVw0e3cBLYu8cqQpr06XhqWchEwIbTNhgfitZMcCVmZIzbY-e7S77dP8_pbzW-4cA7QQpEAcaTAqi4NmcKiGYyekBPR65k5-hnribqAMHxd62KgzYroILCQvdC88xzEQi-rG/s1600-h/screen-capture-3.png" onblur="try {parent.deselectBloggerImageGracefully();} catch(e) {}"><img alt="" border="0" id="BLOGGER_PHOTO_ID_5339056720836647346" src="https://blogger.googleusercontent.com/img/b/R29vZ2xl/AVvXsEiLWEHfDwdlxVw0e3cBLYu8cqQpr06XhqWchEwIbTNhgfitZMcCVmZIzbY-e7S77dP8_pbzW-4cA7QQpEAcaTAqi4NmcKiGYyekBPR65k5-hnribqAMHxd62KgzYroILCQvdC88xzEQi-rG/s400/screen-capture-3.png" style="cursor: pointer; display: block; height: 206px; margin: 0px auto 10px; text-align: center; width: 400px;" /></a>If you just want to test out usermode_hooks.py without installing various malware, try downloading Hogfly's exemplar memory images (instructions on his <a href="http://forensicir.blogspot.com/2009/03/memory-snapshot-project-part-ii.html">Forensic Incident Response blog</a>).<br />
<br />
A few final notes:<br />
<br />
* There are various ways for malware to evade hook detection (the best is to not use hooks ;-0) and still be malicious...<br />
* Most of these hook detection methods can easily be ported to kernel drivers<br />
* Aside from IAT/EAT/inline hooks, we'll have some other rootkit detection plug-ins released soon<br />
* Big thanks to <a href="http://moyix.blogspot.com/">Brendan Dolan-Gavitt</a> and <a href="http://volatility.tumblr.com/">AAron Walters</a> for their help testing the script<br />
<br />
If you find malware that hooks unusual API functions (or even if you find some common false positives), I'd love to hear about it.Michael Hale Lighhttp://www.blogger.com/profile/17377327006242921434noreply@blogger.com0