Remus Stealer: 63,770 Detections in Eight Days

A family nobody is writing about

Search for Remus stealer and you will find very little. It has no disruption announcement, no naming controversy, no vendor blog series tracking its evolution.

Our telemetry recorded 63,770 Remus detections in eight days.

That gap between attention and volume is the reason for this report. Defenders reasonably calibrate their concern to what gets published, and what gets published follows narrative rather than prevalence. A family with no story attached can be substantial and largely invisible at the same time.

Eight days of global detections

• 10 September — 1,319
• 11 September — 3,482
• 12 September — 311
• 13 September — 24,905
• 14 September — 1,096
• 15 September — 29,096
• 16 September — 2,341
• 17 September — 1,220

Total: 63,770.

Six days sit between 311 and 3,482, with a median near 1,270. Two days do not.

The 13th ran roughly twenty times the median. The 15th, twenty-three times. Between them they account for 54,001 detections — 84.7% of the entire period.

The spread inside a single week is severe: 311 detections on the 12th, 29,096 three days later. A ninety-fold swing.

The average describes none of these days

Divide 63,770 by eight and you get roughly 8,000 detections a day. No day came close to that number.

The mean sits above every baseline day and far below both spikes. It characterises nothing that actually happened.

This matters because threat intelligence volume is conventionally reported as a period total or a daily average, and both representations erase exactly the property that has operational consequences. The total tells you how much. It does not tell you that almost all of it landed at once.

What caused the two spikes

We do not know, and we would rather say so than guess convincingly.

Two explanations fit the data.

Infection activity may genuinely have surged on those dates — a distribution push landing at scale within a short window.

Or, more plausibly in our judgement, a bulk collection of Remus output was published to a monitored source on each day. Infostealer output is routinely aggregated and released in archives rather than posted as it is captured, and one release can contain months of collection. On this reading the spikes mark publication, not infection.

These figures cannot separate the two. The conclusion below holds either way.

Why arrival shape beats arrival volume

If data trickled in steadily, your checking interval would control only staleness. Check weekly, be at most a week behind. Simple relationship, easy to reason about.

Concentrated arrival destroys that relationship.

When 85% of a week lands on two days, the question stops being how current is my view and becomes did I happen to look after the day that mattered.

Under the publication explanation, a credential taken from a machine in March may not appear anywhere observable until it is bundled into a collection released in September. Until that moment there is nothing to find. The exposure is real and entirely invisible. The moment it publishes, it is available to everyone who buys the archive.

The window where detection still helps opens at publication and closes when someone uses the credential. Scheduled checking assumes that window is spread evenly across the calendar. It is not.

What to do with this

Calibrate to volume, not to coverage. Remus barely features in public reporting and sits near the top of our telemetry. Silence in vendor blogs is not evidence of absence in your environment.

Treat continuous monitoring as a response to the data shape, not a product preference. A fixed schedule has no relationship to when exposure becomes observable, and can sample entirely inside quiet periods.

Read a clean result narrowly. It means nothing was present in monitored sources at that moment. It says nothing about what has not yet been published.

Revoke sessions, not just passwords. Stealer log output carries session cookies alongside credentials, and a password reset does not end an existing session. See session cookie theft.

Distrust age as a filter. Where publication trails extraction, a credential surfacing today may have been taken months ago and still work if it was never rotated. It will also persist in derivative form through combolists long after the original collection stops circulating.

Do not wait on attribution to act. Remediation for infostealer compromise — rotate credentials, revoke sessions, clean the host — does not vary by family. Identifying which malware was responsible is useful for intelligence purposes and changes nothing about the response.

Method and limitations

Detections are drawn from SphereTI's monitoring infrastructure, which ingests infostealer output distributed through criminal marketplaces, messaging channels and forums.

Unit of measurement. Each detection is one record in our pipeline. We claim no mapping from records to compromised hosts, individuals or organisations, and none can be derived from these figures.

Eight days. This establishes that concentration occurred in this period. It does not establish how often bursts happen, their typical size, or whether the pattern holds. Several more periods would be needed before treating burst arrival as characterised.

Cause not established for the two high-volume days, as stated above.

Single family. These figures describe Remus only and should not be generalised to infostealer activity overall.

Collection scope. These figures reflect material reaching the sources we monitor. Data moving privately or through channels we do not cover is unrepresented, and may behave differently.

Disclosure

SphereTI sells threat intelligence services, including the monitoring infrastructure behind these figures. The argument that continuous monitoring fits this arrival pattern better than periodic checking is one we have a commercial interest in. Weigh it against the data, not our authority.