SKTハッキング仮説：USIMデータの窃取とBPFDoorの設置、どのように行われたのか？

PLURA

要点の一文要約
2025年4月18日、SKテレコムのHSS（Home Subscriber Server）がハッキングされ、最大2,300万人の加入者のUSIM認証情報が流出し、SKTは4月28日に全顧客を対象に無料USIM交換を発表しました。

SKTハッキング攻撃シーケンスダイアグラム例

以下の文書は、「SKTハッキング事件におけるBPFDoor設置の主な侵入ベクトルがWebシェル（WebShell）・RCE（Remote Code Execution）である」という仮説を前提に作成されました。

2018年6月のLGU+ハッキングにおけるWebシェルを用いた攻撃、2021年6月の韓国原子力研究院（KAERI）・韓国航空宇宙産業（KAI）ではSSL VPNの脆弱性を利用したRCE攻撃事例を考慮しています。

もちろん実際にはアカウントの乗っ取りや内部者の悪用といった他の手段も考えられますが、本稿ではWebシェル・RCE攻撃に重点を置いて展開します。

今後、新たな証拠が出た場合にはこの仮説も修正される可能性があることを念頭にお読みください。

1. SKT USIMハッキング事件とBPFDoorの概要

  1. 事件の概要

    • 2025年4月、SKテレコム（以下、SKT）の中核サーバであるHSS（Home Subscriber Server）がハッキングされ、BPFDoorマルウェアが設置され、大規模なUSIM加入者情報が流出したと推定される。
    • SKTハッキングは中国系APTグループ（Red Menshen、Earth Bluecrow、APT41など）と関連があるとみられ、BPFDoorは攻撃者が長期間にわたり密かにサーバ内部を掌握するためのステルス型バックドアとして活用された。

  2. BPFDoorの特徴

    • カーネルレベル（BPF）フィルタを活用：通常のポートリスニングの代わりにマジックパケットを受信しないと起動しない受動型バックドア。
    • メモリ常駐型（fileless）：/dev/shmなどにコピー後、元ファイルを削除し、プロセスを偽装・バックグラウンドで実行するなど、隠蔽技術を多段階で使用。
    • 広範囲なAPT攻撃に活用：中東・アジアなどの通信事業者や金融機関で同様のBPFDoor亜種が報告されており、今回のSKT事件もそのような高度化した攻撃の延長線上にあると評価される。

2. Webシェル（WebShell）・RCEによるBPFDoor配布：仮説的シナリオ

本ドキュメントの核心的な仮説は以下の通りです：

「SKT事件では、攻撃者が最も一般的で効率的なWebベースの攻撃（Webシェル・RCE）を用いてHSSサーバの内部権限を確保し、BPFDoorを設置した可能性が高い。」

これは2018年6月のLGU+ハッキングでのWebシェル使用事例などのように一般的であり、実際に現場でも頻繁に確認されるAPT攻撃の流れに基づいています。また、国内外のレポートでもWebシェルまたはRCEの脆弱性が全体の侵入の「大多数」を占めるという経験的事実が継続的に示されています。

2.1 一般的なWebシェル・RCE攻撃の流れ

  1. 脆弱性の特定

    • 攻撃対象サーバ（例：WebLogic、Apache、Nginx、Tomcat、独自開発のWebアプリなど）に存在する公開脆弱性（N-day）または**ゼロデイ（0-day）**を攻撃者が把握。
    • あるいはファイルアップロード機能が存在し、拡張子フィルタが緩かったり回避が可能な場合、Webシェルアップロードシナリオが開かれる。

  2. リモートコード実行（RCE）の達成

    • Webシェルアップロード：.php、.jspなどの悪意あるスクリプトをアップロード → /uploads/…のようなパスで直接呼び出し → サーバ内部でコマンド実行。

    • RCE脆弱性の利用：Log4Shell、WebLogic RCE、逆シリアライズの脆弱性などにより、HTTPリクエストだけでOSコマンドを直接実行可能。

    • この段階で攻撃者は低い権限（www-data、tomcatなど）でもサーバに侵入できるようになる。

  3. 権限昇格およびバックドア設置

    • sudoの誤設定、カーネル脆弱性、権限昇格ツールなどを利用してroot権限を取得。
    • 確実な再侵入の経路を確保するために、BPFDoorのような高度なバックドアを設置。
    • SKTの事例では、バックドアがkdmtmpflushなどの名前で/dev/shmに常駐し、元ファイルは削除されて隠蔽。

  4. 持続的な侵入

    • BPFDoorは外部から特定のマジックパケットを受信しないと起動しない受動型C2方式で密かに運用 → 長期間にわたりサーバを掌握。
    • その後、HSSのデータベースにクエリを送り、大量のUSIM情報を窃取、他の内部サーバへ横方向に移動。

