Is your Microsoft environment protected from Storm-2372

Are you protecting the core of your business operations from Storm-2372? In case you missed our last webinar, we’ve been helping our customers thrive by maximizing the security potential of their M365 environments. With M365 apps at the crux of communications, file storage/sharing, and authentication to inter-connected systems, one overlooked configuration setting could lead to a big ripple effect.

In the active Storm-2372 phishing campaign, a threat actor is targeting organizations within government, IT, defense, telecommunications, health, and energy/oil/gas sectors in Europe, North America, Africa, and the Middle East. Seemingly linked to Russian interests, the threat actor is exploiting input-constrained devices (think smart TVs and some Internet of Things “smart home” devices). 

So how does this work? The attacker starts a conversation with the target using messaging platforms like Microsoft Teams, WhatsApp, or Signal, posing as a prominent person and inviting the target to an online meeting such as an industry-relevant conference or interview. The fake Teams meeting invite includes a device code generated by the attacker to imitate the experience of the messaging service. This provides the attacker initial access to your account and enables Graph API data collection activities like email harvesting. With this done, the attacker no longer needs password for the victim’s M365 services (email, cloud storage) as long as the tokens remain valid, or as long as the attacker can use the specific client ID to generate new tokens.

What can you do about it?

• Disable External Messaging: We see this often when we perform Microsoft 365 Assessments for our customers. It’s such an easy one to miss, but leaves a gaping hole in your security.
• Restrict Device Code Authentication Flow: Block the device code flow wherever possible, as it’s primarily intended for devices lacking traditional input methods. Evaluate your organization’s need for this feature and disable it unless absolutely necessary.
• Configure Conditional Access Policies: Utilize Microsoft Entra ID (formerly Azure Active Directory) to create Conditional Access policies that control device code authentication. This includes:
  • Blocking Device Code Flow: Set policies to prevent device code authentication for all users, with exceptions only for specific cases where it’s required.
  • Enforcing Multi-Factor Authentication (MFA): Require MFA for all sign-ins to add an extra layer of security.
  • Implementing Sign-in Risk Policies: Automatically respond to risky sign-ins by blocking access or requiring additional verification.
• Educate Users on Phishing Techniques: Conduct regular training sessions to help users recognize and avoid phishing attempts, especially those involving device code authentication requests.
• Monitor Sign-in Activity: Regularly review sign-in logs for unusual activities, such as unexpected device code authentications or sign-ins from unfamiliar locations.
• Restrict Device Registrations: Limit permissions for device registrations to prevent unauthorized devices from accessing your environment. Regularly audit registered devices to ensure they are authorized.

 

If you’re unsure where to start, or want to confirm your Microsoft environment doesn’t have any gaps, don’t hesitate to reach out. We’ve helped many customers ensure their environments are safe and secure.