Analyse a phishing email without opening the lure
Use a synthetic message to inspect headers, authentication results, URLs, and attachment metadata without contacting attacker infrastructure.
Scope
For learners using a text-only sample, isolated workstation, and non-sensitive training data.
Start with the situation, not the slogan
This lab is designed to produce evidence and judgement, not a ceremonial screenshot of a tool running. Analyse a phishing email without opening the lure is successful when you can explain the question, predict the expected observation, collect it safely and distinguish a useful result from noise. The commands are the least interesting part, although they are traditionally the part everyone photographs.
Use systems you own or have explicit permission to test. Keep the exercise isolated from household, client and production networks, take a snapshot before deliberate breakage, and write the rollback step before the first change. A lab without a reset path is simply a future troubleshooting appointment.
The safest first analysis is passive. Headers and message structure can reveal routing and impersonation clues without visiting a link or executing an attachment.
Composite scenario
How this usually reaches the desk
Set one modest objective for the session. Begin with the expected clue: The sample includes full transport headers, body, URLs, and a harmless attachment or hash. Then create or collect only enough benign activity to make that clue visible. If the observation does not appear, investigate the data path before adding more tools. Instrumentation that cannot see a known test event will not become more perceptive during a real incident.
This scenario combines common operational patterns; it is not presented as a report of one named incident.
What to look for
Begin with preserved, comparable evidence. One signal is rarely proof; use independent observations and a reliable timeline before declaring scope or intent.
The sample includes full transport headers, body, URLs, and a harmless attachment or hash.
Write the expected observation before the exercise. Include the source, destination, time and field that should carry it; this turns an interesting screen into a falsifiable test.
SPF, DKIM, and DMARC results are interpreted as signals, not universal proof of legitimacy.
Confirm that clocks, names and identifiers line up across the lab. Time drift and ambiguous hostnames can turn three tidy events into an accidental detective novel.
Displayed sender, reply-to, return-path, and received chain are compared for meaningful differences.
Keep a known-good comparison. The aim is not merely to produce an alert or packet, but to explain how the test differs from ordinary activity and where false positives would arise.
Working examples
Run it, read it, decide what changes
These examples use documentation addresses, test identities and bounded targets. Replace placeholders only inside systems you own or are explicitly authorised to operate. Read the expected result and next action before running the command; a successful command is evidence, not yet a conclusion.
Extract the authentication results from an EML file
- Prerequisites
- A saved `.eml` message; do not open attachments or remote content.
grep -iE '^(From|Return-Path|Reply-To|Message-ID|Received|Authentication-Results|DKIM-Signature):' suspicious.eml > headers.txt
shasum -a 256 suspicious.eml headers.txtThe selected headers are written to a text file and both files receive hashes.
SPF, DKIM and DMARC results describe domain authentication, not whether the message is honest. Inspect the full Received chain and business context.
Compare the sending infrastructure and reply path with a known-good message from the claimed organisation.
Reveal a link target without visiting it
- Prerequisites
- A saved `.eml`; no browser is required.
python3 - <<'PY'
from email import policy
from email.parser import BytesParser
from html.parser import HTMLParser
class Links(HTMLParser):
def handle_starttag(self, tag, attrs):
if tag == 'a': print(dict(attrs).get('href',''))
with open('suspicious.eml','rb') as f:
msg=BytesParser(policy=policy.default).parse(f)
for part in msg.walk():
if part.get_content_type()=='text/html': Links().feed(part.get_content())
PYEvery HTML anchor destination is printed as text.
A blank result can mean the message is plain text, encoded unusually or contains a button built without an anchor. Do not browse the URLs from a trusted session.
Defang URLs for the case record, search mail telemetry for other recipients, and block only after confirming the correct domain or indicator.
Hash every attachment without executing it
- Prerequisites
- A saved `.eml` and a new empty output directory.
mkdir attachments
python3 - <<'PY'
from email import policy
from email.parser import BytesParser
from pathlib import Path
import hashlib
m=BytesParser(policy=policy.default).parse(open('suspicious.eml','rb'))
for p in m.iter_attachments():
data=p.get_payload(decode=True) or b''
name=Path(p.get_filename() or 'attachment.bin').name
out=Path('attachments')/name; out.write_bytes(data)
print(hashlib.sha256(data).hexdigest(), name)
PYAttachments are written without launching their associated applications and each SHA-256 is printed.
Extraction is not detonation. A clean reputation result cannot prove safety, and confidential attachments should not be uploaded to public services.
Scan in an approved isolated environment, retain the original message, and correlate hashes with endpoint and mail-gateway telemetry.
Lab procedure
Read the whole sequence before starting. Several workstreams may run in parallel, but their evidence, authority and expected outcomes still need to be explicit. Every step below points back to a concrete example; use the example as implementation evidence, not as permission to operate outside the stated scope.
Operational judgement
Keep a lab notebook with four columns: time, action, expected evidence and observed evidence. Add screenshots only when they preserve information that text cannot. The notebook should allow another person to repeat the exercise without inheriting your browser history, shell history and particular relationship with luck.
The transfer-to-production question matters more than the demo. For Phishing, Email headers and Analysis, consider data volume, retention, credentials, privacy, performance, ownership and failure behaviour. A successful lab proves that a mechanism can work under stated conditions; it does not prove that it can be deployed everywhere before lunch.
Handover
Make the result useful to the next person
Turn the exercise into a reusable lab card. Record the learning objective, isolation boundary, diagram, versions, seed data, expected observations, exact queries, screenshots that add real information, and the reset procedure. Mark which evidence was generated and which was supplied. If the lab uses a deliberately vulnerable image or sample, store its provenance and checksum. Future-you is a different operator and deserves better documentation than “it worked after I restarted something”.
End with a short teach-back. Explain why “Store the synthetic message as evidence and work from a copy with network access disabled.” matters, demonstrate the observation that supports the conclusion, and show how the environment returns to baseline after “Write a short verdict with confidence, supporting fields, limitations, and the next safe investigative step.” Then name one production assumption the lab did not test. That last sentence keeps a useful experiment from turning into unjustified confidence and gives the next exercise a sensible place to begin.
Validate before you close
Another learner should reproduce the header findings and agree which facts are proven, which are suspicious, and which require external evidence.
Capture the test, the expected result and the observed result. Where a person or business owner must accept restored service, name them in the record. A green dashboard can confirm that a component is answering; it cannot confirm that invoices, identities or restored data are trustworthy.
Finish with a compact closure note: the original trigger, confirmed scope, evidence retained, controls changed, tests passed, known gaps, residual risk, and the people responsible for the remaining work. Schedule a review while the timeline is still fresh enough to challenge. The purpose is not to find a person to blame; computers already perform blame with admirable efficiency. The purpose is to make the next response faster, safer and less dependent on one person remembering where the useful log was hidden.
Common mistakes
- Connecting an intentionally weak lab directly to a home or production network.
- Copying commands without recording the expected evidence and rollback step.
- Calling a test successful without comparing the result to a known-good baseline.
These errors usually come from haste, unclear ownership or misplaced confidence. Build the safeguard into the runbook: a required evidence field, a second-person review, a rollback test or a specific exit criterion.
Questions people ask when the clock is running
Can I run this against a public target for practice?
No. Keep the work to systems you own or are explicitly authorised to assess. An educational intention is not an access-control mechanism and will not improve the conversation with a provider or solicitor.
What should I save from the exercise?
Keep the topology, versions, raw evidence, exact filters or rules, expected result, observed result and rollback notes. Remove real secrets and personal data before sharing the notebook.
How do I know the lab worked?
Another learner should reproduce the header findings and agree which facts are proven, which are suspicious, and which require external evidence. Repeat the key observation from a clean snapshot; repeatability is a stronger result than a single attractive screenshot.
Safety boundary
Use these steps only on systems you own or are explicitly authorised to assess. Preserve evidence, follow your organisation’s legal and regulatory obligations, and prefer reversible actions when the situation is not yet understood.
Primary references
Editorial status: first edition. Review the linked vendor documentation for product- and version-specific changes before acting.