Falco Feedsは、オープンソースに焦点を当てた企業に、新しい脅威が発見されると継続的に更新される専門家が作成したルールにアクセスできるようにすることで、Falcoの力を拡大します。
現代のクラウドネイティブ環境において、SREやPlatformエンジニアが警戒すべき脅威は、IAMの侵害、設定ミス、Secretsの漏えい、サプライチェーン攻撃など多岐にわたります。
そのなかでも、検知をすり抜けて侵害を継続させる高度な攻撃者が利用する代表的な回避手法の一つが、「システムコール回避（Syscall Evasion）」です。
システムコール回避は、日常的な設定ミスや脆弱性ほど頻繁に遭遇するものではありません。しかし、いざ使われると既存の監視では気づけない可能性が高く、対応難易度が大きく上がります。攻撃者にとっては、検知を避けながら侵害を継続し、権限昇格や横展開へ進むための重要な手段になります。
本稿では、攻撃者がどのようにセキュリティツールの監視をすり抜けるのか、その手法と実例を技術的に解説します。特定製品の単純な優劣ではなく、「監視レイヤーそのものに生じる死角」という構造的な問題を、SRE／Platformエンジニアの視点から整理します。
あなたが前提としている「監視」は、すでに攻撃者に織り込まれている
- 「AWS GuardDutyを入れているから安心だ」
- 「GCP Security Command Centerでログは取れている」
- 「Falcoでランタイム検知をしている」
もしこのように考えているなら、その前提自体が攻撃者に織り込まれている可能性があります。
近年の攻撃者は、OSの標準的な監視ポイントであるlibcや、従来型のシステムコールフックを巧妙に回避します。AWS GuardDuty、GCP Security Command Center、Container Insights、GuardDuty Runtime Monitoringなど、クラウド標準ツールもランタイム可視化に向けて進化しています。しかし、ログベースの監視やサンプリングされたメトリクスを前提とする限り、「実行中のコンテナ内部で何が起きているか」をリアルタイムに、かつ攻撃者の隠蔽手法を見抜ける粒度で把握することは簡単ではありません。
問題は、監視ツールが不足していることではありません。
問題は、「どのレイヤーまで見えているのか」「どの経路が監視対象から外れているのか」を把握しないまま、監視できていると考えてしまうことにあります。
システムコール回避攻撃の実態
多くのRuntime Securityツールは、Linuxカーネルのシステムコール（Syscall）を監視することで、プロセスの挙動を検知します。たとえば、ファイルへの書き込み、ネットワーク接続、プロセス起動、権限変更などの操作は、システムコールを通じてカーネルに要求されます。
そのため、システムコールを監視できれば、コンテナやホスト上で何が起きているかを高い粒度で把握できます。しかし攻撃者は、この「監視ポイント」を回避する手法を開発しています。代表的な手法は次のとおりです。
Direct Syscalls / Bypassing C Library
通常、プログラムはlibcなどの標準ライブラリを介してシステムコールを呼び出します。しかし攻撃者は、標準ライブラリをバイパスし、直接アセンブリでシステムコールを発行することで、ユーザー空間に仕掛けられたフックを回避できます。ユーザー空間での監視に依存している場合、この種の直接呼び出しは検知の死角になり得ます。
出所：Ghosts in the Endpoint: How Attackers Evade Modern EDR Solutions | by Mat Cyb3rF0x Fuchs | Medium
io_uringの悪用
io_uringは、高速なI/O処理を実現するLinuxの比較的新しい機能です。従来のシステムコールとは異なる経路でカーネルと通信できるため、既存の監視ツールがこのインターフェースに十分対応していない場合、ファイル操作やソケット通信が検知されにくくなる可能性があります。
io_uringは本来、性能向上のための正当なカーネル機能です。しかし、攻撃者がこれを悪用すれば、従来のシステムコール監視を前提とした検知を回避する手段になります。
出所：io_uringを悪用したマルウェアの検知と緩和 | Sysdig
vDSO Hijacking
vDSO（virtual Dynamic Shared Object）は、カーネルがユーザー空間に提供する仕組みです。攻撃者がvDSOを改ざんできれば、通常の監視経路を避けながらコード実行や挙動の隠蔽を試みることができます。これはプロセスインジェクションの一種として整理されており、MITRE ATT&CKでも関連する攻撃手法として扱われています。
出所：Process Injection: VDSO Hijacking, Sub-technique T1055.014 - Enterprise | MITRE ATT&CK®
具体的なマルウェア・攻撃事例
システムコール回避や監視バイパスは、研究上の概念にとどまりません。実際の攻撃やPoCでも、既存の検知ツールを回避する手法が確認されています。
io_uring悪用のPoC
2025年には、ARMOがcuringと呼ばれるPoCルートキットを公開し、Falco、Tetragon、Microsoft Defenderといったツールがio_uring経由の操作を検知しきれないことを実証しました（Falcoはデフォルトでは盲点、Tetragonは手動でKprobes/LSMフックを設定すれば検知可能）。なお、その後Falcoはio_uringを観測するネイティブ機能を追加しています。
出所：Linux io_uring PoC Rootkit Bypasses System Call-Based Threat Detection Tools
Living-off-the-Land（LotL）
Living-off-the-Landは、攻撃者が新しいマルウェアを大量に持ち込むのではなく、OSや環境に元から存在する正規ツールを悪用する手法です。zshなどのシェル、標準コマンド、管理ツールを組み合わせることで、悪意ある活動を「正規の操作」に見せかけます。
この種の攻撃では、単に不審なバイナリを探すだけでは不十分です。プロセスの親子関係、実行コンテキスト、引数、通信先、ファイル操作などを組み合わせて判断する必要があります。
出所：Identifying and Mitigating Living Off the Land Techniques | Cyber.gov.au
監視ツール／オブザーバビリティツールにおける検知性の違い
SREやエンジニアが日常的に利用するセキュリティツールやオブザーバビリティツールは、それぞれ監視できるレイヤーと検知可能な範囲が異なります。重要なのは、「どのツールが優れているか」ではなく、「どのレイヤーを見ていて、どこに死角が残るのか」を理解することです。
AWS/GCP標準ツール
AWS GuardDutyやGCP Security Command Centerは、主にクラウドAPI、ネットワークログ、リソース設定、クラウドサービス上の不審な挙動を監視するためのツールです。クラウドリソースの異常操作、疑わしい通信、既知の脅威インジケータを把握するうえでは非常に有効です。
近年は、AWS GuardDuty Runtime Monitoringや、GCP Security Command CenterのContainer Threat Detectionのように、クラウド標準ツール側もランタイム可視化に踏み込んでいます。GuardDuty Runtime Monitoringでは、eBPFベースのセキュリティエージェントを通じて、プロセス実行やファイルアクセスといった挙動を捉えることができます。
したがって、「クラウド標準ツールはランタイムをまったく見ていない」という理解は、現在では正確ではありません。
ただし、これらのマネージドな検知は、クラウドベンダーが提供するルールセットや検知ロジックに依存します。io_uringのような新しいカーネル機構や、Direct Syscallsによるフック回避といった最新の回避手法にどこまで追従できるかは、ベンダー側の対応速度に左右されます。また、利用者が独自にルールを細かく拡張・チューニングできる範囲にも限界があります。
そのため、典型的なランタイム脅威の検知には有効であっても、コンテナ内部で進行する高度な回避攻撃を、十分な粒度と前後関係まで含めて捉えるには死角が残ります。
OpenTelemetry / Prometheusなどのオブザーバビリティツール
OpenTelemetryやPrometheusなどのオブザーバビリティツールは、メトリクス、ログ、トレースを通じて、システムのパフォーマンスや可用性を把握するために使われます。
これらは、SREにとって欠かせない基盤です。レイテンシ、エラーレート、リソース使用率、サービス間の依存関係を把握するうえで大きな価値があります。
一方で、これらは本質的に運用監視を目的としたツールです。攻撃者による回避行動、不審なプロセス実行、カーネルレベルの挙動、システムコール単位の操作を詳細に検知することには向いていません。
異常が発生した場合でも、「CPU使用率が上がった」「通信量が増えた」「エラーが増えた」といった間接的な兆候としてしか見えないケースがあります。攻撃者が正規コマンドを使い、正常な負荷の範囲内で活動している場合、オブザーバビリティだけで悪意ある挙動を見抜くことは困難です。
Falco（OSS）
Falcoは、eBPFやシステムコールを活用してカーネルレベルの挙動を監視できる、非常に優れたOSSのランタイムセキュリティツールです。ファイル操作、プロセス実行、ネットワーク接続などの不審な挙動を検知できる点は大きな強みです。
ここで論点になるのは、「Falcoに検知能力がない」ということではありません。
むしろFalcoは、クラウドネイティブ環境におけるランタイム検知の基盤として高い価値を持っています。課題は、その運用です。
OSSである以上、io_uringのような新しいカーネル機構や、次々に登場する回避手法への対応は、利用者自身によるルール管理、チューニング、アップデート運用に依存します。対応ルールの整備が追いつかなければ、その機構を経由する操作は死角になり得ます。
つまりFalcoは、「優秀だが、死角を埋め続ける運用負荷を誰が担うのか」という課題を伴うツールだと整理できます。
なぜ監視を増やしても死角は消えないのか
ここで重要なのは、ツールを増やせば死角が消えるわけではない、という点です。
クラウド標準ツール、オブザーバビリティツール、Falcoをすべて導入しても、それぞれが独立して別々のレイヤーを見ている限り、ツールとツールの「間」には死角が残ります。
たとえば、クラウドAPIログには現れず、オブザーバビリティ上も大きな異常として見えず、Falcoの既存ルールも通り抜ける経路があれば、攻撃者はその隙間を利用できます。
問題は、「検知機能があるかどうか」だけではありません。
より重要なのは、クラウドログ、ランタイムイベント、ワークロード内部の挙動を相関分析できるかどうかです。
個別ツールで監視点を増やしても、それぞれが分断されている限り、攻撃全体の流れは見えません。
どのAPIコールが発端となり、どのコンテナでどのプロセスが起動され、どのファイルに触れ、どこへ通信したのか。この一連の流れがつながらなければ、インシデント対応は断片的な調査にとどまります。
回避攻撃が成立するのは、まさにこの分断された監視点の隙間です。
だからこそ、回避攻撃や短命なコンテナ環境における可視性を最大化し、防御まで一貫して実現するには、カーネル、クラウド、アプリケーションを横断して監視し、レイヤーをまたいで相関分析できるプラットフォームが必要になります。
監視を「増やす」のではなく、分断された監視点を「つなぐ」ことが、死角解消の本質です。
ツール別に生じる「死角」
AWS/GCPの標準ツールは、クラウドAPI、ネットワーク、リソース設定など、インフラレイヤーの不審な挙動を把握するには有効です。一方で、コンテナ内部で進行する高度な回避攻撃や、システムコール単位の詳細な挙動までは十分にカバーしきれない場合があります。ここに第一の死角が生まれます。
オブザーバビリティツールは、可用性やパフォーマンスの把握に強みを持ちます。しかし、意図的に隠蔽された悪意ある挙動の検知には適していません。「正常に見える異常」は、運用指標の枠組みでは捕捉しにくいのです。
Falco（OSS）は高い検知能力を持つ一方で、io_uringなど新しいカーネル機構への継続的な対応が前提になります。対応ルールや運用体制が追いつかなければ、その機構を経由する操作が死角になる可能性があります。
つまり、それぞれのツールには明確な強みがあります。しかし、強みがあるからといって、すべてのレイヤーが見えているわけではありません。SREの観点では、「どのレイヤーまで見えているか」を把握することが、インシデント対応の精度と速度を左右します。
AWS GuardDuty Runtime Monitoringでも残る死角とは
「クラウド標準ツールでもランタイムは見られる」のは事実です。
では、AWS GuardDuty Runtime MonitoringやGCP Security Command Centerのランタイム脅威検知で何が見えて、何が見えにくいのかを整理すると、次のようになります。
典型的な不審挙動の検知には強みがあります。一方で、従来のシステムコール監視が想定する経路を迂回する回避手法は、検知ロジックの追従に依存します。
また、検知後にプロセスを即時停止することや、システムコール単位で活動を録画してフォレンジックに活用することは、マネージドサービスの守備範囲を超える場合があります。
つまり、「ランタイムをまったく見ていない」のではありません。典型的な脅威は見える一方で、回避攻撃、即時阻止、深い事後分析には死角が残る、というのが実態に近い評価です。
検知の死角はどこに生まれるのか
回避攻撃の本質は、「監視ポイントが置かれていない経路を通る」ことにあります。
Direct Syscallsは、ユーザー空間のフックを回避します。io_uringは、従来のシステムコール監視とは異なる経路を使います。vDSO Hijackingは、通常の追跡ポイントを避けながらコード実行や挙動の隠蔽を試みます。
これらに共通するのは、監視センサーが配置されている地点を避けて通る、という点です。
つまり、検知の死角は単なる「ツールの性能不足」ではありません。カーネルのどこにセンサーを差し込み、どの経路を観測できているかというアーキテクチャの問題です。
ログベースの監視は、事後に残った痕跡に依存します。ユーザー空間のフックは、ユーザー空間でバイパスされる可能性があります。特定のシステムコールだけを見るルールは、別経路を使われると見落とす可能性があります。
この死角を塞ぐには、システムコールを単に「見る」だけでは不十分です。前後関係、パラメータ、実行コンテキスト、プロセスの親子関係、コンテナやクラウドリソースとの関連まで含めて、eBPFを通じてカーネルレベルで横断的に観測する必要があります。
回避攻撃を前提とした防御に必要な4つの要件
ここまで見てきた死角を埋めるには、次の4つの要素が一つのプラットフォームに統合されていることが重要です。
1つ目は、カーネルレベルの可視化です。io_uringやDirect Syscallsを含め、監視経路を避ける活動まで捉えられる必要があります。
2つ目は、クラウドイベントとの相関分析です。クラウドAPIログ、ランタイムイベント、ワークロード内部の挙動をひも付け、攻撃全体の流れを再構成できなければなりません。
3つ目は、リアルタイム阻止です。検知した瞬間にプロセス単位でブロックし、被害の進行を止める仕組みが必要です。
4つ目は、事後フォレンジックです。システムコール単位で活動を記録し、攻撃者が痕跡を消そうとしても、後から何が起きたのかを再現できる必要があります。
これらが分断されている限り、監視点の「間」には死角が残ります。逆に言えば、4つを統合できて初めて、回避攻撃を前提とした防御が成立します。
Sysdig Secureは、これらの要件を一つのプラットフォームで提供します。
具体的には、Linuxカーネル技術に深くコミットし、io_uringを介した攻撃を検知するルールをいち早く実装したカーネルレベルの可視化に加え、ランタイムイベントとクラウドイベントを突き合わせる相関分析、検知した瞬間にプロセスを止めるリアルタイム阻止、そしてSysdig Captureによる事後フォレンジックまでを統合しています。
個別ツールでは分断されがちな可視化、検知、阻止、調査を一つの流れとして扱える点が、死角を最小化するうえでの重要な強みです。
「検知」だけでは死角は閉じない——阻止と巻き戻し
死角を技術的に塞いだとしても、検知した瞬間に止められなければ被害は進行します。
たとえば、実行中のコンテナに新しく持ち込まれたバイナリの実行を即座にブロックするDrift Controlや、異常なシステムコールパターンを検知した瞬間にプロセスを停止するProcess Terminationのような能動的対応が必要になります。
検知してから人が確認し、チケットを起票し、担当者が対応するまでの間に、攻撃者は認証情報を盗み、横展開し、データを外部へ送信しているかもしれません。
ランタイムセキュリティにおいて重要なのは、検知の精度だけではありません。検知から阻止までをどれだけ短時間で実行できるかが、被害範囲を大きく左右します。
さらに、攻撃者が痕跡を消そうとしても、システム全体の活動をSysdig Captureとしてキャプチャできれば、事後調査の精度が大きく変わります。
Sysdig Captureは、SCAP形式のトレースファイルです。ここでいうSCAPは、脆弱性管理規格のSCAP（Security Content Automation Protocol）とは異なり、システムコールやイベントを丸ごと記録するSysdig独自の「録画」ファイルを指します。
これにより、攻撃者がどのファイルを書き換え、どのコマンドを実行し、どの引数を渡し、どのC&Cサーバーと通信したのかを、事後に詳細に解析できます。
SREにとって、これはインシデント対応をブラックボックス化させないための重要な前提です。検知時点では断片的に見えていたイベントも、Sysdig Captureを使うことで、後から攻撃の流れとして再構成できます。
まとめ：SREとプラットフォームエンジニアへの提言
クラウドネイティブなインフラを構築・運用する立場にとって、カーネルレベルでの不可視性、つまり検知の死角は大きなリスクです。
標準のモニタリングツールやクラウド標準ツールで安心している間に、攻撃者はシステムコールを迂回し、正規コマンドを悪用し、監視の隙間で活動を続けているかもしれません。
ただし、システムコール回避は、それ自体が権限奪取を意味するわけではありません。システムコール回避の本質は、検知を逃れて侵害を継続させることにあります。見えないからこそ、次の攻撃ステップを許してしまう点に危険があります。
重要なのは、個々のツールの優劣を論じる前に、自分たちの監視がどのレイヤーに死角を残しているのかを構造的に把握することです。
クラウド標準ツールは、クラウドインフラの異常を捉えるうえで有効です。オブザーバビリティツールは、可用性や性能を守るうえで欠かせません。Falcoは、OSSのランタイム検知基盤として非常に優れています。
しかし、回避攻撃を前提に考えるなら、それぞれの監視点を分断したままでは不十分です。
カーネルからクラウド、アプリケーションまでを横断して観測し、検知、阻止、事後分析の各フェーズで死角を最小化すること。それが、見えない脅威を可視化し、確実に阻止するための防御戦略です。
次に読むべき記事
- コンテナランタイムセキュリティとは？Falcoによるリアルタイム検知の仕組み
- ランタイムセキュリティとは？
- CWPP（Cloud Workload Protection Platform）とは？
- CDR（Cloud Detection and Response）とは｜クラウドを守るリアルタイム防御とSysdigのアプローチ
- SREのアラート疲れを終わらせる：Critical脆弱性50件から本当に直すべきリスクを特定する方法
- DevSecOpsとコンテナセキュリティ｜SREが知っておくべき運用設計の考え方
- AIワークロードのコンテナセキュリティ｜LLM・GPU環境を守る新しい視点
- CNAPPとは何か？クラウドネイティブ時代に求められるセキュリティの新常識
- クラウドセキュリティ完全ガイド｜「Code to Runtime」で守るには