3. なぜWebシェル・RCEが重要なのか？

  1. 攻撃者にとって最も簡単な初期侵入手段

    • 通常、企業ネットワークにおいてWebサービスは外部に公開されており、フレームワーク・プラグイン・ファイルアップローダーなど攻撃対象が広い。
    • パッチが不十分だったり、新たな脆弱性が公開された場合、自動スキャナによって多数のターゲットを迅速にスキャンし、一括で侵入可能。

  2. Webシェル vs. RCE、結果は同じ：サーバ掌握

    • Webシェル：アップロード脆弱性を通じて.jspファイルなどの実行可能スクリプトを配置 → Webサーバ権限でコマンドを実行。
    • RCE：アップロードなしでも特定の脆弱性（PHP逆シリアライズ、Log4j、WebLogicなど）を利用して即座にコマンド実行。
    • 一度でもシェル権限を得れば、BPFDoorのようなバックドアの設置は非常に簡単。

  3. 2023年1月、LGU+ハッキングでのWebシェル使用事例

    • このような状況でWebシェル攻撃が成功すれば、横方向移動（Lateral Movement）により内部ネットワーク深くまで侵入可能。

  4. 被害スケールの拡大

    • 特に通信会社・金融機関などは数十〜数百台のWebサーバを運用 → 攻撃対象が多い。
    • ファイアウォール・VPNの監視よりも、Webサービスは頻繁なアップデートが必要なため脆弱性パッチの未適用が多発しやすい。
    • 実際の侵害現場でも「Webシェルで始まり」または「RCEで一発突破」されたケースが大多数との報告が多い。

4. 具体的なBPFDoor設置シナリオ（Webベース仮定）

以下は今回のSKT事件に対する仮説的に構成したWebシェル・RCE中心のシナリオです。実際の侵入経路は異なる可能性がありますが、「Web攻撃が主力である」という仮定の下では整合性が高いです。

  1. （仮定）WebLogic、Tomcat、または自社Webアプリの脆弱性

    • HSSの管理または関連するWebサーバ（運用・開発用など）のいずれかが脆弱なバージョンであったと仮定。
    • 攻撃者が自動スキャン後、curl -F file=@shell.jsp …のような方法でWebシェルをアップロード、またはRCEエクスプロイトを使用。

  2. 低権限シェルの取得

    • Webサーバアカウント（tomcat、www-data）権限でシステム内部に侵入。
    • 攻撃者：uname -a、cat /etc/passwdなどで環境を調査 → 追加の権限昇格ルートを把握。

  3. root権限の取得

    • SUIDファイル、カーネルバグ、sudoの誤設定などを悪用 → root権限へ昇格。
    • ここでBPFDoorの設置が可能に（カーネルソケットフィルタの登録には高権限が必要）。

  4. BPFDoorのアップロード＆実行

    • /dev/shm/kdmtmpflushなどの一時ディレクトリにコピー → 元ファイルを削除。
    • バックドアプロセスが親プロセスから切り離されてメモリに常駐。
    • BPFフィルタ設定 → “マジックパケット”が到着したときだけシェル接続を開く。

  5. HSS DBへのアクセスとデータ窃取

    • BPFDoorを通じて攻撃者がいつでも再接続可能。
    • HSS内部DB（USIM認証キー、加入者IMSIなど）へ大量クエリ → 結果ファイルを流出。
    • 最終的にSKT顧客のUSIM情報が大規模に露出する事態に発展。

5. MITRE ATT&CKマッピング（Webシェル・RCEベース）

なぜMITRE ATT&CKにマッピングしたのか？

MITRE ATT&CKは世界中のセキュリティ専門家が攻撃者の戦術（Tactics）と技術（Techniques）を体系的に整理した知識ベースです。今回のSKTハッキング事例においてBPFDoorが最終的に設置・動作したとすれば、その前に**APT攻撃特有の複数段階（Webシェルアップロード、権限昇格、内部偵察など）**がすでに発生していた可能性が高いです。
実際、BPFDoorのような高度なバックドアは攻撃の終盤（後半段階）に投入されるケースが多く、
MITRE ATT&CKの観点では、初期侵入（Initial Access）→ 実行（Execution）→ 権限昇格（Privilege Escalation）→ …といった複数の戦術が使われるため、事前に複数のイベントを検知する機会があったということを意味します。

したがって、APT攻撃全体がどのような戦術・技術を通っていたかを標準化された方法で確認することで、

  1. BPFDoor設置前にすでに発生していた兆候（Webシェル、RCE攻撃、カーネル脆弱性の悪用など）を見逃していなかったかを確認し、
  2. 体系的な対応策（各段階ごとの検知・遮断）を準備することが不可欠です。
    このようにSKTハッキングとBPFDoorシナリオをMITRE ATT&CKにマッピングすることで、攻撃者の具体的行動（Webシェルアップロード、カーネル脆弱性の悪用、バックドアC2など）を戦術・技術ごとに分類し、事前の検知機会を最大化し再現性の高い防御戦略を立てることができます。

