The perpetrators behind the SolarWinds supplychain attack were observed leveraging four separate, techniques to bypass identity and access management protections and laterally move from victims’ on-premises networks to their cloud-based Microsoft 365 accounts.
Companies that use M365 may therefore wish to heed three key recommendations: harden your hybrid environments, conduct thorough audits of cloud assets, and ensure that any remediation efforts are performed in the correct sequence to prevent the possibility of reinfection.
The findings and recommendations come from a newly released report by researchers at Mandiant, a subsidiary of FireEye, the cybersecurity firm that exposed the SolarWinds attack last month after discovering that its own networks and red-team tools were compromised.
Some of the culprits’ tactics rendered multi-factor authentication moot – a reminder to all organizations that MFA is not a security panacea. Prominent among the four techniques is the “Golden SAML” attack, whereby the bad actors stole Active Directory Federal Services (AD FS) token-signing certificates and then used them to create tokens for authenticating into Microsoft 365 without a password or MFA.
Additionally, the attackers have modified trusted domains in Microsoft Azure AD in order to add a new attacker-controlled federated Identity Provider (IdP) capable of forging tokens – essentially creating an Azure backdoor. In other cases, they have compromised the credentials of high-privileged on-prem accounts synced to Microsoft 365, and they have backdoored M365 apps by adding rogue credentials and exploiting their legitimate assigned permissions.
“These are all sophisticated and effective techniques, allowing the adversary to disable key levels of security controls necessary to identify and stop the attack after a network foothold has been established,” said Deepen Desai, chief information security officer and vice president of security research and operations at Zscaler. But of the four, Golden SAML and the Azure AD backdoor are “particularly dangerous,” he said, because “the attacker can pose as any user in the organization and bypass the primary security controls meant to protect against compromised accounts: passwords and MFA.”
Douglas Bienstock, manager of incident response at Mandiant, agreed with this assessment, telling SC Media that the first two techniques are “good examples of why multi-factor authentication is not a silver bullet… Threat actors know organizations are using multi-factor and so they’re looking for ways around it.”
Making matters worse, some organizations don’t have “defined playbooks” for how to respond to one of these sophisticated cloud attack techniques, added Matthew McWhirt, director at Mandiant. And even if they do have solid playbooks for both on-prem and cloud-based breaches, “when it comes time to combine the two and create that consolidated overview of everything we need to do in both environments, that is sometimes where it gets a little muddy.”
A basic playbook that instructs organizations to simply reset passwords and remove a backdoor “is not going to remediate against some of these tactics. So it really does involve taking a [much] closer look at the cloud infrastructure: How is it configured? How is it being used? And what are some areas that organizations really need to focus on?” said McWhirt. “What are some of the detection triggers, and… what are some of the proactive hardening parameters that can be enforced?”
To that end, Mandiant in a detailed white paper and blog post describes all four techniques and then offers recommendations for companies to harden their infrastructure against such attacks and remediate them if they have already occurred.
To prevent Golden SAML, FireEye recommends configuring a Group Managed Service Account (gMSA) for AD FS services, reviewing AD FS logging and auditing settings, and implementing account and network access restrictions. For the other three techniques, Mandiant advises organizations to filter accounts synched to Azure AD, limit privileged users to trusted IP, enhance mailbox auditing, review Azure application and service principal permission, enforce MFA, review registered MFA devices and review something else.
Desai, meanwhile, recommended that companies adopt a zero-trust architecture “to reduce the attack surface and prevent lateral movement.” He also advises companies to gain visibility into all outbound traffic with SSL/TLC inspection and to practice micro-segmentation with cloud workload protection.
Late last year, security company Ermetic issued a report reminding users that the SolarWinds attack risks not just on-prem systems but also cloud-based infrastructure, warning that the incident has endangered Amazon Web Services and Microsoft Azure API keys and their corresponding accounts.
“This is a particularly important point, especially in the post-Covid world, where the majority of enterprises have shifted to hybrid work environments,” said Desai. “As a result, users are outside the traditional perimeter with many applications and workloads shifting to public cloud infrastructure. We have seen cases where enterprises have struggled to protect both users and cloud resources with the same level of security as on-prem resources.”
As for the remediation, FireEye stresses the importance of executing the process with proper timing and sequencing. The report says that in order to “maximize the probability of fully eradicating this threat actor from hybrid Microsoft 365 environments,” organizations must first fully regain control of the on-premises systems that house secrets and credentials for cloud-based services.
Once that is done, they should rotate their Microsoft 365 secrets and credentials. But if the original on-premise compromise or installed backdoors aren’t entirely eradicated first then the attackers could simply reinfect the M365 app.
Desai also noted that organizations assessing damage to their on-prem and cloud assets may wish to use Sparrow.ps1, a tool created by CISA’s Cloud Forensics team to help detect potentially compromised accounts and applications in the Azure and M365 environment.
“What we don’t want to do… is have organizations go through this entire process all to be negated because the attacker is still there,” said McWhirt. They can still get access to the key material they need to create a forged token to the cloud, for example.”
“So it really is prudent… having that comprehensive overview, really having a good understanding of the ways that the attacker likely leveraged to gain access to whatever it was, [and] then pivot from on-prem to the cloud.”
“There’s no security boundary between a physical on-premise network and the cloud. It’s just kind of this fuzzy line,” said Bienstock. “That’s where things get difficult and I think a lot of it is just down to [the fact that] there’s not a lot of people who have that kind of experience. And at least historically there wasn’t a lot of good documentation or knowledge out there on how [you] recover from this type of breach. And that’s the gap we’re trying to bridge with our white paper.”