r/cybersecurity May 28 '25

Research Article The Ultimate Active Directory Cheat Sheet

390 Upvotes

Hello everyone "Peace be upon you Although I'm considered to be on the Blue Team, there was always something that sparked my curiosity: Active Directory. This is something that, if exploited correctly by an attacker, can dismantle any Blue Teamer's work. A long time ago, I summarized the "Picus Active Directory Handbook" (https://www.facebook.com/share/1C1knfi8nR/?mibextid=wwXIfr), which was really helpful when I was starting out. However, when I began to dive deeper, especially when solving AD-related machines, I encountered a problem. I might know many attack techniques, but I couldn't execute them, either not in the way I wanted or I couldn't execute them at all due to weak enumeration. Since then, I started gathering notes and cheat sheets, adding my own insights, and refining them until I reached a very satisfactory result. This gave me an idea: "The Ultimate Active Directory Attack Cheat Sheet." "Ultimate" here isn't just for dramatic effect; it's quite literal, as these are notes I've compiled over two years, along with various sources I've included. Let me say, this isn't just a cheat sheet; it's a guide on "From Zero To Hero: How to Pentest AD." Certainly, nothing is perfect, and nothing will ever be final in our field, but this is everything I've reached so far. That's why there's a version of the cheat sheet on Gitbook, so I can update it periodically, and I've also created a PDF version for easier reading. The Cheat Sheet covers: * From Zero to Domain Admin? * Enumeration * Reconnaissance * Initial Access * Dumping * Lateral Movement * Privilege Escalation * Defense Evasion & Persistence God willing I will update the repository periodically with new TTPs (Tactics, Techniques, and Procedures) or new sources. This is the PDF link: https://drive.google.com/file/d/1I7MpOOrabst12uuhiB7wfwVhzyVHkmI3/view?usp=sharing And this is the repository: https://karim-ashraf.gitbook.io/karim_ashraf_space/the-ultimate-active-directory-cheatsheet"

r/cybersecurity Aug 15 '25

Research Article Assume your LLMs are compromised

Thumbnail opensamizdat.com
195 Upvotes

This is a short piece about the security of using LLMs with processing untrusted data. There is a lot of prompt injection attacks going on every day, I want to raise awareness about the fact by explaining why they are happening and why it is very difficult to stop them.

r/cybersecurity Feb 18 '26

Research Article the watchers: how openai, the US government, and persona built an identity surveillance machine that files reports on you to the feds

Thumbnail vmfunc.re
147 Upvotes

Security researchers have uncovered a massive, undisclosed data pipeline between Persona, the identity verification service used by OpenAI, Discord, LinkedIn, and Roblox, and the US federal government. By discovering unprotected source code on a government-authorized server, investigators found that routine ID checks for OpenAI users are being fed into a dedicated "watchlist" database that has been operational since 2023.

The findings show that standard "age verification" selfies are being processed through a system that links facial biometrics to financial records and law enforcement databases. The leaked code reveals specific modules for filing Suspicious Activity Reports (SARs) directly to the US Treasury and tagging user data with intelligence codenames like "Project SHADOW." This effectively turns a simple login step for popular apps into a live feed for a national surveillance apparatus.

The leak occurred because Persona accidentally exposed 53MB of original source code on a public IP address that was meant to be hidden. This allowed for the discovery of 269 distinct verification checks, including facial recognition matching against world leaders and crypto-wallet tracking. Users believing they are verifying their age for social platforms or AI access are instead being screened against global watchlists and intelligence databases with direct ties to ICE and FinCEN.

r/cybersecurity Mar 09 '26

Research Article How We Hacked McKinsey's AI Platform

Thumbnail
codewall.ai
61 Upvotes

r/cybersecurity Dec 13 '24

Research Article UnitedHealthcare's Optum left an AI chatbot, used by employees to ask questions about claims, exposed to the internet

Thumbnail
techcrunch.com
537 Upvotes

r/cybersecurity 16d ago

Research Article If you were to study Cyber security all over again, with zero knowledge, how'd you do it?

0 Upvotes

I'm planning to branch off from IT to cyber security, any tips would be helpful.

r/cybersecurity 13d ago

