Unwanted Guests

Uh, four minutes late. We're doing pretty good. Okay. Hope you all grabbed a coffee, stretched your legs, maybe reminded your phone not to connect to random Wi-Fi. Now that we're recharged, it's time to dive into our next eagerly awaited session.

Our speaker is the brilliant David Brun, a renowned threat researcher from Infoblocks. David is a master of threat intelligence and DNS, the infamous glue that holds the internet together. Or if you're on Reddit, it's always DNS's fault. Probably the reason most of us can still check our email Monday mornings.

In his talk, Unwanted Guests, David will reveal how crafty attackers exploit compromised or poorly configured infrastructure, from hijacked domains to everyday gadgets turned malware hosts, to pull off their digital heists. If you've ever wondered what mischief happens under the surface when things go wrong, David's got the stories and strategies you need. So, please join me, postcaffeinated and full of curiosity, and welcome David to the stage.

Folks, thanks for joining me today. My pleasure to be here to talk about unwanted guests. This is a presentation on understanding the ecosystem of exploited infrastructure. My name again is David Brunston. I'm a threat researcher at InfoBlocks, and I research in DNS, hunting threat actors all day every day.

Today, we're going to talk about several different things, but I want to first start with a brief summary of some of the threats that we're seeing. And then we're going to move into some domain hijacking, specifically talking about dangling records and an attack called sitting ducks. We're going to talk about a botnet that we've been monitoring, and that botnet is known as REM proxy on Russian cyber crime forms. And then that is going to lead us directly into the compromised websites that are being abused for Stella stealer malware distribution. That involves two threat actors working together: one that we've just recently identified in research that we released on Tuesday, known as Decoy Dog, and the IBM designated Hive 0145.

And I just want to say that this research is done by myself but also members of the Infoblock threatened health team, as well as researchers that we've collaborated with, such as GoDaddy Security, Lumen's Black Lotus Labs, and IBM X-Force. And at the end there will be a QR code that you can scan, and that'll go to a GitHub that has links to all the research involved with this presentation.

So right off the start, infostealers are kind of the current hotness, and they've been the current hotness for a while with regards to malware infections. There's lots of different ones out there, lots of different flavors. The one we'll be talking about mostly is Stella Stealer. That's a really narrow one. Mostly it targets the passwords in Microsoft Outlook and Thunderbird. We also track other info stealers as well. Lumis Stealer is a really popular one right now. That one's much more broad, getting all sorts of passwords, files in user folders, cookies, and so forth.

Infostealers have a big ecosystem right now. They're collected in logs, but then they're aggregated and sold. So buyers of info stealer logs will be buying specific things, like, for example, EC2 login or Netflix login, or passwords to WordPress sites, which is something that we'll be getting to later. And then info stealers, of course, are self-perpetuating. They lead to more compromise, such as ransomware.

The other threat that I want to make sure people understand a lot about is what's known as traffic distribution systems, or TDS. They're not necessarily bad. They can be used ethically, and I'm sure that that's how they were originally designed. Traffic distribution systems are a component of adtech, and the purpose of them is for profiling your traffic and redirecting you to the most relevant location. So what happens is they're a component of adtech where publishers will bid on your particular piece of traffic.

One example could be: let's say you've got an Android app and you want to target advertisements to just users of Android. You don't want to spend money advertising to iOS users, for example. That would be a great example of a legitimate use of a traffic distribution system. Another feature of them is they filter out bot traffic, which has no value to advertisers. This is the only slide where I refer to traffic distribution systems in a non-malicious way. This legitimate use is certainly not on my radar. I'm interested in traffic distributions used in a malicious way.

So, malicious traffic distribution systems often appear as legitimate or pose as legitimate advertising networks. And instead of profiling buyers, they're looking for victims. So the infrastructure uses two primary techniques. It is a combination of redirections and cloaking. When you go through a traffic distribution system, it can be a very jarring experience because of the cloak nature of it. You don't really know where you're going to end up.

