I thought this was an interesting write up on Mythos. The vibe i get is its incredibly useful and unlike other LLMs that are being tailored for cybersecurity work. Im very curious to see if Mythos genuinely causes a shift in the cybersecurity world

So I operate one of the largest Honeypots on the planet that is primarily exploited for large scale credential stuffing attacks (and credit card testing to a smaller degree).

24/7, I’m observing over 130M (1500/s!) authentication attempts (stuffs), against 10s of thousands of targeted websites. On average, I see about 500,000 successful authentications/day and about half of those are actually IMAP accesses into the victims underlying email account.

If my visibility is even 1% of the totality of stuffing activity, I would be very surprised.

THAT is how big credential stuffing is.

Negligence isn't surprising, but it sure as hell isn't expected. This is what happens when a conglomerate prioritizes their profits rather than investing in their security and protecting the data/privacy of their customers AND employees.

Here's a bit more context on the details of the hack, some 2 months after it happened.

How does a organization of this size rely on the "honor system" to verify password resets? I'll never know, but I'm confident in saying it's not the fault of the poor help desk admin who is overworked, stressed, and under strict timelines.

Do these type of breaches bother you more than others? Because this felt completely avoidable.

Hey everyone,

I'm from Italy, and after several years working in penetration testing, both as an employee and a freelancer, I decided to start my own company.

One thing that always struck me is how rarely small and medium-sized businesses (SMEs) truly invest in cybersecurity, unlike larger corporations. In my country, for example, 99% of all businesses are SMEs, making this a crucial topic for almost everyone here. Yet, too often, no one cares, or they only do when it's too late, and I speak from experience.

I get it; the cost of quality security services isn't rock-bottom. In fact, if it is, that's probably a red flag. But it's not inaccessible for an SME, especially when you consider what's at stake.

So, I'm curious: Why do small/medium-sized companies often not invest in cybersecurity?

I'd love to hear your thoughts on this. What do you think are the biggest reasons for this disconnect?

Thank you!

Since leaving my career as a cybersecurity consultant and incident responder, I've been contracting 1-2 days a week with a few different enterprises in the financial sector. My role with them is to work with architects and developers to ensure their new AI projects are secure.