MITRE ATT&CKマッピングの3つの主な利点

  1. 客観的な基準

    • 攻撃の流れを明確に分類することで、「この攻撃がどの段階に属し、どの技術が使われたのか」を標準化された用語で説明できる。
    • APT攻撃が進行する際、「BPFDoor設置」の直前にもさまざまな指標が残されていた可能性があるため、見逃した警告サインを体系的に確認可能。

  2. セキュリティ運用の最適化

    • 各戦術・技術ごとに対応策が具体的に提示されており、組織のセキュリティロードマップ（防御戦略）策定の参考になる。
    • “Execution(T1059.004)段階でシェルコマンドが実行されたなら、EDRの動作監視は十分だったか？” など具体的な点検が可能に。

  3. 業界標準の遵守

    • APTレポートや侵害事案の分析時にMITRE ATT&CKマッピングは実質的に業界標準。他組織・事件との比較・分析がしやすく、情報共有も円滑。

5.1 BPFDoor攻撃グループとLoL（Living off the Land）技術

BPFDoorを使用するハッキンググループは主に中国系APTグループに分類され、代表的にはAPT27（Emissary Panda）が報告されています。
彼らは検知回避と隠密な長期潜伏のためにLoL（Living off the Land）技術を広範囲に活用しています。

以下の表は、MITRE ATT&CKフレームワークに基づき、BPFDoor関連の攻撃グループが頻繁に用いるLoL技術を要約したものです。

MITRE ATT&CKベースのLoL技術（BPFDoor関連）

Tactic（戦術） Technique（技術） ID 説明
Execution（実行） Command and Scripting Interpreter: Bash T1059.004 Bashシェルによるコマンド実行
Command and Scripting Interpreter: PowerShell T1059.001 PowerShellでメモリ上のマルウェアを実行（Windows時）
Persistence（永続性） Modify System Binary T1543.003 システムバイナリの改変またはサービス登録
Privilege Escalation（権限昇格） Sudo and Sudo Caching T1548.003 正規の権限昇格ツールの悪用
Defense Evasion（検知回避） Masquerading T1036 正常なプロセス名に偽装（例：sshd、syslogdなど）
Obfuscated Files or Information T1027 難読化/暗号化されたスクリプト、実行ファイルの使用

5.2 BPFDoor TIDベースの検知フィルター設計

前節で示したLoL技術と戦術の流れを基に、実際の運用環境でBPFDoorの隠密な動作を特定するための検知フィルターを設計しました。

BPFDoorは多様な攻撃技術を組み合わせてLinuxシステム内で隠密に動作するため、MITRE ATT&CKフレームワークのTID（Technique ID）を基準に特徴と一致する挙動を分類し、それに対応するフィルターを構成しました。

このフィルターは単なるシグネチャ検知を超え、攻撃者の行動パターン（TTP）に基づいたログ分析と挙動ベースの検知を併用できるように設計されています。以下は、実際にBPFDoorを検知するために構成された主なフィルター一覧と、その技術にマッピングされたTIDです。

フィルター名 マッピングTID マッピング理由の説明
BPFDoor_リバースシェル T1059.004（Unix Shell） "Initiated=false" + sshd + 特定内部IPへのリバース接続試行 → BPFDoorのRC4認証後のリバースシェル機能に一致。実際のシェル実行に該当し、Unix Shellとして分類。
BPFDoorファイル削除 T1070.004（File Deletion） 攻撃者が痕跡を消すためにrmコマンドで実行ファイル等を削除 → 痕跡除去のためのファイル削除に該当。
BPFDoorプロセス T1036.011（Masquerading: Overwrite Process Arguments） console-kit-daemon、udevd等、正常なデーモン名に偽装したプロセス → プロセス引数を偽装するTTPに該当。
BPFDoor初期化実行 T1036.009（Masquerading: Break Process Trees） --initフラグの使用は親プロセスをinitに変更して解析回避を試みる → PPID断絶動作。
BPFDoor偽装プロセス T1036.011（Masquerading: Overwrite Process Arguments） qmgr -l -t fifo -uはPostfixの正常プロセスを模倣した文字列引数 → プロセス偽装。
BPFDoor環境変数設定 T1562.003（Impair Command History Logging） HISTFILE=/dev/nullパスを含む環境変数設定 → コマンド履歴の記録防止が目的。
BPFDoorファイル削除（hexベース） T1070.004（File Deletion） Base16でエンコードされたrm -f /var/run/haldrund.pid → 削除を隠蔽して実行 → 痕跡除去目的の隠された削除。
BPFDoorファイル生成 T1480.002（Execution Guardrails: Mutual Exclusion） BPFDoorは/var/run/kdevrund.pid、/var/run/haldrund.pid、/var/run/syslogd.reboot、/var/run/xinetd.lockなどのファイルを多重実行防止のために生成

