Microsoft's disclosure of two concurrent attack campaigns highlights an uncomfortable reality: authentication mechanisms designed to be more secure than passwords can still be compromised through old-fashioned social engineering. The attacks targeted Microsoft cloud infrastructure by combining third-party email infrastructure abuse with passkey-themed phishing—a shift in tactics that infrastructure engineers managing cloud workloads need to understand.
The Campaign Structure
The first campaign involved over one million fraudulent emails sent between 3–5 August 2026, spoofing chief executive officers and using compromised third-party email delivery services to bypass initial reputation filtering. This is not new behaviour in absolute terms, but the scale and the particular targeting reveal a deliberate campaign aimed at cloud account compromise rather than generic financial fraud.
The second campaign employed more targeted social engineering, specifically around passkey authentication. Rather than simply stealing credentials through a fake login form, attackers crafted messages that appeared to relate to passkey verification or enrollment processes. Since passkeys—cryptographic assertions tied to specific services—are meant to be more resistant to phishing than passwords, the psychological angle matters. Users who believe they have a more secure authentication method may lower their guard when presented with official-seeming verification requests.
Both campaigns relied on abusing existing email infrastructure that already had reputation and authentication status. This is the infrastructure angle that matters for hosting and cloud operations teams: third-party email relay services, marketing automation platforms, and transactional mail providers can become vectors when misconfigured or compromised.
Why Cloud Accounts Are the Target
Cloud environments—Microsoft 365, Azure, and similar services—remain high-value targets because they often serve as identity and access management hubs for entire organisations. Once an attacker gains valid credentials or passkey attestation, they can move laterally to on-premise infrastructure, exfiltrate data, pivot to other cloud services, or establish persistence through service principals and application permissions.
For teams running shared or multi-tenant infrastructure, the risk extends beyond a single cloud provider. A compromised Microsoft 365 account in one customer environment can expose API keys, database credentials, and deployment secrets stored in email archives or shared drives. The data exfiltration potential is significant precisely because cloud accounts aggregate so much sensitive information.
Passkey Adoption and Its Complications
Passkeys represent a genuine improvement over password-only authentication, but they introduce a new layer of user interaction that attackers can exploit through social engineering. Unlike a password, which a user might be suspicious of re-entering, a passkey verification prompt can feel legitimate—especially if the attacker's email spoofing is convincing and the target organisation hasn't yet educated staff on what passkey prompts actually look like.
The irony is that passkeys were partly designed to reduce phishing surface area. They cannot be stolen via password reuse or brute force. However, they can be socially engineered if the user is tricked into approving a fraudulent authentication request on their device, or if they're led to a fake enrollment flow before passkey registration is actually set up.
Organisations implementing passkey-based authentication—particularly those managing cloud infrastructure or offering hosting services to business customers—should assume that users will encounter phishing attempts. This means clear communication about what a legitimate passkey prompt looks like, warnings about unexpected passkey requests, and potentially hardware security key options for high-risk accounts.
Infrastructure and Email Delivery Lessons
The campaign's reliance on third-party email infrastructure underscores why organisations managing their own mail systems or evaluating hosted email solutions should apply strict sender authentication policies. SPF, DKIM, and DMARC are baseline controls, but they require proper configuration. A third-party relay service that hasn't been hardened or that accepts mail from untrusted sources can become part of an attacker's infrastructure.
For teams running dedicated mail servers or managing email delivery as part of a larger hosting operation, the takeaway is clear: monitor outbound traffic for anomalies, enforce strong authentication on relay accounts, and audit which third-party services have permission to send mail on your domain's behalf. A compromised email relay doesn't just send spam—it can deliver targeted phishing at scale.
Defence and Detection
Beyond user awareness training, defenders should implement conditional access policies that flag unusual sign-in locations or devices, enable multi-factor authentication on cloud accounts regardless of passkey deployment, and monitor for mass authentication failures followed by successful logins from new locations. Log aggregation and SIEM tools can catch the pattern of bulk phishing followed by account compromise attempts.
Organisations should also review which third-party applications have OAuth permissions to cloud accounts, as compromised accounts are often used to grant persistence through application tokens rather than repeated phishing attempts.
The passkey phishing campaigns demonstrate that authentication improvements alone don't eliminate the human element. Infrastructure security remains fundamentally tied to access control, monitoring, and the unglamorous work of keeping email systems and API tokens properly scoped and audited.
