Malware of the Day – What Time Is It?

What is Malware of the Day?

 

Lab Setup

“Malware”: timeserversync.com

MITRE Tactics: TA0011 Command and Control , T1036 Masquerading

Traffic Type: HTTPS/TCP/TLS

Connection Type: Reverse HTTPS

C2 Platform: PoshC2

Origin of Sample: Active Countermeasures Lab

Host Payload Delivery Method: Binary EXE

Target Host/Victim: 192.168.99.51 – Windows 10 x64

C2 Server: timeserversync.com

Beacon Timing: 64s

Jitter: 0%

 

Malware of the Day Mission

To identify and share examples of post-compromise network activity in order to better detect and respond to potential network threats. Specifically we are looking for command and control (C2) communication channels used by attackers to obtain intelligence, issue commands, and exfiltrate data through a compromised host or hosts.

 

Brief

As active network threat hunting is becoming mainstream and being implemented by more organizations, our adversaries are continuing to shift their resources and craftiness beyond the initial compromise stage and focusing on hiding their post-compromise communications.

A strong method of avoiding detection is attempting to blend in amongst your normal network traffic and applications by appearing as common and expected traffic in an average corporate network. In order to adequately defend ourselves, we should be thinking like a stealthy attacker and not be entirely focused upon the clearly obvious or previously known indicators of compromise.

A common network service that is widely seen within many corporate networks is Network Time Protocol (NTP). These services can be generally designated as benign in nature. They provide time-keeping service to a wide variety of internet connected hosts. Because of this commonality, a threat hunter may easily dismiss anything to do with time services as not a threat or anything out of the ordinary that deserves extra attention.

The communications patterns of NTP, by its nature of verifying the time on regular intervals to an external resource, will appear as a beacon (short repetitive communications). A beacon is also a hallmark indicator of a C2 channel. Using a network traffic analysis tool such as AC-Hunter, this beaconing behavior will be quickly identified. However, after investigation and confirmation that a particular external server is legitimate, it can be safelisted in AC-Hunter to remove it from the results.

Manually threat hunting and verifying hundreds (or possibly thousands) of connections has the potential to place you in the mindset of “If it quacks like a duck and walks like a duck, it must be a duck.”

It may not always be a duck.

 

From the traffic in our active lab network, AC-Hunter has identified a threat, grading it a high 95.70% Beacons Web score:

Here we have an internal host (192.168.99.51) communicating regularly with an external host at timeserversync.com. Okay, that’s just another pesky time service. We’re totally fine… I’ll just move on to the next result.

Or so our adversaries may hope.

 

Investigation

As a threat hunter, once I’ve identified a particular connection pair as suspicious, one of the first things I want to know is how common this external resource is in my network. In other words, how many of my internal hosts are also communicating with this external resource? This will quickly provide a clue if this resource is common (leaning more towards safe) or unique (leaning more towards unsafe).

This is simple to obtain in AC-Hunter:

By clicking on the ‘tls servers’ IP address that the domain resolved to, it brings up a menu with additional investigation options. In this case, we want ‘deep dive’.

 

The Deep Dive module displays all the connections that were made to or from the selected host. We can see from the results that only one of our internal hosts is communicating with this external resource. This result increases the level of suspicion because if it were assumed that this is a legitimate time service, we would expect to see many or most of our internal systems also using this service. Being an outlier adds more questions than it answers. Why is this unique? Is there a legitimate reason that only one of our internal hosts is beaconing to this resource?

Going back to our Beacons Web result, let’s look at the Destination (DST) details:

192.168.99.51 is beaconing to the domain ‘timeserversync.com’. The domain by itself does not necessarily appear malicious, in fact, it sounds legitimate.

We also see in our details “invalid certificate: yes” and when hovering over the ‘subjects’ field, we see the Common Name (CN) value in the certificate as “P18055077”. This does not make any sense and we would expect to see the actual domain name in this field. The rest of the certificate details are also odd and suspicious.

In the ‘comm’ field, we see ‘443:tcp:ssl’. This is telling us the communications are using port 443, it’s communicating using the TCP protocol, and it’s encrypted (we saw the TLS (ssl) handshake). This TLS certificate was valid for a TLS/HTTPS connection, but we know from our investigation above, it is not a valid certificate for this domain. If this were a legitimate time server it would be expected to be communicating on port 123 using the UDP transport protocol. Finally, many of the legitimate time servers operate using the domain of ntp.org and subdomains such as x.pool.ntp.org .

Below the domain, we see the IP address that timeserversync.com resolved to; ‘tls servers 157.245.128.27’. Clicking the IP address brings up an external investigation menu. Let’s look at this IP address using VirusTotal:

Right away this is not looking good. Four security vendors flagged this IP address as malicious, the server has a strange self-signed SSL certificate and the domain has only recently been associated with this IP address.

