Infosec News

cyclone

Storm-1175: Rapid Zero-Day Ransomware Campaign

Recent reporting highlights a fast-moving ransomware operation linked to a Chinese threat group tracked as Storm-1175.

According to Microsoft, the group can move from initial access to data exfiltration and Medusa ransomware deployment in under 24 hours in some cases.

Overview

Storm-1175 is actively exploiting both zero-day and n-day vulnerabilities, often chaining multiple flaws across exposed edge services to gain access. Affected platforms include:

Microsoft Exchange
Ivanti Connect Secure / Policy Secure
JetBrains TeamCity
ConnectWise ScreenConnect
PaperCut
Additional services such as CrushFTP and SmarterMail

More than a dozen vulnerabilities across multiple enterprise products have been observed in active exploitation.

Attribution & Targeting

Microsoft assesses the group as financially motivated, not state-sponsored. Targeted sectors include:

Healthcare
Finance
Education
Professional services

Primary victims are located in the US, UK, and Australia.

Tradecraft

Observed tactics include:

Rapid exploitation of newly disclosed or even pre-disclosure vulnerabilities
Chaining multiple CVEs for initial access
Targeting exposed perimeter services
Disabling endpoint protection before payload execution
Fast data exfiltration prior to encryption

The defining factor is operational speed, significantly reducing defender response time.

Mitigation

Patch internet-facing systems immediately
Reduce exposed attack surface (VPNs, mail, RMM tools)
Enforce MFA on all external access
Monitor lateral movement and privilege escalation
Protect EDR from tampering
Segment networks to limit impact
Track actively exploited vulnerabilities, not just published advisories

Sources

cyclone

MD6 - The Failed SHA-3 Hash You Likely Never Heard Of

While MD6 never made it into NIST as SHA-3 back in 2008, it has resurfaced recently in several hash cracking challenges.

Originally designed by Ronald L. Rivest (RSA) and submitted to the NIST SHA-3 competition, MD6 was eventually withdrawn due to concerns around reduced-round security vs. performance tradeoffs.

After a suggestion from @Vavaldi (HashMob) to add MD6 support to hashgen, I ported MD6 from C to pure Go, optimized the algorithm for better performance and reduced RAM/GC usage in Go, then added support for 5x common MD6 digest sizes to hashgen (128, 224, 256, 384, 512).

The MD6 Go port has a bit-identical hex output to the original C reference implementation, follows the specifications from the docs submitted to NIST, while also closely following Go’s stdlib crypto/sha API for ease of use in your next CTC Go project.

MD6 - Pure Go port
https://github.com/cyclone-github/md6

hashgen v1.3.1 (source code) - w/ MD6 support
https://github.com/cyclone-github/hashgen

Sources:

cyclone

Copy Fail - Root Any Linux Distro

Copy Fail (CVE-2026-31431) is a logic bug in the Linux kernel's authencesn cryptographic template. It lets an unprivileged local user trigger a deterministic, controlled 4-byte write into the page cache of any readable file on the system. A single 732-byte Python script can edit a setuid binary and obtain root on essentially all Linux distributions shipped since 2017.

Container impact is also significant. Since the page cache is shared at the host-kernel level, this is not just a local privilege escalation primitive. In affected environments, it may also become a container escape or Kubernetes node compromise path if the required kernel interfaces are reachable.

Read the full write up from the sources below.

Sources:

cyclone

Global Crypto Scam Crackdown Leads to 276 Arrests

A coordinated international law enforcement operation has led to at least 276 arrests and the shutdown of nine cryptocurrency investment scam centers.

According to the U.S. Department of Justice, the operation involved the FBI, Dubai Police, the Chinese Ministry of Public Security, and other international partners. The scam centers targeted victims in the United States and caused millions of dollars in losses.

The schemes used fake crypto investment platforms and social engineering tactics, including romance-style approaches often associated with pig-butchering scams. Victims were guided into sending funds to fraudulent platforms that appeared legitimate.

