At a bank, the Linux authentication log shows repeated failures and then a success for an admin from a foreign address, and no change ticket exists for that logon. What is the first triage step?
Select an answer to reveal the explanation.
Short Explanation
Before you throw away the sign-in sheet, ask the person if that signature is theirs. You verify the foreign admin success with the admin and you keep the authentication log. The trap is deleting the account, calling failures ransomware, or ignoring the success that followed.
Full Explanation
The authentication log shows a burst of failures and then a success for an admin from a foreign address, with no change ticket. The success is the event that changed the risk, and the first step is to learn whether that admin actually logged on, without destroying the record you will need. The first triage step is "Ask the admin whether that foreign logon was theirs, and preserve the authentication log". "Delete the admin account immediately, before anyone reviews the authentication log entries" removes the account and can hinder the conversation and the investigation before anyone knows whether the logon was legitimate. "Treat the failed attempts alone as proof that ransomware is already running on the bank host" stops at the failures and invents file encryption the log does not show. "Ignore the later success and close the ticket, leaving the foreign address logon unexamined" drops the line that matters, because failures followed by a success are a different story from failures alone. Exam caveat: a foreign address is a lead, not the name of an attacker, and a real admin on travel can produce the same pattern. Operational check: contact the admin on a known bank number, keep the authentication log intact, and note the source address and time of the success while you wait for that confirmation.