1. Summary: What Happened

On 28 July 2026, the Hong Kong Securities and Futures Commission publicly reprimanded and fined Luk Fook Securities (HK) Limited (LFSHK) HK$2.1 million (approx. US$268,000) under section 194 of the Securities and Futures Ordinance. The action concerns a ransomware incident from nearly four years earlier.

LFSHK is licensed for Type 1 (dealing in securities), Type 4 (advising on securities) and Type 9 (asset management) regulated activities.

Timeline as documented:

Outcome for clients: the SFC found no evidence of misappropriation of client assets, unauthorised trading, client financial losses, or leakage of client information. No client complaints were received.

The fine still landed. The sanction attaches to the control failures themselves. Demonstrated client harm was never a precondition.

2. SFC Observed Findings

The following are the SFC's findings as published. No interpretation in this section.

2.1 Deficiencies contributing to the inability to withstand the attack

2.2 Deficiencies contributing to the three-week recovery delay

2.3 The architecture detail in footnote 2

The SFC describes the VMware environment as mainly used by external system vendors for maintenance and by a small group of internal users to access the trading system. It states that although both groups operated within the same VMware environment, their access was restricted to separate areas: system vendors could access the control panel, while internal users could only access the trading system.

2.4 Where the SFC hedged

Three phrases carry deliberate uncertainty, and they matter to everything downstream:

  • Entry to the AD server occurred "likely via a cached remote desktop shortcut."
  • The unencrypted credential file created a vulnerability that attackers "likely exploited" to further compromise the network.
  • The deficiencies "might have contributed" to the failure to withstand the attack; the incident "could have been attributable to" the deficiencies listed.

2.5 Regulatory provisions cited

3. Technical Analysis

The SFC describes control gaps. It does not describe how they were abused, and in most cases it explicitly declines to. What follows works through each finding and sets out the exposure it represents, drawing on what we see when we test environments with the same weaknesses.

A word on how to read this. Our engagement experience tells us what a given gap permits. It does not tell us what happened here. When we say a cached credential store is typically the fastest lateral movement path we find on an administrative host, that describes the class of weakness. Nothing in it reconstructs this incident. The SFC had a same-day self-report, an external consultant's investigation and an independent reviewer's assessment, and still would not commit to an attack chain. We are in no position to do better, and we will not pretend otherwise.

3.1 One environment, three trust levels

Footnote 2 is the most technically loaded part of the statement, and it will probably get the least attention. One VMware environment, with external vendors on the control panel and internal users on the trading system. Separation described as "separate areas."

Separation expressed as areas within a shared environment is administrative or application-layer separation. That differs from a network boundary in a way that matters under compromise. A firewalled VLAN is enforced by a device independent of the identities traversing it, so it keeps enforcing when a credential is stolen. Logical partitioning inside shared compute is enforced by the same authorisation system the credential belongs to. Steal the credential and the boundary moves with you.

The exposure this creates depends on what "control panel" resolves to, and the statement does not say. The general shape is still worth setting out, because we encounter it constantly. Where a virtualisation management plane is reachable, whether that is vCenter, an ESXi host UI, or a vendor maintenance console layered above them, the abuse paths bypass network controls instead of defeating them:

  • Console access sidesteps the network entirely. A VM console session is delivered through the hypervisor, bypassing the guest's network stack altogether. Firewall rules, host-based restrictions and network segmentation between the operator and the guest all become irrelevant, because the traffic never traverses the path those controls sit on. This surprises people. We have seen client architecture diagrams showing a hard boundary that the management plane simply routed around.
  • Offline disk access defeats host-level protection. Snapshotting or cloning a VM and mounting the resulting disk elsewhere yields the filesystem without ever starting the guest. Nothing inside the guest OS is running to object: no endpoint agent, no logging, no credential protection. For a domain controller VM, the relevant artifact on that disk is the AD database itself.
  • Guest operations APIs execute inside VMs without network access. Where hypervisor tooling supports it, files and commands can be pushed into a guest through the virtualisation layer using management-plane credentials.

None of this is exotic. It is the standard reason we treat virtualisation management as Tier 0 in every assessment, at the same classification as domain controllers.

Applied to the finding: the environment carried a vendor maintenance function, a staff jump server function and an application access tier in one failure domain. The question we would ask on an assessment is not "are these groups separated?", because the documentation always says yes. It is "which single credential compromise collapses the separation?" With logical partitioning the answer is usually shorter than the diagram implies. We do not know how LFSHK implemented it, whether it was ever tested, or whether it was breached. The SFC does not say.

3.2 Cached credentials on a remote access tier