Up at the top, affiliates operate as traffic sources. So, traffic sources for a malicious traffic distribution system could be push notifications, which of course we never accept, or hacked websites, or advertising space on questionable websites like pirating sites and so forth. At the other side of it, at the bottom, we've got affiliates who purchase traffic for their malicious landing pages. And then additionally, the TDS will send undesirable traffic to decoy pages or legitimate sites.

There's a variety of threats that a malicious traffic distribution system can lead you to. In a sense, they've become a threat distribution system. I won't be going over all of them, but for an enterprise, certainly a concern would be info stealers. Meanwhile, on the consumer end, we see a lot of fake antivirus, or even legitimate antivirus, where a push notification might just start hammering your phone and saying, "Hey, you might have a virus." Or, "Hey, you do have a virus." And then they just send you to McAfee, where you purchase it and they get a commission.

All right, let's begin with some domain hijacking examples. So, domain hijacking, in a sense, is quite simple. It's stealing another person's domain, and there's several techniques available. A real simple example is if you can get access to somebody's registrar or DNS settings, then you can redirect those settings to your own malicious infrastructure.

A more harder to detect method would involve something called domain shadowing. And domain shadowing would be: instead of compromising the entire domain, you would either create or take over an existing subdomain for that domain. And that's really useful if you want to launch an attack on your organization. So I take your subdomain and I create a phishing email. And that phishing email appears to have a legitimate link in it because it's got your own domain in it, but it's got an attacker-controlled subdomain. And so that email could come from a fake IT department that says, "Hey, please go install this Chrome update." And in fact, they've been misled through a hijacked subdomain.

Dangling records is another opportunity for compromise. When you look at DNS, it's really a system of records that point to resources. And so if you have records that point to resources that are non-existent, that's called a dangling record. And in that kind of situation where a record is pointing to, for

For example, an IP address that's not there, a mail server that's not there, a CNAME that's not there — an attacker has an opportunity to put something in that location, and then suddenly your DNS record is pointing at their resource. So earlier this year, if you had searched for websites under the CDC, you would have found a variety of adult content as well as some sports stuff. And so I put an image of the sports stuff there. This was an example of a CNAME, a dangling CNAME. In this case, these CNAMEs were pointing at cloud resources. So the threat actor was able to identify a bunch of cloud resources at the CDC as well as other organizations like Panasonic, Bose, and Rockwell Automation, and they found that these cloud resources were dangling. So they put cloud resources at the cloud providers, created accounts there, created resources at the same address, and suddenly they were able to redirect that content into traffic distribution systems, which lead to a variety of threats. So that forms a traffic source for these traffic distribution systems, which allows them to monetize hijack domains.

Another type of domain hijacking comes from sitting ducks attacks. A sitting ducks attack is a type of attack that takes advantage of information where the name server in the registrar is pointing at an external DNS server, and that server is no longer configured. In order to pull off a sitting ducks attack, there are a couple stars that need to be aligned. You can't do this with every domain. You need to have a lame delegation on the domain and an exploitable DNS provider. So what's a lame delegation? That's a situation where the DNS server is designated as authoritative for a domain but does not have the proper information to answer queries for that domain.

Let's go through an example now. A company registers brand.net and brand.com, and the company points the name server records of those domains to a DNS provider, an external DNS provider. The company configures brand.com at the DNS provider, but they don't configure brand.net. Because of this, brand.net is considered a lame delegation. It's pointing to DNS records at an external DNS provider that aren't there. This kind of mistake is pretty easy to do. I understand a lot of organizations have trouble even keeping track of how many domains they own. So there's a lot of opportunity for this out there.

So let's go over those steps again. The hardest thing for me to learn about this type of attack was how easy it was to accomplish. So what you have to do, or what the attacker does, is they look for these vulnerable domains that have been designated as lame. Then they go to the DNS provider and they create accounts at that DNS provider, and they add that vulnerable domain to their account. From there, they just have to add resource records so that those domains now point to malicious IPs, and the victims get routed to malicious services.

This is an example of it in the wild. So up at the top, we have a domain that was parked at Digital Ocean. Then it had likely something happened where the owner of the domain lost their account or closed their account at the DNS provider, but they didn't update their records. And then you can see that the IP address was changed to a 193 address, which is located in Russia, and that IP address held there for a couple months, at which point the threat actor we designated as Vacant Viper returned that domain and returned it back to a lame delegation. And then a second threat actor came along, known as VexTrio, and they did the same thing. They took that record and they used it for their own purposes, and they returned it. So we call this the lending library technique, where you take a book, you read the book, and you return it back to the library, except they're using it with your domains.

