30
30
55
30
30
Linux Detection Engineering - Local Privilege Escalation
Elastic details a layered detection framework for Linux local privilege escalation, covering 2026's copy-on-write bug wave and LLM-assisted discovery.
Elastic Security Labs describes how most Linux local privilege escalations share a common host flow — an unprivileged process launched from a writable path becoming root — and proposes layered detections combining general outcome-based rules with per-technique rules in Elastic Defend and Auditd. It tracks 13 recent LPE disclosures, seven of which share a copy-on-write/zero-copy bug class, including Copy Fail, DirtyFrag, Fragnesia, DirtyDecrypt, DirtyClone, pedit COW, and RefluXFS. Qualys attributes RefluXFS to an LLM-assisted research effort with Anthropic using Claude Mythos Preview, and another bug is credited to an LLM-assisted workflow. Detection and endpoint rules are published in Elastic's detection-rules and protections-artifacts repositories.
48
When the Whole Company Adopts AI: What It Does to Your SOC
Analysis of 16.9 million SOC alerts finds AI-related alerts at 0.43%, growing 685% since February, with 94.1% noise and 0.02% real attacks.
A review of roughly 16.9 million SOC alerts found about 73,000 (0.43%) were AI-related, a share that grew 685% between February and June 2026. Of AI-related alerts, 94.1% were noise, 5.8% genuine risks, and 0.02% real attacks; 79.8% received benign verdicts, 81.7% were automatically suppressed, and only 5.4% reached a human analyst. The only confirmed attacks were phishing campaigns that weaponized AI brand names as lures, while developer coding agents spawning shells and reading credential stores routinely tripped detections written before AI agents existed.
45
30
55
30
30
The Machine With Many Faces: Post-Exploitation Identity Misuse in SPIFFE/SPIRE
Unit 42 demonstrates that root access on a Kubernetes node lets attackers spoof SPIFFE/SPIRE attestation and harvest co-located workloads' SVIDs.
Palo Alto Networks Unit 42 describes post-exploitation techniques in which an attacker with root on a compromised Kubernetes node spoofs Linux cgroup metadata used by the SPIRE agent during workload attestation, tricking it into issuing a co-located workload's SPIFFE Verifiable Identity Document to an attacker-controlled process. The research shows the core trust assumption of machine-identity systems—that the node is trusted—collapses once root is obtained, exposing all cryptographic identities scoped to that node. Unit 42 released an open-source tool, Spooffe, for defenders to test identity exposure, and notes the technique has not been observed exploited in the wild.
45
Harnessing LLMs for Automating BOLA Detection
Unit 42's BOLABuster methodology uses LLMs to automate detection of broken object-level authorization vulnerabilities, uncovering flaws in Grafana, Harbor, and Easy!Appointments.
Palo Alto Unit 42 details BOLABuster, a methodology combining large language models with heuristics to automate detection of broken object-level authorization (BOLA) flaws, which traditional fuzzing and static analysis struggle to find. The approach uses LLM reasoning to understand application logic, map endpoint dependency relationships, and generate and interpret test cases. It found CVE-2024-1313 in Grafana, CVE-2024-22278 in Harbor, and 15 CVEs in Easy!Appointments. The team is continuing to hunt for BOLAs in open-source and internal projects.
45
30
30
30
30
Forgery of C2PA on a Pixel 10
Researcher forged a Google Pixel 10 C2PA content credential with genuine signatures, showing root-level attackers can fake photo provenance.
A Hacker Factor blog post demonstrates an AI-generated 'unicorn glitter milk' news photo carrying a valid, cryptographically signed C2PA manifest traceable to Google's Pixel camera certificate chain, passing validation in Adobe Inspect and the CAI Verify tool with a verified timestamp. The author, working with UMBC's PASAWG working group, reported to Google and C2PA in November 2025 that root access on a Pixel device could sign arbitrary images as camera captures; after 90 days without resolution, details were published. The finding undermines C2PA Assurance Level 2 claims made for Pixel 10 Content Credentials.
38
Hackers Turn Windows Shadow Copies Into a Tool for Credential Theft and Ransomware
Attackers abuse Windows VSS shadow copies to delete recovery points before ransomware and to extract NTDS.dit/SAM credentials, demanding context-aware detection.
Threat actors are weaponizing the Volume Shadow Copy Service (VSS) for two purposes: destroying local recovery points via vssadmin.exe, wmic.exe, diskshadow.exe, wbadmin.exe, and bcdedit.exe before encryption, and accessing static copies of locked files such as NTDS.dit and SAM for credential theft. Ransomware families tied to shadow-copy removal include Akira, Black Basta, BlackCat, Conti, LockBit, Qilin, RansomHub, REvil, Ryuk, and WannaCry. Huntress's analysis of the Nightmare-Eclipse tool showed the BlueHammer technique chaining a Windows Defender timing issue with a VSS snapshot to dump the SAM database and decrypt NT hashes. Defenders should correlate VSS operations with parent process, hive access, and subsequent encryption activity, and maintain immutable off-host backups.
52
Don't Trust the Super-App: A Case Study of Russia's Max
Researchers show super-apps like Russia's Max can silently capture mini-app UI, storage, network traffic, and authentication, enabling untraceable user impersonation.
The paper challenges the assumption that super-apps are trusted intermediaries, citing WeChat's passive cross-mini-app tracking, Russia's Max's entanglement with state prosecution of online speech, and Iran's Bale operating during a prolonged internet shutdown. Using Max as a case study, the authors demonstrate that a super-app can capture mini-app UI, read and write mini-app local storage, inject arbitrary JavaScript into mini-app runtimes, mediate network traffic, and control authentication context, enabling silent user impersonation without trace. They argue these capabilities are inherent to the super-app architecture and call for mobile OS and app store interventions to close the blind spot.
48
Has anybody seen my keys? A key-hierarchy strategy for rack-level security
Oxide's RFD 0301 proposes a rack-level key hierarchy using Shamir secret sharing and a trust quorum to protect data-at-rest keys.
Oxide's request for discussion (RFD 0301) lays out a key-hierarchy strategy for rack-level security, deriving keys from a rack secret protected by Shamir secret sharing across a trust quorum of sleds, with keys exchanged over authenticated sprockets sessions. The document maps which keys protect control-plane data, metrics, Crucible extents, and authentication tokens, and defines open questions on key lifecycle, locality, and compromise handling. Future work includes sealing shares with the root of trust so an attacker would need to steal K whole sleds to reconstruct the rack secret.
28
30
30
30
42
30
55
55
30
30
30
30
30
30
30
42
30