Malware

How to Track Actors Behind Keyloggers Using Embedded Credentials

8 min read

This post is also available in: 日本語 (Japanese)

Mo' key loggers, mo' problems

This past year Unit 42 has seen a resurgence of keylogger activity and it seems like every week a new research blog comes out talking about one of four popular families: KeyBase, iSpy, HawkEye, or PredatorPain. These blogs usually delve into the technical workings of the threats, discuss their relationship to each other, and explain how they evolved from one another through new ownership or branding of the tools. The intent of this blog is not to rehash what has already been discussed, but instead to shift the focus to the actors behind these keylogger threats and show a practical technique for identification.

To be of any value, keyloggers must transmit data back to the attacker. There are three well-established methods for doing this: HTTP, SMTP, and FTP. HTTP transmission usually involves a simple POST request with a body containing the stolen data; however, for SMTP and FTP, more often than not these protocols require authentication to log into a service before transferring the data from the compromised system. This presents a valuable data point, because all of the big four keylogger families embed their credentials inside of their binaries. This further provides an analyst with a remote server address, username, and password for each sample analyzed. Couple this with the increase of keyloggers found in the wild and we find ourselves with a very large data set that can be used for correlation.

By using Palo Alto Networks AutoFocus, I was able to quickly identify 500 recent samples of HawkEye and iSpy, which exhibited either FTP or SMTP activity during dynamic analysis. After downloading the samples and their respective network activity, I parsed out all successful FTP and SMTP activity to build a data set for Maltego. We’ll use these embedded credentials to try to uncover patterns and find actor-identifiable data through our research.

Before getting into the correlation, some general statistics on the data:

207 FTP connections were caught with active credentials, e.g., the malware successfully logged into the FTP server to upload data from our virtual test machines
53 SMTP connections were made with active credentials
37 unique drop destinations were identified for stolen data
96 unique accounts used to log into these drop sites

After collecting all of the data from PCAPs and loading it into Maltego, we can visually see multiple organic clusters standout along the top, which will be the topic for discussion.

Figure 1. Key logger clusters

Actor 01 (“Kramer”)

Starting from right to left, the first cluster shows a heavy concentration of samples communicating with IP address, 108.179.196[.]24. This FTP drop site was the most utilized across our sample set, with 71 unique samples and 18 unique FTP accounts being used to drop data.

Figure 2. The "Kramer" cluster

Looking a little closer, there is a smaller cluster of accounts on the left of the graph that warrants further investigation.

Figure 3. Unique password reuse in the "Kramer" cluster

While all the stolen data being dropped on one FTP server is a solid relational indicator, what’s even stronger is that 14 usernames all used the same password, “joinkrama2”. When you look at the actual accounts as well, we see usernames are formatted like e-mail addresses and some of the local parts of the address get shared across domains. The below list highlights some of these shared local parts across domains in the username. The domains themselves have been truncated.

chekube@her
chima@min
daniel@her
daniel@oma
dubem@sam
golden@sam
okumen@oma
oni@pea
oni@sas
udobata@sam
victor@sam
wizzy@pea
wizzy@sas

This correlation provides strong evidence that the actor behind these accounts is the same. We’re also able to pivot from the unique password to another account hanging off the bottom in the first image, which shares a local name with the above local, “dubem”. The sample in question is also seen dumping key logged data to a separate server at 68.171.217[.]250. Finally, one of the “oni” accounts from the above list was also seen using the password “pereyikelamo2”, which was tied to one other account using the same domain, “atus@sas”.

By following these links we can slowly begin mapping out part of the infrastructure utilized by this actor and collect multiple indicators to identify them.

Top Indicators for Actor 01 "Kramer":

108.179.196[.]24
68.171.217[.]250
Chimaeze12
LAURINA12
chimaeze12
joinkrama2
pereyikelamo2
pokerdick123
dubem
oni
wizzy
atus
uzochi

Actor 02 (“OpSec”)

The next cluster we’ll take a look at also uses one server and, similar to the previous actor, the usernames take the format of e-mail addresses.

Figure 4. The "Opsec" cluster

Only one domain is used, nayyabgroup[.]com and, as the image above illustrates, each account uses a unique password. For this particular actor, the complexity of their FTP passwords was a good linking indicator, as it deviates from what is seen throughout most of the embedded credentials captured during this analysis.

P!{Xwn{eEV$T
?G34p}b);w
k*wsOH*P]!up
C7,5#dg4X1b?
QsvGK8H9XGJ8
0gZ3I%dmpXi5

The passwords appear to be auto-generated by a tool and might successfully protect against brute force attempts or unauthorized access. While the actor's password policy appears strong, he or she seems to be disregarding the fact that credentials are embedded in malware that employs plaintext transport mechanisms.

