As mentioned in one of our previous posts, the “success” of a hacker and its malware starts with a working connection. The content was about 3 automated steps that brings this “success” ratio close to zero; provided these 3 steps are executed in a consistent and systematic manner.
In this post a use-case showing the capabilities of step 2. This is based on a real DDoS/hack-attempt against one of our MS-RDP-servers. This attack was on Saturday, Jan-25 and lasted 45-60 minutes.
Step 1: unusual usage patterns. The data for these usage patterns is based on audit- and packet data as coming in from all possible endpoints.
Audit data is based on:
- user login attempts,
- changes in the checksum of files and
- changes in processes/services as running on the endpoints.
Packet data is based on IP-addresses and TCP/UDP-ports from both, source and destination.
Each of these action items generate an event.
This is then translated into an aggregated view with the total number of events. As seen in the next image, this aggregated view shows an exceptional number of events between 15:00 and 18:00 (i.e. 3 and 6 PM).
Step 2: checking the number of events related to audit and packet data. Here, we discovered that the unusual number of events is related to the audit part and the number of failed logins.
Step 3: finding the open door and the location of the endpoint based on the network packet data. As seen in the next image, the open door is TCP-port 3389; which is the TCP-port of MS-RDP; the Citrix equivalent from Microsoft.
The network packet data also shows the IP-address of the endpoint making the login attempts. We checked this address against several Geo-IP-location services. All services reported an IP-address in Russia.
Note that we did not(!) use any kind of deep packet inspection or retrospective analysis through Tera Bytes of packet storage; plain Netflow-like, TCP level visibility will make this happen. This makes it a very cost-effective approach.
What makes this also interesting is that we have white-listed MS-RDP with a different, external TCP-port (i.e. port 33159). Meaning that the hacker must have done an extensive, full-range port and protocol scan before starting the MS-RDP-client and making the attempts!
Step 4: business impact analysis determining which usernames and systems are involved.
In our case, figure 4 shows that the hacker tried a few dozen usernames against server “itv-hub”:
- “factory-default” usernames with admin-rights like admin, administrator and system.
- “well-known” regular usernames like helpdesk, guest and info.
- “lucky-shots” like john and jan without anything else.
Most of the usernames would fall in the category “lucky-shots”.
Fortunately, none of the attempts where successful. And even if they were, the hacker would face the 2FA-part.
To summarize the findings and results: most likely, the attempt started with an extended TCP-port and protocol scan. During this scan an open MS-RDP-door on TCP-port 33159 was found (which is by-design!).
For about an hour the hacker tried a few dozen usernames; mostly typical Dutch first names (previous image with the authentication attempts). As you can see each of these usernames where tried exactly 30 times.
None of these 1200 attempts where successful since the accounts itself where non-existing. And even if the hacker would have been successful, the next hurtle would be the 2FA.
After 45-60 minutes the attack stopped.
These findings show that hackers are “improving” by thinking ahead and automate:
- Did a Geo-location for the IP-ranges-to-be-scanned (why else the Dutch first names for usernames?)
- Did an extensive TCP-port and protocol scan (until now, I only noticed port scans up to TCP port 9999)
- Looks like an automated, structural approach:
- Started the hack-attempt with well-known accounts like guest, admin and administrator
- Switched then to typical Dutch first names as usernames
- Stopped after 30 unsuccessful attempts on each account (the MS-RDP-server allows unlimited attempts to prevent lockouts)
It is my believe that the described approach is the bare minimum for an early detection of hackers; especially in cases where the signatures in firewalls, IDS and IPS systems don’t recognize a low-profile hack-attempt like this.
This bare minimum is also very cost effective. Which makes it available for small organizations starting at 10 seats. By adding more intelligence like BA (Behavior Analytics) and baselining, the approach scales to 1000-plus seats across numerous offices.