Fake Call History Apps Stole Payments From Users After 7.3 Million Play Store Downloads

Cybersecurity researchers have discovered fraudulent apps on the official Google Play Store for Android that falsely claimed to offer access to call histories for any phone number, only to trick users into joining a subscription that provided fake data and incurred financial loss.

The 28 apps have collectively racked up more than 7.3 million downloads, with one of them alone accounting for over 3 million downloads, before they were taken down from the official app storefront.The activity, codenamed CallPhantom by Slovakian cybersecurity company ESET, primarily targeted Android users in India and the broader Asia-Pacific region.

"The offending apps, which we named CallPhantom based on their false claims, purport to provide access to call histories, SMS records, and even WhatsApp call logs for any phone number," ESET security researcher Lukáš Štefanko said in a report shared with The Hacker News. "To unlock this supposed feature, users are asked to pay -- but all they get in return is randomly generated data."

The list of identified apps is below -

• Call history : any number deta (calldetaila.ndcallhisto.rytogetan.ynumber)
• Call History of Any Number (com.pixelxinnovation.manager)
• Call Details of Any Number (com.app.call.detail.history)
• Call History Any Number Detail (sc.call.ofany.mobiledetail)
• Call History Any Number Detail (com.cddhaduk.callerid.block.contact)
• Call History Of Any Number (com.basehistory.historydownloading)
• Call History of Any Numbers (com.call.of.any.number)
• Call History Of Any Number (com.rajni.callhistory)
• Call History Any Number Detail (com.callhistory.calldetails.callerids.callerhistory.callhostoryanynumber.getcall.history.callhistorymanager)
• Call History Any Number Detail (com.callinformative.instantcallhistory.callhistorybluethem.callinfo)
• Call History Any Number detail (com.call.detail.caller.history)
• Call History Any Number Detail (com.anycallinformation.datadetailswho.callinfo.numberfinder)
• Call History Any Number Detail (com.callhistory.callhistoryyourgf)
• Call History Any Number (com.calldetails.smshistory.callhistoryofanynumber)
• Call History Any Number Detail  (com.callhistory.anynumber.chapfvor.history)
• Call History of Any Number (com.callhistory.callhistoryany.call)
• Call History Any Number Detail (com.name.factor)
• Call History Of Any Number (com.getanynumberofcallhistory.callhistoryofanynumber.findcalldetailsofanynumber)
• Call History Of Any Number (com.chdev.callhistory)
• Phone Call History Tracker (com.phone.call.history.tracke)
• Call History- Any Number Deta (com.pdf.maker.pdfreader.pdfscanner)
• Call History Of Any Number (com.any.numbers.calls.history)
• Call History Any Number Detail (com.callapp.historyero)
• Call History - Any Number Data (all.callhistory.detail)
• Call History For Any Number (com.easyranktools.callhistoryforanynumber)
• Call History of Numbers (com.sbpinfotech.findlocationofanynumber)
• Call History of Any Number (callhistoryeditor.callhistory.numberdetails.calleridlocator)
• Call History Pro (com.all_historydownload.anynumber.callhistorybackup)

At least one of the flagged apps was published under the developer name "Indian gov.in" in an attempt to build a false sense of trust and unsuspecting trick users into downloading it.

However, this trick masks a nefarious motive where victims are asked to make a payment in order to view details of a phone number's call and SMS history. Once the payment is made, users are served entirely fabricated phone numbers and names directly embedded into the source code. Evidence indicates that the activity may have been active since at least November 2025.

A second cluster of these apps has been found to prompt users to enter their email address to which the purported details of any phone number would be delivered to. As in the prior case, no data is generated until a payment is made.

The payments either rely on subscriptions via Google Play Store's official billing system or via third-party apps that support Unified Payments Interface (UPI), an instant payment system widely used in India. Ironically, this list includes Google Pay, Walmart-backed PhonePe, and Paytm. A third method includes payment card checkout forms directly inside the apps. The last two approaches are in violation of Google's policy.

In at least one case, the apps implemented an additional trick to convince the user to make a payment. Should they exit the app without making any payment, it displays a deceptive notification claiming that a call history for a certain phone number had been successfully sent to their email address. Clicking on the notification directly takes the user to a subscription screen.

The subscription plans vary across the app, ranging anywhere from about $6 to $80. Users who may have fallen prey to the scam should have had their subscriptions canceled after the apps were removed from the Google Play Store.

What makes this activity notable is that the apps have a simple user interface and do not request any sensitive permissions. And to top it all, they do not even contain any functionality to retrieve call, SMS, or WhatsApp data.

"Users who subscribed via official Google Play billing may be eligible for refunds under Google's refund policies," ESET said. "Purchases made via third‑party payment apps or through direct payment card entry cannot be refunded by Google, leaving users dependent on external payment providers or developers."

The disclosure comes as Group-IB said bad actors have stolen an estimated $2 million from Indonesian users as part of a fraud campaign that involved posing as the country's tax platform, CoreTax, and other trusted brands. The campaign, which began in July 2025, has been linked to a financially motivated threat cluster called GoldFactory.

"The attack chain integrates phishing websites, social engineering (WhatsApp), malicious APK sideloading, and voice phishing (vishing) to achieve full device compromise and unauthorized transfer execution," Group-IB said.

At a high level, these attacks involve using social engineering to distribute the fake apps via WhatsApp, which, when installed, deploy Android malware such as Gigabud RAT, MMRat, and Taotie that are capable of harvesting sensitive data and downloading additional components. The stolen information is then used to conduct account takeover attacks and financial theft.

"The malware infrastructure supporting this fraud campaign is not limited to a single impersonated service. The same infrastructure has been observed actively abusing more than 16 trusted brands, collectively targeting Indonesia’s broader population of approximately 287 million," Group-IB said.

from The Hacker News https://ift.tt/ob3cxwH
via IFTTT

AI is moving fast. Your infrastructure needs to keep up.

Enterprise AI adoption has moved past the experimentation phase. Across industries, organizations are deploying AI in production — embedded in applications, surfaced through copilots, and woven into workflows that teams depend on every day. That’s real progress. But it’s also where a different kind of problem begins.

Because the more AI expands across the business, the harder it becomes to manage. Who has access to what models? How much is it actually costing? What happens when sensitive data ends up in a prompt that wasn’t supposed to be there? These aren’t hypothetical concerns — they’re the operational realities that organizations are running into as AI scales from a handful of pilots to something much larger.

And the numbers reflect this. According to Gartner’s AI services forecast, “In 2024, 60% of GenAI POCs were abandoned upon completion. In 2029, this will be reduced to 35%.” Not because the technology failed, but because the environment around it wasn’t ready. Weak governance, unpredictable costs, and a lack of visibility into how AI is actually being used — these are the factors quietly undermining initiatives that should be succeeding.

The good news is that these aren’t unsolvable problems. They’re infrastructure problems. And infrastructure is something we know how to fix.

The real challenge isn’t the AI — it’s the environment around it

Most organizations aren’t struggling to find AI tools worth using. The market for AI models, APIs, and services is deep and growing fast. The challenge is everything that surrounds those tools: how requests are routed, how policies are applied, how usage is tracked, how costs are controlled, and how security is enforced — consistently, across every team, application that touches AI, and model provider.

