Peach Sandstorm
The hits keep on coming! Microsoft is reporting that they’ve detected yet another nation-state threat actor that’s attacking various targets. This one is code-named Peach Sandstorm, the “Sandstorm” indicating that the threat actor is believed to be associated with the Iranian government (more specifically the Islamic Revolutionary Guard Corps, or IRGC). As with all of Microsoft’s similar reports, they’re telling the world about this particular discovery to share the indicators of compromise (IOCs) and the tactics, techniques, and procedures (TTPs) used by the attacker to help all of us identify, and hopefully prevent, their attacks. Microsoft’s blog post has plenty of details about the “Tickler” malware implanted by Peach Sandstorm, and the IOCs and TTPs associated with these attacks, if you’re interested; instead I want to focus on a couple of the suggested mitigations that you might not have thought of.
According to Microsoft, the attacks mounted by Peach Sandstorm are aimed at “the satellite, communications equipment, oil, and gas, as well as federal and state government sectors in the United States and the United Arab Emirates” and represent “persistent intelligence gathering objectives [and] the latest evolution of their long-standing cyber operations.” You might think that if you’re not in one of the mentioned industrial sectors or countries that you can ignore this but, as it turns out, some of the TTPs used by Peach Sandstorm are common, and you should be prepared to defend against them.
Spraying as Step 1
Peach Sandstorm has been using password spray attacks as one early phase of their campaign, both against the targets where they wanted to deploy Tickler but also against educational institutions (for “infrastructure procurement,” i.e. finding tenants to exploit as a platform for springboard attacks) and the satellite, government, and defense sectors for more direct exploits. Now that we’re in the year 2024, you might wonder how password spray attacks can ever be successful given their long history and the many countermeasures Microsoft has tried to get us to apply. The sad fact is that a sufficiently patient attacker can mount low-speed spray attacks that are successful in proportion to two factors: the number of tenants that don’t have enforced MFA widely deployed and the number of users in those tenants who have either reused passwords or chosen weak ones. Unfortunately, both of these factors are much more common than they should be. According to Microsoft’s analysis, the Peach Sandstorm attackers were able to successfully get access to a number of accounts from educational institutions which they used both to gain access to the accounts’ tenants but also to use those accounts to sign up for Azure educational tenants, which were then used for command and control (C2) for further attacks. These follow-on attacks include dropping the Tickler malware but also more focused attacks with custom tooling, the details of which Microsoft didn’t share in their post. If you can stop an attacker from getting credentials through password spray attacks, you add a significant degree of protection. Here’s what you can do.
Slay the Spray
While Microsoft has taken its own measures to protect against this kind of exploitation (including requiring more widespread use of MFA to access Azure administrative services), they recommend several steps for reducing the risk of, or mitigating the potential impact of, spray attacks.
First, they recommend forced password resets for any account that you suspect has been targeted by a spray attack. Be suspicious of any account that shows a large number of failed logon attempts over time, especially if MFA failures or login attempt location data doesn’t match what you’d expect to see from your actual users. You can use the Azure sign-in logs to identify this kind of behavior, although it’s easier if you have better tools (such as Purview Audit Premium, Sentinel, Security Copilot, or third-party threat hunting tools). They also suggest that you revoke session cookies for any account whose password you reset. The password spray investigation playbook has a bunch of additional useful guidance for carrying out these investigations.
Second, they recommend improving the security of your accounts by enabling Entra password protection to reduce users’ ability to pick bad passwords and Entra identity protection to give you better risk detection. These features require Entra premium licenses, but the odds are good that you already have them since they are bundled in so many different combinations of Microsoft licensing. Don’t skip enabling Entra password protection if you have a hybrid environment, as the on-premises password protection agent will give you coverage for AD-only accounts.
Microsoft also suggests that you train your users to review their own sign-in activity and flag any unauthorized activity in the “My sign-ins” page in the “My account” portal. This is a terrific idea, although it’s easier said than done. Even if you’re not able to train all your users to do this, at a minimum, you should absolutely be doing it yourself (and requiring it for other users who have privileged access). It isn’t difficult or time-consuming, and flagging the suspect activities both signals Microsoft but also marks those sign-in attempts for your own organization’s review.
Broader Protection Through Risk Detection
One of the most common complaints about airline security worldwide is that the security measures we’re all saddled with don’t seem to take into account the most likely threats. In the same vein, measures such as forcing password changes on all users, or excessively zealous MFA requirements, might be overkill. If you’ve already deployed conditional access policies, you should consider using risk-based CA policies to require additional security (including password changes or additional MFA) if Entra detects a risky sign-in. Risk-based policies require Entra ID Premium P2 licenses, which means they may not be available to you; however, the additional security that comes from this one measure is significant enough that it probably outweighs the cost of the licenses themselves.
What About the Malware?
Microsoft’s Peach Sandstorm article closes with a list of mitigations you can apply to block the Tickler malware. There isn’t much to discuss here; if you’re using an EDR system, you can configure it to automatically download signatures, block known or suspected misbehavior, and so on. If you aren’t using an EDR tool, well, that’s a separate problem that goes beyond the scope of this column.
Perhaps the closing note I should sound here is about the risk of collateral damage from threat actors like Peach Sandstorm. While this particular attack focused on specific industry sectors, it also successfully attacked educational institutions and used them to pivot to their real targets. As the educational world improves its security, sophisticated attackers will naturally find other areas where they can mount attacks… and the next one they choose might be the one your organization is in. The ongoing risk caused by the spread of these attackers means you’re better off implementing security measures like the ones covered here sooner rather than later.
