It was routine. A calendar invite from her own company, formatted exactly the way Teams formats them: the meeting ID printed at the bottom, a passcode, a tidy blue "Join Meeting" button. The staff accountant in the finance department of a mid-size industrial controls company had probably clicked that same button a hundred times before.
This one was different, in a way no human eye would catch without knowing what to look for.
Get a Demo: See how IRONSCALES detects personalized phishing attacks before the click
The email had all the right pieces. The display name matched her own organization. The formatting was clean, professional, pixel-for-pixel consistent with the real Microsoft Teams notification template. A meeting ID. A partially obscured passcode. Even a secondary link to a legitimate Teams URL for reviewing meeting options.
On the surface, nothing about the message asked her to be suspicious. It looked like a colleague had added her to a call. She almost clicked.
The sender address was the first thing wrong, though she had no reason to check it. The envelope sender, info@system-scale[.]com, had nothing to do with her company. That mismatch between who appeared to be sending and who actually was is the signature of impersonation, technique T1036.005 in the MITRE ATT&CK framework. Attackers register or compromise unrelated domains, set a convincing display name, and count on the fact that most email clients bury the actual sender address behind the friendly name.
Most people never check. Most people don't need to. That's the bet.
The "Join Meeting" button had been routed through Microsoft SafeLinks before it reached her inbox. SafeLinks is a Microsoft Defender for Office 365 feature that rewraps URLs and scans them at click time. It's a real protection. It's also become part of the attacker's toolkit.
When Themis, the IRONSCALES agentic AI analyst, unwound the redirect chain, what it found at the end was not a Teams join endpoint. The link resolved to an AWS Lambda URL:
4tlm6nzyd33nmh2mcmbo3hmb3u0jqoig[.]lambda-url[.]us-east-1[.]on[.]aws
Lambda URLs live on Amazon's infrastructure. They are by default associated with a trusted, high-reputation domain. Many URL reputation filters see amazonaws.com in the chain and move on. That's the point. Hosting phishing infrastructure on major cloud providers, including AWS, Azure, and Google Cloud, has become a standard evasion technique because it defeats filters that rely on domain reputation without inspecting behavior or destination content.
The path of that Lambda URL contained one more detail. Decoded from base64, it was the recipient's own email address.
That is not an accident. That is a designed feature of the attack.
When an attacker base64-encodes your email address into the click URL, they are not being sloppy. They are confirming delivery, pre-filling a harvesting form, or tracking which specific target converted. This is spearphishing as defined by MITRE T1566.002: a targeted lure with individualized components. The campaign had been built with per-recipient URLs, which means the attacker had a list, worked through it, and built customized infrastructure for each person.
For a staff accountant in finance, that makes sense as a target profile. Finance team members process payments, hold credentials for banking and accounting systems, and are trained to act on calendar requests without asking why. According to the Verizon 2024 Data Breach Investigations Report, finance and insurance remain among the most-targeted sectors for credential theft and BEC, precisely because the downstream value of a compromised finance credential is high.
The mixed-link strategy added another layer of credibility. One link in the email pointed to a real teams.microsoft.com URL for meeting options. That was real. That worked. If a recipient hovered, ran a quick check, or used an automated scanner that sampled links, the real Teams URL would pass inspection and create a halo of legitimacy for everything else in the message. Technique T1204.001, user execution of a malicious link, relies on that split-second trust decision. The attacker gave her a reason to decide yes.
Self-Guided Tour: See how IRONSCALES analyzes redirect chains and behavioral signals
What Themis flagged was the combination: an envelope sender from system-scale[.]com claiming to be her organization, a SafeLinks-wrapped URL resolving to a Lambda endpoint instead of a Teams join URL, and a redirect path with her email address encoded in it. Any one of those signals might be explainable. Together, they were conclusive.
This is the detection gap that static filters consistently miss. A rule-based system would need to know that system-scale[.]com is malicious (it may not be on any list yet), that Lambda URLs can carry phishing payloads (they can, but the domain is trusted), and that base64 strings in URL paths warrant inspection (they do, but this check is rarely automated). Behavioral analysis that evaluates the full signal set, not individual indicators, is what closes the gap. This is the core argument for AI-based email security over legacy filtering approaches.
Without that detection, the accountant clicks. The Lambda function either redirects to a credential harvesting page or directly captures her session, depending on the backend implementation. The attacker gets a finance team login. What happens next depends on what that login can access.
The IBM 2024 Cost of a Data Breach Report puts the average cost of a phishing-initiated breach at $4.88 million. That number includes detection, investigation, notification, and remediation. It does not include the wire transfer that may have already cleared.
SafeLinks wrapping is not a safety signal. Attackers have adapted to SafeLinks. The presence of a safelinks.protection.outlook.com wrapper in a URL tells you the organization uses Defender, not that the destination is safe. Recipients should not interpret SafeLinks rewrapping as validation. Security teams should not configure their stack to treat it as one either.
Base64 in redirect paths is an IOC. If a URL path contains a base64-encoded string that decodes to a recipient identifier, that is a purpose-built targeting artifact. It belongs in your detection rules. IRONSCALES credential theft protection and similar behavioral platforms look for exactly this pattern as part of link analysis.
Mixed-legitimacy link sets require full chain inspection. One real Microsoft URL in an otherwise malicious email does not make the email safe. It makes it more dangerous, because it passes partial inspection. The attack chain has to be evaluated end to end, not sampled. Organizations relying on perimeter-only tools or gateway sampling will miss this class of attack consistently.
### Indicators of Compromise (Defanged)
| Type | Indicator | Context |
|---|---|---|
| Domain | system-scale[.]com | Envelope sender domain impersonating victim org |
info@system-scale[.]com | Attacker sender address | |
| URL | hxxps://4tlm6nzyd33nmh2mcmbo3hmb3u0jqoig[.]lambda-url[.]us-east-1[.]on[.]aws | AWS Lambda redirect endpoint, credential harvesting delivery |
Finance teams are high-value targets. They receive meeting invites constantly, process requests under time pressure, and are culturally conditioned to be responsive. Attackers know this. The combination of a Teams lure, a trusted delivery chain through SafeLinks, and personalized redirect infrastructure is not a sophisticated campaign in the sense of requiring unusual resources. It is a well-researched, low-cost operation designed to slip through the gaps that most organizations have left open.
Phishing simulation training helps finance teams recognize the signals, but simulation alone does not catch an attack that is this close to the real thing. The detection layer has to carry most of the weight.
Try It Free: Start your free trial of IRONSCALES and see what your current stack is missing
---
Sources: