Legitimate infrastructure is becoming the camouflage layer for phishing

At a glance

What this is: IRONSCALES shows that attackers are using legitimate security and platform infrastructure as camouflage, so emails and links can pass checks while still delivering phishing, vishing, or BEC payloads.

Why it matters: Identity and email security teams need to treat authenticated delivery as a weak trust signal, because provenance controls alone do not prove intent, legitimacy, or user safety.

Context

Email security controls are strongest at verifying where a message came from, but much weaker at judging whether the content is trustworthy. That gap matters when attackers deliberately route payloads through legitimate services, wrappers, and authenticated mail paths so the delivery path itself becomes part of the deception.

The article’s pattern is not a broken control in one product; it is the misuse of normal trust infrastructure across the email and collaboration stack. That makes the problem relevant to both human identity workflows and NHI-heavy service flows, especially where automated trust decisions are based on headers, domains, or branding rather than message intent.

Key questions

Q: What breaks when phishing uses legitimate platforms or phone callbacks instead of a malicious payload?

A: When phishing hides behind legitimate services or phone callbacks, traditional URL scanners often return benign verdicts and post-delivery controls have little to intercept. The attack then shifts from link analysis to human manipulation, remote support abuse, or credential capture. Security teams need behavioral detection, user reporting, and controls that flag impersonation and abnormal engagement, not just malicious URLs.

Q: Why do SPF, DKIM, and DMARC still fail in well-managed environments?

A: They usually fail because identity is fragmented across systems. A domain may authenticate correctly in one layer while alignment breaks in another, especially when SaaS tools, agencies, and cloud services send mail on behalf of the business. The issue is usually ownership and lifecycle control, not the standards themselves.

Q: What do security teams get wrong about callback phishing?

A: They often optimise for links and attachments, but callback phishing pushes the compromise into a phone conversation. If the email contains only urgency and a phone number, scanners have little to evaluate. Teams should train for the social-engineering transition, not just the inbox artifact.

Q: How should organisations verify high-value financial requests that come through trusted channels?

A: Use independent verification for any request that changes money movement, account details or beneficiary data. The safe pattern is to validate the person and the instruction through channels the requester did not provide, then require a second approver for anything that creates financial exposure. Trust in the relationship is not enough when impersonation is cheap.

Technical breakdown

How trusted wrappers hide malicious destinations

URL wrapping works by rewriting a link so the user clicks through a security or platform domain before reaching the final destination. That can improve inspection and detonation, but it also creates a trust layer that attackers can exploit when scanners stop at the wrapper or over-weight the appearance of a known vendor domain. If the inspection pipeline does not fully resolve redirects, nested wrappers, and final host reputation, the visible link can look clean while the payload remains hidden. The important distinction is between link provenance and link intent: a legitimate wrapper does not make the destination safe. See the Email Security Guide.

Practical implication: Inspect the full redirect chain and treat wrapper domains as inspection points, not trust endpoints.

Why authentication checks can pass while phishing still works

SPF, DKIM and DMARC answer a narrow question: did the message originate from an authorised sending path, and was the signed content intact? They do not answer whether the message is legitimate, expected, or safe to act on. A phish delivered through a trusted service can therefore pass all three checks, especially when the attacker abuses a real platform account or a legitimate mail sender. In the BEC case described, a DKIM body-hash failure was the meaningful signal because it indicated the content changed after signing. That is a stronger integrity indicator than a simple pass/fail view of authentication. See the DMARC, SPF and DKIM Guide.

Practical implication: Use authentication as a baseline signal and escalate messages with body-integrity anomalies or unusual business requests.

Callback phishing removes the payload from the email entirely

Callback phishing, also called telephone-oriented attack delivery, shifts the attack out of the inbox and into a phone conversation. The message contains urgency, a callback number, and often a plausible billing or support scenario, but no malicious URL or attachment for a scanner to inspect. That means sandboxing and URL reputation tools have little to evaluate. The real objective is to move the victim into a live social-engineering channel where the attacker can harvest credentials, payment details, or remote access. From a control perspective, the email is just the lure; the call is the compromise path. See the Vishing and Smishing Guide.

Practical implication: Add phone-number scrutiny, finance verification steps, and callback-phishing training to email defence playbooks.

Threat narrative

Attacker objective: The attacker wants to turn trusted infrastructure into a deception channel that gets a human to approve, call, pay, or click without triggering standard security checks.

1. Entry began with phishing, vishing, or BEC messages delivered through trusted mail and platform infrastructure such as Microsoft Bookings, Safe Links, and vendor URL wrappers.
2. Credential or trust abuse followed when the attacker relied on authenticated delivery, legitimate branding, and social pressure to make the message appear safe or routine.
3. Impact emerged when the recipient was steered toward malware, payment instructions, or live phone-based social engineering that bypassed conventional email scanning.

Breaches seen in the wild

