They seem so innocent if you spot them, and so complex once you dig into them: IP attacks. During a recent consulting gig, I had run in with a nasty little piece of software, DuBrute, which I spotted running on one (only one) of my client’s servers. DuBrute is a service that processes three text files in sequence: IP addresses, login names, and then passwords. Once running, it fires off logins and passwords until it exhausts the first IP address and repeats the process on down list one until the end. Cute and nasty.
In the Event Log the security section is usually dull reading. It is an endless series of SUCCESS AUDIT, SUCCESS AUDIT and so on for about 1000 entries. Every once in a long while a FAILURE AUDIT shows up and if you check it, usually it is just a local machine at, say, 192.168.1.159 not authenticating to the server for a moment at 7:02 am. That can be an SSID issue or the like, and using PROFWIZ bad SSID(s) these are very, very easy to fix. (It’s free at http://www.forensit.com/).
But then something happened at 2:20 am, a time when nobody is at work. This is the first sign of trouble, but probable cause is that the time frame is radically different in Spain or the Ukraine. The event log shows blast after blast after blast of rapid fire FAILURE AUDITS in sets of five, each repeated for about a 30 minute period. This went on for up to an hour.
Clicking on one of these events displays login names - odd names that I never created or simple names like “administrator” and the like. But the IP address is also displayed. Not local. I will not type them in here, to keep privacy but it was NOT of the 192.168 family, usually something like 27.152 and so forth. Some of these addresses, on a Sonicwall, can be traced to SPAM sites; there is one in Holland that is famous. But these are in the log on the Sonicwall and are not showing up in the Event log. The Sonicwall was not at issue here as the server in question did not HAVE a Sonicwall. The comparisons are not matching up at all.
So I tried an obvious test. I ran remote desktop on my system (not the client’s system) and entered the IP address for a connection. And I connected to a Windows 7 Professional machine in Russian language form and then to another one with a different IP address. Next, a Windows 2008 Enterprise Server, and another that was a Windows 2003 64-Bit server. All trying to blast into my client’s server.
There are websites that physically map the location of an IP address, and here more data came to light — literally servers and systems in Spain, Ukraine, California, and Princeton, NJ. Doubtless, others. I would have become really worried if one was based in (to remember Lex Luthor) Hackensack, New Jersey. But now the question is how to lock down the server.
I checked with the SANS Institute on this one as well as a fellow consultant. My contact at SANS is a long-time business reference who confirmed that these attacks are very sophisticated, and possibly the systems coming up as attack points are not even the originations of the attack itself, being used as hosts only. My co-consultant indicated that the Event Log event code of 10 indicates a port 3389 attack. This is the common port used for Internet traffic. He had a weak password and one of these attacks got into one of his client’s servers.
The hacker, as per good form, created his own account and privileges and stole god knows what. My colleague quickly shut down Port 3389 on the router, deleted the account, and applied real strength to the password. As I saw from DuBrute, running a simple text file of passwords, this is an excellent first step to take.
Resolution steps
I immediately put real iron and steel into an already complex password on my client’s server and in consultation with my client, kept it within a business syntax making it easy for them to understand and remember. On the router, I moved port 3389 to Internal IP only, knocking out the Internet through that port. The server itself performs DNS routing. I then tested Internet on the workstation level without issue. As I was using DYNDNS for remote access to the server, I added one layer of security I spotted on the router and, after punching port 3389 to, say, port 3051 on the server (in the registry), I allowed port 3051 ONLY to accept remote incoming from MY OWN HOST IP address from my IP provider. So only I can log into the server remote from MY network. Workstations maintained connection to the Internet. Lastly, I added a server LEGAL WARNING and STATEMENT to the registry to disable CTL-ALT-DEL and direct access by login to the server. The legal statement and warning can be added as keys and text to the following registry hive:
HKEY_LOCAL_MACHINE\SOFTWARE\Microsoft\Windows NT\CurrentVersion\Winlogon
Create two keys: LEGALNOTICECAPTION and LEGALNOTICETEXT and enter a plain text value for each of them, such as “Welcome to the CIA server” and a text message, “This server is continually monitored for security breaches. Beware all who enter here,” or some such statement of either real or whimsical nature. At any rate, to get to the login screen they have to hit an OK button to continue to the login screen. Password blasting is quickly terminated.
A good solid hardware firewall is next on my list, and may I commend WatchGuard firewalls for the small office. It’s FAR easier to set up and less complex internally than the systemic hell of a Sonicwall. Now I have to convince my clients, having done a good job above, that $400 is another good investment or else to support my evening time worrying about security at a local bar.
