Something hammering admin account logins

[MobileTechie]

Client's SBS 2008 system. I went to RDP in and the usual admin account was locked out. I used the backup admin account to get on and checked the security logs and there were tons of failed logins. Unlocking the account worked but was relocked almost instantly afterwards.

I changed the account username and now there are failed server logins every few seconds using the old account name. So clearly something or someone is hammering that login. However there is minimal info in each error report - no IP or anything so I'm assuming it's coming from the server itself?

I've pasted a sample error report below. I've run a script to see if any services are using this account as a logon but apparently not. Any idea how to track this down?

Cheers

An account failed to log on.

Subject:
Security ID: NULL SID
Account Name: -
Account Domain: -
Logon ID: 0x0

Logon Type: 3

Account For Which Logon Failed:
Security ID: NULL SID
Account Name: adminaccountname
Account Domain:

Failure Information:
Failure Reason: Unknown user name or bad password.
Status: 0xc000006d
Sub Status: 0xc0000064

Process Information:
Caller Process ID: 0x0
Caller Process Name: -

Network Information:
Workstation Name:
Source Network Address: -
Source Port: -

Detailed Authentication Information:
Logon Process: NtLmSsp
Authentication Package: NTLM
Transited Services: -
Package Name (NTLM only): -
Key Length: 0

 

[TurricanII]

Have ypu got rdp exposed to the world? Check in the event log under remote desktop or terminal services.

Check smtp log files for odd connections at same time as event log entries

May be smtp authentication dictionary attack

 

[NYJimbo]

Change the RDP port to something high. Make sure your firewall is not blocking it before you switch. That might give you some time to test ideas.

 

[MobileTechie]

RDP is already mapped to a different 5 figure port. Also, when we've had external attacks it's always given an IP address and usually a port. These don't have that, leading me to think they are internal - maybe something on the server itself.

The admin account (I changed the name) is a random word not guessable or known outside of 2 or 3 people in the organisation. No emails have ever been sent to or from it so I'm struggling to see how anyone could be targeting.

 

[TurricanII]

1 bit of malware on a workstation at any point in the past might have scraped your whole active directory. once that is done you'll be getting spam to rarely used email addresses, forged emails seeming from internal addresses, attacks against admin accounts etc

From a workstation as a normal user type ldifde -f ad.txt
Then open ad.txt - it's all there!

Rename the admin accounts after checking for scheduled tasks and services that may be using the credentials.

Also do a proper full port scan from outside and ensure you have not accidentally opened full server access. This is easily done by setting a DMZ server on some models of modem

 

[nlinecomputers]

1 bit of malware on a workstation at any point in the past might have scraped your whole active directory. once that is done you'll be getting spam to rarely used email addresses, forged emails seeming from internal addresses, attacks against admin accounts etc

From a workstation as a normal user type ldifde -f ad.txt
Then open ad.txt - it's all there!

Rename the admin accounts after checking for scheduled tasks and services that may be using the credentials.

Also do a proper full port scan from outside and ensure you have not accidentally opened full server access. This is easily done by setting a DMZ server on some models of modem

this! I'm betting that you have a service trying to access using old admin credentials.

 

[fencepost]

Not sure it's quite as simple as that, but yeah I'm pretty sure querying as much as possible from AD is easy to do.

For ldifde, the docs note that it's available on servers with the AD DS or LDS roles installed and that it needs to be run from an elevated command prompt. I haven't tried tracking it down and copying it to a member server or workstation or running it without permissions.

 

[Markverhyden]

Personally I'd never expose RDP to the wild. Always VPN first, then RDP.

 

[fencepost]

I have one where RDP is only opened after a port knocking sequence, which whitelists the remote IP for 30 days. That client has a bunch of people working remote from home PCs and Macs that I don't have (or want) much control over, so I'm just as happy to not have to worry about a separate zone for VPN connected users that's just as untrusted as the wide open Internet.

The 30 days was a compromise number and if I were doing it again I'd probably set it at 7 5 days 18 hours instead - I wanted something long enough to not be annoying, but short enough that when it expired people would still remember the whole whitelisting/port knocking thing. Years ago the customer had RDP wide open, and my first approach at locking it down was to block remote IPs that had too many failed logins (identified by # of new connections vs established ones within a time period - basically what fail2ban does) but while that blocked the mass probes I was seeing in the logs it did nothing for the slower attempts that could also be happening. Block by default is much better.

edit: changed the "what I'd do now" time down to ensure that ones done Monday would expire over the weekend even if it was a long weekend with Monday off, without much risk of it expiring during a regular workday "Hey, I just lost connection!"

 

[TurricanII]

Each failed login may generate a few security log entries, some event log entries should have more info.

Logon Type: 3 = NETWORK LOGON which means NOT on the server itself - see http://www.windowsecurity.com/articles-tutorials/misc_network_security/Logon-Types.html

I might change the 5 digit RDP port and set the firewall to log any attempts to connect to the OLD port number. That should alert you to the remote IP that is trying to connect. If the firewall will not allow you to do this then you can run the free attacker program http://www.mcafee.com/us/downloads/free-tools/attacker.aspx

Set attacker.exe to listen on an available high port on the server or a PC, then forward the old RDP port through to attacker.exe's port. Attacker.exe will log any remote IP addresses and reverse DNS that establish a connection and will beep if anyone connects - boom!

If you must open RDP directly then I would restrict access to it from your office IP address if possible, either on the hardware firewall or the Windows SBS firewall. Via a VPN is best as Mark says and port knocking is better than nowt like Fencepost says.

 

[E Bell]

