Suspended

Scenario

A phishing email is submitted to the SOC for analysis. The task is to triage the email file, extract indicators for scoping and defensive activities, and trace the attack chain from initial lure through to the final malicious destination.

Methodology

Stage 1 — Email Header Analysis

Opening the raw email file in Sublime Text exposes the full header structure and message body. The key fields for scoping and attribution:

Subject:  Account has been temporary suspended!
Date:     Thu, 20 Oct 2022 15:32:11 +0100
From:     Prime's Report <kzgxr6fvei99qvheq8kcee6cuibjy5b3@kfndhhejbz.internetartalliance.com>

The from address is the first red flag — a legitimate Amazon communication would never originate from internetartalliance.com. The randomised local part (kzgxr6fvei99qvheq8kcee6cuibjy5b3) and the domain are entirely unrelated to Amazon. The display name Prime's Report is crafted to trigger concern in recipients who are Amazon Prime subscribers.

The subject line Account has been temporary suspended! is a classic urgency lure — grammatical errors (temporary instead of temporarily) are common in phishing emails and serve as a passive filter to select less security-aware targets.

Stage 2 — Attachment Extraction

The email contains an attachment declared in the Content-Disposition header:

Content-Disposition: attachment; filename="Receiptupdate8761524.pdf"

The filename mimics a legitimate Amazon receipt update notification — designed to appear routine and encourage opening. The attachment body in the raw email is Base64 encoded, which is standard for email attachments but also convenient for analysts — it can be extracted and decoded directly in CyberChef.

Stage 3 — PDF Analysis via CyberChef

Extracting the Base64 content from the email body and decoding it in CyberChef reveals the raw PDF content. Searching the decoded output for http surfaces the embedded URL:

https://docs.google.com/drawings/d/1Yjoy0g6WvJ0NF2BFH3ythG186xNpIRhNn8PLaw3bUXY/preview

The PDF links to a Google Drawings page rather than a directly malicious URL — a deliberate evasion technique. Google Drawings URLs pass reputation-based URL filters because docs.google.com is a trusted domain. The malicious content is one hop further, hosted on the Google infrastructure as a staging layer.

Stage 4 — PDF File Hashing

The extracted PDF file is hashed for IOC generation and EDR/SIEM searching:

Get-FileHash '.\Receiptupdate8761524[2243].pdf'

SHA256: 71B6E937013A6A961F3BA8A4FE942DC34A58B9DDEBC79C628E1C0AD572B3755B

This hash can be submitted to VirusTotal and used as an EDR search term to identify any endpoints that have received or executed the file.

Stage 5 — Lure Document Analysis

Opening the PDF reveals a convincing Amazon impersonation — logos, branding, and formatting designed to appear as a legitimate account suspension notice:

The document contains a call-to-action button linking to the Google Drawings URL. The Google Drawings page in turn renders what appears to be an Amazon login prompt with a clickable button — a second-stage lure designed to redirect the victim to the actual phishing domain.

Stage 6 — URL Chain Analysis

Opening the Google Drawings page and inspecting the call-to-action button reveals the full redirect URL:

https://www.google.com/url?q=http://gaykauaiwedding.com/&sa=D&source=editors&ust=1666280016126192&usg=AOvVaw2-OKnMwaN5jcbNehzfwq7p

The redirect chain is: PDF → Google Drawings → Google redirect → gaykauaiwedding.com

The attacker routes through two Google-hosted layers before reaching the final destination. Each hop adds legitimacy — URL scanners and gateway filters that evaluate only the immediately visible link see docs.google.com and google.com, not gaykauaiwedding.com. The final domain is the credential harvesting site.

The full attack chain uses both a malicious attachment (T1566.001) and an embedded malicious link (T1566.002) — two phishing sub-techniques deployed in a single email.

Attack Summary

IOCs

MITRE ATT&CK

Defender Takeaways

Multi-hop redirect chains bypass URL reputation filtering — routing the victim through docs.google.com and google.com/url before reaching the malicious domain is a deliberate evasion technique. Standard URL reputation filters evaluate the immediately visible link, not the final redirect destination. Sandboxing email attachments and following redirect chains to their final destination — rather than checking only the first hop — is required to detect this pattern. Solutions like URLScan or email gateways with full redirect chain analysis address this gap.

Trusted platform abuse is a detection blind spot — Google Drawings, Google Docs, and similar SaaS platforms are frequently abused as phishing staging infrastructure because their domains have near-universal trust. Blocking or alerting on outbound connections to docs.google.com is not practical, but monitoring for users navigating from Google Drawings pages directly to credential entry forms — or flagging Google redirect URLs (google.com/url?q=) in email bodies — provides a more targeted detection layer.

Base64 PDF analysis as a standard triage step — the entire attack chain was recoverable from the raw email file without executing any payload. Extracting and decoding Base64 email attachments in CyberChef to inspect embedded URLs is a fast, safe triage technique that surfaces IOCs before any sandbox detonation is needed. This should be standard practice for any suspicious email containing an attachment.

Subject line and sender domain are primary triage signals — internetartalliance.com has no relationship to Amazon and the randomised local part of the address is a clear indicator of automated phishing infrastructure. Email gateway rules alerting on display name spoofing (display name contains “Amazon” but sending domain is not amazon.com) would have flagged this before delivery.