Introduction to IOC Pivoting, and the Pyramid of Pain

[trobinson667]

Couple of days ago, my boss introduced me to this great blog post by sekoia.io, about the PolarEdge botnet.

I love tearing apart research to make (hopefully) good IDS sigs for finding future exploit attempts, and/or retrohunting for evidence of other exploit attempts. Sekoia delivered me a trove of information. I have HTTP requests for CVEs used to compromise boxes. HTTP structs used for installing backdoors, HTTP structs for interacting with the backdoors, interaction with the C2, Domains, IP addresses and unique SSL certificate details.

Synopsis

If you don’t wanna read it (though you really should), the blog post talks about a botnet that consists of Cisco, Asus, Synology and QNAP devices. A lot of what they found centers around exploits thrown to capture Cisco RV series devices, and from there, because the adversary used FTP servers with static creds for payload delivery, they were able to pivot to payload servers and grab stuff that implies targeting of other assets.

They also used passive DNS to pivot across the various IP addresses to build out infrastructure a little bit more.

Investigation Theory

You thought this was going to be a review of the blogpost by sekoia, but surprise, we’re going to talk about investigation tactics using some of the indicators from this blog post as an example. Today, we’ll be covering the Pyramid of Pain, and Data Pivoting.

How do we turn this into rules?

The research is RICH with IOCs, but where do we start? Are you familiar with the pyramid of pain?

Turning pyramids into molehills

To sum up the blog post I linked above, there is a pecking order to indicators, and how developing detection for different indicators has different levels of impact to adversary operations.

The pyramid of pain graphic on David J. Bianco’s blog implies that there is a certain cost to adversary operations, depending on the detection methods and mitigations developed from IOCs observed in their operations.

I’m going to venture into opinion territory here. The pyramid pain is right: The more complex the indicators you have to describe adversary operations, the harder it is for them to hide, and the harder they have to work to change their footprint and tradecraft when you develop detections and mitigations from those higher tier indicators. However, I feel like this has lead a lot of security researchers to write off the lower-level IOCs like file hashes, IP addresses and Domains as being worthless. As usual, They are wrong. You’ve found the foundation of that adversary’s pyramid.

Sure, they’re easy to change. And alone, they don’t hold that much value, but they provide a starting point for climbing up the rest of the pyramid. You climb the pyramid by pivoting on the data you have. This is the basis of Data Forensics and Incident Response. Let me step back a moment, and describe what pivoting is.

Pivoting Explained

Let’s say this report only produced IP addresses, domains, and file hashes. We still have a target-rich environment, ripe for investigation, it just turns out we have to do a little more detective work, and climb up the pyramid ourselves.

Pivoting is the art of taking one piece of data, enriching it to create additional context for that piece of data, thereby creating more data. For example, anyone can use virustotal and search for an IP address. Let’s pick on an IP address from the report, demonstrating an investigative technique that sekoia used in writing this research.

Start with the IP address 119.8.186[.]227.
Go to virustotal.
or Mnemonic’s passivedns database.
or ipvoid.

The point is that each of these resources (and many more) have scores to tell you about that IP address. Or sometimes, they won’t. But in this case, we have discovered that 119.8.186.227 is:

• hosted in Singapore. Out of Huawei cloud.
• At least 7 vendors have blocklisted the IP address
• passiveDNS has revealed FIVE domains associated with this IP address.

longlog[.]cc
landim[.]cc
hitchil[.]cc
logchim[.]cc
fmnav.bits[.]sa

Now we’ve got Domains associated to the IP address in the past. Be sure to pay attention to the date and time the passivedns data was last retrieved. The domain fmnav.bits.sa was grabbed in 2021, two years before the earliest known detection of this botnet (according to this article). Not saying to ignore old resolutions, but keep things like that in mind, if you know the time frame a campaign has taken place, or if a particular pivot isn’t fruitful.

So now we have domains. We can query online tools and databases for more information about those domains. Because I don’t want this to be a ginormous blog, we’ll only pick on a single result out of the five to continue the example on pivoting: longlog[.]cc. So we have a domain now.

We can query that in virustotal.
We can try to map out any relations using dnsdumpster.
We can use mnemonic’s passivedns database.
Take a look at threatfox results.
Check out urlvoid.
Or urlquery.

Maybe you have internal SIEM or log management tools you want to check for activity.
Or maybe you have access to Threat Intelligence Platforms.
Or Tools that can hook into multiple threat intelligence platforms.

From the links above, this is what we know about longlog[.]cc:

• Virustotal’s results don’t take us any further. There are no file hashes associated with the domain. No URLs. No Services. Nothing. We see one comment on the IOC labeled “PolarEdge”, and we can see that 18 vendors consider the domain to be malicious.

PolarEdge? Wonder what that means.

• Threatfox has a score of data about this domain, and has tagged the threat as “PolarEdge”. there’s even a submitter associated with this database entry.

There’s that tag again. Wonder what it me-

• Wonder if they’ve identified any other domains associated with that the tag “PolarEdge”?

Well, then.

• LevelBlue Labs (aka alienvault) has multiple “pulses” or posts that mention longlog[.]cc. Here is the most prominent one:

This pulse has 36 IOCs and links to original articles/sources for the data.

