Analyzing Email Headers
& Tracing Attacks

Create a one-page Markdown table that you can keep on your phone or print and stick to your monitor. The table should cover the four anchor fields plus a fifth, Reply-To, which is one of the single most-abused fields in modern phishing.

Required columns:

Save the file as a2_reference_card.md. This card will be referenced from your final report; keep it concise and high-signal.

• 5 rows filled (From · Received · X-Originating-IP · Message-ID · Reply-To)
• Concise — fits on one printed A4 page
• Saved to 01_part_a/a2_reference_card.md

Below is a second dump, sample_a3_inconsistency.eml. Copy it into 00_inputs/. Find the field that contradicts another field, and write one paragraph (no more than 120 words) describing the inconsistency in plain language. You should not need any tool yet — just your eyes and the reference card you just built.

Return-Path: <noreply@actualizacion-banco.top>
Delivered-To: pedro.garcia@logistica-vallecas.com
Received: from mail37.actualizacion-banco.top (mail37.actualizacion-banco.top [89.47.114.211])
        by mx.logistica-vallecas.com (Postfix) with ESMTP id 8AE910DE2C
        for <pedro.garcia@logistica-vallecas.com>; Thu, 14 May 2026 08:11:14 +0200 (CEST)
Authentication-Results: mx.logistica-vallecas.com;
        spf=fail (sender IP is 89.47.114.211) smtp.mailfrom=actualizacion-banco.top;
        dkim=none;
        dmarc=fail action=quarantine header.from=santander.es
From: "Banco Santander — Seguridad" <seguridad@santander.es>
Reply-To: verificar@actualizacion-banco.top
To: "Pedro García" <pedro.garcia@logistica-vallecas.com>
Subject: Aviso urgente — Verifique sus credenciales en 24 horas
Date: Thu, 14 May 2026 08:11:10 +0200
Message-ID: <20260514061110.contacto@actualizacion-banco.top>
X-Originating-IP: [89.47.114.211]

• Identified the field(s) that disagree across the header
• Written paragraph (≤ 120 words) saved as a3_inconsistency.md

• Open MXToolbox Email Header Analyzer in a private/incognito window — habit worth building, limits cross-session tracking when pasting metadata into third-party services.
• Paste the full header from sample_a1_clean.eml. Leave the body out — only the header matters and the body could contain malicious markup.
• Screenshot the full results pane (routing diagram + authentication summary) as b1_mxtoolbox_clean.png in 04_screenshots/.
• Write ≈ 200-word analysis as b1_clean_analysis.md covering hop count, longest delay, SPF/DKIM/DMARC alignment, originating server geolocation.

Deliberately use a different tool from B.1. The two most common alternatives are Google Admin Toolbox — Messageheader and Microsoft's Message Header Analyzer. Pick one. If you find a fourth tool you prefer, tell me about it in your report and use it — that earns research credit.

• Paste the header from sample_a3_inconsistency.eml. Screenshot results as b2_<toolname>_suspicious.png.
• Write ≈ 200-word analysis as b2_suspicious_analysis.md.

Address these in your write-up:

• What did the tool flag that you might have missed reading the header by eye?
• The From, Return-Path, and Reply-To all disagree. Why does that disagreement, on its own, not automatically prove the email is malicious — even though it strongly suggests it?
• The Authentication-Results line shows dmarc=fail action=quarantine. Translate that into plain English for a non-technical person — say, the recipient's office manager who is going to ask you "so is it dangerous or not?"

Build a comparison table called b3_comparison.md. Three columns: What the tool checks, Tool 1 result on clean message, Tool 2 result on suspicious message.

At minimum, populate these rows:

Use whois.domaintools.com or any equivalent for the domain age — domains less than thirty days old are themselves a risk indicator.

The suspicious email purported to come from santander.es. The tools told you DMARC failed because the actual sending IP was not authorised by Santander's SPF record. Now verify that yourself, directly from public DNS, without relying on the tool.

Pick any of the following — substitute freely:

For the domain santander.es, capture three things

• SPF record (DNS TXT record starting with v=spf1) — screenshot as b4_spf_santander.png. Read it: does it list 89.47.114.211 as authorised? It should not.
• DMARC record at _dmarc.santander.es — screenshot as b4_dmarc_santander.png. Note the policy verbatim: none, quarantine, or reject.
• At least one DKIM selector at <selector>._domainkey.santander.es. Try selector1, selector2, default, google, s1, mail. If none return — document that fact and explain why.
• Write ≈ 250-word analysis as b4_auth_records.md.

Address these in your write-up:

