Intro Lab 1: Model 3
With the SHA256 value we found, let’s do a search on VirusTotal.
There are quite a few detections that have generic classifications. The detections that are more specific tend to be classifying the hash as Agent Tesla. If we do a web search for the hash, there should be other sources indicating this appears to be Agent Tesla, including on MalwareBaazar (a great resource for finding malware samples to analyze).
One of the things you may have noticed is the count on VirusTotal is higher than what was displayed in the “VT Malicious Hashes” table. There’s often a delay between when you find a sample and detection products start flagging it. Reasons for this can include evasion techniques, or sometimes it just hadn’t been analyzed yet.
Depending on the volume of new hashes you see within your environment you may have to adjust the threshold of malicious hits that warrant a closer investigation. You’ll find that some products have higher ratios of false positives than others, and so depending on what flagged something as malicious, you may decide to take a closer look (or not).
Agent Tesla has been around for a while, and doing a search online will find a wealth of information including how its capabilities have evolved over time. A good one line summary can be found in this Check Point post:
Agent Tesla is an advanced RAT functioning as a keylogger and information stealer, which is capable of monitoring and collecting the victim’s keyboard input, system keyboard, taking screenshots, and exfiltrating credentials belonging to a variety of software installed on a victim’s machine (including Google Chrome, Mozilla Firefox and the Microsoft Outlook email client).
For this question we’re going to pivot from the Dashboard to the Discover section of Kibana. In the VT Hunting Dashboard, we’re going to start by filtering on the image hashes. In this particular case we only have one image to hash pair, but you may run into situations where you have multiple different image names associated to the same hash (for example, if a piece of malware has a dynamically generated filename).
The opposite can also be true, where a piece malware always uses the same name but may have a different hash. Generally, it’s worth checking for that too, because as mentioned earlier, sources like VirusTotal may not have flagged it yet.
![](https://findthebad.com/model-3/table_filter.png)
![](https://findthebad.com/model-3/pin_filter.png)
![](https://findthebad.com/model-3/discover_process_create.png)
After switching to the Discover section of Kibana, we can see a single log entry for a Sysmon process create event that shows the malware was run by cb3f4b32-wsw10\lab-admin on cb3f4b32-wsw10.windomain.local at 2020-07-16T16:28:49.536Z.
It’s worth taking a second to talk about time. A not uncommon “gotcha” that can happen when doing analysis is dealing with times in different formats, including those that may or may not include time zones. An example of where this can cause issues is if your log sources and SIEM aren’t on the same page. As a result, you might have alerts firing hours after the event actually happened, or you may run into challenges searching for the log that generated the alert.
Ideally your organization will enforce some level of standardization. If that’s not the case, just keep the differences in mind.
Sysmon can conveniently capture file creation. We can look here to see that for file creation events, there’s a field named TargetFilename. Let’s do a search for that field containing the value C:\Users\lab-admin\FAX_RECEIPT_SO_151-154.exe.
![](https://findthebad.com/model-3/file_create.png)
If we expand the one hit that the search returns, we see that the malicious file was written by powershell.exe at 2020-07-16T16:28:45.297Z, which is roughly four seconds before we identified it as being executed.
Kibana provides a number of ways we could query to find out when this file was written. Try some other approaches, like filtering just on event ID 11 for all file create events.