When You Find Signs of a Prior Compromise

Every tester eventually finds something they did not put there. It is rarer than the stories suggest and more disorienting than you expect, because everything about the engagement you are running becomes the wrong activity at once.

Stop, and do not investigate

The instinct is to confirm before raising it, which usually means looking at the artefact more closely. That instinct is right for a vulnerability and wrong here.

You are not engaged to do incident response, you are almost certainly not insured for it, and every action you take on a potentially compromised system alters the thing somebody else may need to examine. Reading a file changes an access time. Downloading a sample may move an attacker's tooling onto your own machine, which becomes a different conversation entirely.

Record what you have already done, in detail and honestly, including anything you did before you realised what you were looking at. That record is the first thing a responder will want and the first thing you will be asked about.

Notify immediately, above the usual contact

This is not a finding, and the normal escalation path may be wrong. Your day-to-day contact may be a developer or an IT manager, and this needs somebody who can convene a response.

It also needs a moment's thought about the channel. If the compromise could involve their mail or chat, notifying through it is telling the intruder they have been noticed. A phone call to a person you have already spoken to during the engagement is the safe default, and this is one of several reasons to have collected a second contact at the start.

Say plainly what you saw, what you did, that you have stopped, and that you are not in a position to say whether it is active or historic. Resist estimating age or attribution. Both are difficult with the right tooling and irresponsible without it.

Be clear about what you are not

The client will frequently ask you to keep going. It is a natural response: you are already there, you have context, and finding an incident responder takes time they do not feel they have.

Be straightforward about the boundary. Testing and response are different disciplines with different evidentiary standards, and the value you can add is mostly at the edges: what you saw and where, what you can tell them about the weakness that likely enabled it, and staying available to whoever picks it up. Taking on the response itself, without the mandate or the insurance, helps nobody and can compromise the investigation.

If your firm does offer response, this is still a scope change and should be papered as one, with a fresh authority to act. The paperwork takes an hour and its absence takes years.

What happens to the engagement

Somebody has to decide whether testing continues, and it is the client's decision made with the responder's advice. Continuing on unaffected scope is often sensible. Continuing on the affected system rarely is.

Whatever is decided, the report has to reflect what actually happened. A test that was suspended on day two and resumed on day six covered less than five days, and the summary should say so, along with what was excluded and why. A report that quietly presents partial coverage as complete is the version that causes a problem later.

Afterwards, write down what you learned

Firms that have been through this once are noticeably calmer the second time, and the difference is almost entirely that somebody wrote it down. Who was called, how long it took to reach a decision maker, what the client asked for that you had to decline, what you wished you had captured before you stopped.

Put the outcome into your rules of engagement template as well. The contact you wished you had, the channel you wished you had agreed, the sentence about response being out of scope that you wished had already been signed.

Telling a real indicator from an artefact

Before any of this, be reasonably confident you are looking at what you think you are. Estates are untidy, and several things look like compromise from a distance.

• Another firm's testing artefacts, left from an engagement six months ago that nobody cleaned up. Test files with a consultancy's name in them are common.
• Your own artefacts from earlier in the week, especially on a team engagement where somebody else placed them.
• Administrative tooling that looks hostile out of context: a legitimate remote access agent, a backup process reaching an unfamiliar address.
• Development leftovers, such as a debug endpoint that reads like a backdoor because it effectively is one, placed deliberately by somebody who has forgotten it.

None of that means you should suppress it. It means the notification should describe what you observed rather than what you concluded: "there is a file at this path that accepts commands, we did not place it, we do not know its origin" is accurate and stays accurate if it turns out to belong to the client's own tooling.

Your own position afterwards

There is an uncomfortable second-order problem. You were on a compromised network with your tooling, your credentials for their environment, and possibly a VPN into it.

Treat that seriously rather than hoping. Rotate whatever you used for that engagement. Review what your testing machine touched and consider whether it should be rebuilt rather than cleaned. Where you hold client data from the engagement, that data was gathered from an environment somebody else may also have been inside, which is worth knowing when you decide how long to keep it.

This is also the argument for testing from disposable environments as a matter of routine. It costs a little each engagement and it removes an entire category of question on the day it matters.