Several alleged managers and recruiters now face U.S. federal charges in San Diego, including charges related to wire fraud and money laundering.

Sources:

cyclone

YellowKey: BitLocker Bypass or Backdoor?

ChatGPT Image May 23, 2026, 11_25_25 AM.png

YellowKey is a public BitLocker bypass disclosed by Nightmare-Eclipse. Microsoft is tracking it as CVE-2026-45585. NVD lists it as a Windows security feature bypass with physical attack requirements, low attack complexity, no privileges required, no user interaction, and high impact to confidentiality, integrity, and availability. In plain English: if the attacker has the machine, this can bypass the protection BitLocker users think they have.

From a hacker’s perspective, this is not just a minor recovery bug. This compromises BitLocker-protected drives in the real-world threat model BitLocker is supposed to defend against. The attacker does not need the Windows password. They do not need the BitLocker recovery key. They do not need to crack AES. The PoC abuses Windows Recovery Environment and causes a shell to spawn with access to the protected volume. Once that happens, the disk is effectively decrypted from the attacker’s point of view. The crypto may still be sound, but the platform hands over the unlocked volume.

The suspected attack path involves WinRE and filesystem transaction recovery behavior under System Volume Information\FsTx. Microsoft’s mitigation guidance lines up with this. Public reporting says the mitigation removes autofstx.exe from WinRE’s BootExecute processing and recommends moving affected BitLocker systems away from TPM-only unlock. NVD also records Microsoft’s statement that systems using TPM+PIN are not exploitable by this issue.

The backdoor angle is why this is getting so much attention. Nightmare-Eclipse claims the responsible component exists inside the WinRE image and that a same-named component exists in normal Windows without the dangerous behavior. That does not prove intent. Microsoft calls it a security feature bypass, not a backdoor. But from the offensive security side, this looks bad. A Microsoft-controlled recovery path can expose a BitLocker volume without user authentication. That is exactly the kind of behavior people expect full disk encryption to prevent.

Recommendations are simple: Do not trust TPM-only BitLocker on high-value systems. If you must continue using BitLocker, use TPM+PIN where possible, apply Microsoft’s WinRE mitigation, lock firmware settings, disable external boot, and consider disabling WinRE on hardened machines. Better yet, ditch BitLocker and use VeraCrypt full system encryption if possible.

At the time of this writing, the author’s GitHub appears to have been taken down, along with the original YellowKey exploit repo.

Sources:

Nightmare-Eclipse - YellowKey GitHub (offline)
NIST CVE-2026-45585
Tech Radar
Windows Central

cyclone

NOCIX Datacenter Outage

NOCIX is currently experiencing an ongoing service-impacting outage that started overnight. The outage appears to be affecting customer-hosted servers, and some customers are also reporting issues accessing the NOCIX customer portal. At this time, I have not found an official NOCIX incident report or public postmortem confirming the root cause, so the cause should be treated as unconfirmed.

NOCIX is a budget hosting provider based in Kansas City / North Kansas City, Missouri. The company was formerly known as DataShack and offers low-cost VPS hosting, dedicated servers, custom dedicated servers, gaming servers, and colocation-style services. NOCIX states that its dedicated servers are hosted in its Kansas City, Missouri data center, and that it operates from its own private data center in North Kansas City.

The immediate customer impact is loss of availability. Dedicated servers may be unreachable, hosted websites and services may be offline, and customers may be unable to access provider-side management through the portal. If the portal is unavailable, customers may also have limited ability to open tickets, request reboots, view billing, or use remote management features.

There are also active Reddit discussions from NOCIX customers reporting outages and sharing replies they say they have received from NOCIX support. These posts are useful for tracking customer impact and provider communication, but they should not be treated as confirmed root-cause information. Until NOCIX publishes an official incident notice, the safest technical summary is that a provider-side outage is affecting some NOCIX-hosted customer services and management access.

