7

When I use the new remote desktop with ssl and try to log on with bad credentials it logs a 4625 event as expected. The problem is, it doesn't log the ip address, so I can't block malicious logons in our firewall. The event looks like this:

<Event xmlns="http://schemas.microsoft.com/win/2004/08/events/event">
    <System>
        <Provider Name="Microsoft-Windows-Security-Auditing" Guid="{00000000-0000-0000-0000-000000000000}" /> 
        <EventID>4625</EventID> 
        <Version>0</Version> 
        <Level>0</Level> 
        <Task>12544</Task> 
        <Opcode>0</Opcode> 
        <Keywords>0x8010000000000000</Keywords> 
        <TimeCreated SystemTime="2012-04-13T06:52:36.499113600Z" /> 
        <EventRecordID>467553</EventRecordID> 
        <Correlation /> 
        <Execution ProcessID="544" ThreadID="596" /> 
        <Channel>Security</Channel> 
        <Computer>ontheinternet</Computer> 
        <Security /> 
    </System>
    <EventData>
        <Data Name="SubjectUserSid">S-1-0-0</Data> 
        <Data Name="SubjectUserName">-</Data> 
        <Data Name="SubjectDomainName">-</Data> 
        <Data Name="SubjectLogonId">0x0</Data> 
        <Data Name="TargetUserSid">S-1-0-0</Data> 
        <Data Name="TargetUserName">notauser</Data> 
        <Data Name="TargetDomainName">MYSERVER-PC</Data> 
        <Data Name="Status">0xc000006d</Data> 
        <Data Name="FailureReason">%%2313</Data> 
        <Data Name="SubStatus">0xc0000064</Data> 
        <Data Name="LogonType">3</Data> 
        <Data Name="LogonProcessName">NtLmSsp</Data> 
        <Data Name="AuthenticationPackageName">NTLM</Data> 
        <Data Name="WorkstationName">MYSERVER-PC</Data> 
        <Data Name="TransmittedServices">-</Data> 
        <Data Name="LmPackageName">-</Data> 
        <Data Name="KeyLength">0</Data> 
        <Data Name="ProcessId">0x0</Data> 
        <Data Name="ProcessName">-</Data> 
        <Data Name="IpAddress">-</Data> 
        <Data Name="IpPort">-</Data> 
    </EventData>
</Event>

It seems because the logon type is 3 and not 10 like the old rdp sessions, the ip address and other information is not stored.

The machine I am trying to connect from is on the internet and not on the same network as the server.

Does anyone know where this information is stored (and what other events are generated with a failed logon)?

Any help will be much appreciated.

1

3 Answers 3

8

Using TLS/SSL as encryption for the RDP protocol, Windows does not log the IP address of the user trying to log in. When you configure the server to encrypt the protocol with the (legacy) RDP encryption, it writes the IP address into the security event log.

You will have to make a trade-off. Either you will have a less secure protocol encryption or you will never know the source of a potential attack. Having the right intrusion detection system (can be downloaded for free), the system will automatically lock out the potential attacker after a defined number of invalid logins.

Read more about RDP security and intelligent intrusion detection and defense here: https://cyberarms.net/security-blog/posts/2012/june/remote-desktop-logging-of-ip-address-(security-event-log-4625).aspx

2
  • 1
    Stop spreading FUD! FYI, see my answer on how to both use SSL (i.e. confirmed server identity w/ no warnings on clients) and get Source Network Address in Event ID 4625 in the audit log.
    – wqw
    Oct 17, 2015 at 12:55
  • I don't think this is true in Win10, as my honeypot is logging RDP successes and failures just fine, with IPs and with TLS enabled.
    – user145837
    Aug 7, 2019 at 3:16
4

In secpol.msc open Local Policies | Security Options set Network security: Restrict NTLM: Incoming NTLM traffic to Deny all accounts. This cannot be used with NLA but works with SSL (the SSL info icon on the topbar of mstsc.exe client confirms server identity) and sucessfully records source network address in failed Event ID 4625 in the audit log.

Here is my before log

Oct 17 13:59:22 TS04.ucssaas.local rdp-farm: {"EventTime":"2015-10-17 13:59:22","Hostname":"TS04.ucssaas.local","Keywords":-9218868437227405312,"EventType":"AUDIT_FAILURE","SeverityValue":4,"Severity":"ERROR","EventID":4625,"SourceName":"Microsoft-Windows-Security-Auditing","ProviderGuid":"{54849625-5478-4994-A5BA-3E3B0328C30D}","Version":0,"Task":12544,"OpcodeValue":0,"RecordNumber":1366552,"ProcessID":568,"ThreadID":35244,"Channel":"Security","Category":"Logon","Opcode":"Info","SubjectUserSid":"S-1-0-0","SubjectUserName":"-","SubjectDomainName":"-","SubjectLogonId":"0x0","TargetUserSid":"S-1-0-0","TargetUserName":"wqw","TargetDomainName":"UCSSAAS","Status":"0xc000006d","FailureReason":"%%2313","SubStatus":"0xc000006a","LogonType":"3","LogonProcessName":"NtLmSsp ","AuthenticationPackageName":"NTLM","WorkstationName":"CVETKOV-C3414E6","TransmittedServices":"-","LmPackageName":"-","KeyLength":"0","ProcessName":"-","IpAddress":"-","IpPort":"-","EventReceivedTime":"2015-10-17 13:59:24","SourceModuleName":"eventlog","SourceModuleType":"im_msvistalog"}#015

