When Someone Clicked: The First Hour After a Phishing Click

Monday, 08:52, at Bellweather Logistics. Nadia has been on the desk for forty minutes when Keiran, a dispatcher in the yard office, phones rather than e-mails, which is the first sign. "I think I've done something stupid. I got a shared document from Lorna about the new routes, signed in to open it, and it just went to a blank page. Then Lorna messaged me asking why I'd sent her a document." Lorna is the operations manager. She did not send Keiran anything. Keiran typed his password into a page that was not Bellweather's, about twenty minutes ago. Whoever built that page now has it.

What Nadia does in the next hour decides whether this is a ticket or an incident. She does not ask Keiran how he could have fallen for it. She does not open the document link to see. She does not write a careful note first. She resets his password and has the mail administrator sign his account out of everything. Then she checks his mailbox for rules he did not make, and tells the IT manager, in that order. She has done all four by 09:30. Then she talks to Keiran properly, and then she writes it down. The order is the whole article.

The first hour after a phishing click is the window in which the desk can make a stolen password useless and end a stolen sign-in before anyone uses them. It is called the first hour because that is roughly how long the desk has before the chance is gone. A phishing click, for this article, is any of four things: a link opened, credentials typed into a page that was not ours, an attachment opened or a file run, or a reply sent and a request acted on. Each has its own first hour, and the four share a shape. This article is part of our Phishing Reports & Security Tickets series. It is the one to have open when someone says "I think I've done something stupid".

It covers the four kinds of click and the order of operations. Then come the reset, done as a security reset, and ending the session in plain words. Next come the second factor, the device check, and telling the security function. After that come the kind conversation and the note that records facts without blame. Last come a short war story and the clicked runbook to copy.

Four Kinds of Click

"I clicked it" covers four different events, and the first thing the desk does is find out which one, because the exposure is different for each. A link opened and the page closed, with nothing typed, is the mildest. The page may have tried to do something to the browser, and the security function will want to know, but there is no stolen password. Credentials typed into a sign-in page that was not ours is the common one and the urgent one. Someone now holds a working password and possibly a working sign-in. An attachment opened or a downloaded file run means the device itself may now be doing things for someone else. In that case, the device is the problem before the account is. A reply sent, a payment made or details handed over means the harm has partly happened and the first hour is about stopping the rest.

Keiran's was the second kind, which is the one this article spends most of its time on, because it is the one a small desk sees most and can fix most completely. The third kind, the opened attachment, is where the desk's part is shortest and the security function's longest. The fourth is where the desk's first phone call is to finance rather than to anyone in IT.

The Order of Operations

Contain the account, then the device, then the message, then the paperwork, and do the conversation in the gaps. The reason for the order is speed on the other side. A password typed into a phishing page can be in use within minutes, by an automated process rather than a person. The first things that process does are quiet. It reads the mailbox, sets up a rule, and sends a copy of the same message to everyone in the contacts list. Every minute between the click and the reset is a minute of that. The device, by contrast, usually takes longer to matter, and the message itself is already read. So the reset comes before everything, including the full conversation with Keiran. He is told why: "I'm going to reset your password first, right now, and then we'll talk properly."

The temptation is to understand before acting: to read the message, look at the page, work out what it was, and then decide. Resist it. A reset and a sign-out-everywhere cost the person ten minutes and cost the desk nothing it cannot undo. If the message turns out to have been harmless, the person has a new password and the desk has a short ticket, and nobody has been hurt by caution. If it turns out to have been real and the desk spent twenty minutes understanding it first, the twenty minutes were the attacker's. Act, then understand. It is the only order that works.

The Reset, Done as a Security Reset

The reset after a click is the same reset the desk does every day, with two differences. It is done first, and it is done as a security event rather than a convenience. The identity check still applies. The person on the phone saying "I clicked" is almost always who they say they are. The verification standard the desk already uses for a reset applies anyway. The simple reason is that a standard with exceptions is not a standard. That standard, and why it has no exceptions, is in Verifying Identity Before a Reset. The mechanics of a reset that does not leave the new password in an e-mail are in The Reset Done Properly. This article does not repeat either; it only says that neither is skipped because the situation is urgent. Urgent is when standards earn their keep.