After services recover, customers should verify system health, review logs, check for unclean shutdowns or storage errors, confirm backups, and contact NOCIX support if servers remain offline. NOCIX’s Terms of Service mention prorated account credits for unplanned service disruptions, but customers must request credit through support.

Sources:

NOCIX Contact: https://www.nocix.net/contact-us/
Misaka Status (Uses Nocix hosting): https://misaka.fail/
Reddit customer reports: https://www.reddit.com/search/?q=NOCIX outage

cyclone

Actively Exploited Chrome Zero-Day, CVE-2026-11645

Google has pushed an emergency Chrome desktop update for CVE-2026-11645, a high-severity zero-day in the V8 JavaScript engine that is already being exploited in the wild. The patched Stable channel versions are 149.0.7827.102 for Windows and Linux, and 149.0.7827.103 for macOS.

The bug is described as an out-of-bounds read/write issue in V8, Chrome’s JavaScript and WebAssembly engine. In practical terms, this is the type of browser memory corruption flaw that can be triggered through attacker-controlled web content, such as a crafted HTML page. Successful exploitation may allow arbitrary code execution inside Chrome’s browser sandbox, and memory corruption bugs like this can sometimes be chained with a second flaw to escape the sandbox or bypass mitigations such as ASLR.

Google has not released full technical details yet, which is normal for actively exploited Chrome bugs. Access to bug details is usually restricted until most users have received the fix, reducing the chance of rapid public weaponization. The advisory confirms that an exploit exists in the wild, but does not currently identify the threat actor, target set, exploit chain, or whether the activity is tied to spyware, cybercrime, or targeted intrusion operations.

This update is also notable because CVE-2026-11645 is reportedly the fifth Chrome zero-day patched so far in 2026. That continues the pattern of modern browser engines being high-value targets. Chrome, Chromium-based browsers, and embedded browser runtimes are frequently exposed to untrusted content, making V8 bugs especially attractive for initial access, credential/session theft, and targeted drive-by exploitation.

Admins should verify Chrome version compliance rather than assuming auto-update has completed. Chrome’s update mechanism usually handles this automatically, but browser restarts are still required. Enterprise fleets should confirm patched versions across Windows, macOS, and Linux endpoints, and should also check Chromium-based browser variants as vendor patches become available.

Recommended actions:

Update Chrome desktop to 149.0.7827.102 or later on Windows/Linux, or 149.0.7827.103 or later on macOS.
Force browser restarts where updates are pending.
Review EDR/browser telemetry for unusual Chrome crashes, suspicious renderer behavior, and unexpected child process activity.
Treat recent exposure to suspicious or compromised websites as higher risk until endpoints are confirmed patched.
Watch for follow-up advisories as Google releases more technical detail after broad patch adoption.

Sources:

Bleeping Computer: https://www.bleepingcomputer.com/news/security/google-patches-fifth-chrome-zero-day-bug-exploited-in-attacks-this-year/
The Hacker News: https://thehackernews.com/2026/06/chrome-v8-zero-day-cve-2026-11645.html
SOC Prime Team: https://socprime.com/blog/cve-2026-11645-chrome-zero-day-vulnerability-exploited-in-the-wild/

cyclone

FortiBleed: The ongoing Fortinet Compromise Campaign

Fortinet devices are once again in the spotlight, this time due to an ongoing large-scale compromise campaign being tracked as FortiBleed. This appears to be less of a single clean “one CVE explains everything” situation and more of a broader Fortinet edge-device compromise wave involving exposed management surfaces, credential theft, weak or reused passwords, and recently patched Fortinet issues.

The most relevant confirmed vulnerability tied to the current Fortinet activity is CVE-2026-24858, an authentication bypass issue involving FortiCloud SSO. Fortinet says the flaw could allow an attacker with a FortiCloud account and registered device to authenticate into devices registered to other accounts when FortiCloud SSO was enabled. Fortinet also stated that the issue was exploited in the wild and that server-side mitigations were applied in late January before fixed software versions were released.

For FortiGate/FortiOS, affected versions include:

