25 techniques observed across 4 entries, derived from entry metadata and body evidence, never asserted without a published entry behind it · pinned to MITRE ATT&CK v19.2 · compare on the matrix · Navigator layer (JSON)
Initial Access TA0001
T1189Drive-by Compromise×2
Adversaries may gain access to a system through a user visiting a website over the normal course of browsing. Multiple ways of delivering exploit code to a browser exist (i.e., Drive-by Target), including:
T1059.003Command and Scripting Interpreter: Windows Command Shell×1
Adversaries may abuse the Windows command shell for execution. The Windows command shell (cmd) is the primary command prompt on Windows systems. The Windows command prompt can be used to control almost any aspect of a system, with various permission levels required for different subsets of commands. The command prompt can be invoked remotely via Remote Services such as SSH.
T1059.007Command and Scripting Interpreter: JavaScript×1
Adversaries may abuse various implementations of JavaScript for execution. JavaScript (JS) is a platform-independent scripting language (compiled just-in-time at runtime) commonly associated with scripts in webpages, though JS can be executed in runtime environments outside the browser.
Adversaries may exploit software vulnerabilities in client applications to execute code. Vulnerabilities can exist in software due to unsecure coding practices that can lead to unanticipated behavior. Adversaries can take advantage of certain vulnerabilities through targeted exploitation for the purpose of arbitrary code execution. Oftentimes the most valuable exploits to an offensive toolkit are those that can be used to obtain code execution on a remote system because they can be used to gain access to that system. Users will expect to see files related to the applications they commonly used to do work, so they are a useful target for exploit research and development because of their high utility.
An adversary may rely upon a user opening a malicious file in order to gain execution. Users may be subjected to social engineering to get them to open a file that will lead to code execution. This user action will typically be observed as follow-on behavior from Spearphishing Attachment. Adversaries may use several types of files that require a user to execute them, including .doc, .pdf, .xls, .rtf, .scr, .exe, .lnk, .pif, .cpl, .reg, and .iso.
Adversaries may abuse internet browser extensions to establish persistent access to victim systems. Browser extensions or plugins are small programs that can add functionality to and customize aspects of internet browsers. They can be installed directly via a local file or custom URL or through a browser's app store - an official online platform where users can browse, install, and manage extensions for a specific web browser. Extensions generally inherit the web browser's permissions previously granted.
T1547.001Boot or Logon Autostart Execution: Registry Run Keys / Startup Folder×1
Adversaries may achieve persistence by adding a program to a startup folder or referencing it with a Registry run key. Adding an entry to the "run keys" in the Registry or startup folder will cause the program referenced to be executed when a user logs in. These programs will be executed under the context of the user and will have the account's associated permissions level.
Adversaries may modify pluggable authentication modules (PAM) to access user credentials or enable otherwise unwarranted access to accounts. PAM is a modular system of configuration files, libraries, and executable files which guide authentication for many services. The most common authentication module is <code>pam_unix.so</code>, which retrieves, sets, and verifies account authentication information in <code>/etc/passwd</code> and <code>/etc/shadow</code>.
Adversaries may inject code into processes in order to evade process-based defenses as well as possibly elevate privileges. Process injection is a method of executing arbitrary code in the address space of a separate live process. Running code in the context of another process may allow access to the process's memory, system/network resources, and possibly elevated privileges. Execution via process injection may also evade detection from security products since the execution is masked under a legitimate process.
T1547.001Boot or Logon Autostart Execution: Registry Run Keys / Startup Folder×1
Adversaries may achieve persistence by adding a program to a startup folder or referencing it with a Registry run key. Adding an entry to the "run keys" in the Registry or startup folder will cause the program referenced to be executed when a user logs in. These programs will be executed under the context of the user and will have the account's associated permissions level.
Adversaries may use rootkits to hide the presence of programs, files, network connections, services, drivers, and other system components. Rootkits are programs that hide the existence of malware by intercepting/hooking and modifying operating system API calls that supply system information.
Adversaries may inject code into processes in order to evade process-based defenses as well as possibly elevate privileges. Process injection is a method of executing arbitrary code in the address space of a separate live process. Running code in the context of another process may allow access to the process's memory, system/network resources, and possibly elevated privileges. Execution via process injection may also evade detection from security products since the execution is masked under a legitimate process.
Adversaries may use Obfuscated Files or Information to hide artifacts of an intrusion from analysis. They may require separate mechanisms to decode or deobfuscate that information depending on how they intend to use it. Methods for doing that include built-in functionality of malware or by using utilities present on the system.
Adversaries may use hidden windows to conceal malicious activity from the plain sight of users. In some cases, windows that would typically be displayed when an application carries out an operation can be hidden. This may be utilized by system administrators to avoid disrupting user work environments when carrying out administrative tasks.
Adversaries may modify pluggable authentication modules (PAM) to access user credentials or enable otherwise unwarranted access to accounts. PAM is a modular system of configuration files, libraries, and executable files which guide authentication for many services. The most common authentication module is <code>pam_unix.so</code>, which retrieves, sets, and verifies account authentication information in <code>/etc/passwd</code> and <code>/etc/shadow</code>.
Adversaries may disable, degrade, or tamper with security tools or applications (e.g., endpoint detection and response (EDR) tools, intrusion detection systems (IDS), antivirus, logging agents, sensors, etc.) to impair or reduce visibility of defensive capabilities. This may include stopping specific services, killing processes, modifying or deleting tool configuration files and Registry keys, or preventing tools from updating. This may also include impairing defenses more broadly by disrupting preventative, detection, and response mechanisms across host, network, and cloud environments.
Adversaries may install code on externally facing portals, such as a VPN login page, to capture and transmit credentials of users who attempt to log into the service. For example, a compromised login page may log provided user credentials before logging the user in to the service.
Adversaries may target multi-factor authentication (MFA) mechanisms, (i.e., smart cards, token generators, etc.) to gain access to credentials that can be used to access systems, services, and network resources. Use of MFA is recommended and provides a higher level of security than usernames and passwords alone, but organizations should be aware of techniques that could be used to intercept and bypass these security mechanisms.
An adversary may steal web application or service session cookies and use them to gain access to web applications or Internet services as an authenticated user without needing credentials. Web applications and services often use session cookies as an authentication token after a user has authenticated to a website.
Adversaries may search for private key certificate files on compromised systems for insecurely stored credentials. Private cryptographic keys and certificates are used for authentication, encryption/decryption, and digital signatures. Common key and certificate file extensions include: .key, .pgp, .gpg, .ppk., .p12, .pem, .pfx, .cer, .p7b, .asc.
T1555.003Credentials from Password Stores: Credentials from Web Browsers×2
Adversaries may acquire credentials from web browsers by reading files specific to the target browser. Web browsers commonly save credentials such as website usernames and passwords so that they do not need to be entered manually in the future. Web browsers typically store the credentials in an encrypted format within a credential store; however, methods exist to extract plaintext credentials from web browsers.
Adversaries may modify pluggable authentication modules (PAM) to access user credentials or enable otherwise unwarranted access to accounts. PAM is a modular system of configuration files, libraries, and executable files which guide authentication for many services. The most common authentication module is <code>pam_unix.so</code>, which retrieves, sets, and verifies account authentication information in <code>/etc/passwd</code> and <code>/etc/shadow</code>.
Adversaries may forge credential materials that can be used to gain access to web applications or Internet services. Web applications and services (hosted in cloud SaaS environments or on-premise servers) often use session cookies, tokens, or other materials to authenticate and authorize user access.
Adversaries may install code on externally facing portals, such as a VPN login page, to capture and transmit credentials of users who attempt to log into the service. For example, a compromised login page may log provided user credentials before logging the user in to the service.
Adversaries may attempt to take screen captures of the desktop to gather information over the course of an operation. Screen capturing functionality may be included as a feature of a remote access tool used in post-compromise operations. Taking a screenshot is also typically possible through native utilities or API calls, such as <code>CopyFromScreen</code>, <code>xwd</code>, or <code>screencapture</code>.
Adversaries may take advantage of security vulnerabilities and inherent functionality in browser software to change content, modify user-behaviors, and intercept information as part of various browser session hijacking techniques.
Adversaries may use a connection proxy to direct network traffic between systems or act as an intermediary for network communications to a command and control server to avoid direct connections to their infrastructure. Many tools exist that enable traffic redirection through proxies or port redirection, including HTRAN, ZXProxy, and ZXPortMap. Adversaries use these types of proxies to manage command and control communications, reduce the number of simultaneous outbound network connections, provide resiliency in the face of connection loss, or to ride over existing trusted communications paths between victims to avoid suspicion. Adversaries may chain together multiple proxies to further disguise the source of malicious traffic.
Adversaries may use an existing, legitimate external Web service to host information that points to additional command and control (C2) infrastructure. Adversaries may post content, known as a dead drop resolver, on Web services with embedded (and often obfuscated/encoded) domains or IP addresses. Once infected, victims will reach out to and be redirected by these resolvers.
Adversaries may use an existing, legitimate external Web service as a means for sending commands to and receiving output from a compromised system over the Web service channel. Compromised systems may leverage popular websites and social media to host command and control (C2) instructions. Those infected systems can then send the output from those commands back over that Web service channel. The return traffic may occur in a variety of ways, depending on the Web service being utilized. For example, the return traffic may take the form of the compromised system posting a comment on a forum, issuing a pull request to development project, updating a document hosted on a Web service, or by sending a Tweet.
deep-diveUnit 42 shows three ways endpoint malware defeats Google synced passkeys without elevation, unlock or user interaction, and one of them cannot be revoked
Google's Chrome 152.0.7977.82/.83 Stable release (2026-09-03) fixes 12 security bugs, headed by CVE-2026-85046, a type-confusion flaw in the V8 JavaScript engine (CWE-843) that a remote attacker triggers via a crafted HTML page, reaching arbitrary code execution inside the Chrome renderer sandbox (Google Chrome Releases, 2026-09-03). Google's own release notes state plainly that "Google is aware that an exploit for CVE-2026-85046 exists in the wild," and, per its standard restricted-disclosure practice, withholds further technical detail until most users have updated. The bug (Chromium issue 542403045) was reported by external researcher Salvatore Gulizia ("Serotav") on 2026-08-04. CISA's ADP Vulnrichment program scores it CVSS 3.1 8.8 (AV:N/AC:L/PR:N/UI:R/S:U/C:H/I:H/A:H), network vector, low complexity, no privileges, but requiring the victim to open the malicious page; neither Google nor MITRE, the CVE's assigning CNA, publishes its own numeric score.
The type confusion is a sandbox-escape primitive, not a full chain by itself: code that runs from it stays confined to the renderer sandbox, so full host compromise would need a second bug to escape it, or a target Chromium-based application running with reduced sandboxing, no source describes such chaining for this CVE as of publication. The remaining 11 fixes in the same release (9 High- and 2 Medium-severity issues across V8, Compositing, WebGL, Skia, DevTools, CacheStorage, CrashReporting, Network, Mobile and the Transactions Platform, most found by Google's own security team) carry no exploitation report from Google.
Google is aware that an exploit for CVE-2026-85046 exists in the wild.
Type confusion in V8 in Google Chrome prior to 152.0.7977.82 allowed a remote attacker to execute arbitrary code inside the sandbox via a crafted HTML page.
Symantec's Threat Hunter Team has published the results of a months-long investigation into Jewelbug, a China-based hack-for-hire group that runs two missions from one set of hands: espionage against government ministries and militaries across the Middle East, Southeast Asia and South Asia, and a for-profit cryptocurrency-fraud business aimed at Chinese-speaking victims. Both are administered from a single control panel called XG-Web, a browser-centric remote-access and information-stealing framework built as a React panel over a Node.js backend with a MySQL database that doubles as the rendezvous point for victim implants; its developers describe it in their own documentation as a "penetration-testing platform", while its internal function names include browser hijacking, data theft and man-in-the-middle attack (Symantec, 2026-08-13). Symantec assesses with high confidence that the fraud and search-engine-optimisation arm is run by the sole legal representative of a registered Changsha company, on the basis of government-issued identity documents, a business licence and a signed authorisation letter recovered from the operators, and considers it most likely that the SEO business supplied access, infrastructure and delivery to the espionage operation rather than one person performing both roles (Symantec, 2026-08-13).
The access pattern is the finding. In its largest espionage operation, Jewelbug did not attack ministries individually. It compromised the shared web-hosting platform run by a Middle Eastern state telecommunications provider and national network-services agency, obtained write access to the common webmail installation, and added one script tag, planting a watering hole on every government tenant on that platform at once, in a single campaign that spanned more than 15 tenants (Symantec, 2026-08-13). Symantec infers the tag sat in the shared template rather than being delivered per user because the hook fired on the login page and on every mailbox view. The group also hooked the hosting provider's own administrators to harvest the credentials that granted that write access, which closes the loop: the platform operator's identity was the key to every tenant behind it.
The chain that follows is short and entirely conventional in its parts, which is what makes it worth mapping. When a ministry staff member logged in, the injected script opened a WebSocket to command-and-control, completed a handshake and reported in; a cookie module exfiltrated the page's cookies, and a labelling module read the username straight out of the webmail interface and tagged the new victim with their government email address. Only then did the operators push a lure module, which checked that the address ended in one of nine targeted government domains, that the account was not already compromised, and that the host was Windows, before overlaying a fake Adobe Flash update prompt (Symantec, 2026-08-13). That server-side qualification step is a defensive problem in itself; the malicious behaviour a visiting analyst or a sandbox sees is a cookie read and a WebSocket, because the payload stage never fires for a visitor who fails the filter.
Clicking the prompt downloaded the Antino backdoor, delivered as a fake Adobe Flash or Adobe installer and using the Microsoft Graph API as its command-and-control channel so its traffic sits inside legitimate Microsoft cloud services. Antino also side-loaded the "PDF Viewer" extension into the victim's browser profile, dropped a native-messaging helper and wrote the registry value that enabled it (Symantec, 2026-08-13). The extension is the group's primary implant and requested, in Symantec's words, effectively every dangerous permission the browser exposes, cookies, scripting, debugger access, web-request interception, download monitoring and native messaging across all sites. A background service worker gave the operator a full bridge into the browser API: any Chrome or Firefox function invocable by name, arbitrary JavaScript injected into any page, credentials harvested by hooking login forms, the full cookie jar exfiltrated, live cookie-change events subscribed to so new session tokens are stolen in near real time, plus history, bookmarks, screenshots, clipboard and intercepted traffic. A clipboard module able to swap a copied cryptocurrency address for the attacker's was present and active on victims, but Symantec records that no address-replacement rules were deployed, so the swap was not used during the observed period.
The sandbox escape is the part defenders should take away. To reach the host, the extension talked to a Windows helper registered as a native-messaging host under the misleading name com.microsoft.runedge, which ran operator commands through the Windows command interpreter and returned output to the panel; Antino wrote the enabling registry value under the current user's own hive (Symantec, 2026-08-13). Native messaging is a documented, legitimate browser feature (it is how password managers and document tools talk to their desktop components) and that is precisely why it works here. For at least one victim the bridge carried authenticated traffic to an internal virtualisation-management interface, so browser access became reach into the network behind it.
The group's toolset extends past the browser. Symantec counts 37 builds of a Rust implant the developers call ClientKing, reaching servers and network devices rather than browsers, supporting five command-and-control transports including a custom DNS tunnel, and offering an interactive shell, SOCKS pivoting and the ability to load kernel modules directly from memory; a companion toolkit adds a kernel-module rootkit and a malicious authentication module hooked into su and sudo to steal credentials, across x86-64 servers, ARM64 devices and consumer routers (Symantec, 2026-08-13). For payload delivery the backend created public Google Documents, wrote an obfuscated payload into the body and had implants fetch and execute it, which resolves to Google-owned infrastructure that reputation filtering is unlikely to block, and the group disguised its command-and-control hostnames as typosquats of common web resources such as font services. A scheduled job checked the group's own domains against a public multi-scanner every twelve hours so operators could rotate away from anything flagged.
Scale, in the group's own bookkeeping: the victim database holds more than one million implant check-in rows, more than 580,000 stolen browser cookies, several thousand captured credentials and more than 2,300 exfiltrated email bodies (Symantec, 2026-08-13). Symantec also notes builds configured to beacon through the internal corporate proxy of a major US aerospace and industrial manufacturer, so the tooling is not confined to government estates.
Triage: a native-messaging host registered under HKCU\SOFTWARE\<browser>\NativeMessagingHosts\<reverse-domain-name> is normal on its own, legitimate password managers, document viewers and enterprise agents use this exact mechanism. Three discriminators separate this from that baseline, and they derive from the mechanics the source describes rather than from any indicator: a host name asserting a Microsoft identity while being written per-user under HKCU by a downloaded executable, where a genuine Microsoft browser component arrives through a signed machine-wide installer; the command interpreter appearing with a native-messaging host executable as its parent, a process-lineage pair that legitimate browser-helper traffic does not produce; and an extension whose manifest requests native messaging together with debugger access, web-request interception and all-sites cookie access, a permission combination a document reader has no use for. The extension side-loads into the browser profile rather than arriving from a store, so an extension inventory built only from store IDs will not see it.
Rather than breach each ministry separately, Jewelbug compromised the shared web-hosting platform run by the state telecommunications provider and national network-services agency, obtaining write access to the common webmail installation, and added a single script tag.
A single campaign spanned more than 15 government webmail tenants, with the hook firing on the login page and every mailbox view, indicating it sat in the shared template rather than being delivered per user.
To escape the browser sandbox, the extension talked to a Windows helper registered as a native-messaging host under the misleading name com.microsoft.runedge, which ran operator commands through the Windows command interpreter and returned the output to the panel.
Masquerading as a document reader, it requested effectively every dangerous permission the browser exposes: cookies, scripting, debugger access, web request interception, download monitoring, and native messaging across all sites.
Passkeys remove the shared secret, which removes phishing, replay and credential stuffing from the attacker's toolkit. Unit 42's research, published 2026-08-03, is about what replaces them: three attacks that leave the cryptography intact and instead abuse the trust a cloud-synced passkey system places in the client device, its onboarding flow and its recovery flow. The scope is specific (Google Password Manager in Chrome on Windows on machines with a TPM) and the precondition is unremarkable: malware already running as the logged-in user, with no elevation (Unit 42, 2026-08-03).
Reconnaissance. Chrome stores synced passkeys as proto-encoded WebauthnCredentialSpecifics records in its sync database under %LocalAppData%\Google\Chrome\User Data\<Profile>\Sync Data\LevelDB, and Unit 42 states plainly that "Accessing these records does not require elevated privileges." Reading them tells an attacker which services the victim protects with passkeys, the associated usernames and credential identifiers, and the encrypted private key; a target list before any authentication is attempted.
Pass-ta-key, forging the assertion. Chrome proves device possession to Google's cloud authenticator with a hardware-backed identity key, and the way Chrome handles that key is what the attack turns on. Chrome creates the TPM key without a name so it is never persisted inside the TPM, then exports it as an NCRYPT_OPAQUE_KEY_BLOB (encrypted by a TPM-resident key) and stores the result as wrapped_identity_private_key in the passkey_enclave_state file. Malware reads that blob from disk or Chrome's memory and re-imports it through the ordinary Windows CNG interfaces (NCryptOpenStorageProvider, NCryptImportKey, NCryptSignHash) to sign whatever it likes on the same physical TPM. Unit 42's own framing of the consequence: "Unlike a legitimate user flow that requires user interaction and device unlock, this attack shows how malware can obtain the required signature silently, without user consent, biometrics, device unlock or elevated privileges." The attacker opens a WebSocket handshake with the cloud authenticator, signs the handshake hash together with the assertion request using the stolen identity key, receives a valid assertion, and replays it to the relying party.
The single bit that decides whether that works. The cloud authenticator issues a valid assertion whether the request was signed with the identity key or with the user-verification key; the only difference is the User Verified flag in the authenticator data, which is 0 for the identity key. A relying party that requires user verification and checks the flag rejects the forged assertion; a passkey-protected GitHub login did. A relying party that sets userVerification to required but never inspects the returned flag accepts it, and multi-factor authentication collapses to possession of one device key: "In our testing, we identified relying parties that accepted authentication because they did not properly validate the UV flag." Unit 42 demonstrated this against eBay, which has since fixed its validation. Because many relying parties set the parameter to preferred rather than required for device-compatibility reasons, the population this variant works against is not small.
Silver Pass-ta-key, becoming the verification key. Rather than trying to reach the UV key, the attacker deletes it. Nothing protects the passkey_enclave_state file from removal (or the attacker issues a device/forget command with the identity key it already controls), which forces Chrome to re-onboard the device on next passkey use. Windows onboarding completes only on the second passkey use, so the device sits in a uv_key_pending state in between, Chrome defers creating the UV key to avoid stacking a Windows Hello prompt on top of the Google Password Manager recovery-PIN prompt. In that window the attacker generates its own key pair and sends device/add_uv_key with its public key, and it is accepted: "The cloud authenticator does not validate the attestation of newly registered UV keys to verify whether they originate from secure hardware." From then on the attacker mints assertions with the UV bit set, from its own infrastructure, without the victim's device being online, reusable access that satisfies even correctly implemented relying parties.
Golden Pass-ta-key, taking the master key. Synced passkey private keys are encrypted under a 32-byte security domain secret (SDS) that is supposed to stay inside the cloud authenticator, with only a wrapped copy on the client. Unit 42 found it in plaintext in Chrome's own FIDO device log, and while Google removed it from logging after the report, the underlying flow is unchanged: "Although Google removed this secret from Chrome's logging output following our report, the SDS is still sent to the client and remains accessible in Chrome's process memory." So the attacker forces a fresh onboarding using the Silver technique, watches for passkey_enclave_state to be recreated, dumps Chrome's process memory at that moment, extracts the SDS, and decrypts every record in the sync database. The result is exportable passkey private keys, usable from anywhere, for every current and future passkey on the account, and there is no remediation: "In Google's current implementation, there is no way to rotate or revoke the SDS, meaning all current and future synced passkeys remain protected by the same master key." Re-enrolling the device evicts the Silver variant; nothing evicts this one.
Triage: the telemetry classes are process and file access, not network. In process and module telemetry, the discriminator for the assertion-forging step is process identity; Chrome itself calling CNG to sign with the device identity key is the legitimate flow that happens on every real passkey login, whereas a non-browser process importing an NCRYPT_OPAQUE_KEY_BLOB and calling NCryptSignHash after reading passkey_enclave_state or the sync LevelDB is not a flow the product produces. For the Silver and Golden variants the sequence is the signal rather than any single event: deletion or modification of passkey_enclave_state, followed by a device re-onboarding the user did not initiate, followed by cross-process memory reads of chrome.exe. Legitimate re-enrolment happens, but it is user-initiated and rare, and it is not preceded by something removing the local state file. Hardening beyond the relying-party check follows Unit 42's own list: restrict access to Chrome's sync database and local passkey state files to the browser process through platform access controls, and monitor for repeated or unexplained re-triggering of onboarding and recovery flows.
Unlike a legitimate user flow that requires user interaction and device unlock, this attack shows how malware can obtain the required signature silently, without user consent, biometrics, device unlock or elevated privileges.
The cloud authenticator does not validate the attestation of newly registered UV keys to verify whether they originate from secure hardware.
In Google’s current implementation, there is no way to rotate or revoke the SDS, meaning all current and future synced passkeys remain protected by the same master key.
In our testing, we identified relying parties that accepted authentication because they did not properly validate the UV flag.