You ran the mystery script. Assume it won.
What to do after running software of unknown origin: contain the computer, replace exposed sessions and secrets from a clean device, then decide whether to investigate or rebuild.
Scope
For a person or small team who has just run an untrusted script, installer, cracked utility, copied shell command, browser extension, or program on Windows, macOS, or Linux.
Start with the situation, not the slogan
An incident rarely arrives with a neat label. It arrives as a forwarded screenshot, a worried telephone call, or a monitoring alert written by a machine with no sense of occasion. In this case “You ran the mystery script. Assume it won.” is the working heading, but the label is only a starting hypothesis. The useful work is to establish what happened, what can still happen, and which decision cannot safely wait.
Keep three clocks in view: the attacker’s opportunity, the business interruption, and the lifetime of the evidence. They do not run at the same speed. A hasty change may interrupt access but erase context; a perfect investigation conducted at geological pace may leave the organisation exposed. Good response is the slightly unglamorous art of making the next reversible decision with the best evidence currently available.
Execution gives unknown code the permissions of the account that launched it—and sometimes more. It may steal browser sessions, passwords, tokens, documents, keys, wallets, or cloud credentials and may also leave persistent malware behind. A clean antivirus result cannot prove that none of those things happened.
Composite scenario
How this usually reaches the desk
Imagine the report begins with this observation: “The program was unsigned, unexpectedly requested administrator access, disabled protection, opened a terminal, vanished, or behaved differently from its description.” A second check returns another clue: “New logins, session alerts, mailbox rules, OAuth grants, password resets, browser extensions, processes, services, scheduled tasks, launch items, or outbound connections appear after execution.” Neither fact alone tells the whole story. Together they justify a documented incident, a defined owner, and a deliberate containment decision. This is where a timeline beats a collection of heroic memories; memory is an excellent storyteller and a dreadful audit log.
This scenario combines common operational patterns; it is not presented as a report of one named incident.
What to look for
Begin with preserved, comparable evidence. One signal is rarely proof; use independent observations and a reliable timeline before declaring scope or intent.
The program was unsigned, unexpectedly requested administrator access, disabled protection, opened a terminal, vanished, or behaved differently from its description.
Record the exact time, source, identity, system and time zone. Compare it with a known-good baseline and with what the user or service owner expected. A surprising event is a lead, not a conviction.
New logins, session alerts, mailbox rules, OAuth grants, password resets, browser extensions, processes, services, scheduled tasks, launch items, or outbound connections appear after execution.
Look for the control-plane event that made the visible activity possible: a changed credential, permission, rule, route, token or trusted device. Persistence often looks administrative because, technically, it is.
The host contained an unlocked password manager, active browser sessions, SSH or cloud keys, cryptocurrency wallets, work data, or secrets in source files and environment variables.
Correlate the report with independent telemetry before deciding scope. User testimony, identity logs, endpoint evidence and service audit records are strongest when they agree on sequence rather than merely on mood.
First ten minutes
Stop giving the mystery programme opportunities
You copied a command from a forum, ran an installer from a file-sharing site, opened a “codec”, tried a cracked utility, or piped somebody’s web response into a shell. Then the small sensible voice arrived several minutes late and asked what, exactly, had just been allowed to happen.
Do not begin by arguing with yourself about whether it looked malicious. Treat execution as the event. Unknown code could read anything available to the launching account, including browser sessions, unlocked password managers, SSH keys, cloud credentials, source-code secrets and documents. If you approved administrator or root access, disabled security controls, or entered a password into the programme, widen that assumption.
- Disconnect networking.Turn off Wi-Fi, unplug Ethernet, disconnect VPN and detach shared drives. Do not keep browsing from the suspect device to research whether it is safe. If this is a managed work device, contact security using another telephone or computer.
- Do not log in to anything.Typing new passwords on a possibly monitored machine converts future secrets into present evidence for somebody else. Use a known-clean phone or computer for account recovery.
- Write the timeline.Record the absolute time and zone, download page, message or command, file name and path, what you clicked, prompts approved, credentials entered, visible behaviour and whether protection was disabled. Memory becomes astonishingly creative after the third reboot.
- Preserve the object.If organisational policy permits, retain the original file or exact command in an isolated evidence location and record a hash. Do not upload confidential files to a public scanning service. Do not run it again “with Task Manager open”.
- Decide who owns the response.On a business device, stop and involve the incident team. On a personal device containing work, financial, identity or client data, consider professional help. Evidence, notification and insurance obligations may matter before cleanup.
# Record a SHA-256 hash without executing the file again.
# Windows PowerShell
Get-FileHash .\mystery.exe -Algorithm SHA256
# macOS
shasum -a 256 ./mystery-file
# Linux
sha256sum ./mystery-fileA hash identifies the bytes you retained; it does not certify innocence. A different hash does not prove a different programme either, because installers and scripts change. Keep the source URL, filename, signature information and timeline with it.
Workstream one
Assume sessions, passwords and accessible data may have been copied
Containment of the laptop and containment of the accounts are different jobs. Disconnecting the machine stops some new traffic, but a stolen browser cookie, refresh token or API key may already work from another computer. Changing one password may not revoke those sessions. Work from a clean device and protect the accounts that can reset all the others.
Primary email and identity
Change the password to a new unique value, revoke active sessions, inspect signed-in devices, restore trusted MFA and recovery details, and remove unfamiliar app consent. Check forwarding, filters, delegates and sent mail. If email is lost, use the provider’s official recovery route—not a helpful stranger in direct messages.
Password manager and recovery vault
If it was unlocked or its browser extension was active, assume readable vault contents were exposed. Change the master password from a clean device, revoke devices and sessions, rotate the most consequential stored credentials, and follow the vendor’s breach guidance. Do not export the vault onto the suspect computer for convenience.
Work, cloud and developer access
Notify the employer or client. Revoke SSO sessions; rotate cloud access keys, personal access tokens, package-registry tokens, CI/CD secrets, SSH keys and secrets in .env files or shell history. Search provider audit logs for use after the execution time and for new keys, users, rules or workloads.
Money and identity
Contact banks or payment providers through verified channels if financial access was present. For cryptocurrency, use a clean device and provider-approved recovery process; if seed material may have been exposed, move assets to a newly generated wallet according to competent advice. Review tax, government and shopping identities that reuse recovery routes.
Messaging and social accounts
Revoke sessions, review linked devices and warn contacts if the account sent anything. Attackers enjoy borrowing trust because it is cheaper than earning it. Preserve fraudulent messages before deleting them.
A password change is not a time machine. Revoke sessions, rotate non-password secrets and inspect persistence.
Prioritise by consequence and dependency, not alphabetically. Email normally comes before a streaming service because email resets the streaming service. An administrator account comes before an ordinary project account because it can create more accounts. Record each credential and whether you changed it, revoked its sessions, rotated associated tokens and reviewed recent activity. “Passwords done” is not an audit trail.
Workstream two
Assume the computer may still contain malware
Now deal with the endpoint. The aim is not to make the warning disappear; it is to regain justified trust in the machine. Whether that requires investigation, an offline scan or a complete rebuild depends on privilege, value, evidence and the confidence required.
Lower uncertainty, lower privilege
The file never obtained administrator rights, built-in protection blocked it before execution, telemetry records the prevention, and the computer holds little sensitive material. Preserve the alert, update security tools, run a full scan, inspect browser extensions and startup changes, and monitor. Record why this was accepted rather than quietly hoping.
Execution confirmed, ordinary user
Isolate, preserve relevant logs, browser downloads, process and network telemetry, and security history. Run current endpoint protection and an offline scan where supported. Assume user-accessible secrets were exposed even if the scan removes a file. Consider rebuilding when behaviour is unknown.
Administrator/root, security disabled, or secrets present
Choose a rebuild from trusted installation media or a known-good managed image unless a competent responder can establish integrity. Malware with high privilege can alter the very tools being asked to declare it clean. Rotate machine and user secrets from elsewhere.
Business, regulated or legally significant device
Do not improvise cleanup. The incident owner decides isolation, evidence acquisition, legal and privacy notifications, and rebuild timing. A responder may need memory, disk and central telemetry before the endpoint changes further.
Windows
Update Microsoft Defender security intelligence, review Protection history, and run a full scan. Microsoft Defender Offline restarts into the Windows Recovery Environment so persistent malware has a harder time hiding while Windows is running. It is a useful control, not a certificate of innocence. If malware made irreversible changes or trust remains low, Microsoft’s own guidance includes reset, restore or reinstall options using data from a known clean backup.
macOS
Keep macOS security updates current and do not override Gatekeeper warnings for the same programme again. Apple describes XProtect as built-in detection and removal for known malware. Known is the important word: when unknown code ran with broad access, use evidence and risk to decide whether to erase and reinstall macOS, then restore reviewed documents rather than applications and settings of uncertain origin.
Linux
Preserve shell history, package and authentication logs, processes, services, timers, cron entries, user and SSH-key changes, network evidence and the original command where policy permits. Compare against trusted packages or a known image. If the script ran as root, installed persistence, modified security tooling or cannot be fully explained, rebuild from trusted media and rotate keys. A clean process list after reboot mostly proves that you have a clean-looking process list.
Recovery
How to rebuild without inviting the guest back in
- On a clean device, obtain the operating-system installer or managed image from the official source and verify it by the vendor’s supported method.
- Inventory licences and essential data without copying executables, scripts, browser profiles, extensions, login items or mystery archives into the new system.
- Erase and reinstall, or reimage through the organisation’s trusted management path. Apply operating-system, firmware, browser and application updates before ordinary use.
- Re-enrol device management, endpoint protection, disk encryption, backup and logging. Confirm they report to the expected owner.
- Restore reviewed documents from a backup created before the event where possible. Scan them and open risky formats cautiously. Reinstall applications from official sources.
- Reconnect using the new or rotated credentials, then watch identity, email, cloud, financial and endpoint alerts for a defined period.
Do not restore a full untrusted system image merely to recover the desktop arrangement. That can restore the incident with admirable fidelity. If you must preserve a disk for investigation, keep it offline and use a new disk or device for recovery.
Working examples
Run it, read it, decide what changes
These examples use documentation addresses, test identities and bounded targets. Replace placeholders only inside systems you own or are explicitly authorised to operate. Read the expected result and next action before running the command; a successful command is evidence, not yet a conclusion.
Create a UTC evidence note and hash
- Prerequisites
- A directory that only the responder can write to.
mkdir -p incident-evidence
date -u +"%Y-%m-%dT%H:%M:%SZ" | tee incident-evidence/collection-time.txt
sha256sum suspicious-file 2>/dev/null | tee incident-evidence/file.sha256The note contains an absolute UTC time and the hash line contains 64 hexadecimal characters plus the filename.
The hash identifies the collected bytes; it does not say whether they are malicious. A changed hash means the file changed or a different file was collected.
Make the evidence directory read-only, record who collected it, and work on a copy. On macOS use `shasum -a 256` if `sha256sum` is unavailable.
Export a Windows event window
- Prerequisites
- An elevated PowerShell window and a recorded incident start time.
$start = [datetime]"2026-08-18T08:00:00Z"
$end = [datetime]"2026-08-18T10:00:00Z"
Get-WinEvent -FilterHashtable @{LogName='System'; StartTime=$start; EndTime=$end} |
Export-Clixml .\system-events.xml
Get-FileHash .\system-events.xml -Algorithm SHA256PowerShell writes `system-events.xml` and prints its SHA-256 hash.
An empty export can mean the time window or log name is wrong; it is not evidence that nothing happened.
Export the relevant Security, Defender or Sysmon log separately, preserve original time zones, and note any collection errors.
Record live listeners without changing them
- Prerequisites
- Local administrator access; collect before rebooting if incident policy allows.
# Linux
sudo ss -lntup
# Windows PowerShell
Get-NetTCPConnection -State Listen |
Sort-Object LocalPort |
Select-Object LocalAddress,LocalPort,OwningProcessA list of listening addresses, ports and process identifiers appears.
`0.0.0.0` or `::` means all local interfaces; `127.0.0.1` is local-only. A PID is a lead that must be mapped to a signed binary or package.
Save the output, map unexpected PIDs to processes, then compare with firewall, container and port-forward configuration.
Check Defender health
- Prerequisites
- Administrator PowerShell.
Get-MpComputerStatus |
Select-Object AntivirusEnabled,RealTimeProtectionEnabled,AntivirusSignatureLastUpdated,QuickScanAge,FullScanAgeDefender state, real-time protection and signature/scan ages are displayed.
Enabled does not mean every feature is configured or that no malware ran. Third-party EDR can legitimately change some fields.
Compare with policy, update stale signatures through the supported management path, and run an approved test event.
Check disk encryption
- Prerequisites
- Administrator PowerShell.
Get-BitLockerVolume |
Select-Object MountPoint,VolumeStatus,ProtectionStatus,EncryptionMethod,EncryptionPercentageEach BitLocker volume reports encryption and protection state.
A fully encrypted volume with protection suspended does not protect a powered-off lost device as intended.
Escrow and verify recovery keys through approved management, resume suspended protection, and test recovery on a non-production device.
Export effective security policy
- Prerequisites
- Elevated command prompt and protected output path.
mkdir C:\SecurityBaseline
secedit /export /cfg C:\SecurityBaseline\effective-policy.inf
certutil -hashfile C:\SecurityBaseline\effective-policy.inf SHA256Windows exports applicable local security settings and prints the file hash.
Domain and MDM settings may not all be represented, and export does not prove enforcement on every endpoint.
Compare with the approved baseline, pilot one change group, and validate both permitted use and the blocked case.
Locate a secret in Git history without printing every file
- Prerequisites
- A unique, non-secret identifier or a revoked token prefix; never paste a live secret into shared shell history.
git log --all --oneline -S 'REVOKED_TOKEN_PREFIX'
git grep -n 'REVOKED_TOKEN_PREFIX' $(git rev-list --all) -- ':!vendor' ':!node_modules'Commits and matching paths containing the identifier are listed.
Removing the current file does not remove earlier commits, forks, CI logs, artefacts or cloned copies.
Revoke first, inspect provider audit logs for use, replace the secret everywhere, then rewrite history only with repository-owner coordination.
Inventory environment-variable names without exposing values
- Prerequisites
- Run only on a system you are authorised to inspect.
env | cut -d= -f1 | sort | grep -Ei 'TOKEN|SECRET|KEY|PASSWORD|CREDENTIAL'Potential secret-bearing variable names appear without their values.
Names are hints; secrets may also live in files, keychains, CI variables or process arguments. Avoid commands that print values into terminals or tickets.
Map each credential to an owner, provider, permissions and rotation procedure; revoke suspected exposures before cleanup.
Prove the old credential no longer works
- Prerequisites
- A harmless read-only endpoint and the revoked credential held only in a private local variable.
OLD_TOKEN='replace-locally-never-commit'
curl -sS -o /dev/null -w '%{http_code}\n' -H "Authorization: Bearer $OLD_TOKEN" https://api.example.invalid/v1/me
unset OLD_TOKENA revoked bearer token should receive an authentication failure such as HTTP 401; the documentation host here must be replaced with the real provider endpoint.
HTTP 403 can mean the token is valid but lacks permission; a network error proves nothing. Use the provider’s documented harmless identity endpoint.
Record the revocation evidence, test the replacement through the application, and search audit logs from exposure time onward.
What to do
Read the whole sequence before starting. Several workstreams may run in parallel, but their evidence, authority and expected outcomes still need to be explicit. Every step below points back to a concrete example; use the example as implementation evidence, not as permission to operate outside the stated scope.
Operational judgement
Containment and recovery are different verbs. Containment limits the next harmful action; recovery returns a service to trustworthy operation. Between them sits eradication: removing the access path and persistence that would make the freshly restored service merely a cleaner target. For Malware, Session theft and Recovery, keep those decisions separate in the timeline even if a small team performs them minutes apart.
Communication is also a control. Tell affected people what is known, what remains uncertain, what they must do and when the next update will arrive. Avoid both melodrama and false reassurance. “We are investigating” is useful only when followed by an owner and a time. The goal is to reduce secondary harm without teaching a possible attacker exactly what the team has discovered.
Handover
Make the result useful to the next person
Maintain two views of the incident. The working timeline should contain detailed events, evidence locations, hypotheses and technical actions. The stakeholder update should contain confirmed impact, current containment, material uncertainty, decisions required and the next reporting time. Do not copy speculative indicators into executive statements. Equally, do not polish away uncertainty merely because it looks untidy. Both records should use absolute times with a declared time zone and should identify the source of each important fact.
At shift change, hand over the current scope, trusted administration path, preservation status, active controls, failed actions, business priorities and the next three decisions. Read back the most consequential assumptions. For this case, ensure the record begins with “Disconnect the affected computer from Wi-Fi, Ethernet, VPN, Bluetooth networking, and shared storage; record what ran, when, from where, and under which account before changing more state.” and does not finish until the team has addressed “Restore only reviewed data, patch the rebuilt device, re-enrol security controls, monitor affected identities, and document exactly what was invalidated, checked, restored, and left uncertain.” A concise, accurate handover prevents the incoming team from repeating disruptive work or mistaking a quiet telemetry gap for successful containment.
Validate before you close
The incident can close only when exposed sessions and credentials are invalid, important accounts show no unauthorised persistence, the endpoint is rebuilt or its integrity is accepted by an accountable owner, restored data is checked, and follow-up monitoring has a named duration and owner.
Capture the test, the expected result and the observed result. Where a person or business owner must accept restored service, name them in the record. A green dashboard can confirm that a component is answering; it cannot confirm that invoices, identities or restored data are trustworthy.
Finish with a compact closure note: the original trigger, confirmed scope, evidence retained, controls changed, tests passed, known gaps, residual risk, and the people responsible for the remaining work. Schedule a review while the timeline is still fresh enough to challenge. The purpose is not to find a person to blame; computers already perform blame with admirable efficiency. The purpose is to make the next response faster, safer and less dependent on one person remembering where the useful log was hidden.
Common mistakes
- Resetting systems before preserving volatile evidence and audit logs.
- Treating the first visible symptom as the complete scope of the incident.
- Restoring service without verifying that the attacker’s access path is closed.
These errors usually come from haste, unclear ownership or misplaced confidence. Build the safeguard into the runbook: a required evidence field, a second-person review, a rollback test or a specific exit criterion.
Questions people ask when the clock is running
Does one suspicious event prove compromise?
No. Treat “The program was unsigned, unexpectedly requested administrator access, disabled protection, opened a terminal, vanished, or behaved differently from its description.” as a reason to investigate and preserve evidence. Confidence should rise when independent identity, service, endpoint or network records support the same sequence.
Should we reset everything immediately?
Reset or revoke what the evidence and risk justify, but preserve the state you will need to understand the incident. Broad, undocumented resets can interrupt the attacker, the business and the investigation in one impressively efficient stroke.
When can the incident be closed?
The incident can close only when exposed sessions and credentials are invalid, important accounts show no unauthorised persistence, the endpoint is rebuilt or its integrity is accepted by an accountable owner, restored data is checked, and follow-up monitoring has a named duration and owner. Closure also requires named owners for residual risk and follow-up work; “it seems quiet now” is an observation, not an exit criterion.
Safety boundary
Use these steps only on systems you own or are explicitly authorised to assess. Preserve evidence, follow your organisation’s legal and regulatory obligations, and prefer reversible actions when the situation is not yet understood.
Primary references
- SP 800-61 Rev. 3: Incident Response Recommendations and ConsiderationsNIST
- Virus and threat protection in Windows SecurityMicrosoft Support
- See devices with account accessGoogle Account Help
- Protecting against malware in macOSApple Platform Security
Editorial status: first edition. Review the linked vendor documentation for product- and version-specific changes before acting.