——「誰もいない」はずの部屋に、ずっと誰かがいた。
「眠っているバックドア」を技術的に解く
2026年8月、独立系マルウェア研究者が SLEEPWALKER と名付けた Windows バックドアを公開した。このマルウェアの最大の特徴は「受動性」だ。メモリ上に常駐しながら、特定の細工（クラフト）されたネットワークパケットが届くまで一切の悪意ある動作をしない。EDR（エンドポイント検知・応答システム）が「挙動」でマルウェアを検出するのに対し、SLEEPWALKER は「動かないこと」で検知を逃れる。
さらに驚くのは、その「実行エンジン」だ。受け取ったパケット内のペイロードを、独自設計の 23命令バイトコード言語 で解釈して実行する。つまり、シグネチャで既知の shellcode を検出しようとしても意味がない。バックドア自体がミニ VM（仮想マシン）を内包しており、命令セットが既存のどんな AV シグネチャとも一致しない。
sequenceDiagram
participant 攻撃者
participant ネットワーク
participant SLEEPWALKER常駐
participant OSプロセス
Note over SLEEPWALKER常駐: 通常時: 完全沈黙・無害に見える
攻撃者->>ネットワーク: 特定の細工パケット送信
ネットワーク->>SLEEPWALKER常駐: パケット到達
SLEEPWALKER常駐->>SLEEPWALKER常駐: 独自バイトコードをデコード
SLEEPWALKER常駐->>OSプロセス: コマンド実行
OSプロセス-->>攻撃者: 結果を返送
style 攻撃者 fill:#c0392b,color:#fff
style SLEEPWALKER常駐 fill:#e67e22,color:#fff
style OSプロセス fill:#27ae60,color:#fff
「眠るマルウェア」は珍しくない——でも今回は何が違うのか
「トリガーを受け取るまで動かない」マルウェアは過去にもある。有名なのは Sliver や Cobalt Strike のビーコンが一定間隔でしか通信しないモードだ。しかし SLEEPWALKER の特異点は、独自バイトコード VM を内包している点にある。これが意味するのは：
① コマンドが「命令セット」として送られるため、ネットワーク側のシグネチャでも検知しにくい。② 攻撃者が新しい「命令」を定義しても、バックドア本体を更新する必要がない。③ 解析者が逆アセンブルしても、既知の API 呼び出しパターンが見えにくい。
まだ帰属や被害規模は不明（未報告のサンプル）だが、設計思想 の洗練度が注目に値する。
自分のコード・システムに照らし合わせると
SLEEPWALKER を使っているのは高度な攻撃者だとしても、「受動的に潜む」設計パターンは自分のコードにも潜んでいないか と考えてみてほしい。
たとえば、長期間使われていない eval() や exec()、外部から受け取った文字列をそのまま SQL や OS コマンドに渡す箇所、あるいはデシリアライズ処理——これらは「普段は動かないが、特定の入力が来ると突然コードを実行する」という意味で SLEEPWALKER と構造が似ている。EDR が「挙動」を見ているように、コードレビューも「普通のリクエストではトリガーされない」パスを見落としやすい。
# 危険なパターンの例（Python）
def handle_request(data):
# 普段は無害に見えるが、細工された data が来ると...
result = eval(data["expression"]) # SLEEPWALKER 的な構造
return result自分のサービスのどこかに「特定の入力でのみ起動する処理」があるなら、それが正規フローでしか到達できないか確認する価値がある。ファイアウォールや WAF（ウェブアプリケーションファイアウォール）はその「特定パケット」をそもそも通さない設計になっているか？
あなたのシステムへの問い
SLEEPWALKER が示したのは「静かであることが無害の証拠にはならない」という事実だ。最後に一つ問いかけたい——自分の本番環境で、外部からのネットワーク入力を受け取ってコードや SQL を動的に構築・実行している箇所を、すべて把握しているか？ セキュリティツールが「正常」と判定しているのは「今まで誰も細工したパケットを送ってこなかったから」かもしれない。