The Teams Meeting Notification That Led to an AWS Lambda Credential Harvester

The meeting invite arrived looking exactly like the Teams notifications that land in corporate inboxes dozens of times a day. The display name read "Bastiansolutions Meeting," referencing the recipient's organization by name. The format matched Microsoft's own notification template: a truncated Meeting ID, a date stamp, and an "OPEN" button rendered in Microsoft blue. The footer carried links to microsoft.com's privacy and terms pages. Nothing about the visual layout raised a flag.

Underneath the familiar packaging, every technical signal pointed somewhere else entirely.

The Sender Had Nothing to Do With Microsoft or the Recipient's Organization

The From address was s.takahashi@monado[.]co[.]jp, a domain registered in 2003 belonging to MONADO Corporation, a Japanese entity with no documented relationship to industrial automation or to the recipient organization. The display name, "Bastiansolutions Meeting," was wholly fabricated.

The domain's SPF record was present, which provided a passing SPF result. But there was no DKIM signature and no DMARC record. The absence of DKIM means no cryptographic binding between the message content and the sending domain. The absence of DMARC means monado[.]co[.]jp had published no enforcement policy whatsoever. An attacker sending from a domain with SPF but no DKIM and no DMARC has exactly the authentication posture needed for this kind of display-name impersonation: enough authentication to pass basic filters, not enough to constrain who can name the sending domain in the display name.

The sender had no prior relationship with the recipient organization. No person search match existed for s.takahashi@monado[.]co[.]jp.

SafeLinks Wrapped the CTA. The Destination Was Not Microsoft.

The "OPEN" button, the primary call-to-action in the email, was wrapped in a Microsoft SafeLinks rewrite. That wrapping is itself a trust signal many recipients interpret as confirmation that a link has been scanned. It has not been blocked, therefore it must be safe.

The SafeLinks destination resolved to a credential harvesting page hosted at qb6oyttnfl44ojnui5hb6a4uma0tcxvo.lambda-url.us-east-1.on[.]aws, an AWS Lambda function URL. Lambda function URLs are auto-generated subdomains under Amazon's infrastructure. They carry the implicit reputation of Amazon Web Services without any relationship to legitimate Microsoft authentication services.

This is a deliberate choice by the attacker. Serverless function URLs on major cloud providers (AWS Lambda, Azure Functions, Google Cloud Run) are cheap to provision, carry inherited cloud-provider reputation, and have no prior blocking history at the moment of first use. A SafeLinks scan encountering a fresh Lambda URL with no existing malicious verdict may pass it without intervention.

The footer links in the email, by contrast, pointed to genuine microsoft[.]com pages. Privacy policy. Terms of service. Real URLs, real destinations. This is textbook trustbaiting: embedding high-reputation links alongside the malicious CTA to make the message read as legitimate on a surface scan.

The meeting metadata reinforced the illusion. The Subject included a truncated Meeting ID formatted as "914 ," consistent with how Teams obscures full meeting identifiers in notifications. The body text read, "This notification has been sent to you because you did not respond to a meeting invitation." The date format used "Feb/03/2026," an atypical but plausible rendering. Every detail was calibrated to pass a human quick-read.

What Authentication Did Not and Cannot Tell You

The SPF pass for monado[.]co[.]jp confirmed that the sending IP was authorized to send on behalf of that domain. It said nothing about whether that domain had any relationship to the recipient organization, to Microsoft, or to any meeting invitation the recipient might have expected. Authentication answers "was this authorized to send from this domain?" It does not answer "is this email what it claims to be?"

The mixed link destination pattern, where the CTA routes to Lambda infrastructure while the footer links route to legitimate Microsoft domains, is not detectable through authentication results or URL reputation alone. It requires analyzing the relationship between what the email claims to be (a Microsoft Teams notification) and where the primary action actually leads (a serverless AWS endpoint with a randomized 32-character subdomain).

Themis, the IRONSCALES Adaptive AI engine, flagged this email based on the behavioral fingerprint: display-name impersonation of the recipient organization, sender with no prior relationship, and a primary link destination inconsistent with the claimed sender identity. The Lambda URL pattern, combined with the SafeLinks wrapper creating a false sense of pre-clearance, is a technique that recurs across the IRONSCALES community threat feed.

Why Teams Lures Keep Working

Microsoft Teams is now central infrastructure at most organizations. Notification volume is high. The visual template is familiar enough that recipients process the format, not the content. An attacker who can clone the notification layout and insert a plausible meeting reference only needs one click to begin credential collection.

The absence of DKIM and DMARC on the sending domain is the earliest technical indicator available to defenders. Domains with SPF only and no DMARC enforcement are a known attacker preference for exactly this reason.

See Your Risk: Calculate how many threats your SEG is missing

Indicators of Compromise

MITRE ATT&CK Mapping