Salesloft Intrusion Began in March and Stayed Dormant Until August

Analysis of the Salesloft incident filed at 25-0818 describes a sequence: a GitHub compromise between March and June 2025, a dormant period, then active exploitation from 8 to 18 August.

The ten days of theft are what everyone remembers. The five months before them are the more instructive part.

An intruder who acts immediately risks colliding with active investigation of whatever produced the initial access. An intruder who waits benefits from log rotation, staff turnover, and the closure of whatever ticket the original anomaly generated.

By August, the evidence that would have connected the token theft to the March repository compromise had largely aged out — the retention problem this desk filed at 26-0620.

Dwell time is conventionally measured from first access to detection, and this desk records it in every case card. On that measure this incident ran roughly five months.

But the harm occupied ten days at the end. A single dwell figure conflates a long quiet period with a short intense one, and an organisation optimising to reduce mean dwell time may be optimising against the wrong phase.

Retention long enough to reconstruct backwards from a discovered theft — which means keeping authentication and access logs longer than the dwell time you expect, not longer than the dwell time you have previously seen. The corpus records at 26-0203 how closely a long quiet intrusion resembles legitimate account usage, and at 25-0807 how much turns on somebody noticing early.

A source repository compromise that looks contained in March is not contained if the credentials taken from it are still valid in August. Rotation after a repository incident is the control that would have severed this chain, and it is routinely scoped too narrowly.