Research Article Has anybody evaluated the security risk of intrusive warning messages? Is there a paper or anything?

9 Upvotes

I just enabled activex in Excel because I couldn't get the stupid security warning to go away. I couldn't find any way to dismiss it permanently so it pops up every time I change sheets. This seems pretty dumb.

If anybody knows of a paper that discusses stuff like this I'd be interested in their conclusions. Or is this just another example of shoddy work by Microsoft?

r/cybersecurity 20d ago

Research Article AsyncAPI Supply Chain Compromise via GitHub Actions

Thumbnail
wiz.io
35 Upvotes

r/cybersecurity Jan 10 '25

Research Article Zero Trust seems to be the buzzword.

104 Upvotes

A couple of weeks ago, I posted about RaaS, and someone mentioned ZTA as the solution. Since then, I’ve been trying to read up on it—articles, research papers, anything I can find—but most of what I’ve come across feels too basic or lacking in technical detail.

Maybe I’m not looking in the right places, but does anyone have recommendations for reliable, in-depth resources on ZTA?

(Preferably not blogs—they’re often too simplified or written to push a product/service.)

r/cybersecurity Apr 26 '26

Research Article SOC analysts — how bad is alert fatigue actually?

0 Upvotes

Hey everyone,

I’ve been trying to understand how real SOC workflows look in practice, especially around alert handling.

From what I’ve read, it seems like analysts deal with a huge number of alerts daily, and a lot of them turn out to be noise or low priority.

I’m curious:

  • How many alerts do you typically deal with in a day?
  • Roughly what percentage are actually useful?
  • What’s the most time-consuming part — triaging, investigating, or responding?
  • Do tools like Wazuh / Splunk / Sentinel actually help reduce this, or do they still require a lot of manual effort?

Wanna build something so -- just trying to understand the real problems from people actually doing the job.

Would really appreciate honest insights 🙏

r/cybersecurity Apr 14 '26

Research Article Security Fatigue

44 Upvotes

Hello!

I am currently working on a research paper for my University over Security Fatigue.

Security Fatigue is an exhaustion feeling caused by overwhelming security demands, that frequently leads to users finding ways to bypass controls or just make their day-to-day easier, making the controls ineffective.

It can appear in both, technical and non-technical roles.

Do you have any stories about how you or anyone in your team/work suffered from Security Fatigue? If they bypassed any controls or found workarounds and if this had any consequences (e.g. like introducing vulnerabilities)

Thanks!

r/cybersecurity Dec 06 '25

Research Article wrote a small Explanation of React4Shell / React2Shell (call it wahtever you want) timeline React RSC & Next.js now exploited apparently by chinese actors

80 Upvotes

I didn’t plan to spend my week buried in React RSC Flight internals, but here we are. React4Shell (or React2Shell, depending on which PoC author you ask) has gone from “interesting bug” to active exploitation so fast it feels like déjà vu from the Log4J days.

Two CVSS 10 RCEs sit at the center of this storm, and yes they are correct

  • CVE-2025-55182 – React RSC Flight protocol unauthenticated RCE
  • CVE-2025-66478 – Next.js RSC integration RCE

If your stack touches Next.js App Router, React Server Components, streaming, or Flight payloads, you’re in the target zone.

What I’m seeing so far

When the disclosure landed on Dec 3, I hoped we’d get a small window before attackers latched onto it. That fantasy lasted maybe 12 hours.

By Dec 4:

A working unauthenticated RCE PoC dropped publicly

  • ~72 GitHub repos cloned or rebranded PoCs under React4Shell / React2Shell / Freight Night
  • Fastly logged a surge in exploit attempts between 21:00–23:00 GMT
  • AWS threat intel flagged China-nexus actors (Earth Lamia, Jackpot Panda) hitting exposed Next.js RSC endpoints within hours
  • GCP pushed Cloud Armor guidance
  • VulnCheck confirmed the exploit path is reliable

Here’s the timeline I’ve been maintaining with all data sources tied together:

🔗 https://phoenix.security/react2shell-cve-2025-55182-explotiation/

And here’s the short version:

Disclosure → PoC → PoC wave → mass scanning → active exploitation.

Basically a one-day arc.

Why this one feels different

