Engaged for Security

mgy0knxycvop3nptyu87

8 years ago

So I was recently engaged as an IT Security consultant and I figured I would write up what occurred, not name names, show the thought process, and maybe get a conversation started…

In this instance, an email was sent to a VIP from one of the company’s consultants. This email was empty, no subject line and no text in the body of the email. But attached to this empty email was a ‘blank’ Word that was promptly saved and opened.

The installed AV didn’t complain before and after the Word doc was opened. The only thing that tipped off the VIP that something was amiss was that the accounting software would no longer open. This prompted getting the IT dept for the company involved, which in this case, is an outsourced MSP that according to the VIP, do not have the company’s best interests at heart. The MSP’s more interested in maximizing the amount of billing they do and minimizing the amount of exertion required on their end (kinda the name of the game for an MSP, but I digress). So there isn’t a lot of trust for the MSP from the company’s side, but the Word file was submitted to the MSP.

From what I understand, the MSP scanned the Word doc with some unspecified anti-malware/anti-virus product and got no detections. Their recommendation was to contact the vendor of the accounting software to get support and get it running again on the VIP’s computer. This prompted the VIP to request an outside view on what was occurring and thus my involvement.

So after the NDA for naming the company, employees, the MSP, etc, etc, etc, I started with the email from the consultant to the VIP. It looks legitimate, if not a little weird for just being blank and with attachment. I have no access to any logs for review, so I can’t verify directly that the backend infrastructure was used for transporting the email (under MSP control), but I can check the email headers. So taking that and running it through MXToolBox (https://mxtoolbox.com/EmailHeaders.aspx) and G Suite Toolbox (https://toolbox.googleapps.com/apps/messageheader/) (I prefer to have things double checked, if possible), gives that it definitely appears to have passed through the company’s backend. I checked an internal to internal email from another consultant to the VIP to verify what a ‘good’ header looks like in this environment.

Where we stand currently:

Change all the consultant’s passwords?
Restage the consultant’s workstation?
???

Now onto the Word doc, since it contained no sensitive info, it was immediately uploaded to VirusTotal (1), Hybrid-Analysis (2), and Any.Run (3). The VirusTotal results returned 11 of 59 engine detections and of course, the AV used by the MSP and was rolled out to the company was not one of the 11 that detected a problem with the Word doc. Of course, the AV the MSP used and had deployed this company was Sophos and this vendor was not one of the 11 engines that detected anything wrong with this file.

So I surmise the MSP just took the Word doc and scanned it with the Sophos AV they more than likely had installed on their own workstations, seen no detections, and sent back their response. As an aside, due to definition updates, the Word file was blocked by Sophos approximately 24-36 hours after the first run in the company’s environment.

Using the VirusTotal, Hybrid-Analysis, and Any.Run, I begin to build a list of Indicators of Compromise (IOCs) for this event. I’m feeling that the following has been established:

Consultant received the same empty email with a document
- Outside source
- Malware compromised the workstation
- Consultant or attacker then used the consultants email to send the document higher up the chain in the company
The sent Word document (maldoc) is definitely malicious
- Malicious Macros on document open
- Runs powershell to pull malware from ‘oopasdnqwe[.]com’
- MALWARE
Currently deployed AV is blind to this maldoc and it’s payload
Consultant and VIP need to have work done…

Next step is to create an mitigation plan with the above and include the IOCs so that the company can get the MSP working on checking the environment for any other infections from this supposedly ‘clean’ Word document.

To update where we stand currently:

Mitigation Plan

Change all the consultant’s passwords
Restage the consultant’s workstation
Change all the VIP’s passwords
Restage the VIP’s workstation
Try to follow the email with the maldoc back to its source
- Was it sent from internal source to the consultant?
  - If so, then add that source to the password change/restage
- Was it sent externally to the consultant?
Compile IOCs to be submitted to the MSP
- Check company environment for:
  - Other infections
  - Possible other compromises of company assets

To build the list of IOCs, we’ll refer back to the various uploads that have been made regarding the maldoc and it’s payload. Please be aware, I did not take screenshots to demo this at the time, but am instead going back to the submission and getting the current data. So the details will show more detections for the maldoc as it is closer to current time then when this all occurred, mid-June 2018.

https://www.virustotal.com/#/file/9bac1109bed7400dbb6aa062b22c1d31e86c7f1f11bd355e631aa9ee82f8fc73/detection

IOCs

- Maldoc
  - Inquiry.doc
  - 9bac1109bed7400dbb6aa062b22c1d31e86c7f1f11bd355e631aa9ee82f8fc73
- Payload
  - C:\Users\USERID\AppData\Local\Temp\#####.exe
  - D64426736e4f588634b112829a2e347123b64ea0aa3aac0a54d2e04212f80c67 (4)(5)
    - Appears to be Ursnif (6)
    - malware family is primarily known for being a data-stealing malware, but it’s also known for acquiring a wide variety of behavior
      - Backdoors
      - Spyware
      - file infectors
- Domains
  - Oopasdnqwe.com
    - https://exchange.xforce.ibmcloud.com/url/oopasdnqwe.com
    - Risk 10 (Code RED)
    - Spam URLs
- IPs
  - 23.227.199.70
    - Points to Oopasdnqwe.com

Share this: