Note
Access to this page requires authorization. You can try signing in or changing directories.
Access to this page requires authorization. You can try changing directories.
Question
Tuesday, February 5, 2019 12:03 PM
Hello,
I have an SBS2011 Server which has been subjected to brute-force password guessing attempts.
Originally these attempts were resulting in Event 4625 entries with the Source IP address (external) and I was able to use a program to read the Event Logs and update the Windows Firewall config to block the activity.
More recently I am observing many 4625 events with no Source IP address or port being recorded.
It seems that there is a known bug where if NTLM is used by the attacker then for some strange reason Windows Server 2008 R2 / SBS2011 does not log the source IP address. This is really unfortunate. You can look this bug up for RDP over TLS/SSL although in my case it is OWA via SSL.
Nevertheless I have attempted to workaround this shortcoming by enabling logging of all successful connections in the Domain Profile of the Windows Firewall.
However when I inspect the firewall log and compare the timestamp with the Event 4625 in the eventlog; the only entries that I see in the firewall log are for the server IP address (as both source and destination)
After troubleshooting suggestions
Thanks
Regards,
Vaughan
All replies (8)
Wednesday, February 13, 2019 1:52 AM ✅Answered
Hello,
I have since reached a resolution of this issue
From the event 4625 I was aware that the calling process was w3wp.exe (i.e. IIS). However I had not investigated the actual calling process (i.e. the process ID).
I had assumed that to stop this activity I would need to stop IIS, which would not be a viable.
However, upon investigating the process ID, I discovered that the calling process was an Application Pool - MSExchangeServicesAppPool
It turns out that I can stop this Application Pool without disrupting OWA or Outlook Anywhere.
Since stopping this Application Pool, all the 4625 events without IP address details have ceased.
The remaining 4625 events have full details and as a result can be blocked
Regards,
Vaughan
Tuesday, February 5, 2019 12:08 PM | 1 vote
Have you checked this?
“Vote As Helpful” and/or “Mark As Answered” - MCSA - MCSE - http://www.ucsteps.com/
Tuesday, February 5, 2019 12:19 PM
Hello Thiago,
I had considered using a packet sniffer, and I still might do so.
However from a "solution" perspective I would prefer to enable some type of logging (e.g. the firewall logs) which I can read when the 4625 Event is missing the source IP address. That way I have an automated solution to this behaviour.
Somehow our public IP address has got onto some type of blacklist where we see a lot of password guessing attempts from many IP's. Early on I was blocking the addresses manually, but it soon became apparent that this wasn't going to be a viable approach.
Then I blocked via the IP address on the 4625 events, using a program, which stopped them cold for a few weeks. Now unfortunately they have found a work-around and so I need to as well.
Ideally I would like a 'fix' to the 4625 logging, but I don't think that exists.
What I need to understand is why the firewall logging is not logging the activity?
I guess I may need to use Network Monitor / Wireshark to identify some of the source IP's. But given the history, I am certain that the activity is still external - the question I have is why is the activity not being logged by the firewall?
Regards,
Vaughan
Wednesday, February 6, 2019 8:31 AM | 1 vote
Hi,
Have you got a chance to check this?
- Security Log in Event Viewer does not store IPs
https://serverfault.com/questions/399878/security-log-in-event-viewer-does-not-store-ips
There is one suggestion to use audit: Introducing Auditing Changes in Windows 2008
Thanks,
Jenny
Please remember to mark the replies as answers if they help.
If you have feedback for TechNet Subscriber Support, contact [email protected].
Wednesday, February 6, 2019 10:05 PM
Hello Josh,
No we don't have RDP exposed to the Internet
I have tried using the Windows Firewall to log all connections and surprisingly these connection attempts were not being logged initially. It seems perhaps that when using Windows Firewall logging, you need to configure logging on all profiles - not just Domain?
I can assure you that in this case the Event is not being caused by a stale hidden credential
Thanks
Vaughan
Wednesday, February 6, 2019 10:10 PM
Hello Jenny,
I've not read that specific article, but I have read others like it.
The 'solution' is to disable inbound NTLM traffic.
The trouble is that the server in question is an Exchange server, and when you disable inbound traffic Outlook clients can no longer connect to Exchange. So unfortunately the 'solution' is not an option in this case.
Thanks
Vaughan
Tuesday, February 12, 2019 8:51 AM
Hi Vaughan,
Since then, I think the proper resolution shall be what your mentioned in the beginning that involve other logging tool to capture and compare if the source IP has been logged.
Thanks,
Jenny
Please remember to mark the replies as answers if they help.
If you have feedback for TechNet Subscriber Support, contact [email protected].
Wednesday, February 13, 2019 2:53 AM
Hi Vaughan,
Glad to hear the issue has been resolved and thanks for sharing the details.
Best regards,
Jenny
Please remember to mark the replies as answers if they help.
If you have feedback for TechNet Subscriber Support, contact [email protected].