これらのフィルターは、実際に解析されたBPFDoorサンプルの動作と、システムログで現れたパターンに基づいて作成されており、ログベースの検知と挙動ベースの整合性検証を同時に実施できるように設計されています。

⚠️ 注意： 検知フィルターの具体的な正規表現やブロックコマンドはセキュリティ上の理由から非公開とし、本ドキュメントでは検知戦略の概念的アプローチのみを説明します。

このようにして、単一イベントではなくTTPの組み合わせを検知できる高度なフィルタリング体系を構築し、実際の運用環境ではこのマッピングベースの検知により隠密なバックドアの動作を効果的に特定することができました。

5.3 TIDベースの検知フィルターとリアルタイムEDR連携

前述のBPFDoorに関するTIDマッピングに基づいて設計された検知フィルターは、EDRと連携してリアルタイム対応が可能な構成となっています。フィルターによって疑わしい動作が検知されると、次のような方式で即時対応が行われるように構成されました。

  • 一時ファイルおよびPIDファイルの生成に対する対応

BPFDoorは感染後、/dev/shm、/var/runなどのディレクトリに一時実行ファイルやPIDファイルを生成し、多重実行を防止し、実行状態を隠蔽しようとします。これらのファイルは通常のシステム運用中に生成されるファイルと類似した形式を取るため、単純なパスベースのフィルタリングでは検知が困難です。

これに対して、以下の条件に基づいた検知および自動遮断ロジックを適用しました：

  • 特定のパスに存在する疑わしいファイル名パターンがログに現れた場合、

  • 該当ファイルを自動的にバックアップし、直ちに削除、

  • 事後分析を支援しつつ、感染拡散を事前に遮断できるよう構成。

  • 偽装プロセスの検知および終了

BPFDoorはシステム内でconsole-kit-daemon、udevd、hald-runnerなどの正常なデーモンプロセスを偽装して実行されます。一見すると正常プロセスに見えるが、コマンドライン引数や実行パスを分析することで異常なパターンを特定できます。

以下の条件に基づいて、検知および対応が行えるように設計しました：

  • 疑わしいプロセス名とコマンドライン引数が特定のパターンと一致する場合に検知

  • ログから該当プロセスのPIDを自動抽出し、

  • リアルタイムで終了スクリプトを実行して隠蔽された悪性プロセスを即座に遮断

  • 正常プロセスに偽装した実行の遮断

BPFDoorはqmgr -l -t fifo -uのようなコマンドライン引数を使用し、実際のPostfix構成要素のように見せかける偽装方式も活用します。このような偽装は表面的には正常なコマンドに見えるため、一般的な検知基準では回避されやすくなります。

これに対して、次のような検知および遮断手順を構成しました：

  • 実行中のプロセスリストから、正規表現ベースで偽装された引数パターンを検知

  • 一致する項目のPIDを自動抽出し、

  • 該当プロセスを即時終了させて後続の悪性動作を根本的に遮断

  • 非対称暗号通信によるデータ流出の遮断

BPFDoorはscp、sftpなどの非C2プロトコルベースの転送ツールを悪用して外部にデータを流出させる手法を使用することがあります。これらのコマンドはSSHベースの非対称暗号を活用するため、セキュリティ機器による内容分析が困難であり、プレーンテキスト検知やトラフィック分析の回避が可能です。

特にscpは運用環境でも正常に頻繁に使用されるため、単純なコマンド検知基準だけでは誤検知の可能性が非常に高くなります。このため、実行パス、コマンド引数、呼び出しパターンに基づいた正規表現による精密な検知ロジックが必要です。

以下の検知および遮断手順を構成しました：

  • ログ内でscp、sftpなどのコマンドが異常なパスから呼び出されるパターンを検知（例：/usr/bin/scp以外からの呼び出しなど）
  • 正規表現条件と一致するコマンドライン引数が存在する場合にプロセスIDを自動抽出
  • 検知されたプロセスを即座に終了させ、データ流出行為を事前に遮断

このように、BPFDoorの隠蔽された動作に対応する検知フィルターとリアルタイム遮断体系をMITRE ATT&CKの戦術・技術に基づいて構成することで、単一イベントではなく**攻撃者の行動全体（TTP）**を識別する高度な対応が可能になります。

これを通じて、**BPFDoor設置以前の初期侵入段階においても多数の検知機会が存在していたことが確認でき、**各検知要素はATT&CKマッピングを通じて体系的に分類・対応可能となります。

まとめ：MITRE ATT&CKマッピングの意義

  • BPFDoorが設置・活動していたとすれば、その前段階（Webシェルのアップロード、OSコマンドの実行、権限昇格など）においても十分に検知可能なイベントが発生していた可能性が高いです。
  • MITRE ATT&CKはこれら一連の段階を標準化し、組織のセキュリティチームが見落としたり脆弱だった箇所を迅速に把握・改善することを助けます。
  • 最終的にBPFDoorを防ぐことも重要ですが、初期侵入（Initial Access）と実行（Execution）を事前に遮断できていれば、被害を大幅に抑えることができたという観点から、MITRE ATT&CKマッピングには大きな価値があります。

