# Autodoxer

> An autodoxer is malware or tooling that automatically turns stolen personal data into a correlated victim profile, often ranked by what the victim is worth.

Also known as: autodoxing, auto-doxxing, automated doxxing, AI-assisted victim profiling, VOLTA-AUTODOXER

Source: https://socket.dev/glossary/autodoxer

Last updated: 2026-11-09

An autodoxer is software that automatically collects personal data about a victim, correlates it into a single profile, and often scores what that person is worth to an attacker. In the VOLTA-AUTODOXER infostealer, stolen sessions fetch receipts and order history, and a language model writes the appraisal. Autodoxing is also called automated doxxing.

"Autodoxer" is an emerging term, not an established malware category. Most current use traces to October 31, 2026, when [Cisco Talos analyzed](https://blog.talosintelligence.com/appraisal-by-ai-model-driven-victim-prioritization-in-the-volta-infostealer/) a Windows [infostealer](https://socket.dev/glossary/infostealer) that called itself VOLTA-AUTODOXER. The mechanism that matters is the second pass. An autodoxer uses the sessions it stole as a search interface into the victim's life. A stolen Gmail token does more than log in. It answers "where does this person live?" by searching the inbox for delivery receipts.

Our position: the language model is the least important part of an autodoxer. The dangerous input is a live session, and the dangerous output is a triage decision. Stolen credentials used to wait, sometimes for years, for a human to decide whether a victim was worth the effort. An autodoxer makes that decision at infection time, for every victim. Defenders should stop assuming a stolen log will sit unread, and should treat every long-lived session as an open query interface to the person behind it.

## What is an autodoxer?

An autodoxer is a tool that runs three steps without a human: collect, correlate, and appraise. Collection gathers raw personal data, usually stolen credentials, cookies, files, and messages. Correlation joins the fragments into one identity, for example linking a delivery receipt, a geolocation, and a work email into a name, an address, and an employer. Appraisal decides what that identity is worth and how to use it.

None of the three steps requires AI. Correlation with regular expressions and lookup tables is decades old, and the demo later in this article links a developer to an employer with about 60 lines of Python and no model. What a language model adds is cheap reading of messy text. ETH Zurich researchers found that large language models inferred attributes such as location, income, and sex from Reddit posts with up to 85% top-1 accuracy, at about 100 times lower cost than humans ([Staab et al., arXiv 2310.07298](https://arxiv.org/abs/2310.07298)).

Autodoxing differs from doxxing in who sees the result. Doxxing publishes a person's private information to expose, harass, or intimidate them. An autodoxer keeps the profile private and hands it to its operator. That profile can feed doxxing later. It can also feed extortion, targeted [phishing](https://socket.dev/glossary/phishing), account takeover, or a decision to sell access to the victim's employer.

The generic concept is also broader than the named sample. VOLTA-AUTODOXER is one Windows infostealer that Talos analyzed from a single sample, first seen on October 11, 2026. "Autodoxer" describes any tool that automates the profile, whether it is bundled into an infostealer, run on an operator's server after the theft, or improvised from the victim's own AI tools.

## How VOLTA-AUTODOXER builds a dossier

VOLTA-AUTODOXER is a self-deleting 64-bit Windows infostealer with an optional stage that sends its findings to a language model. Ryan Fetterman of Cisco Talos published the analysis. The pipeline has five stages, and only the fourth needs a model.

> VOLTA-AUTODOXER from theft to appraisal, reconstructed from Cisco Talos's October 31, 2026 analysis. Stage 4 is the only step that needs a model, and VOLTA skips it when no API key is present.
>
> VOLTA-AUTODOXER pipeline: collect, enrich, assemble, appraise, deliver

Stage 1 collects browser passwords, cookies, and saved cards from Chromium browsers, Firefox, and Thunderbird. It gets past Chrome's App-Bound Encryption by launching Chrome with `--headless`. It also takes Outlook profiles, Slack workspaces, Microsoft OAuth tokens, Steam, Battle.net, Discord, Telegram, and Roblox sessions, SSH keys, gcloud and VPN config files, crypto wallets (opened with an embedded password cracker), saved Wi-Fi passwords, screenshots, and document authorship metadata. The haul is packed into `volta_log.zip`.

Stage 2 spends those sessions. With the victim's Gmail token, VOLTA searches for receipts from Amazon, DoorDash, Uber Eats, Grubhub, Walmart, and PayPal, which Talos says it reviews "to establish a confirmed home address." It pulls Uber Eats and DoorDash order history, enriches the Discord profile, and prices the Roblox inventory through a live Rolimons lookup. If enrichment finds anything, the results go into `volta_doxnet.zip`.

Stage 3 writes `Identity_Report.txt`. It holds geolocation and home address, employer and employer domain, inferred birth year, card last four digits, Slack workspaces, document authorship metadata, iPhone backup indicators, and a live Roblox valuation.

Stage 4 serializes that report as JSON and posts it, with a system prompt, to OpenRouter's chat completions endpoint at temperature 0.2. The default model is `anthropic/claude-opus-4.6`. If a reply contains phrases like "I can't" or "I'm not able," VOLTA retries with `moonshotai/kimi-k2` and then `google/gemini-2.5-flash`. The prompt casts the model as "a forensic intelligence analyst drafting a target assessment." Required sections include "WHAT THEY'RE WORTH" and "THEIR OPSEC." The reply is saved as `AI_Analysis.txt` and packed into `volta_dox.zip`. With no API key present, VOLTA skips this stage.

Stage 5 delivers the results through a Telegram channel set at build time. The executable may delete itself. The file `%APPDATA%\volta_debug.txt` records what was collected and whether the model call succeeded, and Talos advises preserving it.

Three design choices in VOLTA-AUTODOXER matter to defenders. First, it has no [command-and-control](https://socket.dev/glossary/command-and-control-c2) server of its own. Talos states plainly: "There is no actor-owned infrastructure." Every endpoint belongs to a third party, so there is no attacker domain to block. Second, VOLTA is built from a template with six slots, including the Telegram channel and API keys, filled in for each build. The slot values are encrypted with a key derived from SHA-256 of two constants in the same binary, so anyone who reverses a sample recovers the operator's model API key. Third, the model chain expects refusals and routes around them.

These are the [indicators of compromise](https://socket.dev/glossary/indicators-of-compromise-ioc) and behaviors Talos published for the one known sample:

```text
SHA-256     57ef4242666d78c50df145b34023df564f0fad38812d6a580e66433d427e2279
Filenames   9BY0tjwOc3ut.exe, yLP9m5J3i2Aw.exe
Type        PE32+ x86-64, PE timestamp 2026-08-17 20:35
First seen  2026-10-11 12:46 UTC
Endpoint    https://openrouter[.]ai/api/v1/chat/completions
Models      anthropic/claude-opus-4.6 > moonshotai/kimi-k2 > google/gemini-2.5-flash
Files       Identity_Report.txt  AI_Analysis.txt  volta_log.zip
            volta_dox.zip  volta_doxnet.zip  %APPDATA%\volta_debug.txt
Behavior    chrome.exe --headless started by a non-browser parent process
```

As of November 2026, Talos has not reported how VOLTA reaches victims. We have found no evidence that it spreads through npm, PyPI, or any other package registry.

## How does an autodoxer differ from an infostealer?

An autodoxer differs from an infostealer in its output: an infostealer delivers a log of secrets, and an autodoxer delivers a judgment about a person. The infostealer answers "what can I take from this machine?" The autodoxer answers "who is this, where do they live, who employs them, and what are they worth?"

That difference matters because the infostealer economy has always had a reading problem. A stealer log is thousands of lines of cookies and passwords, and someone has to decide which victims are worth working. In the 2024 Snowflake data thefts, [Mandiant found](https://cloud.google.com/blog/topics/threat-intelligence/unc5537-snowflake-data-theft-extortion) that at least 79.7% of the accounts the attacker used had prior credential exposure. The earliest infostealer infection tied to a used credential dated to November 2020. Those credentials waited more than three years for someone to use them. An autodoxer does the reading at infection time.

| Dimension | Infostealer | Autodoxer | Doxxing |
| --- | --- | --- | --- |
| Input | The victim's machine | Stolen data and live sessions | Any personal data, often public |
| Action | Copy secrets | Query, correlate, rank | Publish |
| Output | Log of credentials, cookies, and files | Profile of a person, often scored | A public post |
| Who sees it | Operator or log buyer | Operator | Everyone |
| Main harm | Account takeover | Targeting: who to extort, phish, or sell | Harassment and physical risk |

The verdict: an infostealer is how an autodoxer usually gets its input, and doxxing is one use of an autodoxer's output. Treat a suspected autodoxer infection as an infostealer infection plus an identity exposure. Rotate every secret the machine held, and also assume the operator now knows the person's address, employer, and habits.

## Where the model runs decides what defenders can see

Language models have entered the collection-to-appraisal pipeline in at least four documented cases since August 2025, and they sit in three different places. Where the model runs decides whether a defender has anything to detect.

| Case | Where the model runs | What the model does | What a defender can see |
| --- | --- | --- | --- |
| Nx compromise, Aug 2025 | Victim's machine, through the victim's own claude, gemini, and q CLIs | Lists files that look like wallets and secrets | AI CLIs launched by an npm package; /tmp/inventory.txt |
| VOLTA-AUTODOXER, Oct 2026 | Victim's machine, calling a third-party model API | Writes the appraisal | Model API traffic from an unsigned executable; headless Chrome |
| Bee Stealer 2.1, Sep 2026 | Operator's service, after the log arrives (inferred from artifacts) | Writes ProfileEn.txt and ProfileRu.txt | Nothing beyond the original theft |
| Dolphin X, Jul 2026 | Unknown | Risk score, ranking, daily summary | Unknown |

In the [Nx compromise](https://socket.dev/blog/nx-packages-compromised), malicious versions of the Nx build system published to npm on August 26, 2025 prompted locally installed AI coding CLIs to "enumerate the filesystem" and write an inventory of interesting files. The malware then read those files and uploaded them to public repositories named `s1ngularity-repository` in the victims' own GitHub accounts, more than 1,000 of them. Nx used the model for collection, not appraisal, but it showed that a victim's AI tools are part of their [agentic AI attack surface](https://socket.dev/glossary/agentic-ai-security). Socket's AI scanner flagged those releases shortly after publication. That kind of package analysis only helps when the collection code ships in a package, and nothing yet links VOLTA to one.

For Bee Stealer, [BlackFog found](https://www.blackfog.com/bee-stealer-uses-ai-to-profile-victims/) no evidence of profiling inside the Windows payload and concluded that "the available artifacts point to processing after the log reaches the service." For Dolphin X, [Varonis analyzed](https://www.varonis.com/blog/dolphin-x-stealer) the operator panel rather than a running sample and could not say where its "AI behavioral profiler" runs.

The verdict: victim-side models are the easy case, because they leave process and network traces, and the Nx case shows that collection code in a package can be caught before it runs. Operator-side profiling leaves nothing on the victim's machine beyond the theft itself, and it needs no change to the payload. Plan as if every stolen log is read in full.

Model providers are a weak checkpoint. A provider can refuse a request, and it can revoke an API key recovered from a sample. VOLTA's fallback chain shows the operator already plans for refusals. Talos put it this way: "As AI integration in malware matures, refusal resilience may become a standard design requirement." An operator can also run an open-weight model on its own hardware, where nobody can refuse. We treat provider refusals as friction, not as a control defenders can plan around.

## Why developer machines make rich dossiers

Developer machines make rich dossiers because their config files already join the person to the employer. VOLTA's dossier has a field for employer and employer domain, and on a developer laptop no model is needed to fill it.

The script below prints the identity links a developer's home directory exposes to any code running as that user. It prints hostnames, domains, and account names. It never prints a secret.

```python
#!/usr/bin/env python3
"""Print the identity links a dev machine exposes to code running as you.
Prints hostnames, domains, and account names only. Never prints a secret."""
import configparser, re, subprocess
from pathlib import Path

H = Path.home()
links = []

def add(source, kind, value):
    links.append((source, kind, value))

# Git identity: the commit email usually names the employer.
try:
    email = subprocess.run(["git", "config", "--global", "user.email"],
                           capture_output=True, text=True).stdout.strip()
    if email:
        add("~/.gitconfig", "work email domain", email.split("@")[-1])
except FileNotFoundError:
    pass

# SSH: HostName entries map internal infrastructure.
ssh = H / ".ssh/config"
if ssh.exists():
    for m in re.finditer(r"^\s*HostName\s+(\S+)", ssh.read_text(), re.M | re.I):
        add("~/.ssh/config", "ssh host", m.group(1))

# AWS: SSO start URLs name the organization's identity portal.
aws = H / ".aws/config"
if aws.exists():
    cp = configparser.ConfigParser(); cp.read(aws)
    for sec in cp.sections():
        url = cp[sec].get("sso_start_url")
        if url:
            add("~/.aws/config", "aws sso portal", re.sub(r"^https?://", "", url))

# gcloud: the active account is an email address.
gc = H / ".config/gcloud/configurations/config_default"
if gc.exists():
    cp = configparser.ConfigParser(); cp.read(gc)
    acct = cp.get("core", "account", fallback="")
    if acct:
        add("gcloud config", "cloud account domain", acct.split("@")[-1])

# npm: a private registry URL names the company that runs it.
npmrc = H / ".npmrc"
if npmrc.exists():
    for m in re.finditer(r"registry=https?://([^/\s]+)", npmrc.read_text()):
        if m.group(1) != "registry.npmjs.org":
            add("~/.npmrc", "private registry", m.group(1))

# Kubernetes: cluster API servers.
kube = H / ".kube/config"
if kube.exists():
    for m in re.finditer(r"server:\s*https?://([^:/\s]+)", kube.read_text()):
        add("~/.kube/config", "k8s api server", m.group(1))

for src, kind, val in links:
    print(f"{src:<16} {kind:<22} {val}")
print(f"\n{len(links)} identity links, 0 secrets printed")
```

We ran it against a test home directory seeded with six common config files for a fictional company:

```console
$ HOME=./testhome python3 dossier_inputs.py
~/.gitconfig     work email domain      acme-corp.example
~/.ssh/config    ssh host               bastion.prod.acme-corp.example
~/.ssh/config    ssh host               github.com
~/.aws/config    aws sso portal         acme-corp.awsapps.com/start
gcloud config    cloud account domain   acme-corp.example
~/.npmrc         private registry       npm.acme-corp.example
~/.kube/config   k8s api server         k8s.prod.acme-corp.example

7 identity links, 0 secrets printed
```

Six of the seven links point at the same company. The git email gives the employer domain. The SSH config names a production bastion host. The AWS SSO URL names the identity portal an attacker would phish next. The private registry and the Kubernetes API server name infrastructure that stolen tokens may open. The test `.npmrc` also held an auth token. Our script skipped it, and an infostealer would not. Short-lived, narrowly scoped credentials, covered in our [secret management](https://socket.dev/glossary/secret-management) entry, limit what that token is worth once copied.

This is why the appraisal stage matters to organizations, not just individuals. Talos's report does not show how VOLTA weighs an employer link. An operator who sells access would still want a victim with an employer domain, Slack workspaces, cloud configs, and an SSH key at the top of the list. The appraisal is what turns an infection on a personal laptop into initial access to an employer.

## How can you protect against automated doxxing?

You protect against automated doxxing by cutting off the sessions an autodoxer queries and by shrinking what one infected machine reveals. The model stage is the hardest place to intervene. Each control below covers part of the path and misses another part.

Revoke sessions, not just passwords. An autodoxer's second pass runs on live tokens. Signing out every session for email, Microsoft, Discord, and delivery accounts stops further enrichment. It does not recall data already pulled. A stolen session cookie proves that a login, including any [multi-factor authentication](https://socket.dev/glossary/multi-factor-authentication-mfa) step, already happened, so MFA does not stop the replay.

Keep credentials in hardware-backed stores, as Talos recommends. Passkeys and hardware security keys keep the private key off disk, so there is nothing to copy. They do not protect session cookies issued after a login.

Detect the collection technique. Talos recommends restricting which processes can launch Chrome with `--headless` and alerting on unexpected launches, which it says "would block the ABE decryption path entirely." That stops VOLTA's route into Chrome's cookie store. Other infostealer families use code injection into Chrome instead.

Watch for model API calls from unexpected processes. Traffic to openrouter.ai or a model provider from an unsigned executable in a user's temp directory is a strong signal. On developer machines the signal is noisy, because editors, agents, and CLIs call these APIs all day. Operator-side profiling sends no such traffic.

Separate identities across machines or browser profiles. Keep work single sign-on, cloud CLIs, and SSH keys away from the profile used for shopping, food delivery, and gaming. One infection then exposes half a dossier instead of the join between a home address and an employer. The cost is convenience, and few personal-device policies enforce it.

Treat any crypto wallet whose seed phrase was stored in plaintext as fully compromised. Talos advises moving funds to a new wallet generated on an air-gapped device.

[Incident response](https://socket.dev/glossary/incident-response-ir) for a suspected autodoxer starts like any infostealer case and adds one step. Preserve `%APPDATA%\volta_debug.txt` before cleanup, then revoke and rotate from a clean machine. The added step is telling the person that their address, employer, and spending habits may sit in an operator's file. The follow-on attack targets a person, through a tailored phishing message or extortion, not the machine.

## What changes when every log gets read

Talos framed the open question well: "The axis of AI improvement here is not speed or scale but effort displacement." The appraisal VOLTA buys from a model is work that operators used to skip for most victims. The scarce resource in the stealer-log market was never stolen data. It was analyst attention. When that attention costs one API call, every victim gets the analyst treatment, including the ones nobody would have bothered to read.
