An autonomous system (AS) is a collection of IP subnets that is managed by a single administrative entity. Think of an ISP or a hosting provider, but also a large corporation or a university, many of which manage one or more autonomous systems. Each AS is assigned a unique number, called an ASN; in practice the terms AS and ASN are often used interchangeably.
ASNs play a crucial role in routing and thus in making the Internet work. However, because each of them is managed by a single entity, it also makes sense to assign a reputation to them, based on the amount of malicious activity hosted on the AS.
Silent Push assigns a reputation to each ASN, that takes into account both the number of active IP addresses within the AS and the number of these that are currently being used for malicious activities.
The reputation of an ASN reflects the current state rather than a historical reputation, so that ASNs that shut down malicious activity will see their reputation drop immediately. Historic reputation data is available through the API.
The Silent Push platform’s threat score reaches from 0 (best reputation) to 100 (worst reputation). The following are the ASNs with the worst reputation ranked by the number of IP addresses currently listed.
However, all of ASNs are all quite small, with each containing 2048 or fewer IP addresses. They host a relatively large amount of malicious activity, but in absolute terms, their contribution to ‘bad things on the Internet’ is pretty small.
Look at the ASNs below that contain at least 100,000 IP addresses (active or not):
Now, a number of well-known companies appear in the list, including Tencent, Digital Ocean, Alibaba and Google.
Each of these cloud providers make it easy for someone to quickly and anonymously set up a virtual server. That has many advantages for researchers and developers but also attracts those hosting malicious infrastructure, such as malware authors or those providing services to them.
It is not recommended to block something just because it is hosted by any of these providers. But something unknown hosted there definitely deserves some extra scrutiny.
Takedown reputation
In fairness, it is unreasonable to expect a hosting provider or other network to be able to proactively block all malicious activity on its network. After all, it’s not like a malicious actor is open about their intentions when renting a server or purchasing a domain.
This is why at Silent Push, one can assign a ‘takedown reputation’ to each ASN, that assigns a score from 0 (best reputation) to 100 (worst reputation). This measures how well an ASN takes down malicious activity hosted on its network.
If we add the takedown reputations to the previous table, we note they are all low, but in some cases not 0. This leaves some room for improvement for these ASNs when it comes to their due diligence in keeping the Internet free of malware and scams.
Finally, look at the ASNs with the worst takedown reputation. These are all pretty small, containing 4096 IP addresses or fewer, and have a takedown reputation higher than 90:
Conclusion
Simply ranking ASNs or hosting providers by the number of IP addresses that are hosting or have hosted malicious content ignores both their actual size and their responsiveness when it comes to takedown requests. By including both, Silent Push provides you with a clearer picture of what ASNs to consider somewhat suspicious, which combined with other context can help during an investigation.
Yesterday, a security engineer for the privacy-focused Brave web browser, tweeted about a domain impersonating Brave that was promoted through Google ads.
The domain was bravė[.]com.
Note the accent on the e, which distinguishes it from brave[.]com, the domain it was impersonating.
This is an example of an Internationalized Domain Name (IDN), a domain name that includes non-ASCII characters. Such domains have an ASCII representation that starts with xn-- and use punycode to convert from ASCII to unicode and vice versa. The ASCII representation of the impersonating domain is xn--brav-yva[.]com.
When IDNs are used to impersonate existing domains, one speaks of a homograph or homoglyph attack. Other than the use of accents on Latin characters, this also includes using similar-looking characters from non-Latin alphabets, such as using the Greek α instead of the Latin a. Though not incredibly common in practice, such attacks do exist and security researchers have warned about them for more than a decade.
The bravė[.]com or xn--brav-yva[.]com domain was registered through NameCheap in June and is hosted at 185.198.166.104, which belongs to ITLDC, a Bulgarian cloud provider with servers in a number of countries.
Using the Silent Push app, the user can see what else is hosted there:
Three more domain names were found, all IDNs: xn--ldgr-xvaj[.]com, xn--sgnal-m3a[.]com and xn--teleram-ncb[.]com. The unicode representations of these domains are lędgėr[.]com, sīgnal[.]com and teleģram[.]com respectively, presumably impersonating cryptocurrency wallet maker Ledger and messaging apps Signal and Telegram. (I say ‘presumably’ because signal[.]com and telegram[.]com aren’t actually linked to the respective messaging apps.)
These other three domains were also registered at NameCheap. Using the Silent Push passive DNS, it was found that none of the domains had been seen at another IP address, so the user cannot pivot any further.
However, could this actor have hosted other domains at a different server? Assuming they’d also use the same registrar and hosting provider, a search query was ran in the Silent Push API for domains starting with xn-- using NameCheap’s name servers and hosted on ITLDC’s ASN (AS21100).
Nine further domains were found. Two of them (xn--80aaw7ah[.]com and xn--80ahcmbumt[.]org) represent words in the Cyrillic alphabet and there is no reason to assume they are used for anything malicious.
The other seven, however, were all hosted on the same IP address (195.245.113.25) and all impersonate legitimate products, including once again Brave and Telegram:
The fake installer on bravė.com that prompted this research was an ISO file that appears to contain a version of the Redline infostealer. That suggests it may be related to a campaign analysed by Morphisec last month, where Redline was also served packed inside an ISO through malicious Google ads, impersonating Telegram and other services. The domain names involved in that campaign were also registered through NameCheap.
As for IDNs, there are tools that help one find homograph attacks on an existing domain name. However, it is through a comprehensive and easily searchable passive DNS database that one can find a bigger picture of the campaign using a homograph attack.
2021 may well be called, “the year of the targeted attack.” Over and over, threat actors have carried out carefully crafted operations using infrastructure tailored to specific victim organizations.
On the other side of the table, large organizations rely on security tools that, at best, attempt to block the indicators they observed hitting other organizations previously. These IOCs don’t necessarily relate to the defending organization, meaning blue teams regularly miss the actors crafting domains and infrastructure to get beyond their particular defenses.
It is too easy for the organized crime or espionage group to develop new, bespoke assets to attack an organization safe in the knowledge of how to evade traditional security products and services. Silent Push regularly sees assets set up with such specific evasion techniques in mind.
Silent Push often sees domains registered and then aged for a period of time before malicious use to avoid aged based reputation scores. There are often domains imitating supply chain partners of various types to avoid security practitioners and potential victims becoming suspicious when seeing them in logs. Rotating name servers and customized name servers are often used in order to communicate with specialized malware while avoiding fingerprinting rules and behavior-based detection techniques. At the same time, there are very few innovations from security vendors to react to these new techniques.
It is time for the security industry and those defending teams to fight back. Silent Push wants to equip enterprises with the freedom to protect themselves.
Everybody needs their own customized threat intelligence. If an organization can’t meaningfully search for the attacks that are being tailored to them, what chance do they have?
Silent Push is exposing the analytics to help organizations track and trace the very attacker infrastructure being designed just for them. This allows threat intelligence teams to shine a light on this infrastructure as it is going live so they have a chance to proactively defend their organizations instead of hoping to discover the infrastructure after it has hit someone else.
What can be done?
Enterprises have been expected to accept ‘black box’ thinking from their security vendors for years: ‘You don’t need to know the details of how we detect things, just pay us the money and trust that we are defending you.’ That clearly hasn’t worked.
Now, Silent Push is exposing the underlying connections and patterns to enable enterprises to create their own intelligence feeds, focused on what they need to defend against.
If 5 threat groups use the same malicious infrastructure provider, then the enterprise needs to defend against that infrastructure provider. If numerous advanced threat groups use the same technique of managing and aging domains over time, then the enterprise needs to be able to identify domains currently managed with that technique going live. If a virtual Bullet Proof Hosting Provider is the commonality across numerous campaigns by different groups then a defending enterprise must be able to identify the fingerprint of that provider to defend against it.
These are the things Silent Push can allow the enterprise to do, with the aim to empower enterprise Threat Intelligence teams with the right tools to generate their own new intelligence, and to fuse their current intelligence with new insights that help contextualize and prioritize what matters today.
Working with Intelligence Analysts as well as SOC teams over many years has led to an identification of pain points that just seemed solvable with a little thought. A couple of these pain points can be helped enormously by “Infra-Tagging”. This is a new term so just go with it for now while I explain.
The problem
There are many different ways to asses the relationship between domains. Each way involves numerous look-ups and then saving the results to compare them.
This is where Infra Tagging steps in. Using Silent Push, just do one API call for each domain to generate an Infra-tag. The tag will be of the form {mx.ns.as.reg} where MX= the domain portion of the first mail exchange record in DNS, NS= the domain portion of the top last seen Name Server, AS= the AS name of the assigned IP address of the A record, Reg- the registrar mentioned in Whois if available. If any field is unavailable it is replaced with a _.
A penetration tester was asked to try the Silent Push service to see how it could help him and his team to get their work done quicker. This is written in the tester’s own words and only uses the Silent Push ‘DNS Explore’ feature.
Reconnaissance
Reconnaissance is performed to gain as much information on the target before beginning the penetration testing. ‘Recon’ is an essential element of any penetration testing. Recon on a target can be done in two ways: passive and active reconnaissance.
During the recon process researchers try to collect information about the subdomains associated with the target and their respective IP address. Most applications today are protected using WAFs and CDNs and it is often challenging to identify the real IP address associated with an application. That is where the subdomains associated with the application help researchers get more information about the main application and expand the attack surface.
The Silent Push application can be used for passive reconnaissance quickly.
Case Study:
Domain : magicbricks[.]com
For the past few years, the tester has been testing web applications and spent around 2 to 5 days on collecting the information about each target. The information that he collected included all the domains that are associated with the company, their respective subdomains and IP addresses, as well as the information about the OS.
There are different search engines available for collections of the above information but there is no single place where more information can be found at any one time.
The tester worked on the application mentioned above a couple of months back and was not able to collect more information. Then, he gave it a try with Silent Push and the information was gathered in just a few minutes. Normally, it would take the tester several days to get that information from different sources.
1. The tester started by using their Explore DNS feature which accepts wildcards:
Explore DNS history using wildcards proved very powerful
2. The tester then searched for any records associated with the test domain:
Gathering all the DNS information in one place using the explore feature
3.The tester then realized he could use a wildcard and gather subdomains and see what CNAME records were gathered and what IPs subdomains were using.
Gathering all subdomain info using a wildcard
4. This allowed the tester to pivot off this information and see what else was pointed to the same infrastructure:
Mahesh could see all A records pointing to the same IP straight away
5. The tester could enrich that information to find out more about ‘the neighbours’ and see what sort of reputation was associated with them.
This looked like a clean domain
Conclusion
Even though the tester was not on a threat intelligence team, the simple data gathering capabilities of this part of the Silent Push application saved him enormous amounts of time. Quite literally, this saves the tester days per job. The use cases across entire security teams is tremendous.
Last week, Cisco Talos published a blog post with new research on LodaRAT. Apart from updates to the Windows version of this malware, the researchers also found Android malware (‘Loda4Android’) written by the same group. They link both versions of the malware to an ongoing campaign targeting people or entities in Bangladesh.
This blog post reveals some further infrastructure used in this campaign.
LodaRAT
LodaRAT, or Loda, is information gathering malware. It has the ability to take screenshots of infected machines, record keystrokes and sound and allows its operators to send commands to the machine. It was first analysed by Proofpoint in May 2017.
In most of its campaigns, LodaRAT has been spreading through malicious documents, that either contained malicious macros or exploited vulnerabilities in Office. Some earlier campaigns exploited CVE-2017-0199, while more recent ones exploited CVE-2017-11882. Though patched several years ago, the latter vulnerability remains popular among malware authors.
Among the indicators of compromise shared by Talos is the domain lap-top[.]xyz, from which a malicious APK file was served. This domain was registered in October and points to 134.122.120[.]22, an IP address belonging to the popular cloud infrastructure provider Digital Ocean.
While looking in Silent Push’s database for other domains that have pointed to this IP address, Martijn Grooten noticed two that turned out to be actively serving LodaRAT: corona-bd[.]com and imei[.]today.
Using the COVID-19 vaccine as a lure
At first glance, corona-bd[.]com looks like an official Bangladeshi government website with information on the coronavirus. That’s not surprising, because in an iframe it contains that very website, hosted at corona.gov.bd.
But right above the iframe, there is a grey bar with the Bengali text “প্রথমধাপে অগ্রাধিকার ভিত্তিতে করোনা ভাইরাসের টিকা পাওয়ার আবেদন করতে এখানে ক্লিক করুন।” which Google helped me translate to “Click here to apply for the corona virus vaccine on a first-come, first-served basis.”
The real Bangladeshi government website (left) and the fake one with an extra link on top (right)
This link goes to a form that asks for many personal details, some of which (such as “Freedom Fighter Status”) may appear unusual for non-Bangladeshis. Upon filling in the form, you are presented with a page telling you your application has been accepted. It is unclear whether the information filled in the form is used in some way, but JavaScript carefully checks you have filled everything in, after which it is submitted to the server in a POST request.
Once you have submitted the form, you are urged to download the a copy of the application. Apart from a receipt number, which is different every time the page loads, you are given a password to open the application. The application turns out to be a zip file protected with this password and inside is a variant of LodaRAT (SHA256: e78546bb33df88c6be3afce32f5d13084295a6e0599b26c3b380d54318170d86).
It is unknown how people end up on this website: whether it relies on natural traffic, or whether the campaign urges specific targets to visit it, but the context of the campaign and the apparent lack of public links to it make the latter more likely.
Interestingly, the domain corona-bd[.]com had been active many years ago, when it hosted the website of a fashion company. Last spring, it was registered again to serve information related to the coronavirus pandemic.
From the copy on the Wayback Machine, Martijn couldn’t determine any malicious purpose of this website, but it shared an IP address with a number of domains that Talos also linked to this campaign, so it is likely that the same actor was hosting it already. This would suggest this campaign, or at least preparations for it, started well before October.
Fake IMEI checker
The second domain, imei[.]today, hosts what appears to be a checker for IMEIs: numbers that uniquely identify mobile phones.
The page lay-out is largely copied from the legitimate site imei.info, but made to look to belong to the BTRC, the Bangladesh Telecommunication Regulatory Commission. This site thus too targets Bangladesh, even if it is written in English, a language however still widely understood in the country.
Legitimate (left) and malicitious (right) IMEI checker
Upon entering a valid IMEI number (client-side JavaScript performs the ‘Luhn check’), the user is served a zip file. Inside this zip file, which this time is not protected with a password, is another variant of LodaRAT (SHA256: cf29981bfec0f0cf2abd54ae469c8795a3cf1e19c715ded329fdb2707f982407).
Other domains
While I found these domains because both have used the IP address 134.122.120[.]22, they have in fact shared several more IP addresses. And there are several more domains that have used some of these addresses in recent months.
One is mybnp[.]club. This site looks near identical to bnpbd.org, the website of the Bangladesh Nationalist Party (a Bangladeshi political party), from which it includes most content. The only difference is a line on top that says (in Bengali) “Click here to register to become a member of the BNP” that links to a signup page. This signup page contains an iframe that loads content from http://educationboardresults[.]net/php/application/.
However, there is no content there: educationboardresults[.]net is a parked domain. Moreover, mybnp[.]club does not render well in most modern browsers, due to mixed content errors. It may be that this site was intended to be used in the campaign but then abandoned.
Other domains that have used IP addresses in the same set include av24[.]co and bracbank[.]info, both of which were mentioned by Talos, but also bkash[.]club, bkashagent[.]com, aktel[.] org and zepode[.]online. All of these are relevant to Bangladeshis: bKash is a mobile financial service in Bangladesh, AKTEL is the former name of a mobile phone provider in Bangladesh, and Zepode is an ecommerce platform popular in the region.
Information on aktel[.]orgon Silent Push’s dashboard.
Apart from using some of the same IP addresses, all of these domains use two nameservers ns1.domain and ns2.domain with domain the domain itself and both name servers pointing to the same IP address as the domain’s A recor , a somewhat peculiar set-up.
Martijn had not been able to find any content hosted on these latter four domains, but that does not mean URLs with malware don’t exist. It is also possible that these have been registered for future use in this campaign.
A hacker-for hire campaign?
Writing about the discovery of LodaRAT activity in Bangladesh, Cyberscoop suggests it might belong to a hacker-for-hire group.
Last year, several hacker-for-hire operations (sometimes referred to as ‘cyber mercenaries’) have been uncovered. Such groups make cyber-espionage capabilities available to companies, political organisations as well as nation states without their own offensive cyber capabilities.
LodaRAT’s activity has all the hallmarks of such an operation. First, the geographic spread of the activities: Talos believes the group is based in Morocco (which is why it is referred to as ‘Kasablanka’) and previous activity by this group was linked to Latin America, while this campaign targets Bangladesh. The Android malware used by this group has been linked to campaigns in the Middle East.
Secondly, the malware focuses on gathering information rather than on direct financial gain, which would be common for malware used by a more traditional cybercrime group.
And thirdly, this particular campaign appears fairly targeted. While the real size can’t be determined without global telemetry, a more widespread campaign would have likely left public traces through search engines and public thread feeds.
Of course, none of this is conclusive proof of the kind of operation this is. Nor does it mean that the authors of the malware are the same as the ones conducting this campaign.
Conclusion
Malware and phishing campaigns make a serious effort to stay under the radar. However, limited resources forces threat actors to reuse infrastructure.
In this case, with the Silent Push API, Martijn was able to use this weakness to uncover more infrastructure used by the ‘Kasablanka’ actor in its targeting of Bangladesh, based on a few publicly posted indicators.
With contributions from Ken Bagnall and Nick Kostopoulos.
Of these, 94.130.110[.]78 had a PTR record set to be vps.corona-bd[.]com, while 134.122.120[.]22 used vps.lap-top[.]xyz as a PTR record. This confirms that at least these two IP addresses are or were attacker owned rather than shared hosting space.
Some other IP addresses that the domains have pointed to were shared with too many unrelated domains to considered them reliable indicators for this domain, or for malicious activity in general; hence they have not been listed.
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:
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:
emanielepolikutuo1[.]
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.
Conclusion
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.
Two weeks ago, a blog post was shared by Martijn Grooten regarding the IcedID malware, in which he published hundreds of domains and IP addresses that were part of IcedID’s command and control infrastructure. Though many of these had been published before, many others had not been publicly linked to the malware.
IcedID has become a crucial component in many cybercrime supply-chains, and it is thus on the radar of many security researchers. Several analyses of IcedID have been published since including ones by Awake and Uptycs as well as twoposts on Brad Duncan’s Malware Traffic Analysis blog.
Most of the command and control indicators listed in these posts were already in our list of indicators, which shows once again how one doesn’t always need to analyse active network activity to detect such infrastructure. Because IcedID is still very much active and continues to register new command and control domains, Martijn used the method described in the previous blog post to find many more indicators.
These new indicators have been added to this Github account, which now contains 366 unique domains, 69 unique IP addresses and 495 combinations thereof.
Thank you to John Jensen who contributed to this research.
Domains created for malicious purposes are rarely registered on their own. When you have identified such a domain, it is therefore always a good idea to look for other domains used in the same campaign.
Sometimes finding such a domain is easy. For example, you may notice a very similar domain (such as the .net version of a .com domain) registered with the same registrar on the same day. At other times you will need to look for other evidence, for example find them hosted on the same IP address.
In general, however, linking two domains through a single IP address isn’t strong enough evidence that the domains themselves are linked. The link becomes a lot stronger though when two or more domains were seen moving through the same set of IP addresses simultaneously.
In previous blog posts, this was used to find five domains that used the same infrastructure and that were made to look like they belonged to a content delivery network, as well as the infrastructure of a LodaRAT campaign targeting Bangladesh.
In this blog post, a few more examples showing sets of malicious domains that moved simultaneously through the same set of IP addresses will be examined. The sets of domains are linked and there is some evidence to suggest that the infrastructure belongs to a bulletproof hosting service.
Magecart
The first set of domains spoofs well known services such as Cloudflare, Google, jQuery and Magento:
These domains were all registered at Russian registrar REG.RU on the 3rd of November 2020 and have simultaneously moved through the same set of IP addresses. The all use the name servers of DNSPod, a Chinese DNS hosting provider that has long been popular with cyber criminals.
For the first three months of 2021, the domains were seen on the following twenty IP addresses, in this order:
Sometimes, the domains only pointed to an IP address for less than a day, but in one case they pointed to the same IP address for three weeks in a row.
The IP addresses belong to various hosting services, with a particular preference for Google’s.
Interestingly, around the 8th of March, nine more domains joined the cycle:
They have been pointing to the same IP address as the original set ever since.
There is public evidence linking these domains to Magecart. Magecart is an umbrella term use to refer to more than a dozen groups that insert code into websites’ payment pages that steals credit card data. A common trick used by Magecart groups is to make their domains look like those from which code is regularly included into web pages. A website owner looking at the source code on a webpage may thus incorrectly assume the inclusion of third-party JavaScript is harmless.
Note: because the domains sometimes pointed to an IP address for a very short time period, it is possible that the list of IP addresses above isn’t complete for the three-month period January 1st to March 31st 2021. The same applies to the examples below.
IcedID and Qakbot
A second set of domains also cycled through a set of IP addresses, again all pointing to the same IP address at the same point in time.
The domains were registered between late February and mid March 2021, mostly through Dutch registrar Hosting Concepts with a few using REG.RU instead. The name servers used were again those of DNSPod, while the IP addresses belong to Google and Alibaba.
Interestingly two of the IP addresses (marked in bold above) were also used by the Magecart domains above, suggesting a possible link between the two sets.
Many of the above domains have been used to download either the IcedID or the Qakbot malware. Both IcedID and Qakbot (also known as Qbot) are commonly used as initial access brokers. Though no direct link between these two actors is known, recently URLs of the type that previously served Qakbot started to serve IcedID instead.
This suggests that it is another actor that handles the spam campaigns that delivers either malware, an example of the increased commoditization of cybercrime. This would also explain why the domains listed above are different from the IcedID command and control domains written about recently, which use a different hosting infrastructure.
Ursnif and phishing
A third set of domains also cycled through a set of IP addresses:
All these domains were registered through Eranet, a registrar based in Hong Kong, and again used DNSPod’s nameservers. Two of the IP addresses, marked in bold, were also used by the Magecart domains, suggesting a possible link.
Interestingly, there are two kinds of domains in the list. One the one hand, there are random looking domains which, as with the IcedID/Qakbot domains above, could suggest a domain generation algorithm (DGA). On the other hand, domains like docusign-cloud[.]com and upsdocstorage[.]com of which one can be all but certain they have been used in phishing campaigns: both DocuSign and UPS are commonly used in phishing lures.
It is not surprising therefore that these latter domains were taken down, often within a week after becoming active: lookalike domains are actively hunted by the affected organisations.
As for the DGA-like domains, one of them, uidacrtsppxece[.]com, has been linked to Ursnif, another common malware delivered in email campaigns.
It is unclear whether there is a direct link between Ursnif and the phishing domains beyond the use of the same infrastructure, or even whether all DGA-like domains have served Ursnif.
Other domains
There are many other domains that have used the same infrastructure, including the use of the DNSPod DNS provider.
will no doubt have been used to impersonate KBC, an Irish bank, while authorise-eebilling[.]com has likely targeted customers of UK mobile provider EE. There are also several more domains that suggest a DGA.
Conclusion: a bulletproof hosting provider?
The similarities among the various sets described above, such as the use of DNSPod and the sharing of IP addresses, suggests the campaigns described all use the same infrastructure, likely that of a bulletproof hosting service.
A bulletproof hoster serves a similar function as a content-delivery network (CDN) does for legitimate domains: making it harder for a denial-of-service attack. The “attack” in this case would come from law enforcement and security researchers.
In the past, bulletproof hosters ran their own networks, which often led to the whole ASN being blocklisted. More modern bulletproof hosters rent servers at cloud providers and set these up as proxies for their customers’ content. By rotating through a set of IP addresses, the content is less vulnerable to being blocked based on the IP address.
Intel471 recently wrote about bulletproof hosters and in particular mentioned DNSPod.
Of course, we cannot be 100% certain that this is a bulletproof hoster, or even that the various campaigns do use the same infrastructure: the sharing of IP addresses may be a coincidence, or because there is another party involved in renting the servers.
But this is yet another example that shows how understanding the context of a domain name can help one find a lot of related infrastructure that is worth blocking, even without having seen evidence of actual malicious activity.
Your security team likely uses many threat intelligence feeds to detect and block threats on your network. But which of these are the best? And what does ‘best’ even mean in this case?
Silent Push helps you answer these questions.
In this blog post, we use a number of open source feeds to show two indicators of feeds that we use to determine the quality of feeds: originator percentage and overlap percentage. Contact us directly if you are interested in having your paid feeds evaluated for their quality — and possibly saving you quite a bit of money.
Originator
Originator %
In the first chart, we look at the originator percentage: the percentage of data in each feed for which it was the first to report it. Many indicators are only active for a short period of time, so the earlier they are included in a feed, the better.
Originator and Overlap
In the second chart, we have added the overlap percentage: what percentage of the data in a feed also appears in other feeds. Low overlap makes a feed very valuable, as it provides data no other feed provides, but the reverse isn’t automatically true: a feed may have a high overlap score, but still be very valuable because it is often the first to report observables. This is why we weigh the originator score more heavily than the overlap score.
If you have open source feeds you want us to add to the report please contact us. We will expand on this report each month.
If you want to evaluate your intelligence feeds please contact us to set up a trial. You can ingest your feed to the platform and receive statistics for the contents quickly with many more factors included than what is listed above.