Wanted to find out how you guys do it across different scales, from one-person teams to enterprise teams

Filing this one under things I should have known before..

I recently went digging through our setup last week and found more holes than I expected.

I’d always thought group membership changes were a single event. They are apparently three events (4728, 4732, 4756) depending on the group’s scope. I was watching 4732 and nothing else. So for who knows how long, someone could’ve been added to Domain Admins and I would never have known.

The rest was a mix of policy applied in the wrong place, collection not covering everything, and stuff configured years ago by people who’ve since left the company years ago.

Luckily none of it failed loudly. The dashboard looked fine. I only found it because I went looking for it.

So:

• Which event IDs are you actually confident you’re capturing, and have you ever verified it?
• How’d you find your gaps: audit, incident, or just poking around?
• Anything you’ve decided not to bother auditing, and did that hold up?

I'm also evaluating budget friendly Active Directory auditing tools, particularly between Quest Change and ADAudit Plus and Netwrix Auditor. Anyone here who's used one of them?

My company acquired a startup a few months ago and I’m starting to realize their asset inventory was nowhere near complete. We keep finding old domains, cloud stuff, random services, etc. that apparently nobody is tracking anymore.

For anyone who’s dealt with this after an acquisition, how did you figure out what was actually out there? I’m increasingly skeptical that comparing CMDBs and asking the acquired team is going to get us very far.

We're weighing up SASE options and Cato Networks has landed on the list. Most people I ask just name the same two or three giants, and the pricing on those made my eyes water. Would really like to hear from someone who's actually had it deployed for a while, good or bad. Thanks in advance!

Say you run a hybrid environment, AD plus a few cloud subscriptions, and an inventory pass turns up a few hundred service accounts with passwords set to never expire. Most have no clear owner, and some have been around longer than the people who set them up.

Forced rotation is the obvious fix, but nobody can say what breaks when the password changes. Windows services, scheduled tasks, hardcoded connection strings and old LDAP binds are all possible. Rotating blind means scheduling outages, and leaving them alone means keeping long-lived credentials around.

I was wondering, how do you find out what depends on an account before you touch it, and who takes the risk if something does break?

https://github.com/Kludex/mangum/issues/160

I believe I may have found proof that WOFF2 is vulnerable to the Brotli zero-day, and the entire industry is looking the wrong way. Can someone please tell me I'm crazy?

We are busy patching Node.js and Python HTTP servers, but a site tracking bundled decoders called Broccoli2Shell published a table on October 24th. It lists projects that hardcoded their own private copies of the vulnerable Brotli C decoder:

• Project: woff2 (Makefile build)
• Bundled Copy: Brotli 1.0.3 (Critically vulnerable)
• Input it decodes: WOFF2 fonts passed to woff2_decompress
• Status: "Tracked in issue #207. A fix has been proposed in PR #208."

The maintainers of the font-compression library know it's vulnerable, but because it’s a C-library issue and not a flashy web-server exploit, it isn't making headlines.

Why this takes down servers too:
You might think, "Fonts are a client-side problem." Look at Kludex/mangum Issue #160: issue in reading .woff/.ttf/.woff2.

It throws a Unicode decode error. So what?

So what? It means your middleware touches the file. If you don't explicitly whitelist the media type in AWS API Gateway, the gateway tries to unpack the WOFF2 file to read the body. And what algorithm does WOFF2 use to compress its data? Brotli.

If your firewall/middleware checks the file, the firewall dies. If the firewall ignores the file, it passes to the client... and the client dies. It's a bidirectional nuke. And right now, there are millions of malicious WOFF2 files sitting in AWS buckets, just waiting for someone to request them.

The servers we already manage should be the easier part. Query EDR for running PHP processes, compare that with package inventory and check which web services are actually public.

Where it gets messy is everything that never made it there. Old campaign sites, domains inherited through acquisitions, vendor-managed portals and cloud instances that were retired in theory but remain public in practice.

A few approaches I’m looking at:

• Compare the CMDB with EDR and vulnerability-scanner inventories. Search for php-fpm, mod_php, php-cgi and PHP bundled inside appliances, not only a package named php.
• Check certificate transparency logs and passive DNS for old domains, historical hosts and certificate relationships connected to acquired companies.
• Use Censys or Shodan to find public PHP fingerprints. Server and X-Powered-By headers are useful leads, but CDNs and reverse proxies can hide the origin or return misleading versions.
• Review cloud accounts, DNS zones and load balancers sitting outside the central organisation. That forgotten test account is apparently production now.
• Confirm the package or vendor backport on the host. A PHP banner will not tell you whether the fix was backported.
• After patching, restart every relevant worker and test the runtime serving the public route. php -v on one shell is not enough.

If manual correlation starts eating the day, cycognito and cortex xpanse are other discovery options. ionix maps broad PHP candidates back to customer footprints, with version narrowing still in progress. It has held back the exploitability test because the current method may crash PHP servers. The free external assessment does not require credentials. 

