Built a disposable file transfer tool with a focus on minimising server-side trust. Wanted to share the architecture and get feedback from people who break things for a living.

burnbox.au

Crypto stack:

AES-256-GCM for file encryption. Argon2id (32MB memory, 3 iterations) for password-protected files. PBKDF2 fallback for devices that choke on WASM. 96-bit unique IV per encryption. Key derived client-side, stored in URL fragment (never transmitted to server).

Threat model:

Server compromise returns only encrypted blobs. No plaintext filenames (encrypted and padded to 256 bytes). No key material server-side. Burn-after-reading enforced atomically in Postgres (prevents race conditions). Database stores: encrypted blob, padded filename, approximate size, expiry timestamp.

Not protected against:

Compromised endpoints. Link interception (share via secure channel). Malicious browser extensions. Coercion.

Architecture:

Static frontend on Netlify. Supabase backend (Postgres + Edge Functions). Retrieve requests proxied through Netlify (Supabase sees CDN IP, not user IP). Row Level Security blocks direct storage access. Downloads only via Edge Function with service role.

Source: gitlab.com/burnbox-au1/Burnbox-au

Interested in feedback on the implementation. What am I missing?

Analyzed a browser-only tech support scam that relies entirely on client side deception and no malware dropped.

The page abuses full screen and input lock APIs, simulates a fake CMD scan and BSOD, and pushes phone based social engineering.

Hi, after my last post, most of you said that you had no more need for another Newsletter. So I thought of other ways to use the content and now put it into a directory.

You can use it 100% for free.

Just tell me what you want adjusted or added.

Site is still in Beta

Thank you

I built DVAIB (Damn Vulnerable AI Bank) - a free, hands-on platform to practice attacking AI systems in a legal, controlled environment.

Features 3 scenarios: Deposit Manipulation (prompt injection), eKYC Document Verification (document parsing exploits), and Personal Loan (RAG policy disclosure attacks).

Includes practice and real-world difficulty tiers, leaderboard, and achievement tracking.

Following up on the Careless Whisper research from University of Vienna / SBA Research (published late 2024, proof-of-concept public as of December 2025):

Protocol-level vulnerability:

Both Signal and WhatsApp use the Signal Protocol for E2EE, which is cryptographically sound. Both platforms, however, emit unencrypted delivery receipts—protocol-level acknowledgements of message delivery.

The research demonstrates a side-channel where RTT characteristics of delivery receipts leak recipient behavioural patterns. This is not a cryptographic issue. This is an information-leakage issue where an auxiliary channel (delivery receipt timing) reveals what the primary channel (encrypted messages) is supposed to conceal: who's communicating, when, and from where.

Attack surface:

• Delivery receipts are unencrypted, per-message acknowledgements
• RTT measurements (even with jitter) remain correlated with device state
• Repeated probing builds statistical fingerprints of behavioural patterns
• Victims experience no notifications or evidence of probing

Platform architectures:

• Signal: Sealed sender + metadata encryption makes this harder but not impossible. Server doesn't know sender identity, but receipt timing still correlates with recipient availability.
• WhatsApp: Server-side metadata handling more permissive. Receipt timing correlates with both sender and recipient state.

Signal's architecture mitigates this better but doesn't eliminate it. WhatsApp's architecture provides less protection.

Current mitigation status:

• Rate limiting: Signal implemented (Dec 2025), WhatsApp has not
• Protocol fixes: Neither platform has implemented substantive changes
• User-level controls: Disabling receipts helps, but attacks work at lower frequencies

Why this matters for protocol design:

This is a good case study in why you can't evaluate messaging security through encryption alone. You need to think about:

• What metadata signals does the system emit?
• Can those signals be correlated to reveal patterns?
• What does the threat model assume about these signals?

For detailed technical analysis, research citations, mitigation strategies, and threat model implications.

40 years to the random, brilliant, insightful, demented masterpiece that hackers for the past forty years, and for a thousand years to come, would identify themselves in.

