IcedID Command and Control Infrastructure

A frozen lake with the ice breaking apart

Earlier this week, the DFIR Report published an interesting analysis of an intrusion with the notorious SodinokibiREvil ransomware. The intrusion used IcedID as the initial access broker: many ransomware actors use another malware campaign to gain access to an internal network and IcedID has become a very popular choice for that.

This blog post demonstrates how the IOCs shared by the DFIR Report can uncover more command and control infrastructure linked to IcedID, some of which has not been published before.

IcedID, also known as Bokbot, was discovered by IBM X-Force in November 2017. Initially operating as a banking trojan, it has since made the same move that Emotet had made previously and is now used to serve a foothold within a network. This is then later used by a ransomware operation.

The DFIR Report’s analysis lists cikawemoret34[.]space and nomovee[.]website as IcedID command and control servers used during the intrusion. These domains were hosted on the IP addresses 206.189.10[.]247 and 161.35.109[.]168 respectively.

It is always a good idea to see what other domains were hosted on these IP addresses. Using Silent Push passive DNS data, on 206.189.10[.]247, Martijn also found the following domains:


While on 161.35.109[.]168, Martijn found:


Unsurprisingly, most of these domains have been publicly linked to IcedID.

All the domains were registered through Porkbun in February or March and parked there initially before switching to Cloudflare’s name servers and pointing to the aforementioned IP addresses. This switching happened at different times for different domains, suggesting that the switch was made just before a domain was used in a campaign.

One domain stands out:


This website first switched to using name servers belonging to Russia’s Server Space and pointing to the IP address 143.198.25[.]214, before switching to Cloudflare and 206.189.10[.]247 a little over a week later.

So, looking at 143.198.25[.]214, the following domains hosted there can be found:


All but one of these domains were registered at Porkbun, the exception is the slightly older seconwowa[.]cyou, which was registered through NameSilo.  

Just like the previous set of domains, all these domains switched to using Cloudflare’s nameservers at some point and switched IP addresses at the same time. However, some first pointed to 83.97.20[.]176 before pointing to 143.198.25[.]214. On the former IP addresses, four more domains were found:


Again, these used same pattern of registering at Porkbun before switching to Cloudflare’s name servers and the above IP address.

Of the latter two lists of domains, only some have been publicly linked to IcedID activity. However, the similarities noted above, as well as the choice of TLDs, suggest these domains belong to the same infrastructure and either have been or will be used in IcedID campaigns.

There is a pattern there: a domain gets registered, usually at Porkbun, and parked there for a while before its name servers switch to those of Cloudflare when the domain points to a new IP address. This IP address hosts multiple of these domains. There is also a preference for slightly unusual top-level domains.

Using this pattern, one can dig into the Silent Push data trove to look for other domains that satisfied this pattern. After sifting through the results to filter out false positives, the analyst ends up with a list of domain names and corresponding IP addresses of which he considered very likely to belong to IcedID’s infrastructure.

Many of these indicators have been published previously, for example on Maltrail’s GitHub, but many others have not been publicly linked to IcedID before.

You can find the full list of 58 IP addresses and 323 domain names (and 402 combinations: some domain names have pointed to multiple IP addresses) on our GitHub page.  


Malware like IcedID plays a crucial role in many large cybercrime campaigns, including ransomware, which can be very costly for the victim organization. Early knowledge of indicators is thus important, even if these indicators haven’t all been publicly linked to the malware. This blog post demonstrated how to find hundreds of such indicators by spotting some patterns in the domain behaviour. 

Thank you to John Jensen and Ken Bagnall for their contributions.