# The new infostealer sorts its victims for you, and researchers are the top of the list
*A subscription malware kit advertises an "AI Profiler" that ranks stolen machines by value — and the credentials it prizes most are the ones sitting on developer and research laptops.*
The old economics of credential theft worked in your favor, even if nobody framed it that way. A compromised university laptop landed in a pile of tens of thousands of stolen logs. Most of that pile was never read. Volume was the criminal's problem, and your obscurity was your protection.
A malware kit called Dolphin X is built to solve that problem.
## What happened
On July 22, Varonis Threat Labs published research on Dolphin X, a subscription infostealer and remote access trojan advertised on a cybercrime forum by a seller using the alias Kontraktnik. It is marketed as an all-in-one kit with 329 advertised features, driven from a single panel. Nothing compiles on the buyer's machine; the operator sets options in a desktop client and the vendor's server builds the binary.
The feature drawing attention sits in the panel's surveillance tab. The seller describes it as an "AI behavioral profiler with app usage tracking, risk score, and daily summary." In practice it watches which applications a victim uses, which domains they browse and what software is installed, assigns a risk score, and emails the operator a ranked list each morning. Varonis compares it to an automated warehouse sorter — it does not break in, it decides who gets robbed first.
Two caveats should shape how much weight you give this. Varonis analyzed the operator panel and its network traffic, not a live sample on an infected machine, so the agent's capabilities are as advertised rather than independently observed. And nobody has established what does the scoring — the behavior is equally consistent with heuristic rules wearing an AI label.
What is not in question is the collection scope. The credential looter targets more than 300 applications: nine browsers with DPAPI decryption, ten password managers, over 100 wallet extensions, and — the part that should interest you — more than 30 cloud CLI tools, SSH keys, and `.env` files.
There is also no victim data. No infection count, no named campaign, no confirmed compromise, and no mention anywhere in the reporting of universities or government. This is a marketplace and capability story, not an incident story, and it is worth saying so plainly.
## Why it matters for Texas institutions
The reason to pay attention is the target list, not the body count.
Consider what sits on a graduate researcher's laptop: `~/.ssh/id_rsa` with no passphrase, an `aws` or `gcloud` token issued during a project and never rotated, a `.env` file holding database credentials for a lab server, a session cookie for the cloud console. That machine is not an endpoint in any meaningful sense — it is an unmanaged privileged access point into HPC clusters, grant-funded cloud accounts and research data stores. Varonis puts it directly: "On a developer's machine, .env files and SSH directories often contain over-scoped, long-lived credentials that can provide access to cloud consoles, build pipelines, and production data."
Higher education has structurally more of this exposure than a bank does — decentralized IT, thousands of transient users with legitimate developer tooling, personal machines touching institutional cloud, and credentials scoped to a project rather than 90 days.
Ranking turns that from a background risk into a targeted one. A triage system flagging "password manager plus cloud CLI plus SSH keys" as high value pushes your research and sysadmin machines to the front of the queue instead of losing them in the noise. And because cloud tokens and session cookies survive a password reset, "we have MFA" is an incomplete answer.
## What your institution should do
**Get long-lived credentials off local disk.** This is Varonis's own first recommendation and the one that removes the prize: "Infostealers are designed to grab everything in one pass, so anything stored locally should be treated as potentially exposed." Move research and developer environments to short-lived federated credentials — SSO or OIDC-based CLI auth, workforce identity — and retire static access keys.
**Treat every `.env` on a laptop as already leaked.** Run secrets scanning across repositories and endpoints, push secrets into a managed vault, and make that the path of least resistance for researchers rather than an obstacle.
**Passphrase-protect or eliminate SSH keys** in favor of certificate-based SSH with short lifetimes, and hardware-backed keys where feasible.
**Make token and session revocation a first-class incident response step,** not an afterthought behind the password reset.
**Detect on behavior, not hashes.** The kit's build mutation is off by default, so hashes still catch lazy operators but paying subscribers evade them. Better signals: `explorer.exe` running under a non-default desktop, cross-process memory reads against browser and password-manager processes, and unexpected reads of `~/.ssh`, `.env` and cloud CLI config directories. Note the published indicators, including `thedolphinx[.]top`, are operator-side — blocking them protects nothing on a victim endpoint.
## RSOC is here to help
If you want help building detections around credential-theft behavior, or reviewing how research computing in your environment handles cloud tokens and SSH keys, the Regional Security Operations Center can assist. RSOC provides monitoring, threat intelligence and incident response support to Texas higher education institutions and state agencies: [rsoc.utexas.edu](https://rsoc.utexas.edu)