> For the complete documentation index, see [llms.txt](https://hackhunter-hacking.gitbook.io/hackhunter-hacking/llms.txt). Markdown versions of documentation pages are available by appending `.md` to page URLs; this page is available as [Markdown](https://hackhunter-hacking.gitbook.io/hackhunter-hacking/soc-research/lets-talk-about-srum-why-soc-analysts-should-know-about-it.md).
# Let's Talk About SRUM: Why SOC Analysts Should Know About It
## What is SRUM?
SRUM stands for System Resource Utilization Monitor (SRUM) and this is a feature in Windows that tracks application usage, network activity, and energy consumption. it stores historical data regarding the system within an Extensible Storage Engine (ESE) file that is named SRUB.dat and is located at "%SystemRoot%\System32\sru\SRUDB.dat". Although this feature was not meant to be forensically significant, SRUM is a highly relevant and highly useful DFIR artifact that can provide a lot of value in an investigation.
### SRUM Caveats
SRUM does not write to the database continuously. Data is gathered and pushed to the SRUDB.dat once per hour or on a clean system shutdown. This means that it does not provide exact minute-by-minute execution timelines. Another caveat is that, if an analyst extracts the database after a malicious event, it might not have been recorded yet. Additionally, the networking data does not show the remote IP address or port that the host was communicating with.
\
As you can see, it is not perfect. There are some things to consider, but SRUM can still provides forensic benefits when correlated with other telemetry from a system. The goal of this blog is to present SRUM usage and discuss how it can be used in your investigations.
## Real World Example
I recently worked a case where our agent was deployed post-compromise. The unfortunate thing is that an Akira Ransomware threat actor had already made it into the network. Post-compromise deployment makes an investigation difficult because we do not have all of the data to paint the full picture. In this case, we did not have retroactive process data handy. That meant we needed to pivot to the artifacts on the system. One great thing to use is the SRUM.dat to find forensically sound artifacts that allow us to present a timeline to provide substantial value.
\
Initially what we observed was svchost.exe executing out of the "C:\PerfLogs\Temp" directory which was... extremely odd as you might imagine since svchost.exe should execute outside of "C:\Windows\System32" and it should not be making outbound networking connections to an IP registered to the ASN Digital Ocean. As you might ascertain, this was malicious. After pulling the file binary and getting the SHA256 hash, it was renamed "Gost" which is a networking tunnel binary written in Golang. The observed telemetry showed that it was executing a config.dll, whose contents had the IP that it was configured to reach out to. We had IOCs to go off of at this point, but to truly provide value, pulling SRUM proved to be beneficial in that we could track the compromised user based on their SID as well as correlating based on other telemetry (Windows EVTX logs) to create a forensic timeline.
\
The man himself, Dray aka [Purp1eW0lf](https://github.com/Purp1eW0lf/Blue-Team-Notes) pulled SRUM and was able to provide a nice succinct forensic timeline for the partner. This got me thinking and took me back to this case to figure out how he was able to work his magic to obtain all of that. After picking his brain, I tasked myself with the challenge to dive deeper into this. This led me down the rabbit hole into the SRUM world and thinking of ways that I can add this to my workflow in the SOC.
{% hint style="info" %}
Let me preface by saying that this is only one artifact that can help provide value in an investigation. There are several other artifacts that can be a discussion for another blog. Additionally, real world telemetry will look drastically different than a small lab, which is what I will use to demonstrate this.
{% endhint %}
## SRUMDB.dat Overview
### Syntax
To parse the SRUDB.dat, I will use [Eric Zimmerman's tool SrumECmd.exe](https://ericzimmerman.github.io/) to launch it. If we run it with the help, we will get the help and be able to use the correct syntax. As we can see, we need to point it at our SRUDB.dat file:
{% code overflow="wrap" %}
```
SrumECmd.exe -f "C:\Users\HackHunter\Desktop\SRUDB.dat" -r "C:\Users\HackHunter\Desktop\SOFTWARE" --csv "C:\Users\HackHunter\Desktop"
```
{% endcode %}
{% hint style="info" %}
I would highly encourage you to grab the SOFTWARE hive as this can help to enrich the data and provide better output. Again, it is not required, but highly encouraged
{% endhint %}
### Output
Once we have correctly processed the files, we should see the following output:
You will notice that SRUM tracks a lot of things on the system. What we are most interested in are the following:
* App Resource Usage: Records program names, full file paths, user SIDs indicating the user that launched them, and how long they ran.
* Network Connection/Network Usage: Measures data uploaded and downloaded (bytes sent and received) broken down by individual applications and processes.
{% hint style="info" %}
SrumECmd.exe will output the results into CSV files. We can then open them with Timeline Explorer, another tool by Eric Zimmerman that I highly suggest you become acquainted with and know how to use as it is very useful for constructing a timeline with different artifacts on a system.
{% endhint %}
## Correlation Analysis with SRUM
When it comes to investigations, correlation is key! We utilize different tools and telemetries to give the best representation of the attack chain that we can from the data that we have. For this demonstration, let's walk through it as though we just received a signal that we need to investigate (chrome.exe executing out of the Temp folder). Immediately, I like to grab the Windows event logs. The three that will provide a ton of value are the Security, System, and Application EVTX files. There are others, but for this simple demonstration, we will stick with them.
\
Let's parse some data. I like to use a tool called Chainsaw, Timeline Explorer, or [IRFlow Timeline](https://github.com/r3nzsec/irflow-timeline) (for you Mac users) to look at this telemetry. In this case, we can see that we have a user 'SQLService' that is logging in from Kali and we have an IP. Already, that should be firing alarms in your head:
We have a workstation name and an associated IP address. The next question we can ask is "was anyone else seen logging in from this IP?" For this I will switch over to IRFlow Timeline and we can see that fcastle was also seen logging in from this IP. We now have two users that are coming from the Kali host IP on the day of the intrusion:
We have established that the users 'fcastle' and 'SQLService' are compromised and are observed logging in from a malicious Kali workstation that was not previously seen within the network. Let's get to the nitty gritty of this post and look at the SRUM output.
Timeline Explorer is a very versatile tool that provides us with search functionality. Let's look for the SQLService user within the AppResourceUseInfo csv that SrumECmd.exe provided:
We see that SQLService was executing files on the same day as the intrusion. Again, this is not a minute-by-minute artifact, so if you are hoping to find the exact time that it was executed, you will need to correlate with other artifacts that would show this.
What stands out to me is the file path "C:\PerfLogs\Temp\kat.exe (Mimikatz in this example), the use of wsmprovhost.exe (Win-RM; in this case, Evil-WinRM), and rdpclip.exe. "C:\PerfLogs\Temp" appears to be the working directory of the threat actor, which, as SOC analysts, we would try to pull to see what else is in that directory that could provide additional clarity on the goal of the threat actor. We can also hypothesize that the threat actor utilized Win-RM and RDP'd to the host based on these findings. Again, need to verify with other telemetry sources.
We could also pivot to look for the Temp folder that we previously identified to see if there is anything else that was executed from there:
From the above, we learned that the SYSTEM user and the Administrator user were also observed utilizing files within this directory within the same hour. We see the SQLService and SYSTEM user used kat.exe.
We can hypothesize the threat actor attempted to run Mimikatz as the SQLService user and possibly failed. They then gained access as the SYSTEM user and were able to use SYSTEM privileges to enable debug and use Mimikatz. We can also see that the Administrator user is running "chrome.exe" from the Temp folder. Very strange behavior.
{% hint style="info" %}
I feel that it is important to stress that just because it appears that these events are in order, we should take this with a grain of salt as we cannot confirm the exact time that these were run.
{% endhint %}
One more thing before we wrap this up. We know that the System level user was running Mimikatz. Maybe we can attempt to find out how this came to be. If you have used or oberved impacket-psexec usage, you know that it will create a random 8 character exe that runs as a service, which is how SYSTEM privileges are obtained. To be able to utilize this, you need a user that is an Admin, Domain Admin, etc to be able to access the ADMIN$ share (The $ signifies that the share requires admin privileges).
In this case, event ID 7045 will help to determine if impacket-psexec was utilized. We can see the following from the log that a strange service was started running with SYSTEM level privileges within the timeframe of our intrusion. This is also reflected in SRUM. First, we look for event ID 7045 to gain information on that service:
We can then look for the execution of this exe:
One hypothesis this could lead us to is that, as the SYSTEM user, the threat actor dumped the credentials on the system using Mimikatz and was able to gain access to the Administrator account. We attempt to prove or disprove this hypothesis by gathering information such as where the Administrator user was observed logging in from, if the timeline lines up with our intrusion, and any other information that help to paint the picture.
## Conclusion
I hope that this post has shown how effective analyzing SRUM can be during an investigation. While it does not log a minute by minute log, we can correlate based on other artifacts to help us paint a clearer picture of an intrusion. This post was meant to serve as a high-level overview of the ways SRUM can bring value to the investigative table and discuss uses and caveats surrounding it.
\
Telemetry in real-world situations will differ drastically compared to a small lab setup. I did not hit much on the network aspect as emulating that within a lab is a bit more nuanced. However, the AppResourceUsage is more than enough to provide forensic value.My hope is that I was able to provide information that can be used by those just beginning in the field of cybersecurity or those of you that have been working in the field with a different perspective and tools to utilize. Thank you for reading!