A jump host earns its keep by being narrow, instrumented and credential-free. Cache credentials on it and the property inverts. Rather than one hardened transit point, you have a single machine that aggregates access to everything behind it. That follows from the design itself, and does not depend on any particular attacker behaviour.

The SFC's phrase, "likely via a cached remote desktop shortcut," points at a specific and well-understood set of Windows artifacts:

ATT&CK references: T1555.004 (Credentials from Password Stores: Windows Credential Manager), T1078 (Valid Accounts).

What this class of finding permits, in our experience:

The MRU is a target list. Before touching anything, connection history tells you which hosts an administrator considers important and which account they use for each. On engagements this routinely saves an entire discovery phase, and it is quieter than scanning, since reading a registry key generates nothing a network sensor will see.

The stored credential authenticates without ever being cracked. People misread DPAPI protection here. It is effective against theft of the file in isolation. It offers very little against an actor already executing in that user's session, because decryption proceeds through ordinary API calls using the user's own master key. There is no offline cracking step to slow anyone down. cmdkey /list shows what is available, and the unwrap follows from context.

Shared administrative hosts introduce session hijacking. Where several administrators RDP into one jump host, which is precisely the pattern described here with vendors and IT sharing an environment, disconnected sessions persist. An account with sufficient local privilege can attach to another user's session without needing that user's password at all. The credential never has to be stolen, because the authenticated session is already there.

Bitmap cache leaks content. This is less commonly useful, but on long-lived administrative hosts, cached screen tiles can be reassembled into fragments of what was displayed in prior sessions. We have recovered configuration detail this way, and occasionally credentials typed into visible fields.

One conclusion does follow from the finding itself, with no assumption about technique: if a remote access host holds credentials that authenticate to a domain controller, it is functionally Tier 0 whatever the documentation calls it. Its control requirements should match the most sensitive asset it can reach. The seniority of the people using it is beside the point.

On the missing MFA (finding 2.1e), the purpose of a second factor on remote access is to break exactly this chain. A cached or stolen credential stops being sufficient by itself. Without it, every credential exposure elsewhere in the estate converts directly into remote access.

3.3 Why "legacy OS" is really a telemetry finding

The SFC writes that the systems no longer receive security updates and are incompatible with modern endpoint protection. The second clause carries far more weight and will get far less attention.

A Windows 7 or Server 2008-era host is not simply a current host missing recent patches. The defensive substrate that modern detection depends on does not exist on it at all:

One further issue is specific to this generation: WDigest caches plaintext credentials in LSASS by default on Windows 7 and Server 2008/2008 R2. KB2871997 (2014) made it configurable through HKLM\SYSTEM\CurrentControlSet\Control\SecurityProviders\WDigest\UseLogonCredential, and later Windows versions ship with it off.

Stack those together and the practical position on an unpatched host of this vintage is: plaintext secrets resident in a process protected by neither PPL nor virtualisation-based security, on a system with no AMSI to inspect script payloads and no ETW Threat Intelligence provider for a kernel sensor to consume, running an endpoint product that most vendors stopped supporting after January 2020.

From an offensive standpoint, the significance lies less in any single technique becoming available and more in the fact that the detection cost of everything drops to near zero. On a modern, well-instrumented host we plan around telemetry: which actions generate which events, what a defender is likely to correlate, how to stay under thresholds. On a host of this generation that planning is largely unnecessary, because the events are not being generated and, per finding 2.1a, not being centrally collected either. We have described environments like this in reports as offering no meaningful resistance after initial access. That is a comment on the platform. It says nothing about anyone's competence.

A second problem builds more slowly. An EOL system accumulates publicly documented privilege escalation and remote code execution issues that will never be fixed. The gap does not stay constant; it widens every month the system stays in service. Two years and eight months past the end of extended support, which is where 19 September 2022 sits relative to the 14 January 2020 cutoff, is a long time for that to compound.

For reference:

The statement says only that the systems no longer received security updates. Whether ESU was ever purchased is not addressed, and we do not assume either way.

On the regulatory logic, precision matters. Running EOL software is not in itself a breach. What was cited is running it as the internet-reachable jump server carrying privileged remote access into a licensed corporation's core network, without compensating controls. Cybersecurity Guidelines 2.4 (patch management) and 2.5 (end-point protection) were cited together, and that pairing reads as deliberate.

3.4 The AD server had the weakest posture in the estate

Three findings land on one machine: antivirus signatures roughly a year out of date, system account credentials in an unencrypted Excel file, and the attacker gaining entry to it.

