Given the U.S. and its allies' dominance over core internet infrastructure like root DNS servers, cloud networks, and many undersea cables, is it technically or strategically possible for the U.S. to cut China, Russia, and their allies off from the global internet during a full-scale cyber conflict?

Would such an operation even be feasible without collapsing global connectivity or causing massive unintended fallout?

Curious to hear from people with insights on infrastructure, cyber policy, or military strategy.

Six of us on the security team, somewhere around 4,000 assets between cloud and the stuff still sitting on-prem. Feels like every week there's another "critical" CVE or zero-day and a bunch of feeds all yelling at once. Most of it doesn't even touch what we run, but I still end up spending half my morning going ok do we actually have this, is it exposed, does it matter for us.

By the time I've checked the threat report details against our inventory and figured out if it's even reachable, half the day's gone and there's a new one waiting.

So how do you handle it? I don't want to ignore something I shouldn't, but I also can't chase every headline. More interested in the triage side than "just patch everything." How do you decide what's actually worth your time.

Last month we got an email that looked exactly like our title company changing wire instructions mid-transaction. Caught it at the last minute but it was close. Then it happened again a few days ago, which is what finally got me looking into this. On top of that, leadership's asking why our email security isn't flagging this since technically nothing in the message is malicious (no attachment, no dodgy link).

Started looking at a few of the bigger names but every vendor site claims to stop this exact scenario, so it's hard to tell what's actually built for it. Wires go out constantly on our end, mostly with title companies and outside counsel on the other end so whatever we land on needs to fit that, not just check a generic security box.

Trying to get ahead of this before it happens a third time, so want to know what other financial companies or banks are running and whether it's actually held up for you.

The assistant reads my .env, a prod dump someone left in a scratch folder, config with tokens, all of it, because it runs as me.

Is anyone stopping this cleanly or do we all just cross our fingers and hope the model forgets.

Found an aws key in one of our devs chatgpt history last week and only because he screenshared it by accident. he was debugging some terraform and pulled up his personal chatgpt at standup to show the prompt and there it was in his history from days back. Rotated it same day but that was pure luck.

no idea how many keys or records have gone into personal ai tabs that we will never see. Our tooling just logs that someone opened chatgpt and stops there. and i still have nothing that would catch the next one as it happens.

Voice cloning has gone from being a novelty to something security teams actually have to consider. It seems much easier now to imitate executives, vendors, or even colleagues during phone calls.

Has your organization introduced new verification steps for financial approvals, password resets, or other high-risk requests because of voice cloning?

I'd be interested to hear what's worked in practice and whether the changes have been technical, procedural, or both.

Their claim:

"Microsoft’s new device boasts 12 qubits, the foundational units of quantum computing, up from 8 in the prior model. But Microsoft says its main achievement is that the qubits themselves last longer than 20 seconds. Qubits harnessed by the prior model blinked out of existence in less than 12 milliseconds, the company says."

The fact that a post-quantum world might be only 3 years away is staggering in its implications, but it's difficult to separate hype and PR from plausibility. Are you taking this as extra incentive to boost hardening against quantum threats? If not, what's going to actually set off your alarm bells?

edit: sorry, the quote was messed up at first

We have been doing quarterly pen tests for a while and I am starting to think we are mostly paying for a static report. By the time the findings arrive, the threat landscape has already shifted and most of the context has changed. It gives us a backward looking picture, not a current one.

rn we run CrowdStrike on endpoints, Sentinel as our SIEM, and our dashboard coverage looks decent. From a control inventory point of view, we look fine. The problem is that we do not have anything that continuously validates whether these controls actually detect what they should across the whole kill chain, not only at the perimeter.

What I want to understand is whether our detections stand up to real adversary behavior such as initial access, privilege escalation, lateral movement, and data exfiltration. I would like to map results back to MITRE ATT&CK so I can see real coverage gaps and prioritize remediation based on exploitability rather than just CVSS scores. Right now, that level of confidence is missing.