Two additions belong to the security version. The first is the question about reuse, asked kindly: "Do you use that password anywhere else, work or personal?" If the answer is yes, those places need the same password changed, today, by the person. In that case, the desk says so plainly without handling the personal ones. A password stolen from a fake document page is tried against every service the attacker can think of within the hour. The person's personal mailbox is top of the list. The second addition is that the reset is recorded as a security reset on the ticket, with the time. That way, the security function can see exactly when the old password stopped working and judge what might have happened before that.

One thing the reset does not do is end a sign-in that is already in progress. This is the point that most of this article turns on. A new password stops the next sign-in. It does not always stop the current one.

Ending the Session, in Plain Words

When a person signs in to the mail service or the directory, the service hands their browser or app a session. This is a small token that says "this person has already proved who they are, let them in without asking again". Think of the wristband at a venue. You show your ticket once at the door, you get a wristband, and for the rest of the night nobody asks to see the ticket. Changing the password is like cancelling the ticket. It does nothing about the wristband. Someone who signed in with Keiran's stolen password before Nadia reset it may still hold a working wristband. On many services it stays valid for hours or days unless someone cuts it off.

Cutting it off is session revocation. The directory or the mail service has a way, usually available to an administrator and often to the user, to sign an account out of everything, everywhere, at once. Every token is cancelled and every device and browser has to sign in again with the new password, which the attacker does not have. On most desks this is the mail administrator's or the directory administrator's action rather than the help desk's. The first hour needs that person reachable. Write their name on the runbook. Agree in advance that a call from the desk saying "clicked, reset done, please revoke" is acted on immediately without a ticket first. The ticket follows. The revoke does not wait for it.

Two checks ride along with the revoke, and they are defender's checks that any administrator can do. The first is the mailbox rules. Look for rules the person did not create, particularly ones that forward mail outside the organisation or move messages out of sight. Setting one up is the usual first move after a sign-in and it keeps working after a reset. Remove any you find and record what they did. The second is the recent sign-in history, which most services keep. A sign-in from somewhere the person was not, at a time they were not working, confirms that the password was used and tells the security function where to look. The desk reads the history and reports it; the desk does not go hunting through it. That is the line again, contain and hand over.

Sign-out-everywhere has a cost the person feels immediately: every phone, laptop and browser they use asks them to sign in again, and some apps do so grumpily. Tell them it is coming and that it is the point. It is a strange feature of this work that the moment a desk has done the most to protect somebody is also the moment that person has the most prompts on their phone.

The Second Factor

If the organisation uses a second factor, a code or a prompt on the person's phone in addition to the password, the stolen password alone may not have been enough to sign in. That is good news that must not become complacency. Some phishing pages are built to capture the code as well, in real time, by passing it straight through to the real service while the person watches a convincing copy. So the first hour is the same, reset and revoke, whether or not a second factor exists. The second factor changes the odds; it does not change the runbook.

What it adds is one more check: the list of devices or methods registered for the person's second factor. An attacker who got in may have added their own phone or method so that they can get back in after the reset. Have the administrator review the registered methods with the person, remove anything they do not recognise, and record it. Re-enrolment, when the person's own method needs setting up again afterwards, follows the organisation's normal process, which lives with the directory rather than with the desk. The desk's part is to make sure the review happened and to write down that it did.

The Device Check

When an attachment was opened or a file was run, the device moves to the front of the queue. That is because the device may now be acting for someone else and the account is only one of the things it can reach. The desk's first action is to take it off the network: disconnect the wireless, unplug the cable, and leave it like that. The desk's second action is to find out, before doing anything else, what the security function wants done with the machine. Some want it left powered on and untouched so that what is running can be examined. Others want it shut down and collected. Ask yours now, before the first incident, and write the answer on the runbook. At 09:15 with a worried dispatcher on the phone is not the time to discover that you disagree.

The person needs a device to work on. The loan laptop from the spares cupboard is the answer, set up with the new password and nothing copied across from the old machine. The practice of keeping a loaner ready for exactly this is in The Loaner and Spares Strategy, and the clicked case is one of its best arguments. The suspect machine is labelled, with the ticket number and the time it was isolated, and handed to the security function or kept untouched until they say. The desk does not run its own investigation on it, however curious it is and however well it knows the operating system's built-in tools. A desk that "just has a look" has altered the one thing the security function needed intact.

