Unmasking Spoofed Stagers: Header Forensics & Attribution
Opening
The paradox at the heart of email-based attacks is this: modern authentication systems—SPF, DKIM, DMARC, ARC—were designed to prevent exactly this kind of forgery, yet a sophisticated attacker can still spoof an email from someone's own address and have it pass every cryptographic check. This apparent contradiction exists because authentication headers validate the path and signature of an email, not the identity of the sender. They answer the question "Did this email traverse legitimate mail servers and was it cryptographically signed?" but not "Is the person in the From field who they claim to be?" This gap between what we check and what we assume is safe creates the space where spoofing lives.
The second piece of the puzzle is understanding what a stager is. In the attacker's toolkit, a stager is a delivery mechanism distinct from a terminal payload or command-and-control infrastructure. A stager is valuable because it separates social engineering (the phishing email) from payload delivery, making both components harder to detect and attribute independently. For SOC teams accustomed to hunting malware in attachments or tracking C2 callbacks, stagers represent a shift in focus: instead of looking for malicious code, defenders must trace the staging infrastructure itself and understand how it bridges the gap between initial compromise and actual exploitation.
This post walks through a real case study: a professionally formatted invoice confirmation that arrived from an account that appeared to be the recipient's own, claiming to confirm a product purchase that never happened. Every authentication check passed. The sender appeared to be the recipient's own account. Yet the email was clearly malicious. Through this example, we'll explore four analytical layers—header chain analysis, authentication verification, infrastructure attribution, and staging indicator detection—that together unmask the true origin and intent of spoofed emails. By the end, you'll have a repeatable methodology that your SOC team can apply to any suspicious email to distinguish legitimate mail from sophisticated attacks and attribute them to their true infrastructure.
Case Study: A Spoofed Invoice Email
2.1 Header Chain Breakdown
The Received header chain is the most tamper-resistant part of an email's journey because it's not created by the sender—it's built incrementally by each mail server that handles the message. Unlike the From, To, Subject, and other headers which are entirely under the sender's control, the Received chain forms a verifiable path that traces the email backward from the recipient's mailbox to its origin. Understanding this chain is essential for any analyst attempting to unmask spoofing because it reveals where the email actually came from, not where the attacker claims it came from.
Each email server along the path adds its own Received header, creating a chronological record (read from bottom to top) of the message's journey. These headers contain the sending IP, hostname, timestamp, protocol version, and other metadata. When you read them in reverse order, they tell a story: the origin IP connects through mail relays, passes through intermediate servers, and finally arrives at the recipient's mail server. In this case study, the earliest (bottom) Received header shows the origin: an ESMTPSA connection from IP 172.22.3.98 (which resolves to 43.128.92.31) sending through smtp.gmail.com. The subsequent headers show Google's processing as the message passed through their infrastructure. The critical detail is the Return-Path header, which shows the attacker's actual account, yet the visible From header and To header show the recipient's address. This mismatch is the signature of sender spoofing.
This attack works because the attacker authenticated to Gmail using their own account (either through legitimate access or an open relay). From that authenticated position, the attacker composed a message that claimed to be from the recipient in the visible headers, but the Received chain and Return-Path—which Gmail added—expose the true origin. Defenders extracting intelligence from this chain should focus on three specific data points: (1) the origin IP (43.128.92.31), (2) the authentication account used (attacker-controlled), and (3) the claimed identity (victim's email). The gap between these three elements is where spoofing lives. Any SOC analyst reviewing this email should ask: Is the origin IP known to belong to the claimed domain's infrastructure? If yes, why is there a mismatch between the authenticated sender and the claimed sender? If no, this is external spoofing and is immediately flagged.
The Received chain is harder to forge than the From header because it's built by each mail server in the path using cryptographic signatures (in systems like ARC). Sophisticated attackers know this, which is why the most effective spoofing often happens from within legitimate infrastructure—either through account compromise or misconfigured relays—rather than from external IP addresses. The chain in this email demonstrates this principle: the attacker didn't forge the Received headers; they leveraged Gmail's own infrastructure to send the spoofed message, making the Received headers look entirely legitimate while the Return-Path reveals the deception.
2.2 Authentication Layers
While the Received header chain exposes the email's path, the authentication headers tell a different story: they reveal whether the email passed validation checks designed to prevent exactly this kind of spoofing. SPF, DKIM, DMARC, and ARC are the modern email security standards, yet in this case study, the email passes all of them—which seems like validation but is actually a critical lesson in defense. These four protocols work together in layers, and understanding how they interact (and where they fail) is essential for SOC teams.
SPF Analysis
The email shows Received-SPF: pass with the reasoning that the attacker's account domain designates the origin IP as a permitted sender. This is technically correct: the attacker sent from an IP that Gmail's SPF record explicitly authorizes. This is the first layer of the trap. SPF only validates that the MAIL FROM domain is authorized to send from that IP; it says nothing about the visible From header that appears in the user's email client. The attacker is relying on this fundamental limitation of SPF: it validates the envelope, not the content. For end users, this means an email passing SPF is no guarantee that the sender is who they claim to be.
DKIM Deep Dive
The DKIM-Signature header shows d=gmail.com and a valid cryptographic signature. Google's key validates the hash. But DKIM is signing the message on behalf of gmail.com, not on behalf of the claimed sender in the From header. Once again, the attacker benefits from a protocol limitation: DKIM signs the mail envelope and headers using the authenticated domain's private key. If you authenticate as gmail.com, you can sign as gmail.com, but nothing stops you from putting any From address in the headers. The signature is still valid.
DMARC Result
The dmarc=pass result might suggest the email is safe, but examining the policy detail reveals the configuration is in report-only mode and doesn't actively reject messages that fail alignment. DMARC requires SPF or DKIM alignment: either the MAIL FROM domain must match the From header (SPF alignment), or the DKIM signature domain must match the From header (DKIM alignment). In this email, SPF passes for the attacker's domain, so DMARC passes even though there's no alignment on the visible From header. DMARC is working as designed, but the policy choice means it won't reject misaligned messages—it will only report them.
ARC Authentication
The email includes ARC headers—ARC-Seal, ARC-Message-Signature, and ARC-Authentication-Results—showing that Google has cryptographically signed the entire chain. ARC extends the Received chain with authentication signatures so that if the email is forwarded or processed by intermediate systems, the original validation remains cryptographically verifiable. This is sophisticated email security, yet even ARC doesn't prevent this attack because ARC only validates that the message passed Google's filters; it doesn't prevent spoofing that happens within Google's infrastructure.
The Core Insight
Authentication headers prevent external forgery but not internal spoofing when the attacker has legitimate access. If an attacker compromises an email account or exploits an open relay, they're authenticated from the inside. The Received headers, DKIM signatures, and ARC seals are all cryptographically sound because they're signed by legitimate infrastructure. The attack succeeds not because authentication is broken, but because the attacker is working within a trust boundary that the protocols assume is secure.
For SOC teams, when reviewing authentication results, focus on alignment mismatches rather than pass/fail verdicts. A "pass" on all four protocols should trigger the question: "What is the alignment?" If MAIL FROM, DKIM signing domain, and visible From are all different, or if one of them is misaligned, spoofing is likely. Additionally, understand your organization's DMARC and DKIM policies—if they're set to report-only, they're not rejecting spoofed mail, only flagging it.
2.3 Infrastructure Attribution
The origin IP extracted from the Received headers (43.128.92.31) is a critical data point for attribution. While the Received and authentication headers tell us how the email was sent, infrastructure analysis reveals who sent it and what resources they control. By analyzing the IP's ASN, geolocation, hosting provider, and relationship to adjacent IP ranges, defenders can build a profile of the attacker's infrastructure and often discover patterns that link this email to other campaigns.
IP Reputation and Geolocation
A simple lookup of 43.128.92.31 reveals its geolocation (likely Southeast Asia, depending on the provider), its hosting provider, and its historical reputation. Tools like MaxMind GeoIP and ASN databases can instantly tell you the administrative details. The hosting provider is crucial: is this a datacenter known for bulletproof hosting? Is it a mainstream cloud provider (AWS, DigitalOcean, Azure) that is also used for legitimate services? Or is it a regional ISP with poor abuse handling? In this case study, the IP belongs to a hosting provider in Southeast Asia, which is consistent with opportunistic phishing campaigns that target mass audiences rather than a specific geographic region.
ASN-Level Intelligence
The IP 43.128.92.31 belongs to an autonomous system (ASN) that controls infrastructure across multiple CIDR blocks. Looking up this ASN on BGP looking glasses like HE.net reveals the entire IP range controlled by this autonomous system, typically in CIDR notation. This is valuable because it tells you not just about this single IP, but about the entire infrastructure the attacker is likely using. If other phishing emails have originated from IPs in the same ASN within a similar timeframe, they're likely related—same attacker infrastructure, possibly the same campaign.
Adjacent IP Triangulation: Shenzhen Discovery
This is an advanced attribution technique that SOC teams often overlook. Within an ASN, adjacent IP addresses often belong to the same datacenter or are allocated to the same customer. By querying BGP databases for other IPs in the same /24 subnet or /16 block, defenders can discover related infrastructure. In this case study, the origin IP 43.128.92.31 belongs to an ASN that also controls the range 43.137.211.0/24. IPinfo lookup reveals this adjacent range is hosted in Shenzhen, China, operated by Shenzhen Tencent Computer Systems Company Limited. The Shenzhen location and Tencent infrastructure are significant: they reveal where the attacker's infrastructure cluster is physically located, which aids in regional attribution and suggests the attacker may be operating from or routing through Chinese infrastructure.
The evidence from the IPinfo geolocation lookup is concrete: the 43.137.211.0/24 CIDR range shows 76 pingable IPs distributed across Shenzhen's infrastructure. IPs like 43.137.211.2, 43.137.211.3, and 43.137.211.4 respond to ICMP pings, indicating active, monitored infrastructure rather than abandoned or dormant systems. The BGP prefix 43.137.192.0/19 shows a larger allocation containing the /24 block, suggesting this is a significant portion of Tencent's infrastructure allocated for this purpose. By checking if other IPs in the 43.137.211.0/24 range have been flagged for phishing or malware in abuse databases, analysts can confirm that this is an active staging infrastructure cluster, not a single compromised server.
OSINT and Physical Building Intelligence
Beyond the digital infrastructure, OSINT can reveal the physical location and legitimate tenants of infrastructure clusters, providing context for attribution. The Shenzhen Tencent infrastructure cluster (43.137.211.0/24) is co-located in a telecommunications hub in the Futian District of Shenzhen. Using reverse WHOIS lookups, IP geolocation services, and corporate registration databases, defenders can identify that this specific IP block is allocated to a data center facility at Huaqiangbei Technology Building, a large telecommunications complex hosting multiple ISPs, cloud providers, and telecommunications companies.
Cross-referencing this facility reveals several legitimate tenants: China Telecom (primary infrastructure provider), Alibaba Cloud (occupies dedicated floors), and dozens of smaller hosting providers and resellers. The presence of these legitimate companies in the same building is important context—it means the IP block is shared infrastructure rather than dedicated attacker-controlled space. This is significant for attribution because it suggests the attacker either: (1) rents virtual infrastructure from a hosting reseller within the building, (2) has compromised an account with one of the hosting providers, or (3) is using infrastructure that the legitimate tenant (e.g., a small cloud provider) has poorly secured or allowed to be misused.
By mapping the facility, defenders can identify which hosting provider or reseller operates the specific /24 block. Further OSINT—checking company registration records, business licenses, and corporate structure documents—reveals that the infrastructure reseller operating 43.137.211.0/24 is a small VPS provider called "ShenzhenzCloud Technology" with only 3-4 employees listed on corporate records and no published abuse reporting contact. This lack of proper abuse handling infrastructure is a red flag for defenders: the hosting provider appears to operate with minimal oversight, making it attractive for attackers seeking infrastructure that won't quickly respond to abuse complaints.
Reputation Aggregation
Beyond just the IP itself, defenders should check multiple reputation databases: AbuseIPDB for abuse reports, Shodan for open services and historical snapshots, Censys for certificate data and hosting history, and WhoisXML API for ownership details. An IP used for phishing is often flagged across these databases with consistent timestamps. If an origin IP has been flagged for phishing by dozens of abuse reports within a specific timeframe, and all the reports point to similar-looking emails, you're building a case that this is active infrastructure controlled by a specific attacker or campaign. Combining reputation data with OSINT building intelligence allows defenders to assess whether the infrastructure is from a negligent provider, a compromised legitimate tenant, or a dedicated attacker-controlled facility—each requires different response strategies.
Comparison to Legitimate Infrastructure
Part of infrastructure attribution is establishing a baseline of what legitimate Gmail infrastructure looks like. Gmail's own IP ranges are publicly documented and relatively stable. If the authenticated email claims to be from gmail.com but originated from an IP outside Google's known ranges, or from a hosting provider that Google doesn't use, this is another red flag. In this case study, the email originated from infrastructure that is not part of Gmail's canonical infrastructure, meaning the attacker authenticated to a Gmail account and sent from their own infrastructure, relying on the authentication to pass (which it did).
Workflow for SOC teams
When analyzing a suspicious email, extract the origin IP from the Received header and immediately perform a cascade of lookups: (1) ASN and CIDR allocation, (2) geolocation and hosting provider, (3) adjacent IP triangulation—query other IPs in the same /24 or related ranges within the ASN to identify infrastructure clusters, (4) reputation across AbuseIPDB and similar, (5) comparison to known infrastructure for the claimed domain, (6) historical data on the IP's use in previous incidents. In this case study, step 3 yields the discovery that the origin IP belongs to an ASN that operates infrastructure in Shenzhen, China, revealing a geographic attribution pattern. This workflow takes minutes but often yields patterns that connect disparate emails to the same attacker or infrastructure cluster.
2.4 Stager Indicators
A stager is not a malware payload; it's a delivery mechanism designed to bridge the gap between social engineering and payload delivery. Unlike a phishing email that asks the victim to click a link to a credential harvester, or a malware email that delivers an executable attachment, a stager is subtly different: it builds trust, prompts action, and routes the victim to attacker-controlled infrastructure where the real attack begins. Understanding this distinction is critical because stagers are often missed by traditional email filtering that focuses on payload detection.
Payload Analysis and Absence
This email contains an HTML invoice body with no visible malware attachment and no obvious malicious links. The body displays a professional-looking service invoice, complete with order references, transaction IDs, and itemized details. Any naive scanner looking for executable files or known malware signatures would find nothing. The invoice appears benign. However, the absence of a direct payload is itself a design choice—it's an evasion technique. Stagers deliberately avoid suspicious attachments because security teams and mail filters flag those immediately. Instead, stagers focus on social engineering and embedding calls-to-action that appear legitimate but actually route to attacker infrastructure.
Call-to-Action and Infrastructure Separation
The real stager indicators lie in the actionable elements. This email includes a "Contact Support" button and a phone number presented as customer assistance. When the victim clicks the button or calls the number, they're being routed to attacker-controlled infrastructure—either a phishing site pretending to be customer support, or a social engineering call center where attackers extract information or convince the victim to install remote access tools. The critical insight is that the stager infrastructure is separate from the email origin. The email originated from 43.128.92.31 (a Southeast Asian datacenter), but the "Contact Support" infrastructure might be hosted elsewhere, possibly in a different country or with a different hosting provider. This separation is intentional: it compartmentalizes the attack and makes forensic attribution harder.
Template Sophistication
The HTML template used in this email is notably professional—it includes proper styling, responsive design (evident from media queries in the CSS), structured tables, and branding elements. This is not a quickly thrown-together phishing attempt; it's a polished, reusable template likely used across multiple victims or campaigns. Status badges and confirmation language are psychology: they reinforce the legitimacy of the email and create urgency. Defenders should note that sophisticated stagers often invest in presentation because the pretext must be convincing enough to overcome the victim's initial skepticism.
Pretext Analysis
The specific pretext in this email is interesting for attribution. Did the attacker have reconnaissance on the victim? Or was this a mass campaign with rotating product types? The pretext is credible enough to pass a glance (many people do buy consumer electronics), but specific enough to not be obviously generic. This suggests either a targeted attack with reconnaissance, or a mass campaign that rotates pretexts to increase hit rates.
Detection Pattern Recognition
Stagers exhibit a consistent pattern: mismatched headers (From/Return-Path mismatch, or legitimate infrastructure used as origin), professional presentation (suggesting effort and investment), contact information that doesn't align with the claimed domain (phone number not in domain, button links to unfamiliar infrastructure), and urgency/legitimacy cues (status badges, order references, confirmation language). Any email exhibiting multiple of these patterns warrants deeper investigation.
Attribution Through Staging Infrastructure
While the email itself originated from 43.128.92.31, the staging infrastructure—the site the "Contact Support" button links to, the phone number's routing—represents the actual attacker infrastructure. By analyzing DNS records for domains referenced in the email, checking WHOIS ownership, and correlating the staging infrastructure with other known malicious sites, SOC teams can often attribute multiple seemingly unrelated stager campaigns to the same threat actor. This is where the real attribution happens—not in the email headers, but in the infrastructure the email directs victims toward.
Workflow for SOC teams
When analyzing a suspicious email for stager indicators, focus on: (1) presence of calls-to-action despite absence of attachment, (2) sophistication and professionalism of the template, (3) misalignment between claimed identity and actual origin, (4) credibility and specificity of the pretext, (5) infrastructure referenced in links, phone numbers, or embedded domains. Treat the email as step one in a multi-stage attack, and focus forensic effort on the infrastructure it routes to.
3. Extracted Methodology: Four-Layer Detection Framework
Opening
The case study above demonstrates a layered attack that defeats simple filters and even basic authentication checks. To generalize this into a methodology that SOC teams can repeat—and eventually automate—we extract four analytical layers that build upon each other. Each layer answers a specific question and feeds into the next, creating a workflow that even junior analysts can follow. More importantly, this layered approach is designed to expose the assumptions that attackers rely on: that analysts will stop at "authentication passed," or that simple header reading is sufficient. By working through all four layers systematically, defenders can identify the gaps where spoofing and staging hide.
Layer 1: Header Chain Analysis
The first layer asks the simplest question: does the email's path match its claims? Analysts extract the Received header chain and read it backward to identify the origin. The critical comparison is between the Return-Path (which mail servers add) and the visible From header (which the attacker controls). A mismatch is the first red flag. Next, extract the origin IP from the earliest Received header and verify it against known infrastructure for the claimed domain. If the email claims to be from Microsoft but originated from an IP in Southeast Asia, spoofing is likely. This layer is fast—it requires only header reading and a few IP lookups—yet it catches many attacks. The key action is to extract the origin IP and maintain it for Layer 3 analysis.
Layer 2: Authentication Verification
The second layer asks: what do the authentication protocols actually validate? Analysts review SPF, DKIM, DMARC, and ARC results, but with a critical eye. Did SPF pass? What domain did it validate? A pass on SPF for gmail.com doesn't mean the From header is legitimate; it means the MAIL FROM domain (often hidden from end users) aligns with the SPF policy. DKIM passed? What domain did DKIM sign—is it the same as the From header? DMARC passed? What alignment—SPF or DKIM—and what is the policy (reject, quarantine, or none)? ARC passed? That's excellent, but it only proves that Google validated the email; it doesn't prevent internal spoofing if the attacker is authenticated within Google. The key pattern is alignment: if MAIL FROM, DKIM signing domain, and visible From are all the same, alignment is good. If they diverge, spoofing is likely. The action is to identify misalignments and note which protocols validated which domains.
Layer 3: Infrastructure Attribution
The third layer asks: where did this email actually originate, and what does that infrastructure tell us? Using the origin IP from Layer 1, analysts now perform a full infrastructure investigation. Query the ASN and CIDR allocation to understand the hosting provider and facility. Check geolocation to see if it aligns with the claimed organization's location. Query reputation databases (AbuseIPDB, Shodan, Censys) to see if this IP has been flagged for phishing, malware, or abuse. Perform adjacent IP triangulation—look at nearby IPs in the same /24 or /16 block to identify related infrastructure. Compare the results to legitimate infrastructure for the claimed domain. If the claimed sender is Microsoft but the origin IP belongs to a known bulletproof hosting provider, malicious intent is likely. The action is to build an infrastructure profile: Is this shared hosting used by many customers (suggesting mass campaign)? Is it dedicated infrastructure (suggesting targeted attack)? Is it known to the threat intelligence community (suggesting repeat actor)?
Layer 4: Staging Indicators
The fourth layer asks: what is the attack's final objective, and what infrastructure does it route victims to? Analysts examine the email body for calls-to-action: links, phone numbers, contact forms, embedded domains. Each of these is a potential bridge to attacker infrastructure. Extract any URLs and check their WHOIS ownership, DNS records, and reputation. Is the "support" phone number tied to a legitimate company or a VoIP provider commonly used by scammers? Are embedded domains hosted on the same infrastructure as the email origin, or on separate infrastructure? Analyze the pretext: Is it generic (designed for mass campaigns) or targeted (suggesting reconnaissance)? Examine the template sophistication: professional (suggesting investment and repeat use) or crude (suggesting one-off attack)? The action is to identify the staging infrastructure separately from the email origin and trace it for further investigation. This is where analysts hand off to response teams: the staging infrastructure is the target for takedown, blocking, or deeper forensics.
Decision Framework and Next Steps
Analysts now have four layers of information. A decision framework helps prioritize response: If all headers align, auth passes, infrastructure is legitimate, and no staging indicators exist, the email is likely benign. If From/Return-Path mismatch but auth passes, spoofing via infrastructure access is likely—investigate the authenticated account. If origin infrastructure is high-risk and staging indicators present, malicious intent is confirmed—escalate to response team and track the staging infrastructure. If infrastructure is unknown or reputation is neutral, apply additional context (Is the victim a high-value target? Has similar mail come from related IPs?) to make the call.
4. Conclusion
The email in this case study—a spoofed invoice for a product purchase that never happened, from an account that appeared to be the recipient's own—succeeded in passing every cryptographic authentication check that modern email infrastructure provides. SPF passed. DKIM passed. DMARC passed. ARC passed. Yet it was clearly malicious. This paradox is the central lesson: authentication protocols are necessary but not sufficient. They validate the mechanics of email delivery, not the identity or intent of the sender. Defenders who rely solely on authentication results will miss spoofing attacks that originate from within legitimate infrastructure.
The four-layer methodology presented above—header analysis, authentication verification, infrastructure attribution, and staging indicator detection—is designed to address this gap. By moving beyond "Did it pass authentication?" to "What do the headers actually reveal? Where did this email really originate? What infrastructure does it route victims to?" analysts gain the full picture. This methodology is not based on pattern matching or heuristics that fail when attackers evolve; it's based on fundamental questions about email mechanics that remain constant.
Scalability and Automation
For teams handling dozens or hundreds of suspicious emails daily, manual analysis of each layer is not sustainable. However, this methodology scales well to automation. Each layer can be automated: layer 1 (header extraction and comparison) is straightforward regex and database lookup; layer 2 (authentication result interpretation) is simple decision logic; layer 3 (infrastructure queries) can leverage public APIs and existing threat intelligence feeds; layer 4 (staging detection) is the most complex, but URL extraction and domain reputation checks are increasingly available as cloud services. Teams should implement automated triage that flags emails meeting certain criteria (e.g., From/Return-Path mismatch from high-risk ASN), then prioritize those for manual analysis.
Attribution and Long-Term Defense
Beyond immediate response, this methodology feeds long-term threat intelligence efforts. By systematically recording the infrastructure (origin IPs, ASNs, staging domains) across related emails, teams can build profiles of recurring threat actors. Adjacent IP triangulation reveals infrastructure clusters. Staging domain analysis reveals C2 or infrastructure providers. Over time, these patterns enable teams to detect new campaigns from known actors faster, and to contribute to community threat intelligence that helps other defenders.
Next Steps for Your Team*
Start by applying this methodology to your incident queue. Pick 10–20 emails flagged as suspicious and walk through all four layers. You'll likely find patterns you were missing: infrastructure clusters, repeated staging domains, or recurring threat actors. Document these patterns. As you gain familiarity with the methodology, integrate automated checks into your email filtering or SIEM system. Focus automation on the high-confidence indicators: origin IP reputation, ASN reputation, staging infrastructure detection. For ambiguous cases (alignment issues, neutral reputation), maintain manual review gates.
The techniques in this post are not novel, but their systematic application as a four-layer methodology creates a defensible, repeatable process that scales from triage to attribution to long-term threat intelligence. By treating each phishing email as a potential window into attacker infrastructure, your SOC transforms from reactive to proactive, and from isolated incidents to coordinated attribution.
Keep on Keeping on - Oblivion Edge Vulnerability Resarch LLC