Welcome to another #ThreatThursday! This threat is a community contribution from OnDefend, a SCYTHE consulting and managed service partner. Did you know you can now purchase SCYTHE as a hosted service? Contact us for more info. Ben Finke from OnDefend will go through our typical #ThreatThursday format to introduce the threat actor, UNC2452, ingest Cyber Threat Intelligence, build an adversary emulation plan, and discuss detection and response. We hope you enjoy it!

Introduction

Hello all, I am Ben Finke, a co-founder at OnDefend.  We’re big fans of the SCYTHE platform (so much that we integrated it into our BlindSPOT purple team platform), and are excited to share one of the custom campaigns we’ve built.

When the news of the Solarwinds supply chain compromise first broke we got a *lot* of requests from our customers to help simulate not just the techniques that this particular threat actor used but how we could simulate a supply chain attack of any kind.  More on that it a later blog post, but for this #ThreatThursday post we want to share the campaign we designed.  Using the name that the excellent folks over at FireEye gave to this specific threat actor, UNC2452, we filled a SCYTHE campaign to the brim with the exact techniques observed in the wild.  

You’ll notice as you work through this threat that you will see a difference in the outcome if you run this campaign with Administrator rights versus a standard user, so make sure you test both!  This, of course, is easy to do, because it’s automated!

OK, on to the threat!

Cyber Threat Intelligence

When the news of the SolarWinds supply chain attack broke, we wanted to provide as realistic a scenario as possible to emulate the threat for teams to test their security controls against.  The idea of trusted (and possibly whitelisted) utility in your enterprise suddenly being the source of malicious activity is obviously something you will want to test, but how can you simulate something like this?

For the activity to execute, we’ll build this like any other threat.  The Mitre ATT&CK team provided a great breakdown of the UNC2452 threat actor’s TTPs in this medium post (https://medium.com/mitre-attack/identifying-unc2452-related-techniques-9f7b6c7f3714). For the purposes of this threat we are worried about the activity on the endpoint itself.  Some  actions observed in use by this group involve interaction with services over the network, such as T1098.002 - Account Manipulation - Exchange Email Delegate Permissions.  This technique is difficult to build as an automated threat without knowledge of the specific customer environment, so those types of actions are not included in this threat.

Now that we have the activity, how can we replicate a trusted utility executing this threat activity?  We could try to have our SCYTHE client payload deployed as a trusted utility in the environment, but that can be tricky to accomplish, and what if we want to change the threat after initial deployment?  

A better solution is to convert our SCYTHE payload into shellcode that can be injected into the memory space of a trusted process.  When you track back the the activity generated by the threat, it will all come back to the trusted process.

If you are a BlindSPOT customer then this is already prepared and ready for you (we automate the shellcode generation of any SCYTHE campaign, and the delivery implant has multiple process injection methods available for easy campaign execution).  

If you want to manually execute the process injection methodology, follow along in this SCYTHE blog post by Jean-Maes on using a SCYTHE payload as Shellcode: https://www.scythe.io/library/using-scythe-payload-as-shellcode

Adversary Emulation Plan

As usual, we have created and shared the adversary emulation plan in our GitHub. Here is a table with the CTI analyzed and organized for easier consumption:

Automated Emulation with SCYTHE:

1. Download and import the threat in JSON format to your SCYTHE instance - https://raw.githubusercontent.com/scythe-io/community-threats/master/UNC2452/UNC2452_scythe_threat.json
2. Download the Virtual File System (VFS) files under UNC2452/VFS
3. Upload the VFS files to your SCYTHE VFS in the following location: VFS:/shared/UNC2452
4. Create a new campaign, selecting HTTPS, and ensuring the communication options match the CTI: --cp yourdomain[.]com:443 --secure true --multipart 10240
5. Import from Existing Threat: UNC2452
6. Launch Campaign

Manual Execution

If you are not a SCYTHE user you can manually execute some of the procedures manually.  Some of the activities require an Administrative PowerShell session.  

Detect and Respond

Lots of surface area in this threat we can cover here.  While our typical guidance includes “don’t run as admin where possible”, this activity was observed executing from a trusted component that is installed and running with Administrative rights.  

Internet Access: One of the early detections of this attack was observing a trusted systems management utility reaching out to the Internet.  Network based proxy servers can help identify the source internal machine and the external destination, but using the built in operating system firewall can provide the exact process and application making outbound requests.  Using the host firewall as a monitoring tool (or in blocking mode as a prevention measure) can provide some good identification of unexpected activity from a trusted utility.

Defenses Working? - This threat actor actively degraded host-based security controls, such as the firewall and the registered antimalware software service.  Monitoring these systems for functionality and for log entries showing a change in state can provide high value signal that something is not working as expected.  This is also applicable for any anti-virus you may be running in your environment. You should confirm alert and response around any deactivation of your anti-virus solution. The detection opportunity for this emulation plan is to detect an event 5004 stating that “Windows Defender has been disabled”.

Scheduled Tasks - System management tools are more likely than others to create and utilize scheduled tasks, but that doesn’t mean you have to trust everything they create.  Special care should be paid to tasks that execute cmd.exe or powershell.exe and source the command inputs from untrusted files or network locations.

WMI Event Subscription for Persistence - WMI Event subscriptions should be logged and reviewed.  Of course, Windows might not provide you what you need natively, but Sysmon (from the Sysinternals Suite) can capture that information and save it as event log entries.  You still need to get those logs off of the endpoints and forwarded to a central location for processing, but with some tuning you can generate high-value signal for your SOC.  Sysmon has a few event IDs that apply to WMI:

• Event ID 19 - WmiEventFilter Activity Detected
• Event ID 20 - WmiEventConsumer Activity Detected
• Event ID 21 - WmiEventConsumerToFilter Activity Detected

Kerberoasting - Kerberoasting is a common attack technique leveraged by various malicious actors and pentesters to compromise domain service accounts. We will not cover the details of the technique or the depth of defenses against it, but will highlight an excellent starting point for organizations. We recommend that organizations begin their detection engineering of said technique by implementing a Kerberoast Honey Account, and follow Sean Metcalf’s guide Detecting Kerberoasting Activity Part 2 – Creating a Kerberoast Service Account Honeypot. For more details see Detecting Kerberoasting Activity.

PowerShell  - Like other threat actors who have found PowerShell to be useful, this threat uses PowerShell heavily to avoid having to bring a lot of additional malware along for the ride.  In addition to keeping artifacts off disk, PowerShell activity is frequently invisible to defenders.  Microsoft has added lots of logging capabilities to the last few major versions of PowerShell, leaving you to 1) enable the level of logging you want and 2) the forwarding of those relevant Windows Event logs to some central process point.  If you already do this for your Sysmon logs, then I have some great news for you - adding the relevant PowerShell logs to your forwarding configuration is going to be pretty easy!

