Milan Startup’s Bet: Assume the Breach, Then Trap the Attacker

Most security tools try to keep hackers out. Beelzebub, an Italian AI-native cybersecurity startup, operates on a darker assumption: the bad guys are already in. And instead of just detecting them, the company wants to trap them.

That bet just got a serious cash infusion. The Milan-based firm announced it raised €3 million (roughly $3.4 million) in a seed round led by VC United Ventures. With this latest injection, the company’s total funding now stands at $3.8 million.

The Beelzebub Platform: A Closed Loop for Intruders

Founded in 2025, Beelzebub has built a platform that fuses red-team and blue-team tactics into a single response system. The core idea is simple: if you can’t stop every intrusion, make the intrusion itself a losing game for the attacker.

The platform’s approach is built on a few key pillars:

• Continuous adversary emulation – It actively probes for attack paths before real criminals exploit them.
• Runtime deception technology – LLM-powered traps that lure attackers into a controlled environment.
• Autonomous threat intelligence – When an attack is intercepted, the system automatically converts it into actionable defenses.
• AI analyst – Dissects malware, generates full incident reports, and contains affected systems instantly.

The whole loop is designed to isolate a threat, trigger incident response, and learn from the encounter — all without waiting for a human analyst to catch up.

On-Premises for the Paranoid (and the Regulated)

One of the more interesting angles is deployment flexibility. The platform works as a SaaS, but it can also run entirely on-premises. That’s a critical feature for organizations in sensitive environments — think critical infrastructure or government-adjacent sectors — that can’t send data to cloud-based tools.

NIS2-Ready and Backed by a Global Threat Intel Network

Beelzebub isn’t just building traps; it’s also plugged into a live intelligence feed from over 60 independent researchers worldwide. That’s a significant network for a startup that’s barely a year old.

The platform is also designed to be NIS2-ready out of the box. For European organizations scrambling to meet the EU’s updated cybersecurity directive, that’s a selling point that could open doors.

Where the Money Goes: Rome, San Francisco, and a Bigger Research Team

Founder and CEO Mario Candela has clear plans for the fresh capital. The company will expand its research team, open new offices in Rome and San Francisco, and aggressively pursue clients across Europe — with a focus on NIS2-regulated organizations.

“Cybersecurity is a nonstop battle, and one that humans can no longer fight alone,” Candela said. “AI-powered attackers are too powerful, too competent, too fast, and too numerous, meaning the only way to fight back is at the same pace and intensity.”

He emphasized that the product adapts to new malware and stays updated to match the current state of the most sophisticated attacks.

The Bigger Picture: AI vs. AI in Cybersecurity

Beelzebub’s approach reflects a broader trend in the industry. As attackers weaponize AI to automate their campaigns, defenders are being forced to respond with AI of their own. The days of relying solely on human analysts to spot and stop intrusions are fading fast.

The funding round also signals growing investor confidence in deception-based defense. It’s a niche but increasingly vital segment of the market, and Beelzebub’s hybrid red/blue team model gives it a distinctive position.

For those tracking the space, it’s worth watching how the company scales its threat intelligence network and whether its on-premises offering gains traction with NIS2-regulated firms.

Related coverage: AI-powered email security funding and composable security operations platforms have also drawn significant investment recently.

Malicious Vite npm Packages: A New Supply Chain Threat

Cybersecurity researchers at Checkmarx have uncovered a cluster of seven malicious npm packages targeting the Vite frontend tooling ecosystem. Dubbed ViteVenom, the campaign is an evolution of an earlier operation called ChainVeil, which used a four-tier blockchain-based command-and-control (C2) infrastructure spanning Tron,

The attackers are sneaking remote access trojans (RATs) into developer environments through packages that appear legitimate. If you’re a frontend developer using Vite, this is a wake-up call.

How the ViteVenom Attack Works

The malicious packages are designed to slip past standard security checks. They use blockchain transactions as their C2 channel, making detection far harder than traditional HTTP-based malware.

Checkmarx noted that ChainVeil’s C2 infrastructure was “unprecedented” because it relied on smart contracts to issue commands. ViteVenom continues that trend, embedding malicious code in packages that mimic Vite plugins or utilities.

The Seven Malicious Packages

While Checkmarx didn’t name all seven packages in public disclosures, the campaign targets developers who install Vite-related dependencies. The packages are likely published under names that resemble popular Vite plugins, a common typosquatting tactic.

Once installed, the RAT can steal credentials, exfiltrate source code, and even pivot to other systems on the developer’s network.

Why Blockchain C2 Is a Game-Changer for Attackers

Traditional C2 servers can be taken down by security teams. Blockchain C2, however, is decentralized. Commands are embedded in transactions on networks like Tron, making them nearly impossible to shut down.

This is a significant escalation in supply chain attacks. Security tools that rely on blocklists or domain reputation won’t catch this activity.

