ogmini - Exploration of DFIR

Having fun while learning about and pivoting into the world of DFIR.

---

About Blog Research CTF/Challenge GitHub RSS

27 March 2025

SSH Artifacts in Windows 11 - Part 2

by ogmini

Continuing from yesterday’s post, we are diving deep into the Windows Event Logs. Please refer back to the main post for full details as this post will only talk about the tests and results.

Detailed Analysis of Windows Event Logs

Logon IDs

In the log analysis below, we will see the following Logon IDs:

• 0x3E7
• 0x44C61B
• 0x44C8A8
• 0x44C907

Successful Login

Pay special attention to the Logon IDs which are listed right after the EventID.

1. EventID 4717 (0x3E7) - WINDOWS-SSH-SER$ is given the SeServiceLogonRight. https://www.ultimatewindowssecurity.com/securitylog/encyclopedia/event.aspx?eventID=4717
   
2. EventID 4648 (0x3E7) - The sshd.exe process now logs on (RUNAS) as the Account “sshd_4568”. https://www.ultimatewindowssecurity.com/securitylog/encyclopedia/event.aspx?eventID=4648
   
3. EventID 4624 (0x3E7) - Take note of the Logon Type, Virtual Account, and Elevated Token. https://www.ultimatewindowssecurity.com/securitylog/encyclopedia/event.aspx?eventID=4624
   
4. EventID 4672 (0x44C61B) - “sshd_4568” is given the SeImpersonatePrivilege. https://www.ultimatewindowssecurity.com/securitylog/encyclopedia/event.aspx?eventID=4672
   
5. EventID 4718 (0x3E7) - WINDOWS-SSH-SER$ has the seServiceLogonRight removed. https://www.ultimatewindowssecurity.com/securitylog/encyclopedia/event.aspx?eventID=4718
   
6. EventID 4798 (0x3E7) - Enumerates local groups for the User we’ved logged in as. Again, I chose a bad username of “User” for testing purposes. https://www.ultimatewindowssecurity.com/securitylog/encyclopedia/event.aspx?eventID=4798
   
7. EventID 4648 (0x3E7) - The sshd.exe process now logs on (RUNAS) as the Account “User”.
   
8. EventID 4624 (0x3E7) - Take note of the Logon Type, Virtual Account, and Elevated Token.
   
9. EventID 4672 (0x44C8A8) - “User” is given a bunch of privileges. Note the Logon ID of 0x44C8A8.
   • https://learn.microsoft.com/en-us/previous-versions/windows/it-pro/windows-10/security/threat-protection/auditing/event-4672
   • SeSecurityPrivilege - Manage auditing and security log
   • SeTakeOwnershipPrivilege - Take ownership of files or other objects
   • SeLoadDriverPrivilege - Load and unload device drivers
   • SeBackupPrivilege - Back up files and directories
   • SeRestorePrivilege - Restore files and directories
   • SeDebugPrivilege - Debug programs
   • SeSystemEnvironmentPrivilege - Modify firmware environment values
   • SeImpersonatePrivilege - Impersonate a client after authentication
   • SeDelegateSessionUserImpersonatePrivilege
10. EventID 4634 (0x44C8A8) - The “User” is now logged out which is interesting because I hadn’t closed the SSH Session yet. Note the Logon ID of 0x44C8A8. https://www.ultimatewindowssecurity.com/securitylog/encyclopedia/event.aspx?eventID=4634
    
11. EventID 4798 (0x3E7) - Repeat of Step 6 above.
    
12. EventID 4648 (0x3E7) - Repeat of Step 7 above.
    
13. EventID 4624 (0x3E7) - Repeat of Step 8 above.
    
14. EventID 4672 (0x44C907) - Repeat of Step 9 above.
    
15. EventID 4634 (0x44C61B) - The “sshd_4568” is now logged out and this correlates with closing the actual SSH Session.
    
16. EventID 4634 (0x44C907) - The “User” is now logged out and this correlates with closing the actual SSH Session.
    

Failed Login

When a user inputs a bad password, the logs are similar for Steps 1 - 10 above. There would be the obvious differences in Logon IDs and the “sshd_####” account.

1. EventID 4625 - The “User” account fails to login. https://www.ultimatewindowssecurity.com/securitylog/encyclopedia/event.aspx?eventid=4625
   
2. EventID 4634 - The “sshd_####” is now logged out and this correlates with closing the actual SSH Session.

Connect No Attempt

When a user connects but makes no attempt to enter a password, the logs are similar for Steps 1 - 10 above. There would be the obvious differences in Logon IDs and the “sshd_####” account.

1. EventID 4634 - The “sshd_####” is now logged out and this correlates with closing the actual SSH Session.

SSH Private/Public Key

Unlike Debian, authenticating with keys must be explicitly enabled in Windows. I had to modify the sshd_config file located at C:\ProgramData\ssh\sshd_config to allow connections using a public key. https://woshub.com/connect-to-windows-via-ssh/. One point to note, you can enable local logging to the sshd.log file. Again, this is not enabled by default and instead logs are stored in the Windows Event Logs.

By default the Private/Public keys are stored at %userprofile%\.ssh.

The Windows 11 Server saves the public key in the authorized_keys file located at %userprofile%\.ssh for the relevant user. They could also be stored at C:\ProgramData\ssh\administrators_authorized_keys for system-wide management.

Event Viewer

Under Applications and Services Logs -> OpenSSH -> Operational, we see a record for the successful login using a Public Key.

The Windows Logs -> Security records are no different from the standard username/password authentication.

tags: sunday funday - challenge