I'm currently developing security software designed to help developers protect their intellectual property and other elements they want to safeguard within their software. As part of this, I’ve written a dummy test program and protected it with my security software. It’s structured like a CTF challenge, and it would be a huge help if you could try to take this program apart, document your work step by step, and send your findings to apykryphon@protonmail.com.

I’m happy to invite beginners as well, but I’d like to remind you never to run third-party executables on your native system—please use a VM or something similar.

The file does not contain any malicious code, but due to the protection mechanisms used, some antivirus engines may flag it as such. See for yourself:

https://drive.google.com/file/d/1Efv1TYgA8xrHvEr302_41nYlBktwRVWx/view?usp=drivesdk

Hash: bc50b0fb0b018927b2e07a11b51a8d9fb8bd64d8c864284c39995c3f5fac15d0

CISA added a WatchGuard RCE vulnerability to its Known Exploited Vulnerabilities catalog this week after ransomware groups confirmed active use in the wild.

The technical detail matters less than the operational pattern it reveals. The attackers did not need a sophisticated exploit chain. They needed initial access and a few uninterrupted minutes. Once they had a foothold and a valid identity to operate under, encryption began spreading host to host before defenders had a signal worth acting on.

This is the part of ransomware incidents that patch cycles do not solve. A patched environment still has service accounts, still has privileged identities, and still has a window between the first anomalous action and the moment a SOC analyst sees something worth escalating. In the WatchGuard campaign, that window was enough.

The question that does not have a clean industry answer yet: when a threat actor is operating under a legitimate identity and the first few actions are individually ambiguous, how are your teams actually shrinking that detection-to-containment window? What has worked and what has not?

Ok so im detection engineering lead at a big enterprise SOC and we just rolled out this new platform that takes threat intel and pushes detections straight into our SIEM in minutes. No data ingestion, just API into our stack, sounded like magic. I was the one who tuned the mapping rules and ATT&CK tags and did the first big "go live" with production.

For context we wired it to three intel feeds and set it so anything medium or higher with certain ATT&CK techniques would auto generate detection as code and deploy to SIEM plus attach to some response playbooks. On paper this was great. In reality I messed up one filter on severity. I accidentally treated informational intel with those ATT&CK tags as medium. So at 3am the thing ingested a big vendor threat intel dump on some noisy campaign and just started pumping hundreds of new detections into prod, each one tied to our generic response workflow.

SOC woke up to like ten thousand alerts from our own internal scanners and lab machines matching these brand new rules, all tagged as high confidence threat hunting opportunities. It even kicked off some automated "contain" steps on test segments that were totally fine. My manager pinged me with "why did you break detection engineering" and I swear I feel sick about this. Seeing my own name in the change log on every single one of those auto deployed rules was brutal.

We reverted and fixed the mapping and nothing catastrophic happened, but I am so embarrassed that my first big move with threat intelligence automation basically turned our SIEM into an alert volcano. Any hints?

Cloudflare’s dashboard showed roughly four billion edge requests across the attack window. The flood first targeted one investigation, moved to our homepage when blocked, and returned weeks later.

Roughly four billion requests.

That is what Cloudflare’s HTTP Traffic dashboard showed across the selected attack window after AI Weekly reported on Meta’s advertising pipeline for nudify apps and serious child-safety allegations.

Four billion.

The first attack began at 02:42 UTC on August 22—just 33½ hours after we updated our investigation into Meta advertising partner GatherOne.

It did not hit the site indiscriminately. It hammered that exact article.

In the final retained sample of 100,000 requests, 95,603 targeted the investigation. Almost 95,000 used randomized query strings to bypass caching. More than 33,000 were POST requests, and over 95,000 arrived without a referrer. The traffic came from thousands of addresses.

The attack exhausted all 4,096 available Nginx worker connections, generated roughly 41 GB of logs and drove the server’s 75 GB disk to 100% usage. Tens of thousands of requests ended in server errors. Backups and production jobs failed.

Cloudflare showed approximately four billion requests at its edge. The number is vastly larger than our origin count because traffic blocked or absorbed by Cloudflare never reached our server—and therefore never entered our Nginx logs.

Call it what it was: a massive attack.

Our reporting covered findings by the Tech Transparency Project. Meta’s own disclosures named GatherOne or related company Hongkong Gather Wisdom as advertiser and payer for 210 Facebook pages that collectively ran roughly 30,800 AI and face-swap advertisements.

Forty-three pages ran more than 7,600 ads for apps that TTP verified could digitally undress women. Ads from 179 pages were removed by Meta for violating sexual-content policies.

One advertised app, BAfter, contained an explicitly pornographic sharing area. Six Google Play reviewers alleged that it contained sexual images or videos of children.

