Digging into DDoS attacks (includes hostile IP's from multiple honeypots)

Question

I have been tracing a series of DDoS attempts, and am wondering if anyone else has seen anything like them.

I've downloaded the following Powershell script which scrapes Terminal Server (RDP) Event Logs and dumps them to CSV. I've modified the script to execute against all of my servers and dump the entire result set into a CSV so I can see a full-network view of whats happening.

Powershell Script to scrape Terminal Server Event logs

---

Section A: DDoS patterns

(Based on the results of the above PowerShell script to pull TS\RDP event log data):

1. Machine Names\Login: WIN-XXXXXXXXXXX\Administrator. More than 90% of the attacks come from machines with this name format, including

   • WIN-8ROR2EODLHP\Administrator
   • WIN-NR0D8EUPULR\Administrator
   • WIN-FSIMHI55CBM\Administrator

to name a few (with over 80 different machine names following this format since Feb 2011).

2. Each machine name makes a series of "reconnect" and "disconnect" attempts against a range of my servers over a short period of time (lasting anywhere from a few seconds to roughly no more than 20 minutes) and then that computer name is never seen again. The IP addresses all show "LOCAL" or blank (nothing). Dating as far back as February 2011, these attacks started off months apart but have slowly increased. Today I see 3-4 groups of attacks per day.

3. On the frontend of my network, I am running a self-made DDoS Sniffer which detects stale RD connections (like the DDoS attacks) and will automatically disconnect the session and blacklist the IP address. This prevents the attacks from bringing down my RDP services.

---

Section B: Honeypotting the attacker

So I created an isolated "honeypot" VM without Domain or internal network access and redirected questionable network traffic to it, allowing a single DDoS attack to successfully instantiate a remote session from a spoofed reconnect attempt, to this machine.

Here's what happened:

1. They attempted to install a trojan, Trojan:Win32/Skeeyah.A!rfn via the following process:

C:\Users\{loggedinUser}\AppData\Local\Temp\5\cssrs.exe; process:_pid:12320, ProcessStart:130880953025982534

2. They replaced the executable tied to the "Remote Desktop Server Service" with a modified version of rdpwrap.dll (from GitHub), thereby forcing all new Remote Connections to execute through THEIR code

3. They created a new local User called "WindowsUpdate", then logged in as that user and surprisingly, installed Steam and Counter-Strike

   • They also used C:\Windows\System32\netsh.exe to add a new Firewall Rule Named “Remote Desktop” for ‘TCP\Inbound\ALL’ for Private, Domain & Public networks and for the next 3 days (logging in and out of the server many times using the newly created WindowsUpdates user, from many ip addresses [see "known IP Addresses", below]) played the game for a total of 15 hours.

I was also able to log into their Steam account, which was logged in as feteryntri@yandex.com.

I looked up their billing information, which uses an AMEX card belonging to an "LB Stein" from Millford, AZ (first address line intentionally omitted, but on file) - but there is no Millford in AZ, and online maps correct the billing state to CT.

A reverse-lookup on the phone number from their steam billing information indeed found a Loribeth Stein in Millford, CT. I called her to inform her that it appears someone may be using her credit card information - but she made very clear that she had no desire to speak or work with me regardless any information I have. (Questionable? For the sake of this post, I am assuming she simply didn't believe me and/or thought I was a scam call)

I also found a single "Credential Validation" event in the event log on my honeypot server, which shows the following:

[UPDATE 11/4/2015]

Before offlining the new VM, I grabbed a copy of the Windows\Temp directory, the logged-in user's profile folder (C:\Users\{LoggedInUser}\, including hidden \appdata) and a backup of the machine's registry. I've spent several weeks combing through ntuser.dat hives and IE cache, registry and all the other files in C:\Users\{LoggedInUser}\appdata and Windows\Temp and have deduced the following (previous undocumented) information:

1. A malicious .DER (certificate) file was downloaded from the following URL:

WARNING: I DO NOT RECOMMEND VISITING THIS URL!

hxxp://ocsp.omniroot.com/baltimoreroot/MEUwQzBBMD8wPTAJBgUrDgMCGgUABBTBL0V27RVZ7LBduom%2FnYB45SPUEwQU5Z1ZMIJHWMys%2BghUNoZ7OrUETfACBAcnqkc%3D

(the file comes down with no extension, and presents garbage in notepad, so I used TrID File Identifier, which confirmed the file as a .DER certificate file, and searching the URL in Google found the following article: OCSP.OmniRoot.com-Virus Removal Guide by Allen Ray @ pcinfectionskiller.com)

2. IE was branded, according to IEBrand logs, but I don't know for what purpose

3. Internet Explorer was used to browse the following sites (and successfully login with the associated emails):

   match.com as queenb69rules@comcast.net

   gmail.com as gsmiles008@gmail.com (Gabriel Chariton***)

***Gabrial Chariton is a known scammer, according to YourITToday.com-1 and YourITToday.com-2

4. Tweaking.com's Registry backup was downloaded, installed, and the following were backed up to C:\RegBackup

   • Local User Profile Folder
   • Local User Registry & ntuser.dat files
   • C:\Windows\ServiceProfiles\LocalService\
   • C:\Windows\ServiceProfiles\NetworkService\
   • C:\Windows\System32\Config***

***this folder is a collection of network and machine info generated by a Microsoft script @ C:\Windows\System32\gatherNetworkInfo.vbs

5. (or 4.2) a file called dos_restore_renamed.cmd was placed in the C:\RegBackup directory. The file contents can be viewed here: dos_restore_renamed.cmd.txt @ textuploader.com"

6. Internet Explorer History was cleared

7. Several Event Logs (including Security and Terminal Server) were partially cleared - or somehow stopped logging for several periods of time ranging from 40 minutes to more than 2 hours.

---

Section C: Known Hostile IP's & Commonality across multiple Honeypots

1. IP's used to access my honeypots with the credentials created by the attacker:
   • 128.71.5.22
   • 128.71.5.53
   • 130.225.59.25
   • 148.251.49.172
   • 154.70.47.90
   • 169.55.19.147
   • 169.55.19.150
   • 169.55.27.134
   • 173.220.35.194
   • 176.226.149.255
   • 178.175.136.114
   • 185.26.144.103
   • 192.3.187.112
   • 198.154.60.102
   • 198.154.60.174
   • 198.58.88.94
   • 199.89.54.108
   • 206.217.140.37
   • 207.182.153.138
   • 37.57.15.23
   • 46.161.40.15
   • 47.22.21.110
   • 5.56.133.145
   • 50.248.158.50
   • 50.255.17.233
   • 77.234.43.139
   • 77.234.43.180
   • 78.68.165.231
   • 80.4.157.18
   • 83.69.0.58
   • 89.163.148.76
   • 93.115.92.244

[UPDATE 02/01/2016]

Since my original honeypot's inception, I've created and tracked several additional honeypots in an effort to find more meaningful data. The following is a summary of these findings...

2. My second and third honeypots saw the attacker create a new user called "temp" (as opposed to the original honeypot's "WindowsUpdate" user). The usage of this account, once logged in, was more or less an entirely different set of malicious activity than the first honeypot, but there were 2 IP addresses in particular which were used to access every single honeypot I've brought online, logging in as the user created by the attacker immediately after account creation.

   • 5.56.133.145
   • 176.226.149.255

3. In addition, the following IP (which was used to log into my original honeypot), shares all but the final octet with 2 IP's which were blacklisted by my Network Firewall for DDoS:

   • 46.161.40.15

   Blacklisted, similar IP's:

   • 46.161.40.11
   • 46.161.40.20

FreeGeoIP.net concludes that both 46.161.40.15 and 176.226.149.255 are from Russia, while 5.56.133.145 is owned by RIPE.net in California, USA, but may have been given to a RIPE.NET customer according to whois.arin.net. www.RIPE.net/whois says it belongs to an address & phone number in Germany.

---

SECTION D: Network Configuration

In general, my servers have FTP, Web Services and RDP ports open.

RDP uses NLA

Most, or all other ports are blocked at multiple stages ranging from the Gateway to the individual servers, including Firewalls, Group Policy and standard security practices.

---

SECTION E: Moving Forward

1. Contacted STEAM support and have been informed they will look into the issue and I will not be updated on results

2. Contacted Amex, but they are unable to match the billing information to an active account

3. Contacted cywatch@ic.fbi.gov - have not heard back yet

Answer 1

It turns out my previous assumption was correct. These DDoS "attacks" are actually a side-effect of a Makost[dot]net-style botnet and is NOT the intention of the attacker (in fact, they seem specifically designed NOT to cause a disruption of service which would make us aware of their activity). The attacks are in fact trying to gain access to my servers in order to rent\sell server time to third parties.

---

The Attack Process (ie 'Unintentional DDoS')

The attacking process is something like this:

1. The botnet will start funneling staggered login attempts in batches to a seemingly random block of ip's in the form of miniature Dictionary Attacks & spoofed reconnect attempts. These attempts always come in staggered batches and appear to be automated or run on some kind of schedule, possibly queued by a real person.

2. The login attempts most often begin by trying to login in with ".\Administrator" (or "local\Administrator") as the domain\username and "Administrator" (same as the username) as the password.
   If "Administrator" fails, but the server is responding on default RDP ports, they eventually come back (seconds, minutes, hours, days or weeks later) with knowledge of actual usernames used to RDP into my servers and servernames which those users have RDP'd into (presumably harvested from compromised client-machines). Most often it attempts to login with the username AS the password (ie "{username}"\"{username}", like jdoe\jdoe, owner\owner, etc).

3. Failed login attempts are seemingly hung or kept open by the botnet\attacker, most often followed with some kind of brute force session-reconnect attempt, leaving stale RDP sessions and eating up ports. This is what leads us to a Denial of Service when multiple groups of attacks are received at once.

   • It seems this botnet is intentionally staggering their attacks in order to avoid being discovered for what they really are. They want to look like isolated\unrelated bad-login attempts, sparsely spread across multiple servers. Multiple waves coming in at once seem undesirable to the attacker, as a Denial of Service would prevent their own dictionary\brute-force attacks from connecting and make the servers inaccessible to them, as well as making us aware of malicious activity.
   • Though we've seen this pattern attacking us since 2011, it has only been since 2013 that batches of attacks have begun overlapping as if they are not aware of each other. Prior to 2013, it was rare to see more than one batch at a time. This says to me that either the botnet has split - new ones are being operated using the same malware, or possibly the others have been there for a while and they've now ended up being fed the same data since 2013 vs prior. It is also worth noting that I've found traces of what appear to be similar attacks dating as far back as February 2009, but they have a different machine-name pattern, with machine names like "37L4247D25-07" and "37L4247D28-05" (see original post, "Section A: DDoS patterns" for more).

---

I was able to deduce the following by cross-referencing my existing information (original post) against my IIS & http Error logs, outgoing bandwidth logs and watching WireShark during attempted attacks and honeypot use:

Compromised computers are used as botnet hosts and to harvest as much information as possible using a sophisticated collection of malware, viruses, rootkits, browser sidejacking, and a long list of several thousand known server exploits (php, phpNuke, phpMyAdmin, phpGallery, wordpress, IIS and asp.net configs to name a few). They also scan networks using WPAD local DNS queries and have been seen attempting to use WPAD\Windows Update for a Man-In-The-Middle attack as well as attempting to hack network printers in order to compromise network security.

I believe the botnet has a growing centralized repository for server and user information, known exploits and much more metadata that helps them compromise the servers they attack. These machines collect data independently, but attacks come in waves and always follow the same patterns.

Once a server is compromised and "rented out", it's anyone's guess what the logged-in party is using it for, but "illegal" seems a pretty good conclusion given what we've seen (see original post, "Section B: Honeypotting the Attacker" for more info).

---

The most hostile IPs

Since my original honeypot's inception, I've created and tracked several additional honeypots in an effort to find more meaningful data. I have updated my original post (Section C: IP Addresses) with 2 additional points which I will summarize here:

5.56.133.145 and 176.226.149.255 have both logged into MULTIPLE honeypots using the credentials created by the attacker immediately after account creation. 46.161.40.15 was used to log into only my first honeypot, but shares its first 3 octets with at least 2 other IP addresses blocked by my Network Firewall for DDoS.

---

I have seen an immediate reduction in DDoS attacks since I posted this article (curious). As I contact my clients and (make them) install\update their security & download (important) Windows Updates, the attacks appear less and less.

---

I am NOT concluding that Makost[dot]net is behind these attacks. I am simply not aware of another name for this type of botnet, but it follows the same attack and usage patterns as Makost is known for.

For more information about Makost[dot]net, check this link:

http://krebsonsecurity.com/tag/makost/

I hope to update this article with additional information as I find it. Questions\comments welcome. The IP addresses in my original post include both botnet-attackers and users logged into my honeypot after it was "compromised".

Answer 2

Check your outgoing bandwidth logs, it could be that the attacker is using you servers as a botnet of sorts. This does seem very in depth and I would be calling up the spooks right about now(you've got plenty of information). Is disabling RDP completely an option?