Have you ever noticed that in many cases of account logon, in windows system, only ip address is present and not the actual workstation name. If you are not sure what I mean, then look into some of the logon events like 4624, 4625 etc. In audit log for this events you can easily find the ip address of the machine from where logon event were generated but not the name of the workstation. There are various reasons for this happening but importantly there are three specific reason.
Example: Event id 4624
{
"EventTime": "2017-10-09 05:00:00", "Hostname": "LPWXDC.ChangeMe.local", "Keywords": -9214364837600034816, "EventType": "AUDIT_SUCCESS", "SeverityValue": 2, "Severity": "INFO", "EventID": 4624, "SourceName": "Microsoft-Windows-Security-Auditing", "ProviderGuid": "{54849625-5478-4994-A5BA-3E3B0328C30D}", "Version": 1, "Task": 12544, "OpcodeValue": 0, "RecordNumber": 409583434, "ProcessID": 824, "ThreadID": 19048, "Channel": "Security", "Message": "An account was successfully logged on.", "Category": "Logon", "Opcode": "Info", "SubjectUserSid": "S-1-0-0", "SubjectUserName": "-", "SubjectDomainName": "-", "SubjectLogonId": "0x0", "TargetUserSid": "S-1-5-18", "TargetUserName": "LPW", "TargetDomainName": "LP", "TargetLogonId": "0x1828eb397", "LogonType": "3", "LogonProcessName": "Kerberos", "AuthenticationPackageName": "Kerberos", "LogonGuid": "{FD1B49BA-A5E9-5D7D-D3F4-D925B43807F2}", "TransmittedServices": "-", "LmPackageName": "-", "KeyLength": "0", "ProcessName": "-", "WorkstationName": "-", "IpAddress": "10.0.2.10", "IpPort": "60208", "ImpersonationLevel": "%%1833", "EventReceivedTime": "2017-10-09 05:00:00", "SourceModuleName": "wineventlog_in", "SourceModuleType": "im_msvistalog"
}
Example: Event id 4624
{
"EventTime": "2017-10-09 05:00:00", "Hostname": "LPWXDC.ChangeMe.local", "Keywords": -9214364837600034816, "EventType": "AUDIT_SUCCESS", "SeverityValue": 2, "Severity": "INFO", "EventID": 4624, "SourceName": "Microsoft-Windows-Security-Auditing", "ProviderGuid": "{54849625-5478-4994-A5BA-3E3B0328C30D}", "Version": 1, "Task": 12544, "OpcodeValue": 0, "RecordNumber": 409583434, "ProcessID": 824, "ThreadID": 19048, "Channel": "Security", "Message": "An account was successfully logged on.", "Category": "Logon", "Opcode": "Info", "SubjectUserSid": "S-1-0-0", "SubjectUserName": "-", "SubjectDomainName": "-", "SubjectLogonId": "0x0", "TargetUserSid": "S-1-5-18", "TargetUserName": "LPW", "TargetDomainName": "LP", "TargetLogonId": "0x1828eb397", "LogonType": "3", "LogonProcessName": "Kerberos", "AuthenticationPackageName": "Kerberos", "LogonGuid": "{FD1B49BA-A5E9-5D7D-D3F4-D925B43807F2}", "TransmittedServices": "-", "LmPackageName": "-", "KeyLength": "0", "ProcessName": "-", "WorkstationName": "-", "IpAddress": "10.0.2.10", "IpPort": "60208", "ImpersonationLevel": "%%1833", "EventReceivedTime": "2017-10-09 05:00:00", "SourceModuleName": "wineventlog_in", "SourceModuleType": "im_msvistalog"
}
These are three reasons for this :
- There is no secure method for the KDC to get the remote machine's name at the current time. If the client provides the name (as in NTLM), then it's not trustworthy and can be spoofed. There are Unix-based hacking tools which spoof workstation name in NTLM auth requests.
- DNS and NetBIOS reverse lookup are not secure and are not reliable- if we tried this, we'd have a high incidence of incorrect or missing information, and hurt performance.
- Even if we chose to do add the name anyway, when we could, there's no field for us to use to carry it in Kerberos AS REQ & TGS REQ messages- we'd have to overload some other field, and run a high risk of loss of compatibility with MIT's reference implementation.
No comments:
Post a Comment