01 Mar 2019

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.

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.

Email

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 mout.perfora.net (mout.perfora.net [74.208.4.194]) by mail.xxx.xxx 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 ([73.176.34.210]) by mrelay.perfora.net (mreueus002
 [74.208.5.2]) 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 xxx.com 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

;; OPT PSEUDOSECTION:
; EDNS: version: 0, flags:; udp: 4000
; COOKIE: 0c5f07116f296ef9 (echoed)
;; QUESTION SECTION:
;xxx.com.       IN      MX

;; ANSWER SECTION:
xxx.com. 598    IN      MX      0 smtp.secureserver.net.
xxx.com. 598    IN      MX      10 mailstore1.secureserver.net.

$ ping xxx.com
PING xxx.com (128.136.151.95) 56(84) bytes of data.
^C
--- xxx.com ping statistics ---
3 packets transmitted, 0 received, 100% packet loss, time 2001ms

$ whois 128.136.151.95

NetRange:       128.136.0.0 - 128.136.255.255
CIDR:           128.136.0.0/16
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
Ref:            https://rdap.arin.net/registry/ip/128.136.0.0

OrgAbuseHandle: ABUSE1522-ARIN
OrgAbuseName:   Abuse
OrgAbusePhone:  +1-866-732-5836
OrgAbuseEmail:  [email protected]
OrgAbuseRef:    https://rdap.arin.net/registry/entity/ABUSE1522-ARIN

$ whois xxx.com
   Domain Name: xxx.com
   Registry Domain ID: 1201393605_DOMAIN_COM-VRSN
   Registrar WHOIS Server: whois.wildwestdomains.com
   Registrar URL: http://www.wildwestdomains.com
   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 https://icann.org/epp#clientDeleteProhibited
   Domain Status: clientRenewProhibited https://icann.org/epp#clientRenewProhibited
   Domain Status: clientTransferProhibited https://icann.org/epp#clientTransferProhibited
   Domain Status: clientUpdateProhibited https://icann.org/epp#clientUpdateProhibited
   Name Server: NS01.DOMAINCONTROL.COM
   Name Server: NS02.DOMAINCONTROL.COM
   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.