Author: norfolk

Some Thoughts on NOAA and NWS

norfolk

When I first started this blog post, I had written what I felt was a more compelling introduction that implied that it was unethical to convert the largely public sector weather service into a completely private sector one. This was in response to the severe staff and resource reductions at the National Oceanic and Atmospheric Administration (NOAA) and the National Weather Service (NWS) that NOAA oversees. Then, of course, this weekend happened.

At the time of this writing, there are over three dozen reported fatalities following a large series of storms and tornadoes that affected multiple southern and midwestern states including Missouri, Arkansas, Texas, Oklahoma, Kansas, Alabama and Mississippi. Pictures of the destruction are available on Twitter, as are discussions from the time of forecasting through the time of the storms’ departure towards the East Coast.

Damage to homes in Tylertown, MS (left, Accuweather) and Cave City, AK (right, Brian Emfinger)

The aforementioned cuts to NOAA and NWS serve as a backdrop to all of this. These cuts create a very real problem for those who live in high-risk regions. The alerts that we use to notify people of severe whether events – and the underlying data, research, and forecasts that generates them – come from these organizations. The end products are alerts that are available online and are also often sent to your phone, and the private sector directly integrates these alerts into their own offerings.

Source: @MatthewCappucci

The thinking behind these cuts is that private sector companies can and should replace the majority of the functions that the NWS and its parent NOAA perform – a way of thinking that is, quite frankly, naïve and that I am writing this post to challenge.

Here are my two main points:

  • You should not assume that the private sector will provide you with a “better” product simply because of competition and the incentive to make money.
  • NOAA and NWS provide a life-saving service, and this life-saving service is something everyone should have access to with no limitations.
Read more “Some Thoughts on NOAA and NWS”

North Korea’s Post-Infection Python Payloads

norfolk

Throughout the past few months, several publications have written about a North Korean threat actor group’s use of NPM packages to deploy malware to developers and other unsuspecting victims. This blog post provides additional details regarding the second and third-stage malware in these attacks, which these publications have only covered in limited detail.

A few good sources that showcase the progression of the security community’s understanding of this attack workflow include:

– Phlyum, which has been tracking this threat since last year
– Palo Alto’s Unit 42, which provided additional information in November 2023
– A Medium post detailing a similar attack to the ones described above and in this blog post

Interestingly, it appears that the threat actors may have either moved to – or begun using in parallel – a series of Python scripts for this attack instead of solely delivering malicious DLLs (as observed by Phylum researchers in their original reports). This may be due to the added flexibility and speed of Python scripting, or it may simply be a result of the threat actors attempting to make their delivered tools and files appear more legitimate to users and investigators.

Read more “North Korea’s Post-Infection Python Payloads”

Some Notes on VIRTUALGATE

norfolk

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:

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.

Read more “Some Notes on VIRTUALGATE”

DPRK Targeting Researchers II: .Sys Payload and Registry Hunting

norfolk

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.

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)

Read more “DPRK Targeting Researchers II: .Sys Payload and Registry Hunting”

DPRK Malware Targeting Security Researchers

norfolk

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.

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.

Read more “DPRK Malware Targeting Security Researchers”

TinyPOS and ProLocker: An Odd Relationship

norfolk

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.

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.

Read more “TinyPOS and ProLocker: An Odd Relationship”

Looking Back at LiteDuke

norfolk

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.

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.

Read more “Looking Back at LiteDuke”

A New Look at Old Dragonfly Malware (Goodor)

norfolk

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.”

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.

Read more “A New Look at Old Dragonfly Malware (Goodor)”

Fuel Pumps II – PoSlurp.B

norfolk

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.

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.

Read more “Fuel Pumps II – PoSlurp.B”

POS Malware Used at Fuel Pumps

norfolk

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.

There are several notable characteristics regarding this malware, including a unique way for the threat actors to terminate the tool.

Read more “POS Malware Used at Fuel Pumps”