6. セキュリティチームのための現実的な対応戦略（Web攻撃の観点）

一般的には、Webアプリケーションのセキュリティ強化、WAF設定、サーバハードニング、BPFDoorの検知・遮断、インシデント対応プロセスの整備という5つの方法論が標準的な対策として提示されます。
しかし、実際の企業・機関において情報セキュリティ専任体制を構築するのは容易ではありません。開発者・運用担当者・セキュリティ担当者がそれぞれ異なる優先順位を持ち、人員や予算が不足している状況では、以下のような現実的な困難が生じます。

参考： MITRE ATT&CKの観点から見ると、BPFDoorが最終的に設置・動作する前段階（Initial Access、Execution、Privilege Escalationなど）において、十分に検知可能なイベントが発生していたはずです。
にもかかわらずセキュリティチームがそれを見逃したということは、以下のような現実的な要因—人手不足、部門間の優先順位の衝突、ソリューションの放置—が原因でAPT攻撃の流れを感知・遮断できなかったことを示唆しています。

1) 情報セキュリティ運用の現実的困難

  • 現場の人員不足
    多くのIT部門が開発、インフラ運用、ユーザーサポートなどに過度に集中しており、「セキュリティ専任チーム」を別途設けるのは困難です。攻撃の兆候があっても、即時のモニタリングや対応がなされにくいのが実情です。

  • 機器・ソリューション導入後の放置
    WAF、IDSなどの機器を導入していても、ルールの更新やログ分析が適時行われなければ意味がありません。攻撃者は最新のRCE脆弱性を活用しますが、組織は6ヶ月前のシグネチャにとどまっているケースが少なくありません。

    • MITRE ATT&CKの示唆：Initial Access（TA0001）段階で多くの攻撃試行がログに記録されていたはずですが、ソリューションが適切に運用されておらず、検知や分析が行われなかった可能性があります。

  • Webアプリケーションのアップデート頻度
    WebLogic、Tomcat、CMSなどはパッチの頻度が高く、「Nデイ脆弱性」が突然発覚することもあります。IT人員が不足していると、こうしたアップデートに追いつけません。

    • MITRE ATT&CKの示唆：攻撃者がT1190（Exploit Public-Facing Application）を利用していた場合、パッチ未適用が主な原因だった可能性があります。

2) セキュリティ担当者 vs. システム運用・開発者の優先順位の不一致

  • 開発スケジュール vs. セキュリティチェック
    開発者は機能実装とリリース速度を重視しますが、セキュリティ担当者は「コードレビュー、侵入テスト、アップロードフィルタリング」などを求めることがあります。リリーススケジュールが逼迫すると、セキュリティチェックは後回しにされたり省略されます。

    • MITRE ATT&CKの示唆：例えばWebシェルアップロードシナリオ（T1190のサブ）を防ぐにはアップロードフィルタやWAFルールの整備が必要ですが、開発スケジュールの優先度によって適用されなかった可能性があります。

  • サービス可用性 vs. ハードニング
    運用担当者は「サービス停止なしの24/7稼働」を目標としますが、セキュリティ担当者は「SELinuxの強化や/dev/shmのnoexecオプション」などのハードニングを重視します。ハードニングは互換性問題を引き起こす可能性があり、衝突が生じます。

    • MITRE ATT&CKの示唆：Persistence（TA0003）の観点では、/dev/shmにnoexecオプションが適用されていれば、BPFDoorのファイルは実行されなかった可能性があります。

  • 機器ポリシーの衝突
    WAFのルールを厳しく設定すると正常なトラフィックまで遮断され、運用部門から不満が出ます。逆にルールを緩めると脆弱性が拡大します。こうした意見の相違を毎回手動で調整するには、時間と専門性が不足しています。

    • MITRE ATT&CKの示唆：Execution（TA0002）段階で疑わしいコマンドパターンをWAFが遮断すべきだったが、緩いルール設定により見逃された可能性があります。

3) 多層・多段防御、かえって逆効果になることもある

「セキュリティ製品は多いほどよい」という考えで、さまざまなセキュリティ製品（WAF、IDS、IPS、EDR、NDRなど）を重ねて導入するケースがあります。
しかし、複雑さが増すほど、システム全体の動作原理を完全に理解している人がいなくなる状況が発生します。
その結果、セキュリティのための設計がかえってセキュリティの盲点を生むという皮肉な現象が起こります。

  1. 製品間の衝突・非効率

    • 製品ごとにAPI連携やログ形式が異なるため、一貫した監視が困難。
    • アラート（イベント）管理が重複・分散され、本当に重要な脅威のサインを見逃す可能性が高まります。

  2. パフォーマンス負荷・予算分散

    • 複数のエージェントを導入すると、サーバリソースが過剰に消費され、ライセンス・保守費用が重複して発生。
    • 結果として、重要資産を守るための核心的な能力に、十分な予算と人員を投資できなくなります。

  3. アラート疲労（Alert Fatigue）

    • 複数のソリューションが同時にアラートを発すると、セキュリティ担当者は誤検知まで含めてすべてを確認せねばならず、業務過多と集中力の低下につながります。
    • 結局、実際の侵入試行（T1190、T1059.004など）への対応が遅れるリスクが高まります。