• Twilio 0ktapus breach 2022: SMS phishing of employees exposed 209 Twilio customers and 1,900 Signal users, part of the 0ktapus campaign against 130+ firms.
• Cisco Yanluowang breach 2022: A password synced to a personal Google account plus vishing and MFA fatigue opened Cisco's VPN; the attacker then abused machine accounts.

Read and download The State of NHI & AI Agent Breach Report 2026, covering 200+ breaches impacting Non-Human Identities including AI Agents.

NHI Mgmt Group analysis

Authentication is not trust: this week’s cases show that origin checks can validate delivery while attackers still weaponise the message itself. SPF, DKIM and DMARC are necessary, but they cannot determine whether a business request, link wrapper, or callback instruction is legitimate. Practitioners should treat authenticated delivery as a gating control, not a trust decision.

Trusted infrastructure has become an attack medium: the more an organisation depends on vendor branding, safe-link wrappers, and cloud collaboration services, the more those services can be turned into camouflage. That creates a governance problem as much as a filtering problem, because security teams must assume that trusted domains can carry untrusted intent. The control question is no longer whether the sender is known, but whether the message path still deserves confidence.

Callback phishing is a trust-model failure, not just a user-awareness problem: when the payload is a phone number, the attack evades the controls most email stacks are tuned to inspect. That means response logic must extend beyond the mailbox into finance validation, call verification, and identity challenge workflows. Organisations that rely only on link analysis will miss the attack class most designed to defeat it.

Email authentication controls need intent-aware correlation: a DMARC pass or a branded wrapper should never be interpreted in isolation. The right governance model correlates authentication, content risk, sender history, platform provenance, and business context before any message is treated as safe. That is especially important where a phishing path intersects with email identity and BEC controls and payment verification.

Legitimate platform abuse is now part of the threat model: attackers increasingly use the same services defenders trust to deliver collaboration, alerts, and security messages. That means identity and access governance for mail, calendar, and collaboration platforms must include abuse detection, not just account protection. The practitioner takeaway is to govern trust signals as attack surfaces, not as defaults.

What this signals

Identity trust is shifting upward into the delivery layer: the next governance problem is not whether a message was authenticated, but whether the authenticated path itself can be abused to create false confidence. That is why organisations need to evaluate message provenance, platform provenance, and business context together instead of trusting any one signal.

Mail and collaboration platforms now sit inside the threat model: if a booking invite, safe-link rewrite, or mail relay can become part of the lure, then those systems need abuse monitoring alongside access control. The operational implication is clear: collaboration tooling cannot be treated as neutral infrastructure when attackers are deliberately using it to borrow trust.

For practitioners

• Harden redirect-chain inspection Force detonation and reputation checks through every hop in wrapped links, including vendor wrappers, nested redirects, and final destination hosts.
• Escalate DKIM body-hash failures Treat financial-request emails with DKIM body-hash failures as high-confidence anomalies, even when SPF and DMARC pass.
• Build callback-phishing playbooks Add verification steps for finance and operations teams when an email contains a phone number, billing urgency, or a request to call support.
• Review collaboration-platform trust paths Audit whether calendar, booking, and messaging services can be abused to send trusted-looking lures without triggering your normal phishing controls.

Key takeaways

• Attackers are increasingly using legitimate delivery infrastructure to make malicious messages look routine and safe.
• Authentication success does not mean the content is trustworthy, and DKIM body-hash or callback clues can be more valuable than a simple pass result.
• Defenders need controls that combine message integrity, redirect-chain inspection, business-context validation, and phone-based verification for high-risk requests.

Related NHI Mgmt Group resources: Email Identity and BEC Guide · DMARC, SPF and DKIM Guide · Vishing and Smishing Guide · Email Security Guide

Key terms

• Credential Phishing: Credential phishing is a social engineering attack that tricks a person into handing over login secrets such as passwords or passcodes. In identity programmes, it matters because the stolen secret can be reused to impersonate the user, access applications, and bypass ordinary authentication controls.
• DKIM Body-Hash Failure: A verification failure that indicates the signed message body changed after the sender applied a DKIM signature. In practice, this is a strong integrity signal because it can reveal content tampering even when other authentication checks such as SPF or DMARC appear to pass.
• Trusted-Platform Abuse: The use of legitimate collaboration or cloud-sharing services as part of the attack infrastructure. The platform itself may be normal business software, but attackers exploit the trust users and security tools place in it to deliver content, redirect victims, or hide malicious activity.
• Authentication Signal: A technical indicator that a message or connection came from an authorised source or followed an expected cryptographic path. It is useful for filtering, but it is not a trust decision on its own because it does not assess intent, legitimacy, or business context.

Deepen your knowledge

NHI Foundation Level course, the industry's only accredited NHI security programme, covers NHI governance, machine identity security, and secrets management. It helps security and identity teams connect trust signals to the access decisions their programmes make every day.