SOC Goulash: Weekend-Wrap Up (Part 1)

22/08/2022 - 28/08/2022

This is Part 1 of the Weekend Wrap-Up, detailing significant Threat Actor Activity and noteworthy TTP changes to be aware of.

Part 2 will cover significant vulnerabilities from the past week, in addition to the latest tools & techniques for offense and defence alike, and some additional reporting that you might find relevant and useful.

Headline Items

1. The true scope of impact of the SMS Phishing campaign targeting Twilio continues to grow, highlighting supply chain risks and the fragility of relying on token-based MFA to secure authentication;

2. APT29 reveal MagicWeb - a “skeleton key-like” backdoor in AD FS, deployed in a last-ditch effort to maintain persistence as remediation and containment efforts commenced to evict them from the network;

3. A series of “risks” in Okta, one of which could allow child domains to gain super admin privileges in their parent - sure sounds like a vulnerability, doesn’t it?

0ktapus - putting a name to the Twilio compromise…and more

References: Group-IB | Okta | Tech Crunch

Remember the Twilio compromise we covered two weeks ago? Well, recent reporting has revealed that this sophisticated SMS-based Credential Harvesting campaign was actually much more wide-spread than first thought, and used to facilitate supply chain attacks on downstream providers.

Impact - Initial & Secondary Attacks

Group-IB have dubbed the campaign “0ktapus” - as it targeted customers of the identity provider Okta - and identified nearly 10,000 compromised credentials and 5,441 MFA codes stolen from victims around the world, with the majority located in the USA. Most of the impacted companies were IT, software development or cloud service providers.

Significantly, Group-IB found that three organisations compromised in the 0ktapus campaign either enabled or could have enabled secondary attacks:

1. Personal information relating to cryptocurrency accounts managed by marketing firm Klaviyo were stolen, and could have enabled the theft of cryptocurrency;

2. The attacker’s compromise of Mailchimp would have enabled them to manipulate password resets and email alerts for downstream customers such as Digital Ocean, thereby enabling potential onward compromise of additional victim networks;

3. The compromise of Twilio enabled the attacker to attempt to hijack Signal accounts by re-registering them to new mobile devices.

Okta’s analysis also revealed the actor - which they track as “Scatter Swine” - sought to expand their access once they compromised Twilio, triggering SMS-based MFA challenges and using Twilio systems to search for those codes.

Figure 1: A breakdown of known impacted organisations

The above examples are a sobering example of supply-chain risk. The range of immediate and indirect impact that can be incurred by a simple SMS phishing campaign is considerable, with the potential for cryptocurrency or account theft, and even onward compromise of downstream customers.

The keys to the efficacy of this campaign were the convincing lookalike login pages, use of Callback Phishing, and real-time relay of MFA material to the target authentication service. A combination of compensating controls (e.g. Staff/user education) and mitigating controls (e.g. Physical FIDO tokens, Conditional Access policies) will go a long way towards minimising the risk posed by this growing attack vector.

APT29/NOBELIUM deploys skeleton key in AD FS

Reference: Microsoft

Microsoft have released a detailed technical analysis of MagicWeb - a novel persistence technique targeting AD FS - which they discovered being deployed by APT29 (NOBELIUM) as a hail-Mary persistence attempt when the actor believed it was about to be evicted from the network.

The persistence is achieved through using DLL hijacking to inject a malicious DLL into the AD FS process, which looks for a specific value within the user certificate passed by the attacker when authenticating. When found, it bypasses all AD FS checks - including MFA - and grants the attacker network access.

Technical Breakdown

It’s worth noting that a prerequisite to this attack is that the actor must have already acquired highly privileged access within the environment and have a foothold on an AD FS server. That makes this a very late-game persistence method, and one you would’ve hopefully avoided by picking up activities earlier in the intrusion Kill Chain.

The attacker can implement this backdoor by:

1. Replacing the legitimate Microsoft.IdentityServer.Diagnostics.dll file used by the AD FS service with a backdoored version;

2. Editing C:\Windows\AD FS\Microsoft.IdentityServer.Servicehost.exe.config, specifying a different “public token” value that points to the malicious DLL.