A final indicator to attribute to this actor is the usage of the local name “sirvor” followed by three numbers, for example “sirvor123” – there are four different variants of this across the 11 samples using the FTP server.

Top Indicators for Actor 02 "Opsec":

243.113[.]211
sirvor
nayyabgroup[.]com
P!{Xwn{eEV$T
?G34p}b);w
k*wsOH*P]!up
C7,5#dg4X1b?
QsvGK8H9XGJ8
0gZ3I%dmpXi5

Actor 03 (“LogAllTheThings”)

For the third cluster, we again have one FTP server being used by the actor to drop their data. However, one unique attribute about this cluster is that the actor is using three different key loggers across 46 samples to dump data here – HawkEye, iSpy (coupled with Galaxy Botkiller), and PredatorPain.

Figure 5. The "LogAllTheThings" cluster

This use of multiple different key loggers could be determined by looking at the file names being stored on the FTP server.

(HawkEye log – 23.229.206[.]201)

(iSpy log – 23.229.206[.]201)

(PredatorPain log – 23.229.206[.]201)

Each of the families has its own unique capabilities and, more importantly, different ways of morphing itself to avoid detection. It’s not surprising to see the usage of more than one type of keylogger by an actor, as actors constantly need to update and change tools to stay ahead of defenders.

At the top right of this cluster you’ll notice eight different accounts all share a common password, “pentium12345”.

Figure 6. Password reuse by multiple accounts

While there were very few unique passwords, all of the credentials identified for this actor used a numeric suffix of either “12345”, “1234”, “123”, or “@@123123”. Similarly, the usernames were again formatted as e-mail addresses and the domain portions were all listed as “@bigcountrywater[.]com”, with seven of the 13 total accounts using “office” somewhere in the local portion. Tying these all together provides a strong indicator to identify this actor.

Top Indicators Actor 03 "LogAllTheThings":

229.206[.]201
pentium12345
bigcountrywater[.]com
@@123123

Actor 04 (“MailMan”)

Our last cluster in the top left was purely SMTP traffic to the e-mail server at “web.arch[.]ai”, used for transferring HawkEye logged data.

Figure 7. The "MailMan" cluster

As evidenced by the image above, almost every account had a unique username and password. Across the majority of the accounts identified, the passwords were structured to take part of the username (e-mail format) and suffix it with five numbers, usually “12345” or “54321”. For example, if the username was “username@email.com”, the password might be “user54321”, which provided a consistent indicator across the 45 samples identified.

In addition, out of the 20 unique accounts identified sending data to this e-mail server, only two domains in the username field were seen during this analysis, “shamaraholdinq[.]com” and “pmtlogisticsinc.co[.]uk”. A quick WHOIS search for these domains shows the same registrant, based out of Nigeria, with a number of other domains registered that can be used for further pivoting and analysis.

Figure 8. The man behind the mail

Looking at the domains, you can guess the type of phishing activities being carried out by this actor.

Figure 9. Masquerading as US Government sites

Top Indicators Actor 04 "MailMan":

web.arch[.]ai
shamaraholdinq[.]com
pmtlogisticsinc.co[.]uk
Nelson12345
abacom12345
abuchi12345
abuchi54321
alfred54321
bethel54321
bro54321
compu54321
ebuka12345
humble12345
immortal12345
kaycelaz5
kelechi12345
kunde54321
miraclebaby16
obi12345
opera54321
philip54321
shoki54321
spencer098765
sular54321
sular@54321

Conclusion

In the grand scheme of keylogger activity, this was a small sample set. Despite this, it was enough to highlight that using embedded credentials at scale could be leveraged to gain insight into actor behavior and infrastructure. It’s a practical technique and quickly identified at least four different actors actively utilizing keyloggers to steal data from compromised systems.

It should be obvious, but it’s worth stating: keyloggers aren’t going anywhere and without a doubt they will only continue to evolve like every other type of malware. As this happens and we’re left trying to protect our organizations, sometimes we can get lost in the analysis of minute details between various malware families, so it helps to change perspective now and again and take more of a macro look at the landscape in front of you.

There is always a human element to these threats and, as evidenced throughout this blog and countless others, the people behind these threats can fall prey to the same issues that organizations do – poor operational security.

Palo Alto Networks customers are protected by these various threats through WildFire AV signatures. AutoFocus customers can further research these threats through the below tags.

AutoFocus Tag - iSpy Software
AutoFocus Tag - PredatorPain/HawkEye
AutoFocus Tag - KeyBase

Below are additional indicators from the discussed sample set, including the ones shown above, that were observed by the malware. Please note that individually, these indicators may not be enough to determine whether something is good or bad, but the combination of multiple indicators can lead to actionable intelligence. Account names will not be included in an effort to prevent any potential abuse from the credential pairs.

IP/Domains: