Skip to main content

Get The Most Out Of Your IoC: The Beginner’s Guide

Posted on 2020-06-30 by Nick Chalard

Find the clues, stop the bad guys, steal the... (don't steal the Declaration of Independence).

So you want to add a little spice to your indicators of compromise. After all, an IoC without context or attribution is very much like when you learn what hot is. There are many tools available for us to determine how “hot” an IoC is without burning ourselves. We will be focusing mainly on what we can access publicly and use for free. As we dive in, I am sure a lot of this will be familiar or evident for most, but let me say this for all you new people. I have one rule: everyone pivots, no one clicks.

Lieutenant Rasczak won’t shoot you if you click on malicious URLs, but no one wants to deal with infections.

Your ability to effectively pivot will determine how much value you can get out of a given IoC, and there aren't many good reasons to click on malicious links when we have tools to mitigate the risk for us. To kick things off, let's grab an IoC to enrich.

We will be using our very own InQuest Labs for much of the process. Starting with IOC-DB, we can look at many potentially malicious IoCs collected from various sources. This suits our use perfectly as many of these IoCs will be benign, and it is up to us to determine that. To keep things simple, we will start by looking at domains. Spotting a potentially malicious domain is as easy as checking its top-level domain. Spamhaus has a useful tool for checking different TLDs for the likelihood that it may be used by threat actors. As most commonly used TLDs (.com, .net, .org) tend to be costly to register and quick (relatively) to shut down for abuse, obscure TLDs from the ever-growing list prove to be cost-effective when staging malware campaigns. From the Spamhaus top 10 list, let's search for a .tk IoC. (This TLD and why it is so commonly abused is rather unusual and worth researching.)

Looking at motherlisancev[.]tk (Always defang links when sharing with others.), we can start with the [link] under the reference column. Twitter sources are a great and succinct way to obtain IoCs. Researchers and analysts can share their findings with the community and provide enough context to pivot on within the character limits of a tweet. From the tweet, we can see that this is an admin panel for Android package files. If we follow the thread back up to the top, we find several other indicators such as the content of the site where the file was downloaded, the URL, the file hash, and information on the file, as seen on VirusTotal. Looking at a reply we see that this APK is believed to be Cerberus malware. Based on known tactics, techniques, and procedures known about Cerberus, it is likely that this is correctly attributed with a lower probability of actually being another Android threat. As with any research, we must verify as much as we can through our efforts. Others may have sources that conflict with what we currently know of any given threat, and we need to ensure that we have the most up-to-date and correct information; Trust but verify. This goes with every judgment call we make, such as how we determine a bad TLD. From here, we can pivot onward in many different directions, but to maintain the trend of simplicity, we will keep finding more basic information linked to this IoC.

Records will vary, but malicious domains tend to stand out in different ways.

Depending on the IoC, one may or may not find useful information with a WHOIS search on a domain or IP based on the search alone. Adding on to what we know so far, however, can yield more context or data we can pivot on. Going back to our initial .tk query on IOC-DB, the dropdown arrow next to our domain allows us to query Domaintools for our WHOIS record. As we can see, there isn't much to see here. Try searching for some legitimately known domains and compare the records. Malicious domains may redact or simply provide little information; this varies between different registrars and may be legitimate for privacy purposes.

Under different circumstances, a clean record may indicate a compromised domain rather than one created by and maintained by threat actors. Registrant organizations can also be useful with enough research and references--another case of forming our judgments based on our observations. Finding linked IoCs sharing registrars, IP locations, and registrant information could be an indicator of a malware campaign infrastructure; adding to our budding IoC that came to us as just another domain in the pile. With everything we have so far, we move on to our next stop to see what else we learn and pivot on.

As seen at the time of writing. (2020-06-23)

Another query in the IOC-DB dropdown arrow takes us to VirusTotal, again, not much to see here. At first glance, it would appear that our motherlisancev[.]tk has not set off any alarms with any of the antivirus vendors except for a single suspicious note. Under the relations tab, we find the resolving IP, and in defiance to the one rule, we are going to click on it as it will help us pivot while staying within VirusTotal. Under the relations tab for the IP, we can see other .tk domains resolving to the same IP. We can also see the provider hosting this IP, another potential indicator when combined with enough data to assign reputations for different providers. This is the basis behind REP-DB, another tool available via InQuest Labs for research use.

With all of these tools at your disposal, there are many rabbit-holes out there to fall within. Based on indicators shared and collected through IOC-DB, it is safe to assume that there are dozens of us engaged in this field of research. As the number of threat actors tends to outnumber researchers and analysts, getting more sets of eyes to expose these threats is imperative to reducing future infections and data-loss.

Until next time, stay safe out there and remember to pivot.

Tools:

Tags
osint labs open-source