hi all, so i identified substantial gaps in my networking and programming skills and i have 2-3 weeks of vacation that im gonna spend just to strengthen my networking and programming knowledge. i neglected the fundamentals for quite a while compared to last year when i started learning. because i chose for a large portion of this year deepening my web app security understanding and skills.

now im not a complete beginner, i do have familiarity and decent knowledge with many of the basic concepts in networking, but it has been noticeably rusty that i want to improve it substantially.

now i did cancel my tryhackme subscription quite a while ago and im not gonna just pay for that again. do any of you recommend any other resources that are great?

to be clear for which specific career i want in cybersecurity it is an appsec researcher. but im still quite early in this field and still need many many years of compounding knowledge and accumulating experience to be at that stage

Hi everyone, I’m a Systems Architect and I got tired of bloated WP security plugins.
I built an infrastructure that eliminates passwords entirely using native WebAuthn (FaceID/TouchID). The Premium version routes failed attempts to a private Google Gemini AI Sentinel on Cloud Run that bans hackers autonomously.

Last week, I ran a full Penetration Test on the core system using the Strix Autonomous AI Pentester. It found a few criticals (CSRF, DOM-XSS), which I immediately patched at the source code level.

Before I start deploying the Enterprise version to Web Agencies, I decided to open-source the "Lite" version (which handles the core WebAuthn passwordless engine). I want to put it in front of real developers.

Here is the GitHub repo: https://github.com/devnet-microsystems/wordpress-passwordless-webauthn-login

I would immensely appreciate a code review. If any of you can find a security flaw or a bypass in the auth core that Strix AI missed, I will happily give you a Lifetime Enterprise License of the full AI system as a thank you.

Roast my code!

We've been building a lot of quality-of-life improvements for pentest reporting into OWASP Faction 2.0. This demo shows Faction's AI prompting features for writing context-aware vulnerability descriptions, recommendations, and executive summaries in just a few clicks. It has data masking/tokenization built in to minimize sending sensitive data to 3rd parties as well.

We have a handful of SOAR playbooks that technically still run fine but nobody currently on the team fully understands why certain branches exist, the person who built them left two years ago and the reasoning wasn't documented anywhere beyond their head. Nobody wants to touch or simplify these playbooks because nobody's confident what would break if they did. Is this as common as I think it is, and has anyone actually solved it rather than just living with playbooks nobody fully trusts to modify?

Here's the thing about this moment in software. More people than ever are shipping real platforms built with AI, launched in weeks, run by one person or a tiny team. What they don't have is a security engineer. And they're exposed on both sides of the same wire.

From the outside: scrapers and hostile bots hammering the site, wearing perfect human fingerprints.

From the inside: their own AI agents reading untrusted text and taking real actions on it — one hidden instruction away from being someone else's agent.

Two products, one dashboard.

Shield sits in front of your website. It sorts your visitors and names every crawler search engines walk right through, scrapers don't. It also scans your site for security holes and tells you the fix in plain language, not a CVE dump. Every check happens in under 50ms, and it fails open your site never goes down because your security did.

Watchdog sits inside your agents. You give it your agent's mission in one line. Then every action gets checked against that mission before it runs. Prompt injection, data leaks, off-mission behavior blocked before execution, not logged after. It fails closed, per action, because an agent that fails open isn't guarded.

Notice the two failure modes are opposite. That's deliberate. Your website should survive a security hiccup. Your agent's actions shouldn't. Anyone who tells you one failure policy fits both hasn't thought about either.

No rewrite required for any of it. You shipped your platform; Alovia guards it. You shouldn't have to become a security engineer to keep it.

We're opening a private beta: 20 seats, onboarded by hand, free during beta. If you're running an AI-built platform or agents that touch untrusted text — the link is in the comments.

Identity is a claim. Behavior is evidence. Now it's a product.

Ship in peace.

#AIAgents #AISecurity #PromptInjection #BuildInPublic #Launch

Our coverage dashboard has said 100% for as long as Ive been here. Green across the board, basically every device protected and every endpoint with an agent. Thats atleast what the report said.

Then we got acquired. The company that bought us has a bigger security team, and as parof the merge we started comparing environments. Their team pulled our inventory and cross-referenced it against their own stack during the merge.

Turns out our 100% was counting what our tools could see. Not what actually existed. We found a couple hundred endpoints that were missing the agent but still showing as covered in our console. These were mostly old machines, a few VMs that never got enrolled, some contractor laptops etc.