Because Microsoft.IdentityServer.Diagnostics.dll is loaded into the AD FS process at startup to provide debugging capabilities, this presents the attacker with a reliable DLL Hijacking opportunity to exploit.

The backdoor is triggered when a user authenticates to AD FS with a crafted user certificate that contains an attacker-specified “magic” Object Identifier (OID) value within the certificate Enhanced Key Usage (EKU) field. The MagicWeb backdoor - which is injected into the AD FS process - is configured to look for this value being passed. When encountered, the backdoor will bypass all AD FS processes (including MFA checks) and validates their authentication attempt to provide access to the network.

Mitigations, Detections, and Hunts

Microsoft has provided detailed guidance on how to protect against and respond to this threat on your network.

1. Enabling AD FS verbose logging and security auditing in order to generate and monitor Event ID 501, which can highlight anomalous EKU values being passed to the server;

2. Include the Global Assembly Cache (GAC) in periodic audits, as that’s where the malicious dll would be stored;

3. Look for unsigned files in the GAC - keep in mind the legitimate DLL is catalog signed, meaning it may appear unsigned in the file properties pane and to some tools. If you can’t work around this, long-tail analysis of hash values to identify outliers may be the next best approach.

Some other (untested) suggestions I’d make based on Microsoft’s write-up:

1. Look for file write events to the GAC - there may be no/few legitimate instances of this in a standard SOE;

2. Look at file open/write events for the ADFS config file, as the attacker will have to modify the “public token” value to point to their DLL.

3. Look for a file write event where the original name is Microsoft.IdentityServer.Diagnostics.dll - that might catch the attacker renaming the original file or placing their new one. A file delete event for the file might also surface the attacker removing the legitimate dll before placing their malicious one.

4. Certificates with unknown EKU values will have the value flagged with “Unknown Key Usage” when inspected manually - it’s possible this value presents somewhere in logs, but requires testing to confirm.

IcedID campaigns vary delivery methods

References: @pr0xylife | @Max_Mal

IcedID distributors have again changed up their TTPs, with two distinct IcedID delivery chains being observed this past week - one using the zip > iso > lnk mechanism, and another that used an rtf maldoc to deliver the payload.

Campaign #1

1. The campaign begins with delivery of a password-protected zip archive containing an iso. This contains <file>.png.lnk and <decoy_image>.png;

2. Execution of the .lnk will first open the decoy png image using start.exe;

3. Curl is then invoked to download the .dll payload, executing it with rundll32 at ordinal #1.

The key takeaways:

1. The use of a decoy image - which is a page from a finance-related document - to give the user the impression they opened the expected attachment, while the payload is downloaded and run in the background; and

2. The use of carets to obfuscate the command line - these are ignored when run, but will bypass simple string-based detections.

Campaign #2

1. VBA macros embedded in a rtf maldoc provide initial code execution;

2. This drops two files:

   1. [a-zA-Z]{2}\d{3}.tmp.exe - a renamed copy of rundll32.exe;

   2. [a-zA-Z]{2}\d{3}.tmp.dll - the IcedID payload;

3. The renamed executable is used to execute the IcedID dll at ordinal #1.

The key takeaways:

1. VBA Macros and rtf payloads are still being used - just less frequently;

2. The use of a BYO binary to obfuscate the use of rundll32.exe;

3. Despite the dropped instance of rundll32.exe being renamed, the spawned child process that executes the dll still appears with the original filename.

Figure 2: The renamed rundll32.exe binary still spawns with the original file name

NetSupport RAT Campaign Summary

References: @SecurityAura | @ankit_anubhav

@SecurityAura has shared a neat summary of a recent campaign distributing the NetSupport RAT - a legitimate remote access tool abused by cyber crims - spanning from August 9 past August 18.

Key Campaign Details:

1. Emails (hijacked email threads) contain Google Drive/Dropbox links to download zip payloads

2. Unzip archive with password. Executing the .lnk runs an obfuscated .ps1 script that downloads and runs the NetSupport .exe

The tricky part is the PowerShell, which uses aliases to obfuscate its intention:

Figure 3: An example of the PowerShell download cradle

If you’re looking to run a quick simulation to test your detections, @ankit_anubhav has provided a handy PoC that’ll emulate the execution chain from the initial payload invocation through to the PowerShell download cradle.