I recently read through an excellent article by Mandiant, which recently split with FireEye, on their findings and analysis of the continued actions of suspected nation-state actor NOBELIUM.  This group appeared on most IT pro’s radar because of their SolarWinds’ software supply chain.  You are probably familiar with it by now, but if not, the tl;dr is that SolarWinds’ Orion IT software was “trojanised” via an attack on their software supply chain.  Orion is (probably now “was”) used by enterprise customers to monitor their servers, network, etc, so not only was SolarWinds compromised, so too potentially were its customers.

Note NOBELIUM is Microsoft’s assigned name for this advanced persistent threat, but other vendors will use different names.

As I scrolled down the report, in the back of my head I’m thinking things like “XYZ in Defender could have stopped that”, or “wouldn’t have happened if they’d ABC’d in Azure AD”.  In this article, I’ll reference Mandiant’s above article, then explain how implementing security capabilities found across the Microsoft 365 E5 license may help mitigate similar threats.  In many cases, you don’t even need E5.  Check out m365maps.com to see exactly where it falls in the licensing picture and if it’s available to you in something like Microsoft 365 E3 or Business Premium.

This is not a third-party vs. Microsoft security blog.  There are pros and cons to all solutions.  This is an attempt to help folks paying for Microsoft 365 E5 get their money’s worth by squeezing as much of its offerings out as possible.  Details are light on some parts of the report, so those will be reviewed at a high level only.  Additionally, there may be simplifications for the sake of brevity.  I am available on Twitter @rucam365 for any clarifications you want.

Compromised CSPs and privileged access

“multiple instances where the threat actor compromised service providers and used the privileged access and credentials belonging to these providers to compromise downstream customers”

“The account held a specific Azure AD role that allowed it to use the Admin on Behalf Of (AOBO) feature. With AOBO, users with a specific role in the CSP tenant have Azure Role Based Access Control (RBAC) Owner access to Azure subscriptions in their customer’s tenants”

“… evidence that the actor compromised multiple accounts and used one for the sole purpose of reconnaissance, while the others were reserved for lateral movement within the organization…”

Defence against compromised CSPs and privileged access with Microsoft 365

CSPs, cloud solution providers, in the context of Microsoft 365, are typically license resellers and if set up as delegated administrators, can have global administrative rights to customers’ tenants.  As pointed out in the article, and I reference in the quotes below, they can be extremely powerful with Azure owner access to subscriptions.  If an Azure VM owner is compromised, and that VM happens to run Active Directory Domain Services, you are trivial steps away from being pwned.  Obviously, you can have other service providers beyond the scope of Microsoft or Microsoft 365, managing other services.

Compromised VPNs

“the threat actor identified and compromised a local VPN account and made use of this VPN account to perform reconnaissance and gain further access to internal resources within the victim CSP’s environment”

Defence against compromised VPNs with Microsoft 365

  • This one is light on specifics, but for your client endpoints, you should be moving away from VPNs entirely by considering the following points.
    • Replace on-premises Active Directory domain join or Hybrid Azure AD join with pure Azure AD join.  In The Case For Azure AD Join, I lay out a manifest of why so many reasons you thought you couldn’t do Azure AD join are not necessarily true.
    • Replace on-premises file servers with SharePoint Online and OneDrive for Business.  I know, I know… ScarePoint, etc, etc.  I get that SPO is not exactly a replacement for file servers, but many (most?) environments can and should make the move.  Why?  Get rid of that dependency on VPN for network drives, speed up file access for users, and get modern improvements such as auto-save and co-authoring.
    • Replace Group Policy and ConfigMgr with Intune MDM.  Again, reduce that dependency on VPNs (or Cloud Management Gateways, etc) and get a bunch of other benefits.  Not suitable in all cases, but the vast majority.  Also not a quick journey: the best practice would be to start from scratch as much as possible.
    • Access on-premises applications securely over the internet without a VPN by using Azure AD Application Proxy.  Your apps will benefit from Single Sign On with Azure AD accounts, and be protected from the wider internet by pre-authentication using Azure AD.  This means you get the benefits of Azure AD such as Conditional Access, DDOS protection, etc, all before any packets touch your app (and even then, only via a connector intermediary replacing your DMZ).
  • For your servers infrastructure, VPN isn’t so easy to kill.  I’m focusing on Microsoft 365 E5 in this article, but of course, Microsoft and the industry, in general, is heading towards PaaS/SaaS which means less infrastructure for you to manage in general.  Don’t misquote me: I’m not saying cloud = security and on-prem/VPN = insecurity.  I’m saying, personally, I’d rather keep my need for managing VPNs to a minimum… or get one that supports Azure AD auth.