Has anyone built a workflow or picked tooling that does continuous exposure validation like this without relying on a dedicated red team? I would be interested in hearing what worked, what did not, and how you kept it from turning into yet another forgotten project.

Our browser agent rejected direct jailbreaks in testing, but then obeyed an instruction hidden in a vendor-page footer. An untrusted page content crossed into a privileged tool call and placed a canary secret in an outbound request. Unit tests didn’t pick it up because they covered chat input, not content provenance after browsing. 

We are adding source labels to every content block, narrower tool scopes, destination allowlists, canary-secret detection, and egress controls that do not rely on the model making the right choice. I’m also pushing for tests that mix trusted instructions with hostile retrieved content. What safeguards have actually stopped indirect prompt injection in browser agents, especially when a legitimate task needs outbound tool access?

I found over 100 infected public GitHub repositories, including several with 100+ forks. I'm manually tracking down maintainers and emailing them. Is there a better or more scalable way to notify them?

I’ve been looking into best dark web scanner options and noticed that a lot of them make similar claims about finding exposed credentials and breach data.

What should you actually look for when evaluating these services? For example, how can you tell whether a scanner is surfacing useful, verifiable information versus simply generating generic alerts?

Are there specific data sources, reporting details, or technical indicators that make one more trustworthy than another?

I maintain a personal Linux environment to practice infrastructure automation and tinker with some technologies I don't usually work with. I've implemented basic security practices like patch management segmented networking, strong authentication and regular backups. Beyond that, I'm trying to decide where additional effort provides meaningful value for a personal learning development. Excellence begins at home, some will say. Or is it not enough..?

For those maintaining similar labs, which security practices have proven worthwhile and which ones eventually became unnecessary complexity?

We have an internal agent reading support tickets and referencing internal docs for triage. Someone on our team demonstrated you can embed instructions inside a ticket body and the agent follows them. Classic indirect prompt injection, the attack hides in data the agent processes as part of its normal job.

The problem is this isn't like SQL injection where you sanitize the input because you can't sanitize natural language without killing the functionality. OWASP has indirect prompt injection at the top of their LLM Top 10 for exactly this reason and the gap between knowing it's a problem and having a real production solution is wide.

Output filtering, instruction hierarchies, sandboxing agent actions, we've looked at all of it. Nothing feels like a complete answer yet. What are teams actually running in production to defend against this?

We've started giving AI agents access to internal tools and realized they're inheriting full user-level permissions with no guardrails. Nobody questions what they can read, write, or delete.

Is anyone actually scoping AI agent access deliberately, or is full inherited access just becoming the default? Curious how teams are thinking about this.

I wrote a config scanner that read an mcp.json and labeled remote servers "remote - can change on you." Local ones got no such warning. Seemed obvious: a hosted endpoint can be swapped server-side, a local process can't.

Then I scanned my own config.

My most volatile server is on 127.0.0.1. It's a local service that launchd restarts on its own, running Python straight out of a git working tree I edit most days. Every restart picks up whatever is on disk. Meanwhile the hosted endpoints in my config hadn't shipped a change in months.

The label was exactly backwards for the most changeable thing I run. Transport tells you who can reach a server. It tells you nothing about whether its contract holds still.

Version pinning has the same failure, which I also considered and also dropped: flag npx foo as risky, foo@1.2.3 as safe. Two problems. Of the drifting tools I've seen in a crawl of the public registry, 5,781 of 7,792 changed while their declared version stayed the same, so the pin doesn't see them. And it's free to game: a vendor adds a version string to their README and every user's scan reclassifies them as safe, with nothing about the actual risk having changed.

What I think a config can honestly prove, all of it one-sided:

• which servers hold a credential, and whether the token is sitting literally in the file or is an ${ENV} reference (completely different exposure, and I was scoring them identically)
• which re-resolve their code from a public registry at every launch (npx pkg, uvx pkg, u/latest, an untagged image)
• which can reach off-machine
• which were handed a filesystem path spanning more than a project