Where the click was only a link, with nothing downloaded, nothing installed and no prompt asking for permission, the device usually stays in service, and the security function's view decides. The desk notes what the page showed, if the person can describe it, and whether anything was asked for. "A blank page" and "a sign-in page" are both useful answers, and both go on the ticket.

Telling the Security Function

The security function is told within the hour, every time, including when the desk is fairly sure the click was harmless. That includes when the person is senior and would prefer that nobody knew. Telling them is not an accusation and it is not an escalation of blame; it is the handoff of the part of the work the desk cannot do. What they receive is a short set of facts: who, when they clicked, what kind of click, and what the message was with the original attached. They also receive what the desk has done and at what times, what the sign-in history and the mail rules showed, and whether a device has been isolated. The clock times matter most. The security function's first question is always "when", and a ticket that answers it in the first line has done half their job.

By phone first, if a phone is faster, then the ticket. On a desk of two, where the security function is the IT manager and a contracted firm, this is a thirty-second call followed by a linked ticket. On a larger organisation it may be a form or a security mailbox of its own, which is also fine, as long as a person reads it within the hour. The desk asks, at the end of the call, whether there is anything more they want the desk to do. The answer is often "send a note to everyone who got the message" or "ask the person these two questions". The desk is the right pair of hands for both.

Where the account sent messages out before the revoke, to colleagues, customers or suppliers, the security function decides whether and how those recipients are told. The desk does not send that notice on its own, because its wording has consequences the desk cannot see. The desk can draft it, and often should.

The Kind Conversation

Once the account is contained, talk to the person properly. Start with the sentence that is both true and the most useful thing you will say all day: "You did the right thing telling us straight away. The people who get hurt by these are the ones who don't say." Then explain what has been done and why, in plain words. The password is new, every signed-in device has been signed out, and the mailbox has been checked. The security team has been told so that they can check the rest. Then explain what the person needs to do: sign back in everywhere with the new password, and change the password anywhere else it was used. They should also tell the desk about anything odd in the next week. That could be an unexpected sign-in prompt, a colleague asking about a message they did not send, or a call referring to the document.

Nothing in the conversation is a lecture, and nothing in it is a test. The person already knows what happened and already feels worse about it than any reminder could achieve. A technician who adds to that has made the next person less likely to phone. Whether the organisation wants a training conversation later is the security function's call and the manager's, not the desk's. If wanted, that conversation happens later, somewhere else, kindly. The desk's job is to be the place where telling the truth is safe. The reason that matters beyond decency is in Rewarding the Reporters: every click the desk hears about within the hour was reported by someone who believed the desk would not make it worse.

Keep the explanation short and concrete; the person is anxious and will not retain a tour of the authentication system. The three-sentence form, what happened, what we did, what you do now, is the one to use. The craft of it is in The Three-Sentence Explanation. Keiran's version was: "Someone got your password from that page. I've changed it and signed you out everywhere, so it doesn't work for them any more. Sign back in on your phone and laptop, and tell me if anything looks odd this week."

The Note That Records Facts Without Blame

The ticket is the only account of the first hour that will exist by next week. It is written for two readers: the security function tomorrow and a stranger in a year. It records times above all. Reported at; what kind of click; password reset at; sessions revoked at, by whom; mail rules found, what they did, removed at; sign-in history showed; second-factor methods reviewed; device isolated at, handed to; security function told at, by what means; person told at; what the person was asked to do. Each line is a fact with a clock time, and together they are a timeline that the security function can read without phoning anyone. If you run QuerySolv, the event history on the ticket already stamps every reply and note with its time. That way, the sequence of what the desk did is kept for you. The facts themselves still need writing.

What the note does not contain is judgement, and it does not contain secrets. No "user fell for an obvious phish", no "should have known". The person's name appears as the account that was affected, not as the cause. No password, old or new, is written anywhere, ever; "reset" is the whole record of it. The link in the message is not pasted into the note in a form that can be clicked by the next reader. "A sign-in page on a domain that was not ours" is enough for the desk. The security function holds the exact destination in its own record. The general rule, that a ticket note must never carry a credential or a line you would not want the person to read, is in What Not to Write in a Ticket. The clicked ticket is where that rule is tested hardest, because the technician is tired, the hour was tense, and "fell for it" is right there.

