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
China’s APT40 continue to conduct espionage operations, targeting countries and organisations involved in the South China Sea with the ScanBox browser exploit framework as part of a broader multi-year campaign;
The Bumblebee loader now unpacks and loads itself into memory through a convoluted and multi-staged PowerShell script, plus we look at IcedID’s core TTPs and how to detect them;
Another no-fix, “by design” flaw - this time in Azure’s SMTP Matching - enabling takeover of privileged Azure AD accounts.
APT40 use ScanBox browser exploitation framework in South China Sea campaign
Reference: Proofpoint
Proofpoint and PwC have released a joint report detailing the latest campaign they believe to have been conducted by the Chinese espionage-motivated threat group TA423 (more broadly tracked as APT40), which ran from late-April to the start of June, 2022. The actor has consistently used Phishing as their initial attack vector, in this case pairing it with a fake Australian news outlet website that hosted the malicious Javascript exploit framework known as ScanBox.
Activity Summary
This latest campaign primarily targeted:
Local and federal Australian Governmental agencies;
Australian news media companies; and,
Global heavy industry manufacturers which conduct maintenance of fleets of wind turbines in the South China Sea.
The report asserts this is part of a longer-running campaign dating back to May 2021, involving the impersonation of trusted Australian news outlets and the use of RTF template injection maldocs that delievered XOR-encoded Meterpreter payloads to a broader range of sectors and geographies:
APT40 represents a persistent and ongoing threat, targeting countries and organisations operating in and around the South China Sea in order to conduct espionage activities.
While governments are an obvious target - as evidenced in the groups 2020 Copy-Paste compromises - commercial entities that conduct or support projects in the South China Sea, such as manufacturing, professional or financial services companies, should also take note, as this report shows they are also within the scope of targeting.
ScanBox Technical Summary
ScanBox was first reported on in 2014, and has been used by six China-based threat actors, and across 13 distinct campaigns to perform basic victim profiling and deliver additional payloads, with targeting very closely aligned with espionage-related activities.
Capabilities
ScanBox is typically hosted on compromised legitimate websites, with victims delivered URLs containing unique strings, likely intended to enable the actor to identify those who clicked through.
The watering hole website hosts the initial ScanBox script, which performs basic recon of the victim endpoint such as the current time; browser details, and the host Operating System.
The initial script will then load additional payloads to perform further enumeration and tasks:
Keylogger plugin: Creates an iframe and logs keystrokes entered within it;
Browser plugin scanner: Enumerates legitimate installed plugins;
Browser fingerprinting plugin: Checks for Java and ActiveX installation, any installed Java web apps, the browser family, and use of the Microsoft Java Virtual Machine in the browser;
Peer connection plugin: Enables Interactive Connectivity Establishment (ICE) P2P connections over STUN servers, allowing attackers to communicate with victim machines sitting behind NAT;
Security check plugin: Checks for Kaspersky Internet Security.
This modularised framework enabled multiple China-based threat groups to enumerate victim systems and potential attack paths. Its ability to bypass NAT to communicate with infected browsers via STUN also allows them to interactively exploit those identified attack paths, potentially escaping the browser sandbox and gaining a foothold on victim networks.
While a much more involved attack vector, it still provides the attackers with internal reconnaissance without having to bypass traditional email filters and endpoint protections that many organisations rely on.
ScanBox highlights the importance of maintaining browser patching, and what can be achieved through pairing a simple watering hole attack with a capable browser exploitation framework.
BumbleBee pivots to PowerShell
References: Deep Instinct | @Max_Mal_ | Mattnotmax
Recent Bumblebee campaigns have been identified to be using heavily obfuscated powershell scripts to unpack and load the Bumblebee dll into memory.
It begins with typical malspam that delivers a .vhd Virtual Hard Disk file, which in turn contains the powershell script along with a .lnk file to detonate it.
This obfuscated script then decompresses an array of gzip-compressed streams to compile and execute the 2nd-stage code block with the Invoke-Expression cmdlet.
This in turn compiles and validates the Bumblebee dll, before loading it into memory.
Detection & Analysis Tips
This is a much more sophisticated unpacking and execution routine compared to commodity malware like IcedID and Qbot, which download to disk and execute multiple stages to launch their final payloads.
Don’t despair though - while the unpacking routine is complicated, strings from the co-opted al-Khaser anti-vm project are visible in the unpacked dll, and may therefore be picked up by memory-scanning EDR products
@Kostastsale also identified that the unpacking script has simply repurposed PowerSploit’s Invoke-ReflectivePEInjection to load the DLL into memory, with little more than function renaming and string splitting to obfuscate it.
Best of all, Mattnotmax has shared a new Cyberchef recipe to pick apart Bumblebee’s Powershell loader and extract the Bumblebee payload. Amazing work, and certain to save a lot of analysts a lot of time manually tinkering with the script!
IcedID activity summary + Hunt tips
TTP Variations
References: @Unit42_Intel | @pr0xylife | @pr0xylife
IcedID distributors have used multiple delivery & execution chains throughout the week, with macro-enabled documents still featuring, as well as a consistent use of rundll32.exe for payload execution.
29/08 - rtf, multiple stagers to Cobalt Strike
TA551/Shathak ran a campaign using hijacked email threads to deliver the initial payload, downloading two additional stages before ultimately ending in a Cobalt Strike stager:
Stage 1: Email > password-protected .zip > macro-enabled maldoc (.rtf)
Stage 2: Download (http) IcedID installer dll + renamed rundll32.exe
Stage 3: Download (http) gzip > drops license.dat + persistent IcedID DLL
Stage 4: IcedID C2 (https) > Cobalt Strike stager
31/08 - url > zip > iso > lnk execution
A more traditional execution chain:
Email containing malicious URL (storage[.]googleapis[.]com)
Downloaded .zip > .iso > .lnk + .dll + .bat
Execution of .lnk > cmd.exe executes .bat > rundll32.exe executes .dll#1 (IcedID)
01/09 - zip > docm > curl download & execution
Reverting to a much simpler maldoc stager the next day:
Email > .zip > .docm
Enable macros > curl.exe downloads 2nd stage;
Executes with rundll32.exe at ordinal #1.
Hunting/Detection Tips
Reference: @Kostastsale
See the thread for full details, but Kostas has done a great job highlighting several consistent indicators and behaviours you can use to surface IcedID delivery and activity on your networks:
Use of common native binaries for initial recon, e.g. net.exe, nltest.exe, ipconfig, etc.;
Hourly Scheduled Tasks, running dll files from randomly named directories in world-writeable directories like %AppData%;
“license.dat” dropped to a folder somewhere in %AppData%;
Use of the JARM hash “2ad2ad16d2ad2ad22c2ad2ad2ad2adc110bab2c0a19e5d4e587c17ce497b15”;
The presence of _gid, _io, _u, _gat, _ga, and _gads Cookies in HTTP requests - the values of which relate to the victim endpoint.