Brute force attacks on Windows 2003 terminal server... what to do? 2

[1LUV1T]

Hey all, I am in need of urgent advice concerning a *critical* issue. Since about two weeks ago, I have log records of [unauthorized] Login Failures happening on my Terminal Server at off-peak records. I am using LANGuard Log Event monitor to help alert me to these things, so I have all the records:

Logon Failure:
Reason: Account currently disabled
User Name: administrator
Domain: MyDomain
Logon Type: 10
Logon Process: User32
Authentication Package: Negotiate
Workstation Name: TSServer
Caller User Name: TSServer$
Caller Domain: MyDomain
Caller Logon ID: (0x0,0x3E7)
Caller Process ID: 10732
Transited Services: -
Source Network Address: 216.241.54.50
Source Port: 17369

This set off a red alert for me because the administrator account is and always has been disabled. What is the proper response to an intrusion? Never really had to go on the defense on behalf of a client before.

 

[Roadki11]

What do you have for perimeter defense? You should have a firewall device or at least a decent router. I would start by blocking the source address with an ACL or whatever your perimeter device is capable of.



RoadKi11

"This apparent fear reaction is typical, rather than try to solve technical problems technically, policy solutions are often chosen." - Fred Cohen

 

[1LUV1T]

Sorry for not being specific. On the perimeter, there is a Linksys 4-port VPN router with the default/strict security settings on. Software-wise, we have a firewall/antivirus running across the network. The defense part, *I think* I can manage. I guess my question is, how would I go about reporting the intruder to the ISP (since the IP address is clearly logged, although may be spoofed/proxied)? How would I go about deeper inspection as to what type of attack this is? The source port is very strange.

 

[Roadki11]

Well you always want to try and stop an attack as far out from you as possible. This is usually your perimiter as ISPs generally dont give you much help and it can take a lot of time. So... i would start at your router and firewall and block that IP then if you want work your way out thats fine. I did a simple reverse nslookup of that IP and the is the results:

Reverse Lookup Results
Host Type Value
50.54.241.216.in-addr.arpa PTR 216-241-54-50.static-ip.telepacific.net.

IP Address Contact Information
TELEPACIFIC COMMUNICATIONS CORPORATION TELEPACIFIC (NET-216-241-48-0-1)
216.241.48.0 - 216.241.63.255
Millwall Inc MILLWALLINC (NET-216-241-54-48-1)
216.241.54.48 - 216.241.54.63

As you can see the ISP is Telepacific but your problem address seems to be part of a block owned by Millwall Inc. Now a simple google search for Millwall Inc produced this:

Millwall Inc
Local (702) 270-6331
6680 Amelia Earhart Ct Ste 100
Las Vegas, NV 89119

They could have a compromised pc or a bored employee either way maybe a call to the IT guy and ask him what the heck is going on may be in order.




RoadKi11

"This apparent fear reaction is typical, rather than try to solve technical problems technically, policy solutions are often chosen." - Fred Cohen

 

[1LUV1T]

This is great information RoadKi11, thank you.
I will call the company directly and go from there.

 

[1LUV1T]

Interestingly enough, I reached some one at the company. It seems as though they have a worm loose on their network. They are aware of the problem as others have reported to them the same thing. I gave them some suggestions since they do not have an internal IT dept.

My last question is, in terms of the worm, why of all the terminal servers on the Internet would it by hitting my server? I know worms spread, I get the concept, but what are the chances that it hits my server? Does it base it off servers that were visited at some point from that local machine?

 

[Roadki11]

You are just "lucky", maybe you are on the same subnet, maybe not. It takes very little effort to scan huge swaths of the internet for open ports. If you have port 80 open to the internet you should check those logs once, you wont believe the crap people throw at port 80 to try and break in. Which brings me to another point, always best to run standard services on nonstandard ports whenever its possible. Here is a good link that explains how and why and has a little app that helps you do it.

http://www.codeproject.com/KB/system/ts_port_utility.aspx

RoadKi11

"This apparent fear reaction is typical, rather than try to solve technical problems technically, policy solutions are often chosen." - Fred Cohen

 

[1LUV1T]

Which brings me to another point, always best to run standard services on nonstandard ports whenever its possible"
I couldn't agree more, however, in the case of this terminal server environment, it would be extremely time consuming to reconfigure the "average user's" RDP file to add that ort# on each workstation.

Also I knew the source IP address looked familiar, because you are correct, we are somehow "connected". I checked one of the backup DSLs that is just sitting there for backup purposes, and the company is on a 216.xxx.xxx.xxx network and probably same subnet. Which explains why we were "lucky".

