Hunting Ducks – A Threat Hunters Take on Ducktail Stealer

by Jun 29, 2023

This post will look into DuckTail Stealer and their current .NET-based payloads. The stealer is well known for targeting marketing companies. Ducktails attacks usually come via email, posing as marketing campaigns or hiring offers. They use legitimate cloud hosts like iCloud, OneDrive, and Google Drive to link to ZIP archives. The archives often contain harmless images and videos, with fake Word, PDF, and other standard document format files hidden among the otherwise harmless material. Those fake files masked as documents are executable files loading the stealer malware.

Triage of the Loader

DuckTails loaders usually have an icon resembling popular document formats like docx, pdf, xlsx, etc.; however, the files are regular .exe files.

DuckTail uses self-contained .NET apphost binaries. The files are pretty large; an average DuckTail sample has a size of 60-80MB without any added zero bytes or other bloating tricks applied. These self-contained apps allow them to run .NET Core even on machines that do not have the correct runtime installed.

DuckTail has access to several code-signing certificates. However, not all in-the-wild samples are signed. While analyzing various samples, we observed that most certificates have Vietnamese names, starting with CONG TY NHH and, recently, CONG TY TRACH.

Although similar in name, the certificates were registered with different root CA’s. We recently published a Yara rule covering all DuckTail certificates currently known to us.

To open self-contained .NET apps, we used ILSpy, an open-source .NET decompiler. ILSpy lets us view and extract the managed .NET files embedded in the native host. Before extracting the main payload, we took a quick look at the appname.deps.json in here. We can find all the embedded dependencies and the main runtime app:

  • Telegram.Bot – a popular library to interact with Telegrams API from .NET code. Like many other stealers, DuckTail uses the Telegram API to exfiltrate data.
  • Portable.BouncyCastle – a popular library for cryptography commonly used in .NET stealers.
  • RedGate.SmartAssembly.* A commercial .NET obfuscator. While not necessarily malicious, threat actors often abuse obfuscation to hinder analysis and evade detection.
  • Microsoft.Data.Sqlite While not malicious, in the context of other dependencies, this library is likely imported to read browser cookie storage.

The Main App

Next, we are taking a closer look at the main app ZipBro1Wal.dll, the actual .NET code responsible for unpacking and loading the stealer payload.

The code is obfuscated using SmartAssembly. Strings are encrypted, and many of the calls are hidden through dynamically resolved delegates, making initial analysis quite troublesome. In this post, we will focus only on the threat-hunting aspects rather than so much on unpacking and analyzing the loader in depth. Despite the obfuscation, we found a bunch of fields and types that remain unchanged across different samples. Since SmartAssembly has unique names for all its runtime components, we can use it as one potential identifier for DuckTail. Apart from the obfuscator runtime, we identified a few more unique and consistent names over various samples. The main namespace SDCBundle and its classes AppRunHandler, CryptService, and FileUtils were present in almost all samples.

Additionally, the AppRunHandler class contains three config fields:

  • GUID_APP stores the Mutex used by the loader
  • typeName stores the type name where the payload EntryPoint is located
  • methodName stores the name of the method that serves as the payload EntryPoint

Since the actual stealer payloads are AES encrypted and compressed, we cannot directly detect them from the loader file; however, we have found quite a few indicators for the loaders that we can now assemble into a Yara rule:

rule MAL_MSIL_NET_DuckTail_Stealer_Blog_Post_Jun23 {
  meta:
     description = "Detects DuckTail stealer loaders using SmartAssembly"
     author = "dr4k0nia"
     date = "2023-06-29"
     reference = "Internal Research"
     hash1 = "d27280102bd64cb36db81db07d41466649023a8b1acdb960129303b69cffee60"
     hash2 = "c19d6e7af08d0461da00f0ca2b28276eb5a1f2c922c2794abe73f5e5ac37754f"
     score = 80
  strings:
     $sa1 = "Telegram.Bot" ascii fullword
     $sa2 = "Portable.BouncyCastle" ascii fullword
     $sa3 = "Microsoft.Data.Sqlite" ascii fullword
     $sa4 = "SmartAssembly.StringsEncoding" ascii fullword
     
     $sb1 = "SDCBundle" ascii fullword
     $sb2 = "AppRunHandler" ascii fullword
     $sb3 = "CryptService" ascii fullword
     $sb4 = "FileUtils" ascii fullword
     
     $sc1 = "GUID_APP" ascii fullword
     $sc2 = "typeName" ascii fullword
     $sc3 = "methodName" ascii fullword
  condition:
     uint16(0) == 0x5a4d
     and all of ($sa*)
     and ( 2 of ($sb*) or 2 of ($sc*) )
}

First, we identify the file as a PE image. Next, we search for the imports we know will be present. As secondary indicators, we chose the type names and the field names. We accept either. In an ideal case, we would search for byte patterns based on CIL instructions or raw array contents; however, that approach is not feasible in this case due to the obfuscator messing with the branching, which results in different CIL bodies for every obfuscated sample.

Conclusion

Remember that the rule above is not a catch-all, as DuckTail is evolving rather quickly. We see them changing their loaders and certificates within only a few weeks. After some of their certificates were posted on Twitter we saw them adopt new certificates, changing root CA and differing from the previous name pattern. We also identified samples that stopped using SmartAssembly instead of opting for a custom obfuscator. We suspect that this trend will continue.

For more in-depth YARA coverage of the DuckTail family, checkout our Valhalla rule feed. There you can find rules covering not only the .NET loaders but also the stealer payloads, PowerShell scripts, and other tools used by DuckTail. You can search for all DuckTail-related rules using the keyword ducktail.

DuckTails tactics have not changed much, as we can read in other articles like this one from deepinstinct. they have been using the fake marketing campaign strategy for a long time now. Ducktail still utilizes various platforms, like Google Drive, Microsoft OneDrive, and iCloud, to host their malicious archives. Its primary objective is to infiltrate businesses with access to ad accounts across the internet. Their stealer payloads focus on Facebook Business accounts, containing multiple classes to collect additional information from Facebook Business accounts and modify specific account details directly from the compromised host. We suspect that DuckTail is using these Facebook accounts to spread malicious advertisements using legitimate accounts.

If you enjoyed this blog post and would like to read more posts like this, feel free to subscribe to our Newsletter.

About the author:

Jonathan Peters

Jonathan Peters works as a Threat Researcher and Detection Engineer. He has a background in software development and is experienced in .NET, primarily developing obfuscation and deobfuscation solutions. Jonathan began reverse-engineering software in 2015, which eventually led him to malware analysis. Due to his interest in malware analysis and detection solutions, he began writing his own tools and Yara rules. He engages with the cybersecurity community as @cod3nym on Twitter.

Newsletter

New blog posts (~1 email/month)

GDPR Cookie Consent with Real Cookie Banner