Late last week, Mandiant researchers published findings from an incident response engagement detailing an attacker workflow that took place in a VMWare ESXI environment. In this workflow, the attackers placed malware or persistence mechanisms on each layer of this environment:
Read more “Some Notes on VIRTUALGATE”
1. vSphere layer, which can manage multiple ESXI environments
2. ESXI hypervisor layer, which can manage virtualized “guest” machines
3. Virtualized guest machines
A key function of several of the attacker tools placed at the ESXI and guest levels in this environment was reportedly the ability to exchange attacker commands and data between the two layers.
This blog post examines a likely sample of VIRTUALGATE, a reported malware family that sits at the guest machine layer of this workflow. The post will provide additional technical details regarding its underlying mechanisms and provides context for how an attacker might operate in this environment.
In an earlier post, this blog examined malware from a DPRK-affiliated campaign targeting security researchers. Since the initial public post about this activity from Google, multiple vendors have corroborated and supplemented the technical details in this attack.
Read more “DPRK Targeting Researchers II: .Sys Payload and Registry Hunting”
Whereas the previous post examined a DLL file delivered via social engineering and VisualStudio, this post examines the inner-workings of a malicious .sys file likely delivered through a watering hole. In addition to reverse engineering, this post offers possible threat hunting avenues for identifying data associated with this file hidden in the registry of a compromised system.
For those purely interested in the hunting portion of this post (the malware reads, and likely executes, data from the registry), click here to skip ahead. As a disclaimer, the hunt workflow proposed is merely hypothetical, and should not be considered any sort of official security guidance.
(2/1 Update, Stage 2 can be found here)
Earlier today, Adam Weidemann from Google’s Threat Analysis Group (TAG) published research regarding a threat actor targeting security analysts following a social engineering campaign. Google attributes this activity to DPRK threat actors. This blog has no evidence to corroborate or refute this claim, but considers Google to be a reputable source of information.
Read more “DPRK Malware Targeting Security Researchers”
According to the published research, the threat actors would engage in a social engineering effort in which they would attempt to collaborate with security analysts on a Visual Studio project, ultimately leading to them delivering a malicious DLL that the researcher would unknowingly launch.
This post examines that DLL and parts of its second-stage workflow.
Recently, I came across a VISA bulletin regarding point-of-sale malware being used against merchant targets. In Incident #1 in this VISA report, VISA described a deployment technique for TinyPOS that seemed oddly similar to the ProLocker ransomware installation workflow described by Group-IB, although I initially dismissed this as a coincidence.
After spending time mapping out code-level relationships and VirusTotal submitter relationships (initially with the intent of identifying an entry vector), there is evidence to suggest that this is not pure chance. In short, one of the following is likely true:
1. ProLocker and TinyPOS are written by the same author, who also provides a deployment mechanism; or,
2. ProLocker and TinyPOS are written, deployed, and used by the same threat actor
3. The ProLocker adversary obtained or modified the TinyPOS source code and also operates in the carding space
Of these, the second seems the most likely. In addition to distinct code-level relationships shared across several tools from both threat actors (and no apparent other threat actors) and the very similar delivery mechanisms, both ProLocker attacks and TinyPOS attacks appear to be low-volume enough that it is plausible a single small to medium-sized group is operating them, rather than two distinct entities. This would parallel assessments that other threat groups who traditionally operated in the carding and banking spaces have also switched to ransomware attacks, including FIN6 and TA505.
Read more “TinyPOS and ProLocker: An Odd Relationship”
This remainder of this post primarily walks through the analytic workflow that led to these assessments (as opposed to a traditional intelligence-style condensed publication of the key facts) so that others may properly evaluate the methodology and findings.
Last October (2019), ESET published extensive research regarding additional tooling from the “Dukes” adversary, which analysts have traditionally aligned with [APT29/Cozy Bear] operations. While conducting some unrelated research, I came across a LiteDuke sample and decided to take a deeper dive into the mechanics of its loader and its malware.
Read more “Looking Back at LiteDuke”
The original ESET publication covers the key details at a high level; in addition, this malware is old and has likely been discontinued for several years. This blog post is intended to document some additional lower-level details for operational comparison purposes and general learning.
From time to time, new tools emerge that make it significantly easier to examine older malware. In 2017, Symantec’s threat intelligence team published research regarding the Dragonfly group, an adversary with an apparent interest in performing reconnaissance against energy sector companies. One of the reported malware families, “Backdoor.Goodor,” is written in Golang and the blog post states that it “provides the attackers with remote access to the victim’s machine.”
Read more “A New Look at Old Dragonfly Malware (Goodor)”
In recent years, several free options have become available to help reverse engineer these types of Golang binaries, replacing premium (but extremely well documented) methods and making this type of analysis particularly more accessible.
This post walks through the reverse engineering of a Goodor file, examining its capabilities and discussing key principles of these types of files.
In a previous post, this blog examined malware used in a financially-motivated incident at a fuel dispensing company, as disclosed in a security bulletin by VISA. The bulletin detailed a second incident that is likely attributable to an additional threat actor. Specifically, VISA identified C2 infrastructure, a filename, and additional TTPs that allegedly align with FIN8 activity, as described in public Gigamon and Root9b reporting. These TTPs suggest that the threat actors used a memory scraper referred to as PoSlurp.B in public reporting to scrape customer credit card data from a targeted device.
Read more “Fuel Pumps II – PoSlurp.B”
This post examines a PoSlurp.B file identified (through its shellcode loader) by Twitter user @just_windex to provide additional details regarding the malware’s functionality that were not previously disclosed in open source. This analysis focuses on the final payload of the shellcode loader, although additional information and advice for bringing this file into a debuggable state is available at the end of the post.
Unlike the previously analyzed file (FrameworkPoS/GratefulPOS), which indiscriminately scraped all processes on a device, PoSlurp.B is designed to scrape the memory of an attacker-specified process.
In December 2019, VISA Security released a bulletin detailing multiple incidents in which threat actors targeted point of sale systems used at fuel dispensing companies with malware designed to parse out credit card numbers from these systems. This blog post examines a file, 19d38325f715f623bd4b6e819a150cde, associated with the first of three listed incidents in that bulletin.
Read more “POS Malware Used at Fuel Pumps”
There are several notable characteristics regarding this malware, including a unique way for the threat actors to terminate the tool.
Recently, a VirusTotal submitter uploaded a file that was digitally signed with the same certificate as two previously reported Lazarus tools. Like one of those tools, this newly uploaded malware appears to act as an injector, although it behaves significantly differently.
Read more “Another Lazarus Injector”
This blog post offers a brief analysis of the features and purpose of this injection tool, as well as a comparison with a previously identified injection tool that behaves significantly differently and likely serves a different operational purpose.
Update 20 October, 2019: A small section towards the bottom of this post has been updated to reflect this malware’s strong resemblance to a file described in a US-CERT Report in late 2018. The file in that report served as an injector for the FASTCash AIX malware. Given this file’s similarity, it is highly likely that this file is intended to perform a similar function, but on a Windows environment.
In late June, multiple researchers and security entities (including researchers from ClearSky, FireEye, and U.S. Cybercom) highlighted APT33 activity in public outlets. Several of these files have already been identified and analyzed as part of ongoing discussions on Twitter regarding this activity.
Read more “APT33 PowerShell Malware”
This blog post examines a file identified through public resources with infrastructure links to these attacks that has not been widely examined.
As part of this activity, researchers identified the C2 domain “backupaccount[.]net” as a C2 used within a malicious HTA file hosted on attacker infrastructure. A PassiveTotal pivot at the time of this writing highlights 11 hashes associated with this domain. PassiveTotal accounts are free, but also do not offer the context behind these hash associations.