A domain controller is Tier 0 by definition, since compromise of it is compromise of the identity system every other system trusts. These findings describe that asset carrying weaker controls than would be acceptable on a general workstation.

The credential file. ATT&CK T1552.001, Credentials In Files. Its value is that it requires no interaction with protected memory and no specialist tooling, and produces no behaviour endpoint protection is built to catch. It is a file read. In our engagements, recursive keyword search across common document and spreadsheet formats is one of the first things we do after obtaining any read access, because the effort-to-value ratio is so extreme: a search measured in seconds can replace an entire privilege escalation phase. In environments without a privileged access management system, we find something usable more often than we do not. The SFC says the file existed and that attackers "likely exploited" it, which is the regulator's hedge and we will leave it as theirs. How it was found, whether it was accessed, and what it contributed are not in the record.

What DC compromise permits generally. This is why the concentration of findings on this host matters:

  • The AD database itself. NTDS.dit holds every domain credential hash. Extracting it (T1003.003) is a well-trodden path and needs nothing exotic, since the mechanisms are built into Windows administrative utilities and volume shadow copy services. Alternatively, DCSync (T1003.006) abuses legitimate directory replication to request credential material remotely, without touching the DC's filesystem at all.
  • Persistence that survives remediation. With the right key material recovered, forged Kerberos tickets (T1558.001) can outlast password resets across the domain. This is why the standard AD recovery runbook mandates resetting the krbtgt account twice, and why organisations that skip that step get reinfected.
  • A distribution mechanism. Domain controllers are the natural point from which to reach every joined system simultaneously: Group Policy modification (T1484.001), SYSVOL script placement, remote scheduled task creation, remote service creation. The SFC's list of affected systems (file servers, domain controllers, email, trading application, accounting) is consistent with estate-wide impact instead of sequential impact, though the statement does not describe deployment mechanics and we will not invent them.

The stale signatures. A signature set a year out of date on a domain controller has stopped being a degraded control. In practical terms it is an absent control that reports as present, which is worse than nothing, because it occupies an audit line item that would otherwise generate a finding. We see this pattern repeatedly on domain controllers, usually justified on stability grounds: the DC is too sensitive to risk an agent update, so it is quietly excluded from the fleet policy. The result is that the least-monitored host in the environment is also the most valuable one.

The generalisable point: domain controllers should be the ceiling of your security posture, not the floor.

3.5 The backup design set the outage duration in advance

The SFC records three related failures here: backups sat on an external drive that was not consistently disconnected, those backup files were compromised during the attack, and the BCP contained no ransomware or data-loss scenario.

A mounted volume is enumerable and writable by any process with sufficient privilege. From the perspective of encryption tooling there is no distinction between "the backup target" and "another reachable path," because enumeration does not respect intent. Inhibiting system recovery is T1490, a technique class that ransomware operators carry out deliberately before encryption begins, and it covers shadow copy deletion, backup catalog destruction and disabling of boot-time recovery alongside encryption of the backup data itself.

Two exposures here go beyond the drive simply being mounted. First, backup infrastructure tends to run under highly privileged service accounts by design, since it needs to read everything. Where those credentials are recoverable, the backup system becomes a lateral movement path in its own right and not merely a target. Second, backup servers are frequently excluded from patching windows and endpoint tooling for the same "too sensitive to disturb" reasons as domain controllers, with the same result.

The recovery duration is where the real inference sits. The SFC states that domain controllers were affected and that backups were compromised. Where both hold, the problem stops being file restoration and becomes Active Directory forest recovery, procedurally one of the harder operations in Windows administration. Microsoft's documented approach involves restoring a single DC per domain from known-good system state, seizing FSMO roles, performing metadata cleanup for DCs not being restored, rebuilding the remainder from that authoritative source, and resetting krbtgt twice, all before dependent application services can come back and be revalidated.

In the recovery exercises we have observed, organisations underestimate this consistently, and the reason lies in the shape of the work: the constraints are sequential, not resource-bound. Adding people does not compress a dependency chain. Where clients have actually timed a forest recovery in a lab, elapsed time has frequently exceeded their documented RTO by a wide margin, and those are the well-prepared clients, the ones who ran the test at all.

We do not know what procedure LFSHK followed. The statement says only that restoration proceeded in phases and completed on 7 October 2022. Three weeks is entirely consistent with a rebuild-order problem instead of a restore-speed problem, and rebuild order is decided by architecture long before an incident starts.

3.6 The missing SIEM is visible in the statement's own wording

This is the observation we find most instructive, and it needs no speculation at all, because it comes from comparing two parts of the same document.

