ForumsGeneralAPT37 Returns: Facebook Social Engineering & RokRAT's Cloud C2

APT37 Returns: Facebook Social Engineering & RokRAT's Cloud C2

CISO_Michelle 4/13/2026 USER

Just caught the latest report on APT37 (ScarCruft) pivoting back to Facebook for initial access vectors. They are leveraging 'friend requests' to establish trust before delivering RokRAT. While social engineering isn't new for this group, the brazenness of adding targets as friends to bypass the 'stranger danger' heuristic is a notable shift in their TTPs.

Technically, RokRAT remains a headache because it doesn't rely on traditional C2 infrastructure that we can easily sinkhole. Instead, it abuses legitimate cloud providers like Dropbox, Google Drive, and pCloud for command and control. This allows the malware to blend in with normal corporate traffic, as standard firewall rules usually allow access to these endpoints.

If you're threat hunting for this specific campaign, focus on the delivery mechanism and the subsequent cloud abuse. Look for:

  • DLL Side-loading: APT37 often uses legitimate, signed binaries to load their malicious DLLs.
  • Suspicious Process Execution: Unexpected child processes spawning from social media apps or document viewers.
  • Cloud API Anomalies: Non-browser processes hitting cloud storage APIs.

Here is a quick PowerShell snippet to hunt for suspicious processes accessing common cloud storage APIs that are not the official client binaries:

Get-NetTCPConnection | Where-Object {
    ($_.State -eq 'Established') -and 
    ($_.RemotePort -eq 443) -and 
    (Get-Process -Id $_.OwningProcess -ErrorAction SilentlyContinue | Where-Object { 
        $_.ProcessName -notin @('dropbox', 'googledrivesync', 'chrome', 'firefox', 'msedge', 'onedrive') -and 
        $_.MainWindowHandle -eq 0 # Headless or background process
    })
} | Select-Object OwningProcess, RemoteAddress, State

Given that RokRAT uses these platforms for data exfiltration, detecting the API calls is often more effective than blocking the IPs.

How is everyone handling the 'Social Media' vector in their environment? Are you relying solely on awareness training to spot fake profiles, or has anyone implemented technical controls (like TLS inspection or strict proxy categorization) to catch the C2 traffic?

SY
SysAdmin_Dave4/13/2026

We actually caught a similar attempt last month targeting our research team. The 'recruiter' profile looked very polished, but the header image was a stock photo.

From a detection standpoint, we've had success with EDR correlation rules looking for unsigned binaries touching googleapis.com or dropboxapi.com. RokRAT is tricky because it hides in plain sight, but the user-agent strings and the lack of standard tokens usually give it away if you are inspecting SSL traffic.

MD
MDR_Analyst_Chris4/13/2026

The technical side is manageable with proper EDR tuning, but the psychological aspect is the real vulnerability here. Users instinctively trust a 'friend request' from someone with mutual connections or a plausible profile picture.

We've started including 'social media verification' in our phishing simulations. It's shocking how many people will accept a request from a 'new colleague' they've never met in real life just to be polite.

Verified Access Required

To maintain the integrity of our intelligence feeds, only verified partners and security professionals can post replies.

Request Access

Thread Stats

Created4/13/2026
Last Active4/13/2026
Replies2
Views19