This report was reported on previously. What we did was we demonstrated that this effect in fact was going on at scale, and that's what our reporting brought to this. It's true that most of this activity has a Russian nexus, and that's because it's been reported on previously in Russia quite extensively, and it's been not reported on here as much so far. First of all, I should say you can't do this with every DNS provider. We've identified some specific DNS providers that you can use to perform sitting ducks attacks on. Digital Ocean was one example that we gave before, and so far we've identified over 35,000 domains that have been hijacked using this technique.

Another example of a threat actor that uses this specific technique is an actor that uses sitting ducks attacks to take domains, and then they run ads on Facebook with those hijacked domains. And those ads on Facebook — you're going to see a pattern here — they redirect people into traffic distribution systems to monetize that traffic, and simultaneously people are redirected to threats. This threat actor uses a couple DNS providers that we've identified: Linode, TRNet, and A2 Hosting.

So what can you do as a domain owner? Well, there's one thing you can do, and then there's a couple things that other people can do, like the registrar and so forth. As a domain owner, you should make sure that you don't have any lame delegations, and if you do, you should direct those DNS settings to a dummy address or a placeholder address or something under your control, so that it's not pointing at the DNS provider that you no longer have an account at. Alternatively, some DNS providers are simply naturally better at resisting this type of attack. Cloudflare, as an example: when it provides you name servers, it gives you two name servers. You don't get to pick them. There's two people's names, and this has a natural hardening against this type of attack. Alternatively, a registrar could look for lame delegations and automatically modify those name server records to placeholders instead.

Now let's move on to compromised infrastructure. I mentioned before there's a botnet that we've been tracking known as REM Proxy, and in general, botnets can be a real pain in the neck for defenders. There's reasons why they're so popular. What we've seen in general is that they're used as a proxy network to enable all sorts of cyber crime. This in turn allows them to hide their activity behind routers that are installed in home offices or offices or homes. It allows DDoS attacks, password brute force type attacks like credential stuffing, malspam — which is how we've been tracking this botnet — and click fraud.

So our investigation into this began with a single email, and from that single email, we identified over 60,000 similar emails. And what was really weird was that all of these emails, when we looked at the SMTP address of the sender of these emails, they came from over 13,000 different IP addresses. Going on to places like Shodan and stuff, we investigated what's going on here, and we found a consistent theme that these were all MikroTik routers that were the SMTP servers for all of these emails. If the

Threats were coming from behind the routers, we would have seen a variety of different routers. There would have been Netgear, TPLink, ASUS routers, and we just did not see that. And then also adding to this confusion was the fact that these domains were being sent by approximately 20,000 different domains. So a huge variety of domains including the world's largest beverage company were involved with this. And we identified that a trend in these domains was a simple misconfiguration in DNS that allowed these domains to be spoofed.

So to understand this simple misconfiguration, you're going to have to understand what SPF is, or Sender Policy Framework. So what is SPF? Well, if an email is received, we better check and see if that email has been spoofed. The mail server at that time will make a DNS request for the text records of the purported mail server. And if configured, this will contain the domain's SPF records. And those SPF records indicate what servers can mail on behalf of that domain and how to handle emails that come from elsewhere.

So, what went wrong? Well, we identified a simple typo in all 20,000 of those domains that instructed mail servers to allow all SMTP servers to mail on behalf of the domain. So, a good SPF record is right there, right? It says include example.com, and then in that case, it's a soft deny all. So, soft deny everybody other than example.com. All of these domains had it wrong: include example.com and everyone else. Here's an example of a sample of the domains. You can see in each row they each include — they're written a little differently, but in each row you'll see that plus all consistently down the row.

This is an example of what that email was that we got 60,000 of sent out. Real simple email. We've probably seen it all before. This spoofing, or pretending to be DHL, it contained a simple JavaScript file that in turn decoded a PowerShell script that ran a reverse shell connection to the C2 server. This particular IP address exists in what I would call a disreputable part of the internet. If you are into cyber threat at all, you're probably sick of hearing about Stark Industry. I know I am. This ASN is downstream of Stark Industries, meaning that to get to the greater internet, we have to go through Stark Industries. And today though, of course, Stark Industries got in a little trouble. So now they've been rolled into Perfect Quality Hosting.

It's also worth mentioning that MikroTik routers have been identified previously in DDoS attacks on Ukraine. There's no need to claim that there's a zero day involved with this particular attack. There's plenty of reasons to, or ways to, justify it without it. MikroTik routers have historically shipped with a default admin and blank password. And there's buffer overflow attacks and exploits available online that can be downloaded. So, not necessary to assume a zero day is involved here. And so if your router's compromised, it's now a product that's available for purchase on Russian cyber crime forums. And this was reported on by Lumen's Black Lotus Labs, who explains the malware that's been used in these routers. I found it really interesting that what they noticed was the most notable use of this botnet was brute forcing WordPress sites, which comes into play later.

So we keep monitoring this botnet. We keep looking for that signature I've been talking about being sent by IPs that we've identified using this SPF misconfiguration. And in tracking this, we noticed over the summer, starting in June, a campaign involving the sending of SVG files out. SVG files are Scalable Vector Graphics. They're a vector graphic, or a graphic file that has JavaScript in it, which sounds bad. And while researching this, IBM X-Force came out with a great analysis of the malware that's involved here. So essentially this is a Strela Stealer malware campaign, an info stealer campaign. And it has two malware pieces involved with it. There's a downloader that they designated as Starfish. And so the malware infection from the email leads to Starfish, and when you're infected by Starfish, that reaches out to their C2 server which does a couple checks and then infects you with Strela Stealer.

This campaign was easy to identify because it calls out to a variety of different domains and it's distinguished by this u=script parameter. Once you open that attachment, you then begin the next stage of the malware infection where you begin to download the Starfish downloader, and that's indicated as well by this seemingly random domain and then the u=file parameter. And this takes us into the compromised websites where we were able to identify many, many websites involved with this campaign. One open source way you could look into this is using URLScan and searching for this u=script parameter.

And this takes us to our new threat actor which we recently designated as Detour Dog. And Detour Dog is responsible for orchestrating this campaign for Hive0145 behind the scenes. So the malware itself points to a series of compromised domains, and those domains are not actually where the malware is stored. And this is all a bit of a three-card Monty game orchestrated by Detour Dog. There's two things going on here. There's a malware campaign leading to Strela Stealer, and separately these websites are compromised so that when you visit them there's a chance you will be redirected into a traffic distribution system. We've identified over 30,000 domains, entirely WordPress sites, that have been compromised by Detour Dog. And most visitors, including the site owners, are not going to notice anything when they visit the site.

Here's how it works. The victim's going to make a GET request to one of these compromised domains, and behind the scenes that compromised website — this is the compromise — is going to make a server-side DNS text record request to a Detour Dog authoritative DNS server. And it's formatted in a very particular way. It's got the domain that you're visiting, the IP address of the visitor, a random number, an identifier related to the device that's being used. NA in this example, we think means Android. There's NI, we think that means iPhone or iOS. There's NW, we think that means Windows. And then the domain that's controlled by Detour Dog.

So every site visit initiates this request for C2 from the Detour Dog controlled DNS server, and Detour Dog is going to respond in one of three ways to that request. 90% of the time, based on the data that we've analyzed, that response says don't do anything. That means the site loads normally. Okay. So Detour Dog is going to respond with an ERR encoded in base64. That instruction in the compromise means the site does nothing.

However, occasionally the response is formatted as a URL, and the compromised website is going to perform a redirect, a 302 redirect, to that domain. That's the entrance into the traffic distribution system. And then third and rarest is the response will begin with the expression down. This is related to the u=script or u=file parameter seen in malware. So when malware accesses the system, instead Detour Dog is going to respond something like down, http://update-msdns-server.com/script.php, and what happens is the compromised website is going to strip the word down. It's going to use curl on the remaining string, and it's going to

