As to NSO’s blanket denial of having any access to how their customers use their software, that’s not entirely true by design —they manage the exploit delivery infrastructure for their clients. This is a hard-earned lesson from the HackingTeam days—
HT had a lot of woes attempting to idiotproof their payload building and exploit delivery process. The former was characterized by a prompt urging operators NOT to upload to VT (aimed primarily at dim Saudi operators). Exploits were handled more carefully via support portal—
The support portal required a backdoor created with the HT masternode and a lure document of the customer’s choosing. HT would create the exploit-laced file and host it via a one-time link that the operators could deliver in the method of their choosing.
NSO does something similar—they don’t leave their precious zero-click iOS exploits at the mercy of clients. They host the infrastructure for exploit delivery. That doesn’t entail access to the exfil stolen from victims but it’s certainly enough to identify intended targets.
If I had to guess, a list of numbers that includes actual victims as well as incompatible phones and targets that weren’t successfully infected would come from this infrastructure or whatever support portal was used to nominate infection targets.
• • •
Missing some Tweet in this thread? You can try to
force a refresh
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.