Combining Pivot Points to Identify Malware Infrastructure - Redline, Smokeloader and Cobalt Strike

In this post, we'll demonstrate how to use Censys to pivot when there are minimal unique indicators that could be used for a single strong pivot.

We'll combine 5 separate "weak" indicators to identify 11 malware servers from a single initial IP found on URLHaus.

The final query we will be building can be found here.

services.http.response.body_hashes="sha1:7dd71afcfb14e105e80b0c0d7fce370a28a41f0a" and services.port:22 and services.port:80 and service_count:2 and operating_system.vendor="Ubuntu" and autonomous_system.asn="210352"

Analysis

I'll be starting with the ip 5.42.65[.]80 . This IP was present on URLHaus and marked as Smoke Loader.

Viewing additional information, we can see that the IP has been used to host Smoke Loader samples.

Censys Analysis

Moving over to Censys, we can search on the IP address and attempt to determine a pivot point.

Within Censys, we can see that there are two running services. SSH on port 22 and HTTP on port 80.

Pivoting on the SSH Service.

When SSH is in use it can be possible to pivot on the SSH host key, this works if the threat actor has used the same SSH setup across related infrastructure.

In this case this did not work, the SSH Host key was not re-used across any other hosts in the Censys database.

Pivoting on the HTTP Service

Inspecting the HTTP service on port 80, there isn't a lot of information that we can pivot from.

At first glance, everything seems to be a default install of the Nginx load balancer.

Attempts to pivot on the html title or banner hash will result in either millions of results, or a single result (the same server). So these are not useful as pivot points.

Pivoting On The Body Hash

The response body from one of the previous screenshots shows a default but relatively long string of text.

In hopes that this text is unique enough to be used as a pivot point, we can use the search button in Censys to attempt a pivot on the hash of this text. (This will search for any server that returns identical text to this one)

Pivoting on the hash of the response body returns over a million results. So this value is also not useful as a pivot point.

At least not on its own.

Combining Pivot Points

Since we weren't able to identify any useful pivot points within the HTTP or SSH services, we can instead try a different approach by limiting the location and the number of services running.

For example, we can combine our body hash search with a requirement that the server is ONLY running SSH/22 and HTTP/80.

The below query will limit our search to servers running only port 22 and 80.

services.http.response.body_hashes="sha1:7dd71afcfb14e105e80b0c0d7fce370a28a41f0a" and services.port:22 and services.port:80 and service_count:2

This reduces our results from ~1Mil down to ~71k.

This is still too many results, but much lower than before so we may be on to something.

Looking for Additional Pivot Points

Since we've already limited our results fairly significantly (considering the lack of unique services running). We can go looking for other options for pivoting.

If we return the summary view of our initial host, we can see that it's running Ubuntu Linux and is operating on ASN 210352.

ASN is short for "Autonomous System Number" and is used to group IP addresses with the same routing policy. This generally means that it groups IP addresses in similar locations (same datacentre) or at least roughly the same geographical area.

ASN's are often useful as pivot points when other options fail.

Filtering on Ubuntu Operating System

If we return to our previous search and a filter on Ubuntu, we can reduce our results down to ~38K.

This is still too many but heading in the right direction.

Filtering on Autonomous System Number (ASN)

Since we still had too many results (38K) after filtering on Ubuntu. We can go ahead and filter on the ASN number 210352 present in our initial IP.

This means that our current search looks like this. Which accounts for...

Body Hash of nginx page
ONLY services 22 and 80
Running Ubuntu Operating System
Grouped by ASN Number 210352

Now we're down to 11 results, which looks very promising.

Investigating Results

With only 11 results remaining, we probably don't need to do any additional filtering. We can instead go ahead and confirm our current results.

The second result 79.137.192[.]9 has 9/88 hits on Virustotal and may be related to Redline Stealer.

Investigating 77.91.76[.]7

The 4th result in the search has 0/88 detections on Virustotal. But has 11 recent communicating files that are very likely to be malicious.

The first communicating file has been marked as Amadey Clipper Module by the Thor scanner by Florian Roth.

Investigating 5.42.65[.]49

A VirusTotal search on the returned result 5.42.65[.]49 returns 12/88 results.

There are also two comments indicating that the server has been used as a Cobalt Strike C2.

Confirming Results

So far 3 of the returned results are malware C2's related to Redline, Amadey and Cobalt Strike.

We won't go into the analysis of every one of the results, but a summary will be included below of the findings.

Some of the results had 0 detections and no indications of malware. In these cases, I would still assume that the IP is related and malicious (possibly reserved for later use).

Final Results

The final results can be observed below, based on the prevalence of malware C2's, I would assume that the 3 "clean" results are malicious but not yet in active use.

5.42.65[.]49 - 12/88 VT, Cobalt Strike C2
5.42.65[.]64 - 0/88 VT, Clean
5.42.65[.]80 - 19/88 VT, Smokeloader Delivery
5.42.66[.]9 - 4/88 VT, Amadey Bot C2
5.42.66[.]18 - 0/88 VT, Clean
5.42.67[.]28 - 0/88 VT, Clean
77.91.76[.]7 - 0/88 VT, Amadey C2 
77.91.76[.]12 - 1/88 VT, Unsure
79.137.192[.]6 - 17/88 VT, Redline Stealer
79.137.192[.]9 - 9/88 VT, Redline Stealer
79.137.192[.]18 - 19/88 VT, Redline Stealer

Additional Notes - Lumma Stealer

The concept covered in this post can also be applied to a Lumma C2 from URLHaus.

By combining the use of "Tiny File Manager" on port 80 with the limited port numbers and ASN, we can identify another 6 malicious servers.

Below is an example of what this looks like.

services.http.response.html_title="Tiny File Manager" and service_count:2 and services.port:22 and services.port:80 and autonomous_system.asn="216419"

Additional Notes - RecordBreaker

The same concept can also be applied to this server from URLHaus.

You can see the Censys search here.

services.http.response.html_title="Error" and services.software.product="nginx" and service_count:2 and services.port:22 and services.port:80 and autonomous_system.asn="211409"

This is based on a limited number of ports, ASN and an error message in the returned page on port 80.

Additional Notes - PrivateLoader/Mirai

There is another similar pattern in the IP of 91.92.244[.]70 from URLHaus.

This search returns 10 results with hits for PrivateLoader and other malware.

services.http.response.html_title="403 Forbidden" and services.port:22 and services.port:80 and service_count:2 and autonomous_system.asn="394711"