How Email Works

Before analyzing phishing, need to understand the protocols behind it.

• SMTP (Simple Mail Transfer Protocol) — sends emails. TCP port 587 (TLS) or legacy port 25.

• POP3 (Post Office Protocol) — downloads email to local client and deletes from server.

• IMAP (Internet Message Access Protocol) — keeps email on server, accessible from any device.

Email Delivery Flow

Sender's client → Outbound SMTP server → DNS lookup (recipient domain) 
→ Route through internet → Recipient SMTP server → Recipient client (POP3/IMAP)

The key takeaway: email passes through multiple servers. Each server adds headers. These headers are what we analyze.

Types of Phishing

Tactics Attackers Use

• Impersonation — pretend to be a trusted entity (colleague, vendor, IT support)

• Sender Spoofing — forge the "From" address to look legitimate

• Typosquatting — register look-alike domains (e.g., amaz0n.com, rnicrosoft.com)

• Homograph Attacks — use unicode characters that look identical (e.g., Cyrillic "а" vs Latin "a")

• HTML Styling — hide the real URL behind styled buttons

• URL Shortening — obscure destination using bit.ly, tinyurl

• Legitimate Service Abuse — host payloads on Google Docs, Dropbox, OneDrive

Collecting Artifacts

This is the core of phishing analysis. Collect everything before blocking anything.

Email Artifacts

• Sending address — display name vs. actual address (often different)

• Reply-to address — critical indicator. Attackers often set a different reply-to to bypass sender verification.

• Date and time — track campaign trends

• Originating IP — check X-Sender-IP or X-Originating-IP in headers

• Subject line — useful for finding similar phishing emails across mailboxes

• Recipients — check BCC field for hidden recipients (mass campaign indicator)

Web Artifacts

• Full URLs — copy via right-click "Copy Link Destination". Never click. Never hand-type.

• Root domain — determine if it's a malicious domain or a compromised legitimate site

• Redirect chains — follow 302 hops through multiple domains to find the actual phishing page

File Artifacts

• Attachment filename + extension — for EDR blocking rules

• SHA256 hash — standard for VirusTotal lookups. Avoid MD5/SHA1 (hash collision vulnerabilities).

How to Extract Email Headers

Open the .eml file in a text editor (Sublime Text works well).

Use CTRL+F to search for:

• From — sender email address

• To — recipient

• Subject — subject line

• Date — timestamp

• X-Sender-IP or X-Originating-IP — originating IP

• Reply-To — reply address (if different from sender, suspicious)

• Content-Transfer-Encoding — check for Base64 encoded content

Here's an example — opening a phishing email in Sublime Text and searching for the originating IP:

Reverse DNS Lookup

Once you have the sending server IP, verify it with a WHOIS lookup:

• MXToolbox — https://mxtoolbox.com/ReverseLookup.aspx

• Compare the resolved hostname against the claimed sender domain

• If it doesn't match, likely spoofed

Decoding Base64 Content

Some phishing emails encode their body in Base64 to bypass filters.