The SFC found that network devices were not monitored by a SIEM tool. It also found that no record retention policy existed even during the recovery period. Now read how the statement describes the attack: likely via a cached remote desktop shortcut, attackers likely exploited the credential file, the deficiencies might have contributed.

The regulator had three evidentiary layers available: a same-day self-report, an external consultant's investigation, and an independent reviewer's assessment commissioned at its own request. With all three, the regulator still would not state the chain.

That outcome is technically consistent with the logging findings. Windows Security event logs are host-local, default-sized and subject to rollover. On encrypted hosts they may be unrecoverable. Network devices never onboarded to a collection platform retain nothing. Without off-host forwarding, forensic evidence has the same availability as the systems that were just encrypted. Log clearing (T1070.001) is also trivially available to anyone with administrative access on a host where nothing is shipped elsewhere.

The practical takeaway: the gap between "we know the control failures" and "we know the attack path" is exactly the gap centralised logging closes. Detection is the usual business case for SIEM. This case supplies a second one, namely the ability to give a defensible, evidenced account to a regulator years after the fact. That LFSHK also lacked a record retention policy during recovery is unlikely to be a coincidence.

3.7 The two findings that get overlooked

USB controls (2.1g). Unrestricted removable media is usually discussed as a malware introduction risk, which undersells it. On engagements the more useful property is that removable media is an exfiltration path that bypasses network controls entirely: no proxy, no DLP inspection, no egress filtering, no netflow record. Where physical or insider access is in scope, it is the quietest route out of an environment available to us. It is also a delivery vector for devices that present as keyboards instead of storage, which sidesteps controls scoped only to mass storage.

Training last delivered in 2018 (2.1h). That is four years stale, and it was narrow even when current, covering only two-factor authentication for the trading system. The risk this leaves has little to do with staff clicking links. It concerns helpdesk and vendor-support pretexting. An environment with third-party remote support relationships, no MFA on remote access and no recent awareness training presents a social engineering path where a plausible caller claiming to be from a known vendor can be assisted rather than challenged. In red team work this is frequently the lowest-effort route in, and it defeats technical controls by going around them. The people most exposed are usually the ones with the most access.

3.8 What cannot be determined from the record

Stating the limits is part of reading the document honestly. The following are not in the statement, and we make no claims about them:

  • The initial access vector. "Exploited remote access to the VMware environment" does not distinguish credential abuse from exploitation of an internet-facing service. The cached RDP shortcut is the SFC's hedged description of entry to the AD server, not of initial entry to the environment.
  • Any specific vulnerability or CVE.
  • The ransomware family or affiliate.
  • Dwell time. Per Β§3.6, we would question whether it was reliably determinable.
  • The deployment mechanism for the encryption.
  • Whether data was exfiltrated. The SFC found no evidence of client information leakage, which given the telemetry findings is a statement about available evidence.
  • Whether a ransom was demanded or paid.
  • Whether ESU was purchased for the legacy systems.

If you encounter analysis that fills any of these in, ask where it came from.

4. Lessons Learned

Each item maps to a documented finding. None requires significant expenditure.

4.1 Credential hygiene on remote access tiers

Verify this technically. A policy assertion is not evidence. Per user profile, on every jump host and administrative workstation:

cmdkey /list
reg query "HKCU\Software\Microsoft\Terminal Server Client\Servers" /s
dir /s /b %USERPROFILE%\*.rdp

Then search privileged hosts and file shares for credential-shaped content in .xlsx, .docx, .txt, .ps1 and .config files. Deploy a PAM vault with checkout and rotation so that static credential files have no operational reason to exist. Enforce session timeouts and logoff on jump hosts so that disconnected sessions do not accumulate.

4.2 Legacy systems that cannot realistically be retired

Where a vendor dependency makes near-term retirement impossible, apply what hardening this generation supports:

reg add HKLM\System\CurrentControlSet\Control\Lsa /v DisableRestrictedAdmin /t REG_DWORD /d 0
reg add HKLM\SYSTEM\CurrentControlSet\Control\SecurityProviders\WDigest /v UseLogonCredential /t REG_DWORD /d 0

(Restricted Admin mode was backported to Windows 7 and Server 2008 R2 via KB2871997.)

Then treat the host as untrusted regardless: no inbound internet path, segmentation enforced by an independent device, a modern hardened bastion positioned in front of it, application allowlisting, and network-layer monitoring compensating for host telemetry you cannot obtain. Document risk acceptance at board level with a dated migration plan. The structural failure in this case was that the legacy host was the bastion.

4.3 Treat the virtualisation management plane as Tier 0

