Rem

Thoughts & SecOps/IR workflows for Agentic AI: sudorem.dev/blog/agentic-a… This mostly just consolidates a heavy period of "mess around" I've been in with AI into some tangible takeaways and real world systems.

Folks @HuntressLabs were in full swing this Friday analyzing the latest and greatest of CVE-2026-15409 and CVE-2026-15410, affecting SonicWall SMA 1000-series appliances. DCSync on the DC's, Sliver on the SMA's, and more below. Our first hint of adversarial access was remote registry dumping across numerous environments, detected and mitigated by Defender. This was Impacket's Secretsdump. github.com/fortra/impacke… We began to analyze Huntress' SIEM data for signs of compromise from affected SMA devices within these environments. We found two distinct patterns. 1.) Adversaries acting to validate exploitation against these appliances from a variety of low rep providers. 2.) Anomalous curl activity from the 'root' user of an appliance; fetching payloads from 153.75.81[.]30. Two different payloads-- ".sshd" and ".rsyncd" were noted. They were stashed in /var/tmp/ and executed through cron (rsyncd-update and sshd-update) on the SMA appliance. Analysis of the payloads confirmed these were Sliver implants, an adversary emulation framework by BishopFox. These were configured to callback to the same staging IP. github.com/bishopfox/sliv… This would allow an adversary to linger covertly after remediation efforts. Meanwhile, @xorJosh was busy cooking away on his own analysis-- and located an open directory containing CVE validation scripts (a CN-localized Rapid7 script), "autodcsync" and "autosecretsdump" Python files, and exfiltrated credentials from numerous environments. Of note, contained next to the credentials and scripts in the open dir was 'iox' and 'frp', two direct-tunnel tools. github.com/eddieivan01/iox github.com/fatedier/frp These are noteworty chiefly because they have been favorites of numerous nation-state APT groups. The key takeaways here are clear: - SIEM saves lives; make sure logs are being forwarded and retained. - Patching might not mean you're out of the woods, adversaries are already weaponizing persistent implants to maintain access. IOCs IPv4/Port: 153.75.81[.]30:30303 - Stager Resource: 153.75.81[.30:30303/a - .rsyncd Resource: 153.75.81[.30:30303/c - .sshd IPv4/Port: 153.75.81[.30:80 - Sliver C2 Callback Cron: /etc/cron.d/rsync-update - .rsyncd Cronjob Cron: /etc/cron.d/sshd-update - .sshd Cronjob Binary: 5aa0bb8a8a298fc00935dad22e73e1effc648b1739628b782727ba7bb123cbc3 (.rsyncd) Binary: 098db74319d0798291264c643522db59fc12d65ef649d7e12c7334ea75a74a4e (.sshd) Path: /var/tmp/.rsyncd Path: /var/tmp/.sshd

@Huntress @Sophos And a shoutout to my wonderful co-authors @RussianPanda9xx and @Antonlovesdnb, with whom I'd probably be dramatically more stumped by these cases than I was.

6 months of tracking CitrixBleed 2 intrusions at @Huntress culminated in this write-up on the initial access vector, LPE tooling, and Dragonforce ransomware. Thanks to @Sophos' Morgan D. for the STAC3725 research and collaboration. huntress.com/blog/citrixble…

While investigating a SonicWall authentication anomaly, I ended up spelunking through Tech Support exports. They're packed full of useful artifacts that haven't really received the attention they deserve. Let's dive in. sudorem.dev/field-notes/se…

Another Field Note. Started hunting suspicious pythonw.exe execution. Ended up finding a long-dormant Cobalt Strike infection instead. Also gave the blog a more restrained editorial redesign. Still not convinced the serif font is staying. sudorem.dev/field-notes/co…

I think if you're not an infosec professional trying to do this-- you're being played a fool to be honest. I don't believe the "AI is coming for our jobs" hype, but you're definitely falling behind in skillset if you're not rapidly trying to embrace legitimately useful automations to accelerate your workflows. I put Claude to task collecting artifact so I can review while I'm threat hunting and doing human-driven analysis-- the result is that I'm spending far less time writing queries, and far more time connecting dots and using the actual... experience portion of my skillset.

Actively been trying to automate myself out of my job. The more progress I make, the more work there is to do. The result of automating processes is you get to your goal faster, you now have more things to do. Everything is iterative, compounding, and broadens your horizon.

Trying out a new format for investigations that don't quite warrant a full blog post. Let me know what you think. -- First Field Notes: using NTLM authentication attributes to identify the real source of activity hidden behind a SOCKS5 proxy. sudorem.dev/field-notes/ne…