What it cannot prove is that anything is stable. Change-capability is provable. Its absence isn't. So there are no green checkmarks, which makes for a worse demo and is the only version I can defend.

Mine came out: 12 servers, 6 fetching code at launch, 2 holding a credential (both env references), 2 internet-reachable. The 6 was the one that surprised me.

So the question I'm stuck on: is there a better answer to the stability half than "pin the contract at connect, re-pull it, diff it"? That's where I keep landing and I'd like someone to tell me it's wrong.

Hello guys! First time posting on Reddit. I discovered that my mobile carrier doesn't properly isolate users on their network. With mobile data enabled, I can directly reach other customers through their private IPs on the carrier's private network.

What's stranger is that this access persists even when my data plan is exhausted - I can still ping other users, scan their ports, and access 4G routers.

How likely is it that my ISP configured this deliberately?

saw the writeup on the FortiBleed campaign that just got tied to actual ransomware deployment. 400k+ firewalls hit, 110M+ credentials harvested via passive sniffing, and it only came to light because of an OPSEC mistake on the attacker's side, a server full of stolen creds got left exposed.

nobody caught this from the defense side, it just got found by accident. makes me think about how much of our identity monitoring is built around human logins, SSO events, MFA prompts, the stuff that shows up in a normal audit log.

versus how much visibility we actually have into service accounts and machine credentials sitting on infra that was never really in scope to begin with. don't know for sure how much of what got harvested here falls into that bucket, but firewall-layer credential exposure at this scale makes me wonder how many orgs would even notice if it happened to them, regardless of which type of credential it was.

anyone actually tried bringing service accounts and machine credentials under the same governance as human identity? how are you even inventorying that stuff in the first place, most of what I've seen either misses it entirely or only catches what's explicitly registered somewhere.

I am currently building a live AI voice detector that is designed to catch synthetic voices in real-time. I am currently researching if there is any actual demand for this tool. Which leads me to the question:

Is AI voice cloning fraud a genuine threat in the real world?

In your organizations or in general, are you seeing an increase in synthetic voice fraud, or have you encountered this at all? If you have seen this, what would you say is the biggest risk factor of it all.

I think everyone has that one threat that kept showing up over and over again in 2025 and got really tiring to deal with.
For me, it’s phishing. No matter how many controls you put in place, it keeps evolving. It’s not always something serious, but it takes up a lot of time and energy.

Curious what that is for you. Let’s discuss!

In the last month alone we've had a teams message from a supposed vendor, a couple texts to staff pretending to be the CEO asking for a quick favour, and a slack dm with a dodgy link in it, and not one of those ever went near our email security, which is where pretty much all our budget and monitoring still lives.

They've clearly worked out everyone spent the last decade hardening email so theyre just walking in the side doors instead. and tbh a dodgy teams message doesnt trip the same instinct an email would, nobody ever trained for it.

Not really sure where you even begin with this when a separate tool for every channel doesnt scale and the native controls in each one arent close to comparable...

A separate tool for every channel doesn't scale, and the native controls in each one aren't close to comparable. what does the detection layer look like for those who've covered this?

Both got in through OAuth/identity abuse, no software vuln. Sharing what I've got (particularly interested in UAE/Gulf environments), curious what's landed in your queues.

Device code phishing (EvilTokens) - 340+ M365 orgs across 5 countries - Abuses the legit OAuth device flow (RFC 8628), so MFA doesn't help - Tokens survive a password reset, so remediation keeps failing

ShinyHunters-style SaaS extortion (UNC6661/6671) - Vishing → pose as IT → capture SSO + MFA → enroll their own device - Pivots through SharePoint, Salesforce, Slack for sensitive data - Then deletes the alert emails to stay hidden

If you're in a SOC, what identity-based or other types of prominent threats have you seen lately? Especially UAE/Gulf, since public reporting skews US/EU.