The internal note is for the desk and the security function. The public reply is for the person. It is the kind conversation written down: what was done, what they do next, and thank you. Keep the two apart. A person who opens their ticket and reads the desk's working notes about them has learned something about the desk. It is not the thing you wanted them to learn.

A Short War Story: The Reset Without the Revoke at Stonebridge Insurance

A claims handler at Stonebridge Insurance named Ingrid reported that she had typed her password into "a document from HR" that led nowhere. Lewis on the desk did the right first thing and reset it within ten minutes. He closed the ticket with a friendly note and moved on to a queue that had not got any shorter. Nobody ended her sessions or looked at her mailbox rules. The sign-in that had already happened with the old password stayed valid for the rest of the week. A rule in her mailbox forwarded every message containing the word "claim" to an outside address for nineteen days, until a customer asked why a reply had come from an address they did not recognise. The clean-up involved the security firm, the data-protection officer, letters to several dozen policyholders and something over eighty hours of other people's time. That was for a ticket that had taken Lewis ten careful minutes. The lesson, written on the runbook afterwards in Lewis's own hand, was that the reset ends the password, the revoke ends the session, and the rule check ends the quiet leak. The lesson also said that doing one of the three is not a third of the job.

The Clicked Runbook

The runbook below is the first hour as a checklist, in bands, and it is filled in on the ticket as the hour goes. The names in the "who" column are the ones to write in before the first incident. Write in the administrator who can revoke sessions, the person who is the security function, and what they want done with a suspect device. A runbook with those blanks still empty at the moment it is needed is a list of things to find out. Fill them in this week.

CLICKED RUNBOOK — THE FIRST HOUR
Ticket: ________   Person: ______________   Account: ______________
Reported at: ______   Kind of click: [ ] link only  [ ] typed credentials
                                     [ ] opened attachment / ran file  [ ] replied / paid / sent data
Linked triage ticket: ________   Original message attached: yes / no

BEFORE THE FIRST INCIDENT (fill in now)
  Who can revoke sessions: ______________ (phone ________)
  Who is the security function: ______________ (phone ________)
  Suspect device: [ ] leave on, isolated, untouched   [ ] shut down and collect   (their answer)

FIRST TEN MINUTES — CONTAIN THE ACCOUNT
  [ ] Identity verified to the usual standard                      at ______
  [ ] Password reset, delivered without e-mail                     at ______
  [ ] Sessions revoked everywhere, by ______________               at ______
  [ ] Reuse question asked; person to change other places today    yes / no

MINUTES TEN TO THIRTY — CHECK AND ISOLATE
  [ ] Mailbox rules reviewed; unexpected rules found: none / ______ removed at ______
  [ ] Sign-in history read; unexpected sign-ins: none / ______ (reported, not pursued)
  [ ] Second-factor methods reviewed with the person; unknown methods removed: none / ____
  [ ] Device off the network (attachment or file cases)            at ______
  [ ] Device handled per the security function's standing answer; labelled with ticket and time
  [ ] Loan device issued, clean, new password                      at ______

MINUTES THIRTY TO SIXTY — TELL AND TALK
  [ ] Security function told by phone / ticket                     at ______
      Given: who, when, kind of click, original, actions with times, history, rules, device
  [ ] Finance told (payment or bank-detail cases)                  at ______
  [ ] Person told: what happened, what was done, what they do now; thanked for reporting
  [ ] Asked to watch for: sign-in prompts, colleagues' questions, calls about the message
  [ ] Outbound messages sent from the account before the revoke: none / ______ (security decides notice)

AFTER THE HOUR
  [ ] Internal note: timeline of facts with clock times; no judgement, no credentials, no live link
  [ ] Public reply: the kind conversation, written down
  [ ] Ticket linked to the security function's record; left open until they confirm
  [ ] Counted as one click on this month's line (never as a name)

Nadia's hour at Bellweather ended at 09:48 with Keiran signed back in on a new password. A rule that had been in his mailbox for twenty-three minutes had been removed. The IT manager was on the phone to the contracted firm. The ticket's first line read "credentials typed at approx 08:30, reset 08:58, revoked 09:06". The firm's review the following week found that the sign-in had been used once, to create the rule, and nothing else. Keiran has since reported two messages before clicking anything, which is the outcome the first hour is really for.

Frequently Asked Questions