Recently I had a client contact me. Their primary application is Oracle-based and was no longer functioning.  I quickly logged into the server and discovered immediately that it was hit with a Ransomware bug. The whole server was encrypted.

I didn’t even bother trying to investigate.  I shut the server down immediately and started the process of a full recovery.  That’s when I discovered that the Ransomware had also encrypted all of the local backups – not just for this server, but all backups for all systems.

Fortunately, I always push for redundant off-site backups.  In this case Acronis Cloud to the rescue.  It took about 4 hours but the server was fully restored to a time prior to the hack.  In that four hour period I did some investigation.

1. The account that I found logged in was named “admin”.  I confirmed that this account did not exist in Active Directory, therefore it was a local account to the server.
2. The server was using a custom RDP port, but that port was open to the public because there are third party Oracle specialists who occasionally have to service this system.

I wasn’t too worried about the admin account returning (though I did check) since it was a fully recovery, but I did review the local accounts. I still am not certain how the hackers got in, but I’m suspecting it was a man-in-the-middle RDP brute-force attack.

Anyway, long story short, the custom RDP port was restricted (no more public access) along with any other open server, and the server was restored fully with no real harm done.

However, this is only part of the story.  Over the past few weeks I’ve been encountering issues with other client networks being attacked.  Users are being locked out, sometimes instantaneously after having their passwords changed.  The security logs on the DC’s showed the same thing – a roughly 15 minute period where an unknown system (usually came up as MSTSC) was attempting to brute-force the the password.

This ended up presenting a whole field of frustration.  Microsoft Security Logs do not appear to record much in the way of relevant information.  It showed the username, usually without the domain, but not always, and MSTSC as the ‘Workstation’.  Since there is no system on the network named MSTSC I could only surmise that these were RDP attempts.  But to which system?  Several workstations have custom RDP ports open to the public.

After some searching I came up with a plan.

1. I need to see where the attacks are coming from and hopefully block them.  Are the attacks from a compromised PC on the network or from the outside?  To do this, I need to see what traffic is coming in on the router.  This will be a different blog entry.  Most of my clients have SonicWALL routers and as I discovered SonicWALL routers do not log Firewall Rule Hits.  I did find a way to monitor the traffic, but it wasn’t directly obvious so I’ll blog how to get monitoring working on SonicWALL routers.
2. I need to start monitoring the DC for invalid login attempts.  That’s what this blog entry is all about.
3. I need to be notified when attacks are happening.
4. I need to start pro-actively blocking the attacks.  I’m actually still looking for a solution for this.

So, monitoring the DC turned out to be an exercise in frustration. The Security Logging cannot be adjusted or adapted to provide more information. 

TCPView

A solution that I found proposed was to run TCPview.  Which I did and found it to be less than helpful.  For one thing, TCPview, while a fantastic tool, is also a bit of a pig, like most network monitoring utilities, and the overworked DC had issues running the program.  It’s also a reactive solution – you have to know the attack is happening to know to use the tool.

RDPGuard

I tried installing RDPGuard.  This is another excellent utility (Trial for 30 days only though) but discovered that unless the attacks were directed against the server itself, it wasn’t really going to help source the attack.  The attacks were against the workstations, not the servers, so while it functioned as expected, it didn’t really help.

Microsoft Network Manager

I installed the Microsoft Network Manager 3.4 and configured it for parsing Windows TCP captures.  However, this isn’t ideal either as again, this is a reactive solution that is based around extensive network monitoring, which is also a bit of a pig, and unless you capture huge amounts of data to parse, it’s window is too small.  Capturing even 5 minutes of data can be more than 1 GB of logging.  I did manage to run a capture while an attack was happening but was unable to determine exactly what protocol I should be monitoring.  I read that I should filter using ProtocolName == “NRPC” but that showed absolutely nothing.

Logon Auditing

Logon Auditing is a good idea regardless of whether you are having issues or not.  All administrators should know if user accounts are being accessed incorrectly, even if only to know which users are having trouble logging in.  Administrators shouldn’t be waiting for accounts to get locked out to determine if there’s an issue.  An issue could be there without getting to that stage.

This is the process I use to set up auditing:

1. GPO – Default Domain Controllers Policy
   (Click on the thumbnails to get the full picture)
    
2. GPO – Default Domain Policy
   
3. Download/Install Netwrix Account Lockout Examiner
4. Configure Account Lockout Examiner
   1. File –> Settings
   2. Managed Objects – Edit – set to All DC’s
   3. Notifications – Send notifications to a monitored email address and provide the SMTP server configuration (server and port)
      – does not do authenticated SMTP
   4. Add all users you want to monitor – including Administrator and Guest
      (I just add every user – you just know it’s the one you’re not watching that’s being hacked)

That’s it.  Wait for emails to come in or check on it regularly.  It runs as a service so even if the console is not running it’s still collecting data and sending notifications.

By turning on the Password Lockout settings hackers only get 10 attempts before the account is locked out for (at least) 15 minutes.  With enforced password complexity requirements, this would make brute force attacks pretty difficult.

The post Hardening RDP Security – Logon Auditing appeared first on Wiredwolf Canada.