JEDI-SEC | Security Research & Digital Defense

Tag: Threat Advisory

  • ARTEX and beyond: AI-enabled penetration testing platforms

    Cisco Talos is tracking the growing in-the-wild usage of AI-enabled penetration testing frameworks. AI-enabled penetration testing and red team frameworks can automate and chain reconnaissance, vulnerability testing, and follow-on actions, lowering the skill threshold for attackers and accelerating intrusions when the tools are misused. Talos has seen full automation of the attack chain by these frameworks, which not only use free and open-source tools, like nmap and nuclei, but also take advantage of internet mapping services like Censys and Shodan, CAPTCHA bypass services, credential leak management services, residential proxies, and even hash cracking services. This is the case of Hephaestus, which we mentioned in our previous report.

    Although these frameworks all have the same purpose, they come in different flavors. Some, like Hephaestus, are command line tools which can be deployed with a single script on a VPS and are completely controllable via Telegram.

    PentAGI has a web interface to monitor the agent activity with a full attack chain graph design and monitoring. Talos found more than 700 instances of currently reachable PentAGI instances on the internet. HexStrike AI integrates with many different clients like Claude Code, VS Code, or any other client that supports MCP.

    One such framework making waves, ARTEX, has enabled threat actors to scale offensive operations, compressing work that may have previously taken skilled teams hours or days into activity that can unfold at machine speed.

    Talos’ analysis of ARTEX-associated IP addresses identified a diverse set of tools concurrently present on that infrastructure, reinforcing ARTEX’s role in a broader and varied threat environment.

    AI-enabled frameworks: A new reality

    Before we delve into ARTEX, it is clear that these frameworks are the new reality. Their evolution will most likely include autonomous lateral movement followed by data identification and exfiltration. The precursor of this can already be seen in the victim prioritization of the Volta Infostealer, described in detail in this Talos report. It is highly likely that future attack chains involving these frameworks will culminate in data exfiltration and ransomware activation, all being done autonomously by one of these frameworks.

    Such evolutions present new challenges to defenders:

    • It reduces the time it takes to detect a compromise without any known indicators of compromise (IOCs). We provide guidance to help overcome this challenge in the Recommendations section.
    • After malicious activity is identified, it is crucial to contain the incidents. These frameworks work at speeds that can make it impossible for human operators to identify, assess and react in time to disrupt the attack.

    These frameworks make mitigation and containment, along with a battle-tested cybersecurity incident response plan, imperative for organizations’ resiliency. Defenders using AI can be a force multiplier to provide much-needed improvements, both in the speed and scale of response to such attacks.

    ARTEX

    ARTEX is an AI-enabled penetration testing framework developed under the pseudonym Autumn-27 and published on GitHub in July 2026. An operator gives it a target and objective, a planner agent breaks the objective into tasks, worker agents perform them using security tools, and the framework records assets, findings, and progress in a shared graph. ARTEX can use different large language models (LLMs) and requires relatively little operator input after a task begins. It was designed for authorized security testing, but recent public reporting documented its use in both criminal and targeted intrusion campaigns within weeks of its release.

    It is important to note that ARTEX is not natively bundled with any traditional command-and-control (C2) framework, though the Model Context Protocol (MCP) extensibility layer means any compatible tool server can be added by an operator. This explains why we have observed multiple instances of ARTEX being deployed alongside tools such as VShell, GoPhish, and AdaptixC2.

    Threat actors leveraging ARTEX in offensive campaigns

    Multiple threat actors with distinct motives and tradecraft have been associated with ARTEX activity; its release as open-source software, followed by the continued availability of forks and copies, almost certainly facilitated adoption across different actor groups. Public reporting (referenced below) and Talos observations indicate ARTEX is largely used by financially motivated cybercriminals and threat actors with a China nexus.

    Observed ARTEX campaigns range from opportunistic scanning and credential theft to targeted intrusions and supply chain activity, with targets spanning financial services, cryptocurrency, government, telecommunications, defense, pharmaceuticals, semiconductors, and technology organizations across multiple regions. Reported outcomes vary from unsuccessful attempts to confirmed compromise and data exfiltration.

    Reported campaigns:

    • VAPOR PANDA: CrowdStrike attributed an espionage campaign (beginning Oct. 17, 2026) leveraging ARTEX to China-nexus actor VAPOR PANDA. The actor used ARTEX against more than 200 organizations in at least 14 countries, with targets that included government ministries, telecommunications providers, and organizations in the defense, pharmaceutical, semiconductor, nuclear, and financial sectors. CrowdStrike confirmed post-compromise activity at nine organizations and reported additional credential-scanning and password-spraying activity against at least 12 others.
    • Storm-0940: Microsoft attributed ARTEX-driven activity to Storm-0940, who they assess is a “China-state aligned actor”. Following the compromise of ConnectWise application credentials, Storm-0940 used ARTEX to accelerate sign-in attempts against more than 2,250 downstream Microsoft 365 tenants, with follow-on activity involving Microsoft Graph, application credentials, and privilege changes.
    • Storm-3358: Microsoft also reported financially motivated Storm-3358 activity targeting financial organizations, primarily in Southeast Asia, and describes the cluster as Cambodia-based. Its ARTEX activity included exploitation of public-facing systems and deployment of remote access trojans (RATs). Cisco’s observations for this cluster are in line with Microsoft’s findings. We found IP addresses associated with this cluster conducted asset scanning in October 2026.
    • Unidentified Chinese-speaking threat group: CrowdStrike reported an unattributed campaign against South Korean financial organizations that resulted in data exfiltration; it assessed with moderate confidence that the actor was Chinese-speaking and financially motivated. Talos separately analyzed actor-associated directories used in these attacks and found ARTEX-related artifacts, including directory listings and prompt history references. The archive did not contain the ARTEX executable or source tree, so these artifacts support an association with an ARTEX environment but do not, by themselves, prove that the complete framework was present or used in a successful attack.
    • Unidentified criminal threat actors: Check Point Research documented additional criminal operators pursuing goals that included stealing code-signing certificates and gaming-account credentials and attempting cryptocurrency theft.
    • Unattributed ARTEX-associated activity: Microsoft reported agents using ARTEX to search public GitHub repositories for exposed credentials, including application credentials and AI service API keys, and then use discovered secrets for follow-on activity. In one case, the agent moved from searching GitHub to exfiltrating data from Azure Key Vault within five minutes. Datadog separately observed ARTEX activity in AWS environments involving compromised long-term access keys and public Cognito user pools. The activity included searching cloud logs for financial information and secrets, registering accounts, collecting tokens, and attempting cloud resource enumeration. Datadog did not attribute these observations to a named actor. Finally, Dosu disclosed a separate ARTEX-related incident in which an attacker progressed from account creation and an authorization flaw to access involving integrations, CI, a database, and cloud systems. Dosu reported that the attacker generated more than 80,000 requests in 90 minutes.

    Observed tactics, techniques, and procedures

    Across campaigns, ARTEX has served as an orchestration layer for rapid, parallel reconnaissance and intrusion activity, enabling actors to turn exposed credentials or application weaknesses into broader access, persistence, and data theft. Operators typically set the objective and provided limited direction, while agents adapted their approach to the target. The resulting behaviors vary by campaign and should not be treated as a single fixed playbook.

    Planning and reconnaissance: ARTEX operators provide objectives and may assign tasks across multiple targets; its planner and worker agents can then conduct activities in parallel and record results for subsequent tasks. Check Point’s review of operator consoles found that agents often worked with little interaction after the initial goals were set, while VAPOR PANDA was seen steering agents at selected decision points. Reported reconnaissance includes scanning public-facing applications and services, testing authentication flows, enumerating cloud resources, and searching public code repositories for exposed secrets. ARTEX activity may generate varied requests and rapid retries, but tool signatures and user agents can change and should be treated as supporting indicators rather than definitive attribution.

    Initial access and exploitation: Reported initial access methods in ARTEX campaigns include password spraying, exposed or stolen credentials, and exploitation of application and authorization flaws. Observed weaknesses that were exploited in these attacks include weak or hardcoded administrative credentials, missing API authentication, insecure direct object references, command injection or template injection vulnerabilities, anonymous file upload and server-side request forgery weaknesses, and lack of defenses against privilege escalation. These observed tactics support that ARTEX can automate the discovery and use of weaknesses in web applications and identity systems, but the specific techniques depend on the target and campaign.

    Credential access and cloud abuse: Several ARTEX attacks leveraged the discovery or misuse of credentials as a bridge from an initial foothold to cloud resources and downstream systems. For example, agents were observed searching public GitHub repositories for credentials and API keys, then using exposed secrets for follow-on activity, including access to Azure Key Vault. Another campaign included AWS activity involving anonymous S3 requests, compromised long-term access keys, CloudWatch log searches, and public Cognito user pools. In the Cognito activity, agents registered accounts, collected tokens, and attempted AWS resource enumeration. Microsoft’s Storm-0940 reporting describes compromised application credentials being used to access downstream Microsoft 365 tenants and conduct follow-on activity through Microsoft Graph.

    Privilege escalation, persistence, and lateral movement: Observed follow-on behaviors include changes to application permissions, token or credential abuse, access to privileged accounts, and deployment of web shells or RATs. CrowdStrike describes VAPOR PANDA using historical authentication material to forge an administrator token, read mailboxes, and reach an internal network using recovered VPN information. It also reports endpoint-security discovery, web-shell deployment, and use of the BLOODALCHEMY backdoor in other parts of the campaign. Microsoft reports Storm-3358 deploying WISP, VShell, and AdaptixC2 for persistence and lateral movement. Of note, these actions are actor-specific examples rather than default ARTEX behavior.

    Collection, exfiltration, and impact: As detailed in the above campaigns, threat actor objectives include credential and data theft, financial gain, and supply chain compromise. Observed impacts range from access to cloud secrets and mailbox data to the use of compromised applications to reach connected environments.

    Concurrent tooling observed on ARTEX-associated infrastructure  

    ARTEX is an agentic penetration testing platform that can direct and coordinate other security tools as part of its workflows. Talos identified more than 2,500 ARTEX-associated C2 IP addresses, then analyzed the tools observed on those systems and compared their observation periods with ARTEX. The tools below are ordered from most to least frequently observed during overlapping periods. Although co-occurrence does not confirm with certainty that ARTEX invoked each tool or that all were operated by the same actor, this list can help prioritize defenses against potential ARTEX-associated activity.

    • ScopeWeaver: A localized derivative of ARTEX, rebranded and translated into English and Korean
    • AntiFox: Delivery-enhanced version of ARTEX, reproduction captured in place and provides easy-to-know kill chain findings
    • CyberStrikeAI: An AI-based security testing platform that coordinates agents and external tools for automated assessments
    • PentAGI: An open-source, self-hosted platform that uses multiple AI agents to plan and conduct penetration tests in an isolated environment
    • ScopeSentry: An asset discovery and vulnerability scanning platform developed by the same pseudonymous author as ARTEX
    • VShell: A cross-platform C2 framework primarily used for post-exploitation activities and often compared to Cobalt Strike, given overlapping offensive capabilities
    • Nessus: Tenable’s vulnerability assessment scanner, used to identify vulnerabilities and configuration issues across systems and networks
    • Interactsh: ProjectDiscovery’s open-source tool for detecting out-of-band interactions that can reveal vulnerabilities triggered by external callbacks
    • Acunetix: An automated web application security scanner that crawls websites and tests for vulnerabilities
    • Fscan: An open-source internal network security scanner
    • Net Proxy Server (NPS): An open-source proxy and tunneling server designed to provide access to services behind a network boundary
    • AdaptixC2: An extensible C2 and post-exploitation framework intended for authorized red team assessments
    • Mimikatz: An open-source post-exploitation tool used to extract plaintext passwords, hashes, PIN codes, and Kerberos tickets from Windows memory
    • Cobalt Strike: Fortra’s commercial adversary-simulation and red team platform, which includes capabilities for post-exploitation activity
    • Gophish: An open-source platform for conducting and tracking phishing simulations
    • Chisel: An open-source TCP/UDP tunneling tool that transports connections over HTTP and secures them with SSH; it can also relay traffic through proxy or reverse-tunnel configurations

    Recommendations 

    For frameworks that pursue operator-defined objectives through adaptable workflows and supporting tools, associated activity can vary by target and operator. Defenders should focus on fundamentals that limit the speed and scale of attacks, reduce exposure, protect credentials and cloud identities, and quickly detect suspicious activity.

    • Monitor for rapid, unusual activity: Correlate authentication, cloud API, and endpoint logs to detect high-volume requests, unfamiliar applications, token use, and privilege changes.
    • Harden public-facing systems: Patch promptly, remove default credentials, and test authentication and authorization controls.
    • Defend against credential attacks: Require multi-factor authentication (MFA) for remote and privileged access; apply rate limits and alert on password-spraying patterns.
    • Harden endpoint detection: Enable endpoint detection and response (EDR) tamper protection and sensor health monitoring, alert on service or configuration changes, and retain independent telemetry to investigate attempted defense evasion, as ARTEX has demonstrated EDR bypass capabilities.
    • Protect exposed secrets: Scan public code repositories for credentials and API keys; revoke and rotate any exposed secrets immediately.
    • Limit identity and application privileges: Apply least privilege to service accounts and applications, restrict user consent, and review permission or role changes.
    • Secure cloud resources: Disable unnecessary public or anonymous access and review storage, identity, and secrets services for exposure.
    • Detect post-compromise activity swiftly: Maintain endpoint and network detections for web shells, remote access tools, C2 traffic, and lateral movement; treat tool signatures as leads, not the sole detection method.
    • Prepare for fast containment: Have procedures ready to revoke credentials and tokens, disable suspicious applications, and isolate affected systems.

    Coverage 

    ARTEX is an orchestration framework that malicious actors can use to leverage extant offensive tools at scale and speed. Talos provides coverage for many of the most commonly observed tools we’ve seen deployed, including older ones such as Mimikatz, Cobalt Strike, and Acunetix. While an exhaustive list of coverage for these tools would be impractical given the length, please refer to this sample list of Snort and ClamAV coverage, which demonstrates some of the ways we would detect dual-use tooling associated with ARTEX. Talos will continue to monitor ARTEX-enabled attacks for novel tool deployment.

    ARTEX

    Snort 3: 7:78, 7:77, 7:76

    Snort 2: 1:67496, 1:67495, 1:67494

    Note: 7:78 and 1:67496 are released as POLICY rules (disabled by default). These rules detect artifacts related to norma, the agentic harness framework being used in Artex. Customers can turn these on only if they intend to detect norma.

    AdaptixC2

    Snort

    • 301461-301462, 66200

    ClamAV

    • Multios.Trojan.AdaptixC2-10058665-0
    • Win.Malware.Adaptixc-10058672-0
    • Win.Trojan.AdaptixC2-10058663-0

    VShell

    Snort

    • 64601-64609
    • 301149-301151

    ClamAV

    • Unix.Downloader.VShell-10059152-0
    • Unix.Malware.Vshell-10044416-0

    FScan

    Snort

    • 61106-61152

    ClamAV

    • Multios.Tool.fscan-10041752-1
    • Multios.Tool.fscan-9976167-5

     

     

    IOCs

    IOCs related to these threats are available in our GitHub repository here.

    Source: Cisco Talos Intelligence · 2026-11-13

  • Inside KeyDrift: Analyzing historical UAT-11473 activity on Cisco SD-WAN

    Inside KeyDrift: Analyzing historical UAT-11473 activity on Cisco SD-WAN

    • Cisco Talos has identified UAT-11473, a highly sophisticated advanced persistent threat (APT) actor, who exploited CVE-2026-20127, an authentication bypass vulnerability in Cisco SD-WAN Catalyst Controller instances to bypass authentication and gain unauthorized access to affected systems.
    • UAT-11473 then installed a custom malware framework we track as “KeyDrift” consisting of multiple components geared towards collecting sensitive keying information, acting as backdoors and intermediate command-and-control (C2) hosts.
    • Observed targeting spans across space and satellite services, defense and aerospace technology, and policy research.

    Inside KeyDrift: Analyzing historical UAT-11473 activity on Cisco SD-WAN

    Talos assesses with high confidence that UAT-11473’s operating infrastructure overlaps considerably with Volt Typhoon’s “Silent Train” covert access network.

    KeyDrift is a custom malware framework that is designed to operate in Cisco SD-WAN controller environments. Talos assesses with high confidence that the framework is designed to provide long-term persistent access and automated exfiltration of sensitive keying material. KeyDrift operates inside SD-WAN control-plane processes and is capable of intercepting decrypted control traffic, extracting control-session metadata and data-plane keying material, and staging or transmitting the collected material using encrypted records.

    The framework’s primary component is PolyFlame, a memory-resident module deployed through modified runit service paths. PolyFlame is injected into legitimate running vdaemon processes, and it can also masquerade as a packed “aaamgrd” loader variant. Once resident, PolyFlame interposes socket, DTLS, and runtime-linker behavior through functions such as recvfrom, sendto, getpeername, dlopen, dlsym, mprotect, and “/proc/%d/maps” parsing. This gives KeyDrift access to SD-WAN control-plane traffic from inside legitimate controller daemon execution rather than through a conventional endpoint beacon.

    LittleFilch, another component of the KeyDrift framework, provides the collection and exfiltration capability identified in the framework. The module hooks “SSL_read” inside vdaemon, inspects decrypted control-plane buffers, extracts keying material for a list of predefined edge nodes, and stages the data locally in encrypted format for exfiltration.

    Talos assesses with high confidence that KeyDrift’s intended operational purpose is Cisco SD-WAN control-plane collection: persistent controller residence, in-band traffic access, key-material extraction from decrypted control messages, and encrypted staging or exfiltration of the recovered material. Observed variations of the KeyDrift modules and deployment mechanisms suggest active development of the framework’s capabilities.

    KeyDrift analysis

    KeyDrift uses Cisco SD-WAN runit service paths as its primary execution anchor. In the PolyFlame sshd deployment, the actor modifies the service run script, remounts /rootfs.rw executable, launches a malicious script “conf_sshd” in the background, and then starts the legitimate sshd service. The loader script enumerates running vdaemon PIDs, records them in “/tmp/system-vdaemon”, and invokes the injector component “rsshd” to inject PolyFlame (“libdssl.so”) into each process.

    Recovered conf_sshd logic uses the same control flow across reviewed samples:

    Inside KeyDrift: Analyzing historical UAT-11473 activity on Cisco SD-WAN
    Figure 1. conf_sshd control flow logic.

    Runit launchers

    The observed sshd runit launcher preserves normal Cisco SD-WAN sshd startup logic while adding two malicious lines before service execution, which remount “/rootfs.rw” executable and background execution of conf_sshd, which then drives rsshd injection into vdaemon.

    Inside KeyDrift: Analyzing historical UAT-11473 activity on Cisco SD-WAN
    Figure 2. conf_sshd execution logic.

    The recovered aaamgr runit launcher from an affected vBond appliance uses a parallel service-wrapper pattern, but it executes the packed aaamgrd PolyFlame loader directly. The deletion of the writable-overlay PAM configurations for sshd and login before remounting “/rootfs.rw” executable if part of the legitimate script, along with the invocation of the aaamgrd daemon via Python:

    Inside KeyDrift: Analyzing historical UAT-11473 activity on Cisco SD-WAN
    Figure 3. aamgrd daemon launch.

    PolyFlame

    PolyFlame is the primary operational module in the KeyDrift framework. PolyFlame operates at the socket and DTLS control-plane layer. PolyFlame serves two primary purposes:

    • Command execution via a TinyShell-styled backdoor
    • Intermediate C2 that can forward commands to and from the C2 to other peers

    PolyFlame is primarily injected into the vdaemon process, providing operational obfuscation and access to all in-process state: DTLS session keys, vEdge topology, OMP routes, and policy tables. No hardcoded IPv4 addresses, binding ports, callback domains, URLs, host headers, or polling interval were recovered from the analyzed PolyFlame samples. PolyFlame is designed for in-band control or tasking over Cisco SD-WAN control-plane traffic rather than a conventional fixed external beacon.

    This implant is meant to serve as a hook of the recvfrom() API call. The original recvfrom is replaced by a malicious subroutine in the vdaemon process. When recvfrom is called in the vdaemon process, the malicious subroutine will first execute the real/legitimate recvfrom() API to obtain the C2 IP address info for communicating with it in the future.

    PolyFlame’s time check

    The recvd data from the C2 consists of the MD5 value of a specific DATE. PolyFlame will calculate the local time on the device in format “%Y-%m-%d” and calculate its MD5 hash. If the MD5 calculated by the device does not match with the one sent by the C2, the implant will stop further execution. Otherwise, the implant then uses an “administrative code” from the C2 and performs an action.

    PolyFlame’s tasking

    PolyFlame contains an administrative mode that processes the admin code sent by the C2, that defines operations — it’s one of the first flags checked in the backdoor:

    • Code = 1: Generate random bytes and send to C2. This is likely a check-in beacon or heartbeat for the C2.
    • Code = 2: Set implant type to backdoor (TinyShell) or intermediate C2.
    • Code = 3: Set up the command handler for the intermediate C2.
    • Any other code value: Check the implant type flag currently set. Based on the implant type flag, either send the accompanying data to TinyShell or the intermediate C2 component for processing.

    PolyFlame’s command execution

    PolyFlame contains a backdoor that matches the capabilities of TinyShell: file read, file write, and arbitrary command execution, but not interactive shell. This backdoor component’s implementation is quite similar to TinyShell, but the command codes differ. PolyFlame handles the following command codes:

    • Code = 0x100: Execute command using “/bin/sh -c <command>”
    • Code = 0x200: Write file to disk.
    • Code = 0x300: Read file from disk and send to the C2.

    PolyFlame as an intermediate C2 component

    The intermediate C2 component is a one-to-many handler (somewhat like a one-to-many multiplexer) — meaning the implant can connect to only one C2 but can connect to many peers who can be served by the intermediate C2 component. Similar to the TinyShell-backdoor component, the intermediate C2 component also accepts and processes specific command codes from the C2:

    • Code = 0x403: Create a thread to connect to the specified peer IP. Make a new connection and keep socket alive until specified.
    • Code = 0x404: Send data recvd from the C2 to a connected peer.
    • Code = 0x405: Remove a peer from the list of active connections.
    • Code = 0x407: Send a response recvd from a peer, back to the C2.
    • Code = 0x408: Set a specific value in memory.

    PolyFlame variant: aaamgrd

     Talos has observed a distinct PolyFlame variant that masquerades as the aaamgr service. The legitimate Cisco aaamgr component is a Python package; it does not normally appear as a compiled ELF runit service. This PolyFlame variant is executed by a malicious runit service under “/etc/sv/aaamgr/” with aaamgrd and a modified run launcher.

    aaamgrd is a statically linked ELF64 executable with no section headers, a single RWE loader segment, and an RC4-encrypted embedded ELF payload. The loader uses direct syscalls including ptrace, fork, wait4, kill, tgkill, mmap, and mprotect. It performs an anti-debug check by deobfuscating /proc/%d/status and TracerPid: and exits if a tracer is present.

    The observed staging sequence was:

    Inside KeyDrift: Analyzing historical UAT-11473 activity on Cisco SD-WAN

    Figure 4. PolyFlame staging sequence.

    Note that in addition to the implant execution staging, there are also indications of timestomping.

    LittleFilch: libcommon.so TLS interception module

    LittleFilch is a control-session interception module positioned to collect data-plane keying material from control sessions visible to the injected vSmart process.

    LittleFilch installs an SSL_read hook inside vdaemon. The hook calls the original SSL_read, then processes returned buffers only when the returned size is greater than 0x18F, the first decrypted byte is 0x07, and three marker patterns are checked for presence. These marker bytes are followed by the actual artifacts that LittleFilch aims to record:

    Marker bytes

    Parsed field

    Length

    Notes

    40 03 06

    Public IP

    4 bytes

    vEdge
    public / transport IP

    40 0C 04

    Peer
    system-IP

    4 bytes

    vEdge OMP
    system-IP

    05 01 0C
    06 40

    Binary
    key field

    32 (0x20)
    bytes

    Assessed
    OMP-distributed AES-256 IPsec data-plane key material

    LittleFilch records the extracted keying material and RSA-encrypts it before writing the output to “/var/tmp/vdaemon.bin”. It can then send the encrypted content over UDP in a DTLS 1.2 application-data style record.

    Inside KeyDrift: Analyzing historical UAT-11473 activity on Cisco SD-WAN
    Figure 5. Keying material recording format used by LittleFilch.

    LittleFilch expects its configuration file — located at “/var/tmp/vdaemon.conf” —  to contain two host port lines: one local bind IP/port and one remote destination IP/port. It deletes “/var/tmp/vdaemon.conf” after reading it. Talos has not been able to recover the “vdaemon.conf” file.

    KeyDrift components

    Component

    Primary hook/surface

    Observed scope

    Confirmed
    function

    PolyFlame
    libdssl.so

    Socket /
    DTLS / runtime linker interposition inside vdaemon

    Multiple
    affected controller roles

    In-band
    control-plane interception and tasking; exact command format unresolved

    rsshd

    Ptrace
    injection

    Multiple
    affected controller roles

    Injects
    libdssl.so into vdaemon by PID

    conf_sshd

    Shell-based
    PID enumeration

    Multiple
    affected controller roles

    Locates
    vdaemon PIDs and records injection output

    Trojanized
    run

    Runit
    service launcher

    Multiple
    affected controller roles

    Remounts
    overlay executable and launches injector chain

    Packed
    aaamgrd

    Packed
    loader, direct syscalls, anti-debug

    Affected
    vBond appliance evidence

    Decrypts
    and runs embedded PolyFlame payload; tampers with PAM configs

    LittleFilch
    libcommon.so

    OpenSSL
    SSL_read hook

    Affected
    vSmart process evidence

    Extracts
    control-session identifiers and assessed data-plane key material from
    decrypted control traffic

    vdaemon.bin

    Encrypted
    staging file

    Affected
    vSmart process evidence

    Stores
    RSA-encrypted LittleFilch telemetry records

    vdaemon.conf

    Runtime
    endpoint config

    Affected
    vSmart process evidence

    Supplies
    local and remote UDP endpoint configuration; deleted after read

    MITRE ATT&CK techniques 

    Technique

    ID

    Notes

    Process
    Injection: Ptrace System Calls

    T1055.008

    rsshd
    injects libdssl.so into vdaemon by PID

    Hijack
    Execution Flow: Dynamic Linker Hijacking

    T1574.006

    PolyFlame
    uses dlsym(RTLD_NEXT, …), dlopen, and runtime interposition

    Boot or
    Logon Initialization Scripts

    T1037

    Modified
    runit service scripts launch KeyDrift components

    Create or
    Modify System Process

    T1543

    Malicious
    service paths under etc/sv/sshd/ and etc/sv/aaamgr/

    Masquerade
    Task or Service

    T1036.004

    sshd and
    aaamgr service-name masquerading

    Unix
    Shell

    T1059.004

    conf_sshd
    and recovered operator staging commands

    Software
    Packing

    T1027.002

    aaamgrd
    uses packed embedded ELF payload

    System
    Checks

    T1497.001

    aaamgrd
    checks TracerPid before unpacking

    Timestomp

    T1070.006

    touch
    –reference= and chmod –reference= staging commands copied reference file
    metadata

    Network
    Sniffing

    T1040

    PolyFlame
    and LittleFilch intercept SD-WAN control-plane traffic

    Encrypted
    Channel: Symmetric Cryptography

    T1573.001

    PolyFlame
    AES implementation; aaamgrd RC4 packer; LittleFilch RSA-encrypted records

    Recommendations

    Cisco has released patches for CVE-2026-20127 and published a hardening guide for Cisco Catalyst SD-WAN deployments available here. Organizations are strongly advised to prioritize the application of these patches and follow the guidance provided.

    Following the identification of UAT-11473 activity, Talos strongly recommends that organizations monitor their systems for indicators of post-compromise activity. Should any signs of unauthorized activity be detected, organizations should immediately activate their incident response frameworks. Contact the Cisco Technical Assistance Center (TAC) for support by initiating a TAC request.

    Coverage

    Snort SIDs are already available for CVE-2026-20127: 65938, 65958.

    Snort SIDs for the malicious artifacts illustrated in this blog:

    • Snort v2: 67387 through 67416
    • Snort v3: 7:44 through 7:73

    Source: Cisco Talos Intelligence · 2026-10-28

  • Compromised eMudhra intermediate certificates

    Compromised eMudhra intermediate certificates

    Compromised eMudhra intermediate certificates

    Cisco Talos is aware of eight compromised intermediate certificates belonging to the intermediate certificate authority, eMudhra. Rather than possessing the mandatory 384 bits of pseudo-random security, several private keys evaluated single-digit and double-digit integers. This misconfiguration allows an attacker with the private key of any of the compromised intermediate CAs to impersonate any website or service. Six of the TLS certificates, trusted by Chrome, Mozilla, and Apple have been blocked by these vendors already. Two other certificates, used for codesigning by Microsoft, have also been blocked. Talos expects there will be additional patches available across a variety of technologies as software applications work to remediate the certificates’ exposure.

    Following the disclosure, eMudhra has revoked the compromised certificates and stopped issuing new certificates under its G3 root.

    Compromise details

    The cause of this issue, originated during an April 30, 2025 key generation activity conducted by eMudhra under its emSign Root TLS CA – G3 and cross-signed Comodo AAA Certificate Services.  During a key generation ceremony for 24 subordinate CAs, a flaw in eMudhra’s key generation process created a second set of weak P-384 keys during a wrap/unwrap step. Those keys were mistakenly used for eight intermediate CA certificates. This flaw took the encryption from 384 bytes of entropy down to 3 – 8, making recovering the private keys trivial. The following are the impacted certificates, as illustrated in Mozilla’s bug report:

    EM EV TLS CA - G3B (eMudhra BV), CCADB A012304
