Hunting TeamViewer Abuse When the Tool Is Already Approved

Remote support tools are the awkward case in detection engineering. TeamViewer, AnyDesk, ScreenConnect, Atera, the whole remote monitoring and management family sits in a category ATT&CK calls Remote Access Software (T1219), and half the time it’s your own help desk on the other end. That’s the problem in one sentence. The tool is a blessed insider, so an attacker who can run it inherits all that trust for free, and the SOC waves it through because it saw the same binary do legitimate work last Thursday.

We’ve stopped trying to answer “is TeamViewer running” and started answering “does this session look like our help desk or like somebody else.” Those are very different questions, and the second one is answerable with telemetry we already collect.

What normal actually looks like

Before we can call a session abnormal we have to know what normal is, and for us normal means a specific set of facts. Our help desk connects during business hours, from a small pool of source addresses, to endpoints that raised a ticket. The remote party’s TeamViewer ID sits in a short, stable list. Unattended access is configured on servers we chose, not on a random finance laptop. Write those facts down first. Every detection below is really just a deviation from that baseline, and a baseline you haven’t written down is a baseline you can’t alert against.

The process family

TeamViewer isn’t one process, it’s a little family, and the shape of the family tells you what kind of session you’re looking at. TeamViewer_Service.exe runs as SYSTEM and is the persistent core. TeamViewer.exe is the user-facing GUI at medium integrity. The tv_w32.exe and tv_x64.exe helpers handle logging and hooking. The one we care about most is TeamViewer_Desktop.exe, which only spins up when there’s a live incoming session over unattended access. So on a host where nobody should be receiving remote control, a running TeamViewer_Desktop.exe is a question that needs an answer.

Sysmon process creation (Event ID 1) gives us the tree. The detail we lean on is a portable or “QuickSupport” build of TeamViewer launching from a user’s Downloads or Temp folder rather than from Program Files. Look, a properly installed remote tool lives where installers put it. When the same product runs out of AppData\Local\Temp under a filename like TeamViewer_.exe, that’s not IT following the runbook, that’s someone who downloaded a one-shot copy to get in and out. We flag execution path aggressively for this reason.

The logs the client hands you

This is the part I like, because the tool investigates itself if you let it. TeamViewer writes plain-text logs next to its install, and the one worth ingesting is Connections_incoming.txt. Every inbound session gets a line: the remote TeamViewer ID, the display name, the start and end timestamps, the local user account, and the session type such as RemoteControl or FileTransfer. On the per-user side there’s a connections.txt under the roaming profile. There’s a persistence angle worth a rule of its own here too: unattended access has to be configured before an attacker can connect without someone accepting a prompt, and that configuration leaves registry artifacts under the TeamViewer key, including a stored security password value. A first-seen write to that configuration on a host that was never set up for unattended support is a quiet but reliable sign someone is preparing the box to be reachable on demand. Pull those two files into your SIEM as a log source and you get an authoritative record of who connected to what, straight from the vendor’s own bookkeeping. We cross-reference the incoming IDs against our approved list on a schedule. An ID that isn’t on the list, connecting after hours, with a FileTransfer session type, moves to the top of the queue on its own.

The network shape

By default TeamViewer reaches out over TCP 5938 to the *.teamviewer.com infrastructure, and falls back to 443 or 80 if that’s blocked. Sysmon network connection events (Event ID 3) and DNS query events (Event ID 22) give us both halves: the destination port and the resolved hostname. On its own this is weak, because legitimate sessions look identical on the wire. Where it earns its place is correlation. A DNS query for teamviewer.com from a server that has never phoned that domain before, followed within seconds by a TeamViewer_Desktop.exe process and an incoming-log line from an unknown ID, is three independent signals agreeing with each other. Any one of them is noise. All three together, rarely.

Three detections we run

We keep this to three rules, on purpose, because remote-tool hunting rots into an unmaintainable allowlist if you let it sprawl. The first rule fires on remote-support binaries executing from a non-standard path, which catches the download-and-run pattern regardless of which product it is. The second parses Connections_incoming.txt and alerts on any inbound TeamViewer ID outside the approved set, or any session outside business hours. The third is a correlation rule that ties a first-seen DNS query to a remote vendor domain together with a matching process start on a host with no prior history of that tool. First-seen logic does a lot of heavy lifting here, and modern EDR like Defender for Endpoint or the Sysmon deployment feeding it (we run Sysmon 15 on Win11 23H2 and Server 2022) supplies the raw material for all three.

Where these fall over

The honest weakness is that a patient attacker using the exact remote tool your help desk uses, during business hours, from a plausible source, will not trip the behavioral rules. That’s not a reason to skip them, it’s a reason to pair them with an approved-ID allowlist and to make the incoming-log rule strict about session type and timing. The other place these fall over is unmanaged or shadow-IT hosts where the baseline was never established, which is where the execution-path rule quietly becomes your most valuable one, because it doesn’t depend on a baseline at all.

The broader point is that this exact approach generalizes. AnyDesk keeps its own connection trace, ScreenConnect drops predictable service artifacts, and the process-family plus self-logging plus network-first-seen model transfers cleanly across the RMM category. If tunneled remote access is where your hunt is heading next, the RDP over reverse SSH writeup covers the encrypted-pivot variant, and the named-pipe pivoting notes cover the lateral-movement channel attackers reach for once the remote tool has landed them somewhere.