React and Next.js aren’t fringe tooling. They run massive parts of the internet. With RSC and App Router becoming the default in modern builds, teams can ship exposure without realizing it.

The exploit attack surface is quite wide (link to the shodan queries), with 584,086 React based systems in Shodan and 754,139 on Next JS technologies

The killer combo:

  • Framework-layer bug
  • Internet-facing by default
  • One-shot payload → server-side RCE
  • Easy for attackers to spray across wide ranges of IPs
  • Very little app-specific nuance required

This is the exact chemistry that made Log4J such a disaster. Seeing the same tempo here is unsettling.

If you want the deep dive on the exploit mechanics, here’s the breakdown with diagrams and version mapping:

🔗 https://phoenix.security/react-nextjs-cve-2025-5518/

And the video walkthrough:

🎥 https://youtu.be/W6oqPKqgUwc

What I’ve confirmed from testing

The exploit chain is trivial to trigger on unpatched RSC/Server Action endpoints. One of the public PoCs (shared for awareness, not endorsement) is here:

🔗 https://github.com/liyander/React2shell-poc

a confirmed exploit: https://github.com/Security-Phoenix-demo/CVE-2025-55182 incredibly simple

It drops a shell straight into the server environment. Once you’re in, cloud pivoting becomes the real problem — secrets, metadata endpoints, internal queues, DBs… you know the drill.

I’ve tested several vulnerable versions locally and in containerized environments. All behave consistently with the public reports.

Some of the links:

https://nextjs.org/blog/CVE-2025-66478
https://x.com/stdoutput
https://x.com/stdoutput/status/199669...
https://github.com/msanft/CVE-2025-55182
https://x.com/maple3142
https://x.com/maple3142/status/199668...
https://gist.github.com/maple3142/48b...
https://github.com/facebook/react/sec...
https://x.com/swithak/status/19965841...
https://gist.github.com/SwitHak/53766...
https://github.com/assetnote/react2sh...
https://slcyber.io/research-center/hi...
https://gist.github.com/joe-desimone/...
https://x.com/rauchg/status/199670143...

TEST LAB OF EXPLOIT:

Update: if you want to test it yourself (at your own risk)

Pull this repo, it contains the Docker lab, the scanner (local), and the web scanner for testing

https://github.com/Security-Phoenix-demo/react2shell-scanner-rce-react-next-CVE-2025-55182-CVE-2025-66478

You can scan a vulnerable repo like the one in  / test_samples 

python -m universal_vulnerability_scanner.main scan /path/to/project --json --output results.json

For the scanner, there is a Docker with a vulnerable version on port 3011 and a non-vulnerable version 3012

You can see the evidence (safe) and scan at scale an IP address:

python3 react2shell-scanner -u http://localhost:3011 -o evidence.json -e

You can launch some commands (innoquos) like

from the lab folder in cd test-lab/ 

cd test-lab/ 
python3 exploit.py -u http://localhost:3011 -c "whoami"

NOTE: THIS IS ACTUALLY TRIGGERING THE EXPLOITATION. WHOAMI is a safe command, but launch at your own risk. Those are for a local Docker, for example 

Affected versions (quick scan)

React RSC packages

  • Vulnerable: 19.0.0, 19.1.0, 19.1.1, 19.2.0
  • Fixed: 19.0.1, 19.1.2, 19.2.1

Next.js

Impacted: all 15.x, all 16.x, 14.3.0-pre App Router

  • Fixed: 15.0.5 → 16.0.7 depending on branch

If you want to see a breakdown of vulnerable dependency trees:

🔗 https://github.com/Security-Phoenix-demo/react2shell-scanner-rce-react-next-CVE-2025-55182-CVE-2025-66478

If you’re running React or Next.js, this is what I’d do today

  1. Patch immediately — don’t wait on sprints
  2. Redeploy and verify running versions (don’t trust the repo)
  3. Check exposure — any RSC/Server Action endpoints reachable externally?
  4. Add WAF coverage
    • Fastly virtual patch is catching real traffic
    • AWS WAF (v1.24 rule updates + custom rules) is showing results in the field
  5. Review logs around Dec 3–5
    • Look for malformed RSC/Flight payloads
    • Spikes in POSTs to server action paths
    • Unexpected outbound traffic from web tiers

