We all have thoughts that keep us up at night.
Will the ticking noise the car made end up being an expensive repair? When will YouTube superstar John Hammond respond to my posted fanfiction? And are there user agents in Microsoft 365’s security telemetry that we can use to detect potential business email compromise (BEC)?
It’s the latter one that kept me up at 3am, recently.
If the curl command leaves a unique and obvious user agent behind, are there other (malicious) tools that leave a unique user agent, in a Microsoft 365 context, that are indicative of malevolence?
We’ve shared some Microsoft 365 investigations before, and in this blog, we’ll explore how we took a business email compromise (BEC) threat hunting hypothesis through the empirical endeavor and produced not just detections but also identified and reported malicious behavior to our community members. This article walks through a real-world BEC threat hunting exercise using user agent analysis as detection technology to identify compromised accounts in Microsoft 365
User agents as detection technology for BEC
User agents can serve as a valuable detection technology when analyzing authentication telemetry for signs of BEC. In the Microsoft 365 world, user agents in and of themselves aren’t malicious. A user agent is a string your device gives to a website when you traverse the internet and is designed to share some information about you and your device, which allows the website to tailor the format of the content to best serve you.
There are command-line tools—like Python and Curl—that will leverage a user agent that states it is a command-line tool and its version number (for example, curl/7.54.1). Now, it’s trivial to change the default user agent in both of these tools to masquerade as a different user agent, but as someone who observes adversaries deploy tools like Impacket without changing the default coded-in directories, I can attest to the fact that adversaries often do not deviate from the default of their offensive tools.
Thus, our hypothesis was conjured: could we identify business email compromise by honing in on anomalous user agents?
On the hunt: How to detect BEC in Office 365
Knowing how to detect BEC in Office 365 starts with understanding what normal authentication looks like—and what doesn't. Installed across more than 2 million endpoints, and monitoring 50,000+ email accounts across 1,500 small businesses, the Huntress SOC squad is spoiled for choice when it comes to telemetry. Quite literally, think of what you want to find and diving into our data lake you will find it. And similar to the archer, to ultimately propel our weapons forward to engage our adversarial target, we must first draw backward and prepare ourselves; what are we trying to accomplish here?
We’ve already established that user agents are easy to change. Furthermore, detecting on user agents alone is a fool's errand due to false positives or true negatives. Even the most prized Microsoft 365/Azure Offensive Security suite of tools, AADInternals, does not leave behind unique user agents and facilitates the minor effort to change the user agent.
What we’re looking for across Huntress’ Microsoft 365 telemetry are successful logins from less common user agents, as a contextual indicator that something malevolent is afoot. Through anomaly analysis, we filter out the common user agents, and analyze the rarer user agents until we’re left with a rather interesting user agent:
AZURECLI/2.47.0 (DEB) azsdk-python-azure-mgmt-resource/22.0.0 Python/3.10.10 (Linux-5.4.0-137-generic-x86_64-with-glibc2.31)
In our Huntress telemetry, we filter for this with the following search: user_agent.original.text: "Azsdk", and we identify some rather interesting territories associated with this user agent.
I, too, legitimately authenticate into my email account via the command line when I am vacationing in Russia or China…
Digging deeper into BEC threat hunting
From there, we dug deeper into what tool this user agent came from (no points for guessing a Python package). The user agent comes from the Microsoft-blessed Python library here and has been associated with malicious activity reported by Alice Klimovitsky in May 2023.
The user-agent/Python library is not malicious itself. Rather, the presence of this specific user agent in Microsoft 365 telemetry warrants further investigation. You won’t be surprised, then, that the rest of the investigation was focused on determining exactly how anomalous and malicious was a successful authentication with the user-agent: AZURECLI/2.47.0 (DEB) azsdk-python-azure-mgmt-resource (spoilers: quite anomalous, quite malicious).
Reviewing our telemetry, we had 85 hits for this overall user agent, with the majority being login fails and only four successful logins with the suspicious user agent.
Filtering out the login fails, we’re left with four successful authentications for four user accounts, in all of June 2023. Sounds pretty sus to me tbh…
User Baselining
To investigate this behavior, we can correlate the user’s authentication pattern: how often have they signed in from this territory in the world, how common is it they authenticate with rare user agents, maybe they’re a developer testing some stuff? Saving both you and me the time, evidence attested all four were malicious authentications and all four warranted critical reports to our Huntress community members.
For example, take our "Sales" friend, who consistently authenticated from Belgium only to then anomalously authenticate with the Azsdk-python user agent from Korea.
Or our dear friend "Po" whose Azsdk-python authentication was associated with an Indonesian public IPv4 with a penchant for attempting to sign in as a myriad of accounts.
This also demonstrates the benefit of collecting and storing raw traversable telemetry. Once we identified that these particular IPv4 are malicious, we can then pivot and start to look at what else they have been up to, and if they have had successful authentications elsewhere, and all because we have held onto the telemetry.
Reporting Business Email Compromise in Microsoft 365
From this one hypothesis-driven threat hunt, we issued a number of true positive reports advising our community members of business email compromise, and a suite of remediation strategies to evict the adversary, restore trust to the account, and prevent future compromise.
And the community rewards our investigation with engagement. Below, we have included a testimonial from the recipient of one of the above reports, which demonstrates that Huntress MDR for Microsoft 365 pays security dividends when driven and contextualized by the handsome experts of the Huntress SOC.
Detection Technology Augmented by Humans
The BEC threat hunting cycle should close the loop between manual findings and automated detection technology, turning what analysts discover into scalable detections.
Below is what we have so far put forward internally as a detection, but this will go on to be curated and shaped by the experts in Huntress’ dedicated detection engineering team—such as Matt Anderson, Matthew Brennan, Kris Luzadre, and Greg Ake.
event.action: UserLoggedIn AND user_agent.original.text:"azsdk-python"
# Filter for successful authentications only
# And essentially wildcard for any user agent containing the above string
With the detection conjured, Huntress’ resident ninja Sharon Martin pushed it to production and it immediately fired on the activity we manually identified—that right there is what we call a success. 🙂
I leave it to the reader to decide the priority for this detection. Environments vary in what their baseline is for normal, and far be it for me to tell you whether this should be a high- or low-priority detection.
Remember, this activity alone is not the signal to throw a code red. Rather, as we said, this is a detector that instigates further investigation; it is not the sign of something overtly malicious, but it is the sign of something amiss and anomalous, where we would advise filtering down into the user’s historical baselines and seeing if this fits in with their wider authentication pattern. And, to reiterate, user agents are trivial to change—but when it comes to changing a tool’s defaults, Huntress analysts have observed adversaries to just… not do that.
BEC prevention in Microsoft 365
Beyond detection technology, preventing BEC in Microsoft 365 requires strong access controls and identity security. Multi-factor authentication (MFA) and complex conditional access policies are your friends. I know they receive user pushback, I know they are a pain to administer but, between you and I, business email compromise isn’t going anywhere; the threat looms large and grows every day. Moreover, another secret between the two of us: if you neutralize a threat at your email perimeter, you’ll likely deny the adversary at the earliest stages of their campaign to infiltrate your network; this saves you money, time, and pain in the long run.
Through the cloud, it has never been easy to self-serve your own security alerting, detection, and response. The cloud can facilitate incredible security visibility into the finer details of your users’ activities (maybe too much visibility, too much noise).
You don’t HAVE to have Huntress’ ThreatOps team in your corner—you can just keep an eye out for blogs like this and STEAL borrow the best bits. But if this blog has emphasized anything, it’s that we have a team of people who love doing this, who do it well, we do it quick, and we make life easier for you and harder for cybercriminals. We’re constantly innovating and ambushing adversaries’ where they try to hide, and worryingly, we all find this incredibly fun.
See how Huntress detects and stops BEC attacks in Microsoft 365
Continue to part three: Thwarting Financial Fraud: Shutting Down Hackers in Microsoft 365
• • •
IoCs:
- 213.154.80[.]21
- 203.251.62[.]51
- 91.158.221[.]9
- 118.98.90[.]2
ATT&CK TTPs:
- Initial Access, T1078.004, valid cloud accounts
Detection:
- event.action: UserLoggedIn AND user_agent.original.text:"azsdk-python"