Without a consistent control layer, what tends to happen is a patchwork of protections and configurations. Different teams connect to different models in different ways. Sensitive data flows through prompts that no one is inspecting universally. Costs climb in unpredictable ways as usage spikes. Security and compliance teams ask questions that no one has good answers to. And as the footprint grows, so does the exposure.

This is the governance gap — and it’s the single biggest threat to the long-term success of enterprise AI.

AI governance starts at the infrastructure layer

The organizations that are scaling AI successfully share a common approach: they’ve established a centralized control layer for how AI traffic flows across their environment. Instead of managing each AI connection individually, they route all AI interactions through a single point of governance — one that can enforce policy, manage cost, protect sensitive data, and provide visibility, regardless of which model is being used or where it’s deployed.

That’s exactly the problem the Citrix NetScaler AI Gateway is built to solve.

NetScaler AI Gateway gives enterprises a single control point for monitoring, managing, and governing AI usage across the organization. It applies the same proven infrastructure principles that NetScaler has used to manage application traffic for decades — now extended to the AI layer. The result is an environment where AI can scale without the risk of sprawl: governed, observable, and cost-controlled from the start.

What that looks like in practice

From an operations standpoint, NetScaler AI Gateway simplifies how AI is integrated into applications and workflows. Consider something as common as switching between model providers or models — moving from one vendor’s offering to another, or swapping in a newer model as the landscape evolves. Without a centralized control layer, that change has to be managed across every application and team that touches AI. With AI Gateway, the switching happens behind a single, unified endpoint. Applications and end users stay connected without disruption, and your teams aren’t buried in integration rework every time the AI landscape shifts.

From a performance and efficiency standpoint, NetScaler AI Gateway optimizes how AI requests are handled. It routes requests intelligently based on performance, ensures workloads are distributed evenly, and provides automatic failover when a model or service becomes unavailable. The business outcome is straightforward: more consistent AI performance at scale, without requiring manual tuning or over-provisioning.

From a security and governance standpoint, NetScaler AI Gateway enforces access controls and inspects traffic for sensitive data before it reaches a model. Policies apply consistently, regardless of which application is making the request or which team owns it. This matters across the board — from healthcare and financial services workflows where regulated data is at stake, to something as ubiquitous as developer tooling. As coding assistants become a standard part of how engineering teams work, those tools need the same governance treatment as any other AI service. AI Gateway provides a secure, controlled access point for coding assistants, ensuring developers get the productivity benefits without the organization taking on unmanaged risk.

And from a cost standpoint, NetScaler AI Gateway gives organizations the visibility and controls they need to manage one of the more counterintuitive aspects of AI at scale: the fact that costs are driven by consumption patterns that are often invisible until it’s too late. By tracking token usage and enforcing limits, organizations can prevent runaway spend and allocate AI resources fairly across teams — without degrading performance for anyone.

AI should be a managed enterprise service — not a collection of unmanaged integrations

The organizations that will get the most out of AI over the long term are the ones treating it like any other enterprise-grade capability: with the appropriate infrastructure, governance, and controls in place from the start.

That’s not about slowing down AI adoption. It’s about making sure the investments you’re making today hold up as usage grows. Building AI on a governed, observable, controlled infrastructure foundation isn’t a constraint — it’s what makes scale possible.

NetScaler AI Gateway is built for exactly that moment: when AI is no longer an experiment, and your infrastructure needs to match the ambition.

Ready to see it in action? Watch our demo videos to see how AI Gateway governs AI traffic and controls cost in real enterprise environments.

from Citrix Blogs https://ift.tt/zotR9M6
via IFTTT

ShapeBlue Security Advisory: Security Fixes in CloudStack 4.20.3.0 and 4.22.0.1

The Apache CloudStack project has just announced the LTS release of Apache CloudStack 4.20.3.0 and 4.22.0.1 to address multiple security vulnerabilities affecting several CloudStack components and integrations.

These vulnerabilities include unauthorized access to backup resources, cross-tenant access issues, improper enforcement of resource limits, and security policy handling weaknesses in external integrations. Several of the reported issues may allow authenticated users to access or manipulate resources outside their intended scope.

The following CVEs are addressed in these releases:

• CVE-2025-66170 (severity ‘Low’)
• CVE-2025-66171 (severity ‘Important’)
• CVE-2025-66172 (severity ‘Important’)
• CVE-2025-66467 (severity ‘Important’)
• CVE-2025-69233 (severity ‘Moderate’)
• CVE-2026-25077 (severity ‘Important’)
• CVE-2026-25199 (severity ‘Moderate’)

 

 

CVE-2025-66170: Any user can list backups that they should not have access to

The CloudStack Backup plugin has an improper authorization logic in versions 4.21.0.0 and 4.22.0.0. Anyone with authenticated user-account access in CloudStack 4.21.0.0+ environments, where this plugin is enabled and have access to specific APIs can list backups from any account in the environment. This vulnerability does not allow them to see the contents of the backup.

Affected versions:

Apache CloudStack 4.21.0.0 through 4.22.0.0.

 

Resolution

Users are recommended to upgrade to version 4.22.0.1 or later, which addresses these issues.

 

CVE-2025-66171: Any user can create a new VM from backups they should not have access to

The CloudStack Backup plugin has an improper access logic in versions 4.21.0.0 and 4.22.0.0. Anyone with authenticated user-account access in CloudStack 4.21.0.0+ environments, where this plugin is enabled and have access to specific APIs can create new VMs using backups of any other user of the environment.
 

Affected versions:

Apache CloudStack 4.21.0.0 through 4.22.0.0

 

Resolution

Users are recommended to upgrade to version 4.22.0.1 or later, which addresses these issues.

 

 

CVE-2025-66172: Any user can attach a volume in their VMs from backups they should not have access to

The CloudStack Backup plugin has an improper access logic in versions 4.21.0.0 and 4.22.0.0. Anyone with authenticated user-account access in CloudStack 4.21.0.0+ environments, where this plugin is enabled and have access to specific APIs can restore a volume from any other user’s backups and attach the volume to their own VMs.

 

Affected versions:

• CVE-2025-66170:
  • Apache CloudStack 4.21.0.0 through 4.22.0.0

 

Resolution

Users are recommended to upgrade to version 4.22.0.1 or later, which addresses these issues.

 

 

CVE-2025-66467: MinIO policy remains intact on bucket deletion

Missing MinIO policy cleanup on bucket deletion via Apache CloudStack allows users to retain access to buckets which they previously owned. If another user creates a new bucket with the same name, the previous owners can gain unauthorized read and write access to it by using the previously generated access and secret keys.

 

Affected versions:

• Apache CloudStack 4.19.0.0 through 4.20.2.0
• Apache CloudStack 4.21.0.0 through 4.22.0.0

 

Resolution

Users are recommended to upgrade to version 4.20.3.0 or 4.22.0.1 or later, which addresses these issues.

 

 

CVE-2025-69233: Domain/account resource limits not honoured

Due to multiple time-of-check time-of-use race conditions in the resource count check and increment logic, as well as missing validations, users of the platform are able to exceed the allocation limits configured for their accounts/domains. This can be used by an attacker to degrade the infrastructure’s resources and lead to denial of service conditions.

 

Affected versions:

• Apache CloudStack 4.0.0 through 4.20.2.0
• Apache CloudStack 4.21.0.0 through 4.22.0.0

 

Resolution

Users are recommended to upgrade to version 4.20.3.0 or 4.22.0.1 or later, which addresses these issues.

 

 

