- Dailydave - mm4.emwd.com

Typey typey
by Dave Aitel 30 May '25

30 May '25

https://www.linkedin.com/mwlite/feed/posts/daveaitel_for-the-offensive-info… <https://www.linkedin.com/mwlite/feed/posts/daveaitel_for-the-offensive-info…> yRnO So I wanted to point this contracting gig out because I think it's a good opportunity for someone who can do quick vulnerability triage and either replicate or disprove that a vulnerability exists. Obviously you need to be very good at c and c++ and every other language to do this and have familiarity with vulnerability development....and also be located in the US , although you do not need a clearance. Dave

2 2

Announcing the Parity Release of Volatility 3 and the Deprecation of Volatility 2
by Andrew Case 16 May '25

16 May '25

The Volatility Team is very excited to announce the official Parity Release of Volatility 3! This release is not only capable of fully replacing all of Volatility 2’s features, but it also incorporates support for all the latest operating system versions plus all the latest memory forensics research. With this release, Volatility 2 is now deprecated, and its GitHub project has been archived. Our announcement blog post details the new features, many of the new plugins, and tells you how to get started with Volatility 3. https://volatilityfoundation.org/announcing-the-official-parity-release-of-… Our team is incredibly grateful for the continued support from our community, and we hope that you all enjoy Volatility 3 for many years to come. -- The Volatility Team

1 0

OpenAI Security Research
by Dave Aitel 28 Mar '25

28 Mar '25

So a few things: 1. https://openai.com/index/security-on-the-path-to-agi/ I feel like this blog is worth reading. :) 2. We're throwing a post-RSAC conference in SanFran to talk about AI and Security (in particular, securing cybery things with AI) and if I'm very lucky I'll even get to do a quick demo of the software I've been working on, not that it will surprise anyone on this list! We have a few tickets left I think and if you're interested and one of the people who should be attending I made you a form <https://docs.google.com/forms/d/e/1FAIpQLSe64yhyrTW7LYwY3qxOyOpaVqbrKgdZayq…> to fill out! Thanks, Dave Aitel

1 0

Cyber Reasoning Systems
by Dave Aitel 09 Mar '25

09 Mar '25

I continue to believe there are a lot of interesting questions around building cyber reasoning systems for vuln finding. Even the very basics seem hard to study and understand, and the eval datasets available are....sparse or incomplete. For example, what you really want if you're analyzing git repos is the commit a bug was introduced, and the commit it was fixed. But usually you get "a commit where it maybe existed". Likewise, it's an open question what kind of tools you can provide an LLM in this space and how it can best use them. Anyways, if you're building a cyber reasoning system for finding bugs, please spam me an email. -dave

2 1

on your child going to college in Christchurch, NZ and velvet worms
by Dave Aitel 11 Feb '25

11 Feb '25

*on your child going to college in Christchurch, NZ and velvet worms* By mid‑August the garden already practices absence — stems turning hollow, the robin leaving its notes hanging in the air like torn corners of a song. Under the chirp of palmetto bugs, a log eases itself back into earth. Inside, hidden from the light, a velvet worm does the impossible: offers herself to a spill of pale, blind threads. For days she is nothing but hunger turned outward, spinning glue not to hold but to feed, until their tiny jaws harden and, like rain, they slip back into moss, leaving her the damp and the slow work of being only herself again. It's a kind of mercy, this leaving — clean as the way geese carve open the sky, each V a blade that does not return. You pack your fragments — old Defcon badges, a frayed pentester lab shirt, dreams with edges I've never seen — into my old suitcase. On your dorm wall next to a shattered cathedral, you'll make a collage of faces, new maps where I am just blank space beyond the frame, like unexecuted shellcode left on the heap. The house darkens into its own bark. I wander its rooms like a soft thing without eyes, tasting the air for what I once held. There is a moment in every season when what clung must fall. Even the velvet worm stops spinning sweetness for a brood that has grown teeth, and the log swallows its secrets—the bacterial smell of old rain, the echo of digital footfalls we never learned how to trace.

1 0

(the root of the root and the bud of the bud)
by Dave Aitel 14 Jan '25

14 Jan '25