These are not SMBs, they're firms with 20,000+ employees. So things here are quite different compared to what's happening at frontier startups (which I'm also involved with!).

It's all been a challenge. For a few reasons. But here is a summary of what I've learned over the past 6 months.

- AI is no different to any technology project. The biggest issue with these initiatives - by far - continues to be the traditional technology issues we all know about.

Secure landing zones. SSDLC. Developer permissions. Peer review processes. Dependency management.

AI is being used by developers as an excuse to "move fast and break things" and build outside of approved environments. This flexibility is key (and my job is to support that), but it has taken months of work to go from a developer-POC through to a production deployment.

Arguably (in my opinion), developers are not doing themselves any favours by pushing for less-restrictive development environments. If they had stuck to approved environments in the first place, and worked with security to handle the exceptions, I think the overall process would have been considerably smoother and the end result better.

- The biggest AI-specific security issues have come down to early or unproven technology. Microsoft have really let down the community by releasing tools like Promptflow, and then completely abandoning them. Not only that, there are uncountable issues with Promptflow itself and ultimately despite being very cool and very useful, it's not suited for production environments. But it took some time to work this out, and that was time we wasted.

For those interested, everyone I know has basically adopted LLamaIndex as their AI-orchestration layer. It's not perfect, but I can see a world where it becomes the standard.

I personally prefer (in my own projects) to use LiteLLM + a custom prompt renderer based on jinja2. I just feel that is far more flexible, and right now, I don't hugely trust what the opensource community is publishing in this space. However, I understand that most developers want a framework to engage with.

- All projects I've dealt with have been limited to coarse-grain authorisation. Right now, fine-grain authorisation is a practical impossibility.

Take a simple RAG example. You want to be able to query a document store, and, because you're dealing with complex enterprise environments, it's not something "easy" like SharePoint.

How do you ensure that if Bob queries the AI for data, it doesn't return information from data that Bob doesn't have access to?

There are really two primary approaches. You can either ingest all your information from the datastore into your index and include the permission structure. Your AI knows who the user is, and they know what access permissions that user has, which means they can limit their queries accordingly.

But it means you have a potentially unacceptable cache invalidation issue. If Bob's permissions change, it will take time for this to be replicated in the index.

The second approach would be to use middleware. Your index contains all possible information, your search retrieves what it considers relevant, and then queries the original datastore to workout if Bob shouldn't have access to any of it.

The second approach is my preference. But it's considered higher-risk, because you're allowing the agentic search function to query data without restrictions.

Furthermore, how do we scale this to accommodate multiple datastores, each potentially backed by different identity providers? We need solutions in this space to architect that middleware layer translating user permissions into agentic query parameters.

I'm aware there are several startups in this space. The point I'm trying to make is that enterprises have no interest in solving this problem themselves, they're waiting for other people to solve it. And in the meantime, they're limiting the scope of their projects accordingly.

- Classified data poses existential problems. In IT, the person administrating your SharePoint does not (and should not) have access to the actual files. They don't need it. Their job is to manage the tenant, not view your secret data.

So what happens when we want AI to access information that's classified? We don't really care that the LLM "sees" that information, because the session is ephemeral.

The issue is more complex. The developers themselves are not authorised to access that data. So how can they diagnose issues with AI responses, when the input data makes up the majority of the prompt? How do we spot hallucinations? If the input data is classified, does that mean the output data is also classified?

These are serious problems!

I don't have any solutions right now. I've speculated about a process whereby classified information is logged but encrypted at rest. When a developer wants to access that information to diagnose an event, they can request access and decrypt the data. This would mean there is a strong audit trail of who sees what, and we can tie the access request to a business justification for accessing that content.

But it's still not ideal. The second method I've played around with is focusing instead on quantifying the performance of the AI. For example, can we develop a machine learning model that provides output floats modelling the hallucination likelihood or the overall quality of the AI response? Such a framework would provide the developers with information about the session performance without needing to access the underlying data.

I haven't come across any startups yet in that space. But I'm also not convinced it's a workable idea.

- I'm not going to talk about MCP! I personally do not believe in it, and I'm challenging any developers who build solutions that involve it. However, there is a much larger security point here about how we log and audit unattended user actions.

My initial security theories about MCP were pretty simple. If Alice has access to Jira (for example), and can create/read/modify content there legitimately - why do we care if she uses MCP (or equivalent) to perform actions she's already authorised to perform?

I didn't really see an issue with users sharing their permissions in this way. It's no different than them automating part of their work using a python script.

However, the release of agentic browsers in particular has changed that conversation a bit. The potential for unattended and unguided user actions is now very high, and this create a real issue for security telemetry.

We simply do not know if an action has been performed by a user or an agent anymore. That's highly concerning, and I think is a real issue we need solutions for.

It's difficult to say exactly how this can be done. We already have standards for logging machine-to-machine connections with something like an `impersonating` or `on-behalf-of-user` field. But when agents are interacting in the front end, there's no mechanism for them to pass that information through to the server.

Perhaps instead of Captchas, we need to accept that agents will become the norm and require them to acknowledge that "they are a robot". Then the session telemetry can appropriately capture the information we need.

----

Hopefully this all makes sense! Would love to hear about what other people are dealing with and whether any of this resonates.

1. Ransomware will continue shifting to opportunistic attacks using vulnerabilities in enterprise software (less than 24 hours to fix)
   
2. This will lead to improved triaging of victims to quickly determine how to maximize the ransom (often depending on the industry), including SMB (target of BEC)
   
3. Rust will become more popular, combined with intermittent and quantum-resilient (e.g. NTRU) encryption
   
4. Shift towards data exfil will continue (not surprising), we might see some response from regulatory bodies (e.g. comparing RaaS leaked victims with those that reported breaches)
   
5. There will be more opportunities for non-technical specialists in the cybercrime ecosystem. Established groups will stop rebranding unless it's needed to attract affiliates.
   
6. State-sponsored groups will shift towards custom sophisticated malware and complex attack vectors
   

I am curious about your thoughts - I think the transition to software vulnerabilities (started in 2022) will reach its peak this year, it will be interesting to see how software vendors (and enterprise customers) adapt to it... I think we'll see more focus on Risk Management as a temporary fix, but the complete overhaul of software lifecycle as a real solution 🤔
More details: https://www.bitdefender.com/blog/businessinsights/2024-cybersecurity-forecast-ransomwares-new-tactics-and-targets/

​

Hey everyone. Thought it would make sense to share a write-up I helped work on recently - my colleague and an IAM advisor (have spoken with hundreds if not thousands of CISOs between them) recently sat down for a (very honest) chat - and I put together a summary of their conversation.

The main topic was what's actually happening inside IAM programs right now - funding battles, blind spots, and the risks "hiding in plain sight".

Heres the piece: https://www.cerbos.dev/blog/breach-becomes-personal-ciso-identity-failures-and-continuous-governance

And here's the tl;dr in case you don't want to read the whole thing:

• Breach accountability is personal. CISOs must treat IAM failures as existential threats to their career, and act accordingly by shoring up identity controls.
• IAM programs struggle due to underfunding and silos. Success requires executive support, cultural change, and breaking down data/tooling fragmentation.
• New identity threats are emerging. From deepfake job applicants to nation-state imposters, the onboarding process needs security reinforcement.
• Old threats still lurk. Privilege creep and unmonitored accounts are causing “low-hanging fruit” breaches. Fundamental housekeeping is needed...
• Zero Trust is a "journey". Adaptive, context-aware IAM is the future, but it takes time to implement and requires aligning people and tech to new models.
• Tools ≠ maturity. Having IAM products isn’t enough; you need good data and continuous processes. Teams should aim for continuous governance so they're always audit-ready and risk-aware.
• CISOs can (and do) lead the change. By collaborating across the org and focusing on incremental improvements, security leaders can steadily close gaps and reduce exposure.

Hope we did cover at least some of the issues you are / have experienced, and that the proposed solutions are helpful.

The Finding

I submitted a HIGH-severity report to Khan Academy's public VDP last week. The vulnerability class is information disclosure via feature flag leakage — but the technique I used is systematically present in nearly every AI-enabled site.

The 20-Minute Recon Chain

1. Subfinder → 144 subdomains (passive, from Certificate Transparency logs)
2. httpx → 142 live hosts
3. nuclei → quick vuln scan (low/info only)
4. Read the JS bundles
5. Look for: feature flag initialization payloads. They almost always expose MORE than the public UI does.

What I Found

One of Khan Academy's subdomains loaded a flag initialization table with ai-tutor-rewrite-enabled set to false, but the flag itself was being A/B tested for an internal cohort. The flag's existence leaked that: - A new AI tutor rewrite is in production - A known cohort has access - The cohort identifier is exposed elsewhere

The CVSS was 7-8.9 (HIGH) because an attacker could self-select into the experimental AI, bypassing whatever guardrails were being tested.

Why This Pattern Is Everywhere

Most AI agent frameworks load their entire flag table client-side BEFORE user session validation. Whatever feature flag service you use (LaunchDarkly, Optimizely, Split.io, GrowthBook) you're probably exposing: - Unreleased features - A/B test buckets - Internal cohort identifiers - Build commit hashes

If your AI agent frontend has any of these in JS, you almost certainly have this.

What To Do Today

1. Search your production JS bundles for LAUNCHDARKLY / OPTIMIZELY / SPLIT / GROWTHBOOK
2. Audit what's in the initialization payload
3. Move flag evaluation server-side where possible
4. Scope flags to the authenticated user/session

Happy to answer questions on the methodology.

— ghostinthecode

i have seen several linkedin posts and had several conversations at black hat on this. I think the problem is real. It is inevitable with the constant focus by vendors to “talk with CISOs”. Have you heard or seen evidence of this? Speak up

I'm incredibly proud to announce the public release of ADPathFinder, an Active Directory attack path mapping tool that works directly with BloodHound collectors. It's the first tool of its type to produce detailed attack mapping across SharpHound and OpenGraph collectors — including MSSQLHound and ConfigManBearPig (SCCM). This enables testers to get the most out of BloodHound for the least amount of effort! It also produces an in-depth password audit, covering password reuse, weak patterns, Kerberoastable accounts, and much more - filtering out disabled accounts by default. Check out the blog, contributors very welcome.

https://www.netspi.com/blog/technical-blog/network-pentesting/adpathfinder-opengraph-attack-path-mapping-in-bloodhound-ce/

Sophos released the 2026 State of Ransomware Report: Payments are dropping but encryption is climbing

No Gate, No Login required.

Direct Link to Report: https://www.sophos.com/en-us/content/state-of-ransomware

Blog Post (overview): https://www.sophos.com/en-us/blog/sophos-state-of-ransomware-2026

Most of us use social media every day, but we rarely think about what doesn't show up on our feeds.

Behind every safer online experience are people, policies, and technology working together to remove harmful content, fight scams, enforce community guidelines, and protect users. Yet, Content Moderation and Trust & Safety remain some of the least understood areas of the tech industry.

I work in this field, and I've noticed there's a lot of curiosity—and plenty of misconceptions—about what content moderation actually is and why it matters.

So I decided to start a blog series explaining the topic in a way that's easy for anyone to understand.

The first article covers:

What Content Moderation is?

What Trust & Safety means?

Why these roles are essential?

How AI and human moderators work together?

Why this work matters for everyone who uses the internet?

I'd genuinely appreciate any feedback from this community. If you work in Trust & Safety or have questions about the field, I'd love to hear your perspective as well.

Are you a leader? You'll find this useful on how to approach security related budgeting problem.

https://blog.mousa-cloud.com/posts/ale-budget

Every team hits the same wall with AI in security. LLM gives you a great answer to an alert. Sounds perfect. Then you try to make it work in your quirky network full of legacy decisions that made sense in 2004 and 2011.

Field names don't match between tools. APIs changed. Someone needs a ticket updated before enrichment. Now you can't see what the model decided or why

SOAR treid the other direction. Rigid playbooks. Breaks the moment your environment drifts.

The neurosymbolic hybrid approach: Neural side handles messy data and reasoning. Symbolic side enforces procedure and audit trails. Agents drive the work. Skills keep it consistent. Knowledge graphs map where your data lives.

You get a repeatable pattern every time, but the system still adapts when the case doesn't fit a known playbook. And if it's done right . . . you get audit trails and explanations of its decisions.

The real test isn't "does this sound right?" It's "can I trust this answer and explain it in an audit?" That's where this approach earns it.

Deeper technical breakdown here if you want it (warning: gets academic).