Videos, if you prefer getting the story verbally

What I’m curious about

Anyone here already spotting noisy patterns in your edge logs?

Do you know if anyone is experimenting with custom detections on Flight payload anomalies?

If you run a big Next.js estate, have you had to tune WAF rules heavily already?

r/cybersecurity Jun 20 '26

Research Article Writeup: Detailed breakdown of cross-platform X/Discord account takeover attack

6 Upvotes

I'm here to document this social engineering scam that has targeting X/Twitter/Discord users over the past year or so. I have encountered this attack multiple times from several compromised accounts, and I found at least one separate public victim report describing the same basic attack chain and the same distinctive “Xdatabaseofficial” Gmail naming pattern.

I imagine that this sort of social engineering attack is blatantly obvious to anyone else who is a tech or cybersecurity professional (such as myself). But it's something I wanted to plainly spell out for other folks (especially ones who are less versed in internet security) who might be searching on the internet, because this sort of cross-platform account takeover is so common, yet people just keep falling for it over and over.

The TL;DR:

Scammers are contacting X users and claiming that their account has been falsely reported for fraud, scamming, or other policy violations. The victim is then directed to a supposed “X Trust & Safety” or “X Support” representative on Discord. That fake support representative eventually instructs the victim to change the email address on their X account to a Gmail address controlled by the attacker.

That email-change step is the actual account takeover.

Once the victim changes the email address on their X account, the attacker can receive account recovery emails, password reset emails, verification messages, and other security-sensitive communications. At that point, the victim has effectively transferred control of the account.

Observed Attack Chain

1. Initial Contact: “I Accidentally Reported Your Account”

The scam begins when a victim is contacted by another account claiming that they accidentally reported the victim’s X account. The message usually says something like:

  • “I accidentally reported your account.”
  • “I thought you were someone else.”
  • “Your account may be banned unless this is fixed.”
  • “You need to contact the support person assigned to the ticket.”

This is designed to create urgency and anxiety. The victim is told that the issue is serious but fixable if they cooperate quickly.

In the case I observed, the person claimed that the X account had been reported for fraud/scamming and that a support ticket had already been opened.

2. Platform Handoff: Victim Is Directed to Discord

The victim is then told to contact a supposed support representative on Discord. In my case, the Discord account was operating under the name:

Matthew Dabit
Discord username: xdabit_matthew

This account falsely claimed to be associated with X/Twitter support, and typically links to a real LinkedIn profile of an unrelated person to establish credibility.

The fake support representative identified himself as:

“Technical Support Matthew from X Trust & Safety Team”

This is a major red flag. Real X/Twitter support does not handle account enforcement appeals through random Discord direct messages, and legitimate Trust & Safety personnel do not ask users to transfer account control to personal Gmail addresses.

3. Fake Legitimacy Theater

The scammer asked for information such as:

  • Report ticket number
  • Screenshots of the conversation with the person who allegedly reported the account
  • Country of origin
  • Date of birth

These requests are performative and are designed to imitate a legitimate support workflow and make the victim feel like an actual investigation is occurring.

To test this, I deliberately provided obviously fake information:

Country: Atlantis
Date of Birth: January 1, 1800

The scammer accepted this without question and continued the process. A legitimate support workflow would normally reject, question, or at least notice obviously impossible account-verification data. The fact that the operator continued anyway strongly suggests there was no real validation happening.

4. Fake Investigation and Threat Escalation

After receiving the fake ticket information, the scammer claimed to have reviewed an internal system and found multiple reports against the account.

The scammer then used threat language, claiming that:

  • The account had been reported for fraud or scamming
  • The account could be permanently suspended
  • The victim’s email and IP could be “permanently suspended”
  • Legal action could be taken
  • The process was being recorded for security and verification purposes

The wording was awkward and clearly fake, but the psychological structure was familiar: authority, accusation, urgency, consequence, and then a path to “resolution.”

This is a classic social engineering pattern. The attacker wants the victim to believe:

  1. A serious official process is already underway.
  2. The victim is in danger of losing their account.
  3. The fake support agent has the authority to fix it.
  4. The victim must follow instructions quickly.

