Money Left Untouched, Yet Completely Wiped Out? Ultimate Defense in Automated Trading: Lessons from the GMO GlobalSign Cybersecurity Incident

In the world of cybersecurity, hacker tactics are always more insidious than imagined—and sometimes carry a chilling, almost surreal theatricality.

In October, GMO GlobalSign, a world-renowned Certificate Authority (CA), suffered a major cybersecurity extortion incident that shocked the industry. Facing massive extortion demands from hackers, GlobalSign—a cornerstone of global internet trust—demonstrated the resolve of a cybersecurity titan by refusing to compromise.

Seeing that they could not extract a ransom directly from GlobalSign itself, the enraged hackers did not back down. Instead, they pivoted to a target capable of indirectly inflicting severe damage on GlobalSign's reputation and affiliated investments: a cloud virtual host provider specializing in hosting automated foreign exchange trading services (Expert Advisors).

(中文版內容在後）

1. Extortion Failed, Turned to Sabotage: Why Wipe Out Funds Instead of Stealing Them?

Exploiting underlying host vulnerabilities at the cloud service provider, the hackers compromised and took control of a large number of virtual hosts running automated Forex trading for clients.

Unexpectedly, after gaining control of these hosts, the hackers did not directly transfer out the funds in the trading accounts. The reason was simple: fund withdrawals and transfers were protected by strict Multi-Factor Authentication (MFA). Without secondary verification from the account holders, the hackers could not move the money.

To demonstrate force against GlobalSign and cause maximum chaos, the hackers took an extreme approach: using the already logged-in automated trading interfaces on the hosts, they executed malicious, indiscriminate buy and sell orders, completely wiping out the clients' account equity in a very short period!

This exposed a long-standing cybersecurity blind spot in the field of automated trading:

Automated Forex trading (EA) software operates at high frequencies, placing orders second by second. Once a user completes the initial login, the trading interface remains open for the trading program to execute transactions. This architecture heavily relies on a fatal assumption: "As long as the virtual host itself is secure, trading is secure."

Once the underlying virtual host is breached, this assumption collapses. Even if hackers cannot transfer funds out, controlling the trading interface enables them to inflict catastrophic, irreversible financial losses.

2. The Dual Cybersecurity Pitfalls of Automated Trading: Post-Login Hijacking and Malicious Authorization

Why can a system still be maliciously manipulated even when the account owner logged in legitimately? Examining these attacks reveals two sophisticated threat scenarios that are notoriously difficult to prevent:

2.1 Session Hijacking and Remote Control

• Scenario Description: A legitimate trading manager completes a normal login in the morning (passing initial MFA), and the trading software begins operating. Later, hackers exploit unpatched OS vulnerabilities or a previously deployed Remote Access Trojan (RAT) to quietly infiltrate the host in the background, taking over the already authorized session and control privileges.

  
  

• Traditional Defense Blind Spot: Traditional MFA typically "verifies only once" (at the time of initial login). Once passed, the internal system is treated as trusted, leaving post-login session takeover completely exposed.

2.2 Trojanized Software and Authorization Abuse

• Scenario Description: To expand analytical capabilities, a trading manager inadvertently downloads a third-party indicator, plugin, or cracked EA software embedded with a backdoor. The manager personally logs in, inserts security keys, and completes authorization. The malicious program then seamlessly leverages this "legitimately authorized" connection to execute unauthorized trades in the background, liquidating account funds.

  
  

• Traditional Defense Blind Spot: MFA verifies only whether the user's identity is authentic; it cannot verify whether the code executing in the background is clean.

3. Zero Trust Architecture: Dual MFA Defense Mechanism

To prevent similar "host compromised, equity wiped out" disasters from recurring, relying solely on "MFA for withdrawals" is far from sufficient. A Zero Trust Architecture must be implemented, mandating Multi-Factor Authentication (MFA) across two critical checkpoints:

1. Virtual Host Access Control: Strictly restrict remote host access (such as SSH, RDP, or Cloud Admin Panels) and prohibit login using passwords alone.

   
   

2. Trading Account and API Connections: When trading terminals or automated programs bind to accounts, they must undergo independent authorization verification rather than relying on default host privileges to place orders.

4. The Ultimate Line of Defense: Hardware-Level Access Control

In the face of remote session takeover and trojanized software, traditional software-based MFA (SMS codes, authenticator apps) remains vulnerable to interception or session hijacking. The most secure solution is to implement hardware-level access control with the highest resistance to tampering, such as utilizing SecuX FIDO Keys (e.g., PUFido Drive / CLife Key):

4.1 Core Hardware Security Technologies

• Built-in iMQ Secure Element & PUF Technology: Combining Physical Unclonable Functions (PUF), cryptographic keys are sealed deep within the hardware chip, completely isolated from the operating system and memory. Malicious software running on the host cannot access plaintext private keys.

• Strong Device and User Binding (FIDO2 / WebAuthn): Utilizing open standards, the physical FIDO Key is tied specifically to authorized computers and users.

  
  

4.2 Hardware-Level Defense Against the Two Major Security Pitfalls

Attack Scenario	Traditional Defense Flaw	FIDO Key Hardware-Level Defense Mechanism
Scenario 1: Post-Login Hijacking (RAT / Session Takeover)	Once logged in, remote hackers can freely operate the screen and trading interface.	Step-up Authentication for Critical Actions: Changing strategies, unlocking APIs, or placing large orders mandates a physical touch on the FIDO Key. Remote hackers cannot physically press the key, blocking malicious operations immediately.
Scenario 2: Background Malicious Orders via Trojanized Software (Malware Abuse)	Malicious software uses authorized sessions/APIs to issue background trade commands.	Private Key Isolation & Origin Binding: Cryptographic keys are locked inside the Secure Element and cannot be extracted by background malware. Coupled with FIDO2 domain and application binding, forged connection requests are rejected outright by the secure chip.

4.3 Defense-in-Depth Across Endpoint and Brokerage Levels

• Endpoint System Level: Enable AppLocker / WDAC application whitelisting on virtual hosts to block any unsigned third-party plugins from executing.

• Brokerage Risk Management Level: Configure account-level maximum daily drawdown limits and circuit breakers for abnormal order frequencies to prevent rapid liquidation via consecutive abnormal trades.

5. Conclusion: Anchoring Cybersecurity to an Unclonable Physical Line of Defense

The GMO GlobalSign incident offers a crucial lesson for all automated traders and cloud hosting providers: cybersecurity is not an optional feature, but a matter of survival.

While automated trading brings unprecedented efficiency, it demands a substantially higher standard for security architecture. From virtual host access to trading account authorization, only by combining dual MFA mechanisms with chip-level physical hardware binding (such as SecuX PUF-based FIDO Key) can organizations establish a robust physical defense wall that remote hackers cannot breach.

錢沒被轉走，卻全部「輸光」？從 GMO GlobalSign 資安事件看「自動化交易」的終極防禦

在資安的世界裡，駭客的手段永遠比想像中更刁鑽，有時甚至帶有一絲荒謬卻令人毛骨悚然的戲劇性。

十月，全球知名數位憑證簽發機構（CA）GMO GlobalSign 遭遇了一起震撼業界的大型資安勒索事件。面對駭客的巨額勒索，作為全球網際網路信任基石之一的 GlobalSign 展現了身為資安巨頭的底氣——直接拒絕妥協。

眼看無法從 GlobalSign 本體勒索到贖金，氣急敗壞的駭客並沒有就此罷休，而是將目光轉向了能夠間接對其商譽與轉投資事業造成重創的目標：一家專門提供外匯自動交易（EA）代管服務的雲端虛擬主機廠商。

一、 勒索不成轉下毒手：為什麼不偷錢，而是把錢「輸光」？

這群駭客利用該雲端服務公司主機的底層漏洞，一舉攻陷並掌控了大量託管給客戶運作外匯自動交易的虛擬主機。

令人意想不到的是，駭客掌控主機後，並沒有將帳戶內的資金直接匯轉走。原因很簡單——「資金提領與匯出」設有嚴密的多因子認證（MFA），沒有帳戶持有人的二次驗證，駭客根本動不了這些錢。

為了向 GlobalSign 示威並製造最大的混亂，駭客採取了一種極端的方式：利用已經登入主機的外匯自動交易介面，惡意進行無差別的亂買亂賣，硬生生把客戶帳戶裡的資金在極短時間內「完全輸光」！

這暴露出外匯自動交易領域長久以來的資安盲點：

外匯自動交易（EA）軟體為了實現每分每秒高頻率的自動下單，只要使用者完成初始登入後，介面就會持續開放給交易程式執行。這樣的架構高度依賴一個致命的假設——「只要虛擬主機本身是安全的，交易就是安全的。」

一旦虛擬主機底層被滲透，這層假設隨之破滅，即便駭客轉不走資金，也能透過控制交易介面造成不可逆的巨大經濟損失。

二、 自動化交易的雙重資安陷阱：登入後劫持與惡意授權

為什麼即便帳戶擁有人「合法登入」，系統依然會被惡意操弄？細究這類攻擊，通常包含兩種極難防範的高級威脅情境：

1. 會話劫持與遠端控制（Session Hijacking / RAT Attack）

• 情境描述：合法的交易經理人早上已經完成正常登入（通過了初次 MFA），交易軟體正在運作。此時，駭客利用主機未修補的 OS 漏洞或早先潛伏的遠端存取木馬（RAT），在背景侵入主機，直接接管已經授權的控制權（Session）。

• 傳統防禦盲點：傳統 MFA 通常「只驗證一次（登入當下）」，一旦通過，系統內部就被視為安全，導致登入後的權限劫持完全門戶大開。

2. 木馬化軟體與授權陷阱（Trojanized Software / Authorization Abuse）

• 情境描述：經理人為了擴充分析功能，不小心下載了被植入後門的第三方指標、外掛或破解版 EA 軟體。經理人親自完成登入並插入密鑰完成授權，惡意程式便順理成章地在背景利用「合法授權」的連線將帳戶資金亂買亂賣。

• 傳統防禦盲點：MFA 只能驗證「登入者身分是否真實」，無法驗證「正在背景執行的程式碼是否乾淨」。

三、 零信任架構（Zero Trust）：雙重 MFA 防禦機制

要避免類似的「主機被控、資金抹平」慘劇重演，僅靠「提款時有 MFA」是遠遠不夠的。必須落實零信任架構（Zero Trust），在以下兩個關鍵環節強制導入多因子認證（MFA）：

1. 虛擬主機的權限登入（Virtual Host Access）： 嚴格限制主機遠端存取（如 SSH、RDP 或 Cloud Admin Panel），禁止僅靠單一密碼登入。

   
   

2. 交易帳號與 API 連線（Trading Account Connection）： 交易終端機或程式綁定帳號時，必須經過獨立的授權驗證，不能僅憑主機預設權限開開放下單。

四、 終極防線：硬體層級權限管理

面對遠端劫持與木馬軟體，傳統的軟體式 MFA（簡訊、驗證碼 App）依然存在被側錄或 Session 劫持的風險。最安全的解決方案，是導入破解難度最高的硬體層級權限管理（Hardware-level Access Control），例如運用 SecuX 的 Fido Key（如 PUFido Drive / CLife Key）：

1. 核心硬體安全技術

• 內建 iMQ 安全晶片（Secure Element & PUF 技術）： 結合實體不可複製功能（PUF），將加密金鑰密封於硬體晶片深處，完全隔離於作業系統與記憶體之外，軟體側的惡意程式根本無法存取明碼金鑰。

• 設備與使用者強綁定（FIDO2 / WebAuthn）： 透過開放標準，將 FIDO Key 實體綁定至具備登入權限的指定電腦與使用者。

2. 針對兩大資安陷阱的硬體防堵機制

攻擊情境	傳統防禦漏洞	FIDO Key 硬體層級防堵機制
情境一： 登入後被劫持 (RAT / Session Takeover)	登入通過後，遠端駭客可任意操作螢幕與交易介面。	關鍵動作二次簽章（Step-up Auth）： 變更策略、解鎖 API 或發送大額訂單時，系統強制要求實體觸碰 FIDO Key。遠端駭客無法實體按壓金鑰，惡意操作直接被擋下。
情境二： 木馬軟體背景惡意下單(Malware Abuse)	惡意軟體利用已授權的 Session/API 在背景發送交易指令。	私鑰硬體隔離與 Origin 綁定： 金鑰鎖在安全晶片內，背景木馬無法竊取。加上 FIDO2 的網域與應用程式綁定，偽造的連線要求會被安全晶片直接拒絕。

3. 搭配系統與券商層級的「縱深防禦」

• 端點系統層：在虛擬主機開啟 AppLocker / WDAC 應用程式白名單，禁止任何未經數位簽署的第三方外掛執行。

• 券商風控層：設定帳戶單日最大回撤與異常頻率下單熔斷機制，防止短時間內被連續搓合異常交易。

五、 結語：將資安拉回「無法被遠端複製」的實體防線

GMO GlobalSign 事件給所有自動化交易者與雲端託管企業上了寶貴的一課：資安不是選擇題，而是生死存亡的必答題。

當自動化交易帶給我們高效率的同時，也對防護架構提出了更高的要求。從「虛擬主機存取」到「交易帳號授權」，唯有同時實施雙重 MFA 機制，並輔以安全晶片層級的硬體實體綁定（如 SecuX Fido Key），才能真正建構起網路駭客無法越雷池一步的實體防禦高牆。