Det. Eng. Weekly #54 - I hacked the SEC Twitter 🐦
Det. Eng. Weekly #54 - I hacked the SEC Twitter 🐦
..and all I tweeted was a lousy crypto scam
Welcome to Issue #54 of Detection Engineering Weekly!
This week’s recap:
💎 by Amitai Cohen on applying lessons from intelligence failure to threat detection
Andy Giron drops some knowledge on chat-app based C2s, Ironpeak publishes a clever way to use canaries to detect AitM in Azure, Matt Kiely wades through gallons of M365 logs to find account takeover nuggets, Alex Teixeira on time-based gotchas in threat detection, and Allan Liska says maybe we shouldn’t trust criminals!
Risky Biz podcast with an interesting chat with Nuclei, two talks from Shmoocon by Katie Nickels and Andy Piazza
Simone Krause summarizes an Ivanti disclosure by CERT-Bund and provides detection opportunities, reblog drops several Bluetooth vulns (also at Shmoocon), Alex Delamotte unearths a naughtily-named SaaS attack bot called F-Bot and Censys deep dives the latest Juniper vulnerability
plus so much more!
⏪ Did you miss the previous issues? I'm sure you wouldn't, but JUST in case:
💎 Detection Engineering Gem 💎
Intelligence Failure in Threat Detection by Amitai Cohen
“The solution to [..] dissonance begins with self-reflection and must culminate in some sort of compensation, as mentioned above.”
This is such an excellent quote! This piece by Cohen revolves around looking at intrusions via a lens of branching timelines. A branching timeline, first explored by Chris Sanders in forensics analysis, allows defenders to look at the "space" of some observed event and the time it took place. This can get super hairy and hard to do as you zoom out from a forensic analysis timeline into the world of possibilities of detection engineering.
I love the section dubbed "The tradeoffs of time travel". As you look at potential branching paths of threat detection in the past or future, you experience tradeoffs between false positives and false negatives.
So Amitai offers some advice to readers on managing this since there can be several hundred combinations of attack paths per technique, as Atkinson shows in his call graph piece for detection: find the bottlenecks. Suppose you can zero in on telemetry and detection opportunities that can only be achieved by a finite set of events. In that case, you can start expanding forward and backward in other places to detect threats. This should help with your prioritization strategy for the detection backlog.
🔬 State of the Art
From IRC to Instant Messaging: The Rise of Malware Communication via Chat Platforms by Andy Giron
Note: Andy is my colleague at Datadog 😃
I remember the first time I saw a spam botnet in action. I'm going to age myself here - but I was playing Counter-Strike 1.6 in the 2000s and looking for others to play pick-up games on IRC. There were 100s of players all over the U.S. looking for games, but then tens to hundreds of random people joined the channel and spammed all kinds of naughty things. It slowed everything down to a halt on the server, and I couldn't talk to anyone.
Almost 20 years later, chat apps are still part of Internet culture. Due to the consolidation of these "Chatrooms" on a single app, malware authors use API capabilities to do the same botnet activity I saw years ago. Still, this time, the impact is much higher. Andy explores this change in the TTPs of malware authors and provides detection opportunities for those looking to find this in their infrastructure.
Detecting AiTM attacks in Azure by Ironpeak
This post covers a clever way of using canary triggers via Referer headers to detect phishing on your Azure identity tenant. By recording Referer headers with a custom pixel image on your login page, you can see when victims access a phishing page that cloned your company login page on Azure. Security through obscurity works if you use it against the baddies!
Combating Emerging Microsoft 365 Tradecraft: Initial Access by Matt Kiely
I wish I could say I've claimed the adage: "Technical threat intelligence should be a data point, not a decision." I say it all the time. Maybe I'll attribute random U.S. presidents and see who catches on?
In this blog, Kiely shows how the Huntress team built a successful integration with a unique threat intelligence provider, Spur (they do so much more, but in this case, it's a correct application of a term). It's a great intersection of how statistics and detection engineering go hand-in-hand. By enriching login I.P. events with super detailed data from Spur, the team can start to baseline benign events and pick out outliers while anchoring to the technical threat intel.
This gets especially interesting when you are sifting through IPs that come from VPNs and how you can pivot on the VPN provider to see how naughty or nice it's been with other events and make an alerting decision there.
Under the Radar: Your Detections are missing logs — every single run by Alex Teixeira
Speaking of time and space (Cohen's gem from above), this blog by Teixeira looks into how time is so critical from a technical standpoint. It clarifies that detection should consider the time window to look for activity and how frequently it has happened.
This gets especially painful when you consider devices across timezones, parsing errors of time fields, or straight up "the wrong time" if a naughty device isn't connecting to an NTP server. I like the prescriptive guidance to focus on index time for searching: you can rebuild a forensic timeline if you find an incident.
The Problem with Relying on Criminals for Data by Allan Liska
Whenever I describe detection engineering to a "normal" person, I describe a world where security engineers work on a plane avionics system and help detect weird things happening, such as altitude, temperature, pressure, pitch, and yaw. The only caveat I add is that you are flying through a weather system where malicious actors control a weather machine and try to mess with you.
IMHO, this is a considerable bias in cybersecurity reporting and threat intel firms. Reporting on what people say or write versus what is happening can render HUGE gaps from what we perceive to reality. Case in point: in this post, Liska points out how unreliable ransomware shame site reporting is and how they are incentivized to lie even as they attempt to extort real victims with actual data. Did you know criminals lie? zomg!
🎙️ Detection Engineering Podcasts
Great to have the Risky Biz crew back in action! Lots of news to go over in the last month, which is a holiday for myself and many others. My favorite part in the last few weeks is, of course, the SEC Twitter “hack”.
This should link to the 4:00:11 mark on the video, but there were some great talks at Shmoocon over the weekend. This one by Katie Nickels talks about how we tend to panic when an emerging vulnerability “drops” on our heads. Katie gives some good insight on orgs should do (and not do) when this happens.
Another great intel talk at Shmoocon, this time by Andy Piazza, on intel fallacies. He opens up on some pet peeves of mine (so I guess I’m cool like Piazza), such as describing “targeted” attacks in intel reporting. Without HUMINT, how do you know they are targeted?!
☣️ Threat Landscape
Ivanti — Zero Day Vulnerabilities, BSI Translation and Technical Deep Analysis by Simone Kraus
Why are VPN appliances always getting these kinds of vulnerabilities? Kraus greatly favors the community by translating and summarizing the latest N-day on Ivanti devices released by CERT-Bund. Several threat actors have leveraged two vulnerabilities to bypass authentication and perform command injection to gain unauthorized access to Ivanti devices.
Hi, My Name is Keyboard by reblog
Lots of Bluetooth vulns dropped at Shmoocon this past weekend! This README showcases several CVEs on Bluetooth keyboards across operating systems where you can do some pretty funny hijacking of a user's keyboard or force pairing a keyboard for additional shenanigans.
Did anyone else get weird Bluetooth advertisements at Shmoocon? I had some being pushed Saturday night..
Exploit for under-siege SharePoint vuln reportedly in hands of ransomware crew by Connor Jones
According to Kevin Beaumont, threat actors allegedly have a working PoC for a Sharepoint exploit chain disclosed in 2023. CVE-2023-20357, an elevation of privilege vulnerability, was showcased at Pwn2Own and subsequently published as a PoC on GitHub. According to the researchers, a total SharePoint takeover can happen if combined with a separate vulnerability (CVE-2023-24955). The scary part: Beaumont said to "get ready" for exploitation in the coming weeks.
Exploring FBot | Python-Based Malware Targeting Cloud and Payment Services by Alex Delamotte
I was hoping Alex would put the FULL name of the bot inside the title, but that's because I am a child. You can see the full name in the initial screenshot at the top.
Cybercriminals share more automated scripts to fingerprint, attack, and pivot through production environments, web servers, and cloud service providers. In this particular case, FBot is designed to hit web servers hosting vulnerable Laravel and CMS software, as well as used to gain a foothold in SaaS environments for additional access.
CVE-2024-21591 – Juniper J-Web OOB Write vulnerability by The Censys Research Team
What’s a great way to start 2024? A pre-auth RCE in several thousand exposed Juniper devices! Glad to see the Censys team provide data for the masses on the exposure of network device vulnerabilities like this one.
🔗 Open Source
hi_my_name_is_keyboard by marcnewlin
GitHub repo for PoCs on the Bluetooth hijacking vulnerabilities listed above.
top4grep by Kyle-Kyle
Nifty tool for “grepping” research paper names in Top 4 research paper databases. You can search academic papers on the command line!
TeleTracker by tsale
Did you come across a Telegram bot API key from an investigation? Especially after you read the Datadog post above on how botnets use Telegram for C2? Look no further! TeleTracker allows you to investigate these "malicious" dropper bots and glean additional data for attacker intelligence.
CanaryTokenScanner by 0xNslabs
Red teamers are fighting back! In last week’s issue, I linked a repository that specializes in identifying honeypots to help reduce time wasted from looking at potentially vulnerable infrastructure. Canaries seem to be the next logical step: build tools to detect canaries, make canaries better in response, and hopefully (real) attackers don’t change.
KEV by Ostorlab
Automated scanner for CISA’s KEV dataset. Pip install then run it against a target server or subnet and get Nuclei-esque results. Uses several backends including: Nuclei, Tsunami, Nmap, Asteroid and Metasploit. Not all KEVs are in - some require user interaction or local access, so mostly focuses on RCEs.