In the fall of 2018, We added botnet infrastructure detection capabilities to our Managed Security Services (MSS) and threat detection services.
In the initial press release, there were limited details released on how our machine learning system leverages our access to our global network infrastructure. We own and operate one of the world's largest tier-1 IP backbones, having insight into a significant portion of the global internet traffic and we are consistently ranked among the top five network providers in the world.
In this blog post, we’ll explain how our threat detection analysts used netflow data captured from our global internet infrastructure to uncover the previously unstudied layered network approach the operators of Dridex use, and its unexpected overlap with the Emotet infrastructure.
Once upon a time when analyzing Emotet traffic
It was observed by threat detection analysts that an Emotet C2 server was repeatedly communicating with the IP 18.104.22.168 over port TCP/38400. This was an abnormality in the Emotet network infrastructure behavior we’d seen so far.
In response to this abnormality, our threat detection team opened an investigation in an attempt to identify the purpose and behavior of 22.214.171.124.
During long term monitoring and analysis of netflow gathered from our global internet infrastructure we observed multiple malware families communicating with the IP over the same port, TCP/38400. The below image summarizes our observations:
In numbers, we observed the following to speak with 126.96.36.199 over TCP/38400:
- 10 Emotet epoch 2 C2s
- 4 Emotet epoch 3 C2s
- 7 Dridex C2s
Analysis of available open-source intelligence (OSINT) shows that 188.8.131.52 has been used by the group TA505 at 2019-06-20 to distribute the malware FlawedAmmyy1 2. The hosting company that the IP belongs to, Private Layer Inc, is an offshore hosting company which has been observed to be utilized by threat actors in the past.
The questions start stacking up, what is the purpose of 184.108.40.206? And is it still managed by TA505?
Exploring the connection to TA505
Given that FlawedAmmyy was distributed from 220.127.116.11 at 2019-06-20 it was investigated if TA505 still manages this server. The currently used SSH key was set in the timeframe 2019-06-20 - 2019-07-20 based on historical scanning data as Shodan performs internet wide scans at least once a month3:
If it was the case that the new SSH key was set at 2019-06-20 it indicates that the same operator which distributed the TA505 tied FlawedAmmy sample is also operating the administration of command and control servers connecting over port 38400.
Dridex has been distributed and used by TA505<sup4<>, which strengthens the connection.</sup4<>
Going against this theory is that TA505 has no known ties to the Emotet group, which begs the question why they would manage Emotet C2 servers.
Furthermore, no malware families which TA505 is known to use besides Dridex have been seen to communicate with 18.104.22.168 making the connection even weaker.
Based on these observations, it’s believed that the operator of 22.214.171.124 changed after the distribution of FlawedAmmy.
The use case of 126.96.36.199
Central to the use case behind 188.8.131.52 is knowing when the connecting servers are becoming active C2 servers. If they initially connect to 184.108.40.206 for a duration of time, then stop communicating and become active C2 nodes instead, it could indicate that the operator of 220.127.116.11 handover or sale of access to those servers.
On the other hand, if communication between the servers and 18.104.22.168 is ongoing while the servers are active C2s, it implies that 22.214.171.124 has a closer tie to the groups behind Emotet and Dridex.
We don’t believe that the operator behind 126.96.36.199 has coincidently hacked the same servers as the groups behind Emotet and Dridex, as the incoming connections towards 188.8.131.52 are almost exclusively Emotet and Dridex C2-servers, i.e. indicating non-randomness in controlled servers.
Dridex C2s activity timeline
Below is a timeline visualizing when it was observed that the Dridex C2s speak with 184.108.40.206 and also when they were included as C2s in Dridex binaries.
The timeline shows that the majority of the IPs are acting as C2s while they communicate with 220.127.116.11, which lowers the likelihood of the operator 18.104.22.168 to only handover access of the managed servers to other actors.
Emotet epoch 2 activity timeline
Doing the same analysis with the Emotet epoch 2 C2s shows somewhat inconclusive behavior:
It seems that they actively start speaking with 22.214.171.124 after or at the same time they became Emotet C2s. Five C2s with spotty monitoring coverage were excluded from the graph due to too little available netflow capture for timeline analysis.
Our threat detection analysts make the conclusion that the operator of 126.96.36.199 has strong ties to one of the current groups using the Dridex malware from late December 2019 and is continuing to this day. Threat actors face takedowns of their infrastructure and see a need for persistence and centralized control, as seems to be the case here.
The result of this discovery was used by the team to update the threat detection services coverage to monitor for command and control servers in customer environments before they are, if ever, publicly known. The team continuously monitors the underlying network infrastructure behind the operations of threat actors in order to improve our detection capabilities and uncover previously unknown relations.
In the recently released 2020 Global Threat Intelligence Report, our researchers and thought leaders share statistics and trends from the previous year. A key theme in this year’s report is ‘Threat actors are innovating and evolving their tradecraft’. Read more about how automation, multi stage payloads and custom targeted malware are changing the threat landscape here.
-  https://urlhaus.abuse.ch/url/210523/
-  https://securitynews.sonicwall.com/xmlpost/malicious-office-files-are-seen-distributing-flawedammy-rat/
-  https://www.us-cert.gov/ncas/alerts/aa19-339a
-  https://help.shodan.io/the-basics/on-demand-scanning