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.
Among those, you can already see some of the bizarre taunting–
More importantly, in execution, the malware seems to lose control of concurrent threads creating hundreds of events in our consoles– super loud and ineffective as ransomware (Credit to Jim Walter for the dynamic analysis)
Btw, for folks looking to analyze the Go malware, we released AlphaGolang (a set of IDA plugins for v7.6 and under). The folder organizing feature was adopted by IDA v7.7 natively :) github.com/SentineLabs/Al…
Filenames to keep in mind from the Symantec blog. I have to admit that I find the idea of *independent* ransomware sample being used as a decoy or distraction from a wiper is counterintuitive but who knows.
Ok... so I've been looking to understand the concurrency here. I think there might be big mistake in the code (and one that happens to amateur Go programmers all the time). Concurrent threads are handled by sync WaitGroup that functions as a sort of mutex/counter for threads.
Usually, you wrangle those concurrent threads with an upperbound – max 8 threads or whatever.
In this case, 'partyTicket_len' which is determined by the wHiteHouse.GoodOffice1() function
It looks like they upper bound is dynamically determined and huge (an enumerated file count maybe?) and... they *never* call sync.WaitGroup.Done()! Because that lives in main.subscribeNewPartyMember()... and that's never called!
So that's my explanation for why this thing runs a bajillion threads. It's more effective as a local DoS of the system than a piece of ransomware...
Aaaaand seeing as our friends at @threatintel didn't name this one either... I'm gonna go with @TomHegel's suggestion that we call this PartyTicket!
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.
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.