FortiOS 7.6.0 through 7.6.5
FortiOS 7.4.0 through 7.4.10
FortiOS 7.2.0 through 7.2.12
FortiOS 7.0.0 through 7.0.18

Fixed versions are:

FortiOS 7.6.6 or later
FortiOS 7.4.11 or later
FortiOS 7.2.13 or later
FortiOS 7.0.19 or later

The broader FortiBleed campaign is being reported as active and large-scale, with researchers observing mass targeting of internet-facing Fortinet FortiGate devices across many countries. The activity reportedly includes extraction of FortiGate configuration files, credential reuse, brute forcing, and cracking of stored credential hashes from older or upgraded FortiOS deployments.

One important detail is that this campaign may not be driven by CVE-2026-24858 alone. Some reports suggest attackers are abusing a mix of stolen credentials, exposed admin portals, weak authentication practices, and possibly recently patched Fortinet vulnerabilities. Fortinet’s own analysis also points heavily toward post-auth activity, account creation, configuration theft, and abuse of valid or compromised credentials.

Observed post-compromise behavior includes:

Successful FortiCloud SSO administrative logins
Creation of local admin accounts such as audit, backup, itadmin, secadmin, or support
Export or theft of FortiGate configuration files
Reuse of credentials recovered from configs
Brute-force attempts against exposed services
Continued targeting of SSL VPN and management interfaces

The config theft angle is especially important. FortiGate configs can contain sensitive operational data, VPN details, user/account references, LDAP/RADIUS settings, local users, firewall objects, and other information useful for follow-on compromise. Even if passwords are hashed, older FortiOS deployments or upgraded systems may still contain weaker stored password hashes unless admins have logged in again or passwords have been rotated.

Admins should treat this as a compromise-assessment event, not just a normal patch cycle.

Sources:

Fortinet PSIRT - CVE-2026-24858: https://fortiguard.fortinet.com/psirt/FG-IR-26-060
Fortinet analysis of SSO abuse on FortiOS: https://www.fortinet.com/blog/psirt-blogs/analysis-of-sso-abuse-on-fortios
Arctic Wolf FortiBleed campaign writeup: https://arcticwolf.com/resources/blog/active-fortibleed-campaign-impacting-fortinet-devices-across-194-countries/
Kudelski Security FortiBleed research: https://kudelskisecurity.com/research/fortinet-fortibleed-global-compromise-active-exploitation-of-fortinet-vulnerabilities

cyclone

Januscape: Linux KVM Guest-to-Host Vulnerability in x86 Shadow MMU

Januscape is a newly disclosed Linux KVM vulnerability affecting x86 virtualization hosts. Tracked as CVE-2026-53359, the issue is a use-after-free bug in the KVM/x86 shadow MMU code path. The bug is especially relevant for KVM environments that expose nested virtualization to untrusted guest VMs.

At a high level, this is a guest-to-host isolation issue. A malicious guest with kernel-level privileges inside the VM can trigger corruption in the host kernel’s KVM shadow page state. The public proof-of-concept is a host panic/DoS, but the researcher says the same bug has also been turned into a full guest-to-host escape in a controlled environment. That full exploit has not been publicly released.

The vulnerability was discovered and reported by Hyunwoo Kim, also known as @v4bel, and was reportedly used as a zero-day submission in Google’s kvmCTF program.

The root cause is in how KVM reuses shadow MMU pages. KVM keeps shadow page tables that mirror guest-controlled paging structures in certain modes. When nested virtualization is enabled, KVM may need to shadow the nested EPT/NPT structures built by the guest hypervisor. This forces execution through the legacy shadow MMU path, even on modern systems that normally use hardware-assisted two-stage paging such as Intel EPT or AMD NPT.

The vulnerable function, kvm_mmu_get_child_sp(), reused an existing child shadow page based on a matching guest frame number, but did not also verify that the shadow page role matched. In practice, two shadow pages can refer to the same GFN while serving different purposes. One may be a direct split page derived from a large mapping, while another may be an indirect shadow page for a guest page table. Reusing the wrong one breaks KVM’s internal reverse-map accounting.

