Ok, a delayed connecting flight is finally giving me some time to reflect on the madness of the past few days. Let’s talk about the #3CX software supply chain attack campaign we dubbed SmoothOperator. A brief recap of timeline and salient points…
First of all, let me say I’m shocked at how unfamiliar people are with Sade. You’re breaking @MigoKed’s heart as he continues to play with musical classics for campaign namings. (Looking at you @SecurePeacock :P )
This ‘balagan’ really begins w a series of behavioral detections, the mass of which start on March 22nd and get reported on 3CX’s support forums. As our detections ramp up, so do Palo Alto’s and Crowdstrike’s. There’s a lot of confusion in the forums, w some suggesting exclusions
For those unfamiliar w malware triage at scale, trojanized apps are a pain to figure out (particularly w a 100mb installer package), more so when the file comes from the legit source and is signed w their cert. in most cases, you’re dealing w a false positive and angry customers.
Even our early support struggled to figure this out in the first couple of days. UNTIL, @asaf_gilboa + David Acs latch onto this and realize we are dealing w a five alarm fire. Their early efforts enable us greater visibility and power to act as we figure out what’s happening.
I’m living my blissful existence having a cinnamon danish at @Lachmanina when folks start pinging about 3CX (shoutout to @likethecoins for always being on the ball). I thought there may be something fun… then looked at our support side and realized the planet was on fire.
Jumping on Asaf and David’s early analysis, we were able to latch onto the two most important pieces for early triage imo. The dedicated GitHub repo being used to signal C&C servers and the next-stage infostealer payload. Shoutout to @github for responding quickly—
The repo had a series of ICO files w appended encrypted data. Eventually, the brilliant @jaydinbas was able to decrypt that data to reveal the full URIs being used for C&C by the malware.
Thankfully, we had our hands on the infostealer early and @milenkowski joined the analysis efforts. @TomHegel and @spiderspiders_ went to town profiling associated infra and the spread of the trojanized software.
In 8-10 hours, we were able to produce something more or less comprehensive to provide guidance widely and hopefully support folks needing to do remediation. s1.ai/smoothoperator
On the Mac side, @philofishal got to analyzing Mac deployments on our end. @patrickwardle had confirmed that the MacOS installer too was trojanized but the next stage was missing. We could see the execution of something called UpdateAgent and a hash but it had self-deleted.
Someone was kind enough to share the sample w Patrick leading to the following analysis👇🏻
(Would love a copy of the sample too if a kind stranger would like to DM ;) )
We have also heard that @NickGalea3cx has hired the fine folks at Mandiant to conduct a proper DFIR and secure their build pipeline, good things to come there :)
W benefit of some sleep and some hindsight, I’ll say that I’m really grateful that @SentinelOne continue to invest into behavioral engines and dynamic detections. IMO, they’re the *only way* to deal w software supply chain attacks ITW. Many unsung heroes at all of our companies.
I also have to recognize that this isn’t the next ‘SolarWinds’… BECAUSE it was seen this early on. Had this gone on for another month or so, we’d be at a fullblown CCleaner- or SolarWinds-style broad enabler op (“Fishing with Dynamite”, as I like to call them)
That’s up to say, the attacker gets thousands of victims, collects everything they need for future compromises, profiles their haul, and decides how to maximize that access. Think— trojanizing CCleaner suspected of leading to @ASUS LiveUpdate compromise. securelist.com/operation-shad…
As always, I appreciate the sense of shared purpose, helpful-sharing, and relentless sleepless altruism that permeates this community. We all have our affiliations but what happens behind the scenes to help in these cases should give us all faith in humanity against bad odds.
Finally, the GOAT @silascutler has put a checker in place that compares public IPs with volunteer data sources to check for potential infection. It’s not 100% visibility but it’s enough to alert some folks who may otherwise not know they were infected, please amplify—
Last week, we conducted an experiment at @alperovitch— an intensive primer on Malware Analysis for non-technical students. Unlike beginner MA courses that give a light smattering of approachable tools and concepts, we’d walkthrough the analysis of a single sample end-to-end.
In order to keep myself intellectually honest, we plucked a malware sample I had never analyzed before– an Agent.BTZ sample– and started with initial triage -> light static analysis w HIEW -> deeper static analysis with IDA -> pinpoint debugging w x64dbg -> report writing.
We asked students to do an inordinate amount of prep for a weeklong course– reading a minimum 14 chapters of Sikorski's Practical Malware Analysis course, and a list of quick start references. And *surprisingly*, a majority of them did, making it possible to move quicker.
I've been rather glib in addressing this CN report on 'TAO' malware at Northwestern Polytechnical University in China. So what do we really learn from this?
I don't object on principal to covering these sample sets, having had the pleasure of extensively writing on them before with GReATs like @craiu. EQGRP in all of its forms is practically alien technology and we'd be remiss to ignore it. That said...
The 360 report is the latest in a series of bizarre overtures by CN companies (like 360 and Pangu Lab) highlighting old malware sets related to the NSA as if they're late breaking reprehensible incidents by the US, despite hitting what appear to be perfectly legitimate targets.
We've had 6 wipers in the wake of the Ukraine invasion but the biggest elephant in the room has been the infamous 'satellite modem hack'. Despite statements saying there was no malware involved, we believe it was the work of a 7th wiper– AcidRain
AcidRain is a 32-bit MIPS ELF wiper uploaded to VT from Italy on March 15th with the name 'ukrop'. It's a more generic wiper in that it attempts to bruteforce device file names and wipe any and all, and can be reused for a future op.
Interestingly, there are two wiping mechanisms. The first copies from an array of 4-byte integers starting at 0xffffffff, decrementing at each index.
A @KimZetter two-parter on Intrusion Truth and outing Chinese APT operators! Interesting to see open speculation and RUMINT around the industry codified alongside IntrusionTruth's own spokespeople. zetter.substack.com/p/unmasking-ch…
Beware whatever is happening with this bizarre op. Reporters from @business@motherboard and @TheRecord_Media received emails impersonating me and pointing to an 'Anonymous Liberland' / 'Pwn-Bar Hack Team' onion site. 🧵
You can read the email here. It's actually pretty funny.
Seriously debating changing my email signature to "Glory to Ukraine and Fuck Putin" at this point.
Looking at the site, the logistics of the op aren't very well thought out (assuming the intent is to push this Tetraedr leak) as the main leak is 150GB and the 'sample' is 955mbs, only downloadable via Tor. So see you in 10 days?
Day2, hopefully briefer and less hectic. Our friends at Symantec have published a great blog with way more detail about the attack chain and additional IOCs, including a decoy ransomware–
The 'ransomware' (4dc13bb83a16d4ff9865a51b3e4d24112327c526c1392e14d56f20d6f4eaf382) is written in Go and C and has some interesting quirks and taunting–
Despite a ton of standard Go functions (as is usually the case), all we really want to focus on are the main and Cgo functions.