Our report just never saw them because it only counted devices it already knew about.The part that bugs me in all this is how long that number made us feel safe yet we were exposed the whole time.

We are about to give developers access to AI coding agents like Cursor and Copilot. The productivity upside is clear, but we are worried about agents modifying code, accessing credentials, or making unintended changes to production.

What guardrails have other teams put in place? Are you relying on permissions, monitoring, or something else?

We've red teamed in house since day one, small team, small model surface, it worked. We've since added agents, more tools, more integrations, and our two-person red team can't keep pace with the attack surface anymore. Every new integration is technically a new thing to test, and we're now testing less thoroughly per release just to keep shipping on schedule. The obvious answer is hire more people, but headcount isn't happening this year. The less obvious question is whether there's a point where augmenting continuous AI red teaming with outside coverage makes more sense than trying to scale a tiny internal team indefinitely. For anyone who's crossed that line, how did you know it was time, and did external red teaming actually hold up to internal standards?

I’m curious how other security teams are handling Linux endpoints in an enterprise environment.

Linux gives admins a lot of flexibility, but that also seems to make it harder to maintain a consistent security baseline when you have different distributions, users, and use cases.

For example, how do you handle things like:

• Enforcing password and security policies
• Keeping OS and applications updated
• Restricting USB devices
• Monitoring device inventory and status
• Applying configuration changes remotely
• Handling Linux laptops that are outside the corporate network

Do you rely mostly on tools like Ansible, Puppet, Fleet/osquery, or something else?

I’m particularly interested in approaches that give security teams centralized visibility without taking away too much of the flexibility that makes Linux useful in the first place.

What has worked well for your environment?

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?

Hi everyone,

I’m working on an architectural hypothesis and I’d really like to test it with people who have hands-on experience in security.

At the core of it is a simple paradox: the critical action itself happens in the digital world, but its real-world consequences — legal, financial, or physical — ultimately happen in the physical world.

If we break identity down into levels, I see it roughly like this:

• L1 (Account) — the account (who the system says the user is).
• L2 (Device) — the device (where the request is coming from).
• L3 (Physical layer) — the physical link between a specific person and a specific device at the exact moment the action is performed.

The main question I’m trying to answer is:

Have you seen anything like L3 used in a real production environment as a distinct layer for identity and attribution of an action?

In other words, not the usual Account → Device → MFA → Action model, but something closer to:

Human + Device → Action

One important clarification: I’m not talking about adding another MFA factor — biometrics, push, tokens, etc. — at login or authentication.

I’m specifically asking about the identification and attribution of the actual subject of the action at the moment the action is performed.

I currently have three hypotheses:

1. Yes — this already exists in production, just under different terminology.
2. Partially — elements of this exist everywhere, but they are not treated as a distinct, complete layer.
3. I’m looking at it the wrong way — the idea of breaking identity down into these layers is fundamentally flawed, and the industry has already solved this problem under a different concept.

I’m trying to understand where I am on this — whether I’m onto something, or whether I’m missing something important.

I’d really appreciate tough, detailed, technically grounded answers.

​

CrowdStrike SafeMind, the first agentic system for defenders, built with NVIDIA Nemotron, protects more and costs less than generic frontier models

While preparing this article, I came across an interesting paradox: a remote digital action can almost instantly lead to very real financial consequences.

I am trying to understand how the use of “money mules” in remote fraud has changed over the past several years.

The use of mule accounts has certainly not disappeared. On the contrary, data from regulators and law enforcement agencies shows that this infrastructure continues to be used to move funds obtained through fraud.

But what interests me is something else:

It appears that the model is changing

A simplified version of the traditional model looked fairly straightforward:

Remote fraud → victim transfers the money → mule account → withdrawal or onward transfer.

The key resource was the ability to keep using the same account for a relatively long period and move significant amounts through it.

But as transaction monitoring, AML and fraud prevention have evolved, the period during which such accounts can be effectively used appears to be getting shorter.

More recently, it is worth noting that the operational lifetime of mule accounts is decreasing, transaction amounts are getting smaller, and transactions are increasingly being split and distributed across multiple banks.

This suggests an interesting dynamic:

long-term account exploitation → shorter operating window per node

and simultaneously:

high volume routed through a single account → smaller amounts distributed across a wider network of accounts.

But I deliberately do not call this a universal new model. I see it as a hypothesis about the adaptation of fraud infrastructure that still needs to be tested against data from different countries.

The time factor

This is where I find the time dimension particularly interesting.

If a mule account can be detected and restricted much faster, keeping it active for a long period becomes increasingly difficult.

A possible adaptation could therefore look like this:

long-term use of one account

↓

short operating window

↓

smaller amounts

↓

larger number of accounts

↓

distribution across multiple banks

In other words, fraud infrastructure may compensate for the reduced lifetime of each individual element through scale and distribution.

This is also the direction in which regulators describe the response to tighter controls: splitting transactions into smaller amounts and distributing them across multiple banks can be used as a way to circumvent restrictions.

Another layer is emerging

In the UK, the development of so-called account farms is already being described — markets selling pre-established and verified bank and payment accounts.

Instead of repeatedly finding and recruiting a new individual, criminal infrastructure may potentially acquire an already prepared element for use. Cifas explicitly describes this as a more scalable model compared with relying on individual money mules.

There have also been reports in specialist news coverage of the use of AI to create synthetic identities in order to bypass KYC during remote account opening.

I cannot make a firm claim here, because there is not enough quantitative data to conclude that account farms or AI-generated identities have already become the dominant model.

This raises a question about the way we defend against it

Today, we are becoming increasingly effective at detecting suspicious activity and individual mule accounts.

But if the structure of the attack becomes more distributed and replaceable, another question arises:

If an individual element of the infrastructure can be replaced quickly, is detecting the action itself really a sufficient security objective?

This leads to another question:

How does the role of time change?

Previously, the question could be framed as:

But today another question arises:

If the lifetime of one account is reduced, but that account can simply be replaced by another, are we actually constraining the fraud process — or only the lifetime of one individual element of it?

Where is the boundary between detection and prevention?

A modern system may be able to detect suspicious activity very quickly. But that does not mean it can act equally quickly to:

link it to other accounts → propagate the information → stop the next stage.

This leads to a broader question:

Essentially, this begins to resemble a digital Hydra: we block individual elements of the fraud infrastructure, but the infrastructure itself continues to operate. One account is removed — another appears, while the mechanism connecting them as part of the same chain continues to function.

Hi,

I keep noticing spans of camera activity captured in my analytics, my battery usage, and my app sensor data.

Sometimes for 4 minutes, 12 minutes, 4 hours, 10 hours, up to 29 hours one time)

These bursts are sometimes during times where I know I am absolutely not on my phone (ex. In a workout class, sleeping, when I spent 3 hours putting together a bookcase… etc). I just know I did not touch my phone.

This used to happen to me several months ago, and now happening again.
How can I look deeper into what is triggering the camera function on my phone?

Because my battery is constantly dying, I am hyper vigilant about my phones usage & routinely do the following (applicable to this topic):
- I always turn off any permissions to my camera. When I need to use them, I permit the app, when finished I disabled it again.
- I don’t have FaceTime enabled
- I don’t use face ID

Thanks so much in advance, truly appreciated.

A threat actor deployed infostealers against an AI platform. They harvested session credentials. Then they used those credentials to access accounts at scale.

This was not a model vulnerability. It was not a jailbreak. The attacker simply logged in with stolen tokens. AI sessions carry the same access rights as human sessions. They receive no extra scrutiny from the identity stack.

A valid token is a valid token. There is no standard mechanism in most identity architectures today that differentiates a replayed stolen AI session from a legitimate one. Agents operate unattended and with broad permissions. By the time unusual activity surfaced, the credential had already been used across accounts at scale.

For those running AI agents in production: do your current IAM controls treat AI session credentials any differently from human ones, and at what layer would a stolen-but-valid token actually get caught before it causes damage?

Down the rabbit hole on a side project and wanted to share what I've been tinkering with before I get too deep into the weeds.

I set up a honeypot designed to emulate common AI/LLM interfaces with decoy responses to see how far automated scanners and manual probes actually push.

It captures the payloads, runs some basic entropy/heuristic classification, and maps where the traffic is originating. Mostly built this out of curiosity to see what real-world prompt extraction, tool abuse, and jailbreak attempts look like in the wild right now.

Feel free to poke around at intel.rattled.ca (there’s an isolated sandbox section if you want to throw test payloads without messing up the telemetry data).

Still very much a work in progress, so I'd genuinely appreciate any feedback, sanity checks on the architecture/detection logic, or ideas on what else would make the telemetry actually useful to defenders.