Newsletter

SOC Goulash: Weekend Wrap-Up (Part 1)

03/10/2022 - 09/10/2022

Opalsec

Opalsec

— 7 min read
SOC Goulash: Weekend Wrap-Up (Part 1)
This is Part 1 of the Weekend Wrap-Up, detailing significant Threat Actor Activity and noteworthy TTP changes to be aware of.

Part 2 will cover significant vulnerabilities from the past week, in addition to the latest tools & techniques for offense and defence alike, and some additional reporting that you might find relevant and useful.

Headline Items

  1. Insights into the evolution of BumbleBee Loader’s capabilities, used by the FIN12 ransomware threat group for initial access;
  2. IcedID & Qakbot toy with renamed system binaries and maldocs, but largely continue to rely on zip > iso > lnk detonation to sneak past email filtering;
  3. Zimbra and PHP’s Composer fall victim to serious supply chain vulnerabilities.

BumbleBee continues to evolve its C2 & capabilities

Reference: ESET | Checkpoint

Significant research has emerged from ESET and Checkpoint this week which highlights the latest upgrades being made to BumbleBee’s tasking and communications framework.

I’ll expand on it a little more below, but if you like pretty pictures like I do, here’s a visual summary of the key points you’ll need to know:

Figure 1: Key findings from recent analysis by ESET & Checkpoint

Potential modularisation - PLG Command

First up, ESET have identified a new command option available to BumbleBee operators, which can be invoked with the “plg” option. All commands are represented by a three-letter truncation of their purpose, e.g. “dij” which corresponds to “Download & Inject”, or “dex” which downloads and executes an arbitrary payload.

This has led ESET to speculate that “plg” might enable execution of a particular plugin - a potential indication that the developers are looking to make BumbleBee a modular malware with multiple plugins that can be loaded and run as required.

For now, the command simply performs the same function as the “dij” command, and appears to have been left in there as a testing placeholder.

Use of Session IDs, shift to WebSocket for C2

The other developments ESET notes are:

  1. The use of a hardcoded “client_ping” value of “FORTHEEMPEROR” being added to the initial C2 setup request, which prompts a session_id value being provided in the response that’s then used in further requests;
  2. The switch to WebSocket to replace HTTPS as their C2 medium of choice. WebSocket retains the ability to wrap comms in TLS while also being full-duplex, as opposed to HTTPS which is half-duplex. This could allow the devs to configure BumbleBee to be instructed to run tasks as needed, instead of the malware having to repeatedly check in with the C2 at fixed intervals to request new tasking.

Decryption of the malware config

BumbleBee payloads operate using a config that is encrypted with an RC4 key, which can be found in an 80-byte section of the .data section, but has so far always been much shorter than the allocated 80 bytes.

This key is used to decrypt the remaining sections, including the list of C2 infrastructure which is stored in an encrypted 1024-byte block - many of which are actually decoys.

Two more 80-byte sections trail the RC4 key, though the first appears to be junk, unused code, and the second contains a “group_name” value. I know, it sounds exciting! Unfortunately, it’s been proven to be a dud for grouping samples - see the section on clustering below for an explanation <insert_sad_pepe_meme>.

InfoStealers for individuals, 2nd-stage malware for the enterprise

Checkpoint researchers have noticed that BumbleBee payloads dropped on systems that aren’t domain-joined will typically receive the “dex” command, instructing it to download and execute a secondary payload that is often either a banking trojan or InfoStealer, such as Vidar Stealer.

Conversely, victims that are a member of a domain will receive the “dij” command that downloads and injects a secondary payload into the memory of a target process. This payload is typically either a Cobalt Strike, Sliver, or Meterpreter implant to enable further exploration of the network and post-exploitation activities.

BumbleBee is distributed by EXOTICLILY, the Initial Access Broker (IAB) for the now-fractured, but still very-much operational Conti (FIN12) ransomware syndicate. This selective delivery of trojans and post-exploit implants is consistent with the group’s objective of enabling ransomware operations, while still monetising the accesses that don’t.

