It's been an interesting weekend! Eagle-eyed @TomHegel spotted what appears to be a new variant of AcidRain. Notably this sample was compiled for Linux x86 devices, we are calling it 'AcidPour'. Those of you that analyzed AcidRain will recognize some of the strings. Analysis 🧵
@TomHegel For context, AcidRain was a wiper component utilized during the infamous 'Viasat hack' that took down KA-SAT Surfbeam2 modems at the start of the Russian invasion of Ukraine. sentinelone.com/labs/acidrain-…
@TomHegel The original was an ELF binary compiled for MIPS. It acts as a generic and largely hamfisted wiper, iterating over common directories and device paths for most embedded linux distros.
@TomHegel Mad props to @maxpl0it for his analysis of AcidRain in a pinch/
@TomHegel @maxpl0it The new variant we are calling AcidPour is an ELF binary compiled for x86 (not MIPS) and while it refers to similar devices/strings, it's a largely different codebase. Doing our best to compare across different architectures, we are looking at a rough < 30% similarity.
For those inclined towards healthy skepticism, a few things to consider upfront:
-The initial similarities are strings that could easily be replicated by a different attacker.
-The sample was uploaded from Ukraine on 2024-03-16 14:42:53 UTC. We have no idea about actual target.
With that out of the way, the some of the additions are quite interesting, primarily the addition of ‘/dev/ubiXX’ -a reference to Unsorted Block Images (UBI) commonly used in embedded systems largely dealing with flash memory (IoT, networking devices, maybe some ICS).
Notice also the addition of '/dev/dm-XX', virtual block devices associated with LVM -- think RAID arrays.
And now you're caught up with me, we've entered "We'll do it live!" territory (in the tradition of our OALabs friends cc: @herrcore). This is where GaboRE and I light a candle to @RolfRolles and dive into the remaining analysis. Will keep livetweeting.
Following along at home?
6a8824048417abe156a16455b8e29170f8347312894fde2aabe644c4995d7728
On our end, the intended victim remains unidentified but we notified folks in UA on Saturday since we didn't know the possible spread of the operation.
Hmm.. dem IOCTLs doe...
AcidPour uses a similar IOCTL based wiping logic as VPNFilter 'dstr' plugin and AcidRain
Cute...
Don't read too much into it. It's standard Linux quirk
Wonder if ChatGPT is getting tired..
... but we are getting so close.
Analogous to AcidRain, there appears to be a different wiping logic for borking certain devices like /dev/dmXX (LVMs, likely RAIDs).
Heh, hi there.
Been nerding out and not updating..
All functions labeled, now digging into the nitty gritty of the malware logic.
Upon execution, it overwrites itself on disk with pseudo random data, followed by a polite 'Ok'
Inlined string formatting for those pesky XXs...
Venturing outside to hiss at the sun momentarily..
We are seeing reports this past week of disruption to Ukrainians ISPs. The involvement of AcidPour is unconfirmed but could fit the bill. 'Hacktivist' group taking credit for whatever that's worth ¯\_(ツ)_/¯
The CTI industry proved helpful, motivated, and altruistic during the Ukraine war. I see the same intent and enthusiasm building from the start of the Israeli-Hamas war but we need to be mindful of non-trivial differences that are misguiding ongoing coordination efforts— 🧵
The Ukraine war was special in two ways— Russia’s m.o. was one of announcing their attacks by virtue of regular use of wipers. We knew that the attacks had happened because a wiper would announce it. It was idiotic and shortsighted and it worked in our favor.
Ukraine’s approach to oncoming attacks was to embrace private industry and proactively feed it information— often
openly through CertUA— which allowed folks with analysis resources to contribute even if they weren’t privy to immediate visibility.
In an attempt to cut through the scarcity of candor these days, let’s state some things plainly. Let’s talk about Microsoft. With the upfront caveat that every security vendor has made mistakes and has skeletons in their respective closets that need addressing. None without sin.
Some sins are bigger than others, with ‘hyper’scale comes outsized responsibility, and passable sins of omission or corporate white lies (‘message massaging’) don’t hit the same coming from a mid vendor as they do from the owner and maintainer of *multiple* ecosystems.
The way Microsoft corporate has been acting for the past few years (SolarWinds, Hafnium, general JCDC collaboration, and now Storm-0588) is enraging, duplicitous, disappointing, counterproductive, and most importantly unnecessary.
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
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.