A June 2023 threat roundup blog by Cisco’s reliably excellent Talos research team showed that the banking Trojan malware Ramnit was at the top of their list of most prevalent threats for that week. Ramnit’s been around a long time, so this is clearly malware with staying power, and it must be continuing to pay off for its operators, else it would long ago have been consigned to the virtual scrap heap of malware history.
But since it is still a prevalent threat, I thought it might be interesting to look into the infrastructure it’s been using (including some very recently created), to see what else we could learn about it and, ideally, to be able to stay ahead of it.
By way of background, in case you’re not familiar with it, Check Point describes Ramnit this way:
Ramnit is a banking trojan, meaning that it is primarily intended to steal account credentials for online banking. However, like many banking trojans, Ramnit is designed to be highly modular, enabling it to collect additional types of credentials such as those for social media, email, and other accounts or to download and deploy other malware.
Ramnit is often spread via phishing campaigns that may deploy multi-stage malware. Once the target falls for the initial phishing campaign and runs the malware, it downloads and executes additional malware that eventually launches the Ramnit trojan. Ramnit will then attempt to collect banking credentials and may download additional Ramnit modules or other malware to achieve the attacker’s goals.
One of the distinguishing features of the Ramnit malware is the use of both hardcoded domains and a domain generation algorithm (DGA) for command and control. Malware using a DGA generates a sequence of random-looking domains to which it sends command and control traffic. The attacker’s command and control server runs the same DGA and registers these domains, directing the traffic to the attacker-controlled system. By using a DGA, the malware can avoid DNS blocklists because it is constantly using new, unblocked domains for its traffic.
We’ll see shortly how a bit of infrastructure analysis in Iris Investigate demonstrates that set of characteristics in the last paragraph.
If you’ve attended recent DomainTools webinars, you may have heard me discuss three analytical roles of domain infrastructure features. These features can serve as characterizers, connectors, or identifiers (and in many cases are more than one of these things at once). This may seem self-evident, but it’s worth considering as we go through some Ramnit infrastructure to see how it plays out.
Our starting point is the domain zahlung[.]name. For those who aren’t German speakers, “Zahlung” means “payment.” This domain is one of the indicators that has been tied to Ramnit in some IOC lists (though it doesn’t happen to appear in the Talos blog cited earlier). Here’s what the Iris database has to say about it:
The DomainTools Risk Score doesn’t like this domain very much. As an aside, the reason that the three Threat Profile boxes say “N/A” is that this domain is pretty old by malware infrastructure standards. We stop the Threat Profile scores after a domain reaches an age of 30 months, because as a general rule, malicious infrastructure does not remain active that long.
One of the first things we tend to do after looking up a domain in Iris Investigate is to look for useful pivots that might connect that domain to others. We do this because
- Seeing the “company it keeps” can inform us about the nature of the original domain, and
- Because if we’re threatened by a given domain, we should make the effort to protect ourselves against other domains that are under the control of the same actor.
In the Iris Investigate Pivot Engine, we can see a couple of Guided Pivots. These are data points highlighted in blue; the highlight means that they have more than one, but fewer than 500 (by default) domains that share the feature. Such pivots are typically valued by analysts because they can signal correlation in a way that pivots with thousands or millions of shared domains do not. Put differently, the blue highlight means that the feature is a useful connector. For zahlung[.]name, there are guided pivots on the IP address 72[.]26.218.70 and on two fields from the SSL/TLS certificate section—the certificate’s hash, and the subject CN.
As of this writing, that IP address is shared by 140 other domains. But are those domains actually under the control of the same actor as zahlung[.]name, or are they simply all thrown together by a hosting provider? There are a couple of ways to cross-check this.
First, we can look at the domain names. The Pivot Preview in Investigate gives us a look at the domain names sharing this IP address (and their risk scores).
(A partial view of the Pivot Preview for this IP address)
Notice that a lot of the domain names don’t seem to represent actual words. Recall that the Check Point description of Ramnit says that some of their domains are generated by domain generation algorithms (DGAs). While it’s not proof, the high entropy (randomness) of many of the domain names sharing that IP makes them look sketchy. Moreover, the risk scores of 100 mean that these domains have already been “convicted” by well-known blocklist providers. So we’re looking at malicious infrastructure, and there’s a good chance that it’s tied to Ramnit.
But let’s not rely only on the shared hosting. Might there be other ways to solidify our assertion that these domains are related? Indeed…and one such way is by looking at passive DNS, which has the valuable benefit (among many) of showing the subdomains that have been observed with the registered (second-level) domain. Here are some passive DNS entries for zahlung[.]name:
There are some unusual subdomains there. They are not necessarily damning, (or Ramning?) but they are something to note. We tend to see subdomains that would make sense to a human—things such as mail.<domain>.com or cpanel.<domain>.com. These three-character ones are a little less usual. So now, let’s do some spot-checking of some of the other domains tied to the IP address. To keep things as relevant as possible, first we will narrow our search to just domains that are newer—within the last three months.
This narrows us down to 9 domains. Now let’s pick the newest one, which as of this writing is boeyrhmrd[.]com, (first seen on July 15) and check its passive DNS entries.
We can see that this domain also has some odd-looking subdomain patterns. Now that we know that these two domains have unusual subdomain patterns, we can consider those subdomain values as characterizers—they tell us that there’s something a bit different about these domains. If we combine the factors of the shared hosting, the high risk scores, and the unusual subdomain patterns, we can now have fairly high confidence that we are looking at the work of a single actor—at least for boeyrhmrd[.]com and zahlung[,]name. If the stakes were high, we could look at the subdomain structures of more or even all of the other domains on that IP. But for many defenders, this would be enough to make the determination to block the IP, or at least to block the domain names (since they could flux IPs—more on which below).
But do we know that we’ve found all of the relevant Ramnit infrastructure at this point? Not at all. We have a chunk of it, and it’s a bigger number than what’s on many IOC lists for this malware, but it’s not necessarily the whole enchilada.
Returning to the initial view of zahlung[.]name, we had some connecting data in the SSL/TLS arena as well. Let’s see a Pivot Preview of the certificate hash:
Here we can see a mix of sensical and nonsensical domain names, with a variety of risk scores (but overall pretty high). At the bottom of the preview window, we can also see that 18 of these domains are not among the 140 we already have. So we can bring those in too, and now we’re up to 158 domains in total.
Each time we bring in more domains, it’s a good idea to do some spot-checking to see whether the ones that we’ve added look like they are relevant—in this case, whether they look like they share the Ramnit patterns we’ve seen so far. Certainly the DGA-ish domain names look that way. What about some of the domains with names that do seem to be made of real words?
This is an interesting example. We can see a couple of nonsensical subdomains, a couple of standard ones (mail, smtp), and several (apparent) name server subdomains (ns2, ns8, etc.). Not the same pattern of short non-word subdomains, but there is something this domain has in common with several of the others—large numbers of ns* subdomains. This image is only a small portion of the observed records from this domain, and there are dozens of these ns records. This might indicate fast-flux activity. Although I didn’t mention it earlier, the boeyrhmrd[.]com domain similarly shows large numbers of ns* subdomains. The combination of the shared hosting and this set of subdomain patterns is enough that if your correspondent were making recommendations to the firewall team, I’d go ahead and throw all of these 158 domains on the blocklist. We could block the IP address too, but passive DNS shows a variety of IP address A records for these domains, and all those ns subdomains suggest that these don’t hang around on the same IP address for very long.
In fact, in a sense I’ve buried the lede here, in that another look at the Pivot Engine, without even going into passive DNS, would have shown these unusual name server patterns.
The screenshot above is a random chunk of domains out of our set. Notice that in the name server column, each domain has several name servers, and importantly, the domain of the name servers is the same as the registered domain itself. This is not a common pattern, except for large and well-known domains (e.g. Apple uses *.apple.com name servers). For newly-created domains, or domains that aren’t among the largest on the web, this pattern tends to correlate fairly strongly with high risk scores. Name server records of this kind are a characterizer, within the context of looking at potentially malicious infrastructure.
And in this we see an example of how we can use DNS-based OSINT data to stay ahead of, or at least even with, attackers. If we enrich all of the unique domain names seen in the environment with DNS and domain data, we could create scripts for alerting or blocking that work something like “if domain age < n days AND name server domain = registered domain, alert/block.” Some clever scripting in a local DNS resolver could perhaps prevent even the first attempt to connect to such domains from succeeding. Such a script would, of course, have to have an affordance for a set of well-known legit domains that follow that pattern, so as to avoid help desk calls.
Conclusion
No two adversary investigations are the same. You might not ever observe Ramnit-related infrastructure in your environment. But the same principles from this analysis can apply to any domain-based investigation you carry out. Connecting one domain to others that share characteristics allows you to both increase your chances of flagging or blocking the larger campaign that the first domain was tied to, and increase your contextual understanding of the original domain itself. If you don’t have access to Iris Investigate but are curious, hop on over to https://domaintools.com/demo and we’ll be happy to set up a personalized demo for you.
