Lastline has uncovered a new attack vector launched through Microsoft Excel spreadsheets, and just recently expanded into other Office applications. The challenge is not only the novel technique used but also the difficulty in detecting it in its early stages. Too often companies, due to lack of malware behavior analysis, dismiss alerts as false positives, losing precious time during which the malware is busy stealing credentials. In this post, we’ll describe how the attack works, and what typically happens during the initial days of the attack.
The Attack and the Payload: Dissected
Recently Lastline Labs published a blog post titled “When Scriptlets Attack,” about a trending new infection method in Microsoft Excel spreadsheets that we first saw on the 29th of November. As per the earlier blog post, we scanned the file on Virustotal and only three tools detected it as malicious.
With such a low detection rate of this method of attack, many organisations would be at the mercy of the scriptlets payload. Indeed with only three detections, many would consider the original Excel infection vector to be a false positive and do no further investigation or remediation of this attack. The payload that is delivered by the Excel scriptlet is Loki, a notorious credential stealer malware tuned to focus on exfiltrating usernames and passwords (see Figure A).
Figure A: Dark web ad promoting Loki Bot malware for stealing credentials
This is a double whammy for most security response teams. Firstly, the low detection rate of the infection vector would lean people towards a False Positive verdict. And secondly, even if they discovered the main payload, Loki, mitigating the behaviour of the threat is often incorrectly implemented. This leaves the victimized organisation open to a secondary malware-less attack when the exfiltrated credentials are used by subsequent threat actors to gain unauthorised access and then try to move around inside the network.
Fast forward nearly two weeks. As of 10 December, 12 days later after the first submission, the malicious Excel scriptlet spreadsheet has attracted 12 positive verdicts on Virustotal out of nearly 60 AV tools (see Figure B).
The situation, now that AV tools have caught up, is that security teams suddenly receive an alert from an AntiVirus scan in the internal environment, and they start the validation process. In gathering intelligence on the file, they would see that it now has 12 positive detections, and this level takes it over the line from a false positive to a possible malware infection. Starting 12 days after the initial infection, they would try to build evidence of the behaviour of the potential victim’s system and match it against any IoCs stemming from the original Excel document. The team would have to track back through various logs until they found a connection to a Gabon Top Level Domain [.ga] website, offered from a free web hosting service that downloaded an executable file – _output23476823784.exe – to the victim (see Figure C). Provided with this information, they would instigate a further scan for the second stage payload, or hunt for known IoCs of the payload.
Confirmation of a file hash on the local system would then be reinforced with further intelligence validation. The file _output23476823784.exe was unknown to VirusTotal before the 10 December. However, at Day 12 we have roughly 50% of detection engines returning positive convictions of .exe malware file that was delivered by the Excel scriptlet.
Now that we have a confirmed infection of the host, remediation action can begin. The vast majority of Anti-Virus labels (see Figure E) for the _output23476823784.exe payload indicate that it is a Trojan.Generic variety of payload. There are various discussed methods of remediating a generic Trojan infection including using cleanup tools from AntiVirus vendors, or as is often the case, a simple re-image of the system.
To summarize, as of the end of Day 12, we found an infected client with a malicious Excel spreadsheet that communicated with a domain and installed a generic Trojan, which was subsequently detected and the client system was reimaged. Further studying of logs found that the generic Trojan made some callbacks to a C&C server, but no lateral movement was seen, and a decision was made to close the incident.
Detection Balance, not Bias
Two pieces of conventional wisdom have driven the industry into this response process:
1. Prevention is better than a cure.
Nobody wants to be known as a “traditional security vendor” that cannot keep pace with the massive quantities of unique malware being produced. Instead, the Security industry has devised new detection methods to prevent malware from entering systems based in part on AI and ML, to statically determine good or bad elements of a file … This is fine if the goal is to try to prevent 100% of attacks from ever entering the organisation. It’s a natural preference to simply stop malicious attacks entering the internal network, the problem is, when you miss one, it becomes very hard to triage and mitigate threats if all you have a heuristic alert produced by static analysis at the gateway.
2. Nobody wants malicious software to run in a production environment.
In attempting to address the quantity of detections issue, we, the security industry, have sacrificed quality of detections. We need to enrich our static protections with dynamic behavioural analysis to provide better protection for the attacks that breach defences. You need a malware analysis platform to do this.
Figure F shows the actual capabilities or behaviours of the Trojan.generic file _output23476823784.exe that was downloaded from the Excel spreadsheet. We can see that this Trojan is heavily weighted to stealing passwords. If our detection and remediation processes rely on static detections to alert and have no behavioural intelligence, then we are incorrectly closing incidents that still pose a significant risk.
Behavioral Intelligence is the ability to point security operations at clear, concise remediation instructions. The Behavioral Intelligence Quotient (BIQ) is improved by extracting the purpose and intent of any potentially malicious encounter. The higher the BIQ in an organisation, the faster threat containment occurs using optimal resources with minimum impact.
Getting to Know the Payload: Loki Bot
The payload in question is further identified by behavioral intelligence as Loki bot.
Below (Figure G) is a Dark Market advert for Loki.
Promotional videos of Loki, (see Figure H) demonstrate its prowess at capturing credentials from various applications, especially FireFox (47% of the stolen credentials) and Chrome (41%), while Windows and email credentials make up only 1-3%.
Once credentials have been stolen from a victim, Loki displays which sites are now vulnerable to identity theft (see Figure I). These include social media sites, payment portals, bitcoin wallets, and even a Moroccan government login.
Conclusion
Our detailed Labs blog post about “When Scriptlets Attack” shows how organisations with a low BIQ suffer from extended compromise dwell time (in this case 12 days), inefficient resource usage, unnecessary expenditure of analyst and responder time to correctly triage the threat (approximately 20 man hours), and exposure to a secondary attack vector of file-less attack using unchanged credentials to gain unauthorised access.
If you have a high BIQ, informed by malware behavioural analytics, the breach is not inevitable. Seeing each specific activity engineered into a file makes it immediately obvious when an encounter is malicious. Better security is not just about prevention. The scriptlet and Loki attack demonstrate how Behavioral intelligence with visibility of the real capabilities of the attack makes it possible to detect the attack and implement mitigation efforts on day one instead of waiting until day 12 when it finally is recognized by a critical mass of AV tools and untold credentials have already been stolen.
The post Novel Excel Spreadsheet Attack Launches Password Stealing Malware Loki Bot appeared first on Lastline.
Article Link: https://www.lastline.com/blog/password-stealing-malware-loki-bot/