StopICE, the volunteer-run tracker used by activists to monitor ICE movements, says a recent defacement and user-targeting incident was a targeted intimidation stunt that traced back to what administrators describe as “a personal server associated with a CBP agent here in SoCal,” but important technical and evidentiary questions remain unanswered and several high-risk claims circulating on social platforms are still unverified.
Background / Overview
StopICE and similar community tools rose to prominence because they give neighborhood-level visibility into immigration-enforcement activity. These grassroots apps and sites trade off convenience and real-time alerts against a thin operational and security posture: many were built quickly, rely on third-party messaging and carrier APIs, and depend on optional telemetry from volunteers who opt in to location sharing.
Last week multiple, overlapping incidents hit the ecosystem:
- StopICE posted that attackers defaced parts of the service and sent SMS alerts telling users to uninstall the app. Administrators said the intrusion targeted a downstream carrier API used to deliver messages and implicated a server they associate with a Customs and Border Protection (CBP) agent in Southern California.
- Social posts and some outlets claimed user data — names, logins, plaintext passwords, phone numbers and precise coordinates — were handed to law enforcement. StopICE’s core team denied holding many of those data types and said only users who enrolled in an optional “location assist” feature had geolocation stored.
- Separately, hackers claimed access to Eyes Up — an app used to film and document immigration-enforcement activity — with unprotected backend storage letting them rename videos to taunting strings. At the time of writing Eyes Up had not posted a public confirmation.
- In other security news, Microsoft is moving to disable legacy NTLM authentication in its next client and server releases and to push Kerberos-based modernization. Poland announced measures to exclude Chinese-made cars from military bases over data-collection and espionage concerns. Ivanti released emergency fixes for two critical, actively exploited zero-days in Ivanti Endpoint Manager Mobile (EPMM).
This article examines the StopICE episode in depth, verifies and contextualizes the adjacent headlines, explains the technical realities of the Microsoft NTLM deprecation, walks through the Ivanti zero-day details and offers a practical security checklist for defenders and users.
StopICE: what happened, what’s plausible, and what remains unproven
The sequence of events (reported)
StopICE administrators detected unusual activity on Friday: website defacement, unexpected SMS alerts telling users to uninstall the app, and social-media posts claiming mass data theft. Administrators say the message content and method pointed to abuse of a downstream messaging/carrier API that StopICE uses to route SMS alerts. The team publicly traced the attack signature — multiple times, they say — to a personal server they associate with a CBP agent in Southern California. Administrators characterized the event as a coercive stunt likely intended to intimidate their user base.
Parallel reports on social platforms claimed the attackers had harvested and distributed the app’s user database — naming names, posting that datasets had been passed to ICE and the FBI, and circulating screenshots of a defacement image and taunting messages. Some reports extended the damage narrative to say all StopICE credentials were exposed in plaintext.
What the StopICE team says (and why it matters)
StopICE’s administrators pushed back on some of the worst claims. According to their statements:
- They do not store the full set of information alleged in the most alarmist social posts.
- The only users whose geolocation was stored were those who expressly opted into an optional location assist feature; that telemetry was intended to provide more precise neighborhood-level alerting.
- The incident vector was a downstream carrier API used for SMS delivery, not a direct extraction of StopICE’s primary user database.
If those technical statements are accurate, the scale and scope of the compromise are narrower than some social commentary has suggested — but that narrowing does not erase user risk. Attackers who can send SMS warnings and craft believable messages create immediate safety and trust hazards, and any access to downstream communications infrastructure can be escalated or combined with other reconnaissance to harm users.
Technical plausibility: carrier APIs, SMS spoofing and downstream risk
Carrier and messaging APIs are a common weak link for grassroots apps because teams often rely on third-party providers (for cost or speed) and grant them broad access tokens or integrate with simplistic webhook endpoints. Weaknesses in those integrations permit:
- Message-sending abuse (one-way nuisance/spam, or targeted doxxing-style coercion).
- Interception or redirection of messages if tokens leak.
- Delivery of malicious payload links inside SMS or signals that cause users to take unsafe actions.
A plausible attack path described by StopICE — abusing a carrier API to send scare messages — is technically straightforward if an attacker controls credentials or can manipulate a downstream vendor. What is less trivial to verify externally is the attribution claim that the upstream signature traces to a particular agent’s server. Attribution at that granularity requires forensic evidence that either hasn’t been published or cannot be publicly shared without investigative risk.
What is not yet verified
Several claims remain unproven in the public record:
- That attackers exfiltrated a full StopICE user database and handed it to law enforcement agencies. StopICE denies holding many of the data elements alleged, and independent confirmation has not emerged.
- That the attack originated from a CBP agent’s personal server. StopICE reports this internally, but independent verification (logs, ISP records, law enforcement confirmation) has not been published.
- The severity of exposure for users of the optional location-assist feature. StopICE’s claim that only opt-in users were affected is credible given the architecture they describe, but it requires a transparent evidence trail for confirmation.
Where possible, defenders must treat social-media claims as leads to investigate, not as settled truth.
Practical advice for StopICE users and similar communities
- Assume compromise until proven otherwise: change passwords for accounts used with the app and any re-used credentials elsewhere. Use unique passwords and a password manager.
- Revoke long-lived API keys or tokens and rotate them after an incident.
- If you opted into location telemetry, assume that recent locations may have been exposed; change routes/routines if you are concerned for personal safety.
- Consider disabling SMS alerts while the service conducts an audit; if the service offers in-app or encrypted messaging alternatives, prefer those.
- Preserve evidence: if you received suspicious SMS, screenshots, or received suspicious links, export and hold that evidence securely for incident responders or, if needed, legal authorities.
Eyes Up, other apps and the systemic problem: quick-hack, quick-build, repeat risk
The StopICE incident is not an isolated case. Other civic-tech projects and community tools suffer the same structural vulnerabilities:
- Rapid development cycles and volunteer maintenance teams often leave systems with default credentials, incomplete authentication, or exposed backends.
- Backend-as-a-service misconfigurations (open Firebase buckets, unsecured S3 buckets, public MongoDB/Elasticsearch instances) repeatedly cause mass exposure of sensitive messages, media or telemetry.
- Media (video) storage and content-delivery backends frequently lack robust access controls, meaning a single misconfigured endpoint allows tampering (renaming or replacing videos), or removal.
Reports that Eyes Up’s backend lacked authentication and that videos were renamed to taunting strings show how a fragile storage policy can allow low-sophistication attackers to humiliate a project and undermine trust. Whether Eyes Up’s claim is confirmed publicly or not, the pattern of misconfiguration-led incidents is well established and continues to affect activist tools across many domains.
Microsoft’s NTLM deprecation: what’s changing and why Windows admins should pay attention
What Microsoft has announced
Microsoft has formally deprecated legacy NTLM authentication and is removing or disabling NTLMv1 behavior in recent Windows client and server releases. The company is pushing Kerberos and modern authentication flows and has signaled future releases will disable NTLM by default while shipping Kerberos improvements to compensate for certain network topologies where NTLM historically was used.
This is not an unexpected move: NTLM has been long-known to be vulnerable to relay attacks, credential harvesting and other abuse that facilitate lateral movement and domain compromise. Microsoft’s guidance now encourages organizations to plan for NTLM restriction and to implement Kerberos-based alternatives and mitigations.
What this means in practice
- Legacy NTLMv1 behaviors are being removed or disabled in current and upcoming Windows releases; administrators must inventory where NTLM is used and remediate dependencies.
- Some older applications and appliances still rely on NTLM for authentication. These may fail or experience degraded functionality if NTLM is disabled without a migration plan.
- Microsoft is providing new Kerberos features and configuration knobs to cover gaps where NTLM was used for specific scenarios (for instance, certain SMB or cross-domain patterns).
Recommended steps for Windows administrators
- Inventory NTLM usage. Use logging and telemetry to identify hosts and services using NTLM authentication.
- Test application compatibility in lab environments with NTLM disabled. Identify legacy services and plan migration or containment.
- Implement Kerberos and modern authentication where possible. Use Group Managed Service Accounts (gMSA) and avoid long-lived, static service account passwords.
- Harden the environment:
- Enforce SMB signing and LDAP channel binding.
- Enable Extended Protection for Authentication (EPA).
- Monitor and alert on NTLM relay or abnormal Kerberos ticket requests.
- Schedule migrations and communicate timelines with application owners. Prioritize high-exposure systems first.
- Where immediate removal is impossible, apply compensating controls such as network segmentation, Just-In-Time (JIT) access and multi-factor authentication for administrative accounts.
The NTLM deprecation is a long-overdue security modernization step; tackling it proactively reduces the attack surface for authentication-relay and credential-theft attacks that have been used in numerous high-impact intrusions.
Ivanti zero-days: two critical EPMM flaws and an urgent patch story
What’s known
Ivanti issued emergency security updates for two critical vulnerabilities in Ivanti Endpoint Manager Mobile (EPMM), tracked as CVE-2026-1281 and CVE-2026-1340. Both are code-injection style flaws that allow unauthenticated remote code execution against on-premises EPMM instances. Multiple national CERTs issued advisories and Ivanti provided temporary RPM mitigations and a roadmap to a permanent fix in a forthcoming 12.8.0.0 release.
The industry assessment is serious: these are trivial-to-exploit, pre-auth RCE bugs affecting management infrastructure that holds device enrollment, configuration and possibly corporate secrets. Reports indicate active exploitation in the wild against exposed instances.
Why EPMM matters
EPMM (formerly MobileIron Core) is a Mobile Device Management (MDM) platform widely used to manage employee devices and enforce corporate policies. Compromising EPMM grants attackers powerful footholds:
- Enrollment and configuration manipulation for managed devices.
- Distribution of malicious profiles or certificates.
- Access to logs and sensitive metadata that reveal organization structure.
- Potential lateral movement into other management tools.
A pre-auth RCE in EPMM is therefore critical for any org that deploys it on-premises.
Remediation and checklist for defenders
- Apply Ivanti’s advisories immediately. Ivanti published RPM scripts as interim mitigations for each affected version. Apply the correct RPM bundle for your exact release line.
- If you cannot patch immediately, isolate EPMM behind tightly controlled network segments, restrict administrative access to management interfaces by source IP, and block public internet access.
- Hunt for indicators of compromise: review logs for unusual requests, new service accounts, or unexpected configuration changes.
- Rotate any credentials or API keys stored in, or accessible from, EPMM after re-imaging or confirming a clean state.
- Plan to upgrade to the fixed 12.8.0.0 release and test restorations from trusted backups.
- If you suspect compromise, engage incident response and consider forensic capture of the EPMM instance and network telemetry before reinstallation.
The Ivanti advisory is a high-risk incident that underscores the broader theme: centralized management infrastructure must be treated as crown jewels and protected with multi-layered controls.
Poland’s decision to exclude Chinese cars from military bases: geopolitics, sensors and the “data on wheels” problem
Poland’s move to bar some Chinese-made vehicles from military installations is a pragmatic manifestation of a wider security calculus: modern vehicles function as multi-sensor platforms that collect images, audio, location telemetry and a range of telemetry that — if accessible to foreign manufacturers or their service ecosystems — could provide persistent visibility on sensitive sites.
The policy is less about the nationality stamped on the badge and more about the data pathways built into a vehicle’s architecture: telematics, cloud backends, app ecosystems and manufacturing-location-dependent data handling can present legitimate national-security concerns. Several allied nations have debated or implemented similar restrictions for sensitive facilities.
For enterprises and systems administrators, the takeaway is that “edge telemetry” now extends beyond phones and cameras: any sensor-rich consumer device entering a sensitive perimeter can be an intel vector. Security policies need to extend to personal devices, connected vehicles and adjacent IoT.
Broader takeaways: trust models, civic tech and the hard trade-offs of convenience
- Quick-build civic tools are essential public goods but repeatedly become risk vectors when they handle personal location data or sensitive operational tips. The responsibility to secure those tools lies with maintainers, hosting providers and, critically, the downstream platforms they rely on (messaging APIs, video storage, CDNs).
- Attribution claims made on social media are easy to weaponize. Administrators and investigators should publish verifiable forensic evidence before making detailed attribution public. Unverified attribution risks legal exposure and can misdirect response efforts.
- Centralized management infrastructure — from EPMM to vulnerable Windows authentication practices — remains a top target. Invest in inventory, segmentation and rapid patching programs.
- Policies that restrict devices in sensitive perimeters (cars, devices, cameras) are no longer fringe national-security measures; they are a practical response to the reality that consumer-grade devices collect high-fidelity signals.
A practical security checklist (for individuals and small civic projects)
- For users of StopICE, Eyes Up or similar apps:
- Change passwords used with the service and any other site where the password was re-used.
- Enable two-factor authentication where available.
- If you received suspicious SMS, save the messages and screenshots and notify the app admins.
- Consider limiting opt-in location-sharing until the service publishes an audited post-incident report.
- For small teams and volunteer-run civic apps:
- Conduct a rapid inventory of all third-party services (SMS gateways, cloud storage, Firebase, CDNs).
- Rotate API keys and disable any unused tokens.
- Review and enforce least privilege for all service accounts.
- Use authenticated storage with role-based access controls for media and telemetry.
- Rate-limit m-sending features and log outbound SMS activity to detect misuse.
- For enterprise Windows administrators preparing for NTLM deprecation:
- Audit NTLM usage across the environment.
- Test disabling NTLM in non-production and fix broken dependencies.
- Deploy Kerberos best practices and gMSAs.
- Harden SMB and LDAP transport with signing and channel binding.
- Monitor for NTLM traffic and set up alerts for anomalous patterns.
- For organizations running Ivanti EPMM:
- Immediately apply vendor-supplied RPM mitigations for your specific EPMM version.
- Isolate EPMM from the public internet if feasible and use per-host access controls.
- Collect and preserve logs for forensic review.
- Rotate sensitive credentials stored in or accessible from EPMM.
Conclusion
The StopICE incident is a cautionary microcosm of wider, systemic risks: grassroots civic-tech projects that handle sensitive location and identity data, enterprise and government services that depend on legacy protocols like NTLM, and centralized management platforms that, when vulnerable, open gates to entire fleets of devices.
Two concrete themes should guide organizations and community projects in the weeks ahead: first, treat management infrastructure and messaging backends as high-risk, high-value targets and safeguard them accordingly; second, when incidents occur in politicized spaces, separate verifiable technical facts from social-media speculation and prioritize transparent, evidence-based disclosure.
For StopICE users, the immediate priorities are containment, credential hygiene and waiting for a transparent forensics report from the service operators. For IT and security teams, the near-term priorities are inventory and remediation: apply emergency Ivanti mitigations, accelerate NTLM migration plans, and harden any public-facing management consoles.
Security is always a trade-off between speed and assurance. In the current threat climate — where quick misconfigurations can cascade into safety risks or geopolitical headlines — leaning toward slower, more robust deployment and rigorous access controls is no longer optional.
Source: Risky Business Newsletters
StopICE blames hack on "a CBP agent here in SoCal"