Source: Tero Vesalainen via Getty Images
Initial access brokers (IABs) are phishing employees by calling or texting their personal devices, then exploiting the Microsoft Graph API to perform large-scale corporate data exfiltration.
It’s almost unavoidable that, in general corporate settings, employees will use personal devices to access company resources. Only the most careful government, research, and other high-value organizations ban it entirely, and most security-forward organizations allow it insofar as employees don’t use personal devices to engage with sensitive resources. Even this reasonable latter policy is being tested, though, by attackers who know how to maximize seemingly low-risk attack paths.
Since May, Microsoft researchers have tracked at least two threat actors — Storm-3032 and Storm-3121, in its nomenclature — exploiting personal devices to totally bypass companies’ authentication security protections. Worse: the two Storms are then likely passing on their earned access to extortion groups, including the nettlesome ShinyHunters. Microsoft, however, did not connect any known corporate breaches to these initial access campaigns.
IABs Exploit Personal Devices
It’s intuitive that if an attacker wants to gain access to a corporate system, they should target a corporate account or device connected to it. The problem is that, in doing so, they’ll have to face whatever security measures that company has in place to stop them: email security gateways, endpoint detection and response (EDR), and similar controls.
It’s arguably far easier, then, to target employees’ personal devices. Those — particularly mobile phones — possess few or no security barriers. And anyone who’s worked in an office knows that people use their mobile phones in and around their work environments all the time.
Recently, threat actors have been calling or texting corporate executives and administrators on their own devices, impersonating their companies’ IT helpdesks. The pretext of the call is that the individual has to update some means of authenticating to their work accounts — a passkey, multifactor authentication (MFA), or a single sign-on (SSO) configuration — in order to not lose access to their work. Through a link sent to their phones, they can log into their accounts and restore order.
If the recipient doesn’t shrewdly identify that an important work communication shouldn’t reach them this way, they’ll likely follow the phishing link to a convincing Microsoft sign-in page. At this point, attackers have been utilizing both adversary-in-the-middle (AiTM) techniques to steal credentials and session tokens, and device code phishing flows.
More significant than any specific detail of the phishing flow is the fact that vanishingly little of it happens on actual corporate systems. As Microsoft recalled in its blog post, “In many investigations, the employee’s recollection of a phone call or text message becomes the earliest and sometimes the only evidence explaining how the compromise began. As a result, investigators must often reconstruct the attack by connecting these reports with subsequent sign-ins, device code authentication events, token activity, and authentication method changes.”
Threat actors have been decking out their phishing attacks with other fine details, too, like malicious domains that combine the names of victims’ employers with relevant security phrases such as “company[.]add-passkey[.]com.” And in a minority of cases, for added realism — or perhaps to reach more privileged employees — the hackers have used one compromised employee account to phish another. Then, having obtained control over a victim employee’s identity, they establish persistent access by registering their own MFA devices.
Graph API Attack Enables Corporate Enumeration
Possibly the most important step in any extortion attack is identifying where valuable information is and how to get there. In their continued attempt to evade corporate security measures, threat actors have been avoiding using malware or other suspicious tools in networks. Instead, they’ve been querying the Microsoft Graph API, the shared doorway for all Microsoft cloud services. The Graph API allows permissioned users to inventory users, resources, content, permissions, and other information useful for getting a full lay of the land. This is also why attackers have been targeting executives and global admins specifically, rather than regular employees — these are the individuals who tend to have the most significant permissions in their corporate Microsoft 365 environments.
As Microsoft wrote in its blog post, the Graph API is an all too innocuous tool for doing powerful reconnaissance. “Microsoft Graph abuse rarely appears suspicious when viewed through a single API call. Requests to endpoints such as /users, /groups, or /sites are commonplace in enterprise environments,” the researchers wrote. Only when a single identity or application makes a suspicious number of calls — and an organization is capable of identifying and flagging it — might the activity reach the threshold of actionable security intelligence.
With an easy way in and a helpful map of their environments, the attackers can proceed to exfiltrating sensitive corporate data. In particular, Microsoft has observed threat actors stealing data associated with SharePoint, OneDrive, and Exchange. Here, too, the threat actors have tended to keep low profiles by avoiding large, conspicuous data transfers, instead downloading small batches of files periodically over longer periods of time.
Place Security Restrictions Around Identity Policies
To combat Storm-3032, Storm-3121, and groups like them, Microsoft suggested that organizations more actively log and hunt for suspicious application data exfiltration events and batch Graph API calls, and tightly restrict users’ Graph permissions in general. When it comes to personal device risk, the researchers advocate for stricter authentication and authorization measures: requiring phishing-resistant MFA for every sign-in, blocking device code authentication flows where unnecessary, and limiting application access to managed devices.
“Non-managed devices create a challenge to track the initial vishing activity,” a Microsoft spokesperson acknowledged. “However, for this entire attack kill chain, if the targeted user has a phish-resistant MFA or conditional access policies against device code authentication, this attack would not be successful. We strongly recommend phishing-resistant MFA and enabling conditional access policy for device code authentication only for required business reasons as the key to stop this attack.”
Robert Coles, senior manager of threat intelligence security at Black Duck, seconded the point. “Organizations will get more value from strengthening identity and authentication controls than from trying to eliminate bring your own device (BYOD). Restricting personal device use may reduce some risk, but it’s not realistic for most organizations and it wouldn’t have stopped the social engineering described here,” he said.
“The attackers didn’t compromise the device, they convinced the user to trust them,” Coles noted, adding that organizations should focus on limiting the damage employees can do if they make a bad decision. “The objective is to make a compromised account much less useful to an attacker.”