結論：
多層・多段防御モデルが常に悪い選択肢とは限りません。
しかし、その限界・コスト・人材負荷を明確に認識し、それを統合ソリューションで補完する戦略が不可欠です。

このようにセキュリティソリューションが分散されていると、一貫した監視と即時対応が実質的に不可能となり、
結果としてAPT攻撃の初期イベント（Webシェルのアップロード・RCEなど）すら見逃す危険性が高くなります。

したがって、限られた人員と予算で実効的な防御能力を確保するためには、多層・多段防御よりも“統合”を軸とした戦略をまず検討すべきです。

💡 結局、統合情報セキュリティプラットフォーム（PLURA-XDR）の導入が正しい選択

このような人材・時間・専門性の限界や部門間の意見の衝突によって、APT攻撃の初期段階（Webシェルのアップロード、権限昇格など）で十分な検知機会を逃してしまうと、BPFDoorのようなステルスバックドアが最終的に設置される時点では、すでに大きな被害が出ている可能性があります。
これを防ぐには、複数のセキュリティ機能を単一のプラットフォーム上で統合的に運用・管理できる統合情報セキュリティプラットフォームが不可欠です。特に、PLURA-XDR（Extended Detection & Response）が最良の選択肢です。

以下は、PLURA-XDRがWAFポリシーが緩い環境下においても、初期段階の攻撃をどのように補完・検知できるかを強調した例文です。「理論上、今回の攻撃も初期から検知できたはずだ」というメッセージを含み、MITRE ATT&CKの観点からPLURA-XDRが事前に把握可能である理由を具体的に説明しています。

要するに、PLURA-XDRのような統合プラットフォームは、既存の分散されたセキュリティソリューションによって発生するサイロ（Silo）問題や専門人材の不足を克服します。情報セキュリティ担当者が1〜2名しかいない環境でも、多様な攻撃ベクター（Webシェル、RCE、権限昇格、ファイル整合性の破壊など）をリアルタイムでモニタリング・遮断できるため、MITRE ATT&CKの観点からさまざまな攻撃段階を事前に認知でき、実際のセキュリティレベルも体感的に向上します。

特に、WAFポリシーが緩い、あるいはルールの更新が遅れてファイルアップロード攻撃やRCEペイロードをブロックできない状況でも、PLURA-XDRはWebリクエスト本文（HTTP Body）とサーバ内部の挙動（EDR）を挙動ベースで連携分析することで、初期侵入（Initial Access）の時点から異常兆候を検出する可能性が高まります。
たとえば：

  1. Webサーバログで「shell.jspのアップロード」といったパターンを検出、
  2. 続いて**shell_exec()**やsystem()の呼び出しが発生、
  3. プロセス生成イベント（リアルタイムEDR）で**権限昇格（T1068）**の試行が観察される

といったように、APT攻撃の流れを段階ごとに捕捉できます。
結果として、MITRE ATT&CK上のExecution（TA0002）やPrivilege Escalation（TA0004）段階ですでに警告を発生させることが可能であり、BPFDoorが設置されるPersistence（TA0003）段階以前に正確な検知ができた可能性が十分にあります。

まとめ： PLURA-XDRは、WAFやIPSが見逃しがちな初期攻撃（RCEやWebシェルアップロード）すら統合的に検知してくれるため、「理論上、今回の攻撃も初期段階から追跡できたはずだ」と評価できます。
もしPLURA-XDRが導入・運用されていたなら、Webシェルの呼び出し痕跡や権限昇格の試みを段階ごとにアラートで把握し、BPFDoorのようなステルスバックドアが設置される前に先手を打った可能性が高いでしょう。

結論

  • IT現場において、Web攻撃の防御（アプリケーションセキュリティ、WAF設定、ハードニング、バックドア検知、インシデント対応プロセス）という標準手法は重要ですが、現実的な人員・予算・組織構造を考慮すると容易ではありません。
  • MITRE ATT&CKの初期侵入〜展開段階においてすでに多くの兆候があったにもかかわらず、セキュリティチームがそれを見逃していたとすれば、それは部門間の優先順位の不一致やソリューション運用の不備が原因である可能性があります。
  • 統合情報セキュリティプラットフォームがそのギャップを埋めることができます。PLURA-XDRを通じて、Webシェル・RCE攻撃からBPFDoorのようなステルスバックドアの検知まで、単一インターフェースで一貫して管理することが究極的な解決策といえるでしょう。

7. PLURA-XDR 統合情報セキュリティプラットフォーム：Webリクエスト本文分析による追加防御

