DecryptedTech

Friday12 August 2022

MoonBounce UEFI Malware linked to APT41 by Kaspersky Researchers


Reading time is around minutes.

APT group 41 also known as Winnti has been tied to a wonderful new piece of malware that does not infect your operating system, but the UEFI firmware on your device. The malware in question has been dubbed MoonBounce by the security researchers at Kaspersky who are responsible for finding it. APT41 has been in operation for a while and is identified by their tactics techniques and protocols (TTPs) which include stealthy attacks meant to maintain a long-term presence for information gathering on the target.

MoonBounce is not the first of its kind, in fact we wrote about the concept of UEFI malware years ago when we saw it at Def Con. The Kaspersky team was not able to identify how MoonBounce infects its targets, but there are several methods that can be used. The original way that we saw was thought a code spray which targeted the UEFI updating process inside the OS. Other methods that have been talked about and demonstrated include Intel’s IME and the always fashionable supply chain targeting. Regardless of the method once in place the malware is very efficient and hides itself well.

According to researchers, the malware uses a set of hooks that go after the execution of services in the EFI Boot Services Table. These hooks redirect the flow of these services to shellcode put in place by the attacker. This shell code is appended to the CORE_DXE image. From there the malware uses other hooks in the boot up sequence including the Windows loader. Once complete, the malware launches a driver into the memory address space of the Windows kernel. This driver loads during kernel initiation and injects a payload into the svchost.exe process. The only thing left for it to do is to phone home for instructions on next steps which is to grab a payload and run it in resident memory. The Kaspersky team were not able to get the payload for analysis either.



MoonBounce Execution DiagramMoonBounce Execution Digram
Source: Kaspersky

The research team was able to identify and catalog what the UEFI malware does and notes that one phase, the hooking of ExitBootServices, could have come from the Vault7 leak. Between that leak and the one from the Hacking Team there are ample samples of how to do this out there. We fully expect to see more and more attacks of this nature being uncovered as security research teams start to look for them more closely.

This style of attack is not meant for quick gain, it is one you use when you are looking for a long-term presence and to grab a continuous stream of information from the target, so they are not going to be easy to detect. Your traditional endpoint protection software is likely to miss this for now which means the detection phase moves to the network level. Monitoring packets and destinations for network sessions will be key in finding out if something like this is happening. Security teams will need to stay on top of the latest threat intel. Having a list of known C2 servers will be key in preventing communication between the malware and the people running it.

Although the detection is a big find and a win (of sorts) the fact that both the means of infection and the original payload remain unknown means that the attackers can change parts of execution and reuse their biggest asset, the UEFI malware. The disclosure of the patter of attack, the user mode malware in use and even our new understanding of the injection process gives them a good roadmap for change. Since injection of malicious software into existing processes and memory space is something that current anti-malware can detect, maybe they will move their new code to places that are not currently monitored (like GPU memory space). It is always going to be a game of cat and mouse when it comes to the Advanced Persistent Threat groups, and this will not change any time soon.

The good news is that there are always ways to limit exposure to threats. Kaspersky (and others) recommend ensuring that you are use Secure Boot by default. Best practice recommendations include:
Updating your UEFI firmware regularly
Ensuring that BootGuard is enabled.
Turn on Trust Platform Modules

These are all items that should be part of your hardware level security principals and hygiene. If you are using MS365 you can set these as baseline security requirements or as part of a compliance policy for access to organization resources. If you really want to get fancy, you can set up policies that even prevent user logon to the device (if AAD connected). On-Prem environments can get in on the fun with Network Access Control systems that can detect these items and much more (like blocking devices with the Intel Management Engine accessible). These options are a pain to maintain and can make users annoyed, but at the end of the day, if they are set up early, they become part of the routine.

APT41 and others like it are not going away, they will continue to flourish and will even branch off into new APT groups. Proper device, hardware, OS level, and network security measures are a must in today’s threat landscape. This is even more true when it comes to a distributed workforce with a heavy cloud presence. Stay safe out there.

Last modified on Friday, 21 January 2022 07:50

Leave a comment

Make sure you enter all the required information, indicated by an asterisk (*). HTML code is not allowed.