Jimmy Wylie

ZionSiphon is an AI-generated, non-functional attempt at ICS malware. Malicious intent doesn't imply ability, and broken malware like this is a distraction when we have proven threats like VOLTZITE/Volt Typhoon out there hitting water utilities.:

https://www.dragos.com/blog/zionsiphon-ot-malware-analysis

#ICS #malware

I earned my first CVE credit (CVE-2025-7676) for helping with a Windows ARM vuln. So, to commemorate the credit, @reverseics@infosec.exchange presented me last week with a Trophy of Perpetual Futility, because there’s always more work to do.

https://raw.githubusercontent.com/reidmefirst/vuln-disclosure/refs/heads/main/2025-04.txt

TIL FLARE distributes educational content for free on GitHub.

https://github.com/mandiant/flare-learning-hub

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?

https://www.sentinelone.com/blog/the-implementation-blind-spot-why-organizations-are-confusing-temporary-friction-with-permanent-safety/

Folks are giving AI way too much credit.
"AI wins CTF"
"Claude hacks government"

Sound as silly as saying:
"Metasploit hacked a hospital!"
or "Hammer builds a house!"

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. Capable attackers are still the threat, not AI. Stop worrying about AI. Instead, change your default passwords and enable MFA

Ironically, S4 dropped my talk on vibe coding ICS malware on the same day that non-functional AI-slop OT "malware" is making headlines. It’s hype “malware” distracting us from real threats.

More to say, but it's Friday :) In the meantime, I hope you enjoy the talk.

https://www.youtube.com/watch?v=v0grXXc5zgw

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 coordinated attacks against Polish infrastructure. Adversaries used all manner of destructive techniques: firmware corruption, wipers, SSH commands, FTP deletes, factory resets, even booted Tiny Core Linux on KVM to DD-wipe servers.

They targeted a grid connection point, CHP plant, and a manufacturing site. The forensic reconstruction and malware analysis is excellent. Worth a read for the technical depth.

https://cert.pl/en/posts/2026/01/incident-report-energy-sector-2025/

#ICS #OTSecurity

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.

https://hubs.la/Q040Bwpg0

#ICS #otsecurity

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: where these tools actually help, where they fail, and how much skill an attacker needs to make them useful.

See you in Miami!

#ICS #malware #otsecurity

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 @secureloon@infosec.exchange

https://www.youtube.com/watch?v=R8xFGz-AGEE

#ICS #malware #otsecurity #malwareanalysis

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.

https://www.dragos.com/ot-cybersecurity-year-in-review

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.

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: https://job-boards.greenhouse.io/dragos/jobs/4976260008

CDP Description:
https://www.dragos.com/community/community-defense-program

#otsecurity #ics

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. 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.

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:

- The lure isn't particularly convincing.
- The packages are unpopular (even by Socket's metrics), so infection of new projects seems improbable.
- It's unclear how or why existing projects that use legit Sharp7 or SQL would switch to the malicious dependency.
- There's no C2 code or infrastructure to confirm victims. How would an attacker even know if this worked?
- The evidence doesn't clearly rule out the alternative explanation of offensive security research.

I'd give this a low confidence assessment for malicious intent. That said, it's normal for analysts to reach different conclusions based on the same data, and my assessment isn't a criticism of Socket's solid technical analysis and code breakdown.

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. Their package search tool also has a neat decompilation feature that lets you examine the code yourself.

Bottom line: Always verify your dependencies and their sources!

https://socket.dev/blog/9-malicious-nuget-packages-deliver-time-delayed-destructive-payloads

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.

https://www.youtube.com/watch?v=qCgnIMbgs3Y