This post documents the analysis of a real-world phishing campaign impersonating Apple, received via Gmail and automatically classified as Spam → Dangerous. The campaign is representative of modern phishing operations that deliberately avoid malware delivery and instead focus on credential harvesting, infrastructure abuse, and psychological pressure.
The analysis covers:
- Email delivery and authentication
- Message header analysis
- Social engineering techniques
- Redirect infrastructure
- Phishing site structure
- Network-level credential exfiltration
All investigation was conducted using sandboxed environments and passive analysis techniques. No real credentials were used.
1. Initial Email Delivery and Gmail Classification
The message was delivered to Gmail but never reached the inbox. Gmail immediately placed it in the Spam folder with a Dangerous warning banner.
This is notable because:
- The message passed multiple authentication checks
- Gmail still classified it as malicious based on content, behaviour, and reputation
This highlights a critical point:
Modern phishing campaigns often pass SPF and DKIM. Authentication success does not imply legitimacy.
This was the email in my spam folder:
Then the content of the message looked like this, yes there are no images as that is an indication of receipt in itself:
2. Message Header Analysis
2.1 Sender Identity and Domain Mismatch
Displayed sender name: Apple-Support
Actual sender domain: [emobilers[.]com]
Apple does not send transactional or security emails from third-party domains. This alone is a strong impersonation indicator.
2.2 Mail Infrastructure Path
The message traversed multiple systems before reaching Gmail:
- Originating host: server-633586[.]suffixdomains[.]net
- Sending IP: [50[.]6[.]4[.]96]
- Forwarding service: forwardemail[.]net
The use of a legitimate forwarding service allows attackers to:
- Re-sign messages with valid DKIM
- Preserve ARC chains
- Bypass simplistic filtering rules
2.3 Authentication Results
| Mechanism | Result | Notes |
|---|---|---|
| SPF | Pass (via forwarder) | Not aligned with impersonated brand |
| DKIM | Pass | Signed by forwarding and unrelated domains |
| ARC | Pass | Confirms forwarding chain, not authenticity |
| DMARC | None / Not enforced | Sender domain lacks strict policy |
This combination is frequently abused in phishing campaigns: technical validity without brand alignment.
3. Email Content Analysis
3.1 Visual and Structural Characteristics
The HTML email was professionally styled and included:
- Apple logo (hosted externally)
- Apple-style typography and spacing
- UK address attribution in footer
- Clean CSS and responsive layout
However, several inconsistencies were present:
- HTML language attribute set to Japanese (
lang="ja") - Sender domain unrelated to Apple
- External image hosting
- No Apple-owned links
4. Link Obfuscation and Redirect Behaviour
The call-to-action button linked to a URL shortening service:
[hxxps://dub[.]sh/XXXXXXXX]
URL shorteners are routinely used in phishing to:
- Conceal final destinations
- Bypass reputation-based filters
- Allow rapid infrastructure rotation
Following the redirect (in a sandbox) resolved to a domain unrelated to Apple.
5. Phishing Site Hosting and Structure
5.1 Hosting Location
The phishing page was hosted on a third-party domain under a WordPress directory:
/wp-content/GCR/cap/
This is significant because:
/wp-content/ /sp-contentis commonly abused on compromised WordPress sites- Traffic blends in with legitimate CMS activity
- Many security tools deprioritise deep CMS paths
5.2 Page Functionality
The landing page presented a fake Apple login interface requesting credentials.
Observed characteristics:
- Visual imitation of Apple login flows
- No Apple-owned scripts or APIs
- Client-side JavaScript handling form submission
- No legitimate authentication validation
Then we first we go via Cloudflare which simply means the website is protected by the Cloudflare service:
Then we have the "fake" apple website:
Then you need to login, but the password can be anything:
Then you get the "processing" which is where it seems to hang of if you are lucky you will get asked for more personal details then your credit card.....
Then you are asked for your personal details:
Then you have your credit card details from the primary account you used for Apple:
5.3 Attack Daigram
6. Network-Level Credential Exfiltration
The most critical evidence came from network inspection.
6.1 Credential Submission Endpoint
When credentials were entered, the browser issued the following request:
POST /wp-content/GCR/cap/includes/check-status.php
Host: [phishing-domain]
Content-Type: application/x-www-form-urlencoded
Key observations:
- Credentials transmitted via POST
- Payload size consistent with email + password fields
- Endpoint naming deliberately generic
- Response returned HTTP 200 OK regardless of input
This confirms successful credential harvesting, remembering that the website looks real, excluding the URL and the certificate is valid for that fake domain.
6.2 What Data Is Exfiltrated
At minimum, the attacker receives:
- Account identifier (email / Apple ID)
- Password
- Source IP address
- User-Agent string
- Timestamp
7. Why HTTPS Does Not Protect the Victim
The phishing site was served over HTTPS, the padlock does not mean secure and this is often misunderstood, The certificate for this site was also issued by Lets Encrypt - Not because there is anything wrong with that service, but because the verification records have been successfully created to warrant a valid certificate - DCV had been completed at a TXT level on this website.
Important clarification:
- HTTPS encrypts traffic to the destination
- The destination server itself is malicious
- Encryption protects attackers from interception
HTTPS does not indicate trust. It only indicates encryption.
8. Why Gmail Flagged This as Dangerous
Despite authentication success, Gmail likely flagged the message based on:
- Known phishing redirect infrastructure
- Apple brand impersonation
- Domain misalignment
- Credential harvesting patterns
- Prior abuse reputation of linked resources
10. Key Lessons
- Passing SPF/DKIM does not mean an email is safe
- URL shorteners remain highly effective for phishing
- WordPress sites are frequently abused as phishing hosts
- Credential theft often occurs silently via background POST requests
- HTTPS provides encryption, not legitimacy
Conclusion
This campaign demonstrates how modern phishing attacks operate with a high level of polish while relying on relatively simple technical mechanisms. The success of the attack depends far more on psychology and infrastructure abuse than on exploiting vulnerabilities.
Gmail’s classification prevented user exposure in this case, but the same techniques remain effective against less mature mail environments.