Remote access incident response: First‑hour checklist

If you just learned a support tool may have been the attacker’s entry point, the first hour decides how much you can preserve, how much scope you can limit, and whether you keep forensic options. This article gives a focused, prioritized remote access incident response playbook for that first hour — what to do, what to collect, and which decisions matter.

Who needs this and what this article delivers

This is written for IT, SOC, and incident handlers who already operate remote-support tooling (TeamViewer, AnyDesk, RDP, Tenvo, etc.). It’s not a deep forensic manual — it’s a short, operational checklist you can run in the first hour when the support channel is the suspected entry. You’ll get a prioritized triage sequence, concrete artifacts to capture, quick indicator checks, containment moves that avoid destroying evidence, and a short communications checklist.

Immediate triage: a prioritized checklist (first 0–60 minutes)

1. Don’t panic; act in order. Speed matters more than cleverness. Follow the steps in order — skipping preservation to immediately block everything makes investigations harder.
2. Identify the suspected sessions and users. Who initiated the support session? What account, username, or technician device appears in the support logs? Note timestamps (UTC) and session IDs before altering anything.
3. Preserve logs and evidence first. Pull the remote-access server logs, relay logs, and any session recordings. If the remote tool is cloud-managed, export logs from the admin console immediately. If you must, snapshot the supporting system (memory, disk) after export.
4. Isolate, don’t destroy. Quarantine the compromised endpoint from the rest of the network (VLAN, switch port, or host firewall block) but avoid powering it off unless necessary. You want processes, memory, and open network connections preserved for forensic analysis.
5. Block further access selectively. Revoke or disable the specific support account or device fingerprint used by the suspected session. Don’t blanket-revoke all support accounts unless you’re ready for the operational impact.
6. Rotate credentials and secrets exposed to that device. Change passwords, API keys, and service accounts that the compromised host or session had access to — but document changes precisely for investigators.
7. Notify stakeholders and stand up an incident channel. Inform your incident lead, legal/compliance, and the CISO. Use a pre-approved incident channel (chat or ticket) and assign a single incident commander to avoid duplicated actions.

What to collect and preserve (evidence list)

Collecting the right artifacts in the first hour preserves options for root cause and scope assessments. Prioritize exports you can do remotely and non-destructively.

• Remote-access software logs: session start/stop timestamps, session IDs, connected peer IPs, user/device IDs, relay usage flag, and any session recordings.
• Authentication logs: IdP logs, MFA push/ticket logs, and any SSO service logs showing the support account activity timestamped to session events.
• Endpoint logs and memory: Windows Event Log (Security and System), Linux /var/log/auth.log and syslog, process lists, and memory image if possible.
• Network captures: PCAPs from the endpoint’s switch port, the upstream firewall, or a TAP. Capture at least 60–120 seconds around the known session times if continuous capture isn’t available.
• Relay/provider audit logs: If the session went through a managed relay, export the relay provider’s connection logs and region/POPs used.
• Configuration and policy snapshots: current support tool config, access control lists, group memberships, local admin accounts, and recent policy changes.

Win: wevtutil qe Security /q:"*[System[(EventID=4624)]]" /f:text > log_4624.txt
Linux: sudo journalctl --since '2026-10-13 09:00:00' --until '2026-10-13 10:00:00' > auth-window.log
Network: sudo tcpdump -i any -s 0 -w suspect.pcap host 198.51.100.23

How to tell whether the support tool was the entry point

Not every suspicious support session equals compromise. These checks help determine whether the session was a post‑compromise tool, the initial vector, or benign oversight.

• Session timing vs detection time. If the session started before the first detection (AV alert, new account creation, or suspicious process), it’s more likely to be the vector.
• Credential anomalies. Look for new device fingerprints, new API keys, or a just‑created support account. Check whether the session used SSO or a direct username/password and whether MFA was bypassed or unused.
• Relay vs direct peer-to-peer. Determine whether the client connected directly peer-to-peer (NAT hole-punch) or via a relay. With most tools, a relay fallback means the relay termination point has visibility into the session traffic — capture those relay logs and connection endpoints.
• Concurrent lateral activity. If the support session correlates to lateral logins, privilege escalations, or credential theft within minutes, the session likely played a role in attacker movement.
• Tool abuse patterns. Check for CLI usage, file transfers initiated in the session, remote shell startups, or commands that download executables. Those are clear red flags.

Containment actions that preserve evidence

Containment in the first hour is a balance: you must stop attacker activity without destroying volatile evidence. Prefer targeted, reversible moves.

