A meta-analysis of C2 locations and tools to help you find your bearings
Prologue: Know your enemy
Threat actors are actively attempting to exploit our digital infrastructure — often with little to no rules limiting their conduct nor concern for the damage wrought as part of their attacks. I encourage you to consider these threat actors through the lens of being our ‘enemy’ as part of a conflict that spans the Internet and crosses over into our networks.
“If you know the enemy and know yourself, you need not fear the result of a hundred battles…” — Sun Tzu, The Art of War
The famous quote actually concludes Sun Tzu’s Chapter III: Attack by Stratagem [1]. The chapter encourages comparing the resources, attack surface, and mindset of both you and your enemy (it also has some fascinating insights on siege warfare). I think about our enemies often: Where are they located? How do they carry out attacks against us? and Who supports their efforts?
Table of Contents
- Crash-Course in C2 Tracking
- Where? Who? and What?
Shortcut: What Should You Block and/or Lookout For? - IOC-Cartographer
A. Domain-Map.py
B. IP-Map.py
C. Usage
D. Example Implementations - Conclusion
- Footnotes
Crash-Course in C2 Tracking
Our enemies configure their malware payloads to call-back to specific command-and-control (C2) servers so that the payloads can upload data and receive instructions. Malware analysts often track a C2 server by the server’s IP address (and port number) as well as the domain name used to resolve the server. C2 channels that tunnel through 3rd party applications, such as Telegram, can also be documented in this manner [2]. Tracking the domain names and IP addresses of C2 servers can help network defenders block and detect attacks. The DNS and IPv4 infrastructure which supports these C2s can also be leveraged for insights on our enemies.
Domain Name Parentage
Domain names are defined by hierarchical levels — with a ‘parent domain’ being leveraged to register more-specific ‘child domains’. Commonly, a fully-qualified domain name (FQDN) is broken-down into a top-level domain (TLD), a second-level domain, and further sub-domains. A TLD (such as .io in the FQDN abjuri5t.github.io) is the beginning of an FQDN’s hierarchy — it defines the registry infrastructure which a domain belongs to.
Management of the FQDN abjuri5t.github.io begins with the Internet Computer Bureau — who administer the registration of the TLD .io. GitHub has registered a second-level domain with the Internet Computer Bureau, registering github.io as a domain belonging to GitHub. GitHub’s infrastructure is now the authority for all sub-domains beneath *.github.io. Using GitHub’s automated website hosting infrastructure, I requested that GitHub register “abjuri5t” as a sub-domain — constructing the FQDN abjuri5t.github.io for my account’s GitHub Page.
Similarly, our enemies will go through related domain registration processes so that their malware can connect to their C2 servers (jump to Who is supporting the enemy’s infrastructure? for more details).
IP Hosting and ASNs
At the time of writing, the server https://abjuri5t.github.io is being hosted at the IP address 185.199.110.153. This IP address is contained in a group of IP addresses that make up the range 185.199.108.0/22 [3], which is registered as part of Fastly’s content delivery network. Fastly’s registration of these publicly-available IP ranges is tracked as Autonomous System 54113 and includes various IP ranges which add up to over 300,000 IP addresses.
Various organizations will register their own blocks of public IP addresses for the purposes of communicating, accessing, and sharing content on the Internet. These organizations (including Internet service providers, universities, cloud services, and large enterprises) will all have their own Autonomous Systems and ranges of IP addresses. After staring at the IPs from thousands of C2 servers and investigating their registrations, I began to notice patterns among our enemies’ infrastructure.
Where? Who? and What?
Where is the enemy?
As cyber-security professionals, we do not generally operate in the physical world. Instead, our networks exist in an amorphous landscape of digital infrastructure — which is, frankly, not strictly defined by our physical world nor laws [4]. Instead of bothering with geolocation, I track where our enemies are located on the Internet’s digital infrastructure.
Individual IP addresses and domain names can function as individual markings of digital infrastructure. However as explained above, these C2 artifacts have their own layers of infrastructure which we can exploit to get a digital location. Studying patterns among IP addresses can highlight which ranges regularly host our enemies’ servers. Likewise, tracking domain name hierarchy can show the specific levels of domains that they leverage.
Sometimes I like to imagine these digital locations (and patterns among them)
as ‘neighborhoods’ in a city that is the Internet. Tracking patterns among
which digital neighborhoods are used for cyber-crime can provide insight into
the 'dangerous neighborhoods on the Internet' — tell your computers to beware
of these areas.Who is supporting the enemy’s infrastructure?
Based on SarlakLab’s research (mainly tracking commodity malware and part-time cyber-criminals), the majority of C2 hosting providers fall into one of three categories:
- Abused services — common hosting providers and cloud services that are leveraged for malicious purposes. Our enemies will either register directly (like you or any normal customer would) or compromise existing accounts. Examples include AWS, Tencent, Azure, Huawei, Google Cloud, and some DDNS providers.
- Hacked infrastructure — typically residential IPs, small businesses, and universities. Cybercriminals will hack various servers, compromise user endpoints, and pwn websites. This hacked infrastructure is then leveraged as part of botnets and phishing sites — as well as hosting complex layers of proxied C2 servers. It is often difficult, though not impossible, to contact the legitimate owners of this hacked infrastructure — thankfully ISPs (and occasionally law enforcement) can assist with removing our enemies from it.
- Criminal hosting providers — occasionally referred to as “bullet-proof hosting providers”, these organizations are owned and operated by cyber-criminals who intentionally support malicious infrastructure. A few of these hosting providers will outright say that they are part of a cyber-crime group. Others claim to be legitimate and just ‘privacy-focused’ or somehow unable to enforce security on their own infrastructure. Of course, there are legitimate organizations with similar privacy goals and internal enforcement challenges… but many of these hosting providers care far too little for me to believe they’re not intentionally criminal [5].
Tracking who supports our enemies’ infrastructure can provide insights into who is being irresponsible, who needs our assistance in fighting these enemies, and frankly: who needs to be stopped.
Shout-out to Ngrok! In January SarlackLab's automated C2 tracking uncovered and
reported on an increase in C2 servers leveraging ngrok.io domains. Executives
at Ngrok REACHED OUT TO US so that we could work together to fight abuse of
their platform! Ngrok truly cares about stopping our enemies - and the
SarlackLab team is proud to be working with them.What Should You Block and/or Lookout For?
Your best block-lists (or IOC alerts) are largely going to depend on the nature of your network. I recommend investigating your SIEM and/or firewall logs to determine what online infrastructure is commonly leveraged on your network (see IOC-Cartographer for help visualizing this).
The vast majority of networks will not need access to criminal hosting providers or hacked infrastructure. Such infrastructure is hard to uncover — though many security companies sell blocklists (of varying quality) which can reliably be implemented to block this dangerous infrastructure. If you are implementing blocklists on a budget, I recommend checking-out these free resources:
- Feodo Tracker, ThreatFox, and URLhaus by Abuse_CH and community
- C2 Tracker by ViriBack
- C2IntelFeeds by drb-ra
- and our very own C2 meta-analyses — Blocklist-recommended (mainly clusters of criminal hosting providers and hacked infrastructure) and Indicators-recommended
For most networks, one cannot just block every artifact that has the potential of being malicious — however we can all still leverage meta-analyses for indicators. We can augment our existing detections and enrich our intelligence using patterns uncovered from these meta-analyses. For example:
Approximately 13% of C2 servers tracked by SarlackLab are hosted across different subnets of Amazon’s AWS infrastructure. Blocking all connection attempts from your network to these AWS subnets should stop approximately 13% of malware C2 channels… but such firewall rules would also cause significant disruption due to the amount of legitimate services hosted by Amazon.
Instead of blocking all their infrastructure, I recommend being aware of Amazon as a common hosting provider for C2 servers and then using their IP ranges to enrich the details and validity of your existing network detections.
To help defenders stay up-to-date on commonly abused infrastructure, we re-run
SarlackLab's meta-analysis daily and publish trends in Indicators-recommended.
Other common domain services which are frequently abused by our enemies
include: *.cloudfront.net, *.apigw.tencentcs.com, *.azureedge.net. Mr.d0x
actually runs a great website Living Off Trusted Sites Project where he tracks
and documents the abuse of such services (though I cannot personally validate
the abuse frequency).Several top-level domains have a tendency to be leveraged for C2 server resolution, according to our meta-analyses. The most frequently malicious TLDs in our data include *.top, *.xyz, *.ru, *.fun, *.shop, *.online, *.info, and *.site. For the most part, legitimate websites and online services do not typically use these TLDs. In addition to C2 servers, various online scams and phishing sites will also frequent these TLDs. Depending on your network, it may be beneficial to preemptively sinkhole all DNS requests for subdomains under these TLDs — and then add exclusions for specific domains as-needed.
Finally, Dynamic DNS providers and related proxying services — such as *.duckdns.org, *.ddns.net, *.ngrok.io, *.no-ip.biz, *.no-ip.org, *.zapto.org, and *.hopto.org— are used to register over half of all the C2 servers tracked by SarlackLab. Unless your network has a specific use case for one of these servers, I strongly recommend sinkholing and alerting-on all DNS requests for them.
The exact artifacts which you should be aware of, detect, or outright block will largely depend on the nature of your network. As I quoted at the beginning of this rambling, you must “know the enemy and know yourself”. To assist in understanding the enemies that are attacking you, I have shared some of our meta-analysis scripts in the TLP:CLEAR release of IOC-Cartographer.
IOC-Cartographer
IOC-Cartographer is a tool that I wrote to help better understand our enemies via mapping their malicious infrastructure. Users will need to provide their own lists of IOCs to one of the tool’s main Python scripts.
Domain-Map.py
Network defenders can run Domain-Map.py to visualize patterns among malicious domain names.
The script parses a list of FQDNs, calculates statistics among the submitted domains, and then generates a visual depiction of domain trees. The right-most portion of a tree shows its top-level domain — with common levels of sub-domains depicted in branches towards the left. For example:
service-1cao6cjs-1312654103[.]gz[.]apigw[.]tencentcs[.]com [6] is represented as a wildcard option underneath the .com TLD.
IP-Map.py
Instead of having to worry equally about billions of IP addresses between 1.0.0.0 and 223.255.255.255 [7], threat researchers can use IP-Map.py to generate a heat map of IPv4 space and help prioritize IP addresses of concern.
IP-Map.py takes a list of IPv4 addresses, parses their generic ranges, and depicts their frequency on a Hilbert Curve map of IPv4 space. In April 2024, there was an increase in C2 servers hosted within the 154.0.0.0/8 space. The SarlackLab team actually tracked a few hundred CobaltStrike C2 servers that were temporarily hosted in this space, primarily between 154.216.54[.]0–154.219.191[.]255.
Usage
Source code: https://github.com/Abjuri5t/IOC-Cartographer_TLP-CLEAR
python3 Domain-Map.py example-Domains.list
python3 IP-Map.py example-IPs.list <color-wieght>
python3 slash-16_IP-sub-map.py example-IPs.list <first octet> <color-weight>Please reference README.md for full documentation on running the scripts. If you need assistance or have suggestions, you can contact the SarlackLab team.
Example Implementations
GreyNoise — I released the initial version of IOC-Cartographer while presenting my research to the Boston Security Meetup. At a bar a few months later, I was informed by Sales Engineers at GreyNoise that they had begun using IP-Map.py to help visualize their data.
GreyNoise Intelligence tracks all sorts of malicious infrastructure across the Internet. The above IPv4 maps show where on the Internet the Mirai botnet was hosted in June, 2024. The rightmost map depicts Mirai as a whole and the leftmost highlights specific areas of 5.0.0.0/8 which host the botnet.
Infostealers | RATs — As a key part of their functionality, both information stealers (infostealers) and remote access trojans (RATs) need to be able to communicate with their command-and-control infrastructure. In previous research, I’ve noted that there appear to be slight differences between the domain registration and hosting of their C2 deployments. Infostealers simply run once — stealing your information and sending it to a designated C2 server. RATs, in contrast, will attempt to keep their remote access to compromised endpoints for an extended period of time.
It’s anecdotal — but I’ve noticed that RATs almost always leverage domain names to resolve their C2 server and that their DNS infrastructure is usually part of some resilient DDNS provider. Infostealers will only sometimes leverage domain names — and those domains tend to be basic registrations that can be taken down easily. I speculate that the difference is due to the long-term planning for a RAT’s deployment — versus the rapid infection of an infostealer.
Conclusion
This blog post has been significantly more opinionated and different from most of my published work… it’s been weird to write [8]. Still, I hope that these views have inspired some of you to rethink how we handle our enemies. As a first step: grab a copy of the IOC-Cartographer scripts and try visualizing the infrastructure of a specific enemy or the logs from recent attacks. And of course: please keep the conversation going — share this blog post with friends and let them know what your thoughts on it are, send me a PR with an improvement for IOC-Cartographer, write a blog post with your own suggestions and best practices, or contact the SarlackLab team if you have any suggestions for us!
Handy link: What Should you Block and/or Lookout For?
Footnotes
[1] ‘Know yourself’ is an equally important part of this battle advice — we’ll be tackling that in What Should You Block and/or Lookout For?… Also on the topic of cyber-security and Sun Tzu, Jerry Bell actually had a fantasticly nerdy Twitter bot SunTzuCyber.
[2] Though they are fascinating, in this blog post we will be focusing on direct C2 servers — versus these C2 protocols which leverage existing servers. For now, my advice is to just sinkhole api[.]telegram[.]org (unless access to the service is required on your network for some reason).
[3] 185.199.108.0/22 represents the 1024 IP addresses between 185.199.108.0 and 185.199.111.255. Using a base IP address followed by a /n is called CIDR notation. Wikipedia has a great explanation of it here: en.wikipedia.org/wiki/Classless_Inter-Domain_Routing. In short: the size of the range is exponentially dependent on the size of n.
[4] This should not be used as an excuse to act unethically — just a reminder that we, as digital citizens, need to develop frameworks for our digital infrastructure. Hank Green actually wrote an awesome sci-fi series where he explores digital citizenship in our modern world.
[5] I’ve had different communications with these criminal hosting providers too… Many of them just ignore me — but occasionally the criminal ones will have some unkind words for my research and once they even tried to scam me.
[6] When this map was originally generated in January 2024, a CobaltStrike C2 server was hosted on Tencent, registered under the domain name service-1cao6cjs-1312654103[.]gz[.]apigw[.]tencentcs[.]com.
[7] Yes, I do in fact know about private IP ranges. I have skipped a number of pedantic clarifications in this blog because trying to clarify all of them would be a nightmare of footnotes on footnotes *.
* and I’ve written enough footnotes already
[8] I’ve been drafting versions of this blog post since Junior year of college (see git-blame).