One of the benefits of SBS and Server Essentials is the RWA (Remote Web Access); however, one of the headaches is RWA. The benefit is remote access to files/folders and RDP. The downside is you have to authenticate to the web side using your network credentials. If this is turned on this is probably your issue. A way to combat this is locking accounts after unsuccessful logins. This does fall a little short as whoever is trying to brute force their way is still doing it...just with different logins. What you need to implement is an IDS/IPS solution.

I too have a client that saw an increase in this type of behavior. I went to login with a secondary admin account and it was locked. The solution I went with, for a number of reasons, was a software solution called Cyberarms IDDS (https://cyberarms.net/). Their software is similar, in concept, to fail2ban for Linux. One large benefit is they just changed their licensing model to a support model.

Their software is easy to implement because you do no need to know the port numbers nor the what to look for in the error logs. They have agents that you can enable based on the following:

Within the first 24 hours I had logged over 500 successful login attempts.. Since implementing the solution on November 3rd, there have been 3,571 failed login attempts and 529 hard locks (banned IPs).

Now, you could say: "Just turn off RWA!" Well, when you have a client that relies on this then it is hard to turn off after the fact. So the next best solution is to implement a IDS/IPS solution.

 

[YeOldeStonecat]

I don't mind exposing RDP....so long as you've secured your accounts (especially Administrator) and you have it set to cancel "listen mode" after X amount of failed logins (this really REALLY cuts down on the grinding) Plus you have your own backdoor service admin account.
However, like E Bell mentioned above, since you have SBS...you have RWW/RWA. All you need is port 443. Never open 80. You don't need 80. Just 443.

Next...use business grade firewalls. When you note attacks coming from the same IPs....just block them in the firewall. Better yet...for businesses, I always push (very hard)...UTMs, not just plain NAT routers. IMO, businesses should be protected behind a UTM. Plain old NAT is inadequate for a business. The better quality UTMs have attack blockers, deep strong adaptive DPI, IDS.IPS. Let a good UTM firewall work its magic and protect things on the fly.

 

[MobileTechie]

Thanks for the suggestions.

As I suspected it wasn't from outside the network but from within. But why it doesn't log the workstation name (which would have made it a lot easier to track down) I don't know.

I've isolated the problem now and it's the MD's own computer.I upped the security auditing and found some other items which pointed at this workstation and a simple on/off test confirms it. His computer is on 24/7 hence the round-the-clock hammering. No malware or suspicious processes appear to be running. It would seem it, or something running on it, has old credentials. I'm trying to track it down right now.

I won't run through the setup now but they already have a SonicWall UTM, port 80 is already blocked. I'll look at the idea of VPNing in before RDP.

Actually I'm thinking of maybe some multifactor service like DUO - any of you guys use MFA on client servers and if so what?

 

[MobileTechie]

I've tracked it down to one service which is the desktop's TermServices "Remote Desktop Services". When disabled, no problem, when enabled it locks the user out in AD. Not sure why since TermServices service uses the Network Service account to logon which of course has no password. So must be something else going on.

Anyway, I've worked around it by just changing the user's username so that the errant service is knocking on the wrong door and not locking them out. But I would like to fix it anyway.

The security audit failure errors look like this:

Log Name: Security
Source: Microsoft-Windows-Security-Auditing
Date: 13/12/2016 15:03:24
Event ID: 4776
Task Category: Credential Validation
Level: Information
Keywords: Audit Failure
User: N/A
Computer: servername.domain.local
Description:
The domain controller attempted to validate the credentials for an account.

Authentication Package: MICROSOFT_AUTHENTICATION_PACKAGE_V1_0
Logon Account: USERNAME
Source Workstation:
Error Code: 0xc0000064
Event Xml:
<Event xmlns="http://schemas.microsoft.com/win/2004/08/events/event">
<System>
<Provider Name="Microsoft-Windows-Security-Auditing" Guid="{54849625-5478-4994-a5ba-3e3b0328c30d}" />
<EventID>4776</EventID>
<Version>0</Version>
<Level>0</Level>
<Task>14336</Task>
<Opcode>0</Opcode>
<Keywords>0x8010000000000000</Keywords>
<TimeCreated SystemTime="2016-12-13T15:03:24.410Z" />
<EventRecordID>4385017</EventRecordID>
<Correlation />
<Execution ProcessID="656" ThreadID="7656" />
<Channel>Security</Channel>
<Computer>KHSERVER.keyholding.local</Computer>
<Security />
</System>
<EventData>
<Data Name="PackageName">MICROSOFT_AUTHENTICATION_PACKAGE_V1_0</Data>
<Data Name="TargetUserName">MPIPKIN</Data>
<Data Name="Workstation">
</Data>
<Data Name="Status">0xc0000064</Data>
</EventData>
</Event>

 

[TurricanII]

I can't imagine how the Remote Desktop Service, that accepts inbound stuff, might lock a password on the DC unless your firewall exposes that PC's remote desktop to the Internet and someone is hammering it from outside. Also perhaps an infected PC on the LAN is being used to target the PC in question. I'd check the Event Log > Microsoft > Windows > TerminalServices LocalSessionManager and RemoteconnectionManager operational log files to see if any IP addresses/further info appears.

Did the PC user/a previous staff member use Remote Desktop Gateway coming in via HTTPS on a server somewhere with old credentials?

Maybe disable Remote Desktop on the PC then run attacker.exe per post #10 and have it listen on TCP port 3389 - anything trying to connect?

 

[putz]

You can verify RD connection activity by viewing the TerminalServices-LocalSessionManager Operational event log. Check the logs to see if any times match up when the account locks out. If you dont see anything there, turn on logging on the windows firewall for accepted and denied connections and check there for timestamps to see if you can find IP address and Port/Service.