Whatever the approach, I don’t need another PHP hostname. I need a hostname with ownership evidence, a confirmed package and someone responsible for fixing it.

How are you finding public PHP hosts that never made it into your managed inventory?

If so, was the panic really necessary?

I looked at a bunch of PoCs, and it seems you need to do multiple consecutive requests to the same php worker process. In production systems that get a reasonable amount of traffic, you have multiple VMs/containers running multiple php processes behind a loadbalancer, and there will be constant background noise from legitimate traffic as well as scrapers and scanners.

The PoCs get around this because they experience zero traffic, know the exact number of processes, tie up all but one process with open connections and execute the attack against the remaining process.

On top of that, if you don't know the exact build, you need to try (assuming you have prepared exploits for every common build) exploits for the most popular x number of builds. So basically you would be DoS'ing a site for days or weeks, which would get noticed, and then you'll likely get WAF'd.

After spending crazy amount of time on remediation and then finding that the vuln is afaik significantly less scary than heartbleed/shellshock/log4shell, I'm confused. I did a little writeup explaining the above with more details (https://blog.luitjes.it/posts/i-want-my-wednesday-back/) but I keep wondering if I'm wrong (I do some infosec work occasionally but it's not like I'm a fulltime exploit dev).

I've seen a few posts saying this is hard to exploit because it needs to be customized per build, but nothing about having to DoS anything but the most low-traffic sites for days or weeks to get lucky enough to do two consecutive requests to the same php process.

So: what controls do you use to make sure a decommissioned agent's access is really gone, and how do you prove it after the fact?

I'm looking at options for Cloud Attack Path Analysis solutions and am wondering what solutions are decent vs. total snake oil. Orca keeps coming up but I'd really wanna hear from people actually running it than from a sales deck. I'm going to speak to several but would like to know if anyone out there has had particularly good or bad experiences with any of them. Feel free to DM if you don't want to speak openly in public; I understand 😁

Just wanted to know if anyone has bought into this voluntary program from the DoD Cyber Crime Center that provides an extra layer of security for DoD suppliers network. Any reviews from implementation and its effectiveness?

An exposed C2 server tied to INC and The Gentlemen ransomware affiliates leaked 133 AI session logs (8,257 messages). A few things stood out:

→ The models were standard commercial LLMs accessed through OpenRouter. “WormGPT” was only a persona prompt.
→ When a model refused, the operators didn’t switch tools. They reworded the request as an “Authorized Red Team Assessment Request.”
→ The AI didn’t run on its own. Each campaign started with a victim-specific prompt telling it to “coordinate every action with me,” and the operator approved every step.
→ The tooling included 32 MCP servers covering everything from recon to ransom pricing.

The access methods weren’t new: FortiClient EMS, SimpleHelp, cPanel/WHM, and a lot of password reuse. 62 named organizations appear in the case files.

So the AI added speed and scale, not new techniques. That raises a fair question: is refusal-based safety meaningful when “it’s for a red team engagement” gets the job done?

Without a real help desk, MFA resets on small teams mostly come down to an admin hopping on a call and deciding the person seems legit.

The part that bugs me is where the request comes from. If you’re locked out of MFA you’re probably locked out of email and Slack too, so the ask shows up from a personal phone or Gmail. Same place an attacker would send it from.

What’s the minimum you’d require before resetting? Callback to a number on file, manager sign-off, something else entirely?

Hi, I need honest opinions on any of these vendors from people who tried them (if you're from any of these companies, skip. I don't want marketing bs): Dropezone, Torq, mate, prophet security.

New funding agreement says we have to report a data incident to the funder within seventy two hours of becoming aware and for a small charity on Microsoft 365 with one file server and no SIEM, it's the becoming aware part that worries me. If something happened in our tenant or on the file server I think we'd find out when a user told us and even then I'd struggle to work out what happened inside three days. If you've had to meet a clause like this, what did you put in place to notice and reconstruct an incident that fast?

We're shortlisting exposure management tools and Wiz-io is the front runner mostly because of a couple of engineers close contacts.

Looking for something that covers the external attack surface too and adds threat intel context. Anything that remediates needs to be careful tho as we're payments so production downtime is not an option.

What else should be on the list? Seen Palo Alto, Check Point and CrowdStrike mentioned so far, no demos yet. Thanks

Mod Approved

Hi everyone,

I'm an MSc Cyber Security student at Islington College, London Metropolitan University. My dissertation investigates burnout, cognitive workload and alert fatigue among people working in Security Operations Centres (SOCs) and related cybersecurity operations roles.

I'm looking for participants who currently work, or have worked within the last 12 months, as a SOC analyst, incident responder, threat hunter, or in a closely related role involving security monitoring, alert triage, threat detection, or SIEM/MDR operations.