Memories and thoughts are the same thing, someone tried to explain to me recently. You have to think to remember, in other words. This is hard to grasp for a lot of people because they *think *they have *memories*. They wrongly think memory is a noun instead of a verb, which is ok in philosophy and psychology but in cutting edge computer science we have to be precise about these sorts of things. Twenty-five years ago, when I first started writing fuzzers, a full quarter century, people thought it was an absolutely stupid thing to do. The smart people were using their giant brains to do static analysis. They were tainting and sinking. They were reading the code and finding flaws. They did threat models. They did not write glorified for loops that made different amounts of A's go into different RPC functions. But I had the hubris of a teenage hacker, and I thought it was fun. More fun, perhaps, than reading code. In 2025, fuzzing is part of the software development lifecycle for any organization rich enough to call a hyperscale datacenter home. It is a *sine qua non* for secure software. Fuzzing, we now understand, is *reasoning*. And if you can't reason over your code, you can't secure it. Part of the value is that fuzzing echoes machine learning in that it scales nicely with the amount of CPU you could use. And there's no false positives when you measure whether an input crashes a program - it either does or it does not. There are downsides of course - many inputs may cause the same crash. Fuzzing identifies a flaw exists, but it doesn't tell you what the flaw actually is. And fuzzing often finds enough flaws that development teams become overwhelmed with triage. And of course, fuzzing can often be too dumb to reach the important bugs, since it is exploring the space of possible inputs semi-randomly, even with coverage guided analysis. We (as a community) tried to correct these things with SMT solvers, or smarter fuzzers. But now we have a new tool: LLMs, which reason in a very different way. But still they *reason*. Admittedly, there are many disbelievers. "LLMs just repeat what they are trained on" and taken to an extreme that's true but that's also true for any of us. In practice, they reason perfectly well. And not too long from now, maybe a couple years at most, any organization that is not using them widely for security engineering is left behind the curve - the same way teams not using fuzzers are today. Memories and thoughts are, in essence, the same thing because both require the act of reasoning. In computer science, fuzzing and LLMs are tools that embody this principle. They don't passively store knowledge - they actively explore, test, and refine it. When I first started fuzzing, it was dismissed as a foolish endeavor because it didn’t look like traditional reasoning. Now, it’s indispensable. LLMs are on a similar path: misunderstood by some, but already reshaping how we approach security. Just as fuzzing forced us to rethink what reasoning over code looks like, LLMs are forcing us to rethink reasoning itself. In both cases, the act - not the object - is what matters. They are the root of the root and the bud of the bud - the foundation of what comes next. And if you don’t carry this forward, you risk being left behind in a world that’s growing beyond you. -dave

5 4

Anthropological "Hacker" Map
by A K 13 Jan '25

13 Jan '25