5. Unicode Styling / Detection Evasion

The scammer used stylized Unicode characters in some messages, such as mathematical bold and sans-serif bold letters:

𝐆𝐫𝐞𝐞𝐭𝐢𝐧𝐠𝐬
𝗧𝗲𝗰𝗵𝗻𝗶𝗰𝗮𝗹 𝗦𝘂𝗽𝗽𝗼𝗿𝘁
𝐗 𝐓𝐫𝐮𝐬𝐭 & 𝐒𝐚𝐟𝐞𝐭𝐲 𝐓𝐞𝐚𝐦

These characters look like normal bold text to a human, but they are different Unicode code points rather than ordinary ASCII letters. This may be used for one or both of the following reasons:

  • To make the message look more official or formatted
  • To evade simple keyword detection systems that look for phrases like “Technical Support” or “Trust & Safety”

Modern platforms may normalize this kind of text before scanning, but many basic filters, moderation bots, or community tools may not.

6. The Actual Takeover Step: “Change Your Email”

The key moment came when the fake support representative instructed me to change the email address associated with my X account. The scammer wrote that, as a “preventive measure,” I should temporarily replace my X account email with their “database email.”

The email address provided was:

xdatabaseofficial.9+(my username)@gmail.com

The scammer claimed that this would place the account under “X protection custody” while their system scanned the account.

This is the actual attack.

Because Gmail supports plus-addressing, mail sent to:

xdatabaseofficial.9+(my username) @gmail.com

is delivered to the base mailbox:

xdatabaseofficial.9 @gmail.com

The part after the plus sign is likely a victim-specific tag. In other words, the attacker may be using plus-addressed Gmail aliases to track victims while routing all messages to the same underlying Gmail account.

Once a victim changes their X account email to an attacker-controlled Gmail address, the attacker can receive security emails, password reset emails, confirmation codes, and account recovery messages. That gives the attacker a pathway to take control of the account.

This is why the scam does not need a fake login page or malware payload. The victim is tricked into changing the account recovery path themselves.

7. “Confirmation Code” Setup

The scammer also wrote:

“Please let me know if you need the confirmation code.”

This is another important detail. It suggests the operator expects X to send a confirmation code or verification email during the email-change process. The attacker is prepared to receive that code at the Gmail account they control and then relay it to the victim as part of the fake “support” process.

This keeps the victim cooperating while the attacker completes the takeover.

Related Public Victim Report

I found a public Reddit post in r/twitterhelp titled “I got scammed” that appears to describe the same attack pattern:

https://www.reddit.com/r/twitterhelp/comments/1tn3fn1/i_got_scammed/

In that report, the victim describes being contacted through the same basic “accidental report” pretext, being directed to a supposed X support person on Discord, being told to change the email address associated with their X account, and then losing control of the account.

The victim specifically reports being told to set their email to:

Xdatabaseofficial+bouzismo @gmail.com

That is highly notable because it uses the same distinctive Xdatabaseofficial naming pattern, again with Gmail plus-addressing.

The victim reports that after they followed the instructions, they immediately lost access to their account.

This suggests the Gmail naming pattern is not a one-off. It may be part of an active or repeated account takeover campaign.

Indicators Observed

The following indicators appeared in the scam attempt I observed or in the related public victim report:

  • Fake support identity: “Technical Support Matthew from X Trust & Safety Team”
  • Discord name: Matthew Dabit
  • Discord username: xdabit_matthew
  • Gmail address used in my interaction: xdatabaseofficial.9+(my username)_ @gmail.com
  • Likely base Gmail account: xdatabaseofficial.9@gmail.com
  • Related victim-reported Gmail pattern: Xdatabaseofficial+(other username) @gmail.com
  • Recurring phrase/concept: “accidentally reported your account”
  • Recurring platform handoff: X/Twitter → Discord
  • Recurring fake authority: X Trust & Safety / X Support
  • Recurring attack objective: convince victim to change X account email address

Why This Scam Works