Management interfaces get MFA, dedicated administrative accounts not shared with general IT use, network restriction to a management VLAN, and audit logging forwarded off-platform. Vendors do not get standing management-plane access; they get time-bounded, brokered, recorded sessions. Console access and snapshot rights bypass the network controls you rely on elsewhere, so they need governing at the same level as domain administration.

4.4 Domain controller baseline

Verify signature currency and agent health on domain controllers individually. A fleet-wide average lets a handful of neglected hosts hide inside a healthy number. On Server 2012 R2 and later, confirm HKLM\SYSTEM\CurrentControlSet\Control\Lsa\RunAsPPL = 1. Alert on directory replication requests from sources that are not domain controllers. DCs should be the best-defended systems you own.

4.5 Architecture review

For every environment where two or more trust levels coexist, write down the single credential compromise that would collapse the separation. Where the answer is short, the separation is administrative and should be re-implemented at the network layer.

4.6 Third-party access

MFA, time-bounded, brokered through a session gateway, recorded. Vendor support accounts routinely combine the broadest access with the thinnest governance, and the SFC named vendor credentials specifically.

4.7 Backup and recovery

Keep at least one copy immutable or genuinely offline, with 3-2-1-1-0 as the working standard. Isolate backup service account credentials so that the backup system is not itself a lateral movement path. Then perform a timed lab restore of a domain controller and the most critical trading system. Maintain AD forest recovery as a separately rehearsed runbook, including the double krbtgt reset. An untimed procedure produces an estimate, not an RTO.

4.8 Logging and retention

Forward Security, System and PowerShell operational logs off-host, along with network device logs, and onboard the whole estate, including the awkward devices that never made it into the original rollout. Alert on log clearing. Set a retention period you would be comfortable defending to a regulator several years after an event, and put it in policy.

4.9 Removable media, training and continuity planning

Device control with monitoring, scoped to include devices presenting as input peripherals rather than storage alone. Awareness training refreshed at least annually against current threats, explicitly covering vendor and helpdesk pretexting alongside the usual phishing material. A BCP containing an explicit ransomware and data-loss scenario, reviewed on schedule and exercised. Incident management, data security and record retention policies established before they are needed, since the SFC noted their absence during recovery.

5. Conclusion

Several points seem worth carrying forward.

The findings describe a missing baseline, not a sophisticated attack. Credentials cached on a remote access host. A credential spreadsheet on a domain controller. Antivirus signatures a year out of date on that same domain controller. No MFA on remote access. Backups connected to the network. Awareness training last delivered in 2018, on an operating system out of support since January 2020, under guidance the SFC had published in April 2020. No zero-day appears in the record, and none is needed to account for the findings. The controls that would have interrupted an attack chain at several independent points are all foundational, and fundamental is the word the SFC itself used.

Enforcement did not depend on client harm. No client losses, no data leakage, no unauthorised trading, no complaints, and still a finding of misconduct. Any risk model treating absence of customer impact as absence of regulatory exposure is not supported by this case.

The evidentiary standard cuts both ways. The SFC declined to assert a definitive attack chain despite three layers of investigation, and its hedged language directly reflects the logging deficiencies it identified. For firms, that is an argument for centralised logging that has nothing to do with detection and everything to do with being able to account for an incident years later. For anyone analysing these cases publicly, it is a reminder that the correct response to a gap in the record is to mark it as a gap rather than fill it. We have tried to hold that line here. The SFC's findings are stated as findings, our own testing experience is offered as what these weaknesses permit, and the space between the two is left open.

The disciplinary action was published approximately three years and ten months after the incident. Architecture signed off this quarter will still be on the record, and open to examination, well into the next decade.

About Dracosec Research Limited

Dracosec Research Limited provides penetration testing, red team assessment and security consulting services, helping organisations identify and remediate the kinds of weaknesses described in this post before an attacker or a regulator finds them.

If you would like to discuss how your environment would hold up against the control gaps covered here, including remote access architecture, privileged credential handling, legacy system exposure, Active Directory resilience and recovery readiness, contact us.

Sources: SFC Statement of Disciplinary Action (ref. 26PR118) and accompanying press release, both 28 July 2026; SFC Guidelines for Reducing and Mitigating Hacking Risks Associated with Internet Trading; SFC Code of Conduct; SFC circular on cybersecurity risks associated with remote office arrangements, 29 April 2020; Microsoft product lifecycle and security feature documentation; MITRE ATT&CK.

Disclosure: we have no involvement in, and no non-public knowledge of, the incident described. Attack mechanics referenced in section 3 are general Windows and offensive-security knowledge, included to explain the significance of the control gaps the SFC identified. They are not assertions about the techniques used in this incident.