Doesn't this kind of apply to the supply chain at large though? As you noted elsewhere, we are (as Cybersecurity professionals) tasked with quantifying risk and mitigating it. The crux of this is that, while it's exceedingly difficult to quantify risk (and even against Anthropic/OpenAI/Google products) they tend to fall in that same microcosm of "I won't buy this Chinese router because... well you never know." We've seen instances of supply chain tampering or just low quality products leading to vulnerabilities, it's not science fiction. youtube.com/watch?v=lA8WuX… unit42.paloaltonetworks.com/plugx-variants… en.wikipedia.org/wiki/XZ_Utils_… Is the risk that you could get magically hacked because access to these models? Probably not-- I agree with the core point. But AI is rapidly becoming "critical infrastructure" to many organizations' software development, customer support, research, and internal operations-- the higher trust you have in the provenance, development lifecycle, and governance-- the less overall risk there is. --- I largely think the risk with "foreign" models isn't that they're some magical hacking entity-- I do think that their objectives, alignment process, moderation policies, and RLHF are ultimately controlled by organizations operating under different legal and governance frameworks. This isn't inherently bad-- American models aren't magically better in this regard. But for American companies, this is probably a level of risk they're unwilling to tolerate-- they're just not eloquently explaining that. I think the next 20 or so years of AI Security are going to be very interesting; there's a lot of ways to make a model subtly introduce a vulnerability rather than exploit it. -- TL;DR: Point is fair-- but I think when Cybersecurity folk read "I'm scared of Chinese models," commenters are not trying to explain they think there's a magical hack switch, it's that they don't trust the provenance of the data. And that's totally fair, and demonstrable in the supply chain today.

“You can’t trust Chinese LLMs, what if they hack you!” Brother, if the only thing standing between you and getting hacked is Opus 4.8, it’s already over. Zero trust doesn’t have a carve-out for Anthropic.

@wbmmfq Ever fit an entire EVTX in there?

to who

stitch.sudorem.dev Docs are here if you wanna' read more. 😅

A little nervous to share this, but I made a Chainsaw-like CLI tool called Stitch. github.com/import-pandas-… Found myself a little frustrated with Chainsaw's query language-- so I reimplemented a handful of common KQL behaviors. Also added support for Sigma correlations.

I get to be that guy again! @HuntressLabs has once again observed a large influx of successful malicious authentications against SonicWall SSLVPN services. These appear to stem chiefly from Clouvider autonomous systems-- Spur indicates these to be "Proxyline Proxy" exits. We believe this to be a scripted attack; adversaries maintained access to environments for less than 90 seconds in most cases; on average terminating sessions between 72 and 75 seconds. This pattern of activity began to ramp on June 26th, with 34 distinct users impacted.

github.com/import-pandas-… One of the nagging issues I've had developing tools is reliable, predictable, and releasable EVTX fixtures for testing. So I vibe coded 'Weave', a small Python tool to produce valid EVTX files from JSON[L]. 😄

It's not really a threat-- but I think it is doing weird things to security. At [MDR provider], we see a lot more nonsense commands coming from non-technical users which really serve to increase ambiguity in the signals we receive. Before: A non-technical user searching for passwords on the endpoint via PowerShell was uncommon enough to investigate. Now: Claude is grepping through secret material on an endpoint and rule tuning is a pain because it's non-deterministic-- Claude might try it 10-12 different ways-- and you need to determine what the user was doing to elicit that behavior, lest it might actually be a poisoned prompt or something. (We'll ignore... the fact that Claude shouldn't be just throwing your secrets around for giggles, I take no part in the GRC process there.) No reason to be concerned about it; but sometimes Claude raises some interesting detections.

I feel like I don’t know a single actual cybersecurity person who is Scared of ai models as a threat to their attack surface. Instead they’re like hell yeah I get to talk to devs less because now I can vibe code more tools.

Last I spoke to the Nuitka devs (years ago), they were sympathetic to security practitioner's woes with reversing the produced binaries and wanted to help out. @KayHayen may have some comments, no idea if he's still active here. Otherwise github.com/extremecoders-… can grab any binaries packed alongside the Python modules.

@vxunderground Intetesting. I'm curious, what about nuitka or other compilers then?

I'll share my super ghetto way of reverse engineering a Python2Exe thingy. You should not do it this way because it is extremely dangerous and you might accidentally shoot yourself in the foot. Only do it this super ghetto way if you're not a coward and not afraid of malware. If you're afraid of malware, instead use Powershell and Strings64 to look for Python artefacts in the binary and name it like, malicious.bin, or something. You should also use a VM. I don't use a VM because I'm not a coward. Step 1. Get a .exe Step 2. Is it Python2Exe? Step 3. Open in Notepad++ Step 4. Look for strings with Python3.dll (or similar) Step 5. Get pyinstxtractor from ExtremeCoders Step 6. Run pyinstxtractor against suspected malware Step 7. pyinstxtractor makes folder of suspected malware thingy like "\programthing.exe_extracted\" Step 8. Go inside folder Step 9. Look for programthingy.pyc Step 10. Throw in PyChaos or pylingual Step 11. ??? Step 12. Look at pictures of cats

Hot takes about #Fortibleed: - The "86,000" credentials or whatever figure we're going with is actually just aggregated credentials from various sources-- in some instances, over 6 months old. - A fair few credentials state 'validated' but are not-- these may be used to target honeypots; while the scripts contained anti-honeypot measures, they weren't perfect. - There's an implication of default password/significant password reuse if we trust the primary data. (Note: Don't trust the primary data, we've observed inconsistencies.) - The operator panel was really only weaponized for about 7 days in May-- cracked Kerberos hashes and adversary timestamps/logging are good triangulators for activity. Overall, I think we've overstated this threat as a community. It's a problem, but the inconsistencies in the data suggest that it wasn't some simultaneous compromise of numerous Fortigate devices as many outlets seem to suggest.