This will be a TLP:WHITE talk about an incident response that I had to face with my team in the medical sector.
In December 2019, a Belgian hospital required our help to manage a breach of their informations system. During this intervention we were able to collect a lot of artifacts and information about the attacker's methods and tools.
We propose to detail the attack and explain the droppers, the malware and the TTPs used. We attribute this attack to the TA505 group with high confidence since we were able to cross-check many details in infrastructure, tools and habits from several other reports.
During this talk I will outline:
Initial compromise
The client was compromised (as usual) using a VBA enabled malicious Office document. The interesting point here is the payload. The maldoc payload contains two PE binaries: one for 64-bit systems and one for 32-bit systems responsible for the installation of the backdoor malware.
I will discuss:
- How the payloads and infrastructure were prepared shortly before the attack
- The key artifact of the dropped maldocs
- The capacity of the dropper, the dropper report basic information
- Used decoy documents (multiple forms available in the wild XLS/DOX)
- Delivery methods.
Persistence
The attacker deployed a malware named SDBbot on the patient 0. This malware is a backdoor with a couple of interesting capabilities allowing the attacker persistence inside the information system. SDBbot is a simple malware in terms of conception. It uses a simple persistence method when run with simple user rights. The connectivity is also really simple with this malware since it uses only TCP connections. This is an interesting point since this network protocol allows an effective detection of the CC. Besides that, SDBbot is also a fileless malware. The main malware is stored in the registry in a blob containing the memory mapped PE and a dedicated small 32- or 64-bit DLL launcher is generated per victim. This specificity also allows SDBbot to be less present in public sandbox reports and VirusTotal, helping to hide the threat actor.
I will cover in this part:
- How SDBbot is stored and launched from the registry
- The unique per-workstation loader with hard-coded UUID
- The capacity of SBDbot. The network protocol used and its weaknesses.
Actions on objectives
The attacker used pentester skills to compromise the whole informations system. In our case it was not really complicated since the Active Directory servers were vulnerable to MS17-10. The attacker used Metasploit to perform the compromise and pivoting using a combination of PowerShell for remotely launching meterpreter, a repackaged TinyMet client and Psexec. The actor spread over 50 servers and workstations.
I will cover in this part:
- The tools and technique used for pivoting
- TTP and tools used for extracting the AD database.
- How SDBbot is deployed and persistent at system level
- How we use SDBbot CC configuration feature to block globally the attacker.
Finding SDBbot
In this last part I will explain how to hunt for SDBbot in the Internet space. Since this malware use a simple binary handshake it is easy to spot the malware running in a victim network by looking at network level with Suricata Rules. It is possible also to hunt SDBbot efficiently in the wild using a dedicated Nmap NSE script. It is interesting for the moment to see that all SDBbot C&Cs we found didn’t show the SDBbOT port on Shodan. It look likes the group is managing blacklisting quite well.
I will cover in this part:
- How to detect it in a victim infrastructure in memory and network
- How to detect it in the wild
- Tricks to find candidates based on PDNS.