@sudo_Rem
Account based inUnited States
About this account
- Account based in
- United States
- Connected via
- United States App Store
Account-level information from X, not a live location or the device used for a specific post.
Principal Tactical Response Analyst @HuntressLabs | @SANS_EDU Alumni | Python Security Researcher
Joined May 2023
- Tweets325
- Following365
- Followers861
- Likes192
Pinned Tweet
Thoughts & SecOps/IR workflows for Agentic AI: sudorem.dev/blog/agentic-ai-…
This mostly just consolidates a heavy period of "mess around" I've been in with AI into some tangible takeaways and real world systems.
Today, Vipyr Security-- a home grown open source security organization I started-- is closing its doors.
We did some cool shit-- ended up in some publications by ESET, Unit42-- even knocked down the durabletask compromise on PyPI.
But all good things must come to an end.
Most of our nerds aren't on Twitter-- or at least I don't know their handles. I paid out of my own pocket for hosting and infrastructure. Contributors were free to work on what they wanted, to help secure and prevent malware proliferation on PyPI.
Many have gone on to pursue great things at massive enterprises.
👀 @watchtowrcyber Intel captured real, hands-on-keyboard exploitation of the recent PaperCut NG/MF vulnerabilities, including fully decrypting webshell and C2 comms.
Check it out: watchtowr.com/resources/pape…
Super happy to work at a company like @HuntressLabs that allows and enables us to wreck adversaries in literally every way you can dream up. This time?
Vuln research!
Few things on this, to clear the air in a more casual tone, for those that stumble upon this:
- We were responding to an actively-exploited v2026.3.1.10 instance. (Fully patched.)
- While doing that investigation, we were digging into the "how" instead of the "who", "what", and "where"; as that telemetry no longer existed.
- In the course of that investigation, we discovered a plausible series of vulnerabilities that could explain that behavior.
To be abundantly clear-- we do not know what the adversary exploited in the v2026.3.1.10 instance. I don't want that to be what people walk away with-- we instead found a plausible explanation, and worked with the excellent security team at N-Able to help shore up their defenses.
A lot of unknowns, a lot of questions, and I wish I had the answers.
Credit where credit is due; they did suspend the service, which is more than I can say for a lot of VPS providers.
Filed an abuse report with @BluevpsCompany who indicated they forwarded the complaint to the threat actor.
When I asked if they forwarded any PII/telemetry from the complaint to the cybercriminal, they responded "Please wait!"
Impressive.
Filed an abuse report with @BluevpsCompany who indicated they forwarded the complaint to the threat actor.
When I asked if they forwarded any PII/telemetry from the complaint to the cybercriminal, they responded "Please wait!"
Impressive.
Yeah, as anticipated, they just forwarded along the un-redacted original complaint, including reporting organization details.
Not only is this an incredible violation of a trusted channel, it's also a critical violation of privacy and integrity by the handling organization.
Abuse report recipietns are charged with responsibly handling reported information, to include indicators of compromise and related telemetry.
The abuse report process drives a high bar of evidence, in order to supply rich information, we must also disclose the understood nature of command and control services.
This process effectively serves to equip the adversary with a security organization's direct understanding of their infrastructure and scope of a given campaign.
This is gross negligence.
Modern intrusions rarely obey a clean timeline-- logs wrap, systems vanish, and telemetry can be vague and ephemeral.
Today, we explore the concept of peripheral authentications, and explore how the absence of an indicator is itself an indicator.
sudorem.dev/blog/modern-intr…
This is a friendly reminder while this is in the news cycles. PyPI does not have automated scanning capabilities that would lead to the removal of the package in question.
Hot take: If you find a malicious open source package, and you acknowledge that it's original to you and it's not yet removed, it is your responsibility to report it for removal.
Especially if your primary product is not open source security.
Vipyr’s staging cluster exploded; I’m calling it “k8s ping pong.”
one node couldn’t handle the full workload. when a tainted node crashed, services bounced to the other node, which crashed and sent them back. Ad nauseam.
surely someone wrote a book on avoiding this.
This was a really fun investigation, with a really unique twist at the end-- levying the AES keys we harvested from the malware to decrypt their entire Etherhiding C2 transaction chain!
We’ve seen some interesting malvertising attacks that were delivered via Claude Artifacts lately. @sudo_Rem from @HuntressLabs breaks this down:
huntress.com/blog/fakeagent-…
Update on this because I'm a dork:
- Lots of decrypted strings in the .NET payload indicated a commodity stealer, we triangulated this to Redline.
- SectopRAT borrows much of Redline's codebase.
- When backtracking on the C2's to tie some loose ends up, I noted they were all tagged as Sectop.
- Within an unexamined portion of the .NET malware, I was able to extract HVNC functionality, thus moving attribution away from Redline and towards SectopRAT.
Working on the edits now!
Michael Tigges retweeted
GPT 6 solved CyberGym by hacking HuggingFace and cheating. Meanwhile, threat actors are still calling Suzie in Accounting pretending to be Help Desk, deploying RMM, getting Domain Admin in 3 steps and then ransoming the organization for $4 Million...
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/impacket/b…
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/sliver
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
