Botconf 2023

The Gh0st Remote Access Trojan is a long-standing threat dating back to 2001 that is still active to this day. Following its release to the public in 2008 as version 3.6 Beta, it garnered the attention of Chinese-speaking threat actors in particular who began forking and upgrading the toolset to suit their needs. Various APT (Advanced Persistent Threat) groups targeting Asian countries incorporated modified versions of Gh0st RAT into their own arsenal: GhostNet as the earliest documented instance and GamblingPuppet as one of the most recent ones.

Our deep dive into the subject started when we traced back the origins of a malware family named PseudoManuscrypt directly to Gh0st RAT. Kaspersky first spotted it in July 2021 as being distributed through a network of websites that offer fake cracked software to unsuspecting victims. We also observed it being directly delivered through the PrivateLoader Pay-per-Install (PPI) service.

Iron Tiger, also known as APT27 or Emissary Panda, is an advanced threat actor that has been doing espionage for more than a decade, targeting multiple sensitive industries worldwide.
In the past months, we noticed the threat actor enhancing its toolkit to target all three major platforms – Windows, MacOS and Linux. We found out they obtained access to the backend of a little-known chat application and modified the installers to deliver a remote access tool named rshell to users of the Mac platform. We also observed a new version of the SysUpdate malware family, where in addition to porting the malware to the Linux platform, the threat actor added features such as DNS tunneling for C&C communication protocol.

We Incident Responders from CERT Orange CyberDefense often face the same proven TTPs over and over by threat actors. Similar initial entry, privilege escalation, lateral movements, exfiltration, etc. techniques are seen in the numerous forensics cases we handled per year. Known ransomware gangs in particular follow scripted playbooks, as training documents from the Conti leaks and abundant public incident response reports already showed.
So when a victim came to us for help last November, our analysts expected to run into “Yet Another Ransomware” case. But it turned out way more interesting than initially thought. We’ll walk you into this case, that surprised in some ways even our most experienced analysts and reversers.

You probably know this scenario – you spent a while analyzing new samples, which was not easy, but you’re finally done. You also created a neat Yara rule to match the samples, and you’re ready to send it off and move on to your next task (or lunch). But oopsie – the Yara rule is warning of slowed scanning. Or your colleague comments they do not like a particular part and wants to be sure the rule is effective.

While working with Yara, I consulted with many analysts about this problem. They knew what they wanted to detect, but Yara was not always helping them write the rules more effectively. Based on my experience with algorithms used in Yara, we worked together to find a solution to improve scanning speed and limit potential hurdles for future usage.

This paper presents five studies with descriptions of the five problems, an explanation of why Yara does not like the first solution, and tips on what can be improved. Note that no sensitive information is disclosed in this paper. All studies were anonymized, so the general problem is the same, but there is no direct link to a specific malware family mentioned, nor can it be tracked.

Ever since launching Malpedia [1] at Botconf 2017, we continuously maintained and expanded our community-driven data set with the vision of exploring new ways to leverage it effectively for the research of and defense against malware. A primary research scope for us was working towards enabling efficient one-to-many code similarity analysis. After almost 4 years of research and development, we now finally want to share our results. With this presentation, we will publicly release MCRIT, the MinHash-based Code Relationship & Investigation Toolkit [2]. After giving a short overview of the underlying techniques and implementation, we will explain in a series of practical examples how to apply MCRIT for the three primary use cases it has been geared towards so far:

• Malware family and library code differentiation to accelerate triage and analysis
• Isolation of unique family code to provide means for hunting towards their characteristics
• Lead generation for discovering potentially unknown links between samples and families

During the last three years, we have tracked and closely analyzed a specific TA, intending to infect Windows workstations on corporate environments trying to alter legitimate banking transfers performed by the victims. The main technique leveraged was the Automated Transfer System (ATS), enabled via custom web injects for changing the beneficiary and transferring money to an illegitimate bank account (money mule) controlled by themself or affiliates, which is then responsible for handling and laundering the stolen funds. The critical component behind those fraud operations was one of the most advanced banking trojans, Ramnit.

Even if Ramnit has already been described in the literature, because of our forefront position, it was possible to understand TA behavior deeply and reconstruct the whole infection chain that goes through the initial malspam campaign, an accurate selection of victims during the botnet construction, the Automatic Transfer System (ATS) technique for cash-out through wire transfers, and the final money laundering.

We have been monitoring a wave of spear-phishing attacks targeting the government, academic, foundations, and research sectors around the world. Based on the lure documents we observed in the wild, this is a large-scale cyberespionage campaign that began around March. After months of tracking, the seemingly wide outbreak of targeted attacks includes but not limited to Myanmar, Australia, the Philippines, Japan and Taiwan. We analyzed the malware families used in this campaign and attributed the incidents to a notorious advanced persistent threat (APT) group called Earth Preta (also known as Mustang Panda and Bronze President).

Data exfiltration and detection has been the subject of lots of research in recent years. DNS exfiltration is the process of abusing the DNS protocol, originally designed for hostname resolving, to send data from a querying machine to a remote nameserver. While DNS exfiltration is commonly associated with free DNS tunneling applications, it’s also used by bots (e.g., Feederbot, Morto) to steal sensitive data from compromised enterprises and communicate with their command and control servers.

In this talk, we present a new real-time DNS exfiltration detection solution designed to be deployed on recursive DNS resolvers, based on estimating the amount of data that is transferred to registered domains via DNS requests FQDN. The algorithm is designed to be light-weight in both memory requirements and execution run time and allows real-time mitigation of DNS exfiltration campaigns.

In March 2022, a new buzz called Bumblebee appeared in the eCrime scene. This loader is built to execute tasks from its command-and-control (C2), and deliver payloads such as CobaltStrike. But its development doesn’t stop there. In the span of less than a year, Bumblebee has been through several incremental updates, to such an extent, that this malware may be one of the most actively maintained malware families out there.

This presentation aims to get a sense of the operator’s development process behind Bumbleebee – how it changes and adapts in response to current endpoint defense efforts– and how its techniques compare to other botnet families.

Finding malware is not the difficult part, as it is prevalent due to the widespread malware campaigns which target consumers and companies alike. Samples are available in multitudes on sample sharing websites, but it is impossible to manually sift through all available samples. This is why the ideal process is streamlined using a pipeline. The malware is collected, after which it is scanned to detect known patterns and behaviour. Lastly, interesting samples can be reverse engineered manually.

The creation of such a pipeline is relatively straight-forward. The majority of the issues are encountered when setting everything up in a scalable manner. An example would be the scanning of files. If this cannot be done concurrently (enough), this will strain the whole system. The throughput of the pipeline then poses as a bottleneck. Additionally, or alternatively, the scaling of scanning requires improved and more hardware, which is often costly.

This talk focuses on setting up a pipeline on a budget, where the analyst will have access to malware samples of the last 60 days, all of which are scanned with Yara rules for known patterns. Additionally, all samples are executed in a sandbox to obtain heuristic data. Lastly, tools to analyse samples that the analyst deems interesting are referenced. This pipeline can be executed on a Raspberry Pi 3B, paired with a USB (or external hard) drive. Needless to say, more performance-oriented hardware ensures a smoother experience, but this is the lower limit of the hardware with which the pipeline was tested.