Forescout’s Vedere Labs has identified a previously undocumented malware delivery platform being used in ClickFix campaigns, alongside new delivery techniques associated with malware loaders linked to Vice Society ransomware activity.

The findings, published in two research blogs, examine what happens after victims fall for ClickFix lures. These attacks trick users into copying and running malicious commands, often under the pretence of fixing a technical problem or completing a verification step.

The investigations reveal how attackers deliver different malware families, conceal malicious files and establish access that could support further compromise.

ROMULUS serves multiple malware loaders

During an incident investigation, Forescout researchers discovered a server hosting a panel called ROMULUS. Further analysis identified six IP addresses exposing the same authentication interface and revealed a platform capable of delivering multiple malware loaders.

One of those addresses had previously been identified by Huntress in a campaign that abused ChatGPT’s Custom GPTs to direct victims towards pages hosting ClickFix lures. Forescout independently observed the same malware package being delivered from another ROMULUS server.

Researchers analysed two delivery routes. One used a trojanised installer containing legitimate Stardock software to load malicious code. The other delivered LegionLoader, a malware loader active since 2019, through a series of encrypted archives.

In the LegionLoader route, an archive smaller than 1 MB expanded into an executable exceeding 880 MB. Most of the executable’s size came from artificial padding, which can push files beyond security scanners’ upload limits or sandbox analysis thresholds.

A ROMULUS statistics page also displayed installation and execution counts, a timeline and a breakdown by country, potentially allowing operators to monitor campaign performance.

Forescout said the platform’s operators remain unknown. Researchers could not determine whether ROMULUS is a private tool, a commercial criminal service, an affiliate framework or software shared between operators.

Loader investigation reveals possible connection

The second blog examines Lorem Ipsum and Axolotl, two malware loaders whose relationship had not previously been documented in public research.

The investigation followed a September incident in which attackers used ClickFix to deploy Lorem Ipsum Loader and a Python tunnel client. Forescout contained the incident before ransomware was deployed, although researchers believe ransomware delivery was the attackers’ intended goal.

The tradecraft has previously been attributed to Vice Society, a cybercriminal group associated with several ransomware families, including Rhysida.

Researchers analysed five Lorem Ipsum samples from the incident and 39 Axolotl samples. They identified an additional Lorem Ipsum delivery method using MSI installers and multi-stage PowerShell, as well as three Axolotl variants using different host programs.

The analysis also found overlapping infrastructure and similarities in the loaders’ command-and-control communications. Although their code is distinct, Forescout said the findings suggest Lorem Ipsum may be a later iteration of Axolotl. Researchers could not establish that relationship conclusively.

Forescout recommends monitoring suspicious PowerShell activity, silent installer execution and unexpected DLL loading, alongside educating users about ClickFix and related lures that direct victims to Windows Terminal or PowerShell.

The post Forescout uncovers ROMULUS malware delivery platform behind ClickFix attacks appeared first on IT Security Guru.

Zero trust has become one of the most overused terms in security marketing, often applied to products that simply add another layer of network segmentation. This piece looks at what zero trust actually specifies according to its foundational standard, the implementation order that works in practice, and why identity is the dependency most organizations underestimate.

What Does Zero Trust Actually Specify, Beyond the Marketing Language?

Zero trust gets used loosely enough that it has largely lost precision as a term, applied to everything from a VPN replacement to a full architectural rebuild. That imprecision is a real problem for organizations trying to evaluate vendor claims, since two products both marketed as zero trust solutions can address entirely different parts of the actual model.

Organizations working through this evaluation often look at established regional providers as part of their planning. Among them, cybersecurity solutions in Dubai offer a starting point for comparing how different providers translate the zero trust framework into an actual implementation roadmap, which varies considerably depending on an organization’s existing infrastructure.

At its core, the specification requires continuous verification of every access request, whether it originates inside or outside the traditional network perimeter, and it removes the assumption that anything on the internal network is inherently trustworthy simply by virtue of its location.

Zero trust component	What it actually requires
Identity verification	Every access request authenticated, not just the initial network entry
Least privilege access	Access scoped to the minimum needed for a specific task
Micro segmentation	Network divided so lateral movement is contained, not just perimeter defended
Continuous monitoring	Access patterns evaluated ongoing, not just at login

That table names the components. The harder part, and the part most vendor pitches skip, is the order in which an organization actually implements them.

What Implementation Order Actually Works, and What Stalls?

Organizations that attempt zero trust as a single, comprehensive rollout tend to stall, since the scope quickly exceeds what any team can execute without disrupting normal operations. Organizations that succeed tend to sequence the work, starting with identity infrastructure before touching network segmentation.

That sequencing is not arbitrary. Identity is the hard dependency underneath every other component of the model. Microsegmentation without solid identity verification just creates smaller trusted zones rather than removing the underlying trust assumption. Continuous monitoring without reliable identity data produces noise rather than usable signal. Getting identity right first is what makes everything built on top of it actually function as intended.

IT Security Guru’s coverage of automated tools in SaaS penetration testing touches a related sequencing question from a different angle: the growing reliance on automation to keep pace with continuous verification demands, which is exactly the kind of tooling that becomes necessary once an organization’s zero trust model matures past the identity foundation stage.

Organizations that skip the identity-first ordering often end up with what looks like a zero trust deployment on paper but functions as a rebranded VLAN structure underneath, technically segmented but still relying on implicit trust once a user or device gets past the initial checkpoint.

Where Does the NIST Standard Actually Draw the Line?

Rather than relying on vendor definitions, it helps to work from the actual specification. NIST Special Publication 800-207 lays out the zero trust architecture in detail, defining the core logical components and the tenets that distinguish a genuine implementation from marketing language attached to conventional network security.

The standard makes it clear that zero trust is a set of principles guiding architecture decisions, not a single product or technology you can buy and deploy wholesale. That framing alone rules out a large share of what gets marketed under the term, since a genuine implementation touches identity management, policy enforcement, and monitoring together rather than any one of them in isolation.

How Can an Organization Tell Real Progress From a Rebranded VLAN?

A few honest checks separate genuine progress toward zero trust from a relabeled version of existing network security. Evaluate access decisions per request based on current context, not grant broad access once a user authenticates at the start of a session. Policy enforcement should apply consistently, whether a request originates inside or outside the traditional network boundary. Monitoring should also detect anomalous access patterns after the fact, not just block unauthorized access at the point of entry.

An organization that cannot clearly explain how it makes access decisions on a per-request basis is likely still operating on the old trust model, whatever the marketing materials on its security stack claim.

FAQ

What is zero trust, in the simplest accurate terms?

It is a security model that requires continuous verification of every access request, regardless of whether it originates inside or outside the traditional network perimeter, removing the assumption that internal network location implies trustworthiness.

Why does identity have to come before network segmentation in implementation?

Identity verification is the dependency the rest of the model relies on. Segmentation and monitoring without reliable identity data produce smaller trusted zones or noisy alerts, rather than genuinely removing implicit trust.

How can an organization tell if its zero trust deployment is genuine?

Access decisions should be evaluated per request based on current context, not granted broadly after initial login, and policy enforcement should apply consistently regardless of where a request originates.

Is zero trust a product an organization can simply buy?

No. NIST’s foundational specification describes it as a set of architectural principles, not a single purchasable technology. A genuine implementation brings together identity, policy enforcement, and monitoring rather than relying on any one component alone.

The post Zero Trust in Practice: Moving Beyond the Buzzword appeared first on IT Security Guru.