SHA-256 E7568FE6E12331F4FD7DE61DA4C7559D0F8EB192A218D4741A3BA75184333838
serial c7c41efe92d825f05eae841a4a82c1, issuer emSign Root TLS CA - G3

EM OV TLS CA - G3B (eMudhra BV), CCADB A012308
SHA-256 98B896625C0C230ADEEC3EB2CF6AAD5001ECF9156A68644E82374CE5833BC25B
serial 6cada367fb1c100088120ea202d568, issuer emSign Root TLS CA - G3

EM DV TLS CA - G3B (eMudhra BV), CCADB A012302
SHA-256 42C4ACCD12C4F59597925E1A08A7A90102608543809308D50EC427E118BA1493
serial a4aee678f23362b4c0e460b772f214, issuer emSign Root TLS CA - G3

EM EV TLS CA - G3C (eMudhra Inc), CCADB A012296
SHA-256 432EC25F0D28DE9006D97BF752F17BBB2CD41F669933FCB072D9A1148D0261F3
serial 8009928a64107601af05fa2f19f109, issuer emSign Root TLS CA - G3

EM OV TLS CA - G3C (eMudhra Inc), CCADB A012300
SHA-256 CB6E15165AC802E9B3F993F16C25D41F4E81C21EBDE71AE1B012AC00BF9C7C3F
serial 296926c227a3a1526392b19482a504, issuer emSign Root TLS CA - G3