“The Conscience of a Hacker”, also known as The Hacker Manifesto.

Happy birthday!

Came across this post claiming 67% of AI usage happens through unmanaged personal accounts. Got me thinking about our own dumpster fire.

We rolled out SSO and identity controls, but employees just bypass everything. CRM, AI tools, you name it, all accessed like consumer apps.

The implications are terrifying. Zero visibility into what data is being fed to these tools. No audit trails.

What’s your take here?

The vulnerability was discovered by daytriftnewgen and fixed by fzipi and airween in the latest patch.
Edited: Full discovery story is public now: https://medium.com/@daytrift.newgen/cve-2026-21876-a-short-story-of-a-waf-bypass-discovery-2654a763eb73

‍I discovered a critical vulnerability (CVE-2026-21858, CVSS 10.0) in n8n that enables unauthorized attackers to take over locally deployed instances, impacting an estimated 100,000 servers globally.

This vulnerability is a logical bug, which I call - a (Content-)Type Confusion.
Let me know what you think!

Hi everyone, I wrote a practical guide to finding soundness bugs in ZK circuits. It starts out with basic Circom examples, then discusses real-world exploits. Check it out if you are interested in auditing real-world ZK deployments.

The tool is more important than the blog post; it does everything automatically for you: https://github.com/Adversis/tailsnitch

A security auditor for Tailscale configurations. Scans your tailnet for misconfigurations, overly permissive access controls, and security best practice violations.

And if you just want the checklist: https://github.com/Adversis/tailsnitch/blob/main/HARDENING_TAILSCALE.md

Graph Code: https://osf.io/8kd5f

Graph: https://osf.io/jpqey/files/ytms6

The HardBit ransomware family’s fourth iteration exhibits elevated operational security with mandatory operator-supplied runtime authorization, blurring forensic attribution. Its dual interface models, leveraging legacy infection deployment alongside contemporary hands-on-keys techniques, and an optional destructive wiper mode, represent hybrid malware design converging extortion and sabotage.

Lateral movement enabled through stolen credentials and disablement of recovery vectors reflects targeting of high-value networks for durable control. The absence of data leak websites limits external visibility into victimology, complicating response efforts. This evolution spotlights the intensifying sophistication and malice of ransomware operations.

Hi everyone,

I’m a 24-year-old cybersecurity and information security consultant working for a company in the Netherlands. I hold an HBO-level education and my main area of expertise is social engineering, with a strong focus on mystery guest and physical security assessments for clients.

Currently, I’m the only employee performing these types of projects. Our team was reduced from six people to just me, mainly to move away from multiple individual working styles and to allow the others to focus on long-term projects such as (C)ISO-related work.

Regarding physical security, my goal is to move toward an approach where I not only perform the physical tests (such as mystery guest or intrusion-style assessments), but also expand into providing advisory input on the theoretical and organizational side based on the findings. At the moment, my role is limited to executing the assessments and delivering the final report.

I’d like to further develop my skills and deepen my expertise by obtaining a certification this year (or however long it realistically takes). However, I’m finding it difficult to identify certifications that truly fit this niche. I’ve broadened my search beyond mystery guest and physical security to certifications focused on social engineering, ideally including the psychological or human-factor aspects, while still remaining rooted in security testing. OSINT certs like added aren’t relevant enough, since there isn’t enough interest from clients.

Most psychology-oriented certifications are unfortunately not an option for me, as they require an HBO diploma with a psychology background. My background is in cybersecurity, and I’d prefer something that builds on that.

Practical constraints: • Budget: ~€5,000 (with some flexibility if there’s a strong case) • Time: I work full-time (40 hours), run my own business on the side, and have a private life, so anything requiring extreme workloads (e.g. 100+ hours/week) is not realistic • Format: Online is preferred unless the training is located in the Netherlands or nearby regions in Belgium or Germany • Language: English or Dutch

I don’t currently hold any certifications in this specific area.

Does anyone have experience with certifications related to social engineering, human factors, or physical security testing that would fit this profile? Any recommendations or insights would be greatly appreciated.