CVE-2026-25077: Unauthenticated Command Injection in Direct Download Templates

Account users are allowed by default to register templates to be downloaded directly to the primary storage for deploying instances using the KVM hypervisor. Due to missing file name sanitization, an attacker can register malicious templates to execute arbitrary code on the KVM hosts. This can result in the compromise of resource integrity and confidentiality, data loss, denial of service, and availability of the KVM-based infrastructure managed by CloudStack.

Affected versions:

• Apache CloudStack 4.11.0 through 4.20.2.0
• Apache CloudStack 4.21.0.0 through 4.22.0.0

 

Resolution

Users are recommended to upgrade to version 4.20.3.0 or 4.22.0.1 or later, which addresses the issue.

 

 

CVE-2026-25199: Proxmox Extension Allows Unauthorised Cross-Tenant Instance Access

The Proxmox extension for CloudStack improperly uses a user-editable instance setting, proxmox_vmid, to associate CloudStack instances with Proxmox virtual machines. Because this value is not restricted or validated against tenant ownership and Proxmox VM IDs are predictable, a non-privileged attacker can modify the setting to reference a VM belonging to another account. This allows unauthorized cross-tenant access and enables full control over the targeted VM, including starting, stopping, and destroying the virtual machine.

 

Affected versions:

Apache CloudStack 4.21.0.0 through 4.22.0.0

 

Resolution

Users are recommended to upgrade to version 4.22.0.1 or later, which addresses these issues.

 

Official release notes can be found here: https://ift.tt/RbkpNG1

The post ShapeBlue Security Advisory: Security Fixes in CloudStack 4.20.3.0 and 4.22.0.1 appeared first on ShapeBlue.

from CloudStack Consultancy & CloudStack... https://ift.tt/Vy6PrF0
via IFTTT

The Good, the Bad and the Ugly in Cybersecurity – Week 19

The Good | Courts Sentence Karakurt Ransomware Negotiator & Two DPRK IT Worker Scheme Facilitators

Federal authorities have successfully secured a nearly nine-year prison sentence for Deniss Zolotarjovs, a Latvian national extradited to the U.S. for his critical role in the Karakurt extortion syndicate.

Operating as a specialized “cold case” negotiator, Zolotarjovs (aka Sforza_cesarini) systematically targeted victims who had previously stopped communications with the extortion group to avoid paying the ransom. To coerce the ransom payments, he focused on analyzing stolen personal data and information about the target companies to exert intense psychological pressure on the victims. In some cases, Zolotarjovs resorted to leveraging sensitive health information, including children’s medical records, to force the victim to complete the ransom payment.

Source: Dayton247now

The broader Karakurt operation has extorted an estimated $56 million from dozens of compromised organizations. As the first Karakurt member to face federal prosecution, Zolotarjovs’s sentencing is a hard-won milestone in ongoing efforts to dismantle international cyber-extortion rings.

In a separate victory, U.S. prosecutors sentenced two American nationals to 18 months in prison each for operating extensive laptop farms that actively facilitated North Korean cyber infiltration.

Matthew Knoot and Erick Prince were prosecuted for helping DPRK-based IT workers secure remote employment at almost 70 U.S. companies by exploiting stolen identities. The pair received company-issued laptops and deployed unauthorized remote desktop software, allowing the North Korean workers to seamlessly masquerade as legitimate domestic employees.

The FBI continues to warn about the thousands of North Korean IT workers working to infiltrate U.S. firms to steal intellectual property, implant malware, and siphon funds to the heavily sanctioned regime.

The Bad | PCPJack Worm Evicts TeamPCP, Steals Cloud Credentials at Scale

SentinelLABS researchers this week exposed PCPJack, a sophisticated credential theft framework and cloud worm that targets public infrastructure to harvest sensitive data.

Unlike other known cloud hacktools, the toolset actively hunts, evicts, and systematically deletes artifacts associated with TeamPCP, a threat group responsible for multiple high-profile supply chain intrusions earlier this year.

The multi-stage infection chain begins with a shell script called bootstrap.sh, which establishes persistence and selectively downloads specialized Python modules from an attacker-controlled Amazon S3 bucket. The malware extracts a massive array of sensitive credentials, including cloud access keys, Kubernetes service account tokens, Docker secrets, enterprise productivity application tokens, and cryptocurrency wallets. Unlike typical cloud-focused threat campaigns, PCPJack does not deploy cryptomining payloads on victims.

Beginning of bootstrap.sh, the dropper script

To achieve lateral movement, the framework exploits a number of web vulnerabilities, including severe Next.js and WordPress flaws, while aggressively scanning for poorly secured Docker, Redis, RayML, and MongoDB instances. Stolen data is then encrypted before being exfiltrated via attacker-controlled Telegram channels.

Security teams are advised to strictly enforce multi-factor authentication on service accounts, restrict Kubernetes access scopes, use an enterprise-wide vault, and thoroughly secure all exposed cloud management interfaces.

The Ugly | Palo Alto Warns of Critical Flaw in PAN-OS Enabling Remote Code Execution

Palo Alto Networks customers were issued an urgent warning this week regarding a critical-level, unpatched zero-day vulnerability currently being exploited in the wild.

Tracked as CVE-2026-0300, the buffer overflow flaw directly impacts the PAN-OS User-ID Authentication Portal (aka the Captive Portal), enabling unauthenticated attackers to execute arbitrary code with root privileges using specially-crafted packets.

With a CVSS score of 9.3, the vulnerability presents an immediate risk to enterprise networks. Threat watchdog Shadowserver has currently identified over 5,000 vulnerable firewalls exposed online, primarily concentrated across Asia and North America.

Source: ShadowServers (current as of this writing)

This actively exploited vulnerability adds to the growing pattern of targeting edge infrastructure. PAN-OS has a well-documented history of severe zero-days, and with 90% of Fortune 10 companies and many major U.S. banks depending on it, the exposure is significant. CISA has added the flaw to its Known Exploited Vulnerabilities (KEV) catalog, setting mandatory remediation deadlines for federal civilian agencies.

With a patch not expected until mid-May, Palo Alto is urging administrators to secure affected environments immediately, starting by confirming exposure via the device’s Authentication Portal Settings. To successfully mitigate the threat of remote code execution, security teams can restrict all User-ID Authentication Portal access exclusively to trusted internal IP addresses. If strict network segmentation is impossible, organizations are being advised to disable the Captive Portal service until updates can be safely applied.

from SentinelOne https://ift.tt/1xtPYiQ
via IFTTT

Quasar Linux RAT Steals Developer Credentials for Software Supply Chain Compromise

A previously undocumented Linux implant codenamed Quasar Linux RAT (QLNX) is targeting developers' systems to establish a silent foothold as well as facilitate a broad range of post-compromise functionality, such as credential harvesting, keylogging, file manipulation, clipboard monitoring, and network tunneling.

"QLNX targets developers and DevOps credentials across the software supply chain," Trend Micro researchers Aliakbar Zahravi and Ahmed Mohamed Ibrahim said in a technical analysis of the malware.

"Its credential harvester extracts secrets from high-value files such as .npmrc (npm tokens), .pypirc (PyPI credentials), .git-credentials, .aws/credentials, .kube/config, .docker/config.json, .vault-token, Terraform credentials, GitHub CLI tokens, and .env files. The compromise of these assets could allow the operator to push malicious packages to NPM or PyPI registries, access cloud infrastructure, or pivot through CI/CD pipelines."