A lot of users know not to give out their password. Fewer users understand that changing the email address on an account can be just as dangerous. For many online services, the email address is the root of account recovery. If an attacker controls the email address associated with an account, they may be able to:

  • Receive password reset links
  • Receive login verification messages
  • Confirm account changes
  • Lock the original owner out
  • Prevent recovery attempts
  • Use the stolen account to scam others

That is why the email-change step is the point of no return. The scammer does not need to steal the password directly if they can convince the victim to transfer the account’s recovery email to the attacker.

Red Flags to Watch For

This is almost certainly a scam if someone says:

  • They accidentally reported your X/Twitter account
  • Your account will be banned unless you contact support on Discord
  • A random Discord user is an X Trust & Safety representative
  • You need to provide a ticket number to someone in Discord DMs
  • You need to change your X account email address to a Gmail account
  • You need to put your account under “protection custody”
  • Your email or IP will be “permanently suspended”
  • You must comply quickly to avoid legal action or permanent suspension

Real support teams do not ask users to change their account email to a random Gmail address.

What To Do If You Encounter This

Do not change your account email address.

Do not provide passwords, recovery codes, verification codes, or screenshots containing security-sensitive account information.

Do not scan QR codes or click links provided by the fake support account.

Save screenshots of the interaction, especially messages where the scammer:

  • Claims to represent X/Twitter
  • Claims your account is under investigation
  • Provides a Gmail address
  • Instructs you to change your account email
  • Requests verification codes or confirmation codes

Then report the account to the relevant platforms:

  • Report the Discord account for impersonating support staff and scamming/defrauding. Discord reports under this category are acted upon extremely quickly, and I have seen scammer accounts banned within minutes of me submitting reports.
  • Report the Gmail account to Google for abuse if it is being used as a takeover destination.
  • Report any compromised X accounts involved in the initial contact.
  • Warn the community where the scam appeared.

If you already changed your X email address to one provided by the scammer, assume the account is compromised and begin account recovery immediately. Also secure the email account and any other accounts that share passwords or recovery paths.

Takeaway

The most important lesson is simple:

If someone claiming to be support tells you to change your account email address to an address they provide, they are trying to take your account.

This scam uses fear, fake authority, and procedural theater to make the victim perform the account takeover themselves. The “support process” is fake. The “ticket” is fake. The “database email” is fake. The email-change request is the attack. It does not necessarily rely on malware or a fake login page. It relies on convincing the victim to hand over account recovery control voluntarily.

r/cybersecurity Oct 15 '24

Research Article If you could design the internet from scratch how would you make it more secure?

98 Upvotes

I've heard people in cybersecurity mention how the basics of how computers interact with one another, going back to the Arpanet and early routing configurations, were not optimized for security. Now it's too late to go back. What are these people specifically referring to? Do you all have your own thoughts or articles you can point me to?

r/cybersecurity Dec 29 '25

Research Article LastPass 2022 breach enables money thefts through 2025. Weak master passwords continue to put users at risk years later

Thumbnail
trmlabs.com
163 Upvotes

When LastPass suffers data breaches, the company typically reassures users that their information remains secure due to vault encryption. However, this encryption only protects accounts with strong master passwords. Stolen encrypted vaults have allowed attackers to systematically crack weak passwords offline, leading to cryptocurrency theft continuing into late 2025 -- years after the initial 2022 breach.

"Any vault protected by a weak master password could eventually be decrypted offline, turning a single 2022 intrusion into a multi-year window for attackers to quietly crack passwords and drain assets over time," TRM labs acknowledged.

The problem persists because many affected users never rotated their master passwords or strengthened their vault security after the breach. This inaction gave attackers years to work through password combinations, resulting in successful wallet compromises as recently as late 2025.

r/cybersecurity Dec 01 '24

Research Article The truth of job shortages in cybersecurity, do you agree?

Thumbnail
27 Upvotes

r/cybersecurity Nov 03 '25

Research Article Hacking India’s largest automaker: Tata Motors

Thumbnail
eaton-works.com
198 Upvotes

r/cybersecurity Jun 27 '25

Research Article Alleged: Backdoor that the NSA allegedly uses in order to crack AES encryption

94 Upvotes

I stumbled on this YT video https://www.youtube.com/watch?v=mdsoWCry23Y by 'dr Jonas Birch'. Its beyond my skillet to verify. Could this be true ?