Hi all, In the latest "Security Weekly" (https://www.youtube.com/watch?v=CXefYdEGW04 ) they present the Anthropological "Hacker" Map https://wherewarlocksstayuplate.com/map/ While the map is incomplete (how can it ever be complete?), I think it is one of the few times, outside of David Aitel's writings about the cross-cut between the "underground" (for a lack of a better term) and subsequent commercial activity. Based on my personal bubble, completely empirical evidence that you should take with a huge grain of salt the cross-cut is not the actual highlight here - the highlight is a temporal one. The generation of folks contained therein are the among the first two generations (or so) between the commoditization of Internet - essentially having first movers advantage on the space. Anyway, felt like sharing this with the rest of the community here

1 0

the endless stream
by Dave Aitel 31 Dec '24

31 Dec '24

I've seen great people in our industry crushed under the weight of the secrets they carry into a singularity from which no information can emerge. In some ways the lesson from apache_nosejob.c <https://www.exploit-db.com/exploits/21560> was that we cannot take ourselves seriously, that at the heart of our discipline there must remain a jester, that we must float upon the stream of endless information rather than absorb it into our darkened core. To that end I often listen to infosec podcasts while doing other things: 1. The Three Buddy Problem <https://securityconversations.com/podcast/security-conversations/> with Ryan Naraine, Costin Raiu and JAGs. This is probably my new favorite podcast, with an uncensored take on current infosec events, largely from an incident response standpoint, but in general covering all the bases and courageously offending everyone at great length. 2. Risky.Biz <https://risky.biz/RB775/>: Still excellent after all these years, partially because Adam is such an experienced penetration tester and Patrick is a good host, and I generally learn things about events that are poorly covered in the news from their perspective, without having to go through and do fact checking myself (aka, why the Struts bug is so bad, etc.) Also, happy New Year everyone! -dave

1 0

Hacking the Edges of Knowledge: LLMs, Vulnerabilities, and the Quest for Understanding
by Dave Aitel 02 Nov '24

02 Nov '24

[image: image.png] It's impossible not to notice that we live in an age of technological wonders, stretching back to the primitive hominids who dared to ask "Why?" but also continually accelerating and pulling everything apart while it does, in the exact same manner as the Universe at large. It is why all the hackers you know are invested so heavily in Deep Learning right now, as if someone got on a megaphone at Chaos Communication Camp and said "ACHTUNG. DID YOU KNOW THAT YOU CAN CALCULATE UNIVERSAL TRUTHS BACKWARDS ACROSS A MATRIX USING BASIC CALCULUS. VIELEN DANK UND AUF WIEDERSEHEN!". Hackers are nothing if not obsessed with the theoretical edges of computation, the way a 1939 Niels Bohr was obsessed with the boundary between physics and philosophy, and how to push that line as far as possible using math in such a way that you could find complementary pairs of truths lying about everywhere and of course one aspect of his work is that you can almost a century later deter an adversary from attacking you by threatening to end the world, and another aspect is you can study the stars and as a bureaucrat you would call this "dual-use" although governments tend to have a heck of a lot of use for the former and almost no use at all for the latter. All of which is to say that while NO HAT <http://nohat.it> is a very good conference, with a lot of great talks, the one I have enjoyed the most so far is "LLMs FOR VULNERABILITY DISCOVERY: FINDING 0DAYS AT SCALE WITH A CLICK OF A BUTTON <https://www.youtube.com/watch?v=Z5LMRS3AF1k>" (by Marcello Salvati and Dan McInerney). This talk goes over their lessons learned developing VulnHunter <https://github.com/protectai/vulnhuntr>, which finds real vulns in Python apps given just the source directory, and those lessons are roughly as follows: 1. Focus on Specific Tasks and Structured Outputs: LLMs can be unreliable when given open-ended or overly broad tasks. To mitigate hallucinations and ensure accurate results, it's crucial to provide highly specific instructions and enforce structured outputs. (aka, the naive metrics people are providing are probably not useful). 2. Manage Context Windows Effectively: While larger context windows are beneficial, strategically feeding code to the LLM in smaller, relevant chunks, like focusing on the call chain from user input to output, is key to maximizing efficiency and accuracy. They did a great job here, and this is important even if you have a huge context window to play with (aka, Gemini). 3. Leverage Existing Libraries for Code Parsing: Dynamically typed languages like Python present unique challenges for static analysis. Utilizing libraries like Jedi, which is designed for Python autocompletion, can significantly streamline the process of identifying and retrieving relevant code segments for the LLM. They recommend a rewrite here themselves using treesitter to look at C/C++, although I would probably personally have used an IDE plugin to handle Python (and give you debugger access). 4. Prompt Engineering is Essential: The way you structure prompts has a huge impact on the LLM's performance. Clear instructions, well-defined tasks, and even the use of XML tags for clarity can make a significant difference in the LLM's ability to find vulnerabilities. But of course, in my experience, the better your LLM (larger really), the less prompt engineering matters. And when you are testing against multiple LLMs you don't want to introduce prompt engineering as a variable. 5. Bypass Identification and Multi-Step Vulnerability Analysis: LLMs can be remarkably effective at identifying security bypass techniques and understanding complex, multi-step vulnerabilities that traditional static code analyzers might miss. There's a ton of work to be done in future analysis in how this happens and what the boundaries are. 6. Avoid Over-Reliance on Fine-Tuning and RAG: While seemingly promising, fine-tuning LLMs on vulnerability datasets can lead to oversensitivity and an abundance of false positives. Similarly, retrieval augmented generation (RAG) may not be sufficiently precise for pinpointing the specific code snippets required for comprehensive analysis. Knowing that everyone is having problems with these techniques actually is good because it goes against the common understanding of how you would build something like this. At its core, vulnerability discovery is as much about understanding as it is about finding flaws. To find a vulnerability, one has to unravel the code, decipher its intent, and even the assumptions of its creator. This process mirrors the deeper question of what it means to truly understand code—of seeing beyond syntax and function to grasp the logic, intention, and potential points of failure embedded within. Like Bohr’s exploration of complementary truths in physics, understanding code vulnerabilities requires seeing both what the code does and what it could do under different conditions. In this way, the act of discovering vulnerabilities is itself a study in comprehension, one that goes beyond detection to touch on the very nature of insight. -dave

1 0

Old Infosec Talks: Metlstorm's Take on Hacky Hacking
by Dave Aitel 31 Oct '24

31 Oct '24

The Anatomy of Compromise One of my demented hobbies is watching old infosec talks and then seeing how well they hold up to modern times. Recently I excavated Metlstorm's 2017 BSides Canberra <https://www.youtube.com/watch?v=OjgvP9UB9GI&list=TLGGvAY1CcIr-AcyNjEwMjAyNA> talk on "How people get hacked" - a pretty generic topic that gives a lot of room for opinion, and one a lot of people have opined on, but the talk itself has a lot of original things to say. In particular, there's a huge disconnect between how people get hacked and how defenders and policy makers think people get hacked and choose to defend against them - which anyone on this list already knows - I think we are all aware that defensive strategies in cyber are rarely based on available data. [image: image.png] The Three-Act Play of Compromise Here is how people get hacked, according to Metlstorm: 1. Find something with 1FA and crack it open (or just phish the creds) (Everything in "Secure By Design" is meant to address this part of the problem) 2. Get Domain Admin and hang onto it 3. Watch the person who does the important stuff (like SWIFT transfers) and secretly do their job for them Metlstorm goes into the Active Directory hacking that we all know and love in great detail. His toolbox from 2017 (Kerberoasting, Group Policy files, password spraying, etc.) is still largely relevant today, despite Dwizzle's best work - and points out that removing an attacker that has once had domain admin is practically impossible even though we all pretend it is to the SEC (a painful truth we don't deal with at all in industry, unless Wiz has a product line here I don't know about). But the pattern he's really describing is the understanding that individual vulnerabilities and Active Directory "features" are as relevant to systemic compromise as individual genes are to having an arm with five wiggly bits at the end. Metlstorm picks on Active Directory and its cousin Sharepoint quite a bit, but his point is not that we should blame Active Directory so much as ourselves - we all installed something huge and complex we didn't understand and then put the keys to our kingdoms in it. Partially he doesn't blame AD because Metlstorm, even before the SolarWinds and Kaseya compromises happened, was obsessed with supply chain weaknesses - or rather he clearly looks at it not as a supply chain but a supply web, where compromise propagates through trust relationships like signals through a neural network. And this is where Metlstorm's talk becomes particularly interesting in retrospect. While we were all obsessing over Domain Admin and Exchange bugs in 2017, he was pointing at MSPs and software providers saying "that's where the real action is." In the years since, we've seen exactly this pattern play out in increasingly sophisticated ways: - SolarWinds and Kaseya (2020-2021) showed us what happens when attackers compromise either a build pipeline or an MSP's distribution system - Recent MSSP breaches that none of us will ever hear about unless the GCSB decides to write them up Each of these compromises followed Metlstorm's basic thesis: why hack 1000 companies when you can hack the one company they all trust? The attackers don't see individual organizations - they see connection points, trust relationships, and privileged channels that can be repurposed. Seven years later, this view has proven devastatingly accurate. Metlstorm calls himself an "operational hacker" - different from your Brett Moore style "Research Hacker" who's all about finding bugs and writing shellcode and various useless stuff like that. For him, operational hacking is about systems thinking: what does each compromise actually get you? And this, as it turns out, is what the talk is really about. Digital Ecosystems [image: image.png] Using New Zealand as his laboratory, Metlstorm somewhat cheekily shows us organizations not as isolated entities but as nodes in a vast supply web: - Managed service providers spreading their digital mycelia through thousands of organizations - "Liz in accounts payable" unknowingly holding the keys to national security - Domain registrars running code old enough to be geological This is one of the strengths of the talk - it is backed up by specifics. It is not a vague thought-piece. He takes shots at the whole "I hunt sysadmins" approach as thinking too small! Why hunt sysadmins when you can hunt their managed service providers who already have domain admin? Or, hunt the providers of those providers. It's like a food web of sysadmins. His best examples are massive US companies (NYT, f.e.) that got owned through tiny companies in NZ- big for NZ standards maybe, but microscopic globally. The Observer Effect What Metlstorm as an attacker sees everywhere he looks is large systems that are "commercially untestable" - creating a fundamental disconnect between risk and reality. When you outsource your domain admin to a global megacorp (or your local Kiwi-buds), you create a quantum state of security - simultaneously compromised and secure until someone attempts to measure it. You: - Can't test their security - May not know if they're compromised - Certainly can't perform incident response - But get a lovely compliance certificate to frame Recent compromises prove what Metlstorm saw in 2017: while defenders obsess over hardening their membranes via the magic of secure by design (or paying "$6 a month for MFA"), attackers traverse the supply web and pick on whatever provider seems easiest to own. The reality is that no organization exists in isolation any more than a neuron functions alone. Your security isn't just your controls - it's every provider, vendor, and service in your supply web, each one a potential firing synapse of compromise. *Solutions* [image: image.png] He rightfully calls out that we will not solve these problems. So an A for Accuracy. Very fun talk, worth your time, highly recommended, 10/10 would listen to again in the car on the way to a house built at sea level in a hurricane zone. -dave

1 0

2025

2024

2023

2022

2021

2020

Dailydave