Infrastructure Diversity — Hunting In Shared Infrastructure

As an attacker, it is all too easy to settle down into a rhythm. That rhythm of operations, the specific techniques and automation involved with conducting offensive work, boiled down to foundational tradecraft decisions that are often reused between campaigns. Why reuse of tradecraft between campaigns? Well, it enables scalable and efficient operations; unfortunately, it also creates a digital fingerprint. We have seen the results of this at a national level with the deep revelations of the operations of advanced threat actors. Recently, I have shifted jobs into a Security Engineer role where I get to work with customers and with “BIG” (notice the caps) data to do network forensics and threat detection. Being on the defender’s side of the breach has definitely helped to refine certain aspects of my tradecraft. Don’t worry… I will still be blogging about red team stuff :).

Infrastructure

In an offensive operation, the infrastructure that supports the operation is composed of both attacker owned assets but also . Neutral space might be made up of compromised victims being used for command and control (C2), VPN providers, 3rd party API services, or shared hosting providers. More info on this from the red team perspective can be found in Jeff Dimmock ( “neutral space” @bluscreenofjeff) and Steve Borosh’s (@424f424f) Red Team Infrastructure Wiki. The focus of this blog post is on shared hosting providers from the red and blue angle.

Digital Ocean, Linode, Amazon, OVH, Microsoft, Vultr… there are countless cloud providers that offer platforms to spin up offensive infrastructure. While these services make poor choices for adversaries in some regards (namely attribution through billing), with the proper preparations, they make outstanding assets that are already in place and easy to spin up.

Hunting Shared Infrastructure

Threat hunting often begins with a hypothesis or intel-based assumption surrounding adversary patterns/techniques, then involves the collection of data, enrichment and contextualization of data, and exploration of the data to spur investigations. Knowing that adversaries like using shared infrastructure, a potentially interesting hypothesis to explore is “Threat actors are using shared infrastructure to phish or control malware in my environment.” Before going further, here’s a disclaimer: just because something is using shared infrastructure does not make it malicious… it is just a great place to start looking. Make sure you understand your environment and implications of potential actions. In the wise words of someone I really trust, “You can’t detect what you can’t see”.

Identifying Shared Infrastructure

This won’t be all-encompassing, but here are a couple of easy ways to identify the use of shared infrastructure. The first method is to enrich results in bulk with ARIN whois lookup results, specifically the organization record. I obviously recommend 100% netflow rather than sampled results to ease the pain of dealing with asynchronous C2. With this feature, you can filter down to a list of known and common providers of shared infrastructure. Something to keep in mind with this approach is that as an adversary, I would counter by simply using very obscure foreign VPS providers that are a dime-a-dozen.

The next method I prefer to use is to enrich netflow data in bulk with the aggregate count of passive DNS results per destination IP, either from your environment or ingested data from a 3rd party. Adding in known name resolutions from VirusTotal also gives you more data, and the more data the better with passive DNS. IP addresses that have been associated with a large number of DNS results are likely some type of shared hosting environment.

You’ll note here that both of these methods rely on an organization’s ability to do basic netflow capture and enrichment.

After Discovery

This could really be an entire post on its own. For now, I will highlight that after identifying shared infrastructure, monitoring and investigation of that infrastructure is useful. In my opinion, a mature network defense team will be intimately familiar with any legitimate connections to shared hosting providers or remote access partners. Going through this identification process will help you build the list of known good connections. Questions that I generally ask around any connection out to shared infrastructure:

• Are there other suspicious features of the domain (age, reputation, categorization, VT hits, threat data match, etc)
• Is the traffic regularly repeating? If so, at what time intervals?
• For any content we can see (not encrypted), what type of activity is performed?
• Is the activity limited to certain internal ranges / subnets?
• How many assets do I see this activity originating from and how many requests per 24 hr period? If you are an MSSP, have you seen this in other customers, or in the same industry based customers before?

Red Team Lessons

I often get trolled for answering every red team question with “It depends on the training objective”. For real though, it is all about the training objectives. I personally think that the detection of malicious remote access with shared infrastructure is a GREAT training objective and, therefore, recommend not varying tradecraft patterns until necessary! Detecting malicious shared infrastructure as an objective allows for progression, ie. the red team can get more sophisticated by diversifying across providers and changing C2 schemes.

In planning for when you need to progress, I would recommend that you diversify infrastructure, vary callback patterns, vary C2 schemes, vary working hours, and get out of your comfort zone.

Wrap Up

Blue teams: Do the basics and do them well. Building defensive capabilities is truly a hierarchical approach: there is no reason to buy the latest and greatest machine learning technique if you aren’t getting basic visibility into flow and DNS. If you can’t see across your environment, on different endpoints, in different countries, across subsidiaries, before the proxy, after the proxy, and at the core, you will not robustly detect malicious action. Start with one component, but strive for all. Finally, think of how you can enrich your data to identify suspicious patterns of attack.

Red teams: Don’t fall into so much of a rigid routine that it fails to be threat representative and fails to force blue teams to hunt you down. Think of the patterns you are creating and using in the operations. As the SOC and Hunt team matures, you will be forced to get creative. Plan for that day now!

Originally published at http://www.sixdub.net on April 5, 2017.