For developers, the risk is real: a single malicious package can compromise your entire project and your machine.

How to Protect Yourself from Malicious npm Packages

Here’s what you can do to stay safe:

• Audit your dependencies regularly with npm audit or tools like Snyk.
• Check package popularity and publish dates before installing. New packages with few downloads are red flags.
• Use lockfiles to pin exact versions and avoid surprise updates.
• Run scans for known malicious packages, especially those flagged by npm security advisories.
• Consider using a proxy registry that filters malicious packages.

Also, be cautious with packages that request broad permissions or include obfuscated code. If something looks off, inspect the code before running it.

What This Means for the Vite Ecosystem

Vite has become a go-to build tool for modern frontend projects, so it’s no surprise attackers are targeting it. The ViteVenom campaign shows that even trusted ecosystems aren’t immune.

Checkmarx’s findings highlight the need for stronger supply chain security. Developers should treat every dependency as a potential attack vector.

If you’ve installed any suspicious Vite-related packages recently, review your environment immediately. Remove unknown dependencies and rotate any credentials that might have been exposed.

The threat landscape is evolving, and blockchain-based C2 is just the beginning. Stay vigilant.

Eleven Bytes, 131 KB of Frozen Memory

Eleven bytes. That’s all it takes to make an unpatched OpenSSL server set aside up to 131 KB of memory for a message that never arrives. On glibc systems, that memory stays locked until the process restarts. Not great for a production server.

This is the HollowByte flaw, a denial-of-service bug that Okta’s Red Team found, named, and reported. The team published its findings after OpenSSL shipped a fix — quietly, with no CVE, no advisory, and no changelog entry pointing at it.

So how does a tiny TLS request cause so much damage? The trick lies in how OpenSSL handles certain message fragments. A crafted 11-byte request triggers an allocation that never gets freed. Repeat it enough times, and you’ve got a memory leak that grinds the server to a halt.

What Exactly Is HollowByte?

HollowByte is a memory exhaustion vulnerability in OpenSSL’s TLS handling. It doesn’t require authentication. It doesn’t need special privileges. Just a network connection and a carefully constructed request.

Okta’s Red Team discovered that sending a specific 11-byte TLS message causes the server to allocate memory for a response that never comes. On systems using glibc — the standard C library on most Linux distributions — that allocated memory isn’t reclaimed. It sits there, frozen, until the process dies.

The impact? An attacker can send repeated requests to exhaust available memory, effectively freezing the server. It’s a classic DoS vector, but with a twist: the trigger is absurdly small.

Why glibc Makes It Worse

The memory behavior isn’t universal. On some systems, the allocation gets cleaned up. But glibc’s allocator handles certain patterns differently, and that’s where the freeze happens. Okta’s testing showed the memory staying put until restart — no garbage collection, no cleanup, just a slow leak that compounds.

For organizations running OpenSSL on glibc-based systems, this is a real problem. A single connection isn’t dangerous. Thousands of them? That’s a different story.

OpenSSL’s Quiet June Fix

Here’s the part that’s raising eyebrows. OpenSSL patched HollowByte in June — but did it without a CVE, without a security advisory, and without a changelog entry that mentions the vulnerability.

That’s unusual. Security fixes typically get publicized so administrators know to update. A silent patch means many systems remain vulnerable, simply because nobody knows to apply the update.

Okta’s Red Team, which reported the bug and gave it the HollowByte name, published its research to fill that gap. The disclosure includes technical details on how the attack works and which versions are affected.

Who’s Affected and What to Do

If you’re running OpenSSL on a glibc-based system, you need to check your version. The fix shipped in June, so any version before that is vulnerable. The exact version numbers are in Okta’s disclosure.

Here’s what to do right now:

• Update OpenSSL to the latest patched version. Don’t wait for a CVE announcement.
• Check your changelog — if you’re on a version from June or later, verify it includes the fix.
• Monitor memory usage on TLS-facing servers. Unexpected spikes could indicate an attack.
• Restrict network access to TLS endpoints where possible, limiting who can send requests.

The update itself is straightforward. The challenge is knowing you need it.

The Bigger Problem: Silent Security Fixes

HollowByte highlights a broader issue in open-source security: fixes without fanfare. When a vulnerability is patched silently, the window of exposure stretches. Attackers who reverse-engineer the patch can exploit systems that haven’t updated — and they’ll do it before the news spreads.

Okta’s decision to publish the research after the patch is a pragmatic move. It alerts the community while giving administrators a heads-up. But it also raises questions: how many other HollowByte-style flaws are out there, patched but unannounced?

For security teams, the lesson is clear. Don’t rely solely on CVE alerts. Regularly audit your dependencies, track upstream changes, and test for unusual behavior. A silent patch is still a patch — but only if you apply it.

Interested in related security topics? Check out our guides on TLS certificate management and denial-of-service attack prevention for more context on keeping your infrastructure safe.