October 14, 2020 Detection and response
Julie Brown

Catching Taurus malware with behavioral analytics and Microsoft alerts

In the latest installment of our threat detection series, we explore how the Red Canary CIRT detected an information-stealing trojan called Taurus by correlating native Microsoft Defender for Endpoint alerts with our own behavioral analytics.

On what seemed like a quiet Wednesday afternoon, one of our customers received an alert from Microsoft Defender for Endpoint. The alert was low severity, suggesting that there should be some concern. Titled “Renamed AutoIT tool,” the Defender alert warned the customer that “AutoIT can be used to launch specially crafted scripts that perform malicious actions.” Renamed executables are nothing new for endpoint threat detection, but this low-severity alert led Red Canary to uncover something much more sinister.

First, a little background

Every time a Red Canary + Microsoft customer receives an alert in Microsoft Defender Security Center, Red Canary retrieves that alert via the Microsoft Alert API and attempts to correlate the alert to any relevant endpoint telemetry continually collected by our engine. When we are able to correlate an alert to the underlying telemetry, our team of detection engineers then investigates the alert and the accompanying telemetry to determine if the event should be immediately escalated to the customer as a confirmed threat detection. By ingesting Microsoft alerts into the Red Canary engine, we are able to enhance third-party threat analytics with our library of more than 2,000 behavioral detectors.

Now, let’s talk about the threat

Based on the content in the “Renamed AutoIT tool” Microsoft alert, we expected the Red Canary engine to identify the renamed AutoIT. Things got interesting for the CIRT when four Red Canary detectors fired, revealing additional malicious activity hiding in the telemetry:

  • WIN-AUTOIT-RENAMED: This analytic looks for renamed instances of AutoIT (we expected to see this one)
  • WIN-WMIPRVSE-ROAMING: This analytic looks for a Windows Management Instrumentation provider host spawning child processes from the appdata\roaming directory
  • WIN-POWERSHELL-START-BITSTRANSFER: This analytic looks for PowerShell leveraging the Start-BitsTransfer cmdlet
  • WIN-CERTUTIL-DECODE: This analytic looks for the certutil.exe process running with a decode option

Digging in

By the time the Microsoft alert was ready for analysis, we had a lot more to investigate than the alert itself. Detection Engineer Rodrigo Garcia dug through the evidence, created a detection, and alerted our customer to the danger lurking in their environment.

microsoft alerts, taunus malware

Red Canary detection using both Microsoft alerts and behavioral detectors

 

We ingested the alert, validated the threat, and uncovered additional malicious behaviors that told the whole story. But what was the threat? We called on the experts for a better understanding.

Taurus: a new info stealer

Katie Nickels, Red Canary’s director of threat intelligence, stepped in and took a deeper look at the detection. She identified the threat as Taurus, a new strain of malware designed to steal user credentials and other sensitive data from an infected endpoint. Taurus was originally detailed on the zScaler security research blog. This instance of Taurus shared many tactics, techniques, and procedures (TTPs) with the variant documented in the original report: We observed the execution of a PowerShell script that then downloaded additional malicious payloads from newly registered domains. The payloads were decrypted using certutil.exe. However, the initial infection vector in this case was a compromised freeware download, whereas zScaler observed adversaries distributing Taurus via spam email campaigns.

microsoft alerts, taurus malware

Infection cycle of Taurus malware as observed by Red Canary

A happy ending

Red Canary provided the customer with the threat information they needed to act quickly and stop the threat in their environment. The detection was published to the customer within 2 hours of the malware originally executing on the endpoint. Our customer used Automate to notify their internal security teams of a new high severity detection. Less than 24 hours after the detection was received, the customer had removed the infected endpoint from the environment and provided the employee with a rebuilt machine.

 

Testing adversary technique variations with AtomicTestHarnesses

 

How to use Surveyor, a cybersecurity Swiss Army knife

 

Detection validation: going atomic on false negatives

 

Nothing to hide: seeking out rootkits

Subscribe to our blog