Malware and low reputation websites

“… some systems had been infected with CRYPTBOT, an info-stealer malware, shortly before the stolen session token was generated. Mandiant observed that in some cases the user downloaded the malware after browsing to low reputation websites offering free, or “cracked”, software.”

Defence against malware and low reputation websites with Microsoft 365

Malware protection and web controls are seen as basic stuff, but what can Microsoft 365 E5 offer us?

Anonymous IP access

“These tokens were used by the actor via public VPN providers to authenticate to the target’s Microsoft 365 environment.”

“Mandiant witnessed the actor use a mixture of TOR, Virtual Private Servers (VPS) and public Virtual Private Networks (VPN) to access victim environments.”

“Mandiant was then able to identify numerous TOR exit nodes that the threat actor used based on new authentication events.”

Defence against anonymous IP access with Microsoft 365

In the enterprise context, it’s usually safe to block access from things like Tor and known VPN providers.  I understand that a lot of modern security talk wants to move away from caring about locations, IP based controls, etc, but in my opinion, it should still be used as part of defence-in-depth, especially if you can reasonably say your user base will only be connecting from a known list of regions.

  • Conditional Access can be used to block access from IPs located outwith specified countries.  Create a policy that blocks all locations except those in your named list of allowed ones.  You can also choose how to determine the location: by IP (v4 only) or GPS (requires the Microsoft Authenticator app but doesn’t work with passwordless if you’re using that).
  • Azure AD Identity Protection has a real-time detection capability for anonymous IP addresses, which Microsoft explicitly describe as “for example, Tor browser or anonymous VPN“.  Identity Protection policies can be configured standalone or (recommended) included as Conditional Access conditions.
  • There are offline sign-in risk Identity Protection detections (as opposed to real-time) for malicious IP addresses and activity from anonymous IP addresses.  Although these could not prevent a login, they will raise logs for you to audit, with about a 48-hour delay.
  • Microsoft Defender for Cloud Apps has anomaly detection capabilities that can be used to warn you about suspicious behaviour across integrated apps.  You can also use proactive governance to revoke access from services like Tor.

MFA Push Notifications

“… the threat actor had a valid username and password combination. Many MFA providers allow for users to accept a phone app push notification or to receive a phone call and press a key as a second factor. The threat actor took advantage of this and issued multiple MFA requests to the end user’s legitimate device until the user accepted the authentication…”

Defence against falsely approved MFA with Microsoft 365

I’m in the camp of “push notifications are better than no MFA at all”.  But at the same time, if you’re doing something, do it right.  Hammering someone with MFA requests until they submit – yikes.

LSASS and ntds.dit dumps

“On one device, the threat actors made use of the Windows Task Manager to dump the process memory belonging to LSASS…. There was also evidence that the threat actor used Sysinternals ProcDump to dump the process memory of the LSASS process.”

“Mandiant identified multiple attempts by the threat actor to dump the Active Directory database (ntds.dit) using the built-in ntdsutil.exe command.”

Defence against LSASS and ntds.dit dumps with Microsoft 365

Let’s have a look at how Microsoft 365 Defender services can be used in this scenario.

Azure AD Connect compromise

“The threat actor also obtained the Azure AD Connect configuration, the associated AD service account, and the key material used to encrypt the service account credentials.”

Defence against Azure AD Connect compromise with Microsoft 365

Don’t have the full details here but let’s review Azure AD Connect and securing it in general.  Why is AADC important?  It’s what syncs on-prem AD to Azure AD, so is significant for lateral movement.  Lateral movement aside, the connector account also gets a bunch of permissions to the directory and control over users, groups, and passwords.

  • Give the AADC server the same respect in regards to security as a domain controller: treat it as a tier 0/ asset, with controls around only privileged access workstations getting access, what other apps can run (allow listing), outbound network access, etc.
  • You no longer need the Global Admin role to manage Azure AD Connect: use least privilege and stick with Hybrid Identity Administrator.
  • Keep Azure and Azure AD privileged access accounts (admins) as cloud-only accounts and do not synchronise your on-premises administrators (e.g. Domain Admin) to Azure AD.

Active Directory Federation Services (AD FS) attacks

“… the threat actor obtained the Active Directory Federation Services (ADFS) signing certificate and key material. This allowed the threat actor to forge a SAML token which could be used to bypass 2FA and conditional access policies to access Microsoft 365.”

“Mandiant discovered that the threat actor had stolen the AD FS token signing certificate and the DKM key material. This would allow the threat actor to perform Golden SAML attacks and authenticate as any user into federated environments that used AD FS for authentication, such as Microsoft 365.”

Defence against AD FS SAML token forging with Microsoft 365

Generally, when I see AD FS, I run in terror.  Here goes…

Lateral movement and privilege escalation

“The threat actors leveraged compromised privileged accounts and used SMB, remote WMI, remote scheduled tasks registration, and PowerShell… mainly to perform reconnaissance… distribute BEACON around the network…”

“In some cases, the actors passed in a specific Kerberos ticket during the WMIC execution using the /authority:Kerberos flag to authenticate as computer accounts.”

“the threat actor used Azure’s built-in Run Command feature to execute commands on numerous downstream devices. The threat actor used native Windows tools to perform initial reconnaissance, credential theft and deploy Cobalt Strike BEACON to devices via PowerShell.”

“The actor then used this BEACON implant to persistently install CEELOADER as a Scheduled Task that ran on login as SYSTEM on specific systems.”

Defence against lateral movement and privilege escalation with Microsoft 365

Again, we return to Microsoft 365 Defender to review some threat protection capabilities for this.

Unauthorised data access and exfiltration

“The threat actors performed data theft through several PowerShell commands, uploading several sequential archive files ending with the .7z extension. The threat actor uploaded these files to a webserver they presumably controlled.”

“Mandiant identified binaries that were configured to upload data to the Mega cloud storage provider. The threat actor deployed the tool in the %TEMP%\d folder as mt.exe and mtt.exe. “

“Mandiant also observed the threat actor access a victim’s on-premises SharePoint server looking for sensitive technical documentation and credentials. The threat actor then used the gathered credentials to move laterally around the network.”

“From this documentation, the actor was able to identify a route to gain access to their ultimate target’s network.”

Defence against unauthorised data access and exfiltration with Microsoft 365

There are a few ways to approach this.  We need to consider that the upload operations to attacker-controlled servers and Mega.com were probably on servers, which have different Microsoft 365 capabilities than Windows 10 clients.  We also need to consider everything I’m about to list as part of defence-in-depth and no silver bullet.

Unauthorised Exchange mailbox access

“Mandiant witnessed the threat actor use impersonation to access multiple mailboxes belonging to users within the victim organization.”

“The threat actor also created a new account within the Microsoft 365 environment which Mandiant deems was for backup access in the event of detection.”

Defence against unauthorised Exchange mailbox access

If delegating access to mailbox permissions, you should have an established process for this and monitor any delegations that deviate from the process.

Concluding thoughts

There are no silver bullets against sophisticated, dedicated attackers.  Similarly, there are no perfect security solutions or software services.  However, in this article, I’ve tried to explain that if you are a Microsoft 365 customer already, you probably have a lot of tools in your arsenal to mitigate a lot of potential threats or at least generate enough noise that you can start investigating.

 

 

 

 

 

 

Tags: