Explore our library of thought leadership articles and insights.
Podcasts
Stream informative and exclusive episodes of DomainTools “Breaking Badness” podcast.
Research
Read the latest from DomainTools Investigations.
Webinars
Watch live and on-demand cybersecurity training from the DomainTools team.
White Papers
Discover the real-world impact of DomainTools DNS intelligence.
Client Resources
Technical Documentation
Navigate DomainTools features effortlessly with our comprehensive guides.
API Documentation
Access everything you need, including endpoint, response formats, sample queries, and product service levels.
Webinars
Through close partnerships with leading security vendors, DomainTools embeds our best-in-class domain profiles and predictive Risk Score directly within your preferred SIEM, SOAR, and TIP solutions.
Watch Now
Company
About
Meet our exceptional executive team of experts and industry leaders.
Pressroom
Access the latest DomainTools news and press coverage.
Contact
We’re here to help with product info, pricing, and current and future account services.
Microsoft confirmed that two recently disclosed zero-day flaws in Microsoft Exchange are being actively exploited in the wild
It’s early days yet in terms of these two vulnerabilities, so we’re going to have to speak in generalities here a bit
At a high level, a server side request forgery (SSRF) vulnerability is one in which an attacker can get a server to access resources that normally should not be available without privileged access. These vulnerabilities can have various effects; for example, sometimes they are used to gain access to back-end internal systems that the attacker should not be able to get to. In other cases, the access is to parts of the vulnerable web application itself. So right now, we don’t have all the details on how this particular SSRF works against Exchange, but we do know what some of the effects are—more on that in a minute
The second vulnerability is more mysterious than the first. An RCE (remote code execution) vulnerability can take countless forms—really all that term means is that it allows an unprivileged user to run arbitrary code without physical access to the machine. So a lot of vulnerabilities that you hear about are RCE; in this case all that really tells us is that it’s a serious vulnerability
There are a couple of mitigating factors for these. One of them is that the attacker has to be authenticated to the Exchange server. Now, how easy or hard that would be is HIGHLY dependent on many different things. If someone wanted to pull an inside job against their employer or some organization where they had an Exchange account, then they’ve already got that part solved. (Having said that, the instances of these vulns being exploited in the wild do not seem to be insider threats from what we can see). But there are lots of ways to get authenticated, from basic phishing to more sophisticated social engineering methods, or physical access to an unlocked machine
For the RCE one, a sort-of mitigating condition is that it requires PowerShell to be accessible to the attacker. Now as most of our listeners will probably recall, PS is available to…a LOT of attackers. So that’s not necessarily a source of a whole lot of comfort in and of itself
What’s been observed so far in the wild comes from a Vietnamese security outfit called GTSC, and they have seen these vulns chained together to deploy Chinese Chopper web shells for persistence and data theft, as well as to move laterally through the victims’ networks.” Persistence, lateral movement, and data theft are all things you’d expect to see downstream of RCE vulns on popular systems like Exchange
Microsoft said they would accelerate the timeline to fix the issue, but what’s an ideal timeline?
Any time you have an RCE flaw in a widely used system which, by its very nature, has sensitive internal user data on it, the way an Exchange server does, it’s serious, so ASAP would be an appropriate timeline
This show is airing on October 5 and the next patch Tuesday is October 11, so it would be nice if something for these were available in that update. They sometimes do out of cycle updates for extra severe vulns—not sure that they will do that this time, but we’ll see
Who should take action?
The article is specific that Exchange Online customers don’t need to take action, because, at least this is our assumption, Microsoft has taken some measures to secure their own hosted instances—the same measures they are recommending for on-prem Exchange customers
What mitigations is Microsoft suggesting for on-premises Exchange customers?
Over the weekend, they released a Response Center blog with instructions on adding a blocking rule in something called “IIS Manager -> Default Web Site -> URL Rewrite -> Actions” to prevent known attack patterns
They actually have three paths you can go by, but in the long run, there’s still time to choose the road you’re on. Wait. The three paths, yes. If you have Exchange Emergency Mitigation Service enabled, you’re already all set. No need to take further action, because they’ve mitigated it for you. Or, you can deploy a script they developed to create that blocking rule
If you’re really into turning the wrenches yourself, they provide the instructions for going into IIS manager and manually creating the rule. Fundamentally these all do the same thing
Finally, is there any information regarding who is behind these attacks?
Earlier we mentioned Chinese chopper web shells as part of what gets installed post-exploit, and that was a hint
GTSC, the research outfit that reported this issue, suspects that a Chinese threat group might be responsible for the observed attacks based on the web shells’ code page, which has a Microsoft character encoding for simplified Chinese
Also, the actor manages the web shells with the Antsword Chinese open-source website admin tool, as revealed by the user agent used to install them on the exploited Exchange servers. Of course, there’s always the possibility of a false flag. Attribution is hard, and all that
An archive file of Brute Ratel was uploaded to TotalVirus. Now cybercrime groups are expressing interest in the leak of this new tool
We’ve discussed Brute Ratel on the podcast before (in episode 126 if you want to check it out), but for new listeners, we’ll start with a brief overview of what Brute Ratel is
It made its debut way back in December of 2020 and the creator is ex-CrowdStrike/ex-Mandiant - someone with a lot of experience on the Red Team side of things
There’s a lot of features and functionality the Red Team folks like. It handles EDR invasion really well - it’s pretty advanced
It was built for internal purposes for a while, but then released commercially (similar to the Cobalt Strike story)
But the licensing schema can get cracked and then used by just about anyone
It was out in the wild back in July, so that was pretty concerning and as we’ve seen in the past week, the crack has been released
So what is the most recent news regarding this framework?
Since the release in the past two years, it gets continual updates, but over the summer, the Palo Alto team saw that it’s not just being used for educational purposes - it’s being used for malicious purposes
In the last week, the more underground cybercrime forums are talking about it and how the crack has been released - and when we say “crack” we mean that you can bypass the licensing check and use it however you want with no oversight from the makers
Who’s responsible for the leak?
The article mentioned that the Brute Ratel creator is pointing fingers at MdSec - accusing them of uploading the archive file to TotalVirus, but those claims were unfounded, but let’s look at their interpersonal relationship and dissect it from a psychological perspective
It’s tricky - we don’t necessarily want to get in the middle :)
Do we have information on who got the archive file in the first place?
The Palo folks tied it to Russian activity over the summer, so if you’ve seen it there, that could be the first guess
At a certain point, the genesis doesn’t necessarily matter, the genie is out of the bottle regardless
Would we say there’s a “feeding frenzy” among cybercrime groups?
It’s one of those things that can become commoditized for these folks like Cobalt Strike
It’s important to note that this is more post-exploitation tooling, so getting in and getting visibility and avoiding EDR or XDR tooling - this is helpful for that stuff, but it is not an exploit tool or a vulnerability tool
Just to wildly speculate, what sort of damage will be forthcoming with this leak?
This will definitely help bad actors avoid detection in a more effective fashion
There’s been a ton of iteration on it in the last 18 months or so since it’s gone commercial, so they’ll try to put the genie back in the bottle with new licensing schemas and provide detection tooling for the old stuff, perhaps
If it maintains its current trajectory, you’ll see this in bad actors’ toolbelts like Cobalt Strike
And you’ll be hearing more about badgers - lots of badgering going on with Brute Ratel
Two Truths and a Lie
Introducing our newest segment on Breaking Badness. We are going to play a game you are all likely familiar with called two truths and a lie, with a fun twist. Each week, one us with come prepared with three article titles, two of which are real, and one is, you guessed it, A LIE.
You'll have to tune in to find out!
Current Scoreboard
This Week’s Hoodie/Goodie Scale
From Zero To Sixty
[Taylor]: 6.25/10 Hoodies [Tim]: 5/10 Hoodies
It’s A Brute Point
[Taylor]: 6.5/10 Hoodies [Tim]: 6/10 Hoodies
That’s about all we have for this week, you can find us on Twitter @domaintools, all of the articles mentioned in our podcast will always be included on our podcast recap. Catch us Wednesdays at 9 AM Pacific time when we publish our next podcast and blog.
*A special thanks to John Roderick for our incredible podcast music!