Most have already heard about ransomware attacks, either in the news or as they have been affected by them. Did you known that ransomware attacks are a subgroup of Advanced Persistent Threats (APT)? APT attacks are no longer only affecting large companies, but also mid-size companies, public authorities and individuals.
APT groups and malware attacks are on the rise and it takes more than an antivirus engine to detect them. With Threat Simulation exercises they can be realistically simulated in a safe and risk-evaluated environment. When simulating an APT it can include attacks of Advanced Persistent Threat actor and also their toolkit. The IT-Team gains insights into behavior based analysis by combining evidence of attacks to identify the full picture and extent of the attack. The benefit does not only include a detailed report, but also receiving training for the team. All of this helps to be armed against the next attack.
Summary
In this post we will jump into an exemplary simulation of TrickBot, which is a well known malware. Even though TrickBot is well known, it still affects many organizations worldwide. We will cover the question of “What is Threat Simulation?“, an approach to Threat Simulation and an example simulation. After reading this post you will have a good understanding about Threat Simulation exercises and why software may not always be the answer when detecting a sophisticated attack.
Difficulty of detecting an ongoing attack and variants
In one of our previous posts we have introduced the concept, players and focus of Attack Simulation exercises, and our risk-based approach. One of the discussed services is Threat Simulation (also known as APT Simulation, Adversary Simulation, Threat Emulation). In this simulation we mimic the behavior of an Advanced Persistent Threat (APT) actor.
Detecting an ongoing attack or reproducing one based on artifacts is a difficult task. Even though most organizations have detailed log files on systems, most have a lack in correlating gathered evidence. This does especially include correlating evidence from multiple places to detect/reproduce the attack. Internal teams are often good in remediating alerts from their tools, but lack training in detecting a sophisticated attack. Known good prevention methods were based on signatures (files, strings, etc.). In some cases, they have also been extended by behavior detection/heuristic, monitoring of the operating system’s API usage or other means. However, this is not sufficient anymore.
The German Bundesamt für Sicherheit in der Informationstechnik (BSI) mentioned in a publication that 322.000 new malware versions were detected on a daily average between 01.06.2019 and 31.03.2020. Heuristic approaches have been a good start, but even those have been proofed to not always be fail-safe. Once it is known how they work and what they look for, they can be bypassed by an attacker.
Behavior based detection has been a good start, but the human factor will always play a role in detecting sophisticated attacks!
What looks like an unsolvable challenge, is trainable with real-world attacks of known APT actors or completely tailored attack scenarios. You may ask yourself how you can identify threats affecting you or your organization? Threat Intelligence is one of the answers that can be given. In the below we will look into the simulation of a well-known APT group and software they use on compromised systems. Like we did in our previous posts, we map used Tactics, Techniques and Procedures (TTPs) against the kill-chain.
Planing Threat Simulation exercises
Before starting with Threat Simulation we need to identify the APT group and/or Software we want to simulate. This analysis (Threat Intelligence) is done together with our client. We identify common threats to the organization’s branch of industry and then select the appropriate threat for the simulation. When selecting the threat we ensure that its main TTPs (Initial Access, Execution) fit to the client’s environment. For example, it would not be profitable to simulate a malware that uses External Remote Services during the Initial Access phase, if no external remote services are offered in the client’s network.
During the simulation we would not try to bypass security controls – unless it is part of the TTPs – (like disabling the Antivirus software, circumventing application restrictions), but use the system in the same way an employee could do. This means that we would open attachments in emails (which are used by the threat we simulate) and use the less secure option when getting asked by the operating system. For example, if a Microsoft Office product asks if we like to enable macros in the document, then we would do it.
In the below we will have a look at TrickBot which spreads itself via Phishing campaigns. Looking at the TTPs used by TrickBot already reveals what kind of access we recommend to simulate its behavior. In this case we would recommend the client to setup a new employee in their network (likely Active Directory) and assign a laptop/system to the new user. The system should typically be configured in the same way as it is done for a standard employee. Most organizations use Gold Images during the setup of a new employee system, which also minimizes the support we need from our clients during the preparation phase.
Simulating TrickBot in a Threat Simulation
The APT group Wizard Spider has been operating since at least 2018 and focuses on ransomware campaigns and banking trojans. They changed their existing toolkit from EMOTET to TrickBot after the shutdown of the EMOTET network in 2021. However, both tools used similar TTPs and behavior, but TrickBot is still known to affect many organizations worldwide.
With a Threat Simulation exercise we walk through the attack chain of known APT groups and software to verify the resistance and in place security controls. TTPs used in the attack have been aligned with the MITRE ATT&CK framework and can be viewed in the ATT&CK Navigator.
The attack plan is designed to be repeatable and each phase of the attack can be performed independently using different TTPs. This is used to highlight a potential attack path of TrickBot and identify gaps in technical or process-based security controls and procedures. The below image shows some of the TTP used by TrickBot:
In the below sections we will discuss each phase and some of the TrickBot TTPs in more detail. When actually delivering a Threat Simulation we pick one TTP per category and iterate over the categories with different combinations. This is done to verify if the behavior is detected by in place security controls or not. We tend to start with the stealthiest ones and gain louder with every time we have completed all phases of the kill-chain.
Initial Access
Observed TrickBot phishing emails contained content regarding tax incentive notification and email keywords like FW: or RE: in the subject to trick the user into opening the document.
E-mails are part of the daily business in many organizations and employees, such as Human Resource or Office Assistants, are expected to open incoming documents. It is also still common that macros are enabled in Microsoft Office products due to legacy reasons.
TrickBot is known to gain Initial Access to a system via Spearphishing E-Mails which either contain malicious attachments or links to malicious files. Attached documents use for example macro enabled Microsoft Office documents.
Even though it is common that macro enabled documents are disallowed as an E-Mail attachment, it is very uncommon that files are reviewed on their extension or MIME type while downloading. Downloaded files are often not inspected – on network level – as the data source’s endpoint is protected by SSL. SSL inspection would undermine the overall security and privacy of the user which might be problematic in some countries.
In the simulation we would start with the less noisiest and detectable way to deliver our simulation software. In the first run it would be: Delivery of the document via a Phishing E-Mail containing a link to a malicious file. Once the E-Mail arrived in the user’s inbox, we would then simulate an innocent user and open the document. This includes accepting security warnings if offered by the application.
Persistence
TrickBot attempts to disable antivirus protection software and creates a scheduled task that is executed on system startup.
Remaining active on a compromised machine, even after a reboot, is a risky but also required task for persistence that is also used by TrickBot.
TrickBot gains Persistence on the system by modifying scheduled tasks, modifying registry run keys / startup folders and modifying windows services. For example, TrickBot creates a new scheduled tasks with a name of “SpeedNetworkTask”. Additionally TrickBot has been observed installing a bootkit on the system.
The way of persistence depends on the systems configuration, running security controls and escalation vectors. Throughout our simulations we have seen that Endpoint Protection Systems highlight different kind of persistence methods. Therefore, we use our experience about the in-use Endpoint Protection System to select the Persistence method in our first run which is unlikely to get raised by the system.
Impact
TrickBot verifies if the device is affected by known vulnerabilities to change the UEFI/BIOS for persistence and a remote kill switch.
In some cases TrickBot has been observed to Impact a device by overwriting or erasing the UEFI/BIOS firmware of the compromised device.
As part of the simulation we verify if it is possible to change the UEFI/BIOS of the device to remain persistent even after a cleanup of the device. This step is also useful to review how devices are cleaned/deployed before they get issued to a new employee.
Retracing the attack chain
After the simulation we prepare a detailed report mentioning each performed action. With the fully transparent approach it is possible to identify when each attack step occurred. This is done by providing timestamps when an action occurred, which asset (system, user account, premise, etc.) was targeted and from where the attack happened. Additionally, full insights are given into executed command and attack chains. This information is also analyzed with the IT-Team/Blue Team in our feedback sessions, to identify which security controls did not work as expected or which attacks have been missed.
Conclusion
Threat Simulation exercises are the first step to defend against sophisticated attacks while performing an interactive simulation. Internal teams can start with detecting known malicious behavior and prepare for even more sophisticated attacks of unknown APT groups. Even though Threat Simulations follow a strict playbook and limit the attack surface, they provides explicit threat training for the defending team and insights into currently implemented security controls and their resistant.