The last thing we need to hear about is another big breach, but here we are. Our friends at FireEye were attacked recently. From what I have seen so far, it sounds like this was a nation-state level attack and all the attackers got for their effort was some tools. If an organization is attacked by a nation-state, and the attackers are only able to exfiltrate some tools, that is a pretty good day in my book. Holding the other team to minimal gain can be a win. Some of the stolen tools may be proprietary, but many of them are already available on GitHub or other places on the internet. The attackers worked awfully hard to break in and steal stuff that they could have found on GitHub with some Google searches. Defending against an attack like this is impossible in the long run, unless you just unplug everything and close-up shop. It is not a question of “if”, it is a question of “when”. In response to the attack, FireEye has released a bunch of indicators of compromise (IOCs) to detect the use of the tools that were stolen. This is a great opportunity to evaluate what you are watching for in your environment and see which of your detections need some work. Go ahead and click that link to the GitHub repo and poke around a bit. I am going to have a cookie before we get started.
This post is not about freaking out because a new attack tool was released. It could happen, and probably will. Then again, there are talented coders out there writing new tools and figuring new things out all the time. This is just another day in cyber security. We take in new information, check our environments, remediate what we need to, and move along to the next thing. With this post I want to talk about what we can do with IOCs. If you are looking at IOCs for the first time and trying to figure out what to do with them, follow along as I explore this trove of information.
Looking at the IOCs in the rules folder, the first thing I notice is holy smokes there are a lot of files in here, 60 folders if I am counting them correctly. In many cases the IOCs are provided in multiple formats like Yara, hxioc, and Snort. I love Snort. I don’t use it much myself, I just like the name and their logo is adorable. I have one of those squishy Snort pigs around here somewhere that I use as a stress ball. I’ve had a lot of sugar this morning and I am easily distracted, have you noticed? I need to stay on task, back to red team tool detection stuff, here we go.
Scanning through the files, I am starting with the hxioc files because they are a little easier for me to read. I am looking for a couple of things in the IOCs. First, I want to understand what the IOC is looking for, process starts, files being written by a process, file hashes, DNS request addresses, that kind of thing. An IOC is basically search criteria. I cannot use an IOC based on SysMon data if I am not capturing and storing SysMon data from my endpoints. If I cannot use an IOC because I am not capturing the data required, I can either start a project to start capturing that data, or I can try to better understand what is going on and find the activity another way. Blindly inserting a bunch of IOCs into an environment without understanding the context will likely lead to trouble later, and a lot of wasted resources.
The second thing I am looking for in the IOC is information about what tool is being used for and what it does. A tool used for initial access, or reconnaissance should be treated differently than one for privilege escalation or exfiltration. Understanding how the tool is used tells us more about the risk, and how we need to handle it. Many of the detections in the FireEye repository have MITRE ATT&CK meta information embedded, like this IMPACKETOBF one:
Impacket caught my eye because I have heard of that tool. I have even used that tool. I am not a pentester, but in my spare time I do capture the flag type things and try to learn as much as I can about how pentesting is done. I find the whole thing fascinating, and fun.
This brings me to the third thing I am looking for, the tools themselves. The aspiring pentester in me feels the need to look at all the tools and play with them whenever the opportunity presents itself. My secondary goal in looking at these IOCs is to see what tools FireEye is using. From there, I can learn about the tools that are publicly available, and maybe add more tricks to my tool bag.
After a bit more scanning through the files, I come across this beltalowda folder. It took me a few moments to figure out how to pronounce it, belta-lowd-a. After some googling I do not see anything that looks relevant, except maybe it’s the name of the language spoken by the “belters” in The Expanse TV show. Weird. I have no idea why this folder is named this. The IOC comments talk about a tool called Seatbelt. Seatbelt is an opensource tool that I can see on GitHub. Sweet, new toys! This beltalowda IOC will cover my goals, so I’ll start with this one.
The IOC is easy enough to understand. We are looking for process start logs (Windows Event Id 4688) with some specific file names, shamwow.exe, sealtbelt.exe, and (oh there it is) Beltalowda.exe. The IOC also looks for files being written by any of these three processes. Cool. Assuming we are capturing the data for this activity (which may not be true), we just create a couple searches to fire notifications whenever we see this process kicked off. We just need to repeat this 60 times and go have a cookie, right?
Birdwatching by xkcd is licensed under CC BY-NC 2.5
Just throwing the searches in the scheduler without figuring out what to do with the alerts is another recipe for problems. When a person receives the results from this search, are they going to know what to do with it? Are they going to come to your desk and steal your cookies for creating a bunch of unqualified alerts without details about what they mean in terms of risk and impact?
A SIEM is more than just a search scheduler. The SIEM can enrich the data before we send an alert out. To get started, we need to know the machines and users in our environment, and how they relate to each other. In this case, the process start event details should have the hostname, maybe the username, a time stamp, and a few other values about the process that was kicked off. In our search, we should include some meta information about what we are looking for, and why. The IOC will probably have MITRE ATT&CK references such as the phase, and maybe a MITRE ID value with even more information. We can pass this information through the search as static fields in the results, providing context for the alert. Now the data in the results explains what was found, and why we were looking for it in the first place. That is a significant improvement. All done, right? Nope, not yet. The first question from the person receiving this alert is if this is happening anywhere else, and if there any other suspicious activity from this user and host that should be considered? Our alert will fire off every time the process is started, but nobody wants to count emails to do frequency analysis. We have big, often expensive tools, that are good at counting things. We might as well get some more value out of the tools and justify the budget allocation.
Risk-based alerting to the rescue!
Thinking about this IOC, does the start of this process beltalowda.exe or seatbelt.exe process count as an event worthy of an alert? If the malware detection system catches the call and kills it, did the process do anything that we care about? An event may be interesting but not alertable until it is combined with another event. This is where RBA, or risk-based alerting, comes into play.
I love RBA, it the kind of thing that gets people to bring you cookies, when you do it correctly. Instead of firing off an email alert when the beltalowda.exe process starts, we index the notification details and some metadata about the event, and the search that was run to find it. To properly accumulate risk scores we need some numbers, so we add a numeric score to the event details. Beltalowda.exe is used in the Execution phase according to MITRE ATT&CK, so I will give it a moderate score of 25 out of 100.
An index of “interesting events” is populated with the results from many different searches. With the results flattened out and filtered down to just the interesting events, we can cross-reference the results from multiple searches very easily. We can search for machines where the beltalowda.exe process was started, and a network connection to a specific command and control server was initiated within some period of time. This would be complicated, if not impossible to do with a single search.
Qualifying and correlating events before notifications got out can be a force-multiplier within an organization. Switching over to risk-based alerting is mostly about setting up processes and conventions for how searches should be created and where to send the results from the searches. RAISE is an app for Splunk that can simplify and accelerate your risk-based alerting SIEM journey.
I am going to take this IOC and set it up in RAISE to detect the events and add them to the Score Card dashboards. Since attacking my own environment is a little outside my scope here, I am going to fabricate some data so that I can build my searches and verify that they are working. The fabrication is easy enough, I grab a sample event from my Windows Event Logs, change a few values and fire that to Splunk using the HEC input.
Cool, huh? XML is beautiful, and so easy to read, right? After a little bit of shaping and field-selection, we have the time, the computer name, and we can see that PowerShell started the Beltalowda.exe. There is a lookup call using information built by the other searches in RAISE to add the username based on the computer name in the event. This is helpful because the user that called the process may not be the only user on the machine. Using the host-to-user mapping we can get a better picture of the impact of the event.
Now that I have a good base search, I am going to add it to the scheduler so that the results of this search will be added to the index and attach a score for this event. Imagine one of those awesome movie montages showing me typing on the keyboard, while the camera spins around me showing weird facial expressions and the cat occasionally jumping up on the keyboard.
Isn’t that neat? This new event shows up with a few other interesting events for this person, and the cumulative score for all of the events for that user. From within RAISE we can pivot to different views focusing on the user, the machine, or the types of events that have occurred. By scoring and combining indicator results before alerts or notifications are sent, we can reduce alert fatigue while improving responsiveness and visibility.
There will always be more IOCs to look at, and there will be more threat information to integrate into your processes as you go. Having a repeatable process to categorize and curate detectable events enables you to understand your environment, without clogging up Slack channels and email inboxes with new alerts. This post focuses on one IOC out of the 60 that were released by FireEye. Many of the tools noted in IOCs are likely to referenced in other IOC feeds because they are targeting opensource tools that have been used before.
I look at IOC feeds much the same way I see system update and patch lists. They are important, but they should be reviewed before they are put into production. Developing a process for reviewing your existing searches, before adding duplicates can save a lot of time, and duplicated events in the future. If you have questions or want to learn more about how RAISE can help your organization, give us a call.
Stay tuned an upcoming post on the recent SolarWinds supply chain compromise.
***
This blog was written by Greg Porterfield, Senior Security Consultant at Set Solutions.