and after

Oct 17 14:00:36 TS02.ucssaas.local rdp-farm: {"EventTime":"2015-10-17 14:00:36","Hostname":"TS02.ucssaas.local","Keywords":-9218868437227405312,"EventType":"AUDIT_FAILURE","SeverityValue":4,"Severity":"ERROR","EventID":4625,"SourceName":"Microsoft-Windows-Security-Auditing","ProviderGuid":"{54849625-5478-4994-A5BA-3E3B0328C30D}","Version":0,"Task":12544,"OpcodeValue":0,"RecordNumber":2613410,"ProcessID":564,"ThreadID":17112,"Channel":"Security","Category":"Logon","Opcode":"Info","SubjectUserSid":"S-1-5-18","SubjectUserName":"TS02$","SubjectDomainName":"UCSSAAS","SubjectLogonId":"0x3e7","TargetUserSid":"S-1-0-0","TargetUserName":"wqw","TargetDomainName":"UCSSAAS","Status":"0xc000006d","FailureReason":"%%2313","SubStatus":"0xc000006a","LogonType":"10","LogonProcessName":"User32 ","AuthenticationPackageName":"Negotiate","WorkstationName":"TS02","TransmittedServices":"-","LmPackageName":"-","KeyLength":"0","ProcessName":"C:\\Windows\\System32\\winlogon.exe","IpAddress":"109.199.229.32","IpPort":"0","EventReceivedTime":"2015-10-17 14:00:37","SourceModuleName":"eventlog","SourceModuleType":"im_msvistalog"}#015

Basicly source WorkstationName is lost and now it show RDSH server name instead but you get IpAddress in exchange. This shows the change that happened underneath "LogonType":"3","LogonProcessName":"NtLmSsp ","AuthenticationPackageName":"NTLM" is changed to "LogonType":"10","LogonProcessName":"User32 ","AuthenticationPackageName":"Negotiate"

I'm using this setting on several Win2012 R2 session hosts and did tests with several sucessful/failed logon sessions from mstsc.exe clients on Win XP machines (latest mstsc.exe version 6.1.7600 for XP).

(The log above is from rsyslog on a haproxy load-balancer that collects audit logs from RDSH boxes that are being forwarded by nxlog service in JSON format. There is a fail2ban jail on the haproxy that blocks clients by IP after a number of failed logon attempts.)

5
  • I have installed all updates on both server (Win2k12R2) and client (Win10), but when I follow these instructions, I get the following error trying to log-on: "An authentication error has occurred. The function requested is not supported This could be due to CredSSP encryption oracle remediation. For more information, see go.microsoft.com/fwlink/?linkid=866660"
    – tommed
    Aug 8, 2018 at 19:52
  • I'm using this setup in production in an AD domain with a separate RD connection broker server for the RD farm, not sure which one makes the difference.
    – wqw
    Aug 10, 2018 at 11:44
  • @tommed you must turn of NLA
    – jjxtra
    Aug 13, 2020 at 1:49
  • Please note that when this option is activated, the user can no longer log in with the RDP credentials stored on the the computer. The server opens a log in screen on which the user must log in manually.
    – Sam Sirry
    Mar 20, 2021 at 8:56
  • 1
    @SamSirry It depends on if the user is already logged in to any other server in the RDSH farm although it's true this somehow alters standard logon behavior. A positive effect is that bots are not able to follow this somewhat weird logon sequence and brute force attacks are kept to a minimum.
    – wqw
    Mar 21, 2021 at 13:53
0

I have found this article about log files for RDP session. I hope it will be helpful to you.

http://forums.techarena.in/windows-security/838814.htm

I don't see one either - what is the problem specifically?

Taking a guess based on the Subject, check the Windows XP Security Event Viewer Log. An Audit Policy may be configured using the Group Policy editor to track logon success and failures: From the Start | Run command window type gpedit.msc. Navigate to Local Computer Policy | Computer Configuration | Windows Settings | Security Settings | Local Policies | Audit Policy | Audit logon events. Highlight and right-click and select properties. Configure as desired.

Note that logging in without a password is logged as a failure. This results in the security log filling up very fast if you log failures and have a user without a password. The result is you can not login normally. Also note, not having a password is a potential and probable security risk.

The event log can be viewed by going to Start | Control Panel | Performance and Maintenance | Administrative Tools and click on Event Viewer.

The Event Log (Security) noting a successful logon and logoff by a remote user. The user can highlight a log entry and right-click to view the event Properties for detailed information.

Look in the Security Event Log for a Logon/Logoff Event 528 and Logon Type 10.

The free Microsoft Port Reporter tool provides for additional logging. Description of the Port Reporter Parser (PR-Parser) tool http://support.microsoft.com/default...b;en-us;884289

Availability and description of the Port Reporter tool http://support.microsoft.com/kb/837243

You must log in to answer this question.

Not the answer you're looking for? Browse other questions tagged .