Oh, and while we are on the subject, you should also remove PowerShell version 2 from your systems.  Its there for backwards compatibility, but honestly, you want to use the new hotness, not the old-and-busted, so let’s just remove it.  If you are unsure if a given Windows system still has PowerShell v2 installed, just open up a PowerShell or Cmd terminal and type “powershell.exe -version 2”, then “$PSVersionTable”.

If you see this:

Then you still have v2 installed.

If you see this:

Then you do not have PS v2 installed on the system, hooray!

There are several detection opportunities in this plan, but we will highlight a few that are commonly used procedures from different adversaries. It’s worth noting most detection points look for suspicious activity and will likely need to be tuned for your environment.

SIGMA Highlights

To leverage SIGMA rules you will need to convert the generic rules to your security stack with a converter. We recommend leveraging uncoder.io, pySigma, or the Sigmac Tool. Note that depending on how your data is tagged, you may have to implement data field mappings. SIGMA rules may generate too many results to alert on, but organizations can tune the rule to alert on anomalous instances or utilize aggregated data from the rule for hunting. For more information on SIGMA visit the SIGMA GitHub Page.

SIGMA  - Suspicious Scheduled Task Creation

The first SIGMA rule recommendation is Scheduled Task Creation. It is worth noting that tuning out common installations, accounts, or administrative activities may need to be conducted. This logic may not be suitable for all environments as an alert, but one can hunt for rare events that may be indicative of an adversary.

SIGMA - Suspicious Rundll32 Script Run

The second SIGMA rule that provides coverage is Suspicious Rundll32 Script in CommandLine. This rule looks for a command line that contains ‘rundll32’, ‘mshtml,RunHTMLApplication’, and ‘javascript:’ or ‘vbscript:’. This type of activity is not typical in most environments, though some organizations may have to tune out tools or scripts leveraged in their environment.

SIGMA - Suspicious WMI Execution

In the Suspicious WMI Execution SIGMA rule, the detection logic covers this procedure by looking for a process of wmic.exe that contains command line parameters of ‘process call create’. Depending on your organization this activity may be a rare occurrence, if tuning is needed it is recommended to look for common command line parameters or implement the search as a hunt.

SIGMA - Suspicious Procdump

The final detection point we’ll cover with SIGMA is the Suspicious Use of Procdump rule. The rule description states, “Detects suspicious uses of the SysInternals Procdump utility by using a special command line parameter ' -ma ' and ' -accepteula' in a single step. This way we're also able to catch cases in which the attacker has renamed the procdump executable.” This rule should have a high success rate with a low amount of false positives, if tuning is needed we recommend looking into common processes or accounts to tune out.

Conclusion

Supply chain attacks are just the latest in a long list of threat vectors that defenders have to worry about.  Building realistic attacker emulation campaigns lets you test how your security controls react to the threat vector by functionally testing them.  SCYTHE provides a tremendous capability to build realistic threats and execute them reliably in production.

As SCYTHE partners, our BlindSPOT tool allows you to seamlessly integrate SCYTHE payloads into the BlindSPOT simulation library.  The BlindSPOT agent implants allow you to execute any emulation campaign with a variety of execution methods, including process injection, all handled automatically by the BlindSPOT tool.  BlindSPOT then helps you identify how your security controls handled each action in the campaign, and identifies gaps in your detection and alerting capabilities.   BlindSPOT integrates with other reporting and workflow tools such as Plextrac to help you take action on the insight you gain through running these emulation campaigns.

BlindSPOT Campaign Report for UNC2452 Emulation

Ben Finke is a partner and director of Tactical Testing at OnDefend and also leads the development of the Blindspot platform.  Ben has over 17 years of experience in information security, starting as a Communications Officer in the United States Air Force and then on through multiple information security roles in different industries, including running a security practice for a managed services provider.  Ben is not only passionate about protecting his clients from a successful cyber-attack but enjoys sharing his knowledge with others.  As part of this, Ben speaks regularly at public and industry events and is a co-organizer of the B-Sides JAX information security conference.

This Threat Thursday post discusses active research by SCYTHE and other cited third parties into an ongoing threat. The information in this post should be considered preliminary and may be updated as research continues. This information is provided “as-is” without any warranty or condition of any kind, either express or implied.