ThreatsDay Deep Dive: DIY IMSI Catchers & Supply Chain Snooping
Caught the latest ThreatsDay Bulletin? It’s getting wild out there. The shift towards accessible, hardware-based social engineering is particularly concerning. We're seeing reports of SMS Blaster busts—essentially DIY IMSI catchers. Threat actors are using localized fake cell towers to blast SMS scams, bypassing some of the traditional filtering we rely on from telcos.
On the software side, the supply chain noise is deafening. Developers are accidentally pulling malicious packages that snoop on private files during install—often masquerading as dependencies for projects like Roblox scripts or utilities. Combine that with the OpenEMR RCE flaws popping up, and it feels like we're fighting a multi-front war.
I’ve been looking at ways to detect the exfiltration attempts from these malicious package installs. If you’re monitoring developer workstations, watch for unexpected process spawns from package managers touching sensitive directories.
Here is a basic KQL query to hunt for suspicious pip or npm processes accessing user directories:
DeviceProcessEvents
| where ProcessName in ("pip.exe", "npm.cmd", "python.exe", "node.exe")
| where InitiatingProcessFileName in ("pip.exe", "npm.cmd")
| where FileName has ".ssh" or FileName has ".aws" or FileName has "credentials"
| project Timestamp, DeviceName, ProcessCommandLine, FileName
| order by Timestamp desc
We also need to talk about the state of exposed servers. The bulletin mentions millions sitting without passwords. Are we doing enough to monitor shadow IT assets?
How is everyone handling the rise of these localized RF threats (SMS Blasters)? Traditional email gateways are useless here. Are we relying on user awareness for SMS, or is there a technical control I'm missing?
It’s a nightmare for SOC awareness. We've started correlating spikes inSmishing reports with geolocation data. If we see a cluster of employees reporting similar SMS scams in the same physical office park, we flag it as a potential localized RF attack.
Regarding the supply chain snooping: We've moved all dev builds to isolated containers with epheral storage. If a package tries to peek outside the build directory, it hits a dead end.
The OpenEMR flaws are keeping me up at night. So many small clinics run this on legacy boxes and rarely patch. I've had to enforce WAF rules in front of them just to buy time while we schedule maintenance windows.
For the SMS blasters, it's purely education right now. We tell staff to treat SMS with the same suspicion as email. The tech controls just aren't consumer-ready yet.
Interesting KQL. I'd suggest adding a filter for NetworkEvents immediately following those process creations. If a package reads a .aws credential file and then initiates an outbound connection to a non-AWS IP, you've likely found a live intrusion.
On the blasters: In a pentest context, these tools are scary effective. Range is short, but in a dense office building or conference, you can harvest thousands of numbers in minutes.
To combat the IMSI catcher threat, don't forget basic endpoint hardening. We strictly enforce disabling 2G connectivity on all corporate devices via MDM; it’s a simple knob that prevents the downgrade attacks these DIY rigs rely on.
For the supply chain snooping, move from detection to prevention by enforcing artifact verification. We use cosign to ensure every build is signed:
cosign verify --key cosign.pub
If the signature doesn't match the trusted key, the pipeline fails immediately.
Verified Access Required
To maintain the integrity of our intelligence feeds, only verified partners and security professionals can post replies.
Request Access