Using VirusTotal API v3 Data to Detect Malicious Activity — Part 2
If you missed Part 1 of this series, I highly recommend you check it out. In it i go over the methodology to implementing & using VirusTotal API data combined with Splunk’s correlation power to discover malicious activity on your network by detecting network traffic to domains that had recently been registered.
In Part 2, I am going to demonstrate the value of threat intelligence data being regularly ingested into a SIEM like Splunk by taking a single IOC, like an IP address or domain name and finding possibly related other IOCs that may be useful. Again, i will be focused on using VirusTotal as they offer a free version of their API. For the purpose of this article I am going to assume you already set up a VirusTotal lookup definition in Splunk. If you have not done that yet you can find the instructions here. Once that lookup is set up and configured correctly we’ll be able to take a single IOC and start chaining together some API calls to get additional threat intelligence data.
In my environment I configured three different lookup definitions; one for looking up IP addresses, one for looking up domains, and one for looking up hash values. This is really just my preference as each IOC type have a variety of options and fields that can be returned and it makes it simpler, in my opinion. If you want to see what data is available via the VirusTotal API, check out their documentation here.
The Scenario:
Attacker sent a targeted phishing email to an employee who is part of the finance group. The purpose of the phishing email was to establish communications with the employee and convince them they are an executive at the company prior to requesting a payment. The email was sent from a compromised account that belongs to a third party the employee regularly communicates with.
The email does NOT contain a hyperlink to lure the employee into clicking anything, however, the domain used as the reply-to is an masquerading domain for the target company. This is picked up by our another use case in which all external sender email addresses are parsed and the domain names are extracted then checked against VirusTotal data to find domains that have recently been registered (very similar to the use case I walked through in Part 1 of this series).
Taking that single IOC we will attempt to pivot to additional IOC and start to get an idea of what might be going on…
Above, we used the VirusTotal domain lookup to figure out that the domain was registered a few months ago and has a few different IP addresses associated with it.
Next we want to see what additional domain names might be on those IP addresses. Instead of going online to look them up one-by-one, we’ll use our VirusTotal IP lookup to get information on each IP address…
| makeresults
| eval domain=”sony-spe.com”
| lookup vt_domain query as domain
| mvexpand resolutions
| fields resolutions
| rename resolutions as ip_address
| lookup vt_ip query as ip_address
| stats values(resolutions) as resolutions
Ok, so this is odd…a domain that was recently registered also shares a few different IP addresses with these other domain names. Its not unheard of if the IP addresses were used or owned by the same ASN. That’s not the case in this instance as there are three different ASN (owners of the IP addresses).
At this point we have a suspicion of something nefarious — but we need more proof. Lets take those new domains and run them through our VirusTotal lookup for domains.
Some of those domains have been around for awhile but are using Let’s Encrypt as their certificate authority. Additionally, some of those domains are using the same IP addresses — predominately 50.63.202.39. Ultimately that isn’t to interesting as the IP is owned by GoDaddy.
So we have a bunch of extra data — but lists of data is harder to understand and make connections. Therefore, relationship modeling or graphical representations of relationships is very helpful during security investigations. This type of thing can be used to map a relationship between a process and its other artifacts or, in our case, map the different domains/IP combinations together. To accomplish this we need to install another application in Splunk. The Force Directed app for Splunk is very useful and handy when trying to map relationships between objects.
When we use stats to count the number of times an IP address is associated with a domain name we get the above results. This helps us by visually highlighting relationships that may be interesting.
For this particular scenario we ended up discovering that one of the domains resolved to one of these shared IP addresses is impersonating the previously compromised email account suggesting that company may be a victim of a targeted attack by this threat actor. It also suggests this threat actor may be impersonating other domains which may indicate those companies have either been attacked or will be attacked.
Hopefully I’ve demonstrated the value of threat intelligence within a SIEM solution like Splunk — feel free to follow me as I will continue to post articles like this.