Pass the output to the malware. This is an example of the flow that takes us through to the compromised — from the compromised site to the funnel that operates, or that is controlled by Detour Dog, that acts as a gateway into the traffic distribution system. From there, they hit something called Help TDS, which is an unknown actor that loves tech support scams. And if you don't get a tech support scam, then you're going to act as a traffic source for an additional TDS, which could lead to other badness.

Let's see what happens when Help TDS picks you up. This is what happens: a full screen priming of the victim. So immediately this pops up and the victim essentially forgets what they were doing and starts cursing their operating system. It doesn't matter what they click. They're probably not going to click restart, they're probably going to click close, but either way they're thinking about something else right now. This is when the tech support scam begins.

So, you've got Peta, you've got Emotet, and you've got a solution. You can call that number right there. Do not call that number. They're going to try and get remote desktop into your system. I'm going to guess they're going to try and install an info stealer on your computer. They're going to open up Event Viewer. They're going to point at whatever red X they can and tell you you've got serious problems. And they're going to rope you into some kind of payment scam. And this just shows that this domain is a part of Help TDS, and all of this content is stored directly on Help TDS. This directly implicates the operators of Help TDS as perpetuating the tech support scams.

Skip that one. I wanted to focus on this one right here. I told you about — there's two threats. We talked about the direction to TDS. This is the orchestration behind the scenes done by Detour Dog with regards to the Stella Stealer malware campaign. So on the very left we have the victim. On the far right we've got the Stella C2 server. We've got two compromised sites in blue. And in the middle is Detour Dog's DNS server, which is controlling the compromised sites. So the yellow Stella C2 server, that's going to be controlling the victim's PC. That's the C2 server. But we've got two C2 servers here. Detour Dog is controlling the compromised sites.

So the victim opens an SVG file. It calls out to the infected domain using the u=script parameter. Compromised site number one makes a DNS TXT record request to the C2 server via DNS. This includes a type identifier, and Detour Dog responds with a "down http update msdnserver.com script.php". So what does the compromised site do? It goes to the Strella C2 server. It downloads the malware stage. So the compromised site goes and fetches the malware stage and it relays it back to the victim. This hides the activity and it makes it look like the compromised site is the one that's providing the malware.

At this point, the victim receives a download button and they click that download button, and that initiates the second call out. This time using the u=file parameter, and that goes to the second compromised domain, and this procedure repeats itself. The second compromised domain sends a similar DNS TXT record to the Detour Dog C2 server in the middle there. It again responds with one of those down commands, this time pointing to the file.php endpoint in the Strella C2 server. And again, the compromised site strips the prefix, initiates another curl request to the Strella C2 server, and this time receiving a file in their response, and they pass the payload to the victim. It's a WScript Trojan, and that's the Starfish downloader.

And here we are at the final stage. The domain we've been talking about, update MSDN server — it's a Microsoft lookalike, of course. What Starfish does: it initiates a GET request to that server, provides a little bit of details in there — computer name, timestamp, and a UUID. The Starfish server makes that request. The C2 server responds with an okay, and then it installs some persistence in the form of a registry key. It adds Starfish to launch on startup. The second thing that needs to happen at this point is a screen capture needs to occur, otherwise it goes no further. And then the final stage is that Strella Stealer is deployed and the credentials are exfiltrated to that server, to the up.to.php endpoint.

And the big thing here is that researchers are led to believe that the malware was hosted on those compromised sites. And so all of those compromised sites appear in, for example, VirusTotal. You look at VirusTotal — it's pointing to the compromised sites, not the Stella Stealer C2 server.

So I wanted to leave you with a few takeaways. Please harden your infrastructure. We don't need to presume zero days are the reason why these things are happening. Microtik in particular has historically not shipped with secure-by-default features. And WordPress sites are not inherently bad — they're just really popular. And recognize that auditing your DNS records is important. Misconfigured SPF records can expose your domain to spoofing, and dangling records will lead to compromise. So make sure you do routine audits and ensure everything is resilient and trustworthy. And understand DNS, because this protocol is foundational to both offense and defense in cybersecurity. Thank you very much.