Blog Posts RSS

TrickBot, a modular trojan, has been active in the malware scene since 2016. It is famously known for having a variety of modules in its attack toolkit, some of which are quite recent and some being actively developed. This brings us to its web injection module, injectDLL, that has been around since the malware was first discovered. The core purpose of the module still remains the same, which is injecting scripts into websites to exfiltrate information. However, there have been some recent additions to the module, especially since the introduction of its newer webinject config winj1.

AnchorDNS is a backdoor used by the TrickBot actors to target selected high value victims. It has been seen delivered by both TrickBot and Bazar1 malware campaigns2. AnchorDNS is particularly difficult to track given that it is deployed only post-infection and that too only after a period of reconnaissance, once the malware operators have established that the target is of special interest. Following analysis of AnchorDNS samples published in recent reporting23, we have observed that the C2 communications protocol of AnchorDNS has changed. We also see the use of another Anchor component called AnchorAdjuster. The newer variants contain a modification to the structure of the messages sent to the C2, and have added additional encryption routines when creating the DNS queries. Data received from the C2 is now encoded, thereby making the traffic less obvious.

TrickBot is an established and widespread multi-purpose trojan. Active since 2016 and modular in nature, it can accomplish a variety of goals ranging from credential theft to lateral movement. Many of the malware’s capabilities come as self-contained modules, which the malware is instructed to download from the C2. Initially, TrickBot’s main focus was bank fraud, but this later shifted toward corporate targetted ransomware attacks, eventually resulting in the discontinuation of their fraud operation.

Active since 2016, TrickBot is one of the most prevalent modular banking trojans. The botnet’s modules carry out objectives such as credential harvesting, propagating via the network, web injection and others. Being an actively developed botnet, we often come across updated modules and in some cases new tools that are added as part of its arsenal. Recently we have discovered a relatively new module that goes by the name masrv. The module is a network scanner that incorporates the Masscan open-source tool. Additionally, the module contains an unreferenced Anchor C2 communication function and a list of hardcoded IPs which have previously been associated with Anchor and Bazar 12.

It is well known by now that encryption without authentication is insufficient, and many chosen-ciphertext attacks on improperly authenticated ciphertexts are now commonplace. Authenticated encryption—constructions that both encrypt and authenticate plaintexts in one sitting—are widespread at this point, with the two most common instances being AES-GCM and ChaChaPoly1305. One property that the usual definitions of authenticated encryption do not capture is key commitment: a ciphertext is tied to a particular key, and it should not be possible to create ciphertexts that successfully decrypt under more than one key. Some systems will fail, or have unexpected properties, if their authenticated encryption is not committing; this was the case for Facebook’s message franking, the OPAQUE authenticated key exchange, some AWS and Google services, and more.

Last week the Network Security Research Lab at 360 released a blog post on an obfuscated backdoor written in Go named Blackrota. They claim that the Blackrota backdoor is available for both x86/x86-64 architectures which is no surprise given how capable Golang’s cross compilation is. For the last 4 years we have been using Golang for our internal services, and I can definitely see the allure that Golang has for malware authors:

A fast pseudorandom generator for KASLR A recent patchset proposed for the Linux KASLR randomizes not only the kernel base address, but also reorders every function at boot time. As such, it no longer suffices to leak an arbitrary kernel function pointer, or so the logic goes. Along with this patchset came a custom random number generator intended to be as fast as possible, so as to keep the boot time overhead at a minimum:

Remote Desktop Gateway (RDG), previously known as Terminal Services Gateway, is a Windows Server component that provides routing for Remote Desktop (RDP). Rather then users connecting directly to an RDP Server, users instead connect and authenticate to the gateway. Upon successful authentication, the gateway will forward RDP traffic to an address specified by the user, essentially acting as a proxy. The idea is that only the gateway needs to be exposed to the Internet, leaving all RDP Servers safely behind the firewall. Due to the fact that RDP is a much larger attack surface, a setup properly using RDG can significantly reduce an organization’s attack surface.

It has been almost six months since an eye opening vulnerability in Microsoft Windows RDP CVE 2019-0708, dubbed BlueKeep, was patched. Today, Security Researcher Kevin Beaumont posted a Twitter thread reporting BSODs (Blue Screen of Death) across his network of BlueKeep Honeypots. huh, the EternalPot RDP honeypots have all started BSOD’ing recently. They only expose port 3389. pic.twitter.com/VdiKoqAwkr — Kevin Beaumont (@GossiTheDog) November 2, 2019 Kevin kindly shared the crash dump with us and following this lead, we discovered the sample was being used in a mass exploitation attempt. Due to only smaller size kernel dumps being enabled, it is difficult to arrive at a definite root cause.