前述のWeb攻撃対応戦略（Webアプリケーションのセキュリティ強化、WAF活用、サーバハードニング、BPFDoor検知/遮断、インシデント対応プロセスの確立）だけでも基本的な防御体制は構築可能です。
しかし最近のAPT攻撃では、Webリクエストを巧妙に偽装したりファイルアップロードを暗号化することで、従来のルールベースソリューション（WAF、IPS）を回避する事例が増えています。
このとき、Webリクエスト本文（HTTP Body）まで分析できるPLURA-XDRのような統合セキュリティプラットフォームが非常に有効です。

7.1 PLURA-XDRの主な機能

  1. 多層イベント連携（Extended Detection & Response）

    • PLURA-XDRは、ネットワーク、エンドポイント、クラウド、Webトラフィックなどの多様なイベントを統合分析し、断片的な兆候ではなく行動ベース（Behavior-based）の相関関係によって攻撃を特定します。
    • 例：WebサーバのHTTP Body異常 + /dev/shm内のマルウェア実行 + 特定C2 IPへの接続が連鎖して検知された場合、高リスク攻撃と判断して即時アラートを発生。

  2. HTTP Body/Payloadの高度な分析

    • 通常のWAF/IPSはURI、ヘッダー、クッキー中心で検査しますが、PLURA-XDRはHTTP Body（ファイルアップロード、POSTデータ）の内容を深く解析し、疑わしいコマンドやWebシェルコードを特定できます。
    • 例：Base64でエンコードされたJSP Webシェルのスニペットや、スクリプトと疑われる難読化文字列が含まれているかどうかをAI・パターンマッチングでリアルタイム検知。

  3. ゼロデイ脅威の検知（行動ベースルール）

    • シグネチャベースを超え、「POSTボディにシェルコマンドパターンが見られる」、「アップロードされたファイルにJSP/PHP構文がある」などの行動ベースルールを設定可能。
    • WebシェルやRCEの脆弱性が未公開でも、PLURA-XDRはコマンドパターン／プロセス実行フローから異常を検出し、先制遮断が可能です。

  4. 自動対応（Automated Response）

    • 高リスクイベント（例：shell.jspのアップロード試行＋サーバ内のシェル実行）が検知された場合、PLURA-XDRはIP自動遮断、プロセス隔離、通知送信などを自動で実施。
    • セキュリティ人員が24時間常時監視できない環境でも、即時防御が可能です。

7.2 Webリクエスト本文分析が重要な理由

  • ファイルアップロード型Webシェル：一般的なWAFが拡張子.jsp、.phpのみをチェックする場合、攻撃者は.jpgなどに偽装し、BodyにJSPコードを含めて通過可能。PLURA-XDRはBodyの中身を開いてスクリプト/コマンドパターンを検出できます。
  • 複雑なRCEペイロード：攻撃者はLog4Shellなどの脆弱性を狙う際、JNDI URLや逆シリアライズペイロードをBodyに隠して送信します。このときPLURA-XDRは多段階分析でRequest Bodyに隠された改ざんオブジェクトや難読化文字列を認識します。
  • HTTP/2、SSL、HTTP Chunkedなどのプロトコル変種にも対応：PLURA-XDRはSSL/TLSトラフィックの復号やHTTP仕様の変種処理にも対応し、特殊エンコーディングを用いた回避手法も見逃しません。

7.3 PLURA-XDR導入時の期待効果

  1. Webシェル・RCEのリアルタイム検知および遮断

    • 既存のWAFとは異なり、深層本文分析＋行動ベースルールの組み合わせで、疑わしいアップロードや特定コマンド挿入シナリオを即時遮断。
    • Webシェルがアップロードされても、PLURA-XDRはサーバのエンドポイント（EPP/EDR）と連携してプロセス実行をリアルタイム監視し、追加のroot権限取得の試みも検出。

  2. BPFDoorのような隠密バックドアの検知

    • BPFDoorはカーネルレベルのBPFソケットフィルタを使用しますが、C2通信自体はICMP/TCPで発生。PLURA-XDRはネットワークトラフィック＋ホストプロセスの動作を統合分析して、隠されたC2活動を明らかにします。
    • 例：iptablesルールが一時的に変更され（Host EDRイベント）、その直後に特定のICMP Pingにパケットが挿入される流れ（Network D&Rイベント）を連携して認識。

  3. 包括的な脅威インテリジェンスの適用

    • PLURA-XDRはセキュリティ情報（SIEM）と脅威インテリジェンス（Threat Intelligence）を統合管理し、BPFDoorのIOC（マジックバイト、C2 IPなど）や最新のRCEエクスプロイトパターンを自動更新して迅速に防御。

  4. 自動化されたフォレンジックおよびレポート機能

    • インシデントが疑われる時点で、PLURA-XDRコンソールから関連イベント（HTTPリクエスト、ファイル実行、プロセス生成、ネットワーク接続）を自動収集・可視化。
    • 事件発生直後に攻撃経路の再現や情報流出範囲の推定が可能になり、対応時間が大幅に短縮。