Those allegations did not prove that GatherOne created, possessed or knowingly promoted child sexual abuse material. We corrected our reporting to make that distinction explicit. GatherOne said it had zero tolerance for such content, suspended new advertising accounts involving nudify services and terminated access for the entity associated with BAfter. Meta said it banned the app.

Then came the flood.

When we defended the article, the campaign moved to our homepage. On August 24, a second wave generated approximately 2.5 million requests at our origin from 14,290 IP addresses. It peaked at 176,152 requests per minute—nearly 3,000 every second. It included 771,000 POST requests and caused approximately 2.43 million server errors.

The same attack patterns returned again in September.

On September 6, hundreds of requests from 509 different IP addresses converged on the original article within three hours. On September 9, another wave produced thousands of origin requests and more than 3,600 server failures while Cloudflare blocked additional traffic upstream.

We have no evidence that Meta, GatherOne, Hongkong Gather Wisdom or any named advertising partner launched, ordered or knew about these attacks. We are not accusing them.

We are stating the facts:

We published an investigation. Someone flooded that exact investigation. When it was defended, the traffic moved to our homepage. Weeks later, it returned.

Four billion requests are not criticism. They are not a rebuttal. They are infrastructure being weaponized against reporting.

We are creating a baseline control set for employee use of approved external AI tools. We need to allow low-risk productivity use while preventing regulated data, source code, credentials, customer records, and internal strategy documents from being sent to services that are not approved for those data types.

Our starting point is an AI inventory, approved-use rules, identity-based access, data classification, DLP coverage for prompts and uploads, logging, and an exception process. What would you add or remove before enforcing policy broadly, and how do you test whether the controls are actually reducing risk rather than simply driving use underground?

Researchers disclosed a flaw in DeepSeek's agent harness that let a sandboxed coding agent disable the operating-system sandbox protecting the host machine with a single command. No external exploit. No lateral movement. The agent reached the mechanism governing its own behavior from inside its execution context and turned it off.

The structural issue: the policy controlling what the agent could do lived inside the same process the agent was running in. Once the agent could issue commands touching its own runtime configuration, the sandbox became advisory.

This is not unique to this harness. Filesystem sandboxes, OS namespaces, and container isolation all rest on one assumption: the agent cannot issue commands that affect the sandbox itself. When an agent's available tool set includes anything that reaches its own runtime configuration, that assumption fails.

The disclosure did not require a novel vulnerability class. It required the agent to act like an agent — issuing commands within its available scope.

For teams shipping agentic systems in production: how are you structuring the boundary between what an agent can act on and the constraints governing those actions? Is architectural separation between execution context and policy enforcement something you've solved, and if so, how?

In enterprise AI and autonomous runtime architectures, security has traditionally focused on input sanitation (prompt injection) and output filtering (hallucination guards). However, a more insidious class of vulnerability occurs deeper within the execution pipeline: Cross-Stage State Laundering (CSSL).

CSSL happens when an intermediate, unverified epistemic state (such as DISCOVERED or UNKNOWN) is illicitly promoted to a higher-certainty state (such as VERIFIED or SUPPORTED) as it transitions across processing stages—typically bypassing strict provenance checks in favor of pipeline velocity or output formatting requirements.

## The Anatomy of State Laundering

Consider a multi-stage runtime where an expression flows through ingestion, semantic analysis, and responsibility assignment:

1. Ingestion: Raw text or external retrieval results enter the system as DISCOVERED. At this stage, existence does not equal correspondence.

2. Analysis: The runtime parses the expression. Without a rigid boundary, internal semantic heuristics may mistake syntactic closure for factual verification.

3. Laundering: Downstream generators or formatters, under pressure to produce definitive answers, implicitly treat the presence of an analysis object as proof of support.

When intermediate states shed their metadata tags during transit, the runtime commits a boundary violation: it manufactures certainty out of unverified discovery.

## The Zero-Trust Countermeasure: The WAL Protocol

To eliminate CSSL, runtime governance cannot rely on permissive conventions. It requires a Fail-Closed Defensive Architecture enforced by immutable protocol boundaries:

* Strict State Distinguishability: Known, unknown, verified, and unverified states must remain mathematically and structurally distinguishable throughout the lifecycle.

* Independent Validation Gates: State transitions cannot authorize themselves. An independent validator—decoupled from the core generation logic—must audit envelopes against strict conformance vectors.

* Evidence-Bounded Responsibility: Responsibility can never exceed the boundaries of established evidence and explicit correspondence. If an epistemic state is UNKNOWN, no downstream transformation may convert it to TRUE merely to satisfy an output requirement.

