It's awesome to see analysis of Lamberts and Equation Group tools. They're some of the most noteworthy findings in the short history of Cyber Threat Intelligence and we're doing a disservice by collectively ignoring their existence. Great work @runasand and @patrickwardle!
If you missed it, I'm sure the video will be up in the near future. In the meantime, here's Runa's blog on Green Lambert OS X objective-see.com/blog/blog_0x68…
For additional (non-MacOS) background, here's an overview of the color-coded constellation of the Lambert's toolkit up to a point– securelist.com/unraveling-the…
Since then additional flavors added to the rainbow include Gold, Orange, Purple, Violet, Silver...
Looking at this list I realize I should've called 'Tuxedo' Lambert (a blend of White Lambert code that drops Black Lambert) something more Skittles appropriate...
Another neat little tidbit, since we talking cross platform... GoldLambert is quite ancient but appears to have been originally coded for Unix and ported to Windows. It's also referenced in the Territorial Dispute driver_list.txt :)
While Im ranting on Lamberts, it’s easy to look at the timeline and assume that folks latched onto them because of Vault7. But the first sighting of a Lambert was a font exploit discovered by Fireeye in 2014 alongside Black Lambert—
They are one of my favorite threat actors. They’re incredibly hard to track, well-segmented, OPSEC obsessive, and always rewarding to the keen analyst. That’s not to say they haven’t made opsec mistakes in the past but that’s a minor blemish on a superb record.
• • •
Missing some Tweet in this thread? You can try to
force a refresh
There are three things you don't want to see made– laws, sausages, and threat intelligence.
Frankly, I'm bummed out at the framing of this issue. It adds fuel to the air-quote 'privacy' debate that keeps eating away at our ability to do security research, as in the case of GDPR.
I've played with Augury before. Netflow can be useful. But for the most part it's spotty, incomplete, and inconclusive. You don't turn into a SIGINT agency because you have visibility into a few hops along a path for a sliver of time. Internet routing doesn't work that way.
You're seeing points connecting to other points at a given time. If the connection is routed a different way, if it takes a hop you don't have access to, if any number of factors changes the connective tissue of the internet, you don't see anything.
When researching MeteorExpress, I couldn't have guessed the direction the discussion would take. Let's take a minute to evaluate these different claims– Indra, non-state-sponsored, MBC, SEA... (thread)
(1)Let's dispense with the patently brittle claims– just because a ransomware group claims they perpetrated an attack doesn't make a credibly claim... looking at you DarkTracer.
(2)Subsequent claims that it's related to SEA are using a reference so outdated as to be meaningless. Additionally, SEA was a pro-regime group so nothing about this adds up other than a vague Syria connection.
Alright, let's add some substance to this Pegasus discussion. Contrary to what you might read, research into NSO has been going on for years and has involved a lot of great research groups (@citizenlab, @kaspersky, @Lookout, to name a few). It has also included leaks.
Folks are speculating about how we might know about the targets of Pegasus customers. NSO simultaneously claims that they don't know their customers targets but at the same time they know that none of the @AmnestyTech infections are real. Two obviously incompatible statements.
Assuming NSO doesn't have access to their customers targets, a list of targets of interest would have to come from a structural fault in the agent/exploit delivery infrastructure that NSO uses. We have a high-level view of how that system is architected.
Please beware the false parity of 'experts'. Random technical ppl aren't sources on difficult threat intel topics. Open speculation isn't substantiation for denials ('More details plz'). And neither is technical solipsism ('Everything can be faked! I'd do better than this!').
This uncoordinated flailing is being used to substantiate state interests that would rather not have the spotlight shined on them. We'll all do well to display sound judgement.
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.
Unbelievable work by @AmnestyTech, done in spite of @Apple’s reticence to provide means to verify the integrity of iOS devices. What’s it going to take for Apple to stop burying its head in the sand?
These remarks on the limitations when inspecting iOS devices should give us pause… there’s a mistaken belief that privacy is protected by limiting checks on system integrity and correlation of anomalies. What privacy is protected in these cases? (@tim_cook@radian)
I love Apple products. Wonderful things are regularly done under the hood to increase the cost of attack. But it’s clearly not enough to tinker with security engineering alone. Plenty of unscrupulous actors are finding it affordable and we can’t even tell how big that iceberg is.