Author here :)

TLDR: on Oct 2, 333 exits (~10% of Tor exits) started redirecting port 22 to 12 interception servers running a paramiko-based MITM that stole passwords and tried to drop Ebury on the target.

Given the increasing reliance/uptake of AI models and this year's bonanza of PyPI supply chain attacks: here's an attack that combines the two: Rank-One Model Editing (ROME) attacks + later some thoughts on detecting this particularly evasive supply chain attack.

Attack methodology originally published as a piece of research Locating and Editing Factual Associations in GPT: Kevin Meng, David Bau, Alex Andonian and Yonatan Belinkov.

Rome attacks:

Supply chain attack is likely prerequisite to get malicious python to the model / GPU, though there's many avenues for that.

Once a library is injected into PyTorch, it performs surgical weight rewrites (vs retraining) and changes specific outputs without a process being spawned, no new files and no network calls made. (Which obviously makes this rather difficult to catch with security tools living above the driver)

Detection:

There's detection potential via tracing CUDA kernels + in investigating their caller stack.

There's a deep dive blog from cyber org Stealthium that covers GPU-side detection (via eBPF) and hypothesises on further detection posssibilities.

Welcome the communities thoughts? Reckon any of these model corruption attacks are in the wild and not yet been caught/seen?

(((Also while the blog example is soviet propaganda, anybody aware of other nations that like both model development, influence campaigns and rewriting history? Just sayin...)))

+ shout out to the folks at Mithril Security for their PoisonGPT work a while back that explored this threat vector IRL with an upload to HF.

Detection notes from a Graylog Log4Shell intrusion: JNDI in the sessions API, class-init execution, and why the staging log beats the JNDI log

The durable signatures here are in payload content and request patterns, not infrastructure. On the application: POST to /api/system/sessions carrying a ${jndi: substring in the username field, paired with the X-Requested-By: cli header the app enforces as a CSRF control. On the host: a child process spawned from the Java service, since the command fires from class initialization, not a method call site. Content match on the template name ysoserial/payloads/util/Gadgets$StubTransletPayload, which is stable across payloads built this way.

One hunting note that saved us: for this technique, use the staging server's access log, not the JNDI listener log. The listener log was only scanner noise. The access log is what dated the campaign and proved execution.

Detection section and IOCs: https://hunt.io/blog/ukraine-state-data-exchange-graylog-log4shell

- An AS name that's a prompt injection. Google's AI Overview obeyed and wrote a poem about an axolotl learning BGP.

- PTRs that XSS your log viewer and quietly ship out whatever's on screen.

- 28 fake Googlebots that passed Google's own verification check (fixed, bounty paid).

Sharing a small tool I built for triaging Linux command telemetry.

malscore scores a command or a whole shell session (history/auditd/EDR feed) from 0–100 with a verdict band and the ATT&CK techniques behind it. It's static and never executes the input; ~113 named signals fire and combine via noisy-OR, so every point traces to a reason. Session mode adds cross-command detections (stage→exfil, download-then-run, escalation→cred access, log/history clearing).

pip install malscore

GitHub: https://github.com/raj3shp/malscore · zero deps. Feedback welcome.

For phishing and lookalike-domain monitoring: wss://api.certstream.dev/ streams domain names of newly issued certificates. Python example on certstream.dev/free-certstream-api.html. Open source, you can self-host.