• Disable the exact support account or device certificate. Most tools let you revoke a client certificate or disable a user. Revoke the compromised credential instead of reinstalling or wiping the endpoint.
• Block remote-control traffic to/from the endpoint at the network edge. Apply an ACL or microsegmentation rule targeted at the endpoint's IP and the support tool’s known relay IPs. Don’t wipe the host yet.
• Quarantine affected hosts. Move them to an isolated VLAN or drop their uplink. Preserve a management path if you still need to run forensic commands.
• Preserve disk and memory if you suspect active malware. If live memory is needed, perform a RAM dump now. If not possible, at least take a disk image before re-imaging.
• Rotate credentials with logs. Rotate secrets for affected services but log each change clearly. Investigators need a timeline of what you changed and why.

Communications: who to tell, and what to say

Clear, fast communications reduce confusion. Use your incident notification matrix, and keep messages factual and short. Avoid speculative language ("we were breached") until confirmed.

• Internal: Incident lead, SOC, IT ops, legal/privacy, HR (if employee data involved), and your executive sponsor.
• External: Managed relay provider or SaaS vendor support contact (open an incident ticket and export logs), managed service providers, and your breach counsel if regulated data might be affected.
• Customers: Only after scoping. Have pre-approved templates for "we are investigating" and for post-mitigation notifications that meet compliance requirements.
• Regulators: If you’re under notification requirements (GDPR, HIPAA, PCI), notify legal early and follow your breach notification timeline.

Decide fast: managed relay vs self-hosting for recovery

If the incident shows the relay operator could see session traffic, that affects risk and evidence. For most teams, a managed relay (Tenvo’s multi-region managed relay by default) is the right choice: it removes on-call relay maintenance, centralizes logs, and provides multi-region failover. Tenvo offers native clients for Windows/macOS/Linux, a browser client in public beta, and a managed relay with Free $0 / Lite $2.99/mo / Pro $7.99/mo tiers.

Self-hosting is appropriate only if you have a written requirement that forbids third-party infrastructure (data residency, a compliance rule, or an isolated network). Self-hosting adds operational cost: you now own relay uptime, certificate renewal, key custody and patching. If you’re considering self-hosting after an incident, read the self-hosting tradeoffs in Self-hosted remote desktop: the honest 2026 guide before committing.

Technical checks and commands to run next (quick indicators)

These quick checks provide immediate indicators of attacker activity. Run them from the endpoint (if safe) or a forensics workstation with a preserved image.

• Windows: Event IDs — Authentication: 4624 (logon), 4625 (failed logon), 4672 (special privileges), 4688 (process creation). Check PowerShell logs for suspicious scripts (4104) and Sysmon (if deployed) for remote parent processes.
• Linux: sudo /var/log/auth.log for sudo/ssh sessions; check process list (ps auxww) and last -f /var/log/wtmp for recent logins.
• Network: tcpdump or tshark for connections between the endpoint and known relay IPs. Look for unusual outbound dumps, DNS over unusual resolvers, and persistent TLS sessions.
• Application artifacts: support tool session IDs, file transfer logs, and clipboard transfer entries. Export them before uninstalling the client.

After containment: remediation and hardening (next 24–72 hours)

After you’ve contained and captured evidence, execute remediation and remove attacker persistence.

• Re-image affected hosts from a verified golden image unless the host must remain for ongoing forensic work.
• Reissue all credentials and keys accessible from the compromised host; rotate service accounts, SSH keys, and tokens.
• Enforce stronger authentication for support tools: require SSO + MFA, per-device allowlists, and session approval gates. See remote access mfa: TOTP, push, passkeys, hardware for method comparisons.
• Harden audit logging and retention so future incidents are easier to investigate. See practical logging best-practices in Remote Desktop Audit Logging.
• Run a full credential sweep (passwords shared in chat, stored credentials, saved browser passwords) and enforce a credential-change window.

Lessons learned and where to invest

Once the immediate incident is closed, run a short post‑mortem focused on root cause and operational holes. Typical investments that reduce both risk and time-to-contain include:

• Restricting support-tool privileges to the minimum necessary and enforcing just-in-time elevations.
• Adaptive MFA and device allowlisting for support clients.
• Automated session recording and immutable audit exports to an external SIEM.
• Clear offboarding and device revocation processes — see Remote access offboarding checklist for a ready list.
• Testing incident runbooks regularly in tabletop exercises focused on remote-access scenarios.

Final notes on trust and the relay truth

Be explicit in your team: a direct peer-to-peer connection is end-to-end between the two devices, but when traffic falls back to a relay, TLS terminates at that relay. That means whichever organization operates the relay can access session traffic if they choose or are compelled to. Don’t assume relays are invisible — build controls and log exports accordingly. If you want a deeper threat model for remote tools, our technical deep-dive is useful: Is Remote Desktop Secure? An Honest Threat Model.

Where to get help and the download link

If you need a managed relay with centralized logs and multi-region failover, Tenvo’s managed relay is the default recommendation unless a written requirement forces self-hosting. For hands-on recovery, preserve evidence, open tickets with your relay vendor immediately, and follow the triage checklist above. When you’re ready, download clients or run a controlled migration from your current tool at Download Tenvo.