The malware's ability to systematically harvest a wide range of credentials poses a severe risk to developer environments. A threat actor who successfully deploys QLNX against a package maintainer gains unauthorized access to their publishing pipeline, allowing the attacker to push poisoned versions that can lead to cascading downstream impacts.

QLNX executes filelessly from memory, masquerades itself as a kernel thread (e.g., kworker or ksoftirqd), and is capable of profiling the host to detect containerized environments, wiping system logs to cover up the tracks, and setting up persistence using no less than seven different methods, including systemd, crontab, and .bashrc shell injection. 

Furthermore, it exfiltrates the collected data to an attacker-controlled infrastructure, and receives commands that make it possible to execute shell commands, manage files, inject code into processes, take screenshots, log keystrokes, establish SOCKS proxies and TCP tunnels, run Beacon Object Files (BOFs), and even manage a peer-to-peer (P2P) mesh network.

Exactly how the malware is delivered is unclear. However, once a foothold is established, it enters a primary operational phase by running a persistent loop that continuously attempts to establish and maintain communication with the command-and-control (C2) server over raw TCP, HTTPS, and HTTP. In total, QLNX supports 58 distinct commands that give the operators complete control of the compromised host.

QLNX also comes with a Pluggable Authentication Module (PAM) inline-hook backdoor that intercepts plaintext credentials during authentication events, logs outbound SSH session data, and transmits the data to the C2 server. The malware also supports a second PAM-based credentials logger that's automatically loaded into every dynamically linked process to extract the service name, username, and authentication token. 

It employs a two-tiered rootkit architecture: a userland rootkit deployed through the Linux dynamic linker's LD_PRELOAD mechanism to ensure that the implant's artifacts and processes stay hidden. There also exists a kernel-level eBPF component that uses BPF subsystem to conceal processes, files, and network ports from standard userland tools such as ps, ls, and netstat upon receiving instructions from the C2 server.

"The QLNX implant was built for long-term stealth and credential theft," Trend Micro said. "What makes it particularly dangerous is not any single feature, but how its capabilities chain together into a coherent attack workflow: arrive, erase from disk, persist through six redundant mechanisms, hide at both userspace and kernel level, and then harvest the credentials that matter most."

from The Hacker News https://ift.tt/GAKpJud
via IFTTT

Security Onion and Linux Kernel Dirty Frag Vulnerability CVE-2026-43284

There is a new local privilege escalation called Dirty Frag (CVE-2026-43284):

https://access.redhat.com/security/cve/cve-2026-43284

Updated kernel packages should be coming soon to resolve this issue. If you can't wait until updated kernels are released and need to apply a temporary mitigation, please see the Mitigation section of the article above and also:

https://github.com/V4bel/dirtyfrag#mitigation

from Security Onion https://ift.tt/zsr7kYZ
via IFTTT

New Linux PamDOORa Backdoor Uses PAM Modules to Steal SSH Credentials

Cybersecurity researchers have disclosed details of a new Linux backdoor named PamDOORa that's being advertised on the Rehub Russian cybercrime forum for $1,600 by a threat actor called "darkworm."

The backdoor is designed as a Pluggable Authentication Module (PAM)-based post-exploitation toolkit that enables persistent SSH access by means of a magic password and specific TCP port combination. It's also capable of harvesting credentials from all legitimate users who authenticate through the compromised system.

"The tool, called PamDOORa, is a new PAM-based backdoor, designed to serve as a post-exploitation backdoor, enabling authentication to servers via OpenSSH," Flare.io researcher Assaf Morag said in a technical report. "Allegedly this would remain persistent on Linux systems (x86_64)."

PamDOORa is the second Linux backdoor targeting the PAM stack after Plague. PAM is a security framework in Unix/Linux operating systems that grants system administrators the ability to incorporate multiple authentication mechanisms or update them (e.g., switching from passwords to biometrics) into an existing system through the use of pluggable modules without the need for rewriting existing applications.

Because PAM modules typically run with root privileges, a compromised, misconfigured, or malicious module can introduce significant security risks and open the door to credential harvesting and unauthorized access.

"Despite its strengths, the Pluggable Authentication Module's (PAM) modularity introduces risks, as malicious modifications to PAM modules can create backdoors or steal user credentials, especially since PAM does not store passwords but transmits values in plaintext," Group-IB noted in September 2024.

"The pam_exec module, which allows the execution of external commands, can be exploited by attackers to gain unauthorized access or establish persistent control by injecting malicious scripts into PAM configuration files."

The Singaporean security vendor also detailed how it's possible to manipulate PAM configuration for SSH authentication to execute a script via pam_exec, effectively allowing a bad actor to obtain a privileged shell on a host and facilitate stealthy persistence.

The latest findings from Flare.io show that PamDOORa, besides enabling credential theft, incorporates anti-forensic capabilities to methodically tamper with authentication logs to erase traces of malicious activity.

Although there is no evidence that the malware has been put to use in real-world attacks, infection chains distributing the malware are likely to involve the adversary first obtaining root access to the host through some other means and deploying the PamDOORa PAM module to capture credentials and establish persistent access over SSH.

After an initial asking price of $1,600 on March 17, 2026, the "darkworm" persona has since reduced it by almost 50% to $900 as of April 9, indicating either a lack of buyer interest or an intent to accelerate a sale.

"PamDOORa represents an evolution over existing open-source PAM backdoors," Morag explained. "While the individual techniques (PAM hooks, credential capture, log tampering) are well-documented, the integration into a cohesive, modular implant with anti-debugging, network-aware triggers, and a builder pipeline places it closer to operator-grade tooling than the crude proof-of-concept scripts found in most public repositories."

from The Hacker News https://ift.tt/7zS5ZB1
via IFTTT

Ivanti EPMM CVE-2026-6973 RCE Under Active Exploitation Grants Admin-Level Access

Ivanti is warning that a new security flaw impacting Endpoint Manager Mobile (EPMM) has been explored in limited attacks in the wild.

The high-severity vulnerability, CVE-2026-6973 (CVSS score: 7.2), is a case of improper input validation affecting EPMM before versions 12.6.1.1, 12.7.0.1, and 12.8.0.1.

It allows "a remotely authenticated user with administrative access to achieve remote code execution," Ivanti said in an advisory released today.

"We are aware of a very limited number of customers exploited with CVE-2026-6973. Successful exploitation requires Admin authentication. If customers followed Ivanti's recommendation in January to rotate credentials if you were exploited with CVE-2026-1281 and CVE-2026-1340, then your risk of exploitation from CVE-2026-6973 is significantly reduced."

It's currently not known who is behind the exploitation efforts, if any of those attacks were successful, and what the end goals of the attacks were.

The development has prompted the U.S. Cybersecurity and Infrastructure Security Agency (CISA) to add the flaw to its Known Exploited Vulnerabilities (KEV) catalog, requiring Federal Civilian Executive Branch (FCEB) agencies to apply the fixes by May 10, 2026.

Also patched by Ivanti in EPMM are four other flaws -

