CL-STA-1087: Deep Dive into AppleChris & MemFun Targeting SE Asia
Saw the Unit 42 report on CL-STA-1087 this morning. It looks like a Chinese state-sponsored cluster is actively going after Southeast Asian military entities using a cocktail we haven't seen enough of: AppleChris and MemFun.
What stands out to me isn't just the malware, but the timeline. We're talking about operational patience dating back to 2020. This isn't a smash-and-grab; it's a long-term foothold establishment. The report highlights "strategic operational patience," which usually implies extensive recon and custom phishing tailored to specific commands.
From a technical perspective, MemFun is the real headache here. Based on the name and prior APT trends, we're likely looking at memory-resident techniques designed to bypass traditional EDR file-scanning. If they are manipulating memory headers or utilizing process hollowing, disk forensics might come up clean.
I've started rolling out a KQL query to our Sentinel tenant to hunt for similar injection patterns that might indicate early stages of this loader:
DeviceProcessEvents
| where Timestamp > ago(7d)
| where InitiatingProcessFileName in ("excel.exe", "winword.exe", "powerpnt.exe")
| where FileName in ("powershell.exe", "cmd.exe", "rundll32.exe")
| where ProcessCommandLine contains "-enc" or ProcessCommandLine contains "FromBase64String"
| project Timestamp, DeviceName, AccountName, InitiatingProcessFileName, ProcessCommandLine
| order by Timestamp desc
Has anyone else in the sector picked up on the MemFun IOCs? I'm curious if the memory evasion techniques they are using bypass standard AMSI bypass signatures.
Good catch on the KQL. We've seen similar memory-only payloads in the financial sector recently. If MemFun is indeed resident only in memory, you might want to augment that hunt with memory scanning on the endpoints. We've had success using Elastic's query-string to look for unsigned DLLs loaded into Office processes that aren't backed by a file on disk.
The 'strategic patience' aspect is terrifying. In our red team exercises, we often find that if we just wait 6-12 months after initial access, the SOC usually rotates out the analyst watching the specific alerts, and our dormant C2 channels get forgotten. Defenders need to stop treating incidents as one-offs and start looking for the dormant threads.
Since we've covered memory residency, don't overlook AppleChris's delivery vectors. This group heavily relies on DLL side-loading via signed binaries. Catching the dropper often requires monitoring for rundll32.exe or regsvr32.exe loading unsigned DLLs from suspicious user paths.
Sysmon
| where Image in ('rundll32.exe', 'regsvr32.exe')
| where Signed == 'false'
| where ImagePath !contains "C:\\Windows\\System32"
Given the "strategic patience" mentioned, you should also hunt for Scheduled Tasks with delayed triggers. These groups love to set execution dates weeks or months out to avoid immediate detection. I use this one-liner to find tasks set to run far in the future:
Get-ScheduledTask | Where-Object {$_.Triggers.StartBoundary -gt (Get-Date).AddDays(30)}
It’s a simple way to catch long-term sleeper agents.
Verified Access Required
To maintain the integrity of our intelligence feeds, only verified partners and security professionals can post replies.
Request Access