Posts on Security, Cloud, DevOps, Citrix, VMware and others.
Words and views are my own and do not reflect on my companies views.
Disclaimer: some of the links on this site are affiliate links, if you click on them and make a purchase, I make a commission.
Google on Wednesday took the wraps off Gemini 4 Carbon, its latest frontier model with state-of-the-art cybersecurity and long-horizon capabilities.
"It shows significant gains across coding and agentic tasks as well as across key capabilities critical for cybersecurity defense, landing a firm lead in SEC-bench Pro (88.2%) for finding vulnerabilities, ExploitGym (54.8%) for exploitation, and CWE-bench (71.0%) for patching," Koray Kavukcuoglu, senior vice president of Google DeepMind and chief AI architect at Google, said.
On the Artificial Analysis Intelligence Index benchmark, Carbon leads with a score of 59, surpassing Anthropic's Claude Opus 5.5 (58), OpenAI GPT-6 Astra (57), GPT-6.1 Sol (55).
One of the core focus areas is cybersecurity, where the latest iteration reportedly delivers significant performance improvements across the board, including vulnerability detection, validation, and remediation. Carbon is also twice as likely to generate secure code versus Argon.
Google also emphasized that Carbon attempts to respond to complex or high-pressure tasks by seeking human input in the face of ambiguity rather than "guessing or forcing a path forward," as well as resisting every evaluated attack attempt at indirect prompt injection.
The debut of Gemini 4 Carbon comes less than a week after the tech giant unveiled Gemini 4 Argon. The release plan is similar to that of its predecessor, with the rollout currently limited to a subset of cyber defenders before expanding access to other trusted partners as part of its Fairwind Program.
Google also said it's actively engaged in the U.S. government's voluntary process for pre-release model testing.
The development comes as OpenAI released GPT-6.1 Terra, which it described as a fast, efficient model that "excels at communication and computer-based tasks."
"GPT‑6.1 Terra meets the Critical threshold in cybersecurity under our Preparedness Framework, and maintains the protections developed for GPT‑6 Astra," OpenAI said.
"GPT-6.1 Terra brings with it the alignment improvements of the GPT-6 series. According to our evaluations, GPT-6.1 Terra is more likely to stay within scope and honestly disclose limitations and potential blockers to the user compared to GPT-5.6 Terra. In our prompt-injection tests, GPT-6.1 Terra also showed strong resistance to malicious instructions designed to divert it from the user's task."
Earlier this week, rival Anthropic also disclosed that an unreleased, internal research model uncovered critical vulnerabilities in some of the world's most widely used software.
This included a one-click remote code execution in Google Chrome, a one-click exploit chain in Apple Safari that could be used to access a user's browsing history, cookies, and other sensitive data, an Android lock screen bypass, and a denial-of-service (DoS) flaw in the Windows HTTP.sys driver (CVE-2026-33096, CVSS score: 7.5). All the identified issues have been fixed by Google, Apple, and Microsoft.
"These attack chains demonstrate the model's ability to create sophisticated, multi-step exploits in both open-source and proprietary software," Anthropic said.
"These skills have historically been the domain of few specialist teams with expertise in these targets. Now, it’s something models can do with little human involvement, and then prove by producing a working exploit that anyone can run and verify."
from The Hacker News https://ift.tt/pjOtVoC
via IFTTT
GitHub has announced that it's introducing a new package firewall as a preview to block installation of suspicious npm packages during installation time.
"The firewall inspects both metadata requests and package downloads for signs of malicious activity, acting as an install-time policy gate," GitHub said.
The feature, which currently supports only npm packages, is available in public preview for all GitHub Enterprise Cloud customers, including data-resident GitHub Enterprise Cloud.
According to the Microsoft subsidiary, the firewall is placed between endpoints or internal registries and the upstream package repositories so as to deter malware attacks that compromise systems when packages are installed.
This behavior can expose users to severe security risks, especially when artificial intelligence (AI) agents and CI runners automatically install dependencies to complete a task or build without their explicit permission.
The idea is that endpoints like coding agents and CI/CD hosts use the firewall for their requests instead of directly pointing to the public package registries. The firewall then checks package downloads against policy controls such as minimum package age and malware advisories, and blocks downloads that do not meet those policies.
To use the firewall, administrators are required to configure policy controls, such as the ones listed below -
Block known malware by checking against the GitHub Advisory Database for active malware advisories
Block packages based on the severity of vulnerabilities by checking the GitHub Advisory Database for flaws that affect the requested package version. The control defaults to "Critical only" as the severity level that blocks an installation, although users can choose "High or higher," "Medium or higher," or "Any severity."
Block attestation downgrades by comparing attestations for the requested package version with those of earlier versions and stop the download if the requested version does not have an SLSA attestation.
Block newly-introduced install scripts by checking whether the package recently added scripts that run using preinstall or postinstall hooks, which can be abused to steal sensitive data.
Block packages based on a cooldown period that prevents versions that are newer than the configured minimum age from being installed. The value can range from 1 to 365 days. The default value is 1 day. Users can disable it by setting it to 0.
Users who need access to a package that gets blocked erroneously by the firewall can submit an exception request, which can then be approved by enterprise administrators and security managers.
The development comes as Rust 1.100, which is scheduled for release on November 12, 2026, readies to add support for a configurable minimum publish age, allowing security scanners and maintainers time to flag and block malicious crate releases before they can be installed or used by users.
The value, defined via the "global-min-publish-age" option in "cargo/config.toml," allows users to specify a minimum publication age in days or weeks. If left unspecified, a seven-day waiting period is applied by default to skip releases published within that window.
Over the past year, similar waiting periods have been implemented across open-source ecosystems, including npm, Python, Microsoft Visual Studio Code, Ruby, Bun, pnpm, and Yarn, as a way to bolster software supply chain security by reducing the chance that a newly published, unreviewed version is immediately pulled into a build.
Cooldown periods help add friction and slow down attacks in which a bad actor publishes a poisoned version of a popular package after seizing control of a maintainer account, thereby preventing rapid spread through manual or automated installations.
"The tradeoff is that legitimate fixes have to wait, too, unless developers make an exception," Socket said. "Malicious code also doesn't magically become harmless with age. A release that escapes detection can simply outlast the cooldown. The value is in buying researchers, maintainers, and registries time to act before the next dependency update carries an attack further."
from The Hacker News https://ift.tt/n1iMqNy
via IFTTT
Cisco Talos observed a new AI-integrated command-and-control (C2) framework in the wild called “NIK C2.”
NIK C2 contains a Windows implant, using which, an actor can dump credentials, stream the victim's keystrokes to collect the targeted victim’s sensitive data, and instruct an integrated AI model to analyze the harvested data, all within the compromised session.
In this framework, the actor has abused the OpenAI Chat Completions application programming interface (API), which is a HTTP endpoint that enables ChatGPT-style conversations programmatically.
In addition to the features that enable theft, an actor can also deploy desktop screen-locking ransomware via the NIK C2 implant onto the victim machine, leading to a ransom demand in Bitcoin or USDT cryptocurrencies.
NIK C2 reshapes adversary tradecraft by collapsing collection and exploitation into a single continuous session, effectively erasing the offline processing delays that historically granted defenders critical detection windows.
Such AI-enabled adversarial frameworks require defenders to move beyond traditional detection and embrace continuous behavioral vigilance as the new baseline.
NIK C2 implant: AI-integrated remote access tool
The NIK C2 implant is a Go-based, 64-bit Windows remote access tool that grants persistent control over compromised hosts using a resilient dual-channel C2 architecture. It communicates over TLS-secured WebSockets on port 443 alongside an HTTP fallback polling loop every 250 milliseconds, protecting all traffic with AES-256-GCM encryption derived from a hardcoded seed. To survive takedowns, the implant routes traffic across three prioritized C2 tiers, which are runtime-updated URLs, an embedded encrypted server list, and a hardcoded fallback address. Beyond standard operations, the implant features surveillance, theft, lateral movement, and evasion capabilities, including credential dumping, RDP session hijacking, process hollowing, and a C2-driven screen lock ransomware module.
Notably, the NIK C2 implant embeds a fully integrated OpenAI API client via its ai_generate command, allowing operators to route arbitrary prompts to the OpenAI Chat Completions API directly through the infected host. The NIK C2 implant manages API key resolution, request assembly, and response parsing locally, returning the encrypted generative AI results to the actor's C2.
The observed NIK C2 implant samples in the wild contains an embedded build path (/opt/nik_panel/data/build_52b79724a1fc4b8f/main.go), which identifies the project as "nik_panel" and indicates that the implant was cross compiled for Windows from a Linux development environment. Furthermore, the embedded eight-byte hex token matching the build identifier highlights that the threat actor's infrastructure actively tracking and versioning the implants.
Talos observed that the NIK C2 implant development trajectory spans at least three distinct versions. All binaries observed in the wild were compiled with Go 1.23.4 (which was released in December 2024), placing the entire sample set compiled no earlier than late 2024. The actor has Zeroed PE TimeDateStamp fields and near-epoch filesystem timestamps (manifesting as Nov 29, 1979) are applied consistently across all samples.
We developed a timeline based on the initial sighting dates of NIK C2 implant variants in OSINT.
Figure 2. NIK C2 implant evolution timeline.
The pace of capability addition across the three versions indicates a technically proficient team with prior malware operations experience is actively expanding NIK C2 towards a full-service adversarial framework.
Active NIK C2 server seen in the wild
During our research, we observed that a threat actor hosted the NIK C2 framework on a server at IP address “87.120.196[.]120”, resolving the domain “total-sitevv[.]lol”. The C2 server hosted an SSL/TLS certificate (serial number 7d16381a9de823943b5a0987dbd0f26edf22052b and jarm:"28d28d28d00000000042d42d0000001f361a1bf80ed39a1e352adeb016a07b" ) with the Common Name (CN) set to nik-panel. This CN value matches strings embedded within the implant binary. Observing the NIK C2 infrastructure active in the wild allowed us to assess with moderate confidence that NIK C2 is not merely a proof of concept, but a fully functional, AI-integrated C2 framework.
Figure 3. NIK C2 was observed in the wild during the research period.
NIK C2 implant integrates OpenAI’s API
AI integration is one of the most architecturally distinct features of NIK C2 implant. It constructs a fully formed HTTP request to OpenAI’s production inference endpoint, transmits it from the victim machine IP address, parses the JSON response, and returns the AI-generated text to the actor’s panel. The entire operation from receiving the actor prompt to returning the large language model (LLM) reply is executed synchronously with a 60-second timeout.
The implant begins by extracting three fields from the command payload received from the C2. The first field, identified by the key prompt, is the text the actor wants to send to the AI model. If the prompt string has zero length, the handler immediately constructs an error response and returns without making any outbound network call. The second field, identified by the key api_key is the OpenAI API key to use for authentication. The third field, identified by the key model, specifies which OpenAI model to use.
Figure 4. Snippet of NIK C2 implant AI handler module.
After extracting the three parameters, the implant checks whether the actor supplied an API key. If not, it calls the operating system's environment variable reader with the string OPENAI_API_KEY and uses the victim’s API key. This fallback is not a backup mechanism for API key resolution. It is a deliberate design with significant operational implications. If the victim has configured an OpenAI account on their machine, that account's API key will be used to fund the actor's AI inference. OpenAI's billing system will charge the victim's payment method, and OpenAI's access logs will show the victim's API key as the one that made the requests, allowing no trace attributable to the threat actor.
If the actor does not specify a model name, the implant falls back to a five-character default string stored in the binary data section. Decoding the five-character value showed gpt-4 confirming that GPT4 is the default when no model is specified. The actor can override this by passing any valid OpenAI model identifier in the command payload, allowing selection of newer models as they become available without requiring a binary update.
The implant builds the OpenAI API request body by constructing a map with four fields. The first field uses the key model and contains the resolved model name. The second field uses key messages and contains a two-element array of message maps. The third field uses the key temperature and contains a floating-point value read from a constant in the binary data section. The fourth field uses the key max_tokensand contains an integer value also read from binary.
The message array is constructed in the order that the OpenAI Chat Completions API expects. The system message is first followed by the user message. The system message map has the role system and a content string that is exactly 68 bytes long hardcoded in the binary. This 68-byte string is the implant's behavioral instruction to the AI. It defines the model's operational role and response style for the duration of the session. The user message map has the role userand contains the actor's prompt text verbiage. The complete map structure is then serialized to JSON. The JSON message is sent to the URL https:// api.openai.com/v1/chat/completions, the OpenAI Chat Completions endpoint, through an HTTP POST request.
Figure 5. Snippet of NIK C2 implant AI handler module.
When the HTTP response arrives with a 200 status code, the handler uses Golang's JSON decoder to parse the response body directly into a generic map structure without defining a typed schema. It then navigates the decoded map by string key lookups in the sequence that the OpenAI Chat Completions API response structure defines. The outermost map is queried for the key choices which in a successful response contains an array. The implant checks that this array is non-empty, then accesses its element keys messageand content. The string value at key contentis the AI model-generated text response.
After successfully extracting the AI-generated content, the handler assembles a result map with four entries. The key status is set to a constant string that reads as generated. The key code is set to the AI model's response text, so that the actor receives the full content of the model’s replies. The key modelis set to the resolved model name that was used for the request, confirming which model produced the output. The key usageis set to the raw usage object from the OpenAI response, which contains the prompt token count, completion token count, and total token count. This usage data allows the actor to track how many tokens are consumed per request. The completed result map is ultimately transmitted to the C2 server over WebSocket or through the HTTP fallback C2 address.
Figure 6. AI model response is encapsulated in JSON message and will be sent to C2.
Dual execution modes of NIK C2 implant
Upon execution, the implant inspects its command-line arguments to determine its execution path. The argumentwatchdog activates supervisory monitoring to relaunch the core process if terminated, the copywatchdog tracks file copy operations, and the absence of either defaults execution to primary agent mode.
In primary mode, it uses a named mutex to enforce single-instance execution, logs a messagereading [NIK] Starting, generates a 32-byte cryptographic session key if uninitialized, decodes its obfuscated C2 address, and sets its masquerade name to “svchost.exe” or “simvol.exe”.
After initial setup, the binary records its process ID (PID) in the victim's temporary application folder and executes its persistence and evasion routines. These routines include copying to %appdata%/Roaming/Microsoft/Network with modified access controls, configuring Windows autostart registry entries, and masquerading its process. Finally, it starts the local proxy server, initiates the WebSocket communication loop in a separate goroutine, and enters a continuous heartbeat polling loop on the main thread.
Implant’s C2 command surface overview
The implant command dispatcher module facilitates over 52 commands that are directed by the C2 panel. The dispatcher module uses byte-level string matching to map the associated modules that are launched as concurrent goroutines, allowing multiple operations to run in parallel.
The following table shows the NIK C2 implant’s command categories:
Extracts all saved WiFi SSIDs and plaintext passwords via Windows wireless
configuration tooling.
Surveillance
Keylogger
Real-time live stream per keystroke to actor panel, plus accumulated buffer
dump on demand.
Surveillance
Screen Capture
Full-screen screenshot and continuous screen stream.
Surveillance
Camera & Audio
Camera snapshot and stream, microphone recording, live audio feed.
Surveillance
Clipboard Monitor
Real-time clipboard content interception and replacement.
Remote Control
HVNC
Hidden Virtual Network Computing — full desktop control invisible to the victim.
Lateral Movement
SOCKS5/HTTP Proxy
Embedded proxy routing actor traffic through victim into internal network.
Lateral Movement
Reverse Proxy Tunnel
Bidirectional TCP relay tunneled over C2 WebSocket for LAN pivoting.
Lateral Movement
RDP Operations
RDP session interaction for lateral movement to other Windows hosts.
Persistence
Autostart &
Masquerade
Registry Run key persistence, process name masquerading, COM hijacking.
Persistence
Self-Heal Watchdog
External watchdog subprocess monitors and relaunches agent on termination.
Evasion
Defense Bypass
AMSI patch, debugger detection, stealth mode, UAC bypass, process hollowing.
AI
AI Generate
Live OpenAI API inference routed through victim machine with actor prompts.
Destructive
Boot Ransomware
Master Boot Record raw backup via PowerShell disk read and Screen-locking ransomware via LOLbin, registry persistence, crypto payment demand.
Destructive
Bootkit Preparation
UEFI vs. BIOS detection, Secure Boot query, bootkit binary staging.
Implant deploys screen-locking ransomware
The ransomware module of the implant operates as a multi-stage attack controller that the actor runs in sequence to prepare, deploy, and retract a screen-locking ransomware payload.
At first, it executes PowerShell to execute a raw disk copy command that reads directly from the physical drive device path (“\\.\PhysicalDrive0”) and writes the first sector, which is Master Boot Record (MBR), to a file named “mbr_backup.bin” in the Windows temporary directory.
Next, the module constructs a complete self-contained HTML lock screen code entirely at runtime from a hardcoded format string, parameterized with actor supplied Bitcoin and USDT wallet addresses, prices, contact email, timer duration, and custom text from the C2 command message, allowing the actor to fully customize the ransom demands.
Figure 8. Screenlocker HTML code is hardcoded in NIK C2 implant binary.
After generating the HTML code, the binary writes it to the file “lock_screen.html”in the system temporary directory. It then generates a Windows batch script that calls mshta.exe with the path to the HTML file, followed by an infinite loop construct with a five-second timeout between iterations, ensuring that if the user somehow closes the window it reopens within five seconds. This batch file is written to the temp directory as “lock_start.bat”.
The implant then runs a reg add command that writes a registry Run key named “SystemLock” under the current user's autostart path, pointing to a cmd /c invocation of the batch file, so the lock screen is executed on every user's logon. Additionally, a background goroutine is spawned that continuously monitors and relaunches the lock screen process. Finally, the module sends a confirmation response to C2 with the path of the deployed HTML file and the timer value.
The design of this ransomware module is notable for several reasons. It does not encrypt any files, which means it leaves no forensic trail of file modification timestamps or encryption markers. It relies entirely on a screen lock, which is considerably faster to deploy than a file encryption ransomware. The persistence via registry Run key and a self-healing loop ensures the screen lock survives user attempts to dismiss it and survives a system restart.
Figure 9. Desktop lockscreen page of the ransomware deployed by the NIK C2 implant.
Implant’s bootkit preparation feature
The bootkit preparation module of the implant is designed to survey the victim machine's boot firmware environment and then stage a bootkit payload file.
It executes bcdedit /enum, the Windows Boot Configuration Data editor, with the output flag that enumerates all boot entries while hiding the console window. The implant reads the full output and searches for three specific substrings in sequence including EFI,Windows Boot Manager, and Windows Legacy OS Loader. If any of these are found, the boot type is classified as UEFI. The binary also searches for ntldr, the legacy Windows NT loader used by BIOS-mode systems as a fallback. Based on which string was matched, the boot type is recorded as either "UEFI" or "BIOS" as a string of the appropriate length. Separately, the binary runs a PowerShell command invoking Confirm-SecureBootUEFI, which is a built-in PowerShell command that returns to the current Secure Boot state. The output is searched for the string True to detect an enabled Secure Boot and for False to detect an explicitly disabled Secure Boot. If neither is present, the value is recorded as unknown. The result is sent back to the C2, a map containing the boot type classification and the Secure Boot status string.
Then the implant writes a 16-byte placeholder file named “bootkit.bin” to the system temporary directory. The bytes written spell out "NIK_BOOTKIT_PREP" in ASCII, which serves as a staging marker rather than an actual bootkit binary. This placeholder confirms that the target path is writable by the current process, establishes the file location that subsequent operations will reference, and can be overwritten by the actual bootkit binary delivered through the implant's file-upload or file-write command handlers. The path to the staged file is returned to the C2 in response.
Implant’s theft functionality
When the actor issues the theft category commands from the C2, the implant executes the associated goroutines to collect the targeted data into a result map space in the victim machine memory:
WiFi password theft (wifi_steal)
The implant executes netshcommands directly via Go’s exec.Command function by passing arguments as discrete tokens rather than through a shell string. Harvested results are formatted under specific labels: plaintext Wi-Fi passwords appear under Key Content:, saved network names are cataloged under WiFi Profiles:(with missing entries flagged using the per-entry format[%s] not found), and execution failures or absent interfaces return standardized error strings such as [WiFi] no wireless adapter or access deniedand No WiFi profiles found.
netsh wlan show profiles
netsh wlan show profile name="
The implant stages targeted browser database files into an archive alongside the Local State file, which contains the AES master key protected by Data Protection Application Programming Interface (DPAPI). The implant imports and executes the CryptUnprotectDataWindows API to unwrap the AES key and decrypt the databases locally. Otherwise, it exfiltrates the raw encrypted databases to the C2 server for offline extraction.
Targeted browser database files are shown in the table:
Browsers
Targeted files
Chrome
Login Data, Cookies, Web Data, Local State, Bookmarks
Edge
Login Data, Cookies, Web Data, Local State
Brave
Login Data, Cookies,leveldb file
Opera
Login Data from folder Opera Software\Opera Stable\
The implant extracts Discord tokens and session cookies from the levelDB store on the victim machine. The extracted outputs are labelled as === Discord Tokens === and DISCORD TOKENS. The browser session cookies (Discord_Cookies) are extracted from the copied Cookies database.
Victim’s desktop-based wallets are collected directly from the wallet storage paths. Browser extension wallets are extracted from chromium LevelDB stored by extension ID.
Desktop based wallet storage paths targeted are listed below:
/AppData/Roaming/Exodus/exodus.wallet
/AppData/Roaming/Electrum/wallets
/AppData/Local/Electrum/data/wallets
/AppData/Roaming/Ethereum/keystore
/AppData/Local/LedgerLive
wallet.dat (Bitcoin Core)
/AppData/Roaming/atomic (Atomic Wallet)
Electrum\wallets
Browser extension wallets targeted:
Wallet
Extension ID
MetaMask (Chrome/Brave)
nkbihfbeogaeaoehlefnkodbefgpgknn
MetaMask (Edge)
nkbihfbeogaeaoehlefnkodbefgpgknn
Coinbase Wallet
hnbohgpbmfldddohgoiefkeifpjficbk
Phantom (Chrome)
lnbcamaoebkogjmdnaofbeemigaalhlp
Brave Wallet
odbfpeeihodbihlmhbnhakoadhilfibh
Seed phrase, private key file, and system reconnaissance
The implant performs two regular expression patterns to search on the entire filesystem of the victim machine. These two regular expressions are designed to scan file names for sensitive cryptographic assets and credentials, functioning as case-insensitive patterns ?i. The first expression targets cryptocurrency recovery materials and wallet backups by matching keywords like "seed," "mnemonic," or "wallet" paired with common plain-text and data file extensions (.txt, .md, .csv, .dat), while the second seeks out asymmetric private keys and general secrets using terms like "private," "privkey," or "secret" paired with both text files and standard cryptographic key containers (.key, .pem). Because both patterns use unanchored, greedy matching (.*) without start (^) or end ($) boundary anchors, they capture any file where these sensitive terms precede the target extensions. Matched data are collected under the label of seed candidates and archived into “browserdata.zip”.
The implant also performs victim machine reconnaissance by executing the following commands and uses chcp 65001 prefix to force the output in UTF-8 format.
After all collection paths are complete, the implant assembles all collected data into a single document that looks like a formatted report with clearly labeled sections for each data category such as === CRYPTO ===, === WIFI ===, === BROWSER ===.
Keylogger: Keystrokes livestreamed to C2
The keylogger module of the implant uses a persistent background goroutine that polls all 256 Windows virtual key codes, detecting keypresses via dynamically resolved API calls, and transmits the captured input. When a compromised victim presses a valid key on the keyboard, it is simultaneously streamed live as an AES-256-GCM encrypted JSON payload over WebSocket to C2 and also appends to an in-memory buffer capped at 10,000 entries and halved when full to prevent memory leaks. On an actor's dump command, this buffer is concatenated into a single string and returned to C2 via WebSocket or HTTP fallback, ensuring complete data transfer even during network interruptions.
Stolen data exfiltration to C2
Once the archive is assembled, the entire result map is handed to the result transmission routine of the implant. That routine constructs a new JSON object containing five specific fields. It includes the command identifier echoed back from the original command. It also contains the agent's persistent identifier, formatted as ag_<16 hex chars>. The type field is set to the string quick_steal_response. Finally, the data field holds the complete result map.
Once constructed, this object is forwarded to the encryption routine. The routine serializes the object into JSON. It then generates 12 fresh random bytes to serve as a nonce. Next, it encrypts the serialized JSON using AES-256-GCM with a static key derived from a hardcoded seed. It concatenates the nonce, the ciphertext, and the 16-byte authentication tag and Base64-encodes the entire payload. The encrypted payload is placed in a wrapper object under the "e" key alongside the plain-text agent ID, and the wrapper is JSON marshaled into the final payload.
This encrypted payload is then delivered through an available transmission path. The sending routine first checks whether the WebSocket connection is live. If it is, the payload is written directly into a WebSocket text frame on the existing connection, reaching the actor's panel with minimal latency. If the WebSocket is not currently connected, the routine falls back to an HTTP POST request to the endpoint path /api/c2/result on the C2 server, using the same encrypted body format. This dual-path design ensures stolen data is delivered even during WebSocket interruptions, as the HTTP channel remains functional independently of the WebSocket state.
Implant’s C2 protocol
The implant C2 architecture is designed for two independent, simultaneously operating communication channels. The primary channel is a persistent WebSocket connection over TLS. The secondary channel is an HTTP polling loop that posts to a fixed API endpoint at regular intervals.
With the primary channel, the connection begins with a TCP dial to the C2 server address with an eight-second timeout. If the port is not explicitly present in the configured address, port 443 is appended automatically. Once the TCP socket is established, it is wrapped in a TLS session using a custom certificate configuration that pins to a specific certificate rather than validating against the system's certificate authority store. This prevents standard TLS interception proxies from observing traffic.
Immediately after a successful WebSocket handshake but before any command is received, the implant transmits a full system registration message. The implant collects victim data such as the machine hostname, the local LAN IP address, the Windows username from the environment, a user security identifier, the local reverse-proxy port number that was assigned when the embedded proxy server was started, and the detected upstream proxy configuration derived from the Windows registry proxy settings. All of this is assembled into a JSON object and encrypted and sent to the C2.
Figure 10. Snippet of NIK C2 IMPLANT’s C2 communication handler function.
The HTTP polling channel runs independently. Every approximately 250 milliseconds, the agent collects a fresh snapshot of victim state hostname, watchdog status, local IP, username, current timestamp, and system uptime encrypts it in the same wire format and posts it to the /api/c2/update endpoint on the C2 server.
Below table shows the C2 endpoints that the implant communicates:
Endpoint
Purpose
/api/c2/update
Reconnaissance beacon – victim system info
/api/c2/result
Command output exfiltration
/api/c2/screen
Screenshot upload
/api/c2/file_chunk
File exfiltration
/api/c2/rproxy_up
Reverse proxy upstream data
/api/c2/ws
Websocket – actor command channel
Every message on both channels, in both directions, uses the same symmetric encryption scheme. A hardcoded seed value stored in obfuscated form in the binary data section is decoded at startup and produces a 32-byte AES key.
The C2 server then responds with an encrypted payload, whose inner map contains a command array identical in structure to those delivered over WebSocket. Commands received through HTTP are dispatched through the same logic. If the HTTP POST fails, the agent rotates to the next server address before retrying.
Figure 11. Snippet of NIK C2 implant’s C2 communication handler function.
The result transmission to the C2 is performed by the implant when a command handler completes its operation, the result is packaged into a response envelope containing the original command's identifier, the implant's own identifier, a type string formed by appending _response to the command name, the result data payload, and a top-level type marker of "result". This object is encrypted and delivered through either directly over the WebSocket connection if it is active, or via an HTTP POST to /api/c2/result.
Implant’s defense evasion and anti-analysis techniques
The NIK C2 implant deploys a layered set of defense evasion measures that activate immediately at startup and operate across the full compromise session. On launch, It hides its console window via API ShowWindow, renames the binary to “csrss.exe” in the Windows temp directory to impersonate a legitimate system process, disables Windows Recent Documents telemetry through a registry write action, and applies a critical-process flag via API NtSetInformationProcesswith the parameter value0x1Dfor ProcessBreakOnTermination that causes a Blue Screen of Death if any attempt is made to terminate the process through Task Manager or taskkill actions.
Figure 12. Snippet of NIK C2 implant’s evasion handler module.
Alongside these, two anti-debug checks IsDebuggerPresent and CheckRemoteDebuggerPresent run silently and call os.Exit(0) on detection, leaving no exception record or crash evidence. When directed by the C2, the implant can also escalate privileges without a UAC prompt using the fodhelper.exe COM hijack, which writes the implant path into HKCU\Software\Classes\ms-settings\Shell\Open\command, triggers elevation, and cleans the registry key within two seconds.
The implant bypasses the Antimalware Scan Interface (AMSI) by executing a hardcoded, embedded PowerShell script that patches memory inside “System.Management.Automation.dll”. Specifically, it overwrites the AmsiInitFailed field with a six-byte stub (MOV EAX, E_INVALIDARG; RET), forcing initialization to report failure and disabling content inspection for the remaining of the PowerShell session.
The emergence of NIK C2, an AI-enabled command-and-control framework, underscores a critical shift in modern malware design: the transition from static intrusion toolsets to dynamic, modular implants that adapt on demand. By embedding a live AI pipeline directly into the C2 loop, the compromised host is no longer a passive foothold but an autonomous operational asset. Operators can dynamically generate context-aware lure material, execute localized deception, synthesize operational intelligence, and craft targeted payloads directly on the compromised hosts — all while lowering the technical barrier which was traditionally required for such sophisticated tradecraft.
Coverage
The following ClamAV signature detects and blocks this threat:
Win.Trojan.GoDiscorder-10060526-0
Indicators of compromise (IOCs)
IOCs for this research can be found at our GitHub repository here.
from Cisco Talos Blog https://ift.tt/27SWLbv
via IFTTT
Hackers exploited a critical Cisco Catalyst SD-WAN flaw, fixed in February, to plant custom malware inside the systems that control an organization's SD-WAN network.
The malware, called KeyDrift, is designed to copy the keys that encrypt traffic between sites and store them for later use, Cisco Talos said on October 28. Talos calls the attacks historical but does not specify when they occurred or whether any keys were sent.
The flaw is tracked as CVE-2026-20127 and has a CVSS score of 10.0. It allows an unauthenticated remote attacker to bypass authentication and gain administrative privileges on these control systems. On a Controller, the attacker can log in as a high-privileged internal account that is not root.
When Cisco disclosed the flaw in February, Talos tracked its exploitation as UAT-8616, a cluster of activity it said went back to at least 2023.
In Cisco's traditional key exchange, each SD-WAN router periodically generates an AES key for its traffic and sends it to the Catalyst SD-WAN Controller (formerly vSmart). The Controller passes the keys on to other routers. A process on the Controller called vdaemon runs the encrypted control connections that carry these keys.
On a compromised Controller, a KeyDrift component called LittleFilch hooks into vdaemon and reads control messages after they are decrypted. For a preset list of edge routers, it pulls out their IP addresses and a 32-byte field. Talos assesses that field as the AES-256 key material that the Controller passes between routers.
LittleFilch encrypts what it collects with RSA and writes it to a file. It can then send that data over UDP to an address listed in a settings file, which it deletes after reading. Talos could not recover that settings file.
The group behind KeyDrift, which Talos tracks as UAT-11473, has targeted space and satellite services, defense and aerospace technology, and policy research.
The group's infrastructure "overlaps considerably" with Silent Train, Talos assesses with high confidence. Silent Train is the name Lumen's Black Lotus Labs uses for a network of hacked small-office, home-office, IoT and business devices.
Lumen says Volt Typhoon used the network to hide its activity. CISA, the NSA and the FBI said in 2024 that Volt Typhoon is a Chinese state-sponsored cyber group.
Talos links UAT-11473 to Volt Typhoon only through the infrastructure overlap. It does not say the two are the same group, or how UAT-11473 relates to UAT-8616, the cluster it reported in February.
Separately, Lumen said on October 28 that Volt Typhoon was exploiting CVE-2026-20127 by late 2025 and continued to exploit it after Cisco disclosed the flaw in February. Lumen does not tie that activity to KeyDrift.
KeyDrift primarily starts via modified runit scripts that Cisco SD-WAN devices use to launch their services, according to Talos. In one version, the script for the SSH service starts a loader script, conf_sshd, before the real SSH server. The conf_sshd script writes vdaemon's process IDs to a file, and a tool called rsshd injects KeyDrift's main module, PolyFlame, into each of those processes.
PolyFlame runs in memory inside vdaemon. It can act as a TinyShell-like backdoor that runs commands and reads and writes files, or as a relay that forwards commands between its command server and other machines. It is built to accept commands within SD-WAN control traffic, and the analyzed samples contained no hardcoded server address.
On a compromised Validator, formerly vBond, a fake aaamgr service under /etc/sv/aaamgr/ runs a packed loader, aaamgrd, that decrypts and runs PolyFlame. Cisco's real aaamgr component is a Python package and does not normally run as a compiled service.
There are also signs of timestomping: commands the group ran copied the timestamps and permissions of existing files onto its own files.
Affected Releases and Fixes
CVE-2026-20127 affects the Catalyst SD-WAN Controller (formerly vSmart), Manager (formerly vManage), and Validator (formerly vBond), regardless of their configuration. On-premises systems are affected, as are Cisco's hosted SD-WAN cloud deployments, including the Cisco Managed and FedRAMP environments. Cisco added the Validator to its advisory on June 16.
Cisco says it is aware of limited exploitation of the flaw. There is no workaround, and the first fixed releases are:
Release train
First fixed release
Earlier than 20.9
Migrate to a fixed release
20.9
20.9.8.2
20.11
20.12.6.1
20.12
20.12.5.3 or 20.12.6.1
20.13
20.15.4.2
20.14
20.15.4.2
20.15
20.15.4.2
20.16
20.18.2.1
20.18
20.18.2.1
Releases earlier than 20.9 and the 20.11, 20.13, 20.14 and 20.16 trains have reached end of software maintenance.
Until they can upgrade, on-premises customers can limit access to ports 22 and 830 to the IP addresses of known controllers and other known systems. Cisco says this step worked in a test environment, but that customers should check how well it works in their own networks. Such guardrails are already in place for Cisco's hosted SD-WAN cloud deployments.
Blocking the ports does not remove malware already on a device.
Checking for KeyDrift
Talos advises organizations to install Cisco's fixes, follow Cisco's Catalyst SD-WAN hardening guide and watch for signs of post-compromise activity. Anyone who finds such signs should start incident response and can ask Cisco's Technical Assistance Center (TAC) for help.
That advice does not say whether upgrading removes KeyDrift from a device that was already compromised, or whether any keys should be replaced. Cisco's February remediation guide for this flaw warns that there could be "existing exploits which are still in place" from before an upgrade.
KeyDrift uses these files and locations, some given only by name:
File: the run script under etc/sv/sshd/, modified to start conf_sshd
Directory: /etc/sv/aaamgr/, a fake service on a compromised Validator
File: aaamgrd, the packed loader
File: conf_sshd, the loader script
File: rsshd, the injector
File: libdssl.so, PolyFlame
File: libcommon.so, LittleFilch
File: /tmp/system-vdaemon, the list of vdaemon process IDs
File: /var/tmp/vdaemon.bin, LittleFilch's encrypted records
File: /var/tmp/vdaemon.conf, LittleFilch's send settings, deleted after reading
Talos's report does not include a list of file hashes, IP addresses or domains for KeyDrift.
Talos released Snort rules on October 28 that look for inbound KeyDrift command-and-control connections: 67387 through 67416 for Snort 2, and 7:44 through 7:73 for Snort 3. Rules 65938 and 65958, already available, cover CVE-2026-20127 itself.
The October 28 rule update lists the Snort 2 rules as disabled by default, so users of the paid Snort Subscriber rule set must turn them on. The Snort 3 rules appear with no default state.
To check for exploitation of the flaw itself, Cisco says to look in /var/log/auth.log for Accepted publickey for vmanage-admin entries from unknown IP addresses. Before opening a TAC case, customers should run request admin-tech on each control component. The remediation guide also recommends rescanning those admin-tech files with the Check Bug Applicability feature on the Bug Search Tool page for bug CSCws52722.
For US federal civilian agencies, CISA's February 25 emergency directive sets out what to do if a root account compromise is found. They must report it to CISA, deploy fresh Manager, Controller and Validator instances from patched images, and move their edge routers to the new systems.
Found this article interesting? Follow us on Google News, Twitter and LinkedIn to read more exclusive content we post.
from The Hacker News https://ift.tt/cE0nzhd
via IFTTT
Twenty years ago this month, pfSense® software version 1.0 shipped. It started as a small fork of m0n0wall, built by a handful of people who wanted a better firewall than anything they could buy.
Today pfSense software protects and connects hundreds of thousands of networks in: homes, schools, hospitals, ISPs, public and private Cloud and in some of the largest companies in the world. Netgate® has been the largest contributor to the pfSense project over its entire lifetime, but none of this happened because of us alone. It happened because of you: your interest, your support, and your help making pfSense software relevant and useful to everyone who needs to connect securely to the Internet.
So for the twentieth anniversary, we’re looking ahead to where pfSense software needs to go and giving something back to everyone who has made it part of their network security stack. This is the first of several things we’ll be celebrating and announcing through 2027.
One pfSense
Starting with release 26.10, there is one edition of pfSense software. The separate pfSense CE and pfSense Plus editions are now one. Splitting pfSense software was the right call for its time. It let new users get up to speed on firewalls, VPNs, routing and general networking principles with zero-cost, fully featured production-ready software. It also let us fund the kernel and system engineering that pfSense software needed, the backend infrastructure, testing, 24/7 assistance, etc. and this is how features like in-kernel PPPoE, IPsec multi-buffer, the pf L2 filtering we upstreamed to FreeBSD, and ZFS boot environments with rollback got built. But two editions also meant two codebases, two release tracks, and too many conversations about which you should be running.
With release 26.10, everyone runs the same pfSense software:
The full feature set, free on any amd64 hardware. Every feature is included, from Snort 3 with Intel Hyperscan to ThreatGate with Zero Trust Egress (ZTE). It installs and reinstalls at no cost, with no account or registration required. On AWS, Azure and other public clouds, pfSense software remains available through our marketplace images.
The new GUI and the full API, for everyone. If you’ve built automation on a third-party API package, the built-in API is now the supported path. The documentation is on GitHub.
Security updates and bug fixes, free and online.
The air-gapped installer is back, so you can install pfSense software on networks that never touch the Internet.
This isn’t a promotion or an introductory offer. This is how pfSense software works from now on: the full feature set, with free security fixes.
Netgate keeps you secure, for free
Every pfSense install gets security fixes at no cost, whether it runs on our hardware or yours, and whether or not you ever pay us anything.
This matters more now than it did even a year ago. AI tools are finding bugs in widely used open-source code faster than ever, which means more “patch it now” days for everyone, not fewer. When a critical fix lands in FreeBSD, OpenSSL, or anything else pfSense software is built from, we want it on your firewall as soon as it’s ready, not at the next release.
Moving the base system to packages in 26.10 is what makes this possible. We can ship a fix for just the component that needs it, and you install it like any other update. Security fixes go to the current release, and since moving to a new release is free, every pfSense install can always be on a release that’s getting them.
This is also why we’re retiring the PHP-based GUI. We’ll remove it, with notice, once the new GUI covers everything it does. Much of the security work on pfSense software in recent years has gone into fixing bugs in old PHP code, and keeping up will only get harder as these bugs are found faster. The new GUI and API are built to remove this whole class of problem, not just patch it.
What you can pay for is convenience and help: online upgrades to new versions, fleet management at scale, and support. We don’t charge for security.
If you run pfSense CE software today
You get everything Plus users have had, on the hardware you already own. Nothing about your existing install stops working, and your configuration comes with you.
This includes:
OpenVPN® data channel offload (DCO) and Intel IPsec Multi-Buffer (IIMB) crypto, for much faster IPsec, OpenVPN and WireGuard® VPNs
Intel QuickAssist (QAT) crypto acceleration, on hardware that has it
ZFS boot environments, so you can roll back a bad upgrade or configuration change
Unicast CARP, for high availability where multicast doesn't work, including many hypervisors and clouds
Ethernet (layer 2) filtering rules
802.1X authentication bridging and VLAN 0 tagging on the WAN, so an ISP gateway that has to authenticate to the network can do so without sitting inline in your traffic. AT&T fiber is the common case.
Native NetFlow and IPFIX export, straight from firewall states
LDAP client certificates
The AWS VPC wizard, IPsec profile wizard and OpenVPN client import packages
We're also publishing the updated PHP and the FreeBSD source for 26.10 to GitHub.
Upgrading from pfSense CE software 2.9 to release 26.10 is free, and it happens in place, the same way you upgrade today.
From release 26.10 on, security fixes keep arriving online, for free. To move to a new version, reinstall from the installer at no cost. It saves and restores your configuration for you. Or, if you’d rather skip the reinstall, upgrade online in one step with a subscription.
The most widely used packages, including HAProxy, FRR and ACME, continue to work on release 26.10. pfBlockerNG continues to work in the existing GUI until that GUI is retired, and ThreatGate, now built in, is its successor for DNS-based blocking.
If you run pfSense Plus software today
Your existing subscription carries over, whether it’s TAC Lite, TAC Pro or TAC Enterprise, and you keep online upgrades. You don’t need to do anything.
If you bought Netgate hardware, nothing changes either: online upgrades to every new version are included for the life of the appliance, with no subscription required.
For partners and MSPs, one product means one thing to deploy, one thing to support, and no more questions about which edition a customer should run.
When
pfSense software version 26.10 will be released before the end of November. We're announcing it now because October is the pfSense project's birthday, and this is the change we wanted to mark it with.
Release notes, online and air-gapped installer images, and upgrade instructions will be on netgate.com on release day.
Thank you
pfSense software exists because people tested releases, answered forum questions at 2 a.m., wrote packages, filed good bug reports and told their friends. Twenty years of this is why it’s still here.
We’ll keep doing our part. Our software engineers, TAC engineers and SREs bring decades of experience across hardware, software, firmware and systems deployment, and they’re the people who take on the hardest problems. Netgate is the third-largest sponsor of FreeBSD by commit volume over both the last five and the last ten years, with several FreeBSD committers on staff. Much of what we build for pfSense software goes upstream, so everyone who builds on FreeBSD benefits. This includes the igc driver for Intel’s 2.5G NICs; layer 2 filtering in pf, used by the pfSense captive portal; dummynet support in pf for traffic shaping; and, just this month, an iflib fix that makes packet forwarding on FreeBSD much faster.
Here’s to the next twenty years of keeping your network secure.
Palo Alto Networks on Wednesday warned that threat actors are exploiting the recently patched PHP2Shell vulnerabilities against publicly-accessible management interfaces.
"Active exploitation has been observed targeting the Palo Alto Networks management interface exposed to the internet," the network security company said in an update to its advisory.
The vulnerabilities, tracked as CVE-2026-109618 and CVE-2026-109619 (CVSS scores: 9.2), allow attackers to achieve unauthenticated remote code execution on systems running affected versions of PHP. The issues were patched upstream by the PHP Foundation on October 21, 2026, in versions 8.5.12, 8.4.27, 8.3.36, and 8.2.35.
The development comes days after Israeli cybersecurity company Dream said it observed a suspected China-nexus threat actor weaponizing the flaws in conjunction with a local privilege escalation bug in the Linux kernel, tracked as Fragnesia (CVE-2026-46300, CVSS score: 7.8), to root 25 servers across the U.S., Japan, Taiwan, and South Korea.
Among those were three systems belonging to a U.S. government-affiliated environment.
"The affected devices run specific versions of a large vendor's firewall software," Dream noted. "The attacker then launched attacks against Active Directory. The recovered artifacts confirm credential extraction and directory enumeration."
Although Dream did not disclose the name of the affected firewall vendor, the timing of the advisory, combined with the fact that othernetwork security companies have not reported malicious exploitation against their products, suggests that these events may be related.
The Hacker News has contacted both Dream and Palo Alto Networks for comment, and we will update the story if we hear back.
The development has prompted the U.S. Cybersecurity and Infrastructure Security Agency (CISA) to add CVE-2026-46300 to its Known Exploited Vulnerabilities (KEV) catalog, requiring federal agencies to apply the fixes by October 31, 2026.
"This vulnerability can be chained with CVE-2026-109618 and CVE-2026-109619 to implant PHP web shells and run commands as root," CISA said.
Palo Alto Networks has also noted that no special configuration is required to be affected by this issue, adding the risk is highest on PAN-OS when access to the management interface is allowed from external IP addresses on the internet.
"This issue strictly affects the management web interface, which includes the HTTPS web UI and XML API service," it said. "It affects the dataplane interface only if a management profile is attached to it."
The following versions of PAN-OS are impacted by PHP2Shell -
PAN-OS 12.2
< 12.2.4-h1 (Fixed in >= 12.2.4-h1)
PAN-OS 12.1
< 12.1.4-h13 (Fixed in >= 12.1.4-h13) (ETA: 10/29)
< 12.1.7-h11 (Fixed in >= 12.1.7-h11)
< 12.1.10-h3 (Fixed in >= 12.1.10-h3) (ETA: 10/30)
PAN-OS 11.2
< 11.2.4-h23 (Fixed in >= 11.2.4-h23) (ETA: 10/30)
< 11.2.7-h23 (Fixed in >= 11.2.7-h23)
< 11.2.10-h16 (Fixed in >= 11.2.10-h16)
< 11.2.13-h4 (Fixed in >= 11.2.13-h4)
< 11.2.16-h1 (Fixed in >= 11.2.16-h1)
PAN-OS 11.1
< 11.1.4-h38 (Fixed in >= 11.1.4-h38)
< 11.1.6-h40 (Fixed in >= 11.1.6-h40)
< 11.1.7-h12 (Fixed in >= 11.1.7-h12) (ETA: 10/30)
< 11.1.10-h36 (Fixed in >= 11.1.10-h36)
< 11.1.13-h16 (Fixed in >= 11.1.13-h16)
< 11.1.16-h4 (Fixed in >= 11.1.16-h4)
PAN-OS 10.2
< 10.2.7-h39 (Fixed in >= 10.2.7-h39) (ETA: 10/30)
< 10.2.10-h42 (Fixed in >= 10.2.10-h42) (ETA: 10/29)
< 10.2.13-h27 (Fixed in >= 10.2.13-h27)
< 10.2.16-h12 (Fixed in >= 10.2.16-h12)
< 10.2.18-h13 (Fixed in >= 10.2.18-h13)
For PAN-OS versions where fix versions are not yet available, Palo Alto Networks has recommended the following mitigations -
Route incoming traffic for the MGT port through a DP port, e.g., enabling management profile on a DP interface for management access.
Replace the Certificate for Inbound Traffic Management.
Decrypt inbound traffic to the management interface so the firewall can inspect it.
Enable threat prevention on the inbound traffic to management services.
"Customers with Frontier Virtual Patching (ATP Plus) on PAN-OS 12.2.4 and later versions received advance coverage, released via Threat ID 543004, which was released at 10:21 PM PT on October 20," it said.
"The security risk posed by this issue on PAN-OS and Panorama is minimized by restricting access to the management interface to only trusted internal IP addresses according to our recommended best practice deployment guidelines."
from The Hacker News https://ift.tt/M7INilg
via IFTTT
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.
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:
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.
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:
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:
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.
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.
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
from Cisco Talos Blog https://ift.tt/LkrowJT
via IFTTT
