This blog nails some real problems with bringing AI into an organization in any industry, not just cybersecurity.
The article brings up a human training issue that I've been pondering a lot. What does it look like to train a new reverse engineer with AI tools available?
Capable attackers are still the threat, not the AI.
The defenses we've been preaching for years still work. Stop worrying about AI. Instead, change your default passwords and enable MFA.
2/2
"Claude hacks government" is as silly as saying "Metasploit hacked a hospital!"
Blaming AI shifts responsibility away from the humans who orchestrate it, and confuses defenders into thinking they're up against some vague AI supervillain.
AI hasn't changed the fundamental problem.
1/2
I had a great time on Jim's podcast discussing malware analysis, reverse engineering, working at Dragos, and a little bit of my personal history.
www.youtube.com/watc...
Afterwards, if you try to use remnux install, it will again break the vm tools inside the VM. I'm unsure the cause. I'm avoiding it for now.
3/3
Remnux docs say to run "remnux install" after loading into KVM to install spice and other tools. When I do that, the VM gets worse: cursor disappears, resolution gets jacked.
Instead, simply installing spice-vdagent using apt gets you dynamic resolution and copy-paste, and a nicer to use VM.
2/3
If you're trying to run Remnux on KVM by loading the OVA:
For network access: KVM changes the network adapter name, so change the config in /etc/netplan, replacing the old adapter (like enss0) with the new one and reboot. Use networkctl to find the non-loopback adapter name (like en1ps0)
1/3
Photo of smiling Jimmy holding a gold and red trophy in right hand. The top of the trophy is a gold statue of a king holding a sceptre. The king is standing on a red column, with a white base and a gold plaque.
Hand holding a trophy of king standing on a column. At the base of the column is the text: ‘MY NAME IS OZYMANDIAS, KING OF KINGS; LOOK ON MY WORKS, YE MIGHTY, AND DESPAIR
I earned my first CVE credit (CVE-2025-7676) for helping with a Windows ARM vuln. So, to commemorate the credit, my coworker, Reid, presented me last week with a Trophy of Perpetual Futility, because there’s always more work to do.
raw.githubusercontent.com/reidmefirst/...
The Dragos 2026 Year In Review Report is live: 3 new threat groups, updates from 3 of our more active threat groups, and (my personal favorite) coverage of a subset ICS-related capabilities that we found last year.
I've spent a lot of time reversing ICS malware. Recently, I've been building it with AI tools. While there's been plenty of commentary and news about AI and malware, I'm excited to share what I learned actually trying to build some at S4x26.
Stage 2, Feb 24, 12pm.
CERT.PL's report on the attacks against Polish infrastructure. A full destructive playbook enabled by default credentials: firmware corruption, wipers, factory resets, even booted Tiny Core Linux on KVM to DD-wipe servers. The report is excellent work.
I know I'm feeling stressed out when I go back to reading Thich Nhat Hahn. His teachings calm me, and I need that reminder that happiness is available in any moment despite circumstance. I'm not even Buddhist. or maybe I am? He'd probably say the distinction isn't important.
This is the first known attack on DERs. Attackers compromised RTUs at 30 different sites. The report has an overview, defensive guidance, and a comparison to past ELECTRUM ops.
Hats off to CERT Polska for leading the charge, and kudos to our Intel team for the hard work.
I spent a couple months arguing with Claude and Copilot while building FrostyGoop variants for DNP3 (and Modbus), keeping detailed notes on what worked and what didn't. At S4, I’ll share my honest assessment of these tools and how they might lower barriers to ICS malware dev. See you in Miami!
Finally sharing what’s been under wraps for months.
Adam Foster and I tore into HID SEOS to build the first open-source implementation for Proxmark3.
This is our Black Hat Asia 2025 story → www.youtube.com/watch?v=mnhG...
#RFIDHacking #SEOS #CyberSecurity
We have a job opening in our Community Defense Program (CDP) which gives small utilities free access to the Dragos Platform. This opening is a chance to do some truly meaningful work for the community.
Job Description: job-boards.greenhous...
CDP Description:
www.dragos.com/commu...
Had a great time presenting at LSU this week on hunting and analyzing Go and Python malware samples while hunting for ICS malware. For those who couldn't make it, you can catch a recording of this talk from Hou.Sec.Con last month with @sam-hans0n.bsky.social
www.youtube.com/watc...
Props to their Threat Research team for identifying and publicizing these harmful packages. If you want to understand what the code does, check out their post.
Bottom line: Always verify your dependencies and their sources!
socket.dev/blog/9-ma...
6/6
The evidence also doesn't rule out security research as an explanation.
I’d give this a low confidence assessment for malicious intent. That said, it's normal for analysts to reach different conclusions, and this isn't a criticism of Socket's solid technical analysis.
5/6
- The lure isn't convincing.
- The packages are unpopular (even by Socket's metrics), so infection of new projects seems improbable.
- Why would existing projects switch to the malicious dependencies?
- There's no C2 code to confirm victims. How would an attacker know if this worked?
4/6
While I agree the code is harmful and the packages are suspicious, I'm not convinced about the supply chain attack angle -- or if it is one, it’s not a particularly effective one. Several factors give me pause:
3/6
No legitimate projects were compromised, and no S7, Sharp7, or Siemens codebases were modified. Socket identified packages published by a separate user ("shanhai666") containing code that probabilistically kills host processes and causes database write failures within specific date ranges.
2/6
A lot of folks have reached out about Socket’s recent report on a supply chain attack using malicious NuGet packages to target Siemens S7 protocol and other PLCs.
This is not a supply chain attack in the traditional sense.
1/6
“No, that’s my neighbor, Bobby. I live at 502, but you have to write 501 on the package or the mail carrier brings it to the wrong house. He has a problem.”
ICS is fun. This blog covers the problem:
blog.softwaretoolbox.com/topserver-mo...
(H/T to Reid Wightman for inspiring this post)
(2/2)
Learning Modbus is basically this conversation:
“I live at 502 Westport Ave.”
“Sweet, I’m sending you a package.”
“Wait! If you talk to the mail carrier, my address is 501 Westport Ave.”
“Oh. So, you live at 501 Westport?”
(1/2)
Other questions I'm exploring:
How much does AI know about ICS protocols?
Does AI truly lower the barrier for entry? If not, is that an AI limitation or am I just "holding it wrong"?
Is it shortening my development time? Or solving some problems but creating new ones for a net-zero benefit?
2/2
I'm speaking at S4x26 on creating a FrostyGoop-style tool using AI. This experiment has been a good avenue for tackling a few questions I've had about AI-enabled software development. Most importantly, just how easy is it?
I'm excited to share what I learn come February!
1/2
MinusOne, a deobfuscation engine for scripting languages: github.com/airbus-ce...
EPIC Erebus for PCIe and DMA attack research: www.crowdsupply.com/...
3/3
Here are a few of the projects I enjoyed learning about this time around:
Thorium Malware Pipeline: github.com/cisagov/t...
CTADL Static Taint Analysis Tool: github.com/sandialab...
2/3