Once that accounting is wrong, KVM may fail to remove the correct reverse-map entry when tearing down shadow pages. Later, when the relevant memslot or shadow page is freed, stale pointers can remain. When KVM later walks or cleans up those structures, it can dereference or write through memory that has already been freed. The public PoC drives this into a host kernel panic through KVM’s own corruption detection path.

This is not a QEMU bug. The vulnerable logic is in the in-kernel KVM implementation. That distinction matters because mitigations focused only on QEMU device emulation do not address this issue.

The practical risk depends heavily on the environment. The most concerning targets are:

x86 KVM hosts
Multi-tenant virtualization platforms
Cloud, hosting, CI, lab, or VPS environments
Systems where guests are untrusted
Hosts exposing nested virtualization to guests

The attack requires root or equivalent kernel-level control inside the guest VM, because the published trigger is implemented as a guest kernel module. In many cloud or VPS scenarios, that is not a strong limitation, since customers commonly have root inside their own guest. The more important exposure condition is whether nested virtualization is available to the guest.

The issue affects both Intel and AMD x86 systems because the vulnerable shadow MMU logic is shared across the KVM/x86 implementation. ARM64 KVM hosts are not affected by Januscape, although they have had separate KVM escape-class issues such as ITScape.

The vulnerable code dates back to commit 2032a93d66fa from the Linux 2.6.36 era, around 2010. The mainline fix is commit 81ccda30b4e8, which updates the reuse check so KVM compares the shadow page role along with the GFN. In simple terms, KVM now only reuses a shadow page when both the frame number and the role match.

Fixed stable kernel versions reported include:

7.1.3
6.18.38
6.12.95
6.6.144
6.1.177
5.15.211
5.10.260

Distribution backports may not line up cleanly with upstream version numbers, so admins should check vendor advisories and package changelogs rather than relying only on uname -r.

For operators, this should be treated as a high-priority patching issue if nested virtualization is exposed to untrusted guests. The safest remediation is to update the host kernel to a vendor-patched build and reboot into the fixed kernel.

If patching cannot be done immediately, disabling nested virtualization is the main mitigation for the guest-to-host path:

kvm_intel.nested=0
kvm_amd.nested=0

After applying that mitigation, reboot the host or reload the KVM modules only if no guests are running. On production systems, rebooting into a known-good configuration is usually the cleaner approach.

Useful checks on a KVM host include:

uname -r
lsmod | grep '^kvm'
cat /sys/module/kvm_intel/parameters/nested 2>/dev/null
cat /sys/module/kvm_amd/parameters/nested 2>/dev/null

Inside a guest, nested virtualization exposure commonly shows up as vmx or svm CPU flags:

grep -Eo 'vmx|svm' /proc/cpuinfo | sort -u

For Proxmox, OpenStack, VPS, and general KVM operators, the key question is not simply “am I running KVM?” The better question is: “Can an untrusted guest reach nested virtualization on an unpatched x86 KVM host?”

If yes, this deserves immediate attention.

The public PoC is intended to demonstrate a host panic and should not be run on production infrastructure. A successful crash can take down all VMs sharing the same physical host. A failed crash also does not prove that the host is safe.

This is one of those bugs where the operational risk is narrower than a generic remote kernel RCE, but severe in the right environment. For single-user local KVM labs, the impact may be limited. For multi-tenant x86 KVM infrastructure with nested virtualization enabled, it is a serious guest isolation failure.

Sources:

Januscape researcher repository: https://github.com/V4bel/Januscape
Openwall oss-security disclosure: https://www.openwall.com/lists/oss-security/2026/07/06/7
NVD - CVE-2026-53359: https://nvd.nist.gov/vuln/detail/CVE-2026-53359
The Hacker News: https://thehackernews.com/2026/07/16-year-old-linux-kvm-flaw-lets-guest.html

freeroute

Is a Duress Password Legal? The GrapheneOS Border Case

