Employees, customers and partners connect to different repositories of information within your network, as well as to the internet, to perform various aspects of their jobs. These people and their many devices represent your network’s users. It’s important to your organization’s risk posture that you’re able to identify who they are — beyond IP address — and the inherent risks they bring with them based on the particular device they’re using, especially when security policies have been circumvented or new threats have been introduced to the organization.
Here are two high-profile, real-world breaches that you can learn from. The key takeaway here is that, to make the most of your next-generation firewall investment, it is critical to implement user-based controls.
Example 1: Data Breach at a Large U.S. Retailer
This data breach started with the attackers stealing a third-party vendor’s login credentials. This allowed them to gain access to the third-party vendor environment and exploit a Windows vulnerability. Since the vendor had the privileges to access the corporate network, the attackers gained access, too. The attackers were then able to install memory-scraping malware on more than 7,500 self-checkout POS terminals. This malware was able to grab 56 million credit and debit card numbers. The malware was also able to capture 53 million email addresses.
The SANS Institute Reading Room for InfoSec has published a report on the breach. The report mentions several ways in which the breach could have been prevented. One of the most important is to have the right access controls in place. Quoting from the report:
An identity and access management solution should be used to manage the identities and access of all internal and external employees (third-party vendors).
Each external employee should have their own account, so that there is accountability for anything performed on their behalf.
Account review procedures should also be in place, specifically for third-party vendor accounts. Auditing of these third-party vendors is critical. This will allow the detection of abnormal behavior.
Having all of these controls in place for managing and monitoring the third-party vendor accounts will detect any misuse of third-party vendor credentials.
Example 2: Data Breach at a Large U.S. Banking and Financial Services Company
This data breach started with the attackers infecting the personal computer of an employee. The malware stole the employee’s login credentials. When the employee used VPN to connect to the corporate network, the attackers were able to gain access to more than 90 corporate servers. The attackers stole private information for 76 million households and 7 million small businesses.
The SANS Institute Reading Room for InfoSec’s report on this breach mentions the need to manage user privileges as one of the key ways to minimize the risk of a breach or minimize damage in case of a breach. Quoting from the report:
Least privilege simply means to give someone the least amount of access to perform his or her job. If least privilege control access were applied, these organizations would have reduced the amount of stolen data by 86 percent.
Anonymous access must be disabled because many Windows vulnerabilities are caused by null user sessions. A null user session is essentially a Server Message Block (SMB) session with blank username and password.
What This Means for You as the Security Practitioner
Want to make sure your organization does not end up in the headlines for the wrong reasons, like a massive data breach? You’d do well to implement user-based controls and restrict user access to least privilege, as the SANS Institute reports recommend. Employ the right user access mechanisms not only on the endpoints and on the applications that they access but also on your next-generation firewall.
Call to Action
If you own a Palo Alto Networks® Next-Generation Firewall, refer to the following resources to enable User-ID™, and increase your organization’s breach defenses:
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.
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.
Device groups make configuring firewalls easy by enabling you to group firewalls that require similar policy rules based on location and function. You can make your configuration workflow even easier by nesting device groups in a hierarchy with the predefined Shared location in the top layer and then parent and child device groups in descending layers. In a device group hierarchy, all firewalls inherit rules and objects that are common across your organization from Shared and the firewalls in child device groups inherit rules and objects from parent device groups. Inheritance enables you to avoid configuring duplicate settings in each device group.
How Do I Configure a Panorama Device Group Hierarchy?
Say you have data center firewalls in Chicago and Cairo and branch office firewalls in London and Shanghai. To avoid redundant configuration, you can create six device groups, each containing only the settings that are specific to the firewalls used for each function (data centers or branch offices) or each location (Chicago, Cairo, London, or Shanghai). Configuring the Chicago and Cairo device groups as children of the Data Center device group ensures that the firewalls in those locations inherit the Data Center settings. Similarly, configuring the London and Shanghai device groups as children of the Branch Office device group ensures that the firewalls in those locations inherit the Branch Office settings. All the firewalls in every location inherit shared settings.
Robert Megennis is a 16-year-old racing prodigy. Palo Alto Networks is proud to be an ongoing sponsor of Rob’s races for the 2016 Mazda Road to Indy racing season. We’ll be checking in tochronicle his adventures as a true next-generation competitor!
After nine races, including the recent Grand Prix Road America in Wisconsin, Rob is the highest ranked rookie in the championship, with almost double the points of the next closest first-year driver. He is the only rookie in the top 10, and the only American in the top 10. On to Toronto!
Check out photos from Rob’s recent travels and fan feedback below.
“We both wanted to thank you so much for the wonderful hospitality and also the amazing view and great food yesterday. Rob is such a great kid–we can’t wait to keep following his career! We will wear the t-shirts with pride!”
“Thanks for the inside look at racing. We enjoyed it a lot. Best of luck to you, Rob, and the whole team this year!”
In recent weeks, I’ve spent time investigating the LuminosityLink Remote Access Trojan’s (RAT) embedded configuration. For those unaware, LuminosityLink is a malware family costing $40 that purports to be a system administration utility. However, when executed, the malware leverages a very aggressive keylogger, as well as a number of other malicious features that allow an attacker to gain full control over a victim machine.
Figure 1 LuminosityLink website
At the request of a coworker, I was asked to extract the configuration of a LuminosityLink sample, and while I could have simply executed the malware in a sandboxed environment and pulled the configuration from memory, I chose to see if I could perform the same action against the static binary.
This led to me understanding how the configuration is encrypted within the binary, as well as how to parse that configuration. I’ve created a script to perform this action against an unaltered LuminosityLink malware sample, which I will be sharing within this blog post. Furthermore, I looked at the roughly 18,000 LuminosityLink samples Palo Alto Networks has collected over time, and using this script, I was able to extract the configurations of 14,700 samples. (This data can be found in the Appendix section of this post.)
Overview of LuminosityLink
Originally surfacing in May 2015, LuminosityLink’s popularity has been on the rise, as shown in the following chart. To date, Palo Alto Networks has tracked approximately 50,000 attempted infections of LuminosityLink against our customers.
Figure 2 AutoFocus graph of LuminosityLink sessions over time.
LuminosityLink currently sells for $40 and can be purchased directly from its author. This package allows attackers to host a LuminosityLink server as well as generate customized binaries, which are obfuscated with ConfuserEx 0.4.0. ConfuserEx is an open-source project that obfuscates the underlying .NET code, making it much more difficult for reverse engineers that decompile it. This is important to note for later when we discuss determining how to reverse-engineer the encryption process.
As mentioned previously, a number of configuration options are included, as we can see in the following screenshot.
Figure 3 Client configuration options in LuminosityLink
Once executed, attackers are given a wealth of options, including keylogging, remote desktop, password stealing, and interacting with a shell on the device.
Reverse-Engineering the Configuration
The first step in parsing out the configuration of LuminosityLink is to extract it statically. I initially opened up a clean LuminosityLink sample using a program named dnSpy to search for clues as to where the configuration might be stored. (As a quick aside, I highly recommend dnSpy, as it not only does a great job of decompiling the provided .NET binary, but it also comes equipped with a built-in debugger, which is instrumental in tackling problems such as the one we are facing.)
When initially opening up a sample binary, I didn’t expect much as I knew the sample was obfuscated using ConfuserEx. However, looking at the resources of the sample, I saw some strings that looked promising.
Figure 4 Embedded resource strings in LuminosityLink
As we can see, the malware contains a number of resources that in turn contain what appears to be Base64-encoded data. The “SMARTLOGS”, “XML”, and “CONFIG” resources all contain a wealth of data, which, at this point, is still unknown. Unfortunately, decoding these strings results in garbage, which likely means some other form of encryption is being used underneath.
I continued to investigate the underlying code, which, while obfuscated, still provides a high-level idea of what various classes are doing. Using imported namespaces, API calls and certain un-obfuscated strings, we’re able to get clues as to what is going on within the program. Specifically, we see the fd() class using the namespace of ‘System.Security.Cryptography’, which certainly merits investigation as we suspected crypto being used against the earlier referenced resource strings.
Figure 5 Cryptography namespace being used by LuminosityLink
As we further investigate this class, we see references to the following classes and functions:
MD5CryptoServiceProvider
ComputeHash
FromBase64String
RijndaelManaged
At this point, I turned to my debugger in an attempt to see how these strings were handled. I set breakpoints on various calls previously mentioned. Specifically, the breakpoint on the RijndaelManaged class yields excellent results.
Figure 6 Successful recovery of AES-128 key
We’re able to not only verify that AES-128 encryption is used, but also verify that the “SMARTLOGS” resource string is being used. We also are able to identify the string being used as the key, which in this particular example is “\\ecnOnuR\\noisreVtnerruC\\swodniW\\tfosorciM\\erawtfoS”. Further investigation reveals that this string is hashed using the MD5 algorithm. The first 15 bytes of this hash is concatenated with the entire 16 bytes of the hash, followed by a null byte. We can replicate this decryption process in Python as such:
1
2
3
4
5
6
7
8
9
10
def decrypt_data(data,key_string):
decoded_data=base64.b64decode(data)
m=hashlib.md5()
m.update(key_string)
md5=m.digest()
key=md5[0:15]+md5+“\x00”
mode=AES.MODE_ECB
iv=‘\x00’*16
e=AES.new(key,mode,iv)
returne.decrypt(decoded_data)
We can further verify that this is correct using the above code. In the following example, the data variable has been set with the base64-encoded string found within the “SMARTLOGS” resource, and the key_string variable has been set to the reversed registry key previously mentioned.
Using trial and error, we’re able to successfully map each variable witnessed in the above configuration. The last variable proves to be quite interesting, as each character except for ‘1’ maps to a particular configuration option. The following mapping was determined:
i : Enable Client Installation/Startup
d : Client Persistence Module: Protect Luminosity’s Client Binary
s : Silent Mode (Hide Luminosity Window on Client PC)
a : Proactive Anti-Malware: Clean Malicious Files and Speed up Client PC
n : Power Saver: Prevent Sleep Mode and Turn off Monitor after 15 minutes of inactivity
m : Remove File after Execution (Melt)
v : Anti-Virtual Machines/Debugging
h : Hide File and Directories
b : Backup Startup
Using this knowledge, we can parse the above configuration, which yields the following results.
[X]Silent Mode(Hide Luminosity Window on Client PC)
[]Proactive Anti–Malware:Clean Malicious Files andSpeed up Client PC
[X]Power Saver:Prevent Sleep Mode andTurn off Monitor after15minutes of inactivity
[]Remove File after Execution(Melt)
[]Anti–Virtual Machines/Debugging
[]Hide File andDirectories
[X]Backup Startup
Parsing LuminosityLink Configurations at Scale
Using this knowledge, we created a script to parse the configuration of a given sample. The script searches for strings that appear to be base64-encoded with a length greater than 50 and takes a brute-force approach. While not elegant, it does the job quite successfully. The script can be downloaded in the Appendix section of this blog post.
Going through Palo Alto Networks repository of samples, we found roughly 18,000 files tagged as LuminosityLink. For these 18,000 samples, we applied our static configuration extraction and parsing script and successfully retrieved about 4,500 configurations. The remaining samples were packed beyond the built-in ConfuserEx obfuscation routine, and as such, the raw configuration strings were not present.
These samples were run through a local instance of the open-source Cuckoo Sandbox, where the process dumps were extracted. The same script was applied to these process dumps, where we were able to obtain an additional 10,200 configurations, leaving us with a total of 14,700 parsed LuminosityLink configurations.
As the samples were processed, further keys were discovered to be used by the author. The following additional three strings were used to generate the keys to LuminosityLink samples.
This conf’ig contains nothing useful. Quit acting as if you’re cool by decrypting it.
Resources.SMARTLOGS
Specify a Password
It appears as though the author of LuminosityLink is not without a sense of humor. Additionally, as we parsed older samples, it was discovered that the configuration made a change sometime between February and June of this year. Fewer options were available in the configuration of older samples. The provided script accounts for these differences and various keys used.
Using the aggregated data from the 14,700 configurations, the following high-level statistics were pulled:
Figure 7 Prevalence of enabled settings in LuminosityLink configurations
Top C2 TLDs/IP Addresses
[3308] ddns[.]net
[2537] duckdns[.]org
[904] no-ip[.]biz
[670] chickenkiller[.]com
[378] no-ip[.]org
[377] mooo[.]com
[242] fishdns[.]com
[174] no-ip[.]info
[165] ignorelist[.]com
[157] freedns[.]su
Top Build IDs
[4829] HOME
[83] Client
[82] crtx1
[71] M4CHINATION
[65] CSGO
[65] NEW
[59] Slave
[47] CAPO
[44] Youtube
[42] PROJECT.D
Top Executable Names
[1973] sysmon.exe
[1831] client.exe
[1254] helper.exe
[1207] repair.exe
[1087] winlogon.exe
[509] svchost.exe
[315] Luminosity.exe
[83] WinCOMHost.exe
[82] chrome.exe
[61] windowsbootapp.exe
Top Ports
[1866] 6318
[1055] 1400
[493] 1604
[412] 1337
[214] 3175
[182] 22028
[162] 9045
[119] 2122
[115] 100
[113] 9999
The parsed configuration data, provided in the CSV file format, is being freely provided to the security community in the hope that protections will be created against this threat.
Conclusion
LuminosityLink, while marketed as a systems administration utility, is a formidable keylogger and backdoor used by a large number of criminals. To date, Palo Alto Networks has witnessed over 50,000 attempted infections of LuminosityLink, encompassing 18,000 unique samples. The malware is cheap and readily available to the public, making this a dangerous threat to both organizations and individuals alike.
By reverse-engineering LuminosityLink samples, we were able to statically extract and parse the embedded configuration, which in turn provides valuable information about with what hosts and ports the malware is configured to communicate. It also provides information regarding configured protections configured within the executable, as well as installation information.
Palo Alto Networks customers are protected from this threat in the following ways:
An AutoFocus tag can be used to track this malware family
All LuminosityLink samples are appropriately marked as malicious in WildFire
All identified domains are flagged as malicious
Network traffic is appropriately identified and blocked as threat ID #14460 (LumonosityLinkRAT.Gen Command And Control Traffic)
Appendix
An extraction and parsing script for LuminosityLink samples can be found here.
A script to be used to parse plain configuration strings can be found here.
A CSV file containing all of the configuration data extracted from Palo Alto Networks sample set can be found here.
![TechDocs_logo_lrg_final[1]](https://i0.wp.com/researchcenter.paloaltonetworks.com/wp-content/uploads/2016/05/TechDocs_logo_lrg_final1-500x153.jpg?resize=500%2C153){kind=logo}