Look at all those IOCs. More IP addresses. More Domains. Filehashes. CVE number(s)! With this we can ask:

• “What devices are being attacked and/or are related to this threat?”

• “Is it something we need to concern ourselves with?”

On top of that, the additional IP addresses, Domains, and Filehashes and the name of the threat “PolarEdge” can be used to pivot even more. Let’s pick on the filehash 1ca7262f91d517853a0551b14abb0306c4e3567e41b1e82a018f0aac718e499e:

Filehashes can be searched for in Virustotal.
Or Malware Bazaar. MB can also be used to search by malware family tag.

You can also search by filehash, domain, url, etc. in malware sandboxes. My personal favorites are any.run and tria.ge. Virus total may also have sandbox results for filehashes, but you can’t really extract the malicious files or pcaps without a virustotal intelligence account, but at least you can get a peek indicators from a malware detonation. Sometimes (like in this case) you probably won’t get valuable results, because most sandboxes are x86, or x86_64 and maybe ARM if you’re lucky and won’t cover results for more exotic and embedded CPU architectures that these routers and IoT devices use.

If your company ponied up for Virustotal Intelligence, or paid sandbox accounts (any.run, etc.), you can search for results by network behavior. Notice a weird URI? search it in virustotal intelligence. Does a CVE have an IDS sid number associated with it? search for results where that sid triggers.

Speaking of network activity like URLs, CVE numbers, IDS sigs that trigger, etc. Those are all indicators that are further up the pyramid of pain. I would consider a CVE number a TTP or at least a “Tool” level indicator. Why? If you have detection for, or have patched a set of CVE’s that a threat actor use in their arsenal, or have set up a very convincing honeypot to mimic vulnerable conditions, and you detect those exploit attempts, you’re either no longer a viable target, or you’ve maximized the amount of time you have to mitigate compromised assets before they progress on their goals and objectives.

So to sum up, we went from IP address, to domains (plural) and IP addresses, file hashes, CVE numbers, campaign/malware name, etc. Its a lot of effort to do this, and that’s yet another reason I can appreciate the scope of sekoia’s original blog post.

Conclusion

So it’s the weekend, and this has already been a fairly massive undertaking as is. I’m going to stop here, because I want this to be digestible. Today I introduced you to the PolarEdge write-up by sekoia.io, and I’ve introduced you to the pyramid of pain, as well as the concept of pivoting off of “lower level” indicators on the pyramid, in an attempt to acquire “higher level indicators” on the pyramid to better defend against that adversary.

For your convenience, here is a list of all of the websites, services, and posts I’ve linked to in this blog, all in one spot. Truly, no one rule writer stands alone. I stand on the shoulders of giants.

blog.sekoia.io ← sekoia.io’s blog. Keep an eye out for interesting information on the horizon.
virustotal.com ← passivedns, urls, IP addresses, antivirus/blocklist/IDS tool verdicts, file hashes, sandbox results, etc. we all hate google, but I’ll be damned if I wont use their resources.
ipvoid ← collection of lookup tools related to IP addresses.
urlvoid ← ipvoid, but for full URLs, and/or sometimes domains.
urlquery ← think of this as a very basic sandbox. This website will point a web browser to a URL/domain, and report the results to you.
dnsdumpster ← if all you have is a DNS domain, this tool will try to map out information about that domain and/or try to find related domains.
mnemonic passivedns <–mnemonic’s passive dns database. It isn’t as HUGE as virustotal’s but having another perspective on passivedns data is never a bad idea.
Malware Bazaar ← Spamhaus and Abuse.ch’s collaborative portal in which researches submit information about various types of malware, and make it publicly accessible, include links to multiple sandbox runs, VT results, etc. Think of it as a slightly more open and amenable version of VirusTotal.
Threatfox ← another Spamhaus and Abuse.ch project, threatfox is more for network-based indicators associated with malware families, tags, etc. where Malware Bazaar deals in malware samples, filehashes, and sandbox results related to those samples. They both work extremely well together.
Hunting ← Look for IPv4 Addresses, Domains, URLs, File Hashes, etc. across abuse.ch platforms.
AlienVault ← a very long-lived, and very powerful threat intelligence platform. Users have the ability to create their own pulses, which sometimes leads to questions about reliability and vetting. Follow researchers and use their pulses at your own risk. Generally, the default “Alienvault” account has very good, reliable intel reports, and the pulses are usually label with information and references to the original research reports, if possible.
any.run ← a very good malware sandboxing platform. Requires a registration process to get a free account.
tria.ge ← another very good malware sandboxing platform. Requires a registration process to get a free account.
Intel Owl A Threat Intelligence platform that tries to automate the enrichment of whatever limited IOCs you have to work with. Initial setup sucks, because you need to signup to multiple services, and input API keys and other nonsense, but once everything is hooked in, its a valuable way to check multiple platforms at once for a variety of indicators.
MISP ← Considered the premier open-source threat intelligence platform. Requires a lot of reading to get it set up to handle events you want it to handle.
TheHive/Cortex ← Some of you have atlassian tools or other fancy, shitty, overpriced software for ticket and work management. This is a sort of open-source ticket platform. Consider this to be something like an analyst notebook for threats you are researching.