SOC Goulash: Weekend Wrap-Up (Part 1)
14/08/2022
It’s been a big week with a number of noteworthy incidents, vulnerabilities, and tooling updates, so I’ve had to split this wrap-up into two!
Part 1 will focus on Threat Actor activity & TTP changes, with vulnerabilities, techniques & tools, and the other good stuff rolled into Part 2.
Headline Items
An ongoing attack on Cisco stemmed from an employees browser-saved creds being nicked, and a combination of Vishing and MFA fatigue attacks being used to coerce MFA being supplied. How prepared are you to detect and defend against this?
A widespread SMS Credential Harvesting campaign resulted in the breach of Twilio, highlighting the rise of Attacker-in-the-Middle attacks that can seamlessly bypass TOTP MFA, which is standard for the majority of MFA implementations. Time to reconsider FIDO security keys, at least for admins, perhaps?
IcedID were observed briefly experimenting with CHM files for payload execution. One to watch in this exciting post-Macro world - details and detection ideas are below.
Cisco breach enabled by stolen browser-saved creds and MFA coercion
References: Cisco
Cisco have released a detailed incident report into their ongoing response to a network breach, in which the attacker was able to pivot from an initial foothold on Cisco’s corporate VPN to compromise their domain controllers and dump their Active Directory database. Despite their level of access, Cisco report that the actor was only able to exfiltrate some (2.8GB, based on the listing on Yanluowang’s leak site) non-sensitive content from the network before they were ultimately evicted.
What makes this intrusion particularly interesting is:
Initial access was possible because the attacker “gained control of a personal Google account where credentials [including their Cisco credentials] saved in the victim’s browser were being synchronized”;
The attacker tried both voice phishing (vishing) and spamming the employee with MFA requests (MFA fatigue) to coerce them into accepting the MFA prompts for their account;
The use of several persistence and access mechanism, including:
Initial access via the Cisco VPN, followed by Citrix & RDP to move around the environment;
Image File Execution Options (IFEO) injection for persistence - not something you see too often;
Remote access tools such as TeamViewer & LogMeIn;
A simple custom backdoor.
Cisco attribute this intrusion with moderate to high confidence to an IAB with ties to both UNC2447 and Lapsus$. UNC2447 are a financially-motivated actor observed operating a variety of ransomware families and employing “double extorsion” to leverage victims into paying ransom demands. Lapsus$ made a name for themselves in March this year with a string of hacks against several industry heavyweights including Okta, Microsoft, and NVIDIA.
The two main takeaways from this intrusion effectively boil down to the human element - not quite PEBKAC, but still something you can’t fully mitigate through technical controls alone.
Offering a corporately supported password manager is a good step to prevent use of browsers for storing passwords, but that may prove too cumbersome to users who often tend to take the path of least resistance. Sure, you could disable browser password saving via GPO, but what if they’re using a BYO device? As always, your mileage may vary on how much you’re able/allowed to mitigate this in your organisation, and where mitigation fails, you need to deploy and keep on top of detections.
Vishing takes place beyond the boundaries of network controls and SOC oversight, which is why it’s such a great vector for attackers. In this case, user education and implementing clear and well-known processes for interacting with legitimate IT staff are your best bets in preventing this from being successful. In terms of detection? I’d suggest looking for an inordinate number of MFA requests (catches MFA fatigue attempts) and anomalous logins by IP location, user agent, or originating application to surface potential instances of Vishing.
Twilio compromise highlights limitations of TOTP MFA
References: Bleeping Computer | Twilio | Cloudflare
Cloud communications vendor Twilio reported on August 8th that they had been compromised by way of an SMS Credential Harvesting campaign conducted against their employees. They have so far reported that the data of 125 customers were accessed as a result of the breach.
Security researchers on Twitter did some digging and identified several related phishing domains, with their naming convention suggesting the campaign was more widespread and targeting customers of Identity provider Okta, using lures purporting to be SSO or Okta credential resets.
Cloudflare - another Okta customer - confirmed in a separate blog post that their employees had also been targeted as part of this campaign, and that the phishing page conducted a real-time relay of the victim credentials and subsequent Time-based One Time Password (TOTP) code to the legitimate login page. Simply put, this is an MFA bypass technique for environments where the second authentication factor is a code which is either sent to the user via email/SMS, or generated in an App like Google Authenticator.
While some users were conned into entering their credentials, the attackers weren’t able to abuse their credentials as Cloudflare employees use physical FIDO2-compliant security keys (e.g. Yubikeys) as their secondary authentication factor.
Somewhat ironically, Okta released this article just one day after Twilio’s breach disclosure, warning of the potential for attackers to bypass MFA protections by stealing session cookies or performing Attacker-in-the-Middle (AitM) attacks that relay credentials and MFA - as was the case in this campaign.
That’s not to say they don’t know what they’re talking about though - the sections on defence & detection of these MFA bypass techniques are genuinely useful, and anyone using Okta as an Identity provider should review these to ensure they’re not caught out.
It’s worth noting that AitM campaigns aren’t all that new, with Microsoft highlighting last month that over 10,000 organisations were the subject of such attacks since September 2021, and zScaler reporting on a campaign from June that targeted organisations “in the FinTech, Lending, Finance, Insurance, Accounting, Energy and Federal Credit Union industries”, with the majority located in the US, UK, New Zealand, and Australia.
For Defenders: Monitor for generic alerts on Impossible Travel, attempted breaches of Conditional Access Policies (geographic, out-of-hours, etc.), and potentially anomalous User Agent strings (e.g. curl, Python) and initiating Applications (e.g. PowerShell, Exchange Online Powershell). I’d also recommend looking into detecting Azure Password Refresh Token theft if you use Azure AD as an Identity provider.
For Identity Admins: TOTP-based MFA is still worth implementing - it’ll thwart basic credential relay/harvesting attacks, and is another hoop for both the attacker to set up and user to jump through. While not easy to roll-out, physical FIDO keys take it one step further and will save your bacon when it comes to AitM attacks, as attackers might be able to steal a randomly generated code, but not so much a physical security key that the user holds.
Failing that, Rachel Tobac also makes the great point that credential managers will fill passwords where the domain/site is recognised, potentially preventing them from being entered into typo-squatted or lookalike phishing sites. If you’re not using one, this may be an easier solution to introduce to your enterprise.
IcedID explores CHM invocation for payloads
Reference: Malware Bazaar | Unit 42 | Unit 42
Security researcher Ankit Anubhav identified an IcedID sample on the August 10 that used Microsoft CHM help files to execute its malicious dll payload.
In terms of process hierarchy, Microsoft’s HTML Help Executable (hh.exe) will load the chm first - the chm file contains html code that invokes cmd to launch mshta.exe to execute the malicious Javascript appended to the end of the chm file. The Javascript launches rundll32, executing the dropped dll payload.
While an interesting deviation from the ever-popular ISO > LNK > DLL execution chain we’ve seen since Microsoft committed to blocking Macros by default, the simplest detection opportunity once again lies in anomalous process hierarchies and file locations. This Sigma rule might be a good place to start.
Palo Alto’s Unit 42 identified an earlier sample that also abused CHM files for payload execution, though this one made it through to the download of a secondary payload and ended in Cobalt Strike being delivered. IOCs, infection pcap, and the malware and artifacts of said sample can all be found here.
Unfortunately this change in TTPs appears either short-lived or to have been a trial run, with Unit 42 picking up a sample two days later that reverted to using a lnk > bat > js > dll execution chain.
While it doesn’t appear to have stuck this time, it’s one to keep an eye out for going forwards as attackers look for novel ways to skirt detections in this post-macro world.