Here’s a case study for anyone studying to move into cyber security or any existing cyber security analysts that want to look for this attack within their own environment, as is is a very recent attack. This post focuses only on identifying the attack and determining the scope of how many users and devices have been compromised before sending the information to the relevant teams for remediation.
For those simply wanting to check for this attack within their own environment, skip to the very bottom for a roundup of IOC’s.
One of our endpoint security systems alerted on a Bitsadmin indicator of compromise. our endpoint security tool gives the following description… “Bitsadmin is a command-line tool that can be used to create, download or upload jobs and monitor their progress. However it can also be used to maintain persistence and evade checks for usual persistence mechanisms. An attacker with Administrator rights can use the setnotifycmdline option to create a persistent job and then specify a /Resume option at a later time to execute the job. This mechanism allows the malware to survive reboots since the job is run repeatedly after a system restart. Moreover, Bitsadmin by default downloads files unless the destination server is running IIS with the required server component and /UPLOAD is specified in the command-line. While this is not by itself malicious, the command-line needs to be reviewed to ascertain the origin and intent.”
As i’m sure is the case for most organisations, we have a lot of false positives created by all our tools and so the first thing we want to do is try and verify if this is a genuine alert that needs to be investigated or a false positive The endpoint tool includes the command line arguments for when this process was executed and so that is the first piece of evidence I look at… (some info has been censored for confidentiality and privacy reasons)
That looks a bit small so if you’re unable to read that properly, the main thing I’m focusing on here is this section…
If the download had been some internal file on our own network that I could verify I wouldn’t be too worried after some verification. However as this is downloading something from an external source it is worth some investigation into what is being downloaded.
Running this site through Symantec site review shows the URL is categorized as a security risk and so is a known malicious site. This is enough information for me to treat this as a genuine alert and not a false positive, as a download has occurred from a malicious site.
Using the endpoint tool, and looking at the processes running on the device and files created around the time of the alert, I can see an email was opened just prior to the alert being triggered. For this reason, I use our email security system to investigate what emails the user (identified from the command line argument) has received shortly before the alert was triggered.
Looking through the emails received by this user, one stands out as suspicious. Looking into the details of the email I can see a link contained within the email that looks suspicious and requires further investigation.
Checking this URL in Symantec site review also shows that it is malicious. (note if Symantec didn’t say this was malicious, I would carry out my own analysis to confirm).
Reviewing the end point tools it looks as though, when URL within the email is clicked, it downloads an xlsx file, which in turn runs a powershell script which in turn uses bitsadmin to download the payload.
At this point, I want to determine every user that has potentially been infected so their devices can be remediated. In order to do this, I want to compile a full list of emails received, a full list of the URLs contained within the emails and a full list of the URL’s that bitsadmin has downloaded payloads from.
In order to determine all the emails received I follow the processes laid out here…
And also here…
After following these processes, it was noticed that despite emails having different subject lines and having been sent from different senders, all the URLs contained within the emails ended with “order-status-fulfilled”. Knowing this allowed us to generate a list of potentially affected users.
Using this list of affected users and analysing the web proxy logs and endpoint tools, we also determine that despite the very large number of URL’s contained within the emails, there are only 3 URL’s that bitsadmin attempts to download from.
This attack was executed between the 8th and 12th October 2018
To check for this attack within your own environment, check your proxy logs or web interaction tracking tools for connections to url’s ending with “order-status-fulfilled”
Also check for connections to any of the following… (note, I believe these sites are currently down, but check your historical logs)