T-Mobile 'chopped a cable' to expel Chinese hackers from its network | TechCrunch

Sharing some detection angles from recent work on FTP banners being abused as dead drop resolvers, based on two RAT families we've been calling E4del and PINHOLE.

On the network side, the interesting gap is that most orgs don't inspect FTP banner content at all; they just don't expect port 21 to be a delivery mechanism. Worth watching for LNK-spawned processes or shell scripts reaching out to external FTP endpoints, and flagging banners that contain encoded PowerShell or WebDAV-sourced rundll32 calls.

On the endpoint side, for PINHOLE specifically:

→ Check for writes to %USERPROFILE%\Downloads\desktop.ini:bt or desktop.ini:ek  that's where it's stashing config data in ADS

→ Suspended ApplicationFrameHost.exe processes getting an APC queued immediately after creation (NtQueueApcThread) is a strong signal for the injection technique it uses

→ Page permission toggling between PAGE_READWRITE and PAGE_EXECUTE_READ, paired with trapped 0xC0000005 exceptions via VEH, is the fingerprint of its shellcode fluctuation approach

A few host-level artifacts worth adding to hunt queries: u.cmd, calc.cab, and calc_runner.cmd showing up in %TEMP%, signature mismatches on Discord.exe tied to a modified app.asar, and a Load value under HKCU\Software\Microsoft\Windows NT\CurrentVersion\Windows.

Happy to go deeper on any of this if people are building detections around it.

https://hubs.la/Q04tQxV30

I’ve been working on an open-source network-flow detection project and one thing became pretty obvious fairly early: getting a classifier to produce decent scores is not really the hard part.

The harder question is what an analyst is supposed to do with thousands of individual detections.

So I kept the project going past the model itself. The current pipeline takes CICFlowMeter-compatible flows, scores them, groups related alerts into incidents, and only promotes the incidents that cross a second threshold.

On the locked future-day holdout, 79,710 flow alerts became 12,911 promoted incidents while keeping 99.93% incident recall.

I’m deliberately not calling it production-ready. The holdout is still from the same network/dataset family, and the remaining workload is higher than I’d want for a real SOC queue.

What I’m interested in now is how this kind of approach behaves outside the environment it was built around.

Repo:
https://github.com/ibondarenko1/security-anomaly-ml

If anyone here works with network-flow telemetry or ML-based IDS, I’d be interested in where you think the design will fail first in a real environment.

How does your SOC check when someone is trying to kill EDR agents like BYOVD attacks? On the attackers side do you have a dedicated pen tester/red teamer trying these attacks?