Lesson 1 of 1 in Persistence

Why They Come Back

The moment an attacker is in, their first worry is losing it. Persistence is how they insure against a reboot or a reset — and it is why "we removed the malware" is so often not the end of the story.

3 min read

Not yet reviewed

Wrenlearner

Once they are in, they are in. Why is there a separate stage for staying?

Magpieadversary

Because getting in cost me something, and I do not want to pay it twice. Before I do anything noisy, I make three quiet ways back — an account, a scheduled job, a token. Reboot the machine; I am still here.

Rookmentor

Which is why cleaning up an intrusion is not the same as deleting a file. If you miss one of those ways back, you have not removed the attacker. You have annoyed them.

Legal

Installing a backdoor, creating a hidden account, or leaving any mechanism to regain access to a system you do not own is unauthorised access and, in most places, a distinct and serious offence in its own right. Study persistence to find what an attacker left on your systems — never to leave something on someone else's.

Insurance against being kicked out

Persistence is the attacker buying insurance. Each mechanism answers one question — "if I lose this session, how do I get another?" — and the good ones look exactly like ordinary administration, because the best place to hide a way back in is among the things a system is supposed to have.

1A new account            looks like a normal user, until you count them
2A scheduled task / cron   runs their code on a timer, forever
3A stolen credential       no malware at all — they just log in
4An OAuth / API token      survives the password change you were proud of
5A mail rule               quietly forwards or hides, no login required

Line 3The quietest of all. There is nothing to find on disk, because there is no malware — the attacker holds a valid key and simply returns.
Line 4This is why resetting a password is not enough after a breach. Tokens and app passwords issued earlier keep working until they are revoked.

A company finds and removes the attacker's malware, resets the one password they know was stolen, and declares the incident closed. Why might the attacker still be inside an hour later?

Making the way back not work

The defence is to assume, after any real intrusion, that a way back exists and to go looking for it rather than for the malware alone: rotate and revoke credentials and tokens wholesale rather than one at a time, put a second factor on everything so a stolen password cannot silently re-enter, and know what "normal" looks like — how many admin accounts, which scheduled tasks — so a new one stands out.

Cleaning up

Delete the malware you found.
Reset the one password you know leaked.
Call it closed.

Evicting

Rotate every credential and token.
Hunt for new accounts, tasks, mail rules.
Assume a way back until you have proven none.

The difference is an assumption. Cleaning up assumes you found everything; evicting assumes you did not, and keeps looking. Only one of them actually removes a patient attacker.

One thing you can do this week: in your important accounts — email, and any cloud service — find the page that lists active sessions, connected apps, and app passwords. Revoke anything you do not recognise or no longer use. You are practising eviction on a small scale, before you ever need it at a large one.