Short answer: yes, having one is legal. Using one is where the risk starts.

No law bans a duress password. The software that offers the feature is legal to build, legal to publish, and legal to install. But a US traveler is now facing a federal charge because his phone allegedly erased itself in front of border officers who were about to seize it, and the government’s theory is that typing a passcode you set months earlier still counts as destroying property to stop a seizure.

That is a genuinely new legal question. It is also, for almost everyone reading this, the wrong thing to worry about.

Our guide to phone and laptop seizures at airports and borders opens with the fantasy most people carry through customs: “When shit hits the fan, I will just wipe all data off my device in front of the border agents.” This case is what that sentence looks like when someone actually does it.

What a duress password actually does

A duress password is a second unlock credential that destroys the device instead of opening it. GrapheneOS, the hardened Android build for Pixel hardware, documents it plainly: entering the duress PIN or password anywhere the system asks for your credentials “will irreversibly wipe the device (along with any installed eSIMs).”

Three properties matter.

It is silent. There is no confirmation prompt, no countdown, no way to take it back. The screen goes dark and restarts.

It is total. The wipe destroys the encryption key material, so the data is not deleted in a recoverable sense. It is mathematically gone, and the project has said publicly that there is nothing they can do to help anyone recover it.

It has a trap. If you set the duress credential to the same value as your real unlock, the real unlock wins and no wipe happens. GrapheneOS documents that too, and it is the kind of detail people miss when they configure a feature they hope never to use.

What happened at Hartsfield-Jackson

On January 24, 2025, Samuel Tunick, an Atlanta resident, landed at Hartsfield-Jackson on his way home from abroad. Customs and Border Protection pulled him into secondary inspection and pressed him to unlock his Google Pixel. According to reporting by TechCrunch, officers told him no warrant was needed because he had not yet crossed the border. He entered a passcode. The screen went blank, the phone restarted, and its contents were inaccessible. Officers seized the device and let him into the country.

Roughly eighteen months later, prosecutors charged him under 18 U.S.C. § 2232, the federal offence of destroying property to prevent a government seizure. The indictment says he “did knowingly destroy, damage, waste, dispose of, and otherwise take any action to delete the digital contents of a Google Pixel cellular phone, for the purpose of preventing and impairing the Government’s lawful authority.” He has pleaded not guilty. The maximum sentence is five years.

His defense argues the stop and the seizure were unlawful, that he was repeatedly refused access to a lawyer, and that the government was investigating his association with an Atlanta environmental protest movement rather than any crime. A ruling on the motion to suppress is not expected before late October 2026.

Everything above is allegation and argument. Nothing has been proven either way, and this article takes no position on whether he did what the government says.

Why the charge, not the search, is the story

Warrantless border device searches are old news. What is new is the theory attached to this one.

Section 2232 prosecutions are extraordinarily rare. Tunick’s public defender has said only one other case of this kind is publicly known, and it came out of a drug trafficking investigation. Applying it here means a court has to decide whether a preconfigured operating system feature, triggered by typing a string into a prompt, is the same kind of act as smashing a hard drive on a table.

If the answer is yes, then a setting becomes an offence at the moment you use it. That is the part worth watching, whatever happens to this defendant.

Your rights at the border are getting thinner, not thicker

The legal ground moved in the same month the case became public, and it did not move your way.

On July 13, 2026, the Fourth Circuit ruled in United States v. Belmonte Cardozo that a manual search of a phone at the border is a routine search, so officers need no warrant and no suspicion at all to scroll through it by hand. As the EFF explains, the court kept a higher bar for forensic extraction, which still requires individualized suspicion in that circuit, but drew the line so that a human thumbing through your messages counts as ordinary.

Other circuits disagree, and similar cases are pending elsewhere. The compelled-passcode question under the Fifth Amendment is separately unresolved, with courts split on whether making you type your own passcode is testimony. The practical result is that your rights at an airport depend on which airport it is, and on a body of law that is actively changing.