Thanks for your help.

 

[allywilson]

You could also try just adding the following to a logon script (if the users have writable access). Failing that put it in a group policy:

reg add "HKLM\SYSTEM\CurrentControlSet\Contr
ol\Terminal Server\WinStations\RDP-Tcp" /v PortNumber /t REG_DWORD /d 1445

Believe a restart of the service/PC will be needed though.

 

[allywilson]

Apologies, try this:

reg add "HKLM\SYSTEM\CurrentControlSet\Control\Terminal Server\WinStations\RDP-Tcp" /f /v PortNumber /t REG_DWORD /d 1445

The /f forces it to overwrite without prompting.

 

[Hondy]

really your RDP port shouldnt be exposed to the internet, you have a VPN router so all connections to the server should be via the VPN. i.e. if you don't have the login details for the VPN then you don't even see the RDP port.

The only ports that should be visible to the internet publicly are those which you want the public to access, e.g. port 80 on a web server.

Changing standard ports are fine, but if they are still available to the public someone will run a port scan and find it easily enough.

If you insist on it being publicly available then choose a port number that isn't already a common port that someone will stumble across accidentally.

My immediate thoughts are to check and see what other ports/services are publicly available and subject to other worms/hackers.

I hope some of that is useful.

 

[1LUV1T]

allywilson, can you please clarify what your reg script does and also what '1445' means in the example?

Hondy, I understand what you mean, however, most companies don't like to stray from the norm especially if they are dealing with outside consultants. They prefer that every thing is by the book so the "next IT guy" or the VP of _dept_ who is "computer savvy" can easily understand what's going on. Therefore, the standard RDP, PCA, FTP, SQL, ORACLE are usually better left alone (not in my opinion).

 

[Hondy]

AOConsulting, I hear you, my point was that you shouldn't be exposing RDP to the internet whether its 3389 or a newly chosen port that the other guys are asking you to try.

You should use a VPN to access RDP and other non-public services. If you need to get other people to RDP in then you just give them the VPN details if necessary.

Random people on the internet should not have access to this port, if an exploit is discovered or someone bruteforces/guesses the login info then someone will have full access to your servers.

HTH

 

[1LUV1T]

I will pitch it to management again when the time is right. I absolutely agree with you.

Can you tell me what this script does;
reg add "HKLM\SYSTEM\CurrentControlSet\Contr
ol\Terminal Server\WinStations\RDP-Tcp" /v PortNumber /t REG_DWORD /d 1445

and what is 1445? thanks in advance.

 

[Roadki11]

Its changing the listening port on the TS from 3389 to 1445 via the registry. Port 1445 is just a port off the top of his head im sure, it can by any port you want, but its best to try and use a port that isnt already dedicated to some other service in RFC or a port that isnt a known worm/trojan port.



RoadKi11

"This apparent fear reaction is typical, rather than try to solve technical problems technically, policy solutions are often chosen." - Fred Cohen

 

[Hondy]

okies "security through obscurity" as its known is better than nothing.

Interestingly, I can't find a worm or virus that targets 3389/RDP although I never spent too long looking. I'm not saying there isn't one, but it certainly does sound that someone or something is trying to brute force your administrator account so keep an eye out for other account names appearing such as your email users like "sales" etc. especially if you move the port!

Anyone know the name of an RDP worm as suggested by the people he phoned?

I digress, this wasn't you question, just interested!

 

[1LUV1T]

Ok I'm definately not sure why I am so "lucky" this week but combing through the logs this morning, I've detected another IP address trying to get in as Adminsitrator into one of my servers. I followed the procedure above and did a reverse lookup. I ended up emailing the company instead of calling. It is a completely different IP and the company is out in Texas -- coincidentally, they are an IT consulting company.

 

[Hondy]

did you change the port? Are these new probes on 3389 or a new one?

 

[1LUV1T]

The original source port was: 17369
This source port is: 2150

Not sure if that means much :/

My guess is, the first company who has the worm, is getting assistance from this "IT consulting company" and they are either bored or have the machine in their possession. But i'm no Sherlock so maybe it is just a coincidence.

 

[Hondy]

well if you shift your port as meintioned by the above registry changes then this should go away. You may want to look at the free tool 2xRDPsecure

http://www.msterminalservices.org/articles/Brute-Force-Hacking-Terminal-Server-Environments.html

Also, i couldn't find much on RDP viruses but there is a tool called TSGrinder mentioned in the article that sounds remarkably like what you are experiencing