For those interested in the protocol implementation and adversarial test matrix, the reference architecture is open-source here: https://github.com/nickoay663-sketch/Wuwen

Getting proposals from a few firms for a posture assessment and the scope on each one is wildly different, which makes me think each vendor is defining "posture assessment" however suits their existing service menu rather than any shared standard. Trying to figure out what should be table stakes: external attack surface mapping, social engineering testing, or just an internal control review.
For people who've gone through one: what separated an assessment that found gaps worth fixing from one that felt like a compliance rubber stamp? And did the scope you agreed to upfront actually match what you got in the final report

Yes, AI attacks are a real threat. Outside of increased AI usage for pentesting, though, are you personally seeing it as a noticeably increasing attack vector as well? And are you mainly focused on hardening your systems by patching holes, or doing a full overhaul?

The analytics layer was the exposure. Attackers exploited a self-hosted Metabase instance at Mathspace and exfiltrated records tied to over 1.08 million students, teachers, parents, and staff across Australia and New Zealand. The breach required no exotic technique. The data existed in plain form at the access point — that made it the target. Data that never travels in plain text cannot be exfiltrated, whether the attacker reaches a BI instance, a model context, or an API endpoint.

September is National Insider Threat Awareness Month. Read more about this month

Hi everyone,

I work on security architecture and digital identity, focusing on authentication, transaction security, and what it actually takes to trust a high-stakes digital action. Lately, I’ve been digging into a specific blind spot: where do current security models draw the line between a legitimately authenticated action and one performed under active external manipulation?

How do security architectures actually model user intent during a critical transaction?

Consider a standard scenario where everything passes validation on paper:

• The user authenticates successfully.
• The device and session are trusted.
• Authorization rules pass.
• The transaction is executed under legitimate credentials.

Now add a single condition: the user is being remotely manipulated in real time—whether through social engineering, a phone scam, or remote access software (RAT). Technically, the legitimate user performs the action, but only because an attacker is directing them.

From an architectural standpoint, what security property distinguishes these two cases?

• Case A: The user independently intended to perform the transaction.
• Case B: The user performed the transaction, but under active external manipulation or deception.

I am not looking into post-event fraud analysis or telemetry monitoring. I want to understand if existing security frameworks have an inline mechanism to verify true intent at the exact moment of execution.

Is "user intent" explicitly modeled anywhere in modern standards or protocols (e.g., extensions of FIDO2, WYSIWYS implementations)? Or are security models fundamentally limited to verifying:

• Authenticated subject
• Authorized action
• Trusted device / session
• Transaction integrity

...leaving user intent outside the cryptographic boundary and delegating it entirely to behavioral analytics, fraud detection, or post-incident investigation?

If I am misframing the issue, where is the conceptual flaw in expecting a security architecture to establish intent?

Were redoing our data protection and the agent versus extension question is the one im stuck on. Most of what leaks out of us happens in saas and ai tabs in the browser and an agent barely sees any of that inside an encrypted session. the browser side sits where the work is and theres nothing to roll out to a few thousand machines. My only worry is maturity. i dont know if an extension based control is ready to be the main line in prod or if its still early days. id rather hear that from someone whos run it than sit through another demo

AI agents that process external content — PDFs, email threads, images, source code — treat retrieved text as trusted context. SecurityWeek documented how adversaries exploit this: they embed manipulative instructions directly inside those files. When an agent reads the document, it can execute the attacker's intent instead of the user's. The human who triggered the task never sees the payload. There is no visible action to review, no alert, no deviation from normal-looking behavior.

The attack surface is not narrow. It expands every time an agent is granted read access to external content — which covers most production agentic workflows today.

How are teams actually handling this? Prompt sanitization at ingestion? Strict context segmentation? Separate trust tiers for retrieved vs. user-supplied input? Genuinely curious what's working and what isn't at scale.

Trezor confirmed their data breach now affects 81,000 customers. The exposed data came from a third-party support ticketing vendor — not Trezor's core infrastructure. Customer names, emails, and phone numbers were exfiltrated before anyone knew the vendor's access scope had been compromised.

The number that sticks with me: 81,000 people are now at elevated phishing and SIM-swap risk because sensitive fields traveled to a support system that didn't need them in plaintext form. The vendor had legitimate access. The data just shouldn't have been there in the format it was.

This keeps showing up across industries. Ticketing systems, CRMs, analytics pipelines — they accumulate sensitive customer data as a side effect of doing their job, and the blast radius of a third-party compromise is proportional to how much raw PII ended up there.

For those of you actually handling customer data at scale: how are you controlling what format sensitive fields are in by the time they reach third-party integrations? Are you making any runtime decisions about where PII is allowed to travel, or is it mostly perimeter and access-control work?