From Throwing Zero-Day to Scanning the Internet

Imagine, if you will, a phone call at 3 a.m. from a junior analyst, ranting and raving about communication with an IP they read about in a massive breach report…two years ago. Your slumber, interrupted. Your faith in reason, corrupted. Your rage, erupted. Welcome…to The Atomic Indicator Zone.

Atomic indicators are one of the hottest potatoes thrown around in the threat intelligence community. The pendulum of public opinion swings all the way from “completely useless” as a detection mechanism to “here’s a bunch of our money, give all IPs to us.” The ground truth of their actual utility lands somewhere in the middle.

Recently, Gigamon ThreatINSIGHT™ discovered a unique example that demonstrates a common issue with atomic indicators — primarily, their temporal weakness — but also provides a perfect opportunity to discuss how organizations can make better use of indicator data. This blog will dive into the details of what we observed and provide some advice and implementation methodology that has served us well.

Flashback

In June 2018, Gigamon Applied Threat Research (ATR) observed a document containing an exploit for a zero-day vulnerability in Adobe Flash being used to likely target victims in the Middle East. As part of this analysis, we discovered that the juicy bits of the code weren’t built in. This was a stager that pulled down additional code from a host associated with the domain people.dohabayt[.]com.

This domain was resolving to hosting provider Abelohost B.V., specifically 185.145.128[.]57. While the host had an interesting past association with a large number of suspicious domains, it was previously unknown to us. Now, with the association to this activity, the IP and domain were certainly on our radar. Contextually, IP is good; IP and domain is better.

What did we find? In summary, an unknown adversary leveraged an Adobe Flash zero-day via shared-hosting infrastructure to exploit victims in the Middle East.

Present Day — Oh How the Mighty Have Fallen

On August 9, 2020, ThreatINSIGHT observed network traffic from our previously suspect host, 185.145.128[.]57. We know what you’re thinking: holy cow, right? An old detection firing on some past big bad would get any analyst’s spidey sense tingling. The Gigamon ATR intelligence team reviewed the traffic as part of routine discovery efforts. Except that the traffic looked entirely different than what was previously associated with the indicator. Rather than being a sparse outbound SSL/TLS connection from a workstation (low and slow), this traffic was inbound and spanned across multiple distinct networks — talking to everything, not caring who was listening.

To confirm our suspicions, Gigamon ATR cross-referenced our observations with GreyNoise (greynoise.io) which also confirmed our findings: on August 9, 185.145.128[.]57 was no longer a juicy, zero-day exploit distributor but instead simply a run-of-the-mill internet scanner. Moreover, it has been quite a bit of time since our first observation and it likely has done a ton of innocuous things during the timeframe.

---

Leveraging Atomic Indicators in Detection

Our example above clearly demonstrates something that every analyst deals with: the common weaknesses in atomic indicators. Some common weaknesses we observe are:

• Temporality – Time is money. More importantly, time is context. Network-based atomic indicators are relevant at the point in time in which they are observed, in use, during a campaign. Any relevance outside of that directly observed timeframe/campaign can vary wildly in terms of how confident we are that it’s even still malicious. Additionally, exposure has a large impact on the continued usefulness for atomic indicators.
• Disposability – Atomic indicators are isolated representations of infrastructure and capabilities. Infrastructure and capabilities often vary between campaigns, making many of the unique indicators disposable. An important distinction here is that “disposable” does not mean it will be disposed of. However, the fact they could be easily thrown away is a warning to temper our expectations on fidelity for detection. It’s also worth noting that not all indicators are equally disposable. It’s a heck of a lot “cheaper” to burn an IP address than it is a domain than it is to burn a legitimate SSL code-signing cert.
• Lacking context – Atomic indicators, by themselves, lack the bigger picture. How were they used? What were they used for? Those answers are critical pieces for an analyst tasked with reviewing matches. For example, if an actor used dropbox[.]com for uploading stolen data, blindly adding this domain as an indicator might generate a whole bunch of unnecessary false positives.

In the specific example above, the IP address we had as an atomic indicator represented an “offshore” shared hosting environment, which generally has higher degrees of temporal weakness and is more readily disposed of by actors.

Detecting past atomic indicators should be the easiest wins for your detection strategy. If you have seen these indicators before and nothing fires within your environment, that’s just a missed opportunity. It’s a mistake to assume that just because an indicator is “weak” also means it isn’t useful, especially if you can mitigate and understand the weaknesses associated with that indicator. Even an IP address, commonly thought of as the most flammable of indicators, isn’t always the easiest thing for an attacker to get rid of.

If a known threat has been observed associated with an indicator, the re-observation of said indicator is a relatively easy win to catching the crook. Assuming, of course, that collection, processing and analysis are not too costly for the value.

A great example of weakness not dictating usefulness is when Gigamon ATR detected persistent threat actors reusing infrastructure — in this case a malicious domain used for C2 — specifically because we were collecting and matching on atomic indicators. That detection was then confirmed by other supporting evidence and behaviors because, again, context is king. We have found certain factors contribute to success in using atomic indicators:

• The spectrum – Atomic indicators, and other campaign-specific attributes, are part of a larger spectrum. Be aware of their return on investment and accept their value. Recognizing and realistically understanding the value they provide is critical to prioritizing what effort you put into their use. Due to their limitations and relative bulk form (that giant list of IPs your boss emailed you), automating as much of the collection, processing and analysis of indicators and follow-on matches is critical. Analysts should focus on how indicators truly indicate the larger threat.
• Oh, what a time-to-live – Recognizing that indicators get weaker with time, generally applying a time-to-live (TTL) value to the indicator will minimize the risks of overloading what you have to look through. TTL can be a double-edged sword because it also presents a risk of not matching on something just because that indicator expired. It’s critical that you are aware of the risk and apply the TTL intelligently. Some aspects of indicators that we have found to be useful in considering TTL:
  • Confidence of the indicator
  • Type of indicator (IP, hash, domain, SSL cert)
  • Severity
  • Subject of indicator (Emotet, Oilrig, Beacon, for example)
• Go organic – Your environment, or your technology provider’s environment, has a wealth of useful information about indicators you get from third parties, and it is crazy not to use it. For Gigamon ThreatINSIGHT, we look at all atomic indicators we ingest to measure prevalence in our global customer base, cross-reference with PDNS and enrich on overlapping matches from other sources. This allows us to help assess the nature and confidence of the indicator and evaluate how we use it.
• Go even more organic – While we’re on the topic of “organic” indicators, why not insert a feedback loop from your internal alerting platforms (your SIEM, EDR, or others) to record indicators unique to your environment? Leverage them for further visibility and detection. Unless you don’t trust your alerts (that’s an entirely different conversation), these atomic indicators are valuable: They exist in your environment (potentially as part of an ongoing campaign), they’re current and you have a lot of context on them. Self-derived intelligence can be extremely useful.
• Keep the scent – Indicators should be tracked and enriched, and always maintain the context of their collection. How were they used? What were they used for? In what stage of the kill chain were they observed? In what protocols did you observe them? All of the context could be used to craft more behavioral style detection rules with an indicator match being a factor.

For example, imagine we leveraged GreyNoise to collect all SSH worm indicators and enrich with their labels; we might create behavioral logic looking for successful SSH logins from those worms (long durations, large sizes, persistent communications, Zeek’s SSH success field). Simply seeing an internet scanner is not that interesting. Identifying opportunistic exploitation leveraging that as a data point? Well, that’s very interesting.

The bottom line is, when these indicators are used correctly, they can be powerful. If you can efficiently automate the collection, processing and analysis of atomic indicators, they do provide value and increase detection opportunities.