• CVE-2026-5786 (CVSS score: 8.8) - An improper access control vulnerability that allows a remote authenticated attacker to gain administrative access.
• CVE-2026-5787 (CVSS score: 8.9) - An improper certificate validation vulnerability that allows a remote unauthenticated attacker to impersonate registered Sentry hosts and obtain valid CA-signed client certificates.
• CVE-2026-5788 (CVSS score: 7.0) - An improper access control vulnerability that allows a remote unauthenticated attacker to invoke arbitrary methods.
• CVE-2026-7821 (CVSS score: 7.4) - An improper certificate validation vulnerability that allows a remote unauthenticated attacker to enroll a device belonging to a restricted set of unenrolled devices, leading to information disclosure about the EPMM appliance and impacting the integrity of the newly enrolled device identity.

"The issues only affect the on-prem EPMM product, and are not present in Ivanti Neurons for MDM, Ivanti's cloud-based unified endpoint management solution, Ivanti EPM (a similarly named, but different product), Ivanti Sentry, or any other Ivanti products," the company said.

from The Hacker News https://ift.tt/zUFHVCv
via IFTTT

PCPJack Credential Stealer Exploits 5 CVEs to Spread Worm-Like Across Cloud Systems

Cybersecurity researchers have disclosed details of a new credential theft framework dubbed PCPJack that targets exposed cloud infrastructure and ousts any artifacts linked to TeamPCP from the environments.

"The toolset harvests credentials from cloud, container, developer, productivity, and financial services, then exfiltrates the data through attacker-controlled infrastructure while attempting to spread to additional hosts," SentinelOne security researcher Alex Delamotte said in a report published today.

PCPJack is specifically designed to target cloud services like Docker, Kubernetes, Redis, MongoDB, RayML, and vulnerable web applications, allowing the operators to spread in a worm-like fashion, aswell as move laterally within the compromised networks.

It's assessed that the end goal of the cloud attack campaign is to generate illicit revenue for the threat actors through credential theft, fraud, spam, extortion, or resale of stolen access. The 

What makes this activity notable is that it shares significant targeting overlaps with TeamPCP, a threat actor that rose to prominence late last year by exploiting known security vulnerabilities (e.g., React2Shell) and misconfigurations in cloud services to enlist the endpoints in an ever-expanding network for conducting data theft and other post-exploitation actions.

At the same time, PCPJack lacks a cryptocurrency mining component, unlike TeamPCP. While it's not known why this obvious monetization strategy was not adopted, the similarities between the two clusters indicate that PCPJack could be the work of a former member of TeamPCP who is familiar with the group's tradecraft.

The starting point of the attack is a bootstrap shell script that's used to prepare the environment – such as configuring the payload host – and download next-stage tooling, while simultaneously taking steps to infect its own infrastructure, terminate and remove processes or artifacts that are associated with TeamPCP, install Python, establish persistence, download six Python scripts, launch the orchestration script, and remove itself.

The six Python payloads are as follows -

• worm.py (written to disk as monitor.py), the main orchestrator that launches the purpose-built modules, conducts local credential theft, propagates the toolset to other hosts by exploiting known flaws (CVE-2025-55182, CVE-2025-29927, CVE-2026-1357, CVE-2025-9501, and CVE-2025-48703), and uses Telegram for command-and-control (C2)
• parser.py (utils.py), to handle credential extraction to categorize stolen keys and secrets
• lateral.py (_lat.py), to facilitate reconnaissance, harvest secrets, and enable lateral movement across SSH, Kubernetes, Docker, Redis, RayML, and MongoDB services
• crypto_util.py (_cu.py), to encrypt credentials before exfiltration to the attacker's Telegram channel
• cloud_ranges.py (_cr.py), to collect IP address ranges assigned to Amazon Web Services (AWS), Google Cloud, Microsoft Azure, Cloudflare, Cloudfront, and Fastly, and refresh the data every 24 hours
• cloud_scan.py (_csc.py), to run cloud port scanning for external propagation via Docker, Kubernetes, MongoDB, RayML, or Redis services

Propagation targets for the orchestrator script come from parquet files that the worm pulls directly from Common Crawl, a non-profit that crawls the web and provides its archives and datasets to the public at no extra cost.

"When exfiltrating system information and credentials, the PCPJack operator even collects success metrics on whether TeamPCP has been evicted from targeted environments in a 'PCP replaced' field sent to the C2," Delamotte said. This "implies a direct focus on the threat actor's activities rather than pure cloud attack opportunism."

Further analysis of the threat actor's infrastructure has uncovered another shell script ("check.sh") that detects the CPU architecture and fetches the appropriate Sliver binary. It also scans Instance Metadata Service (IMDS) endpoints, Kubernetes service accounts, and Docker instances for credentials associated with Anthropic, Digital Ocean, Discord, Google API, Grafana Cloud, HashiCorp Vault, OnePassword, and OpenAI, and transmits them to an external server.

"Overall, the two toolsets are well developed and indicate that the owner values making code as a modular framework, despite some redundancies in behavior," SentinelOne said. "This campaign does not [deploy miners], and it deliberately removes the miner functions associated with TeamPCP. Despite that, this actor has well-defined scopes for extracting cryptocurrency credentials."

from The Hacker News https://ift.tt/xrg4FQA
via IFTTT

World Passkey Day: Advancing passwordless authentication

World Passkey Day is a chance to reflect on progress toward a shared goal: reducing our reliance on passwords and other phishable authentication methods by accelerating passkey adoption. As cyberattacks become more automated and AI-powered, each account is only as secure as its weakest credential. Real progress requires more than adding stronger sign-in options—it requires removing phishable credentials and strengthening common attack paths like recovery flows. In partnership with the FIDO Alliance, Microsoft is committed to advancing passkey adoption through ongoing standards work, active participation in working groups, and other contributions to a passwordless future.

Explore Microsoft Entra identity and access solutions

Passwords remain a major source of risk; they’re difficult to manage and easy to steal. Along with weaker forms of multifactor authentication, they’re also highly vulnerable to phishing: AI-powered campaigns drive click-through rates as high as 54%.¹ In response, Microsoft is expanding passkey adoption across our ecosystem. We’re reducing reliance on legacy authentication and strengthening account recovery so it won’t become a backdoor for cyberattackers.

“Instead of vulnerable secrets or potentially identifiable personal information, a passkey uses a private key stored safely on the user’s device. It only works on the website or app for which the user created it, and only if that same user unlocks it with their biometrics or PIN. This means passkey users can’t be tricked into signing in to a malicious lookalike website, and a passkey is unusable unless the user is present and consenting. These are some qualities that make passkeys a ‘phishing-resistant’ form of authentication.”

From Microsoft Digital Defense Report.

Passkey adoption continues to grow industry wide

Passkey adoption is accelerating: FIDO Alliance estimates 5 billion passkeys already in use worldwide.² Across Microsoft’s consumer services, including OneDrive, Xbox, and Copilot, hundreds of millions of users sign in with passkeys every day.

There are many reasons to choose passkeys as the standard authentication method over passwords. Sign-in success rates are significantly higher than with passwords, and exposure to credential-based attacks is significantly lower.³ Organizations and individual users alike prefer the simpler, more secure sign-in experience passkeys offer.⁴

Inside Microsoft, we’ve eliminated weaker authentication methods and rolled out phishing-resistant authentication, covering 99.6% of users and devices in our environment.⁵ It’s made signing in a lot simpler: no codes to enter, no extra prompts to manage, just a straightforward experience for everyone.

Product updates across sign-in and recovery

Across Microsoft, we’ve been steadily building passkey support into every layer of the identity experience from consumer accounts to enterprise access with Microsoft Entra, and from device-based authentication like Windows Hello to Microsoft’s password manager. This work ensures people can create and use passkeys wherever they sign in, with a consistent, phishing-resistant experience across devices, apps, and environments.

