System Resource Utilization Monitor

Published: 2017-01-12. Last Updated: 2017-01-12 03:54:54 UTC
by Mark Baggett (Version: 1)
8 comment(s)

The attackers have come and gone and you are left behind to clean up the mess.   You arrive on site to figure out how the bad guys got in, what they took and how badly it will affect the customer. But, the customer doesn't syslog the firewall logs, so you are limited to the three days of logs that are held in the firewall's memory.   The Windows Event logs on most of the systems roll over every 5 minutes, and there is no centralized long term logging.    There is no IDS.   There is no full packet capture.   They have removed the malware used by the attacker, deleted the attacker's accounts, removed the compromised software and reinstalled the latest version of software.   For good measure, they also installed a years' worth of OS and software patches that were missing.   Being a glutton for punishment you ask if you can take the compromised server offline to create a forensics image but you are told management wants to "tread lightly" on the server.   "That’s Ironic" goes through your mind but doesn't cross your lips.   No logs.  No obvious forensic artifacts.  The only clues left are the remains of whatever wasn't stomped on by the administrators overzealous premature clean up.

Despite the customer's unintentional efforts to destroy the last remnants of proof the attackers, within a few minutes you can have a pretty good idea of what the attackers did.  After the attacker created a new account on the system they logged in using RDP.  They downloaded and executed additional malware on the victim's machine launching attacks on neighboring systems.   After collecting up their loot, they connected to a nearby open Wi-Fi to bypass your egress monitoring and transferred the stolen database over the open WI-FI.  All of these attacker actions are discoverable without doing a full forensics timeline by looking at a little-known log of all users' activity on the system called SRUM.

The Windows System Resource Usage Monitor (aka SRUM) contains a wealth of information about all the activities that occur on your machine. Some of this information is visible from the "APP HISTORY" tab on the task manager, but a vast amount of detail collected is not displayed via the GUI.   It keeps the names and paths of every application that executes on your system even the ones the attackers deleted.  It records the user's SID that execute the program so we knew the attacker used a temporary account that the administrators clean up deleted.   It records then names of all of the networks you have connected to and how long you were connected.   It also records application battery usage, CPU time broken down by foreground and background time, how many bytes were written and read from the hard drive by the application and much more. The information is stored in the \Windows\System32\sru\ directory in a file named SRUDB.DAT.   The file is in the Windows ESE (Extensible Storage Engine) database format. So the trick is to get the data out and make sense of it.

Ovie Carrol was telling me how invaluable the data was in one of his investigations.   An excellent paper on the internals of the database by Yogesh Khatri is available in the SANS reading room. But unless you have Encase you can't access the data using his scripts.  I wrote a small program called srum-dump.exe that will extract the data so you can view it using Microsoft Excel or any XLSX compatible viewer.

SRUM-DUMP will accept a few inputs.  One required input is the SRUDB.DAT file from a system you want to analyze. Another required input is an EXCEL file that specifies which fields you want to extract and what format you want them in. I provide a sample template along with the program on my GITHUB called SRUM-TEMPLATE.XLSX.   You can optionally provide a copy of the SOFTWARE registry hive which is typically located in the \Windows\System32\config\ directory if you want to resolve the names (SSID) of Wireless networks.   SRUM-DUMP reads the SRUDB.DAT file, extracts it as defined in the SRUM-TEMPLATE.XLSX file and produces a new XLSX file with the results.

For example.  The following will analyze the input (-i) SRUDB.DAT, the registry (-r) SOFTWARE and create an output file (-o) called example_output.xlsx.  The -t option can be used to specify a template file.  If no template is specified it will use SRUM-TEMPLATE.XLSX in the same directory as srum-dump.exe.

 C:\srum-dump>srum_dump.exe -i ..\SRUDB.dat -r ..\SOFTWARE -o ..\example_output.xlsx

 

The resulting XLSX file has multiple tabs across the bottom.  Each tab is filled with useful information.  In this screenshot, you can see that on the Network Usage tab that NC.EXE was used to transfer a large amount of data over a wireless network named "OPENWIFI". You also have the SID of the user who ran netcat.  

And that is just from one tab!.  There is a lot more information you can get from the spreadsheet.   You can customize the data that is retrieved from the database by modifying the SRUM_TEMPLATE.XLSX file to meet your needs.   The artifacts that are recoverable from the SRUM can change they way you do incident response!.  Download a copy and give it a try.   The README on the github site has more information to get you started.

Download a copy of srum-dump.exe from here:  https://github.com/MarkBaggett/srum-dump

For more information on SRUM and other useful forensic artifacts check out SANS FOR408 Windows Forensics Analysis.

If you would like to add new features to SRUM-DUMP or develop similar programs check out SANS SEC573 Automating Information Security with Python.

There are two opportunities to take the Python course from me in the near future.   

Come see me in London  or come see me in Orlando Florida at SANS 2017

Follow me on twitter @MarkBaggett  

 

8 comment(s)

Comments

On a production system, what would be the best way to get access to the sru folder? Would changing the ownership cause any issues?
If your are dealing with a forensics image you can grab the files without any problems. If it is a live system then the file will be locked and you will have to go through an extra step or to access the file.

One option is to grab a copy from the volume shadow copies. I did a post on Pauldocom (now SecurityWeekly) some time ago on ways to do that.
http://securityweekly.com/2012/10/15/volume-shadow-copies-the-los/

That is how I grab a copy. Note that on Windows 10 you have to start the Volume shadow copy service also. Here is a python tool I wrote to control the shadow copies also. https://pen-testing.sans.org/blog/2013/04/12/using-volume-shadow-copies-from-python


There is a tool called hobocopy that can do this for you also.
http://www.howtogeek.com/howto/windows-vista/backupcopy-files-that-are-in-use-or-locked-in-windows/

The Windows tool robocopy has a /B option that can be used to copy locked files.

HBGary had a tool called fget.exe (I had to work a bit to find this link) http://opensecurityresearch.com/files/FGET.zip

I'm pretty sure there is a Powershell Forensics tool that does the same thing but the name escapes me at the moment.
Not sure what Powershell tool you may be thinking of, but the one that comes to my mind is Invoke-NinjaCopy which is part of PowerSploit. It bypasses the windows API and goes to disk to read NTFS structures directly which means it can copy files that are locked, protected by DACLS, etc as long as you have enough privs to do raw disk access.
You nailed it! That's it. Thank you.
[quote=comment#38733]On a production system, what would be the best way to get access to the sru folder? Would changing the ownership cause any issues?[/quote]

Use the "backup" privilege to access such files.
There is ABSOLUTELY no need to fiddle with the DACL.
How can this data be integrated into Splunk?
[quote=comment#38747]How can this data be integrated into Splunk?[/quote]

If it's a one shot, you could export the XLSX file into CSV and load it into Splunk. To automate, the software being written in Python, it's not difficult to replace the XLSX output by a CSV file and let Splunk index a directory where the output files will be stored.
Hmmm... I get following when I use the default template:

Unable to find table Undocumented Windows 10 Table {97C2CE28-A37B-4920-B1E9-8B76CD341EC5}
I was unable to write the output file. Do you have an old version open? If not this is probably a path or permissions issue.
Error :
Finished!

And I get this when I use the small template:

Traceback (most recent call last):
File "<string>", line 347, in <module>
AttributeError: 'NoneType' object has no attribute 'replace'

This is running on a Windows 10 Enterprise v1607 with a copy of the SRUDB.dat file from the same machine.

Diary Archives