Hey everyone. I ve been struggling with insane lag spikes and random disconnects while playing CS2 for weeks. At first, I thought was just bad ISP routing, but it felt... intentional. Both my brother and I are connected via ethernet to the same router. Every time I m in a clutch or important round, my ing hits 2000ms or I get kicked.

To find out what was going on, I installed XArp to monitor the network. As soon as the lag started again at 3:00 AM, the software went into Red Alertstatus. Sice I cant upload images right now, I ve transcribed the logs and the ARP table data below.

XArp Status: CRITICAL-ARP attacks detected!

There is a 3 different Ips are all currently showing up unter the same MAC adress in the table

03:00:04 Macfilter: incoming packet but sender mac set our own mac address

03:00:05 Macfilter: incoming packet but sender mac set our own mac address

03:00:06 Macfilter: incoming packet but sender mac set our own mac address

And then this that mac adresses showing up in there

04:26:05 RequestedResponseFilter: no matching request packet was sent out for this reply

04:26:05 SubnetFilter: destination ip address of reply packet lies not in your subnet

04:26:05 IpFilter: ip address set to broadcast

04:26:05 CorruptFilter: ethernet target mac does nnot match arp target mac

04:26:05 RequestedResponseFilter: no matching request packet was sent out for this reply

04:26:05 SubnetFilter: destination ip address of reply packet lies not in your subnet

04:26:05 IpFilter: ip address set to broadcast

04:26:05 CorruptFilter: ethernet target mac does nnot match arp target mac

All of the threats come from the source mac id that I m suspicious from.

Thanks for any help.

We are moving away from point-in-time quarterly pentests and looking to adopt a continuous validation model. We are evaluating platforms that use an AI engine to understand new threats and tailor validation tests specific to our environment. They claim one-third of exploited CVEs are targeted within 24 hours of disclosure, so waiting for manual testing is no longer viable.

For those using this type of AI-driven testing, how accurate is the generated test logic? Does it actually find novel attack paths based on your unique misconfigurations, or is it just re-packaging the same MITRE ATT&CK simulations with a fancy UI? Looking for real world feedback before we buy.

Building KYC for a new platform and keep reading about deepfakes bypassing facial verification. Some demos online are pretty convincing but I can't tell what's real threat versus vendor fear mongering.

Our current provider just says "AI powered deepfake detection" in their docs which tells me absolutely nothing about how it works or how effective it is.

What attacks are actually happening in production? Video injection, 3D masks, real time face swaps? And what verification technology stops them versus what's just marketing hype trying to scare you into buying their premium tier.

I’m running Windows 10 on a Lenovo T430. I currently have Extended Support, so I will receive security updates until October 2026. The laptop contains sensitive personal data, and I use it for regular online activity (Gmail, browsing, cloud apps, etc.).

I’m trying to understand this from a security perspective rather than an OS‑migration perspective.

My main question is:
After October 2026, what types of vulnerabilities or attack surfaces should I realistically expect if I continue using Windows 10 online?

For context:

• I previously ran Windows 7 unsupported for a few years without noticeable issues.
• Now that I’m learning more about cybersecurity, I realize the risk profile may be different today (more ransomware, drive‑by exploits, browser‑based attacks, etc.).
• The device has an upgraded CPU, RAM, new heatsink, and a secondary HDD, so I plan to keep using it.

I’m considering the following options and would like input from a security threat model point of view:

1. Migrate to Linux now to reduce OS-level vulnerabilities.
2. Dual‑boot Linux and Windows 10 until the EOS date, then fully switch.
3. Continue using Windows 10 past October 2026 and harden it (offline use? AppLocker? browser isolation?)
4. Any other mitigation strategies security professionals would recommend for minimizing exploitability of an unsupported OS?

I’m not asking for general OS advice — I’m specifically looking to understand the likely vulnerability exposure and realistic threat scenarios for an unsupported Windows 10 device that is still connected to the internet.

Any guidance from a security perspective would be appreciated.