EM DV TLS CA - G3C (eMudhra Inc), CCADB A012294
SHA-256 0164D7CEAE5BB909C272AF151FF44B1177AE9B47D9424B94F1D9558C30934D19
serial 588b2e3c2bb8cda13e1a1209254321, issuer emSign Root TLS CA - G3

EM OV CS CA - G3B (eMudhra BV), CCADB A012306
SHA-256 9E39DE2881273ACC225A149C72BA3E0F51424963669AB633EE1DC7DF5DB067B4
serial 7818933f8f85b4619a2b35fba83d0a, issuer emSign Root CS CA - G3

EM OV CS CA - G3C (eMudhra Inc), CCADB A012298
SHA-256 4B2460A466F95FD40113BCDCCA2CEB29B3B093921DE45474DA7DF48874C630B1
serial 544b7f922c31ae220a4a922916f6e6, issuer emSign Root CS CA - G3

    CVE-2026-111943 

    Unlike languages that defer entirely to external dynamic system libraries (like OpenSSL), the Go programming runtime implements its own X.509 chain verification engine in the standard library (crypto/x509). While Go usually queries platform certificates, several platforms or static container environments rely on embedded or legacy root certificate pools where certificate revocations are ignored. 

    To eliminate exploitation across the entire cloud-native ecosystem including Docker, Kubernetes, Terraform, and Prometheus, the Go team designated the compromised certificates as a vulnerability, CVE-2026-111943, and released Go versions 1.27.3 and 1.26.10. 

     The fixed versions filter out chains containingthe SHA-256 hashes of the SubjectPublicKeyInfo (SPKI) for all eight compromised eMudhra intermediate certificates.

    Impact

    These compromised certificates could allow adversaries to impersonate servers and intercept or modify traffic. The impact of their exposure is far more than just web browsers. Other programs that check for TLS certificates might still be impacted since they may not check revocation lists. One clear example is related to virtual private networks (VPNs); these technologies will likely require software updates to mitigate the issue. Based on this guidance, Talos strongly recommends users update software using and handling TLS certificates as fixes become available.

    Talos is actively monitoring the impact of these compromised certificates and has not seen any malicious incidents involving them in the wild yet (as of October 21, 2026 14:00 UTC / 10:00 a.m. ET).

    Significance of this breach  

    Public key infrastructure relies on trust being delegated through certificate chains: root CAs authorize intermediate CAs, which can issue certificates within the scope of their authority. An attacker who obtains an intermediate CA’s private key may be able to issue fraudulent certificates that clients accept, subject to the intermediate certificate’s constraints and each client’s validation controls. In this incident, six compromised intermediates were for TLS and two were for code signing.

     For TLS, an attacker able to intercept or redirect a connection could use a fraudulent certificate to impersonate a server and potentially read or modify traffic if the client still trusts the affected key and no applicable protection blocks it. Protections such as revocation, key distrust, certificate transparency enforcement, and certificate pinning can prevent or expose such an attack. Browser vendors have blocked the affected TLS keys, but other applications may rely on separate trust stores or validation paths:

    Enterprise infrastructure and VPNs

    Organizations should assess TLS-using software and appliances, including proxies, reverse load balancers, VPN clients, and gateways. Exposure depends on the certificate chain being validated and the trust store and revocation behavior in use. A stale or separately managed trust store may need an application, operating-system, firmware, or trust-bundle update; verify the required action for each product.

    Software supply chains and CI/CD

    Build runners and package managers may be exposed if they fetch content over TLS while still trusting an affected key and an attacker can intercept the connection. A fraudulent TLS certificate could enable registry impersonation, but it would not by itself bypass separate package integrity checks, such as lockfile hashes, checksums, signatures, or provenance controls. Assess the actual package-manager configuration and dependency path.

    Industrial IoT and embedded systems

    Review devices that use bundled or independently managed CA stores, especially where certificate revocation or trust-store updates may be limited. Some devices may require a vendor update or compensating control, but the necessary action depends on each device’s validation and update mechanisms.

    Talos recommends updating affected software and trust stores as vendor fixes become available.

    Coverage

    The following SNORT® SIDs provide coverage for this threat: 67363 – 67374.

     

    Talos would like to highlight the efforts of Chris Morrison for providing emergency coverage and mitigations for this threat.

    Source: Cisco Talos Intelligence · 2026-10-21

  • Two critical RCEs in PHP core

    Two critical RCEs in PHP core

    Two critical RCEs in PHP core

    Update 10/22: Added section detailing observations of in the wild exploitation and associated IOCs.

    Cisco Talos is tracking the disclosure of two unauthenticated remote code execution (RCE) flaws in PHP core, dubbed “php2shell”, triggered by a plain HTTP request and exploitable before any application code runs, affecting every PHP build since 5.4. Based on the entities involved in the disclosure, artificial intelligence and associated technologies played a key role in the discovery of these vulnerabilities — yet another example of how these technologies are forcing change across the landscape, most notably on patching processes for organizations because of the wave of vulnerabilities being disclosed. 

    Cisco customers are covered with the Cisco Talos Network Intrusion Prevention (SNORT®) signatures 67359, 67360, and 67375. These rules are also available in the Community Ruleset for open-source customers. Splunk Enterprise Security customers have an Enterprise Security Content Update with detections available. Please refer to the following recommendations, detection, and coverage guidance for more information.

    Details

    CVE-2026-109618 and CVE-2026-109619 are both critical vulnerabilities with a CVSS v4.0 score of 9.2.

    • CVE-2026-109618 occurs when out-of-memory handling interrupts PHP while internal request data is only partially initialized. Request cleanup may then treat invalid data as valid.
    • CVE-2026-109619 occurs when a stale internal state is reused after its backing memory has already been freed, before normal initialization resets it.

    Impact

    The potential blast radius is enormous and extends across the PHP ecosystem. The vulnerability sits in PHP core, so applications running affected versions — including WordPress, Drupal, Magento, Shopware, WooCommerce, and Laravel, plus PHP sites hosted through cPanel or Plesk — may be exposed. Note that many older branches will no longer receive fixes, so customers are urged to upgrade to a supported version as soon as possible.

    Talos regularly investigates threat actor exploitation of vulnerabilities. State-sponsored and affiliated threat actors, as well as ransomware and other financially motivated groups, all employ tactics to exploit RCE. Talos assesses that all industries running PHP applications are at risk for exploitation if systems remain unpatched.

    PHP 8.1 and older are end of life (EOL), and PHP 8.2 security support ends Dec. 31, 2026. Talos’ initial estimates based on open-source intelligence show a significant corpus of PHP systems that will not receive a patch (~50%). If your organization is running PHP 8.1 or older, Talos very strongly advises immediate update to PHP 8.2 or later. There is no patch for PHP 8.1 or older.

    Talos is actively monitoring the impact of these CVEs and has not seen them being exploited in the wild yet (as of October 21, 2026 14:00 UTC/10:00 a.m. ET).

    Observed Exploitation 

    Cisco Talos began observing exploitation attempts within hours of the vulnerabilities’ disclosure. So far, most of the activity is scanning, along with some uncoordinated attempts to deliver various payloads. This is expected: scanning or basic exploitation with public proof-of-concept (PoC) code takes far less effort than integrating a vulnerability into an actor’s own tooling. We expect exploitation volume to grow in the coming days, and campaigns to become more sophisticated and coordinated as more capable groups finish updating their tooling and begin deploying it. 

    Recommendations and detection guidance

    Talos strongly recommends all PHP users to upgrade to the available fixed releases. There are no intermediate or temporary controls that provide comprehensive protection; however, PHP advises that the following measure may reduce exposure to specific attack paths:

    CVE-2026-109618

    • Set memory_limit=-1, preferably in a way applications can’t override, such as php_admin_value in the FPM pool or Apache configuration, and check that no pool, directory or application setting puts a finite limit back. This removes the controllable PHP memory limit failure, but an underlying allocation failure can still reach the vulnerable path.
    • Set a low post_max_size. For applications that don’t require file uploads, set post_max_size = 8M. If file uploads are necessary, set post_max_size = 32M. Keep upload_max_filesize below post_max_size. Consider enforcing limits at the web server or proxy level for decoded request size, input field count, multipart part count, header count, and nesting depth. These limits must also cover requests without a usable Content-Length.
    • Use a container or cgroup limit as an availability boundary, preferably with a policy that kills only the affected worker. Do not substitute RLIMIT_AS or RLIMIT_DATA, as these can cause the vulnerable allocation failure.

    CVE-2026-109619

    • Set session.upload_progress.enabled=0 and restart every worker. Use php.ini, an FPM pool, or server configuration that applies before request parsing. Do not rely on ini_set() or FPM .user.ini. This blocks the confirmed session paths but not other variants.
    • On PHP 8.5, set fatal_error_backtraces=0 and restart every worker. This blocks the confirmed fatal backtrace path only.
    • Remove invalid or deprecated settings applied per request that emit diagnostics before initialization. Hiding diagnostics with error_reporting, display_errors, or @ does not help.
    • Fix attacker-reachable fatal errors and execution timeouts, including failures in callbacks, upload or import processing, and cleanup.

    This is another vulnerability that owes its discovery to AI and its associated technologies. As we move through 2026, the wave of vulnerabilities and related patches is building. Talos advises organizations to work on a triaged process for prioritizing vulnerabilities with a specific focus on public-facing systems and vulnerabilities that are under active exploitation. The glaring need to prioritize vulnerabilities along with a streamlined process for rolling out patching strongly indicates that the historic trend of “baking in” patches before deployment is not going to survive the AI era.

    The true impact of this vulnerability will take time to evaluate. These types of vulnerabilities that impact core technologies tend to cascade into other platforms and applications as they evaluate impact and provide associated patching, harkening back to the waves of exploitation that we saw after Log4J.

    Coverage

    SNORT® SIDs covering these vulnerabilities for subscribers: 67359, 67360, 67375. Free community rules are live through our Community Ruleset.

    Splunk has released an Enterprise Security Content Update (ESCU) related to the ongoing PHP2Shell activity with additional detections. Splunk Enterprise Security customers are urged to download and apply.

    Talos would like to highlight the efforts of Ankur Tyagi, Dalton Schaadt, Brandon Stultz, and Matt Killion for providing emergency coverage and mitigations for these threats.

    In this video, Talos’ Nick Biasini explains what the vulnerabilities allow adversaries to do, how to assess your exposure, and what defenders should prioritize.

    Indicators of Compromise (IoCs) 

    5.191.140[.]240 
    158.69.113[.]75 
    94.154.43[.]149 
    143.246.223[.]124 
    45.198.224[.]169 
    85.11.167[.]243 

    Source: Cisco Talos Intelligence · 2026-10-21