To make passkeys more accessible, we’re expanding where and how people can use them:

• Synced passkeys and passkey profiles in Microsoft Entra ID make it easier to scale passwordless sign-in across diverse environments. We’re expanding flexibility in cloud passkey management, including support for larger and more complex policies, and transitioning tenants to a unified passkey profile model.
• Entra passkeys on Windows make it simple for users to create and use device-bound passkeys directly on personal or unmanaged Windows devices using Windows Hello, and will be generally available in late May 2026.
• Passkeys for Microsoft Entra External ID will be generally available late May 2026, so your customer-facing applications can offer a more seamless, consumer-grade sign-in experience.
• Passkey-preferred authentication in Microsoft Entra ID (preview) detects registered methods and prompts the strongest one first. If a passkey is registered, that’s what the user sees—immediately. 
• On the consumer side, with Microsoft Password Manager, users can now save and sync passkeys across devices signed in with their Microsoft account, with support for iOS and Android rolling out soon through Microsoft Edge. 

Account recovery also plays a critical role in maintaining the integrity of identity systems. Historically, it’s been vulnerable to cyberattackers who try to hijack the recovery process, for example by impersonating legitimate users and requesting new credentials.

Microsoft Entra ID account recovery, generally available today, strengthens security for recovery flows by enabling users to regain access to their accounts through a robust identity verification process. Users can regain access after losing all authentication methods by using government-issued ID and biometric face checks. At general availability, we are expanding our identity verification ecosystem with two new partners—1Kosmos and CLEAR1—joining our existing partners Au10tix, IDEMIA, and TrueCredential. 

Removing phishable credentials from user accounts

Strengthening authentication is important, but reducing risk means eliminating phishable credentials entirely. Microsoft is continuing to phase out legacy methods and move users toward phishing-resistant authentication. Starting in January 2027, security questions will be removed as a password reset option in Microsoft Entra ID due to their susceptibility to guessing and social engineering.

The rationale is straightforward: improving strong methods while removing weak ones shrinks the attack surface. This is increasingly urgent as AI agents act on behalf of users. If an identity is compromised, cyberattackers can leverage those agents to access systems, execute workflows, and operate within existing permissions. Organizations need to address this risk quickly.

A more secure and usable future

Last year, Microsoft joined dozens of organizations in taking the Passkey Pledge, a commitment to accelerating the adoption of phishing-resistant authentication and to moving beyond passwords. Since then, we’ve seen meaningful progress, from hundreds of millions of better-protected consumer accounts to large-scale deployments across organizations like our own.

What once felt like a long-term shift is finally gaining real momentum: authentication is becoming simpler, safer, and passwordless.

For a more in-depth perspective on how cyberattackers try to bypass authentication through fallback methods and recovery flows—and how to address those gaps—read our companion post.

Getting started

Organizations that want to strengthen their identity security posture can enable passkeys for their users and extend policy protections across both sign-in and recovery scenarios.

Get started with a phishing-resistant passwordless authentication deployment in Microsoft Entra ID.

Individuals can create and use passkeys for their personal accounts for better security and convenience.

Learn more about Microsoft Entra

To learn more about Microsoft Security solutions, visit our website. Bookmark the Security blog to keep up with our expert coverage on security matters. Also, follow us on LinkedIn (Microsoft Security) and X (@MSFTSecurity) for the latest news and updates on cybersecurity.

---

¹Microsoft Digital Defense Report 2025.

²FIDO Alliance reports mainstream global usage on World Passkey Day. FIDO Alliance, 2026.

³Synced passkeys and high assurance account recovery, Microsoft Entra blog. December 16, 2025.

⁴FIDO Alliance Champions Widespread Passkey Adoption and a Passwordless Future on World Passkey Day 2025, FIDO News Center. May 1, 2025.

⁵Microsoft Security and Future Initiative (SFI) Progress Report—November 2025.

The post World Passkey Day: Advancing passwordless authentication appeared first on Microsoft Security Blog.

from Microsoft Security Blog https://ift.tt/UdfpaRZ
via IFTTT

One Click, Total Shutdown: The "Patient Zero" Webinar on Killing Stealth Breaches

The hardest part of cybersecurity isn't the technology, it’s the people.

Every major breach you’ve read about lately usually starts the same way: one employee, one clever email, and one "Patient Zero" infection.

In 2026, hackers are using AI to make these "first clicks" nearly impossible to spot. If a single laptop gets compromised on your watch, do you have a plan to stop it from taking down the whole company?

What is "Patient Zero"?

In medicine, Patient Zero is the first person to carry a disease into a population. In cybersecurity, it’s the first device an attacker hits. Once they are "in," they don't stay there—they move fast to find your data, your passwords, and your backups.

What You Will Learn

Thisisn't a boring lecture. It is a technical deep dive into how modern breaches start and how to kill them instantly. We are covering:

• The AI Phish: How attackers use generative AI to bypass your current filters.
• The 5-Minute Window: Why the first few minutes of an infection determine if you'll be in the news tomorrow.
• Zero Trust in Action: How to isolate an infected device so the "virus" has nowhere to go.
• The Recovery Blueprint: What to do the second you realize you have a Patient Zero.

Why You Can’t Miss This

Most security tools are great at finding "known" viruses. But they struggle with stealthy, custom-made attacks designed specifically for your company.

This webinar shows you how to build a defense that assumes someone will click a bad link—and ensures that click doesn't cost you millions.

Secure Your Spot – Register Now ➜

Found this article interesting? This article is a contributed piece from one of our valued partners. Follow us on Google News, Twitter and LinkedIn to read more exclusive content we post.

from The Hacker News https://ift.tt/nCpV47W
via IFTTT

PAN-OS RCE Exploit Under Active Use Enabling Root Access and Espionage

Palo Alto Networks has disclosed that threat actors may have attempted to unsuccessfully exploit a recently disclosed critical security flaw as early as April 9, 2026.

The vulnerability in question is CVE-2026-0300 (CVSS score: 9.3/8.7), a buffer overflow vulnerability in the User-ID Authentication Portal service of Palo Alto Networks PAN-OS software that could allow an unauthenticated attacker to execute arbitrary code with root privileges by sending specially crafted packets.

While fixes are expected to be released starting May 13, 2026, customers are advised to secure access to the PAN-OS User-ID Authentication Portal by restricting access to trusted zones, or by disabling it entirely if it's not used.

In an advisory issued Wednesday, the network security company said it's aware of limited exploitation of the flaw. It's tracking the activity under the CL-STA-1132, a suspected state-sponsored threat cluster of unknown provenance.

"The attacker behind this activity exploited CVE-2026-0300 to achieve unauthenticated remote code execution (RCE) in PAN-OS software. Upon successful exploitation, the attacker was able to inject shellcode into an nginx worker process," Palo Alto Networks Unit 42 said.

The cybersecurity company said it has observed unsuccessful exploitation attempts against a PAN-OS device starting April 9, 2026, a week after which the attackers managed to successfully obtain remote code execution against the appliance and inject shellcode.

As soon as initial access was achieved, the threat actors took steps to clear crash kernel messages, delete nginx crash entries and nginx crash records, and remove crash core dump files in an attempt to cover up the tracks.