Spent few days analysing MongoDB, please summarize the analysis and findings.

MongoBleed, tracked as CVE-2025-14847, an unauthenticated memory disclosure vulnerability affecting MongoDB across multiple major versions. It allows remote clients to extract uninitialized heap memory from the MongoDB process using nothing more than valid compressed wire-protocol messages.

This is not native RCE. This is not an issue on the library zlib, is more on the compression-decompression and It is a memory leak. It does not leave a lot of traces, It is silent, repeatable, and reachable before authentication.

TL;DR for engineering teams

• What broke MongoDB’s zlib decompression path trusts attacker-controlled length metadata.
• Impact Unauthenticated heap memory disclosure.
• What leaks Raw process memory fragments including credentials, tokens, config strings, runtime metadata, and recently processed data.
• Auth required None.
• Noise level Low. No crashes. No malformed packets. Minimal logs.
• Exposure 213,490 publicly reachable MongoDB instances observed via Shodan on 29 Dec 2025.
• Fix Upgrade immediately or disable zlib compression.
• Reality check Public PoC exists. Scanning is trivial. Exploitation effort is low (links below on the exploit lab, explaination and scanners if you want to find yours

Links

- Full Detailed Blog: https://phoenix.security/mongobleed-vulnerability-cve-2025-14847/

- Exploit explanation and lab: https://youtu.be/EZ4euRyDI8I

- Exploit Description (llm generated from article): https://youtu.be/lxfNSICAaSc
- Github Exploit for Mongobleed: https://github.com/Security-Phoenix-demo/mongobleed-exploit-CVE-2025-14847/tree/main
- Github Scanner for web: https://github.com/Security-Phoenix-demo/mongobleed-exploit-CVE-2025-14847/tree/main/scanner
- Github Scanner for Code: https://github.com/Security-Phoenix-demo/mongobleed-exploit-CVE-2025-14847/tree/main/code-sca

(Note I spend more time writing exploits, have dyslexia, and I'm not a native English, an LLM proofreads some sections, if this offends you, stop reading)

Affected versions

MongoDB Server	Vulnerable versions	Fixed versions
8.2.x	8.2.0 – 8.2.2	8.2.3
8.0.x	8.0.0 – 8.0.16	8.0.17
7.0.x	7.0.0 – 7.0.27	7.0.28
6.0.x	6.0.0 – 6.0.26	6.0.27
5.0.x	5.0.0 – 5.0.31	5.0.32
4.4.x	4.4.0 – 4.4.29	4.4.30
4.2.x	All	EOL
4.0.x	All	EOL
3.6.x	All	EOL

SAAS version of MongoDB is already patched

Technical anatomy

MongoDB supports network-level message compression.

When a client negotiates compression, each compressed message includes an uncompressedSize field.

The vulnerable flow looks like this:

1. Client sends a syntactically valid compressed MongoDB wire-protocol message
2. Message declares an inflated uncompressedSize
3. MongoDB allocates a heap buffer of that declared size
4. zlib inflates only the real payload into the start of the buffer
5. The remaining buffer space stays uninitialized
6. MongoDB treats the entire buffer as valid BSON
7. BSON parsing walks past real data into leftover heap memory

Memory gets leaked out, not a lot of IOC to detect

Root cause (code-level)

The vulnerability originates in MongoDB’s zlib message decompression logic:

src/mongo/transport/message_compressor_zlib.cpp

In the vulnerable implementation, the decompression routine returned:

return {output.length()}; 

output.length() represents the allocated buffer size, not the number of bytes actually written by ::uncompress().

If the attacker declares a larger uncompressedSize than the real decompressed payload, MongoDB propagates the allocated size forward. Downstream BSON parsing logic consumes memory beyond the true decompression boundary.

The fix replaces this with:

return length; 

length is the actual number of bytes written by the decompressor.

Additional regression tests were added in message_compressor_manager_test.cpp to explicitly reject undersized decompression results with ErrorCodes::BadValue.

This closes the disclosure path.

Why is this reachable pre-auth

Compression negotiation occurs before authentication.

The exploit does not require:

• malformed compression streams
• memory corruption primitives
• race conditions
• timing dependencies

It relies on:

• attacker-controlled metadata
• valid compression
• Incorrect length propagation

Any network client can trigger it, hence is super easy to deploy

Exploitation reality

A working proof of concept exists and is public, more details:

• Original PoC by Joe Desimone https://github.com/joe-desimone/mongobleed/
• Technical analysis and reproduction details https://doublepulsar.com/merry-christmas-day-have-a-mongodb-security-incident-9537f54289eb
• Github Exploit for Mongobleed: https://github.com/Security-Phoenix-demo/mongobleed-exploit-CVE-2025-14847/tree/main
• Github Scanner for web: https://github.com/Security-Phoenix-demo/mongobleed-exploit-CVE-2025-14847/tree/main/scanner
• Scanner for Code: https://github.com/Security-Phoenix-demo/mongobleed-exploit-CVE-2025-14847/tree/main/code-sca

The PoC:

• negotiates compression
• sends crafted compressed messages
• iterates offsets
• dumps leaked memory fragments to disk and saves it locally

No credentials required.

No malformed packets.

Repeatable probing.

What actually leaks

Heap memory is messy. That is the point.

Observed and expected leak content includes:

• database credentials
• SCRAM material
• session tokens
• API keys
• WiredTiger config strings
• file paths
• container metadata
• client IPs and connection details
• fragments of recently processed documents

The PoC output already shows real runtime artifacts.

This is not RCE, but steals pieces of memory, which is not as bad as RCE but still very dangerous (Heartbleed anyone)

MongoBleed does not provide native remote code execution.

There is no instruction pointer control. No shellcode injection. No crash exploitation.

What it provides is privilege discovery.

Memory disclosure enables:

• credential reuse
• token replay
• service-to-service authentication
• CI/CD compromise
• cloud control plane access

A leaked Kubernetes token is better than RCE.

A leaked CI token is persistent RCE.

A leaked cloud role is full environment control.

This is RCE-adjacent through legitimate interfaces.

How widespread is this

MongoDB is everywhere.

Shodan telemetry captured on 29 December 2025 shows:

213,490 publicly reachable MongoDB instances

Version breakdown (port 27017):

Version	Count	Query
All versions	201,659	product:"MongoDB" port:27017
8.2.x	3,164	"8.2."
8.0.x (≠8.0.17)	13,411	"8.0." -"8.0.17"
7.0.x (≠7.0.28)	19,223	"7.0." -"7.0.28"
6.0.x (≠6.0.27)	3,672	"6.0." -"6.0.27"
5.0.x (≠5.0.32)	1,887	"5.0." -"5.0.32"
4.4.x (≠4.4.30)	3,231	"4.4." -"4.4.30"
4.2.x	3,138	"4.2."
4.0.x	3,145	"4.0."
3.6.x	1,145	"3.6."

Most are directly exposed on the default port, not shielded behind application tiers.

Core behaviors that matter

• Unauthenticated Any client can trigger it.
• Remote and repeatable Memory offsets can be probed over time.
• Low noise No crashes. Logs stay quiet.
• Data agnostic Whatever was on the heap becomes fair game.

This favors patient actors and automation.

Detection guidance

IOC Identification Network-level signals

Look for:

• Inbound traffic to port 27017
• compressed MongoDB messages
• Repeated requests with:
  • large declared uncompressedSize
  • small actual payloads
• high request frequency without auth attempts

Process-level signals

Watch for:

• elevated CPU on mongod without query load
• repeated short-lived connections
• memory allocation spikes
• abnormal BSON parsing warnings

Post-leak fallout

Check for:

• new MongoDB users
• role changes
• admin command usage anomalies
• auth attempts from unfamiliar IPs
• API key failures
• cloud IAM abuse
• new outbound connections

If you see filesystem artifacts or shells, you are already past exploitation.

Temporary protections

If you cannot upgrade immediately:

• Disable zlib compression Remove zlib from networkMessageCompressors
• Restrict network access Remove direct internet exposure Enforce allowlists

These are stopgaps. The bug lives in the server - hence patch

Tooling and validation

A full test suite is available, combining:

• exploit lab (vulnerable + patched instances)
• network scanner
• code scanner for repos and Dockerfiles

Repository:

https://github.com/Security-Phoenix-demo/mongobleed-exploit-CVE-2025-14847

This allows:

• safe reproduction
• exposure validation
• pre-deployment detection

Why this one matters

MongoBleed does not break crypto it breaks data and memory

The database trusts client-supplied lengths.

Attackers live for that assumption.

Databases are part of your application attack surface.

Infrastructure bugs leak application secrets.

Vulnerability management without reachability is incomplete.

Patch this.

Then ask why it was reachable.

A blog post on a technique I've been sitting on for almost 18 months that is wildly succesful against all EDRs. Why? They don't see anything other than the file write to %USERPROFILE% (NTUSER.MAN) and not the writes to HKCU.

Ultimately making it incredibly effective for medium integrity persistence through the registry/without tripping detections.

Questions regarding netsec and discussion related directly to netsec are welcome here, as is sharing tool links.

Rules & Guidelines

• Always maintain civil discourse. Be awesome to one another - moderator intervention will occur if necessary.
• Avoid NSFW content unless absolutely necessary. If used, mark it as being NSFW. If left unmarked, the comment will be removed entirely.
• If linking to classified content, mark it as such. If left unmarked, the comment will be removed entirely.
• Avoid use of memes. If you have something to say, say it with real words.
• All discussions and questions should directly relate to netsec.
• No tech support is to be requested or provided on r/netsec.

As always, the content & discussion guidelines should also be observed on r/netsec.

Feedback

Feedback and suggestions are welcome, but don't post it here. Please send it to the moderator inbox.

nullspace - ssrf protection for node.js

• blocks private ips, cloud metadata, loopback

• handles encoding tricks (0x7f000001 = 127.0.0.1)

• dns rebinding protection built-in

• zero deps

github : [ https://github.com/bymehul/nullspace ]

Vulnerability Listing

Presentation VoD

YouTube rehost (by the authors)

Working with a CTO on visibility into what's actually running locally across a 70-engineer org. (For the context, there's no ZTNA implementation, At the moment, if there's a way to approach it from ZTNA angle, I'd love to know)

Engineers use cursor heavily, started adopting MCPs, and now there's a mix of verified, open source, and basically untrusted github repos running locally.

Customer creds are accessible from these environments. We want visibility first - detect what MCPs exist, where they're installed, track usage.

That part feels tractable. But from a detection/monitoring angle, once you know what's there - what's worth actually watching?

Some MCPs legitimately need local execution so you can't just block them. Full network proxying feels unrealistic for dev workflows.

How you approached it? what can implement after visibility?

Static analysis is necessary, but it feels incomplete when it comes to how systems behave under real conditions. How are others dealing with that gap

When attackers use real credentials, everything they do can appear legitimate. Runtime monitoring often becomes the only way to spot it. How do you approach this in practice?

I’m approaching prompt injection less as an input sanitization issue and more as an authority and trust-boundary problem.

In many systems, model output is implicitly authorized to cause side effects, for example by triggering tool calls or function execution. Once generation is treated as execution-capable, sanitization and guardrails become reactive defenses around an actor that already holds authority.

I’m exploring an architecture where the model never has execution rights at all. It produces proposals only. A separate, non-generative control plane is the sole component allowed to execute actions, based on fixed policy and system state. If the gate says no, nothing runs. From this perspective, prompt injection fails because generation no longer implies authority. There’s no privileged path from text to side effects.

I’m curious whether people here see this as a meaningful shift in the trust model, or just a restatement of existing capability-based or mediation patterns in security systems.

Runtime threats rarely trigger obvious alerts. Usually something just feels slightly off before anything breaks. What subtle signs have tipped you off in the past?

A lot of environments look secure on paper, but runtime attacks often operate quietly. Credential misuse, app-layer abuse, and supply chain compromises tend to blend in rather than break things. What runtime signals have actually helped you catch issues early?

I am presenting a verified second-preimage collision for the SHA-256 algorithm, specifically targeting the Bitcoin Genesis Block header (Hash: 000000000019d668...).

Unlike previous theoretical differential attacks, this method utilizes a structural exploit in the message schedule (W-schedule) to manipulate internal states during the compression function. This allows for the generation of an alternative preimage (Kaoru DNA) that results in an identical 256-bit output.

Key Technical Aspects:

• Target: SHA-256 Second-preimage resistance.
• Exploit Vector: Internal state extraction via W-schedule structural weakness.
• Verification: The collision is bit-perfect and can be verified using any standard SHA-256 implementation.

This discovery suggests that the collision resistance of SHA-256 is fundamentally compromised under specific state-transition conditions.

Verification Code: https://osf.io/2gdzq/files/dqghk

Every morning I find myself scrolling through 50+ tabs of RSS feeds, BleepingComputer, and CISA alerts. It’s exhausting.

​I started a project called Threat Road to curate the "Top 3" most critical stories daily with a focus on immediate mitigations. I want to make it as useful as possible for the community.

​I’d love your brutal honesty:

​What makes a security newsletter "instant delete" for you?

​Do you care about "Chili-pepper" risk ratings, or do you find them gimmicky?

​Would you rather have a deep dive on one bug or a brief on three?

​I'm just looking to hear what you all actually want in a daily briefing.

Little write-up for a patched WebSocket-based RCE I found in the CurseForge launcher.

It involved an unauthenticated local websocket API reachable from the browser, which could be abused to execute arbitrary code.

Happy to answer any questions if anyone has any!

Hey r/netsec -- it's been about two years since we last published a tool for the security community. As a little festive gift, today we're happy to announce the release of certgrep, a free Certificate Transparency search tool we built for our own detection work and decided to open up.

It’s focused on pattern-based discovery (regex/substring-style searches) and quick search and drill down workflows, as a complement to tools like crt.sh.

A few fun example queries it’s useful for:

• (login|signin|account|secure).*yourbrand.*
• \*.*google.*
• yourbrand.*(cdn|assets|static).*

We hope you like it, and would love to hear any feedback you folks may have! A number of iterations will be coming up, including API, SDKs, and integrations (e.g., Slack).

Enjoy!

A new research paper highlights a critical implementation flaw in how major vendors (ASUS, MSI, etc.) configure IOMMU during the DXE phase of boot.

The Core Issue:
The firmware reports DMA protection as "Active" to the OS, but fails to actually enable the IOMMU translation tables during the initial boot sequence. This creates a window of vulnerability where a malicious peripheral can read/write system memory unrestricted.

I've analyzed the root cause and the discrepancy between "Reported Status" vs "Actual Enforcement" in this report:
[👉 Full Analysis & Mitigation Strategies]https://www.nexaspecs.com/2025/12/critical-uefi-flaw-exposes-motherboards.html

Has anyone started seeing patched BIOS versions roll out yet?

Hi everyone,

Over the last month I’ve been analyzing modular addition not as a bitwise operation, but as a fractional mapping. Treating (a + b) mod 2^32 as a projection into the fractional domain [0, 1), modular “bit loss” stops behaving like noise and instead becomes predictable geometric wrapping.

This leads to what I call the Kaoru Method.

The core idea is to run a “Shadow SHA-256” in parallel using infinite precision arithmetic. By comparing the real SHA-256 state with the shadow state, it’s possible to reconstruct a Universal Carry Map (k) that fully captures all modular wraps occurring during execution.

Once k is recovered for the 64 rounds, the modular barriers effectively disappear and the compression function reduces to a system of linear equations.

In my experiments, a standard SHA-256 block produces exactly 186 modular wraps. This number appears stable and acts like a structural “DNA” of the hash computation.

Under this framework, differential cryptanalysis becomes significantly simpler, since the carry behavior is no longer hidden. I’m releasing both the theoretical framework and an extractor implementation so others can validate, attack, or extend the idea toward full collisions.

Paper (theory):
https://osf.io/jd392/files/4qyxc

Code (Shadow SHA-256 extractor):
https://osf.io/n9xcw

DOI:
https://doi.org/10.17605/OSF.IO/JD392

I’m aware this challenges some long-held assumptions about modular addition as a source of non-linearity, so I’m especially interested in feedback, counterexamples, or independent replication.

Thanks for reading.

Over one year ago the Goverment wanted to email the victims but Bitfinex denied it. But it is not too late yet if we act now. Did you hear of any availability of old crypto exchange user email addresses? Security researchers in possession of historic leak data could help to return $ nine digits to victims soon.
Please suggest specific forums for outreach.
Thanks!

Ranked list of 2016 exchanges: Poloniex Bitstamp OKCoin BTC-e LocalBitcoins Huobi Xapo Kraken CoinJoinMess Bittrex BitPay NitrogenSports-eu Cex-io BitVC Bitcoin-de YoBit-net Cryptsy HaoBTC BTCC BX-in-th Hashnest BtcMarkets-net Gatecoin Purse-io CloudBet Cubits AnxPro Bitcurex AlphaBayMarket Luno BTCC Loanbase Bitbond BTCJam Bit-x BitPay BitBay-net NucleusMarket PrimeDice BitAces-me Bter MasterXchange CoinGaming-io CoinJar Cryptopay-me FaucetBOX Genesis-Mining

Mac Malware analysis

A few days ago u/broadexample pointed out that our free STIX feed was doing it wrong:

"You're creating everything as Indicator, not as IPv4Address linked to Indicator via STIX Relationship hierarchy. This works when you use just this feed alone, but for everyone using multiple feeds it would be much less useful."

They were right. We were creating flat Indicator objects instead of proper STIX 2.1 hierarchy with SCOs and Relationships.

Fixed it today. New V2 endpoint with:

- IPv4Address SCOs with deterministic UUIDs (uuid5 for cross-feed deduplication)

- Relationship objects linking Indicator → SCO ("based-on")

- Malware SDOs for 10 families (Stealc, LummaC2, Cobalt Strike, etc.)

- Relationship objects linking Indicator → Malware ("indicates")

Should actually work properly in OpenCTI now.

V2 endpoint: https://analytics.dugganusa.com/api/v1/stix-feed/v2

V1 still works if you just need IOC lists: https://analytics.dugganusa.com/api/v1/stix-feed

Full writeup: https://www.dugganusa.com/post/stix-v2-reddit-feedback-opencti-ready

Thanks for the feedback. This is why we post here - you catch the stuff we miss.

During routine threat hunting on my Beelzebub honeypot, I caught something interesting: a Rust-based DDoS bot with 0 detections across 60+ AV engines at the time of capture.

TL;DR:

• The malware exploits exposed Docker APIs on port 2375
• Written in Rust using Tokio for async networking, bincode for the custom C2 protocol, and obfstr for string obfuscation
• Same server (196.251.100.116) for malware distribution (port 80) and C2 (port 8080), single point of failure.
• I decoded the C2 protocol and found it surprisingly weak: no encryption, predictable nonce, hardcoded username ("client_user")
• I built a honeypot that impersonates a bot to monitor DDoS attack targets 👀

In the post you'll find:

• Full attack chain of the Docker API exploitation
• Sandbox setup for dynamic analysis (Docker inside an isolated VM)
• Complete C2 protocol decoding
• YARA rule and Snort rule for detection
• All IoCs

The fact that no AV detected it shows that Rust + string obfuscation is making life hard for traditional detection engines.

Questions? AMA!