Also, the server is hosted in a public cloud service. This by itself is not malicious but in our context here it’s not helping to legitimize the service and is adding another point of suspicion, as almost anyone can stand up a server in a public cloud space without providing verifiable credentials and they are commonly abused for malicious activities.

This is a very consistent beacon as can be seen by the hourly histogram:

Over a 24-hour period, we can see there are consistently ~55 connections per hour. This consistency is confirming that these are programmed communications. If this were “normal” human traffic, the number of connections per hour would be much more random in nature.

 

Looking at the beacon timing graph, the communications are taking place consistently at 64 second intervals. The beacon timing does align with what would be normally seen from a legitimate time server. If we were only looking at the connection timings, this could appear to be a legitimate time server but by reviewing all the parameters of these connections, we can see that it is not.

 

Switching to View 2 in our graph shows us the amount of data that was transferred. In this case they are minimal amounts, just enough for a back-and-forth checking in, also known as a C2 heartbeat. If this C2 channel was being utilized beyond the heartbeat, this data size information would tell us if the attackers are actively using the C2 channel, exfiltrating data and how much.

If this were a real-life scenario, after our quick investigation using AC-Hunter and confirming there is not a legitimate reason for these connections taking place, we can confidently declare this to be very suspicious in nature, or at the least – unwarranted, and should be escalated to incident response for a forensics audit of the internal host.

 

Closing

In this compromised Windows host, C2 server and beaconing example, you may even think “I can clearly see there is so much wrong here.” Keep in mind that the somewhat obvious issues in this compromise are not because it’s impossible to make it much more stealthy. It’s absolutely possible to fix the certificate, the port used and a few other tweaks to make it more difficult for a human threat hunter to recognize as a threat. The issues in this C2 channel example are purposely included to display some of the parameters our adversaries get wrong or are just too sloppy or lazy to perfect. These are some of the items to be aware of and to verify.

Even with a good certificate, the expected port usage and transport, this would still be identified as a threat by AC-Hunter based upon the network communications behaviors and beaconing.

Below are capture files of this network traffic. Would you be able to easily identify this C2 channel within your network?

 

Capture Files

NOTE: The domain “timeserversync.com” is under the control of Active Countermeasures and is not associated with any malicious actors, so no worries.

PCAPs

Because… PCAPs, or it didn’t happen. 😊

The following PCAP files are packet captures taken from the same lab environment over a 1-hour time frame and a 24-hour time frame. The files were generated using Wireshark from the target host and include normal Windows OS traffic and normal network broadcast traffic. They have not been edited. The PCAPs are safe, standard PCAP files and do not include any actual malware.

timeserversync.com 1 Hour Capture
timeserversync_1hr.pcap
Size: 1.23 MB
SHA256 Checksum: A3BAAD3AFFDDB47D3B7F1F060D41F2D1723563B9F6AC3491C32302B736C5EFBA

timeserversync.com 24 Hour Capture
timeserversync_24hr.pcap
Size: 82.62 MB
SHA256 Checksum: 4C9B439F4D99E5218D2A9C7F2052CD082EEA559E79D32D6C70E8E87E749DC31F

Zeek Logs

If you are an AC-Hunter user, we are providing the 24-hour Zeek logs for you to import directly into AC-Hunter. The following Zeek Logs have been taken from the same lab environment over a 24-hour time frame and include normal Windows OS traffic and normal network broadcast traffic. They have not been edited. The Zeek logs are safe, standard log files and do not include any actual malware.

Importing Zeek logs into AC-Hunter example:

ssh into your AC-Hunter server and upload all the Zeek logs contained in the zip file below (all files that have the ‘log.gz’ extension) into a temporary directory on the server. In this example, we are uploading the Zeek logs into /tmp/timeserversync-zeek-logs/

Then run the following command:

rita import /tmp/timeserversync-zeek-logs/*log.gz timeserversync

You will now have a new database in the AC-Hunter UI/web interface titled “timeserversync” you can select and view.

24 Hour Zeek Logs
timeserversync_zeek_logs.zip
Size: 3.40 MB
SHA256 Checksum: D651E62461FA8A44866D9B10160064373DC851A52C100428E916B44EB8EBD745

 

MotD Lab Network Landscape

• 6 Intel-based x64 hosts running Windows 10
• 1 Raspberry Pi running Zeek as the network sensor. The Zeek logs are automatically sent once per hour to our network analysis platform AC-Hunter installed in a cloud environment.

Discussion

Want to talk about this or anything else concerning threat hunting? Want to share how good (or not so good) other detection tools were able to detect this sample?

You are welcome to join our Discord server titled “Threat Hunter Community” to discuss topics surrounding threat hunting. We invite you to join our server here.

 

Additional Resources

https://attack.mitre.org/

 

A special thank you to Bill Stearns for reviewing this article, his contributions and depth of knowledge, and for just being an awesome human.

 

Until the next!