Post-exploitation activities conducted by the adversary included conducting Active Directory (AD) enumeration and dropping additional payloads like EarthWorm and ReverseSocks5 against a second device on April 29, 2026. Both tools have been previously used by various China-nexus hacking groups.

"Over the last five years, nation-state threat actors engaged in cyber espionage have increasingly focused their efforts on edge-network technological assets, including firewalls, routers, IoT devices, hypervisors and various VPN solutions, which provide high-privilege access while often lacking the robust logging and security agents found on standard endpoints," Unit 42 said.

"The reliance of the attackers behind CL-STA-1132 on open-source tooling, rather than proprietary malware, minimized signature-based detection and facilitated seamless environment integration. This technical choice, combined with a disciplined operational cadence of intermittent interactive sessions over a multi-week period, intentionally remained below the behavioral thresholds of most automated alerting systems."

from The Hacker News https://ift.tt/gV3W7su
via IFTTT

Why enterprise AI agents disappoint (and why the fix is not “better agents”)

The past few weeks have seen an explosion of talk about AI agents in the workplace, with everyone talking about how we’re moving past chatbots and rigid workflows towards true autonomous agents which do actual work. Google Next was all about agents, OpenAI announced workspace agents, Anthropic introduced enterprise controls for Cowork, and Microsoft dropped a slew of posts about agents in the enterprise. They’re all basically telling the same story: that autonomous AI is about to do your job, your team’s job, and your company’s entire back office operations.

Meanwhile in userland, most knowledge workers are still just using AI as a fancy answer engine.

When I talk to customers, it seems all I hear about are stalled pilots, Copilot deployments that don’t meet expectations, and feelings that agent demos from conferences don’t translate to anything close to what a company could actually run in production. (I love this 18-minute segment from The Artificial Intelligence Show podcast on this topic.)

The problem isn’t about agents, per se. It’s that most people view agents as the ultimate goal of AI, and now that agents are becoming real(ish), people want to jump right to them even though they haven’t taken the intermediate steps to get there.

I’ve written over and over that agents need to be viewed like human workers, rather than software tools. After all, in order to be successful, agents need the same things as humans: context, guidance on judgement, understanding of the established way of working, etc. (Deploying an agent without this is like handing a new hire a laptop & login and saying, “Now go do my job.”) AI agents without this fail for the same reasons a human would.

Crawl … Run! (Wait, did we skip “walk”?)

You know that phrase, “crawl, walk, run.” It can apply to AI in the enterprise too. Crawl is using AI via a chat interface. (Where most are today). Run is having AI agents do useful work throughout the company. (What everyone is talking about now.) So what happened to walking?

Walking is where you teach AI how you actually work, what context matters, and what good looks like. It’s where you build skills, capture how decisions get made, and give AI memory that persists between sessions. (I laid the full version of this progression in my 7-stage roadmap for human-AI collaboration. Each stage builds on the one before it, and you can’t skip steps.)

You can’t skip steps!!

What does walking look like?

I use the cognitive stack to illustrate how AI is entering the knowledge workplace. Worker interaction with AI is at the top. Context, skills, and judgment are in the middle. Agents are at the bottom.

Everyone understands the top part, since human workers telling AI what they want to do is how most of us have been using AI for years. And everyone understands the bottom part (even if only in fantasy) where AI agents go into the real world and do real work. But how do you connect those two together? That’s the walking part.

I argue that the reason people are having challenges with agents in the workplace is because they’re skipping from crawl to run. In other words, they tell AI what they want (crawl), and they’ve empowered AI with logins and agency and tools (run), but they haven’t given AI the skills or context (walk).

At this point you’re probably thinking that I’ll spend the rest of this post explaining why the walking step is important. But no! I mean, yes, walking is important. But also:

Even after you learn how to run, you still mostly walk everywhere

Just because can see a “run” future where AI agents do all sorts of real work, remember that most people spend more time crawling and walking than they do running. Sure, running is fastest, but it’s also tiring, you get sweaty, and it’s easier to fall.

Successfully leveraging AI in the enterprise is going to be about applying the right approach to each task. Let’s say you need to analyze some data. (A spreadsheet, customer list… whatever.) You can do that analysis at any layer of the stack. So which layer do you choose? (Remembering that each layer down costs more than the one above it while also requiring the layers above it.)

The easiest and simplest (crawl) is you just do it yourself. You open Excel, paste in the data, and write some formulas. There’s no AI involved. It’s cheap (no tokens), fast, and reliable because you’re the one doing it.

One layer deeper, you paste the data into your LLM and have AI reason over it in the context window. Maybe that costs 1,000 tokens. The more context you give the AI, the better chance you have of getting the results you want.

Deeper still, you can use a skill, (maybe a Python script you built once and reuse). The cost per run isn’t going to be any more than in-context reasoning, though this one has a dependency: the skill had to be built with context and judgment, and it has to be maintained. And it required the layers above it.

Finally, you could go all the way down to “run” and have a computer using agent do it, where AI operates Excel like a human would, pasting in the data, clicking cells, writing formulas, and doing the whole thing autonomously. It might cost 200,000 tokens, it’s slower, and it’s more likely to make mistakes. (But hey, you’re “running” with an agent!) But using an agent here only works if it has the context, skills, and judgment from the layers above to know what “good” looks like. Without those layers, you’ll spend 200,000 tokens to do something the layers above could’ve done for 1,000, or for free by just opening Excel yourself.

Don’t focus on agents before you’ve solidified the layers in between

Yes, agents can be a destination. Eventually. But you need to do the work on the middle layers first. I’ve written about that work from several angles: the second brain approach of capturing how you actually work and think, using skills to teach AI to do recurring work, and making the invisible 80% of your work visible.

Once you’ve built out all the layers of your cognitive stack, agents stop being the only destination, instead becoming just one of many approaches in your AI arsenal, (alongside in-context reasoning, skills, and just doing things yourself). The future of AI in the enterprise isn’t about racing to deploy agents. It’s balancing the right effort, the right tool, and the right type of token for each task.

The companies who figure this out will “run” circles around the ones racing straight to agents. They’ll spend a fraction of the tokens, deliver higher quality work, and reach for an agents only when actually warranted. The ones racing straight to agents will burn tokens, dollars, and effort wondering why their pilots stalled.

Crawl before you walk. Walk before you run. Run fast when you need to, but never forget how to walk and crawl.

---

Read more & connect

Join the conversation and discuss this post on LinkedIn. You can find all my posts on my author page (or via RSS).

from Citrix Blogs https://ift.tt/M9FdVhR
via IFTTT

Comparing Different Approaches to Sandboxing

“AI agents will become the primary way we interact with computers in the future. They will be able to understand our needs and preferences, and proactively help us with tasks and decision making.“

Satya Nadella

CEO of Microsoft

Whether you are a software engineer, a product manager, or a designer, this quote should fundamentally change how we approach our daily routine. We are no longer just building interfaces; we are creating environments where agents can operate autonomously with minimal human interaction. What could be the fundamental requirement for such an environment ?

In a single word: Isolation.

A user interacting with traditional software is constrained by the actions it allows. But Agents are non-deterministic, and therefore prone to hallucination and prompt injections. Once you give an AI write access to your systems, there is nothing stopping it from executing a rm -rf to delete all your data. Of course, there are different ways to solve this problem, with one approach being sandboxing: an isolated, controlled environment used for experimentation and testing without affecting the surrounding system.

So, I started exploring different strategies to sandbox the agents. Starting with a bare minimum setup and going all the way to setting up a cloud VM. Here is what I learned at each step.