You cannot plan around that. You can only reduce what is at stake when it goes against you.

What GrapheneOS said, and what it pointed at

The project’s response was unambiguous on the law. It called the feature completely legal, said it has no obligation to weaken the protections it ships, and argued that being forced to do so would be unconstitutional.

Then it did something more interesting. Asked about the case, GrapheneOS mostly talked about everything except the duress password, calling it “only one component” of the security model and listing what actually does the work:

hardware-backed encryption with rate limiting enforced by the secure element
support for passwords up to 128 characters
automatic reboot back to the Before First Unlock state after a set period, 18 hours by default, adjustable from 10 minutes to 72 hours
USB set to charging-only while the device is locked, which is the shipped default
memory tagging and other exploit mitigations against extraction tooling

Read that list again. Not one of those requires you to do anything at the counter. They are all already running while you stand in line, exhausted, being asked questions by someone with far more power in that room than you have.

That is the whole argument, and the project made it without quite saying it.

Passive protection beats active destruction

Screenshot 2026-07-31 at 12-25-44 Is a Duress Password Legal The GrapheneOS Border Case - PrivacyTools.io.png
The top three cost you nothing and are invisible. The bottom one is the only row on this table that has ever turned a bad afternoon into a prosecution.

A phone in Before First Unlock has never been unlocked since boot. Its keys are not in memory. It is the strongest state your device can be in, forensically, and reaching it costs one long-press before you join the queue.

So should you set a duress password?

This is not legal advice, and if you are in a situation where this question is live for you, the person to ask is a lawyer in your jurisdiction, before you fly rather than after.

With that said, an honest read:

If you already travel clean, it adds risk without adding protection. A device carrying nothing sensitive has nothing to destroy. You get the entire benefit of a wipe by simply not bringing the data, and none of the exposure.

Its real use case is coercion with no legal process at all. Robbery, kidnapping, a hostile actor with no warrant to seek and no court to answer to. In that scenario the calculus is completely different, and the feature is doing exactly what it was designed for.

The failure modes are worse than people expect. It is irreversible. It takes your eSIMs with it, which can leave you with no connectivity in a foreign country. Muscle memory under stress is unreliable, and the wrong finger on the wrong digit at the wrong moment ends the same way whether you meant it or not.

Having it set is not the same as using it. Nothing in this case suggests that configuring the feature is itself a problem. The alleged act was entering it after officers demanded access.

What to do instead

Do not bring the data. This is the whole game, and it is covered properly in the border seizure guide. Everything else on this list is a rounding error next to it.
Reboot before you reach the desk. One long-press puts the phone in Before First Unlock, which is free, invisible, and asks nothing of you later.
Shorten the auto-reboot window. If a device is seized while locked, a 30-minute timer means it locks itself down hard long before anyone gets it to a lab.
Leave USB on charging-only when locked. A plugged-in phone should not be able to talk to anything.
Use a password, not your face. The Fifth Amendment picture for memorized passcodes is contested but real. For biometrics it is considerably weaker, and a fingerprint can be taken from you without your cooperation.

If you run a hardened Android build as your daily driver, the same logic applies more sharply, not less. Read the full-disk encryption guide for what encryption at rest does and does not cover, and see our mobile operating systems picks if you are choosing a platform.

The lesson

The technical protections in a modern hardened phone are genuinely excellent. Against thieves, against remote attackers, against ordinary forensic tooling, they hold up.

What they cannot do is fix a legal problem. And the feature that gets the most attention, the one that promises you a way out at the last second, is the only one that asks you to make an irreversible decision at the worst possible moment, in front of the person you are trying to stop.

Privacy that depends on you performing correctly while frightened, jet-lagged and outnumbered is not a plan. It is a bet. The protections worth having are the ones already in place before you walk up to the desk, which is why the right time to think about any of this is when you build your threat model, not when someone asks for your phone.

hashpwn

Infosec News

Overview

Attribution & Targeting

Tradecraft

Mitigation

Sources