Security Worked Example — The Account That Should Have Been Closed
A worked example of an intrusion that used no exploit — how a contractor's credential stayed live for five months, what the response revealed about session revocation, and the four controls that made it impossible to repeat.
This is an illustrative example. The organisation, timeline and details are invented. The intrusion path — a valid credential that outlived its purpose — is the most ordinary one there is, which is why it is worth walking through.
The situation#
A 250-person professional services firm. On a Tuesday morning, a routine review of data access logs showed something that did not fit: an account had exported the full client contact table at 02:14 on Sunday. The account belonged to a contractor whose engagement had ended in November — five months earlier.
No exploit was involved at any point. No vulnerability was used. The credential was valid, the permissions were correct for the role it still held, and every system behaved exactly as configured.
The timeline#
| When | What |
|---|---|
| November | Contractor engagement ends. Laptop returned. Account not disabled. |
| November – March | Account dormant. No monitoring on dormancy. |
| Early March | Contractor's personal email compromised in an unrelated breach elsewhere |
| Mid March | The reused password grants access. MFA prompt is approved by the contractor, who assumes it is their own session. |
| Late March | Access every few days. Read-only. Nothing alerts. |
| Sunday 02:14 | Full client contact table exported |
| Tuesday 09:20 | Found during a manual log review |
Four months of undetected access, and it was found by a person reading logs, not by a control.
What the response revealed#
The response is the part worth studying, because the plan did not survive contact with the systems.
Step one was to reset the password. Done at 09:31.
The session stayed live. The active token remained valid for its full remaining lifetime, which was another six hours. The team assumed a password reset ended access. It did not, and nothing in the incident plan mentioned sessions. Twenty-five minutes passed before someone tested it and found the gap.
Nobody could establish what else the account had reached. Access logs were retained for 30 days. The account had been active for four months. The first six weeks of the intrusion are permanently unknowable, and the disclosure to affected clients had to say so.
The account did not appear on any leavers list. The contractor had been engaged through a procurement process, not through HR onboarding, so the offboarding process that would have caught an employee never applied. Five other accounts were found in the same position during the review that followed.
What was actually wrong#
One cause, visible from four angles.
Access was granted well and removed badly. Onboarding was careful: MFA enforced, roles assigned, approvals recorded. Removal depended on somebody remembering, and nobody owned the remembering for contractors.
The compromise of a personal email account elsewhere was outside the firm's control. The five months of standing access was entirely within it.
The four changes#
Deactivation triggered by the contract end date. The date already existed in the procurement system; nothing consumed it. Now the account is disabled automatically on that date, and extending an engagement means extending the date — which is a renewal, not a memory test.
Dormancy alerting. Any account with no authentication for 45 days is flagged for review and disabled at 60. This alone would have closed the account in January, two months before the credential was compromised.
Session revocation on credential change. Resetting a password now terminates every active session for that identity. This was a one-line configuration change that nobody had made because nobody had tested the assumption underneath it.
Alerting on bulk data access. Any identity reading an unusual volume, or reading something it has never read before, raises an alert. A full table export at 02:14 by a dormant contractor account is not a subtle signal — it simply had nothing watching for it.
Log retention was also extended from 30 days to 13 months, which is what makes the next incident investigable.
What was deliberately not done#
No new security tooling was purchased. Every change above used systems already in place. The failure was not a missing product; it was that the end of access was a thing someone had to remember, in an organisation where nobody had been given that job.
MFA was not changed. It was already phishing-resistant for staff, and it did not fail here — the contractor approved a prompt believing it was their own session. The lesson is about the account existing, not about the authentication method.
The result#
| Before | After | |
|---|---|---|
| Dormant accounts with production access | 6 | 0 |
| Time to detect an intrusion of this type | 4 months | Under 48 hours |
| Access ends by | Someone remembering | Contract end date |
| Sessions ended by a password reset | No | Yes |
| Log retention | 30 days | 13 months |
What was learned#
The most likely intrusion uses a valid credential. It requires no exploit and it defeats most defences, because every system involved is working correctly.
Test what your incident plan assumes. The plan said reset the password. It did not say revoke the session, and the difference was six hours of continued access during the response itself.
Turn removal into renewal. Every change above converts "remember to remove" into "have to renew". That is the direction that survives a busy quarter.
Retention determines what you can ever know. Thirty days of logs meant the disclosure had to include the sentence no organisation wants to write: we cannot establish what was accessed before February.