1. Let’s Start with the Baseline

Chroot has been the traditional way to achieve file system isolation. It works well when you want the process to think that a specific, restricted directory is the absolute root of the machine.

However, there are two major caveats.

1. If the process inside the chroot has root privileges, it could break out.
2. While it offers file isolation, process isolation is still a problem. A malicious agent can still see other processes running on your system and try to kill them.

As you can see above, doing an ls /proc still shows all the processes running on the host.

This is when I learnt about systemd-nspawn, also called “chroot on steroids”. The difference between chroot and systemd-spawn is that the latter provides isolation at the network and process levels in addition to the file system.

Now, when I do the same ls /proc in the systemd-nspawn mybox container, I just see the processes in the mybox container achieving process-level isolation.

Pros

1. Lightweight compared to other container processes like Docker, it offers faster startup times.
2. Native support in Linux.

Caveats

1. systemd-nspawn is not very popular in the developer community unless you are deep into Linux.
2. While this works for Linux, what if you need to run your agents on Windows? You will have to find alternatives depending on the platform.

2. Are Containers Enough?

Another technology that comes to mind when thinking about isolated environments is Docker. And unlike the previous concepts we discussed, Docker has a broader ecosystem and a strong community.

With containers, you also get isolated file systems, network interfaces, and process trees. They also come with cross-platform support across Mac, Windows, and Linux. With all these advantages, creating and running agents across different platforms becomes very easy, which makes containers an obvious choice.

However, the model becomes more complex when containers become a dev platform for agents. More often than not, agents need to execute generated code in separate environments, which in practice means spinning up new Docker containers on demand. This introduces a container-in-container pattern (Docker-in-Docker), where an agent running inside a container needs to build and run other containers. 

To make Docker-in-Docker to work, we would have to run the container in privileged mode (--privileged), which gives the container processes elevated permissions rights and dramatically weakens the isolation. At this point, the isolation guarantees are significantly diminished. As a result, complete isolation for agents using only containers becomes tricky.

3. Do Virtual Machines Help?

As you might have already predicted, Virtual Machines (VMs) offer the strongest isolation. With a VM, you can get an entire OS, file system, and network of your own. For example, I currently run MacOS with lima – Linux VM to run Linux-specific workloads.

However, the tradeoff is that spinning up a VM is expensive. And if this needs to be done for every agent, it is not scalable. Some stats that show how expensive spinning up a VM with system-nspawn looks like.

Approach	Per Agent Cost	Boot Time	10 Agents
VM (Lima)	~4GB RAM + 4 CPU	30-60s	~40GB RAM
systemd-nspawn	~10MB RAM	< 1s	~100MB RAM
chroot	1MB RAM	instant	~10MB RAM

For example, in the below screenshot you can see the cost it takes to run a lima vm.

4. MicroVMs to the rescue

A MicroVM (Micro Virtual Machines) felt like the perfect answer to the isolation story. So what is MicroVM, and what makes it better?

MicroVM is a lightweight virtualisation technology that provides the strong security and isolation of a traditional VM, along with the speed of a container.

1. Strong security and isolation are enabled because a MicroVM gets its own kernel, aka the Guest Kernel, unlike containers, which use a shared kernel. Because of this, any compromise inside the Guest OS does not directly affect the host or the other VMs.
2. Speed: unlike traditional VMs, it is provisioned with minimal hardware (no USB or PCI buses) and bypasses BIOS/UEFI boot, significantly reducing device emulation overhead and startup latency.

Amazon open-sourced Firecracker in 2018, which was the earliest adoption of the MicroVM architecture. While this helped catalyze the MicroVM architecture, Firecracker was restricted to Linux environments. And most of the agentic orchestration tends to happen on developers’ laptops which run MacOS and Windows as well.

Docker addressed this gap with its Sandbox offering. The best part is their MicroVM-based architecture, which runs natively across macOS, Windows, and Linux, delivering better isolation, faster startup times, and a smoother developer experience. We will learn about this in a bit.

5. gVisor

gVisor takes a unique approach to solving the isolation problem. While the previous strategies used the OS Kernel, gVisor creates its own Kernel called the “application kernel” running in the user space.

When a standard containerized app wants to do something like open a file, allocate memory, or send network traffic, it makes a “system call” (syscall) directly to the host’s Linux kernel.

With gVisor, your app is bundled with a component called the Sentry.

1. The Sentry intercepts every single syscall your application makes.
2. It processes that request in user-space using its own implementation of Linux networking, file systems, and memory management.
3. If the Sentry absolutely needs the host kernel to do something (like actual disk I/O), it translates the request into an extremely restricted, heavily filtered, safe call to the host.

However, it suffers from the same problem as systemd-nspawn. Not much broader community supports and only supports Linux.

Docker Sandbox

With Docker Sandboxes, AI coding agents run in isolated microVM environments. The performance is as seamless as it can be, identical to running on the host, but with significantly stronger isolation and security. This means you can run your autonomous agents without worrying about host compromise or unintended access to your local environment. 

Sandbox achieves this levels of security through three layers of isolation:

Hypervisor Isolation: Every Sandbox has its own Linux Kernel. So, anything that affects the sandbox kernel will not affect the host or other sandbox kernels.

Network Isolation

• Each Sandbox has its own isolated network. Meaning multiple sandboxes cannot communicate with each other or with the host.
• In addition, network policies can be enforced to allow or disallow traffic from a source.

Docker Engine Isolation

• This is what made me fall in love with this new architecture. Every Sandbox gets its own Docker Engine. As a result, whenever the agent runs docker pull or docker compose, those commands are executed against the internal engine rather than the external Docker daemon.
  
• Because of this, agents running inside can only see Docker services within their sandbox and nothing else, adding an additional layer of security.

Attribute	Traditional VM	Container	Docker MicroVM
Isolation	Strong (dedicated kernel)	Weak (shared kernel)	Strong (dedicated kernel)
Boot time	Minutes	Milliseconds	Seconds (after the first image pull)
Attack Surface	Large	Medium	Minimal

To demonstrate Docker Engine isolation, I created two Sandbox sessions, ran the Docker hello-world container image in one, and then ran docker ps -a in both.

​As you can see from the screenshot below, one session has the hello-world container and the other does not. This is possible because both of them are running two different Docker engine daemons.

More on the Sandbox architecture here: https://www.docker.com/blog/why-microvms-the-architecture-behind-docker-sandboxes/

Conclusion

If there is one takeaway; it’s this: isolation plays a major role when building autonomous AI agents because the blast radius of a security mistake is significant. 

Each approach we explored till now solves a different piece of the isolation puzzle. Containers improve portability and developer experience, but inherit the risks of a shared kernel. Virtual Machines deliver strong isolation, but the overhead doesn’t scale when you’re spinning up dozens of agents. gVisor sits in an interesting middle ground, though compatibility and community trade offs might slow you down.

Among all these, what makes Docker Sandbox with MicroVMs compelling is how it unifies these dimensions: VM-level security, container-like startup speed, and a workflow developers already know. Per-sandbox Docker Engines and strict network boundaries make it a strong foundation for running untrusted, autonomous workloads at scale.

So, what are you waiting for? Go ahead and try it out today.

For macOS: brew install docker/tap/sbx

For Windows: winget install Docker.sbx

from Docker https://ift.tt/EWX0PmM
via IFTTT