Who connected to this machine, and when: what your logs should show
The question arrives after the fact — was anyone on this machine last Tuesday? — and most setups cannot answer it. The time to decide what you can prove is before you need to prove it.
What a useful record contains
Six fields, and the value collapses if any are missing:
- When it started and ended. Duration matters as much as the timestamp — a 20-second session and a four-hour one are different events.
- Who connected, as an identity rather than an IP. An address without an account behind it identifies a network, not a person.
- From where, as an address and ideally a rough location. This is what makes an anomaly visible.
- To which machine, if you have more than one.
- Whether anyone approved it, and who. For attended support this is the single most important field.
- What was transferred, at least in volume. A session that moved 4 GB is a different event from one that moved 40 KB.
What Windows already records
Regardless of which tool you use, the operating system keeps a record worth knowing about. In Event Viewer, under Windows Logs → Security:
| Event ID | What it means |
|---|---|
| 4624 | Successful logon — logon type 10 is a remote interactive session |
| 4625 | Failed logon — a run of these is a brute-force attempt |
| 4634 / 4647 | Logoff |
| 4778 / 4779 | A session was reconnected or disconnected |
| 1149 | Under TerminalServices-RemoteConnectionManager: an RDP connection was authenticated |
Two caveats. Logon type 10 covers RDP; a tool that runs inside an already-logged-in session may generate no logon event at all, because from Windows' point of view nobody logged on — the existing session simply gained a viewer. And local logs live on the machine in question, which means anyone with administrator rights on it can clear them. For anything that matters, logs need to leave the machine.
Consent beats logging for shared machines
On a machine someone else uses, a log answers the question afterwards. A consent prompt prevents it. If a remote tool can connect without the person at the machine agreeing, unattended access is enabled — which is right for your own server and wrong for a family member's laptop.
The distinction to check in any tool you deploy:
- Attended: the person at the host must actively share a code or accept a prompt, every time. Correct for support.
- Unattended: a stored credential permits connection with nobody present. Correct for your own machines, and a standing risk on anyone else's.
A per-session code that expires is structurally safer than a permanent credential, because there is nothing left behind for someone to find later — see who can see a remote session.
Practical minimums
- For your own machines: know whether unattended access is on, and turn it off where you do not need it. Check the tool's session history exists and that you know where to find it before you need it.
- For a family member's machine: attended only. They start the session, every time. This also removes the ambiguity that a scammer exploits.
- For a work machine: logs must ship off the device, and the approval field must exist. A record an administrator can delete is not a record.
- For anything regulated: retention needs to be defined in advance, and "the tool keeps 30 days" is a constraint you should discover during procurement rather than during an investigation.
The check nobody does
Read your own logs once, while nothing is wrong. Most people first look at a remote access log during an incident, discover it retains seven days or does not record approval, and learn the limits at the worst possible moment. Ten minutes now tells you what you would actually be able to prove.
More guides
Never put RDP straight on the internet — and what to do instead
Port 3389 is scanned continuously, credential stuffing against it is automated, and it is the most common entry point for ransomware. Four safer ways to reach the same machine.
Why a remote connection will not establish, and how to tell which layer failed
NAT, CGNAT, symmetric NAT and corporate firewalls each break the connection in a different place. A diagnosis order that identifies the layer in a few minutes.
Why the remote cursor lags, and which of the six causes is yours
Network round-trip, upstream bandwidth, encoder delay, frame rate, resolution and relay hops each add lag in a different way. How to tell them apart and what actually helps.
Try RemoteFrames
Install the host on the computer you want to reach, then enter its 6-digit code in any browser. No account — two free 10-minute sessions a day.
Try RemoteFrames