• Open CyberChef (https://gchq.github.io/CyberChef/)

• Paste the encoded content

• Apply "From Base64" recipe

• This reveals hidden URLs, embedded images, and actual email content

Analysis Tools

Investigation Workflow

1. Extract all artifacts from the email

2. Check sender IP with Reverse DNS

3. Screenshot any URLs with URL2PNG or URLScan.io

4. Check URLs against VirusTotal, URLhaus, PhishTank

5. If attachments exist — get SHA256 hash, check VirusTotal, detonate in sandbox

6. Check domain registration date (WHOIS) — newly registered domains are suspicious

7. Document everything

Real Investigation: Following a Redirect Chain

Phishing emails often use multiple redirects to hide the actual destination. Here's a walkthrough from a real investigation.

The Setup

A phishing email impersonating Disney+ was targeting German users. The email contained a link — but the link didn't go directly to the phishing site.

First, copy the link (right-click, never click) and decode it:

Following the Redirects

The first URL returns an HTTP 302 Found — a redirect:

Check the HTTP header to find where it's redirecting to:

After following the full redirect chain, we reach the actual phishing domain:

Analyzing the Credential Harvester

The phishing page contained JavaScript that collected user credentials. Investigating the JS revealed what data was being harvested:

The stolen data was POST'ed to a specific endpoint:

WHOIS and Infrastructure Analysis

Checking the WHOIS record — the domain was registered just 2 days before the phishing email was sent:

The hosting server was located in Russia:

And the same server was hosting 10+ other credential harvesters, all targeting banks:

Key Takeaways from This Investigation

• One phishing email led to a full infrastructure of credential harvesters

• Redirect chains are used to evade URL reputation checks

• WHOIS registration date is a strong indicator — freshly registered domains targeting your org are suspicious

• Always investigate the hosting infrastructure — you might find more campaigns

Defensive Actions

Preventative

SPF (Sender Policy Framework)

• DNS TXT record that defines which servers can send emails for your domain

• Syntax: v=spf1 a: include:mailgun.org protection.outlook.com -all

• -all = hard fail — block unauthorized senders

DKIM (DomainKeys Identified Mail)

• Cryptographic signature to verify email authenticity

• Sender's mail server generates an encrypted hash (private key) → added to email header

• Recipient server verifies with public key stored in DNS

• Syntax: V=DKIM1 <key type> <public key>

DMARC (Domain-based Message Authentication, Reporting & Conformance)

• Builds on SPF + DKIM. Lets domain owners set policy for failed authentication:

  • p=none — monitoring only

  • p=quarantine — send to spam

  • p=reject — block completely

• Example: v=DMARC1; p=quarantine; rua=mailto:admin@company.com

• Generates reports for monitoring authentication failures

Other Preventative Measures:

• Spam filters (content and reputation-based)

• Attachment sandboxing — detonate before delivery

• External email banners — warn users about external senders

• Security awareness training

Reactive

When a phishing email is confirmed:

1. Quarantine — remove from all mailboxes that received it

2. Notify — alert affected users immediately

3. Block sender — add sending address/domain to mail gateway blocklist

4. Block URLs — add malicious URLs/domains to proxy or firewall blocklists

5. Block file hashes — add to EDR/antivirus blocklists

6. Reset credentials — if any user clicked and submitted credentials

Sanitizing Artifacts for Reports

Before sharing IOCs in reports or tickets, defang them to prevent accidental clicks:

• URLs: hXXps://malicious[.]com/phish

• IPs: 192.168.1[.]1

• Emails: attacker[@]evil[.]com

Phishing Report Template

A proper phishing analysis report should include:

1. Email Header Info — sender, recipient, date, originating IP, subject

2. Artifacts & Body Content — URLs, attachments, embedded content with sanitized IOCs

3. Analysis Process & Results — which tools were used, what they found

4. Classification — recon, credential harvester, malware delivery, BEC

5. Defensive Measures Taken — what was blocked, who was notified

6. Attached Evidence — original .eml or .msg file, screenshots

Key Takeaways

• Always collect artifacts before blocking — you need the evidence

• Reply-To address is one of the most reliable phishing indicators

• Use SHA256 for file hash lookups (not MD5/SHA1)

• Never click links directly — use right-click "Copy Link Destination" or extract from text editor

• SPF + DKIM + DMARC together provide layered email authentication

• Sanitize all IOCs before sharing in reports

• Check domain WHOIS — newly registered domains targeting your org is a strong indicator

• Investigate the infrastructure — one phishing domain often hosts many campaigns

Network Topolgy & Attack Scenario

VM System

In the course, virtual machines (VMs) are used, but I prefer using Proxmox VE to save resources.

Overall Purpose of homelab project

• Comparison of Detection Integration: corp-svr(without EDR) vs. linux-client (with Wazuh Agent)

Configure a Vulnerability

Open SSH

• PasswordAuthentication yes : Allows users to log in using a standard password rather than a secure SSH key.

  • Why Insecure?: Vulnerable to brute-force attacks.

    

• PermitRootLogin yes : Allows the "root" account to log in directly via SSH.

  • Why Insecure?: Attackers only need to guess one password to gain full control of the machine.

    

• Weak Password: Set the root password to november using sudo passwd root .

Create Detection Alert for ssh in Wazuh

• To create a detection alert, use an SSH authentication failure sample.
  - From the screenshot, can get decoder name, rule groups.

  

• Using the sample, create a query.

Enable WinRM on win-client

• What is WinRM?: allows administrators to remotely manage Windows systems, similar to how SSH works for Linux.

• enable WinRM codeline
  powershell -ep bypass Enable-PSRemoting -force winrm quickconfig -transport:https Set-Item wsman:\localhost\client\trustedhosts * net localgroup "Remote Management Users" /add administrator Restart-Service WinRM .

How to detect activation of WinRM

- Event ID 4624 with a logonProcessName of Kerberos
- Wazuh Rule ID: 60106
- Description: User: Windows Logon Success

• From the sample above, make data filter for alerts

  

Configure SMTP Email Inbox Connection

[project-x-corp-svr] -> [project-x-linux-client]

• Docker is used to host and orchestrate MailHog, which acts as the SMTP server for the lab environment.

• The email_poller.sh script is run on the client machine ([project-x-linux-client]) to interact with the MailHog server.

  

• [project-x-corp-svr] is intentionally unmanaged to demonstrate the security 'blind spot' that occurs when monitoring tools are absent.

Enable RDP on [project-x-dc]

How to detect RDP connection in Wazuh

• Default Wazuh Rule to detect RDP: 92653

  

• or query data.win.system.eventID: 4624 AND data.win.eventdata.logonProcessName: User32 .

  • Successful authentication of Windows Security Event ID: 4624 .

  • UnSuccessful authentication of Windows Security Event ID: 4625 .

  • The value User32 in the logonProcessName field indicates the use of the User32.dll library, which handles RDP logins.

Setup “Sensitive File” in [project-x-dc]

• make secrets.txt file under Administrator > Documents > ProductionFiles .

Detect file modifications in Wazuh

• Under Server management > Endpoint Groups > Windows > agent.conf

• Put below codeblock to make file monitoring

<syscheck>
  <directories check_all="yes" report_changes="yes"
  realtime="yes">C:\Users\Administrator\Documents\ProductionFiles
  </directories>
  <frequency>60</frequency>
 </syscheck>

• check_all="yes" : check multiple file properties including file's hash (MD5, SHA1, and SHA256), permissions, owner, group, and size

• report_changes="yes" : When a text file is modified, Wazuh will actually send the alert

• Under File Integration Monitoring's Inventory tab, can see monitoring files inculding secrets.txt

Create Detection Alert for File Modification

• Under rules tab, find local_rules.xml and adds below code

<group name="syscheck">
 <rule id="100002" level="10">
 <field name="file">secrets.txt</field>
 <match>modified</match>
 <description>File integrity monitoring alert - access to
sensitive.txt file detected</description>
 </rule>
</group>

• save and restart

• Under Alerting > Monitors > Create Monitor, write configuration

• full_log contains secrets.txt : ensures looking at events specifically related to secrets.txt .

• syscheck.event is modified : When a file change is detected, Wazuh categorizes the type of action that occurred.

• and also configure Trigger Condition

Exfiltration Setup on Attacker Machine

• scp : allow copy files and directories between two systems through ssh

• create a file where to copy secrets.txt content

Enable Insecure guest logons for [project-x-client]

• Under File Explorer Window > C:\Windows\System32 > gpedit(Run as Administrator) > Computer Configuration > Administrative Template > Network > Lanman Workstation > "Enable insecure guest logons" > “Enabled” -> allows the workstation to connect to shared network resources (like an SMB share) using a guest account with zero authentication required.

• also with command line