It’s also worth noting that in both cases the secondary payload will be packaged using the same custom Bumblebee packer - a YARA rule for this is included in at the end of Checkpoint’s report.

Correlating Campaigns based on RC4 Key

Checkpoint have found multiple unique “group_name” values used by samples that share the same RC4 encryption key and deliver the same 2nd-stage payload. As dropper malware such as this tend to be built and distributed based on the same config - and therefore often share the same encryption key and perform the same on-target actions - Checkpoint have dismissed group_name values as a reliable means of clustering activity.

Rather, the encryption keys themselves appear to be better indicators of related activity, and - at least for now - can be used to cluster infections.

Found this useful? Subscribe to receive new posts straight to your inbox and support my work!

Patterns in IcedID Infrastructure

References: Team Cymru | @Max_Mal

Team Cymru have published their findings from a comprehensive analysis of recently observed Tier 1 and Tier 2 IcedID infrastructure, which highlights a number of key patterns. Of these, the most noteworthy are:

  1. Up to September 21, Tier 1 domains were registered by 1337 Services LLC Hosting and parked for ~31 days before being linked to an IP and used operationally - presumably to mitigate firewalls that sinkhole traffic newly registered domains;
  2. Domains and IPs are mostly used only for the one campaign before being retired. They’re deployed in batches of four or five C2 IPs per-campaign, with an average operational lifespan of six days;

During September Team Cymru also reported observing four main distribution methods:

  1. Password Protected ZIP -> ISO -> LNK -> JS -> [CMD or BAT] -> DLL;
  2. Password Protected ZIP -> ISO -> CHM -> DLL;
  3. Macro-enabled Word/Excel attachments;
  4. Secondary distribution via the Pay-per-Install PrivateLoader service (the distributor for which was recently reported to have shut down). This was the most effective method of the four observed;

IcedID TTP Summary

There main delivery mechanisms were observed this week:

  1. Campaign #1 (WSF proxy-invocation): @Max_Mal_
  2. Campaign #2 (HTML Smuggling): malware-traffic-analysis
  3. Campaign #3 (xlsm maldoc): @JAMESWT_MHT
Figure 2: IcedID TTPs
Several inflated maldoc samples were observed being delivered, with a 120MB sample observed by @James_inthe_box and several others found on various online sandboxes.

Unit 42 also highlighted the use of Powershell to invoke download of 2nd-stage Cobalt Strike payload from TCP/8080 - something worth keeping an eye out for in network and PowerShell logs:

Qakbot TTP Summary

Both Qakbot distributors started playing with using copied and renamed system binaries to execute dll payloads, with some slight variance to the lnk > * > cmd > dll execution chain, and a continued reliance on malicious URLs and HTML files, as well as iso containers with lnk files for initial execution.

BB Botnet

Like IcedID, TA577 also played around with copying and renaming system binaries before using them to execute the payload, as well as switching .js files as an intermediary for .vbs files in their iso > lnk execution chain, and reverting to delivering malicious Excel docs in some instances;

Figure 3: Qakbot BB Botnet TTPs

Obama Botnet

Two distinct distribution methods were observed from the Obama botnet (TA570) this week, though both relied on html smuggling as the first stage. The first method was simply a repeat of the same execution chain as last week, while the second followed TA577 and IcedID by executing renamed system binaries to run the payload:

  • 05/10 (Obama209): html > .zip > .iso > cmd.exe (.lnk) > wscript.exe (.js) > cmd.exe (.cmd) > regsvr32.exe (.dll)

  • 06/10 (Obama210): html > .zip > .iso > cmd.exe (.lnk) > cmd.exe (.cmd) > copies regsvr32.exe to %PUBLIC%/re.exe > re.exe (.dll)

Figure 4: Qakbot Obama Botnet TTPs

Thanks for reading! If you liked this, please subscribe to receive new posts and support my work!

Read more