Emotet’s automated targeting phishing campaigns have arrived and they are aggressive. As originally discovered and predicted in our previous post about Emotet’s mass email harvesting, computers infected with Emotet and the email harvesting module could be used to create believable emails which even savvy email users may be tricked into clicking. Since then, Kryptos’ Threat Intelligence Team has observed Emotet’s behavior evolve, with the aid of their stolen email troves. During the past few days in particular, we have spotted the Emotet actors implement a new process allowing them to automate and scale the use of targeted emails.

Our Threat Intelligence team has been tracking the Emotet botnet throughout 2018. In our previous post we reported a large scale Emotet campaign focused on e-mail content exfiltration. Today, we review the evidence gathered from our Telltale Threat Intelligence Service, which suggests the involvement of Emotet as the delivery mechanism for the latest wave of Ryuk ransomware attacks being dubbed as North Korean state-sponsored cyber-attacks. The evidence from the dataset completes the missing narrative needed to show a likely and complete attack chain of compromise via organized crimeware activity. This attack chain consists of initial Emotet infections, which are then used to deliver Trickbot. Completing the attack chain, in a select subset of Trickbot infections, actors then deliver Ryuk. Our analysis shows Emotet infections were lingering for weeks in advance before any Ryuk ransom attacks were deployed. This lends a new piece of intelligence to an ongoing attribution debate over whether or not North Korea is directly targeting organizations with Ryuk.

The Emotet malware family just raised the stakes by adding email exfiltration to its arsenal, thereby escalating its capabilities to cyber espionage. While it has recently made headlines for delivering ransomware payloads to United States infrastructure such as Water Utilities, Emotet has laid mostly dormant for the past month. In the past days, however, the mummy has returned just in time for Halloween as we observed a new module capable of exfiltrating email content back to the botnet’s operators.

The Emotet botnet reputation precedes it; historically aggressive and malicious, today it has evolved and incorporated a number of advancements to create a more resilient botnet delivery system, nearly immune from takedown. Recently, US CERT reported that Emotet incidents (and its subsequent payload droppers) are affecting state, local, tribal, and territorial (SLTT) governments at up to 1 million dollars per incident. We have captured a global view of many of the active infections within the latest Emotet botnet. At the time of this writing, we believe this to be the only publicly available coverage of actively infected Emotet peers.

With much attention lately over North Korea and its evolving cybersecurity capabilities, we thought to cover a somewhat related topic. A couple of years back, the North Korean Red Star OS was described at the Chaos Computer Club conference. Among other things, they described the watermarking mechanism used by the OS to keep track of media files. Along with the OS, three kernel modules were identified that appeared to contain homemade encryption algorithms specific to Red Star OS. We will name them after their kernel module names—Jipsam1, Jipsam2, and Pilsung. The former two are present in Red Star OS 2.0, whereas Pilsung is present only in Red Star OS 3.0. We are going to take a look at these, and comment on possible rationales for their design. We will only analyze the algorithms in isolation, as there is not a lot of information on how (or if) they are used. To our knowledge, this is the first time these algorithms are described.

In light of the recent news circulating about sporadic WannaCry outbreaks, namely defense contractor Boeing and earlier last month Connecticut state agencies, as well as Honda, we think it important to provide further guidance on assessing ongoing and hidden dangers related to WannaCry outbreaks. To immediately begin reducing risk and augmenting your existing security defenses, we are providing at no cost Telltale, a free version of Vantage Breach Intelligence Feed. Telltale is a simplified version of our breach monitoring and can help your organization assess past or ongoing malware infections, including but not limited to WannaCry. We will be regularly updating Telltale with new sinkhole data from botnets and useful breach monitoring features.

Last November marked the six-month anniversary of WannaCry, arguably the most impactful global cyberattack in history. The persisting WannaCry attack is a re-purposed ransomware strain amplified by (allegedly) leaked exploit code from the NSA. For previous details about the inner workings of WannaCry see our previous post. Today, the United States declared North Korea responsible for the WannaCry attacks. This post will present analytical findings and perspective into just how wide these attacks have scaled, and how very little footprint is required to sustain a global security crisis.

There are a few interesting things to say about the current ransomware Petya. One thing is clear, there is no “kill-switch”. After some preliminary tracking of the domains which presumably deliver the payload for its RTF (Windows document exploit) delivery system and cross referencing it to passive intelligence about the domain name, we noticed the frequency of 2 million hits within an hour. The domains we tracked are not currently serving the payload and are down. Therefore further attempts to spread through original vectors will remain ineffective. This does not eliminate, however, other attack vectors should anyone release new droppers.

WannaCrypt, aka WannaCry, has been the Infosec story of the past couple of weeks. What was originally a humble ransomware became a newly retrofitted NSA-powered worm which spread recklessly, wreaking global havoc. Fortunately, the proliferation of WannaCry came to a standstill when one of our security researchers, MalwareTech, working to collect intelligence for the Vantage Breach Intelligence Feed, registered a domain associated to the malware, ultimately triggering its “kill switch”.