Right around the time I decided to pursue my GREM Gold Certification, I happened to come across a sample of malware that I had never seen before. The sample was easily identifiable due to the unique User Agent String found within its network traffic. However, when attempting to find research regarding the malware’s characteristics and capabilities, not much could be found. This lack of information pertaining to malware that is actively being distributed in the wild is what drove me to select Loki-Bot as the topic for my Gold Paper.
Now, before I tell you everything you’ve ever wanted to know about Loki-Bot, I’d like to take this opportunity to say a few words about Gold level GIAC certifications. If you have the opportunity to pursue a Gold level certification, I HIGHLY recommend it. While passing the Silver level (multiple choice exam) validates (at least short-term) competency, the Gold level (research paper) really ingrains the skills. It’s one thing to understand the content… but it’s another to have to explain it to someone else… in written form…
So, you know..
Okay, so back to it. My Gold paper on Loki-Bot was accepted and published to the SANS Reading Room on 06/28/2017. I gave you a little taste in my recent post titled “Loki-Bot: Come out, come out, wherever you are!“. You can find the full paper here:
Fair warning: the paper has 177 pages of content but it details every nook and cranny of Loki-Bot. On page 58, a disconnect begins between the Figure # shown and the reference to the Figure in the text and only gets worse as the document progresses. To address this, I’ve uploaded a revised version to this blog with that issue remedied. You can get it here:
If you come across any other issues, please let me know so I can address them.
Cheat Sheet
So that you don’t have to wade through the entire paper to find the information you are looking for, here are the key attributes of Loki-Bot that you should be aware of:
- Loki-Bot employs function hashing to obfuscate the libraries utilized. While not
all functions are hashed, a vast majority of them are. - Loki-Bot accepts a single argument/switch of ‘-u’ that simply delays execution (sleeps) for 10 seconds. This is used when Loki-Bot is upgrading itself.
- The Mutex generated is the result of MD5 hashing the Machine GUID and trimming to 24-characters. In my paper, this value was “B7E1C2CC98066B250DDB2123“.
- Loki-Bot creates a hidden folder within the %APPDATA% directory whose name is supplied by the 8th thru 13th characters of the Mutex. In my paper, this value was “%APPDATA%\ C98066\”.
- There can be four files within the hidden %APPDATA% directory at any given time: “.exe,” “.lck,” “.hdb” and “.kdb.” They will be named after characters 13 thru 18 of the Mutex. In my paper, this value was “6B250D.” Below is the explanation of their purpose:
File Extension | File Description |
---|---|
.exe | A copy of the malware that will execute every time the user account is logged into |
.lck | A lock file created when either decrypting Windows Credentials or Keylogging to prevent resource conflicts |
.hdb | A database of hashes for data that has already been exfiltrated to the C2 server |
.kdb | A database of keylogger data that has yet to be sent to the C2 server |
- If the user is privileged, Loki-Bot sets up persistence within the registry under HKEY_LOCAL_MACHINE. If not, it sets up persistence under HKEY_CURRENT_USER.
- The first packet transmitted by Loki-Bot contains application data.
- The second packet transmitted by Loki-Bot contains decrypted Windows credentials.
- The third packet transmitted by Loki-Bot is the malware requesting C2 commands from the C2 server. By default, Loki-Bot will send this request out every 10 minutes after the initial packet it sent.
- Communications to the C2 server from the compromised host contain information about the user and system including the username, hostname, domain, screen resolution, privilege level, system architecture, and Operating System
- The first WORD of the HTTP Payload represents the Loki-Bot version
- The second WORD of the HTTP Payload is the Payload Type. Below is the table of identified payload types:
Byte | Payload Type |
---|---|
0x26 | Stolen Cryptocurrency Wallet |
0x27 | Stolen Application Data |
0x28 | Get C2 Commands from C2 Server |
0x29 | Stolen File |
0x2A | POS (Point of Sale?) |
0x2B | Keylogger Data |
0x2C | Screenshot |
- The 11th byte of the HTTP Payload begins the Binary ID. This might be useful in tracking campaigns or specific threat actors. In my paper, this value was “XXXXX11111” but “ckav.ru” is another Binary ID that seems to be prevalent in the wild. If you come across a Binary ID that is different from these two, let me know!
- Loki-Bot encrypts both the URL and the registry key used for persistence using Triple DES encryption.
- The Content-Key HTTP Header value is the result of hashing the HTTP Header values that precede it. This is likely used as a protection against researchers who wish to poke and prod at Loki-Bot’s C2 infrastructure.
- Loki-Bot can accept the following instructions from the C2 Server:
Byte | Instruction Description |
---|---|
0x00 | Download EXE & Execute |
0x01 | Download DLL & Load #1 |
0x02 | Download DLL & Load #2 |
0x08 | Delete HDB File |
0x09 | Start Keylogger |
0x0A | Mine & Steal Data |
0x0E | Exit Loki-Bot |
0x0F | Upgrade Loki-Bot |
0x10 | Change C2 Polling Frequency |
0x11 | Delete Executables & Exit |
Suricata Signatures
Since I was able to reverse engineer Loki-Bot’s packet structures, it was my duty to take what I had learned and apply it to the creation of new intrusion detection signatures. The following IDS signatures were created by me and improved/published via EmergingThreats:
Rule SID | Rule Name |
---|---|
2024311 | ET TROJAN Loki Bot Cryptocurrency Wallet Exfiltration Detected |
2024312 | ET TROJAN Loki Bot Application/Credential Data Exfiltration Detected M1 |
2024313 | ET TROJAN Loki Bot Request for C2 Commands Detected M1 |
2024314 | ET TROJAN Loki Bot File Exfiltration Detected |
2024315 | ET TROJAN Loki Bot Keylogger Data Exfiltration Detected M1 |
2024316 | ET TROJAN Loki Bot Screenshot Exfiltration Detected |
2024317 | ET TROJAN Loki Bot Application/Credential Data Exfiltration Detected M2 |
2024318 | ET TROJAN Loki Bot Request for C2 Commands Detected M2 |
2024319 | ET TROJAN Loki Bot Keylogger Data Exfiltration Detected M2 |
Loki-Parse
I was also able to develop a python script (loki-parse) that can detect Loki-Bot related network traffic, either through sniffing the wire or reading in a PCAP, and parse/decode the contents of the payload. The result is JSON formatted output of what was sent the C2 server, like so:
{ "Compromised Host/User Data": { "Compressed Application/Credential Data Size (Bytes)": 2310, "Compression Type": 0, "Data Compressed": true, "Encoded": false, "Encoding": 0, "Original Application/Credential Data Size (Bytes)": 8545 }, "Compromised Host/User Description": { "64bit OS": false, "Built-In Admin": true, "Domain Hostname": "REMWorkstation", "Hostname": "REMWORKSTATION", "Local Admin": true, "Operating System": "Windows 8.1 Workstation", "Screen Resolution": "3440x1440", "User Name": "REM" }, "Malware Artifacts/IOCs": { "Binary ID": "XXXXX11111", "Loki-Bot Version": 1.8, "Mutex": "B7E1C2CC98066B250DDB2123", "Potential Hidden File [Hash Database]": "%APPDATA%\\C98066\\6B250D.hdb", "Potential Hidden File [Keylogger Database]": "%APPDATA%\\C98066\\6B250D.kdb", "Potential Hidden File [Lock File]": "%APPDATA%\\C98066\\6B250D.lck", "Potential Hidden File [Malware Exe]": "%APPDATA%\\C98066\\6B250D.exe", "Unique Key": "g5cy2", "User-Agent String": "Mozilla/4.08 (Charon; Inferno)" }, "Network": { "Data Transmission Time": "2017-04-27T15:03:20.921806", "Destination Host": "185.141.27.187", "Destination IP": "185.141.27.187", "Destination Port": 80, "First Transmission": true, "HTTP Method": "POST", "HTTP URI": "/danielsden/ver.php", "Source IP": "172.16.0.130", "Source Port": 49344, "Traffic Purpose": "Exfiltrate Application/Credential Data" } }
You can find this script on my GitHub page.
One thought on “Loki-Bot: Inside & Out”