The survey explores workplace factors that may contribute to burnout and workload in security operations. It's anonymous: no names, email addresses, IP addresses or employer details are collected, and results will be reported only in aggregate. Participation is voluntary, and you can stop at any time before submitting your responses.

Ethics approval: Islington College (London Metropolitan University)
Estimated time: 15–20 minutes
Survey link: SOC Burnout & Alert-Fatigue Risk Assessment Survey – Fill out form

If you meet the eligibility criteria, I'd really appreciate your participation. If you know someone who may be eligible, please feel free to share this post with them.

I'm happy to answer questions in the comments.

Thank you for your time and support!

Hey folks!
I’m looking into Cymulate, Picus, and Pentera for security validation and BAS, and wanted to see if anyone here has hands-on experience with these tools. How do they perform in real-world scenarios? Are they easy to set up, and are the results actually useful? How do they stack up against each other in terms of features, coverage, and overall value? Would love to hear your honest opinions, pros and cons, or anything worth knowing before making a decision. Thanks.

Howdy folks,
Considering implementing something risky. If I implement the below, is there still risk involved to make me second guess allowing this on a public facing website B2C.

planning enquiry attachments using Cloudflare Workers, accepting only JPEG/PNG images under 10 MB.
Originals go into private R2 quarantine as immutable uploads, are scanned by ClamAV in a separate container, then decoded and re-encoded into fresh JPEGs using Cloudflare Images, stripping metadata.
Only processed copies reach our staff admin viewer or email. Originals are deleted after successful processing; failed uploads remain inaccessible and expire.
Does this architecture make sense, and is ClamAV worthwhile alongside mandatory image re-encoding?

Enquiry form → Email code verification → Upload validation
→ Private R2 quarantine (immutable original + hash)
→ AV scan → Decode and re-encode as a new JPEG
→ Validate output → Save approved copy + enquiry link
→ Delete original

Approved copy → Staff admin viewer / optional email attachment

Failed checks → Block access → Retry or reject → Delete original

I build systems that receive payment confirmations from Safaricom’s M-PESA Daraja API (STK Push and C2B callbacks). As far as I can tell, Daraja doesn’t send an HMAC signature or similar with its callbacks, unlike Stripe or GitHub webhooks, so the receiving endpoint can’t cryptographically verify that a callback really came from Safaricom.

Current mitigations I’m aware of or using:

• Allowlisting Safaricom’s published callback IP ranges
• A long random secret token in the callback URL path
• Treating the callback only as a hint, then confirming the payment with an outbound Transaction Status query before marking anything paid
• Idempotency on the transaction ID so replayed callbacks can’t double-credit

My specific question: is the outbound “confirm before trust” query enough on its own to treat inbound callbacks as untrusted, or are there attack paths I’m missing (e.g. race conditions between callback and confirmation, or manipulation of the confirmation response)? How do others handle unsigned webhooks from payment providers in production?

Hi all, I'm trying to learn how infrastructure and network audits work in practice and would love some input from people doing this daily.
What are the control gaps you find most often?
Where do auditees tend to be weakest (patching, access reviews, firewall rules, logging)?
Any audit checklists you'd recommend

Last year we brought on a tool to get runtime context on our workloads and help prioritize vulns, mostly to cut noise based on what’s actually loaded in memory. At the time it seemed like a no brainer, since direct exploitation or even chained attacks mostly can’t work against components just sitting on the filesystem.

We ran a threat modeling exercise the other day on some new systems running AI agents with tool access, and in some cases a shell. It got me thinking: can’t the agent load anything it needs at any point, unlike older deterministic code? And if so, doesn’t runtime context based prioritization fall apart completely?

Can anyone with practical experience in this area chime in? I’m at my wits end brainstorming hypotheticals with GPT.

We're talking to vendors who keep pitching both, but I'm not sure if my company needs that because we're still a pretty small org. Can someone explain to me why we would budget for both, or if one would be preferable to the other?

Hi everyone,

Our application security workflow is increasingly AI-assisted from threat modeling and SAST/SCA to code reviews and vulnerability analysis. We use Claude, OpenAI, and Copilot to perform SAST with custom prompts, and source-code context along with internal tools[traditonal sast, jars moderation]. Burp Suite for manual validation.

But here's the challenge: when AI helps developers write code and AI helps security teams review it, how do we reliably catch vulnerabilities that escape both?

I'm looking for ways to improve coverage, independently validate findings.

For those working in AppSec, DevSecOps or AI-assisted security:

• How do you identify vulnerabilities that AI-driven reviews miss? If so, have you?
• What independent validation or testing mechanisms do you use?
• How do you automate repetitive security testing while keeping human expertise focused on high-risk issues?
• Have you built effective security agents or workflows that genuinely reduce manual effort?

I'd love to hear about your real-world approaches, automation strategies and lessons learned not just tool recommendations.

[ Removed by Reddit on account of violating the content policy. ]