• What does Santander's published DMARC policy tell you about how seriously they take spoofing of their domain?
• If their policy is p=quarantine or p=reject, why did the suspicious email still land in the user's inbox? Plot twist: the receiving server did mark it dmarc=fail. Whether it then spam-foldered or delivered the message depends on the recipient's mail server configuration, not on Santander's published policy. This nuance is worth understanding.
• What practical advice would you give a small Madrid business that ships invoices through a generic shared-hosting SMTP server about adopting SPF/DKIM/DMARC?

By eye, find every URL in the message. There are two — one visible (what the user sees in the email body) and one actual (where the link would actually take them). Read the HTML carefully. If you cannot tell the two apart, you have just learned the most-exploited trick in phishing: the visible text of an <a> tag is decoupled from its href. Attackers love this because it lets them put https://github.com/security/verify in front of a victim and route them somewhere completely different.

Step 1 — Defang every URL before pasting it anywhere

Step 2 — Submit each URL to three independent sources

• Submit to VirusTotal · screenshot engine results, community score, categorisation as c1_vt_<short-name>.png
• Submit to urlscan.io (public scan) · sandboxed render, redirect chain, page screenshot · save as c1_urlscan_<short-name>.png
• Submit hostname only to Cisco Talos · save as c1_talos_<short-name>.png
• Write findings into c1_url_triage.md — defanged URLs, VT score, urlscan verdict + redirect chain, Talos rating, plain-English ticket summary.

The message has one attachment, declared as application/octet-stream with the filename github_security_alert.html. In a real incident this would be a file you would never open on your own machine.

• Decode the base64 block to a file on disk, but do not open the file.
  Linux/macOS: echo "<base64-string>" | base64 -d > suspect.html
  Windows: certutil -decode in.txt out.html (after pasting the block into in.txt)
  Document the command you used.
• Compute the SHA-256 hash.
  Linux/macOS: shasum -a 256 suspect.html
  Windows: Get-FileHash suspect.html -Algorithm SHA256
• Look up the hash on VirusTotal hash search before uploading the file itself. "No prior submissions" is a valid finding — document it.
• Upload the file to VirusTotal only if hash search returned no results. (Public submissions become public artefacts. Lab file is fine.)
• Get a second-opinion verdict from Hybrid Analysis or ANY.RUN (free tier = public — never use for genuinely sensitive samples).
• Write findings as c2_attachment_triage.md: SHA-256 hash · VT hash result · second-opinion verdict · ≈ 100-word paragraph on what the decoded HTML actually contained.

Now you stitch the routing analysis from Part B together with the safe-triage results from C.1 and C.2 to produce a single end-to-end picture. This is the deliverable graders look forward to — the one that tells them whether you have actually understood the workflow or just clicked through screens.

• Read the Received chain bottom-up. The bottom-most Received line was added first chronologically. Each successive Received line is the next hop the message took.
• List the hops in chronological order in c3_routing_table.md. Columns: Hop number · Time stamp · Sending machine · Receiving machine · Sender IP · What we know about that IP.
• For each unique IP, look up AbuseIPDB + ipinfo.io + Cisco Talos. Screenshot only the interesting findings.
• Build a routing diagram — the visual centrepiece of your report. Hand-drawn, draw.io, Excalidraw, even a napkin photographed with your phone — all accepted. Save as c3_routing_diagram.png.
• Write ≈ 250 words as c3_origin_writeup.md.

Address these in your write-up:

• Which IP do you assess to be the true origin? Why?
• What does the ASN (Autonomous System Number) tell you about the kind of network the origin IP sits on — datacentre, residential ISP, mobile carrier, VPN exit node?
• Why did the email pass SPF, DKIM, and DMARC despite obviously being a phishing message?

This is the shortest section but the one professional incident response teams care most about. Write c4_attribution_caveats.md — about 200 words, no more, no less.

• What can you confidently claim about the attacker based on the evidence in your hands? (Probably: "the message originated from an IP geolocating to Sofia, Bulgaria, on a residential fibre connection".)
• What can you not claim? Almost everything else. The IP could be a compromised home router belonging to an innocent retiree whose grandson installed a torrent client; it could be a VPN exit node; it could be TOR-adjacent; the attacker themselves might be in another country entirely.
• What further evidence would you ask law enforcement to obtain that you, as a private analyst, cannot? (ISP subscriber records with court order; Mailgun server logs with subpoena; cooperation from the registrar of the look-alike domain.)
• Cite Europol — European Cybercrime Centre (EC3) and INCIBE-CERT as the appropriate cross-border bodies for a Spanish-based victim.