7.4 まとめ：PLURA-XDRによるWeb攻撃防御体制のアップグレード

  • PLURA-XDRは既存のWAF、IPS、EDRなどを統合するプラットフォームで、Webリクエスト本文分析のような高度な機能によって、Webシェル・RCE攻撃を精密に遮断します。
  • 特に分離ネットワーク環境で80/443ポートが開いている場合（2023年1月、LGU+のWebシェル使用事例のように）、PLURA-XDRがWebトラフィックを徹底検査することで侵入口を封鎖可能です。
  • 追加のカーネル・エンドポイント監視（BPFDoorやルートキットの検知）、自動化されたインシデント対応（IP遮断、プロセス隔離）機能も提供するため、APTレベルの攻撃に対して強力な防御効果が期待されます。

結論として、PLURA-XDRのような統合情報セキュリティプラットフォームを用いてWebトラフィック本文分析（Body Inspection）を行うことで、Webシェル・RCE攻撃の隠れたペイロードを見つけやすくなり、実際のサーバ内で発生する挙動（バックドアの設置、システムコマンドの実行など）まで連携して監視できます。
これは、SKTハッキング事件のようなBPFDoorなどの高度なAPT攻撃を防ぐための実効的な防御力につながります。

8. 結論

  • 今回のSKTハッキング事例をWeb攻撃（Webシェル・RCE）中心で解釈すると、攻撃者はインターネットに公開されたWebサービスを足がかりにHSSサーバへ侵入し、BPFDoorを設置して長期的な拠点を確保した可能性が高いです。
  • 分離ネットワーク環境でも80/443 Webポートはほぼ唯一の経路：2023年1月のLGU+ハッキングではWebシェル使用の事例があり、DMZから内部ネットワークへの接続はWebサービス（80/443）に限られるケースが多く、これが攻撃者がWebシェル・RCEを狙って侵入・ラテラルムーブメントを行う主な理由となります。
  • BPFDoorはその後の隠密手段：Webベースの初期侵入で得た低権限シェルからroot権限を取得し、BPFDoorを投入することでステルス性と持続性を最大化したのです。

仮説的結論:

  1. SKT HSSサーバはWebシェルまたはRCEによって初期侵入され、
  2. BPFDoorにより密かにC2が構築され、
  3. USIM/加入者データの流出につながった可能性が非常に高い。
    別の経路（アカウント乗っ取り、内部関与など）も否定はできませんが、Web攻撃が最も一般的な侵入ベクトルであることを考慮すれば、本シナリオは十分合理的です。

今後の検証の必要性:

  • 実際のログ・フォレンジック情報の追加公開がなければ最終的な侵入経路は確定できませんが、
  • 企業ネットワーク侵害の大半はWeb攻撃であるという業界の経験則を踏まえると、本仮説が正しい確率はかなり高いと言えます。

MITRE ATT&CKの観点で、戦術・技術別の対応システム（Webリクエスト本文分析、イベントログ追跡、権限昇格の監視など）を事前に構築していなかったことが、今回の攻撃を初期侵入〜BPFDoor設置段階で阻止できなかった決定的要因だと考えられます。
もしセキュリティチームがPLURA-XDRのような統合セキュリティプラットフォームを導入し、Webリクエスト本文からATT&CK戦術・技術までを連携監視し、低権限シェルの取得（Execution）や権限昇格（Privilege Escalation）といった中間イベントをリアルタイムで監視していれば、BPFDoorのステルスバックドアが設置される前に十分に警告を受けて対応できたでしょう。

最終提言

  • WebシェルおよびRCE攻撃が大規模インシデントの主力侵入経路であるという前提のもと、企業・機関はWeb脆弱性管理、ファイルアップロード制御、WAF運用などを最優先のセキュリティ課題とすべきです。
  • 侵入後にBPFDoorのようなステルスバックドアが設置されると検知・遮断が非常に困難になるため、初期侵入そのものを防ぐことが最も効果的な対策です。
  • 侵入が検知された場合はメモリベースのフォレンジックおよび挙動モニタリングによって、BPFDoorや類似マルウェアの隠蔽を徹底的に調査すべきです。
  • PLURA-XDRのような統合セキュリティプラットフォームを導入すれば、Webリクエスト本文の分析に加えてMITRE ATT&CK段階別検知との連携もリアルタイムで可能となり、初期のWebシェル・RCE攻撃を遮断しBPFDoor設置前に警告を受けることができます。
  • 今回のSKT事件を教訓に、重要サーバ（特に通信・金融・公共インフラなど）に対するWeb攻撃防御とLinuxセキュリティ強化の必要性を改めて認識すべきです。

📺 一緒に見る

📖 関連資料を読む

🆙 PLURAアップデート情報

Tags