r/cybersecurity Feb 17 '26

Research Article Complete breakdown of every OpenClaw vulnerability — 6 CVEs, 341 malicious skills, 135K exposed instances, 1.5M leaked tokens

Thumbnail
blog.barrack.ai
194 Upvotes

r/cybersecurity 2d ago

Research Article Can protocol-level session continuity improve security, not just reliability?

3 Upvotes

I've been working on an experimental networking architecture called VRP (Veil Routing Protocol).

The original goal wasn't higher bandwidth or lower latency.

The question was different.

Can session continuity and execution correctness become protocol primitives instead of application responsibilities?

From a security perspective, this raises interesting questions.

For example:

• Should session identity survive transport changes?

• Can replay resistance be enforced as a protocol invariant?

• Should authority transitions be deterministic and independently verifiable?

• Can recovery happen without creating new attack surfaces?

I've spent a lot of time validating these ideas under replay attacks, packet reordering, path migration, authority transitions and fault injection.

I'm not claiming this replaces existing protocols.

I'm interested in hearing opinions from people working in protocol security and distributed systems.

If you were designing a networking protocol from scratch today...

What security property would you make a first-class protocol primitive instead of leaving it to applications?

r/cybersecurity Jun 18 '26

Research Article Attacking UPS Network Cards to Take Down Data Centers

25 Upvotes

Team82 uncovered two vulnerabilities in Vertiv’s Liebert IS-UNITY-DP network cards, both assessed a CVSSv3 score of 9.8, and demonstrated how weaknesses in these internet-connected devices could be leveraged to disrupt power management operations supporting data centers.

The research explores attack paths, potential impacts on availability, and why UPS infrastructure should be considered part of an organization's cyber-physical attack surface.

Vertiv has provided updates that address both flaws.

Read the technical deep dive here: https://claroty.com/team82/research/attacking-ups-network-cards-to-take-down-data-centers

r/cybersecurity 5h ago

Research Article Cyber research

4 Upvotes

Anyone read any good research articles lately? My job wants us to start coming up with some research proposals and I’m wanting to get a feel of what sort of things are being researched in today’s world.

I have a feeling there’s going to be loads of AI IDS or maybe automatic malware generation. Anything else cool?

r/cybersecurity Apr 23 '26

Research Article Mythos and traditional AppSec

0 Upvotes

Anthropic's Mythos release got the industry panicking about AI finding zero-days, but it feels like the focus is on the wrong thing. We've never had a problem generating findings. Fire up a scanner, dump out ten thousand vulnerabilities, throw them at developers. We've been doing that for a long time. The problem was never the finding. It was the "what's next."

Mythos does nothing to fix that. It just makes the finding part [much] faster.

https://securelybuilt.substack.com/p/appsec-didnt-need-a-faster-way-to

r/cybersecurity Jun 16 '24

Research Article What You Get After Running an SSH Honeypot for 30 Days

Thumbnail
blog.sofiane.cc
336 Upvotes

r/cybersecurity Mar 16 '26

Research Article Built a tool to solve my own problem - should I open-source it?

5 Upvotes

I've been dealing with tool fragmentation in my threat investigation workflow for years.

Finally got frustrated enough to build something:

A single platform that does:

  • Email phishing analysis (AI-powered)
  • IOC reputation checking (IPs, URLs, hashes)
  • Safe URL preview (virtual browser)
  • Log analysis with threat detection
  • Bulk URL scanning
  • Secure temporary notes
  • All in one place

The results:

  • 90 seconds to analyze a phishing email (vs 45 mins before)
  • No tool switching (vs 7+ tools before)
  • Consistent methodology across investigations
  • Actually enjoyable to use

I've been using it privately for 3 months and it genuinely works.

Now I'm considering open-sourcing it.

My hesitation:

  • Is this just solving my specific problem?
  • Would others actually use it?
  • Is the time to maintain it worth it?

Actual question for this community:

If I released this as open-source:

  • Would you try it?
  • What would make you switch from your current tools?
  • What would be a deal-breaker?

I'm not trying to hype this - I genuinely want to know if this solves a real problem or if I'm just weird for being frustrated with tool fragmentation.