Email attack analysis on a rainy Friday

After several weeks of nothing happening malware-related at work, my phone pinged and alerted me to someone caught red-handed clicking on something they shouldn’t have. An employee opened a message from a local car dealer with what was assumed to be a safe attachment. The dealer was even nice enough to comply with our policy of sending PII in an encrypted ZIP. Thankfully, endpoint protection snagged the encloser Word document as soon as the employee attempted to open it. So as the alert dropped into our inboxes, the helpdesk phone rang from a slightly upset employee that just had her Friday morning routine interrupted.

While our helpdesk tech assisted the employee and tripped off the virus scan, I went to work on some analysis. My first course of action was to pull the offending message out of the mail queue and open it on my investigation box. The first red flag was the generic and rather weak attempt to get someone to open a password protected ZIP. But the second flag was that the email was a reply from a message originally sent by the employee to this same dealer back in 2016. At this point, my assumption is the dealership has suffered an email breach and this attacker is simply injecting themselves into old conversations attempting to get any traction they can.

I check out the message headers and compare them to the published mail and web infrastructure. Red flag number 3 – the message did not originate from any of the known infrastructures. Since the MX and DNS point to GoDaddy, then we can assume their mail is hosted there as well. Checking the web hosting provider points us to a colo firm who’s front page testimonial talks about helping support car sales thru optimized IT services, which reinforces my assumption.

Message Headers:

Received: from ( []) by with ESMTP id 0kHo7xSBvdRLdrVl (version=TLSv1.2 cipher=ECDHE-RSA-AES128-GCM-SHA256 bits=128 verify=NO) for <[email protected]>; Fri, 01 Mar 2019 08:10:09 -0500 (EST)
X-xxx-Envelope-From: [email protected]

Received: from localhost ([]) by (mreueus002
[]) with ESMTPSA (Nemesis) id 0LniZN-1hTosh0x71-00hxsI for
<[email protected]>; Fri, 01 Mar 2019 14:10:09 +0100
Date: Fri, 1 Mar 2019 07:10:04 -0600
To: [email protected]
From: Admin Services <[email protected]>
Subject: Re: address to send title
Message-ID: <[email protected]>
X-Mailer: Outlook

Whois results:

$ dig MX

;; global options: +cmd
;; Got answer:
;; ->>HEADER<<- opcode: QUERY, status: NOERROR, id: 61060
;; flags: qr rd ra; QUERY: 1, ANSWER: 2, AUTHORITY: 0, ADDITIONAL: 7

; EDNS: version: 0, flags:; udp: 4000
; COOKIE: 0c5f07116f296ef9 (echoed)

;; ANSWER SECTION: 598 IN MX 0 598 IN MX 10

$ ping
PING ( 56(84) bytes of data.
— ping statistics —
3 packets transmitted, 0 received, 100% packet loss, time 2001ms

$ whois

NetRange: –
NetName: PEAK10-NETBLK-19
NetHandle: NET-128-136-0-0-1
Parent: NET128 (NET-128-0-0-0-0)
NetType: Direct Allocation
OriginAS: AS19271
Organization: Peak 10, Inc. (PEK)
RegDate: 2012-02-17
Updated: 2012-10-16

OrgAbuseHandle: ABUSE1522-ARIN
OrgAbuseName: Abuse
OrgAbusePhone: +1-866-732-5836
OrgAbuseEmail: [email protected]

$ whois
Domain Name:
Registry Domain ID: 1201393605_DOMAIN_COM-VRSN
Registrar WHOIS Server:
Registrar URL:
Updated Date: 2018-09-05T15:31:18Z
Creation Date: 2007-09-07T01:05:21Z
Registry Expiry Date: 2023-09-07T01:05:21Z
Registrar: Wild West Domains, LLC
Registrar IANA ID: 440
Registrar Abuse Contact Email: [email protected]
Registrar Abuse Contact Phone: 480-624-2505
Domain Status: clientDeleteProhibited
Domain Status: clientRenewProhibited
Domain Status: clientTransferProhibited
Domain Status: clientUpdateProhibited
DNSSEC: unsigned

So my last piece of analysis was to deploy the malware in a sandbox. I used JoeSandbox Basic for this task, mostly due to lack of my own sandbox. Honestly, I don’t want a sandbox of my own. Cats poop there…anyways. The report confirmed my suspicions. Once opened, the Word document attempts to get the victim to enable macros. From there a Powershell process is spawned, but I could not determine if this happens when opened or once macros where enabled. This process calls out to known malicious IPs attempting to download additional malware.

Based on all of this, my conclusion is the dealership either had their mail server breached or someone’s computer at the dealership is owned. We let the dealership know of the potential issue, and cross our collective fingers no one else fell for this. This is a great example of how attackers are focusing on smaller financial institutions. These attacks not only target the FI’s themselves, but the vendors, customers, and other businesses they work with on a regular basis. It scares me to think what could happen once they get inside…especially if they know what they have just gained access to.

Leave a Reply

Your email address will not be published. Required fields are marked *