01The question
What do the server's logs show about sessions opened with the account in the disputed period, and can the activity be tied to a particular source?
02Background
A fictional organisation asks whether a named account was used on a server one evening. The server image and exported logs were provided. The examination reads the records; it does not describe methods of obtaining credentials or evading controls.
03Constraints
- Only the server's own logs were available; network device and VPN logs were not provided.
- Logon records identify an account and a source address, not a human being.
04Evidence received
05Examination method
Read the logon and logoff events
The Security log was read for event 4624 (logon) and 4634/4647 (logoff) for the account in the disputed period. The logon type field distinguished an interactive logon (type 2) from a remote-interactive one (type 10), and 4648 recorded any explicit-credential logons. The source network address field was recorded for each.
Windows XML Event Log (EVTX)Timestamp decoderEvent 4624Event 4634Event 4647Event 4648
Corroborate remote sessions from the RDP channels
The RemoteConnectionManager and LocalSessionManager operational logs were read for session connect, reconnect and disconnect entries. These were matched to the type 10 logons by time and session identifier, and the source address was compared across the two sources.
Place the session in the activity timeline
User-activity artifacts for the account's profile on the server (UserAssist, Jump Lists, Recent) were read to see what was done during the session window, and $UsnJrnl entries in that window were listed. Each was tied to the session by time.
UserAssistJump Lists$UsnJrnl:$J (USN change journal)Timestamp decoder
Normalise to UTC and state the attribution limit
All times were converted to UTC using the server time zone. The conclusion distinguished what is well supported (an account, a session type, a source address, a time) from what the logs cannot establish (which person sat at the source).
06Findings
Established
The account opened a remote-interactive (type 10) session on the server during the disputed evening, from a recorded source address, and files were accessed during that session.
Basis4624 type 10 and the RDP operational logs agree on time, session and source; UserAssist and $UsnJrnl place activity in the window.
Probable
The source address belongs to the account holder's usual remote range.
BasisThe address matches the range recorded for the holder's prior sessions; but without VPN/network logs the mapping to a specific device is incomplete.
07Limits
- Logon records establish an account and a source, not the identity of the person operating it.
- Without network and VPN logs, the source address cannot be tied to a specific physical device.
- A shared or delegated credential would let someone other than the holder open the session; the logs cannot exclude this.
08Report excerpt
Security event 4624 (logon type 10) for the account is recorded at 21:34 UTC with source 10.x.x.x, matched by an RDP RemoteConnectionManager connect entry at the same second and session ID. UserAssist and $UsnJrnl show document activity until the 4647 logoff at 22:11 UTC. We state the session as established and the source-to-holder mapping as probable; the logs cannot show which person was at the source.
09Lessons
- Match 4624 type 10 with the RDP operational logs; two sources agreeing on session and source is far stronger than one.
- Separate the account from the person at every step; logs attribute to accounts, not people.
- Name the logs you did not have (VPN, network) and let them bound the source attribution.