切られたしっぽ

産業廃棄物の投下場所

「2024年も始まったしそろそろマルウェアの勉強を始めるか」と思っている人向けのマルウェア解析ツール入門話

  • 追記と修正
    • 2024/01/09: FOR710 についてはプロ視点で賛否両論あったので表現を変えました
    • 2024/01/09: FLARE-VM の構築部分でも書きましたが、解析環境と普段生活する環境は分離しましょう。VMWare or VirtualBox を使ってください。普段使いの環境にここで述べた解析ツールをいきなりインストールするとAnti-Virusに検知される可能性もあります。

TL;DR

  • 将来的にベンダーレポートやカンファレンス発表レベルでの"マルウェア解析"を想定した話です
  • とりあえず FLARE-VM 環境を作ってインストールされたツールを見る・触るところから始めるといいんじゃないでしょうか

はじめに

最近は引きこもりをやめてときどき外部に顔を出すようになり、マルウェア解析やインテリジェンス関連の話をする機会も増えました。それに伴って、「これってどうやってやっているんですか?」「参考になる本やWebサイトありますか?」といったマルウェア解析に使うツールややりかたに関する質問もポツポツいただくようになりました。

「(もう令和もはじまって6年目になるし、勉強できるプラットフォームや本も大量に転がっているし、筆者への会話デッキの一つとしてみんな話題を振ってくれているんだろうなぁ)」とか筆者は思っていたのですが、先日とあるところでやったセキュリティイベントのアンケートにて「Windows バイナリの Reversing なんて初めてやるし、ツールとかどんなのがあるかわからないし、事前に教えてほしい」といった意見を目にして、意外と適切なツールをググって探してくるのも初学者にとっては難しいのかもしれないと考え方を改めました。
たしかに SEO の仕組みを考えても古い記事は検索上位に出にくくなるし、現在進行形で入門を考えている方向けの記事があってもいいのかもしれないと思い、筆者が利用するツールやそのツール選択の元となっているプールについてダンプしてみます。

内容的には「何番煎じなんだろう......」ってものですが、マルウェア解析のツール選定に関わるエントリーレベルの記事にありつけていない人がいれば何かの参考にしていただけると幸いです。

ちなみに筆者のバックグラウンドは、

程度です。知らないツールやプラットフォームもいっぱいありますし、筆者のやり方は特殊で思想が偏っている可能性もあります。もっと有用・一般的なものがあれば追記いたしますのでコメントしてください。

"マルウェア解析" のスコープと前提知識の明確化

まず"マルウェア解析"の勉強と一口に言ってもかなり主語がデカいので、今回深堀する"解析"の対象をより明確にしておきます。筆者がここで紹介するマルウェア解析のツールというのは、「マルウェアの静的解析からシグネチャを作成したり、TTP を収集したり、帰属の考察をしたり、C2サーバとの通信を復号したりする」ために使うツールを対象にしています。なので、ファイルのトリアージやマルウェアが EDR などに残すログ、フォレンジックといった観点の話はほとんど入っていません。また、マルウェアとして解析する対象はどうしても Windows PE が多くなるので、oletools のような Office 製品の解析なども一旦省略します。

なので、より抽象的なレイヤーでのマルウェア解析のはなしが知りたい方はマルウエアの教科書を、トリアージからフォレンジックまで幅広く知りたい人は初めてのマルウェア解析を購読してみることを推奨します。

また、解析に必要な事前知識まで話すときりがないので、本ブログでは割愛します。気になる方は pinksawtooth 先生が書いている以下の記事がめちゃくちゃ参考になるので読んでください。
github.com


ちなみに筆者のおすすめの勉強方法は、Practical Malware Analysis (宇宙人本)を一冊やり通すのと Zero2Automated というマルウェア解析における Try Harder 系のトレーニングをやるという2つがオススメです。

慣れてきたらすでにレポーティングされている簡単めな検体を Any.Run から拾ってきて解析してみるのがスキルアップにはよいとは思うのですが、危険と隣合わせなのであまりオススメはしません。個人的な腕試しのオススメは FLARE チームが主催している FLARE-On challenge です。かなり実務寄りの問題が多いのでマルウェアの勉強の実践としては十分なのではないかと思います。
flare-on.com

ツールの選択元(プール) : FLARE-VM

さて、余談が長くなってしまったのですが本題に戻ります。
まず大前提をお話しすると、「マルウェア解析においてツール選定が決定的となるような場面は少ない」というのが筆者の考えです。どちらかというとコンピュータサイエンスの基礎知識やツールに対する練度の方が重要で、いくつかのポイントを自分の使いやすいもので見れればそれで充分ではないかと思います。筆者の感覚で「何かしら自分の手に馴染むツールを抑えていたほうがいいんじゃない?」思うのは、以下の5つくらいです。(より具体的にあげるとフォレンジック関連ツール、各々の言語ごとの解析ツール、モジュールレベルのはなし.......と様々ありますがキリがなくなってしまうので、今回は一般的なマルウェア解析=>レポーティングの流れでほぼ必ず通るものに絞りました。また、python や VSCode といったセキュリティ関係なく使う系のツールは省略しています。)

大項目を5つあげましたが、各々のツールをいちいち調べて集めてくるのも少々面倒です。なので、解析ツールを学ぶエントリーとしては分析に必要なツール一式が導入されているディストリビューションを利用して、仮想環境マシンを作成し、中に入っているツールを調べて使ってみるのが一番よいかなと思います。ペンテストで言うところの 「まずは Kali Linux 落としてきて中身見てみたら」のニュアンスですね。筆者の一番のおすすめは、mandiant がOpen-Sourceで提供している Windows OSベースのディストリビューション FLARE-VM です。

github.com

筆者も大量のマルウェアアナリストを見ているわけではありませんが、VMWare 製品上に Windows 仮想マシンを立て FLARE-VM をインストールしている方を非常によく見ます。(もしかしたら、Ghidra実践ガイド での環境構築で述べられているのが影響しているかもしれません。) ツールも大量にインストールされるので、公式の Installation instruction を参考にしながら導入してみてください。現在は GUI でインストールするツールが決められるので、とりあえず200個近くあるツールすべてインストールしてみましょう。

画面遷移後に 3時間くらい放置すれば以下のようなデスクトップに切り替わると思います。これでひとまず導入は完了です。(余談ですが、昔の FLARE-VM のデスクトップイメージは水色のMマークでしたが、いつの間にか某アンダーなテイルのメタ〇ンっぽいキャラになってました。いつの間に変わったんだろうか。)

FLARE-VM インストール後のデスクトップ

あとは、デスクトップにある "Tools" ディレクトリを見てみましょう。様々なツールが並んでいると思います。知ってる単語や興味のある単語から子階層を漁って、ツールを調べて触ってみるといいんじゃないでしょうか。


FLARE-VM に入っている中でもよく使うツール

FLARE-VM インストールして中を見てみましょうだとさすがに不親切だと思ったので、筆者自身が中からよく引っ張り出すツールも簡単にまとめてみます。

PEStudio

www.winitor.com

マルウェア解析に限らずリバースエンジニアリングで最も大切なことは「自分が今向き合っているモノは何なのか」のあたりをつけることなのではないかと筆者は考えています。.NET で作られていれば de4dot や dnSpy を使って難読化解除やデコンパイルをしますし、pyinstaller や nexe によって実行ファイル化されたツールであればネイティブコードの抽出を目指す人が多いでしょう。つまり、対象がWindows PEファイルであれば最適な分析手法を割り出すためのワンクッションがあったほうが効率的です。そのためのツールの1種別が表層解析系のツールで、筆者は PEStudio を好んで使用します。

ただし、この項目についてはめっちゃ派閥がわかれると思います。pe-beer や CFF Explorer のほうがツールとして使いやすいという人もいますし、malwoverview のようなツールでトリアージは自動化している人、Detect It Easy のような最低限の表層解析ツールで十分の人もいます。

ここまでいろいろ書きましたが、ぶっちゃけ最適な解析ツールを導出することができればなんでもよいと思うので、あとは皆さんが触ってみたフィーリングやレベル感によって使いやすいものを決めてください。筆者はなんで PEStudio 使っているかというと strings の部分が優先度順で並ぶのと全体的にグラフィカルでわかりやすいからです。


IDA Free (Pro)

hex-rays.com

最強です。純粋なマルウェア解析をやっている時間の9割以上がこのツールを触っている時間と言っても過言ではないかもしれません。チラッと目次を見てもらった方には「あれ、デバッガ書いてなくね?」と思った方もいらっしゃるかもしれませんが、現在は x64 のアーキテクチャであれば Free からデコンパイルもできるしデバッグもできるのでほぼこのツールで完結します。つよいです。

IDA Free decompiler & debugger

ただし Free だと x86 や arm まではデコンパイルできないので、そういう場合は Ghidra でディスアセンブル/デコンパイルしながら x64dbg を使うという人が多いのではないかなと思います。(ただやはり Ghidra を使うとデコンパイルの精度やショートカットの微妙さなどが気になるので、できることなら IDA 使いたいなと筆者はよく感じます。あと、バージョンアップのたびにプラグインをビルドしたり python3 がデフォルトで使えないのがあまりにも厳しい。。。)


また、最近なぜか WinDbg を使いますという声もちらほら聞きます。たしかに先日 かえるのほんだな さんが0円というまさかのバグ価格でWinDbg本を公開されていたので、こちらを参考にしながらデバッガの勉強をするのも非常にありな選択肢だと思います。
techbookfest.org

雑にまとめますが、基本 IDA を使う練度を上げて使えない部分は他のツールでカバーするというのが一番実践的だと思う、というのが筆者の主観です。

FakeNet

github.com
FLARE チームが作成したネットワーク通信のエミュレートツールです。デフォルトだとほぼすべてのネットワーク トラフィックをインターセプト、リダイレクトし FakeNet 側で指定したカスタムレスポンスを返させることができます。つまり、マルウェア解析の場面ではホストオンリーの環境でもC2サーバの擬似応答を返させることでデバッグ解析を継続させることができるという強力なサポートをが得られるツールです。(リバエン力が高くない筆者にとっては、ここまでの上三つがとりあえず使うツール3強な気がしています。)

試しに FakeNet を起動した状態で google へ curl を叩いてみると、FakeNet からの fake レスポンスを返してくれることがわかります。

FakeNet sample

DNS も解決してローカルホストにリダイレクトさせてくれるので、ここからC2サーバのレスポンスを作りこみ、解析をより深く行うこともできたりします。FakeNet に届いた通信は pcap 形式でdumpしてくれるので、事後分析もしやすいです。総じて優秀なので、デバッグしながら解析している際には脇で動かさない手はないでしょう。

mandiant さんの公式ブログを見るとカスタムレスポンスのつくり方なども書いてあるので、興味がわいた方はこちらを参考にカスタムしてみてください。
www.mandiant.com

Yara

github.com

ファイルに対するシグネチャマッチングのデファクトスタンダードです。多くのベンダー・組織がマルウェアの検知ルールとして Yara rule を公開しており、さらにセキュリティ製品でもこの Yara が導入可能となっているものが多いです。なので、解析で Yara を使わなくても純粋に Yara の読み書きができるというだけでも得をする場面はあるかなと筆者は想像しています。特にマルウェア解析を仕事にしている人だと、解析結果から Yara ルールを作成して、それを組織のセキュリティ製品に組み込んで運用できる状態にしてもらうことをアウトプットの一つにしていたりするのではないかなと思います。
ルールのイメージがわかない方は JPCERT/CC さんが公開しているものなどを参考にしてください。

脇道にそれたので話を解析に戻します。主に解析後の話を中心として Yara を記述しましたが、筆者のトリアージプロセスの一つとして Yara をかけるというのは最初期段階で行います。「シグネチャでマルウェアのファミリ判定されれば儲けもの」くらいのモチベーションです。たしかに標的型検体や Pack されているマルウェアなどからはいい結果が得られませんが、ものの数秒くらいのロスにしかならないのでとりあえず JPCERT/CC さんなどのGithubに公開されているルールをかけて損はないと思います。

またシグネチャマッチングとは少々異なりますが、実行ファイルがどんなことをしていそうかというのを推定してくれる capa というケーパビリティツールもあります。
github.com

筆者は自分でルールを作りこむことまではしたことなく mandiant さんが提供するルールを IDA Pro のプラグインから使ってトリアージに活用しているだけなのですが、IIJ さんのブログなどを参考にすると自身でルールを書いてもっと有用な使い方ができそうな気がしています。皆さんはぜひ有効活用してください。
eng-blog.iij.ad.jp

FLARE-VM に入ってないけどよく使うので別途入れているツール

本当は上で終わるつもりだったのですが、なんだかんだ3割くらいは別途ツールをインストールして使っている気がするのでこちらも書いてみます。静的解析で使う細かめの話が多いです。ご了承ください。

FileInsight

俗にいうバイナリエディタです。FLARE-VM にも一時期話題になった午前3時から頑張る人向けのバイナリエディタ ImHex や010 Editorなんかが入ってはいるのですが、筆者の肌感にあわずメインでは使ってません。

代わりに何を使っているかというと McAfee 製の FileInsight というのを使っています。こちらは有志の方がマルウェア解析に特化したような plugin を作ってくれたりしていることもあり、雑にデータの復号とか解凍とかができるのがうれしい点です。バイナリエディタ単体で起動することもあまり多くは無いのですが、振り返ってみると一番使っているのはこれですね。

github.com

あとは、IDA にも Hex 表示の機能がついているので、けっきょくのところそこで見て python 使ってデータいじってしまうことが多いですかね。。。IDA つおい。

Process Hacker

processhacker.sourceforge.io

プロセスが使用しているメモリやネットワークレベルのリソースまで確認できる、プロセスリソースモニターです。
似たようなツールとしてProcess Explorerもありますが、筆者の場合 Executable なメモリを見つけたりそこからメモリをダンプしたりする機能が便利すぎてずっと Process Hacker を使っています。

また、少し余談になりますが、Process Explorer などに代表される Sysinternals tool は有用なものが多く FLARE-VM にも標準でインストールされるため見てみることをオススメです。("Tools -> sysinternals" にあります)
learn.microsoft.com

前にも述べた通り筆者はほぼ IDA を使うばかりで動的解析をしなくなってしまったのであまり使ってはいないのですが、Process Monitor, Autoruns なんかはマルウェアをとりあえず動かしてサクッと挙動を掴むうえで有用なツールだと思います。

直近だと IIJ さんのブログにも Process Monitor を活用した動的解析ツール Noriben のはなしがあるので、いきなり静的ではなく動的から勉強していきたい人は活用してもらえるといいのではないかと思います。(初めてのマルウェア解析 の本を持っている方はここからでも学べたりします)
eng-blog.iij.ad.jp

bindiff

github.com

最近 Open-Source になったことで話題となったディスアセンブルコードの比較ツールです。同じところで何年も働いていると一度解析したことのあるマルウェアの亜種とは何回も戦うことになり、詳細を全部確認すると無限に時間がとられてしまいます。なので、限られた時間で読む部分にあたりをつける、さらにはコードの更新部分を第三者にわかりやすく説明するためにかなり重宝されます。(特に、非エンジニアに説明する意味だと後者はデカいと思います。)

具体的なイメージが見たい方は moly さんのブログを参考にしてください。Ghidra での解析差分をサクッとそしてビジュアブルに図示できることがわかると思います。

morimolymoly.hateblo.jp


ちなみに IDA Pro を使っている方は diaphora という便利なプラグインがあるためこちらを使っている方が多いかもしれません。こちらでも bindiff と同等のことができますが、関数をクリックするだけで IDA の該当の関数に飛んでくれるので非常に親和性が高いです。 Pro がある人はこっちも試してみることをおすすめします。
github.com

BlobRunner

github.com

かなり tips よりのツールだが、「抽出した shellcode をサクッとデバッグしたい。。。」とアナリストならば一度は思ったことがありそうな要望を叶えてくれるツール。Initial Accessでは全部が shellcode でできたようなツールがポンポン降ってくるような昨今ではすごく有用だと思います。

筆者もかつては「指定したファイルを読み込んで、Executable なメモリに配置して、3分sleepして、call する。。。」なんてツールを書いて使っていましたが、BlobRunner だとデバッガでアタッチしたあとにエンターキー押せば breakpoint まで飛んでくれるので利便性高いですね。

OALabs さんは他にも API hashing の解決を補助してくれる hashdb のようなプロジェクトや Youtube channel で解析手法なんかを公開していて非常に有用なので、時間に余裕のある方はチラ見してみてください。(筆者自身も、こういうところから便利そうなツールの情報を盗むことが多いです)
github.com

Hayabusa

github.com

大和セキュリティさんが公開している Windows のファストフォレンジックツールです。「あれ、フォレンジックツールは紹介しないんじゃなかったっけ?」と思った方もいらっしゃるかもしれませんが、筆者は Sigma と呼ばれる SIEM でのログ検出用のシグネチャルールを検証する際に使用しています。

github.com

下記は Sigma 公式 Github の README に載せられている図ですが、Sigma ルールは Sigma rule のコンバーターと何かしらの SIEM (に検証したいログがたまっている状態)がないと有効活用、つまり検証できません。

https://github.com/SigmaHQ/sigma/raw/master/images/Sigma_description_light.png

Hayabusa は Sigma を解釈したうえでローカルに溜まったエベントログをスキャンしてくれるので、コンバーターと実質 SIEM 部分の役割を担ってくれます。便利です。Sigma ルールを書いたり検証したりするジョブに就いている人にとっては、マルウェアをローカルでガチャガチャ動かして検証できるようになるツールなので入れておいて損はないと思います。

おわりに

けっこうコンパクトにまとめたつもりがかなりぐちゃった内容になってしまいました。

もっと体系的に学びたいと思った方がいれば、学生の場合はセキュリティ・キャンプの脅威解析クラス, 社会人の場合はFOR710なんかがいいんじゃないかなと思っていましたが賛否両論あるようなので、現場の解析経験ある人から知見を吸収してみましょう。

最後になりますが、一歩目の踏み出し方がわからない方の参考になったり、何かしら新しい知見が得られた方がいれば幸いです。それでは。

某のフィッシングキットから見る、調査のときに留意したいクローキングのこと

はじめに

フィッシング詐欺は企業にも個人にも迫る身近なサイバー脅威の1つであり、それが占める被害件数の割合はサイバー攻撃全体で見てもおそらく最大クラスです。
大規模な SOC や CSIRT に所属している方にとっては、対応することが多いアラート・インシデントの一つになっているのではないかと思います。
もちろんアラート・インシデントがあれば対応者がフィッシングサイトの調査をする必要が出てきますが、ここで一つ課題になるのは クローキング の存在です。

クローキングは一般的なIT用語なのですでに知っている方も多いと思いますが、いわゆるアクセス元の情報を頼りに表示するコンテンツを変える技術のことですね。
wacul-ai.com

フィッシングサイトもクローキングによってフィッシング用コンテンツと良性コンテンツの表示を切り替えているのですが、問題はこのクローキング技術は対応者・リサーチャー側からは見えないブラックボックスの存在であるという点です。
「User Agent によって動作が変わる」, 「IPアドレスによっても動作が変わる」なんて話も人から聞いたことはありますが、実際にコードを見たことがないので調査も伝聞の知見をもとにやるしかありません。

筆者もこれまではサーバ側のコードを見たことがなかったので勘で調査を行っていたのですが、今回ひょんな機会でフィッシングキットを見る機会があったので、フィッシングサイトが使うクローキング技術をコードレベルで確認してみることにしました。
せっかくの長期休暇中なのでいつもと違う分析もしてみようというモチベもあり、調べた結果を簡単ではありますがメモ書き程度に残します。筆者と同じような境遇にいてフィッシングサイトの調査をする機会があった場合参考にしていただければ幸いです。

免責事項

本投稿はフィッシングキットの使用を促す内容ではありません。よって、フィッシングサイトの構築といった部分には触れることもありません。
あくまで行うことはソースコードをベースに攻撃者が行っているクローキング手法を分析することであり、リサーチャーが効果的にフィッシングサイトを調査するための視点を学ぶことを目的としています。
本投稿内容を悪用目的では使用しないでください。

ことのあらまし

2023年9月の頭、16shop というフィッシングキットを使用していたサイバー犯罪者が海外で逮捕された事件は皆さんの記憶にも新しいと思います。
筆者も下記のTrendMicroさんの記事を見ながらその功績の詳細を追うとともに、簡単にフィッシングサイトを作成できる「16shop」というツールキットについても概要を知ることができました。
www.trendmicro.com

......が、記事の中で一枚の画像が目に留まります。それは Maltego での分析画像でしたが、VirusTotal に16shopのフィッシングキットがアップロードされているようです。

『フィッシングキット16shopの分析、トレンドマイクロとインターポールのパートナーシップ(TrendMicro)』, 図5：複数のフィッシングキットが保存されているサーバ より画像引用

なぜキットがアップロードされているか理由はわかりませんが、ツールは海賊版も存在しているようなので、どこかで海賊版を入手した攻撃者がウイルスのチェックをするために VirusTotal にアップロードしたりしたのかもしれません。何はともあれ、`16shop` というキーワードのある zip だけで VirusTotal から見つけることができそうです。

試しに、以下のクエリを試してみると 47 件ほど存在しました。 TrendMicro さんの記事にある命名と同じなので、これらが海賊版(?)の16shopフィッシングキットのようです。

entity:file tag:zip name:16Shop
VirusTotal で16shopのフィッシングキットを search する

せっかく見つかったので、ツールキットを分析して筆者の中でブラックボックス化していたクローキング技術をクリアにしてみることにしました。
これで、勘でやっていたクローキング対策がより論理的に行使されるようになるでしょう。

16shop フィッシングキットの調査

基本情報

今回の分析する対象は以下のキットです。これを対象とした理由は、投稿日時が最も新しかったためです。
www.virustotal.com

ファイル名が『16Shop-Amazon.zip』なので、おそらく Amazon のフィッシングサイト構築用だと思われます。zip の Bundle info にある Latest Content Modification が 2023-05-31 なので、おそらく4か月ほど前に作られたものなのではないかと推測できます。

概要

今回入手したツールの中身を覗いてみると、どうやら php で書かれているツールのようで、index.php へのアクセスからすでに大量のクローキング処理が行われています。画像に見える blocker.php, blocklist.php などがそれに該当する処理ですね。読み込んでいる php ファイルの量が多くすべての処理を列挙していると記事の内容が非常に長くなってしまうため、いくつかにグルーピングして要点だけまとめていきたいと思います。

ディレクトリ構成


余談ですがTrendMicro さんの記事を見た際はツールキットは python で実装されているように見えたので、時代や種類によってキットの構成は一新されているのかもしれません。*1

クローキング処理部分の詳細分析

16shop の場合、フィッシングコンテンツを表示させるかどうかに使っている情報は以下のようです。

  • CLIENT-IP, X-FORWARDED-FOR ヘッダ
  • アクセス元のIPアドレス
  • アクセス元のホスト名
  • アクセス元のISP
  • User-Agent ヘッダ
  • Referer ヘッダ

そこそこあるように書きましたが、実態としては アクセス元のIPアドレス と HTTP header にある User-Agent の2つで、おまけ程度に Referer がある程度です。しかし、IPアドレス部分についてはそこから正規利用者かどうかの判定ロジックが多いのと、そもそもIPアドレスをどのようにして判定するかというロジックがあるため少し小分けにして記述してます。ここからは、各項目を細かく見ていきます。

CLIENT-IP, X-FORWARDED-FOR ヘッダ

大前提として、このフィッシングキットはアクセス元のIPアドレスを取得し、それがbotのアクセスやblacklistに登録されたIPアドレスであった場合はフィッシングコンテンツを返さずブロックするという仕様を持っています。では、そもそもアクセス元のIPアドレスをどのように取得しているかというと以下の部分のコードです。

アクセス元のIPアドレス取得部分

筆者も見て驚きましたが、ロジックがかなりザルです。このコードでは HTTP header に CLIENT-IP または X-Forwarded-For がある場合、それらを真っ先に優先してIPアドレスとして認識します。この先に様々なクローキング処理がありますが、まずは理想に見えるIPアドレスをこれらのヘッダーに入れることから試してみてもよさそうです。

アクセス元のIPアドレス

では理想的に見えるIPアドレスは何かというと、blacklist に載っていないIPアドレスを選択することになります。blacklist に載っているIPアドレスは単発のものもあれば一定のレンジのものもあるので注意が必要ですね。例えば、レンジでのblacklistを見るとTOR や AMAZON のIPアドレス帯などは基本的にblockされています。とりあえず TOR からアクセスしてもクローキングに阻まれてしまう可能性は十二分にありますね。

アクセス元のホスト名

ここではIPアドレスからgethostbyaddrでホスト名を問い合わせ、blacklist にないかをチェックします。しかし、なぜか先述べたIPアドレスチェックのロジックではなく $_SERVER['REMOTE_ADDR'] で取得したIPアドレスからホスト名を取得しているので、結局のところアクセス元のIPアドレスはHeader以外でもきちんと偽装する必要がありそうです。

中をざっと見てみると VPN のホスト名などもチェックしていたので、VPN アクセスかどうかもクローキングの対象にしているようです。筆者は NordVPN や ExpressVPN を使いますがどちらもblacklistに入っていたのでVPNの契約バリエーションを増やす必要があるなと再認識しました。

アクセス元のISP

こちらはIPアドレスの取得ロジックで取得したIPv4に対して、Internet Service Provider を問い合わせてblacklistに当てはまった場合弾くロジックです。
中を見ると、Digital Ocean やら Choopa やらリサーチャー側がよく攻撃インフラとして使われているのを見る文字列は見えましたが、OCN などの日本の利用者向けのものは見えませんでした。ここらの Provider は bot ばかりで一般的な利用者がいないという判断なのでしょうかね。

User-Agent ヘッダ

このヘッダも、基本的には blacklist にマッチしたものを弾く仕組みなので、Webで検索して一般人が使用する OS, Browser のものを引っ張ってくれば弾かれることはなさそうでした。もちろん雑に curl したり、python の requests で訪れたりした場合は弾かれるので CLI から検証をする場合は必ず User-Agent を変更しましょう。


Referer ヘッダ

Referer の blacklist は .htaccess 側にその記載がありました。どうやら phishtank からのアクセスなどはここで弾けるようにしている実装のようです。Referer はヘッダに入っていた場合に弾く材料として使われているようなので基本は設定せずとも問題ないとは思いますが、Webサービス経由で調査を行う場合などは考慮する必要がありそうです。

その他、気になったこと

これはクローキングの仕組みとはずれる話となりますが、blacklist などによってbot判定された場合のIPアドレスや理由はその都度記録されていて、そこは「よくできているなー」という感想が漏れました。例えば、以下のコードは antibot[.]pw にIPアドレスを問い合わせて bot かどうかを判定する処理なのですが、bot 判定された場合はそのIPアドレスをファイルに書き出しています。

bot 判定された場合、そのIPアドレスを別途記憶する処理

書きだされたIPアドレスが即座に使われる様子は今回のコードから確認できませんでしたが、おそらくここで手に入れたIPアドレスを利用して、攻撃者が今後のblacklist拡張などに活用するものと思われます。このような処理は他の blacklist 処理のコードでも散見されるため、調査の一番最初できちんとクローキングを意識したアクセスをするかどうかが非常に大切なことがわかりますね。もし弾かれた場合、即座にVPNの切り替えなどを行った方が賢明かもしれません。

余談ですが、コードを最初に見たときは「『一度アクセスしたIPアドレスでbot判定されたら blacklist 入りする』といった設定が入っていた場合、とりあえずメールに書かれているURLを全部雑にcurlすることで企業ネットワークの同じ出口にいる従業員の被害を最小限にできるかなー」とか妄想していたのですが、16shop の場合それができなそうなので残念でした。

まとめ

簡単ですが、フィッシングキットの調査をしてブラックボックスだったクローキング技術をクリアにしました。基本的にはクローキングはblacklist方式で行われているようで、フィッシングサイトにアクセスする際には

  • CLIENT-IP, X-FORWARDED-FOR ヘッダ
  • User-Agent ヘッダ
  • Referer ヘッダ
  • 出口となるVPN

を最低限工夫してから初動の調査を行われなければいけないことがわかりました。リサーチャーの場合、攻撃者の環境には分析用の仮想環境から TOR, VPN などを経由してアクセスすることになると思いますが、フィッシング関連のインシデント報告を受けてアクセスした結果それらしいものが表示されない場合、VPN を別のものに切り替えたり調査用の専用線からアクセスするようなアクションが必要となりそうです。

最後になりますが、本投稿はあくまで特定の1つのフィッシングキットを分析したサマリになります。他のフィッシングキットは同じような動作をするとは限りませんし、より入念な準備をしている攻撃者ならblacklist以外のクローキング技術を施しているかもしれません。しかしインデント対応者はその仮説が外れた場合、ブラックボックスな状態から変数を考察して次の手を打つことは必須です。この投稿がフィッシングインデントの対応者にとっての、初動対応を考えるための一助になればと思います。

*1:もしかしたら、この php のものは古い海賊版を改造しながら使いまわしている可能性もあるかもしれません。

Webミリしら人間の OSWA 合格体験記 (2023/08)

はじめに

夏休みに暇な時間ができたので、 OSWA という OffSec. の資格を取得しました。

まだ日本語でのレビュー記事や体験記がなかったので、簡単ですが備忘録を残します。

なお今回はWebセキュリティ資格関連の話をしますが、筆者はWebの専門家でもなければWebセキュリティについては全然詳しくない人間です。頓珍漢なことを書いている場合はご訂正いただけると助かります。

What is OSWA & WEB-200 ??

OSWA は Offensive Security Web Assessor の略で、Offsec.が提供するWeb アプリケーションのペネトレーションテスト資格です。
www.offsec.com

日本人の受講記録は筆者調べだと存在せず、多くの日本人にとって未知な部分が多い資格かなと思います。筆者はLearn Unlimitedを契約しているので、夏休みに様子見ということで受講してみました。

Offsec が提供するWebのペネトレーションテスト資格はWeb-300に該当する OSWE のほうが著名ですが、Web-200 は Web-300 よりもより入門者向けに作られたトレーニングとなっています。具体的に述べると、Web-300 はWebアプリケーションテストのホワイトボックステストに大きく焦点が当てられているようですが、Web-200はブラックボックステストが中心です。そのため、コードに対する深い理解などはいらず基本的なコンピュータサイエンスの知見とファジングの基礎知識があれば十分戦えるという内容になっています。公開されているアジェンダをまとめると、以下のような内容が学べます。

  • XSS (Cross-Site Scripting )
  • SQL Injection
    • RCE までを含む
  • CSRF (Cross-Site Request Forgery)
  • SSRF (Server-Side Request Forgery)
  • SSTI (Server-Side Template Injection)
  • Command Injection
  • XXE (XML External Entities)
  • Directory Traversal
  • IDOR (Insecure Direct Object Reference)

CTF やWebが得意な人なら「かなり基本的な内容しかないな」と感じたと思いますが、ご想像の通りでWeb-200の扱うスコープはかなりメジャーなWeb脆弱性のみなので少々ボリュームが少なめです。そしてCVEベースの脆弱性もスコープ外であり、基本的には構築されたWebアプリケーションの実装上の脆弱性を探すという内容になっているので、とにかく列挙列挙列挙ファジングファジングファジングが重要なゲーミングになっています。そのため、すでにWebの脆弱性診断やセキュリティに関わっている人にとっては少々退屈な話題だと思うので、そのような方は最初からWeb-300を受講することを強くお勧めします。ちなみに、筆者は「へー "/api/user/100" => "/api/user/101" にアクセス試すのってIDORって言うんだー」「XML External EntitiesってXXEって訳すんだー今までXEEって言ってたかもー」レベルだったので純粋にトレーニングコンテンツを楽しむことができました。しかしながら、用意されているラボが現状だとまだ8台しかなく、3日で遊びきってしまったのでボリューム的には不満でした。OSWA 試験が提供され始めたのも2022年(だった気がする)のでまだ発展途上な研修であることは否めず、受講者自体が現状少ないのもそのあたりが相まっているものと思われます。

試験

試験概要

OSWA の試験は OSCP と同じく1マシンからlocal.txtとproof.txtを取得するタイプの試験ですが、実態はOSCPと少々異なります。OSCP はuser shellの取得証明でlocal.txt, privilege shell の取得証明でproof.txtを提出しますが、OSWA はwebのコントロールパネルへの侵入でlocal.txtが, そこからfile system上のファイル読み出しができてproof.txtが得られるような試験になっています。(ここでいう webのコントロールパネル というのは、WordPress の admin dashboard だと考えてもらえればOKです。)

wordpress.com


つまり権限昇格のフェーズは存在せず、HackTheBox でいうところのlocal shellが取得できるまであたりがゴールという感覚です。これは"権限昇格がないので簡単です"という表現ではなく、WEB-200で取り上げているような脆弱性でもRCEにつながらないものを試験に取り上げるための都合だと思われます。具体例をあげると、単純なXSSの脆弱性ではRCEにつながらないのでOSCPの試験だと取り上げにくいですが、コントロールパネルへの侵入が第一目標だとcookieをstealする問題として出しやすいという感じですね。なので、OSCP のように "whoami + cat or type proof + ip a or ipconfig" のスクリーションは必要なく、local.txt or proof.txt が映ったBrup SuiteからのスクリーンショットとWeb UIのスクリーンショット2つをレポートに張り付けることが変わりに求められていますね。

https://help.offsec.com/hc/en-us/articles/4410105650964-WEB-200-Foundational-Web-Application-Assessments-with-Kali-Linux-OSWA-Exam-Guide


もう少しイメージしやすい具体的なboxを挙げると、"soccer" というマシンのuser shell取得までをもう少し難しくしたマシンになります。
infosecwriteups.com

このようなマシンが5台分存在し、local.txt, proof.txt がそれぞれ10 pointで合計70 points overで合格です。ボーナスポイントは存在しないので、最低でも4つのマシンでコントロールパネルに侵入できないとアウトとなります。取り扱っている内容が難しくないとはいえ、8割のマシンでexploitを成功させなければならないのでスピードが重要な試験ですね。

試験本番のタイムスケジュール

Web のペネトレは列挙がすごく多いので、筆者のレベルでは時間がかなりカツカツでした。筆者の試験タイムスケジュールは以下で、合格までは15.5時間程度の時間がかかりました。

時間 score 詳細
11:00 0 試験開始.
11:31 10 1台目 local
- - 脆弱性っぽいところは見つかるがexploitまでつながらず一旦あきらめ
14:47 20 2台目 local
- - 列挙しても脆弱性見つからず一旦あきらめ。内心焦り始める。
18:03 30 3台目 local
18:38 40 3台目 proof
19:29 50 4台目 local
19:57 60 4台目 proof
- - ご飯食べて仮眠。3,4台目がめちゃ簡単だったので、"まさかね......" とベットで考えていたことを1台目で試したら通った。
02:23 70 1台目 proof
- - 合格ライン超えたのでレポート作成始め, proofと再現のチェック
08:30 70 ほぼレポートのひな形が完成し一応5台目へ
09:21 80 5台目 local
10:00 90 5台目 proof
10:45 90 2台目の proofも粘ったけど取れず
13:00 レポート提出

1, 2台目のマシンと筆者のメンタルモデルが合わず前半はけっこう焦りましたが、後半はラボやトレーニングの内容をベースにポンポン進んだので内心ホッとしました。悩んで首をひねり続けていても見えないものは見えないので、チートシートを使ってどんどん列挙を続けるのが大切な試験でしたね。ある意味、OSCP のときにやった諦めない列挙の心というのを思い出しました。

github.com

最後1台目のproof.txtだけどうしても取得できず90pointsで終了。スクショの取得漏れが一番怖いので合格点達成時点でレポートを書き、最後に5台目分の内容を追記する形で早めにレポートを提出しました。レポート提出後は別の作問作業などをしていましたが、ピッタリ24時間後に合格通知が来て特に山もなく谷もなくといった具合でWeb-200は修了です。

完走した感想

最後に、いつものように試験のことは書けないので感想を残して終わります。まず試験ですが、OSCPのときと同様に「ちょっと意地悪やなぁ」という問題が多いように感じましたね。Hy3n4 さんのレビューには以下のような文章が書かれています。
medium.com

I would consider myself as a pentester with some decent level of experience. But I have to admit that the time frame in this certification probably makes it even for more experienced pentesters not like a walk in the park.

一言でまとめると「経験者でも楽勝ではないよ」という内容になるかと思います。OffSec. の試験だとツールをただ回すだけではexploitの兆しが見えにくいというのがあり、やはり手動で微調整した列挙や、自分で簡単なコードを書いて試験する必要性が出てきます。CTFで簡単なWeb問をやっていた人なら問題ないと思いますが、bliend SQL injection の検証レベルのコードが書けたほうができることの幅が広がるので、ラボを通してコーディングへの抵抗は少なくした方が賢明です。筆者の場合は、bliend SQL injection からlocalにあるファイルを読みだすスクリプトと、gopher を使ったssrfのURLエンコーディングを二重にするコードは事前に作っておきました。

ここまでネガティブ方面に見えることを書き連ねてしまいましたが、筆者はOSWAにあまりネガティブな印象を持っているわけではありません。ラボや試験で対面したマシンはモダンな作りのWebサイトが多く、やはり実践的なトレーニングができるOffSecの研修はいいなと再認識しました。OSCPのラボやよくある日本の研修だとLAMPという平成の遺産をつかってWebの脆弱性を学ぶことが多いですが、OSWAだと node + mongo やbackendにgraphqlがいるようなモダンなつくりのwebサービスを対象にして遊べるので、「php の webshell 置いて終わり」なんてラボは一切なく非常に楽しかったです。同じような内容は OWASP Juice Shop でも遊べるのですが、やはりマシンが複数ある分Webサービスとしてのバリエーションが多く、起動やリスタートも簡単なOSWAのラボのほうが快適で楽しかったというのは心の底から思います。

owasp.org

HTBの似たようなマシンでも学べはしますが、やはりあちらもshellをとることに特化しているサービスなので、実際のWebサービスのペネトレーションという意味ではOSWAのほうが実践的なのではないか、と浅薄ながら思う所存です。


おわりに

Web ミリしら人間だったので、OSWA を通してWeb脆弱性のことを少しは学ぶことができたかなとうれしく思っています。やはり「知識として持っているだけだと実際のexploitで活用できない, 応用が利かない」というのはどのOffSecトレーニングをやっても痛感することで、今回の試験でもそれを学ぶことができたことは一つの実りです。その一方でWeb-200のみだとトレーニングのボリュームは不満に感じる部分もあるので、診断経験などがある人は素直にWeb-300からやるのが無難かなと思います。しかし、セキュリティ何もわからないけれどもペンテスター目指したいような人の場合、OSCPだとスコープが広すぎて覚えることが多くたいへんな面もあると思うので、OSWAから始めてみるというのも一つの選択肢とありだと考えます。最終的なエントリーレベルとしてどちらを選択するかは、自身のキャリアプランと相談してみましょう。筆者の場合、もうちょっとWebに詳しくなるためにも今度はWeb-300を受けますかね。

そのほか、気になることがあれば Xまで気軽にリプかDMを送ってください。それでは。

SOCっぽいことをしている中の人の OSDA 合格体験記 (2023/07)

はじめに

先日 OSDA というOffsec.の資格を取得しました。

N番煎じなブログですが、体験記のリクエストをもらったので自身の記録を書き残しておきます。OSDAの取得を考えている人の参考になれば幸いです。

What is OSDA & SOC-200 ??

OSDA 合格に関わるブログは、すでにたくさんの方がまとめてくださっているためご存じの方も多いかもしれません。まだ試験が始まって1年も経っていないはずなのに早いですね。

レオンテクノロジー様『OSDA(Offsec Defense Analyst)の受験記』
www.leon-tec.co.jp

GMO CYBER SECURITY by IERAE 様『OffSec Defense Analyst (OSDA)受験記』
gmo-cybersecurity.com

nknskn さん『OSDA のケーススタディ』
news-nknskn.hatenablog.com

ここでも簡単に説明すると、OSDA は Offsec Defense Analyst の略で、Try Harder で有名なOSCP資格と同じOffsec.が提供する唯一のDefense向け資格です。OSDA 試験のためのトレーニングとして SOC-200 というコースが設けられており、その名の通りSIEMを活用したログ分析の手法を学ぶことができます。具体的には、以下のようなことを学ぶことができます。

  • Windows イベントログそのものの勉強/監査設定
  • WindowsとLinuxの初期侵入/横展開/権限昇格/永続化 をした際に発生するログ
  • Active Directory環境での横展開/ドメイン掌握 を行った際に発生するログ
  • Kibanaの操作、アラートルール、視覚化ダッシュボードの作成方法

一言でまとめると、Elasticsearch + Kibana を使ったログ分析ゲーミングとなります。筆者はKibanaを使ったSIEM運用やEndpointログ分析を日常からバリバリ行う職場にいるため、分析環境はとてもなじみ深いもので使いやすかったです。

また、トレーニングの内容としても『監査設定をする => どんなWindows eventログが見えるようになったか確認する => 攻撃をしてどんな特徴的なログが出るかを見る 』という基本のキに沿った内容だったので非常に親切であり、初心者入門教材としては十分だと思われます。その一方で、そこまでハイレベルなログ分析の視点までは紹介されず、一般的なドメイン環境の侵害で使うツールが残すログを雰囲気で追えるレベルの解説しかなかったのは物足りない部分だと感じました。 弊チームにいると 「event id `4662` の3回出現で何されたかも読めないの!?」と詰められますが、この研修だと「lsass.exe に Process Access されたからcredential accessされました」くらいの粒度でわかればOKなので、非常にやさしいです。より専門的なログ分析の方法については SOC-300 が出るのを待ちましょうという感じですかね。

また、この研修はOffsec研修の中でも最高に親切で、用意されている Lab (challenge) の半分以上は OffSec Academy (OSA)という動画付きの講義で詳しく解説してくれますし、Offsec の discord に行って以下のように chatbot を起動すれば、各 Lab のヒントをもらうことができます。
ぶっちゃけ Try Harder 感はほぼないので、初心者向け Offsec トレーニングともいえるでしょう。筆者の肌間的にはOSCP, OSEP, OSWPに比べてかなり快適だったので、Blue teamの人たちの温かさに感動していました。

discord chatbot

試験まで

筆者は4/10からトレーニングの受講をはじめましたが、Offsec側でVMインスタンスが安定して起動しないというトラブルがずっと発生していて、まともにLabができるようになったのは5月末からでした。別の方の合格体験記では「試験環境が不安定でログがSIEMに残らない問題があった」という記述がありましたが、同時期のLab環境でも同じような現象が発生しており「そもそも演習環境のVMが正しく立ち上がるまでが一番難しい」という状態でした。なので、VMインスタンスにちゃんと触れるようになってから約2か月Kibana触ってLabを2周くらいしあたと、「まぁいけるかな」という状態になったため7月末に試験にゴーという感じです。

試験前の対策としてはいつも使用するクエリのチートシートやKibana Dashboardの作成などをしていました。特に、SOC-200 で使用するElasticsearchのバージョンは メジャーバージョン 7 の最終系 であるため、8で運用している人とは微妙に使用感が異なります。「普段 Elasticsearch + Kibana 使っているし余裕」という人も、試験前に使用感をチューニングすることをお勧めします。(「8.8 から使える Response console スゲー」と感動して現場でそれしか使っていない人は使えないので要注意です。)
www.elastic.co

また、分析用のDashboardとosqueryのクエリチートシート(endpoint fileのハッシュ計算や通信しているプロセス列挙など)があると時短になるので、短期間で試験を受ける人もこの2つだけは準備することをおすすめです。

Kibana Dashboard のサンプル

試験

試験は10個のフェーズに分かれた攻撃を順番に分析する24時間の試験です。各フェーズ10点満点で合計75点に達すれば合格になります。体感的には10時間くらいで終わる内容で、特にトラブルもなく最終フェーズまで進んだので運がよかったかもしれません。詳細なスケジュールを書くと以下のような感じです。筆者の場合金曜日業務の終わった後の土曜日夜1時から初めて、月曜日の0時45分までにレポート提出の日程でやったので途中眠すぎて椅子の上で気絶していました。OSCPを受験した際は連勤の間に試験挟む程度余裕だったのですが、もう年のせいか徹夜試験は身体に響きますね。。。

時間 Phase 詳細
01:00 0 試験開始. まずは試験環境の視察. 基本の検索クエリ生成
01:20 1
02:05 2
03:25 3
04:40 4
06:20 5 7時くらいまでは分析していた記憶がある
- - 椅子に座ったまま気絶
10:40 6 慌てて起きて分析の続き
11:15 7
11:55 8
- - お昼食べたり買い物したり掃除したり
16:20 9
17:15 10 18:00には終わり夜食と風呂
ここからレポート作成
06:00 レポートのひな形を書き終え安心して就寝。
- - 睡眠。
10:30 起床して誤字や抜けの確認作業
15:00 提出

筆者の記憶だと PEN-200 のときは性格の悪い環境での試験だったので、今回も捻くれたものを覚悟して受けました。......が、かなり素直な環境を想定したログ分析で杞憂でした。レポートを提出した次の日の夜には合格のメールが来たので、大きな波もなく試験終了。他の人の合格体験記を見ると結果がくるまで1週間近く間が空く人もいたようなので、個人差があるようです。

試験tips

試験に関する詳しいことは書けないので、最後にちょっとした試験のコツだけ書きます。技術面というよりもマインド面でのコツです。

  • 攻撃者が一本道で目標を達成するとは限らない
    • 言い換えれば、1つの行動の追跡にこだわりすぎると全体が見えなくなります
    • 内部まで横展開が進行したあとに唐突に足取りがつかめなくなっても、落ち着いてドメイン環境を見渡して痕跡を探しましょう
  • Phase で一つの目標だけが達成されるとは限らない
    • 「あーこの端末でこれやったんだ!」で勝手に納得すると、後で足元をすくわれる可能性があります
    • 「ログが読めてる!」とノッているときでも、一度全体を見渡して他にも何かされていないかを探してみましょう
  • ログが行動を完全に追跡しているとは限らない
    • 端末によっては監査設定があまく、ネットワークログやオブジェクトへのアクセスログを完全に記録してくれていないものもあります。
    • その場合は、見えているログから攻撃者が何をやっているかを埋め合わせて記述するしかありません。細かい部分は一度脇に置いて、先に進めましょう。
  • Phase のログを実行する場合は 0時01分10秒 のように少し中途半端な秒数から始めるのをおすすめ
    • 0時5分のようにキリのいい時間にやると、cronjob などのログに攻撃のログが混じるので滅茶苦茶見にくくなります。
    • 特に試験の開始前は、焦らずにどんなログが流れている環境かを分析するところから始めましょう

おわりに

以上、OSDA のレビューでした。弊社はOSCP合格者には上限まで資格奨励金が出ますがOSDAは0円なので天と地ほどの待遇差があり、弊チームからは『nmap は神スキルだけど Kibana でログ分析はハズレスキル』なんてネタにされていますが、 Elasticsearch + Kibana を触ったことない人やWindows Event logを全く見たことのない人にとって SOC-200 はとてもいいトレーニングですし、追放された先の多くのパーティで活躍できるスキルになると思います。環境準備して攻撃してログを見てリセットして......という環境を個人のVMで用意するのは面倒なので、SOC-200の研修を受講してサッと試す分にはおすすめです。また、SIEM や EDR 導入の話をすると「セキュリティにお金を1円もかけられない人もいるんですよ!!」というお話も出ますが、Elasticsearch + Kibana の分析環境は0円からSIEM + EDRを始めることができるので、「お金かけられないおじさん」にもおすすめです。*1

逆に運用経験がある人にとっては退屈な内容なので、そういう方々は SOC-300 が出るまで待ちましょう。
そのほか、より具体的な内容でも気になることがあれば twitter (今は X か....)まで気軽にDMしてください。それでは。

*1:もちろん0円だと限界も多いですが、とりあえずおすすめされた100 ~ 1000万円規模の製品だけ買って神様に祈るよりも、ログとして見えるもの, わかること, 限界などを把握したうえでその課題をクリアする製品を選ぶのでは防御の練度がまったく異なります。

OSINTのすてきな乱れ

  • 2023/06/18 騒動の元凶となったTweetについては本人から掲載許可をいただいております。あくまで本記事の目的は知識・用語の整理および以後の混乱を避けるための一提案であるため、本人への突撃などはご遠慮ください。
  • 2023/05/08 AIをArtifact Intelligenceと誤表記していたので修正

tl;dl

  • 筆者が"OSINT"について言及した結果、炎上にガソリンを撒いてしまった恐れがあるため用語の整理と筆者なりの考えをまとめた
  • OSINTという単語は『インターネットを使ってほにゃほにゃした』という非常に漠然としたコンテキストの元で使用される場面が散見され、聞き手にそのコンテキストが共有されていない場合は解釈に不一致が生じる
  • 少なくとも単発のアクティビティや公開情報からの情報収集という行為においては、OSINTという専門用語を持ち出さずとも適切な日本語を使用したほうが聞き手も理解しやすい

はじめに

本記事の投稿から約二か月ほど前、OSINT (Open-Source Intelligence) を題材としたつぶやきで界隈が盛り上がっていた。


時を同じくして、何の偶然かわからないが筆者もOSINT関連の話題をつぶやいており、騒動にガソリンを撒くようなかたちで話題を広げる事態となってしまった。


この結果は筆者としても本意ではないし、事態に加担しておいて「終息したしおーしまい」というのも不誠実な気がしてならない。筆者も本件を機会に改めてOSINTについてその言葉の定義を再確認し、「OSINTとは何か」という問いに対する自分なりの回答を捻りだしてみたので、備忘録としてその内容を書き残す。

なお、本記事は筆者なりの意見を多分に含み、一部の内容については間違っているおそれもある。「皆さんに最もらしく嘘を伝えたい」といった意図は全くないので、誤りのある内容についてはぜひ指摘していただきたい。

SNS 上で見られた論点と筆者なりの見解

炎上というのは「発信元が総叩きにあっている」という場合に限らず、「様々な意見を持っている個人が各々に発言した結果、マクロな視点で見たときに一つの大きな炎に見える」という構造をとっている場合がある。筆者の見立てでは本件もそのケースに該当するのではないかと考察しており、SNS(Twitter) で見られた言及を整理してみるとやはりいくつかの違った論点での指摘が見られた。これを独断と偏見で3つのカテゴリに分けたので、それぞれの命題に対して筆者なりの見解を述べていく。

Intelligence ≠ Collection


さて、これからOSINTについて考えるということは、まずその言葉の定義について確認しなければならない。
本記事を見ていただいている人の多くは、OSINTという単語を見聞きしたことがあるだろう。「本日のOSINTまとめです。」といってWeb記事のまとめを提出する人間や、「OSINTでSNSアカウント特定しました!」と言ってくる身内と遭遇した経験は少なからずあるのではないかと思っている。では、この文脈で語られているOSINTというワードは、果たしてOSINTの定義に沿ったものなのだろうか。


OSINTとは "Open-Source INTelligence" の略であり、その名の通りWebサイトやSNSといった公開情報から生成された "インテリジェンス" なるものである。OSINTはインテリジェンスを"情報の収集源"という観点で整理した一つの分類上の呼び名にすぎず、その他にも HUMINT (Human INTelligence) や SIGINT (Signal INTelligence) といった別の情報源から収集したインテリジェンスの呼び名が存在するが、本記事の本質から内容が反れるため今回は割愛する。

ここで疑問となるのが、先ほどから多用されている"インテリジェンス"とはいったい何者なのかということである。近年では AI (Artificial Intelligence) という言葉が一般人にも知れ渡り使用されるようになったが、おそらく"インテリジェンス"という言葉を単体で使用する人はいまだに少なく、意味をしっかり調べたことがあるという人はもっと少ないのではないだろうか。それもそのはずで、インテリジェンス (Intelligence)とは元来軍事で用いられる専門用語であり、日常で使われることはほとんどない。まずは米軍統合情報本部が公開している『Joint Publication 2-0: Joint Intelligence』*1から、その意味を確認してみるとしよう。PDFの冒頭には、こう書かれている。

Information on its own may be of utility to the commander, but when related to other information about the operational environment and considered in the light of past experience, it gives rise to a new understanding of the information, which may be termed “intelligence.”


情報はそれ自体でも司令にとって有用かもしれない。しかし、作戦環境で関連する他の情報や過去の経験と照らし合わせたとき、その情報に対する新しい理解が生まれる。これを "インテリジェンス" と言うのかもしれない。


日本語訳は筆者が書いたものなので、多少誤訳があるかもしれない。しかし原文を確認した方はおそらく同じような感想を抱くのではないだろうか。「用語解説のはずなのに説明が抽象的ではないか? 情報をいい感じに使ってもっと価値のある何かにすればええのか!?」と。では、内容がより明瞭になる Introduction まで読み進めてみよう。Introduction だけでも長く全文を載せることができないので、筆者がインテリジェンスを理解するうえで重要だと思う箇所だけ抜粋した。もし原文が気になる方は、PDFの Introduction を見ていただきたい。

a. 情報は将来の状況や条件について合理的な洞察を提供することで、司令の意思決定プロセスに貢献し最大の価値を発揮する。
(中略)


生のデータ(Raw Data)はそれ自体は比較的限定的な有用性しかもたない。しかし、データが理解しやすい形に処理されるとそれは情報(Information)となり、より大きな有用性を得る。情報の段階でも司令にとって有用かもしれないが、作戦環境に関する他の状況や過去の経験と照らし合わせたとき、その情報に対する新しい理解が生まれる。これを "インテリジェンス (Intelligence)" と言うのかもしれない。
(中略)


インテリジェンスは、最終的に情報とは2つの異なる特徴がある。インテリジェンスは将来の状況や情勢を予測することができ、行動指針(Courses of Action)をとることでどのような違いが生まれるか明らかにすることによって意思決定に貢献することもできる。


b. インテリジェンスは、作戦環境を理解しやすくさせるための評価および推定を司令に提供する。
(中略)


c. インテリジェンスは科学ではない。インテリジェンスアナリスト(分析者)は作戦環境を評価する際に不確実性を持っている。
(中略)


したがって、アナリストは自らの分析にどの程度信頼を持っているか(degree of confidence)を伝えることが重要である。
(中略)



d. インテリジェンスには、能力・プロセス・組織が含まれる。
プロセスには、収集, 加工, 抽出, 分析, 配布の工程が含まれている。
(中略)


インテリジェンスはそれ自体が目的ではない。作戦におけるインテリジェンスの関連性を向上させるために、マネージャーは消費者のニーズを予測し、インテリジェンスが効果的か、影響力があるかを検討しなければならない。
(中略)


作戦環境は絶えず変化するため、インテリジェンスは継続的な活動であることを留意する必要がある。

ここまで読み進めると非常に詳細に書かれているため、多くの方がより鮮明に"インテリジェンス"をイメージできるようになったのではないだろうか。筆者なりにまとめた"インテリジェンスとは何か"をまとめたものが以下である。

  • インテリジェンスとは: 以下の3つを含むものである。
    • 能力: 意思決定者に対して有効な"アウトプット(成果物)"を提示できることを指す。具体的には、データを収集し、情報へと加工し、分析してインテリジェンスへと昇華できるとともに、それが意思決定者に対する具体的な行動指針として貢献できていることである。サイバーセキュリティの文脈では、CISOに対してセキュリティ施策や予算への提言、SOCにIoC(Indicator of Compromise)やシグネチャの提供といったアウトプットが該当する
    • プロセス*2: 顧客・組織のインテリジェンス要求(Intelligence requirements)を理解・検討し、より要求に沿ったインテリジェンスが提供できるよう継続的に改善が行われている。
    • 組織: 上記が組織的に従事されている。
  • なぜインテリジェンスがあるのか
    • 刻一刻と変化し大量の情報が溢れている現場において、意思決定者は必要な情報だけを取捨選択し次の行動を決める必要がある。インテリジェンスは意思決定者を助け、組織がより最適な行動をとることを継続的にサポートできる
  • インテリジェンスはどのように生まれ、どのような特性を持つのか
    • 組織に所属する能力を持ったアナリストが、意思決定者のニーズをもとに改善を繰り返しながら行動指針に寄与する分析をすることで生成される。しかしインテリジェンスは科学ではなく不確実性を伴っているため、分析にはアナリストの評価・推定が含まれる。アナリストによる不確実性の評価は、信頼度として表現される。


少々遠回りとなってしまったが、このまとめを踏まえつつも『Joint Intelligence』の定義に基づきながら、「OSINTとは?」に対する筆者なりの説明一言で表現してみると、以下のようになった。

「組織・顧客のインテリジェンス要求を達成すること目的として公開情報を収集・分析し、 組織の情報戦に関わる意思決定に継続的に貢献すること」


さて、それでは冒頭の問いに戻ろう。Web記事のまとめやSNSアカウント特定は果たしてOSINTなのだろうか。筆者の見解としては、「OSINTを生成するための情報収集及び分析結果の一部ではあろうが、インテリジェンスの定義には沿っていないのでOSINTと表現すべきではない。」になる。つまり、元来のかっちりとした定義に基づいて"インテリジェンス(または、OSINT)"という単語を使用している人にとっては、昨今様々なコンテキストで使用されているOSINTは本来の意味からずれた別の何かとして映るのである。
本騒動においても、OSINTを生成するための活動を指して"OSINT"と表現している人が散見されたため、「情報収集(Open-Source Collection)というのはOSINTを生成するうえでの活動の一部ではあるが、それ自体はOSINTではないよ」という意味を込めて、このような本質的な事象について述べたアナリストがいたものと思われる。


ここまで長々と茶番をし続けてきたが、直近でSANSから出されたOSINTに関する記事でも同様の内容が書かれていることが確認できる。余力がある方は、是非一読してもらいたい。
www.sans.org


冒頭を抜粋すると、以下のように述べられているのが確認できるだろう。

Open-Source Intelligence (OSINT) is defined as intelligence produced by collecting, evaluating and analyzing publicly available information with the purpose of answering a specific intelligence question.


OSINT は、特定のインテリジェンス要求にこたえることを目的として、公開されている情報を収集・評価・分析することによって生成されるインテリジェンスと定義される。

OSINT のスコープ定義あるいは倫理との境界


本騒動は「OSINT をする過程で図らずして攻撃となってしまったり、法律に抵触するようなことがあるかもしれないので注意してくださいね」という発言内容がもとだったため、法と倫理に関する言及が最も多かったように感じている。

OSINTの定義は先に述べた通りであるが、筆者が調べた限りではそこに倫理や法といった概念は介在していない。そのため、OSINTと倫理に関する論点は、「"OSINT"を生成するにあたり、倫理に背く・法を犯すアクティビティというのはそれに含まれるべきではないのではないか」という命題に言い換えることができるのではないかと思う。(もし筆者が趣旨を間違って理解していたならば、申し訳ない。)

この論点に関して、「OSINTは倫理・法に背くアクティビティを含まない」という意見も散見された。しかし筆者の私見を述べるならば、「OSINTを生成するためのアクティビティには倫理・法に背くものも含まれる」というのがOSINTと倫理問題に対する回答になる。筆者の言葉で言い換えるならば、「己がインターネットをさまよって調査・分析した結果生成されたインテリジェンスであれば、それはすべてがOSINTに分類される」というような認識である。これは、上で引用させていただいた _roku_ さんの図が非常に参考になると考えており、筆者のOSINTに関する理解もまさしくこの通りである。OSINTを生成するためのアクティビティを大別すると、ターゲットに対して自らが直接関与した痕跡が残るActiveとそうでないPassiveの2つのタイプがあり、Activeの活動をやりすぎると倫理や法律の問題が絡んでくるという認識である。いくつか領域わけがされていても、ここに含まれるすべてのスコープがOSINTを生成するために必要なアクティビティである。

なお、これはあくまで「OSINTの定義的に倫理・法に背く活動がその生成過程で行われているものもある」というニュアンスで述べたものであって、決して犯罪を教唆するような内容ではないことに留意してほしい。しかしながら、あくまでサイバー空間における情報戦指南のような存在であるOSINTに求められるのは情報の正確性、蓋然性、証拠の確実性(再現性)である。インテリジェンスとしての価値を高めるための行動は倫理・法的に疑問が残ったとしても、最終的に生成されたインテリジェンスに倫理的な問題が絡まないのであれば、それは非常に価値のあるインテリジェンスとして享受している組織が多いのではないだろうか。少なくとも、筆者は倫理的に疑問がある手法は用いられていれど、そこから非人道的な言及をしたインテリジェンスが生成されているレポートは見たことはない。現実に、カンファレンスでの発表や有償インテリジェンスサービスのレポートを見ていても「おそらく法的に問題ある方法でIoCを取得しているな」というモノはちらほら存在する。だが、それに対して皆は生成されたインテリジェンスに感謝をしながら自組織のシグネチャに組み込んでいるのではなかろうか。だとすると、多くの組織は倫理・法的に問題のある活動を暗黙的に了承しているということに他ならない。

先ほどまでは「インテリジェンスと倫理」という観点で論じたが、では視点をもう少しミクロに落とし「OSINTを生成するまでのアクティビティと倫理」という観点からも考えてみよう。法や倫理に抵触しそうなアクティビティに対する言及にはどのようなものがあっただろうか。

A「不正アクセスはするな!」
B「許可なく脆弱性検査をするな!」

なるほど、たしかにアクティビティに対しては倫理・法的に問題があることはやめましょう、と説くことができそうである。(しかし、これはOSINTという文脈ではなく"調査活動"のようなニュアンスで語るほうが正確な気がしてならないが)
では、これらの行為がどのような法律に引っかかる恐れがあるのだろうか。おそらく、『不正アクセス行為の禁止等に関する法律』、通称『不正アクセス禁止法』が該当する。法律の該当部分*3を抜粋すると、以下の文面になると思われる。


不正アクセス行為の禁止等に関する法律
(中略)


第二条
４　この法律において「不正アクセス行為」とは、次の各号のいずれかに該当する行為をいう。
一　アクセス制御機能を有する特定電子計算機に電気通信回線を通じて当該アクセス制御機能に係る他人の識別符号を入力して当該特定電子計算機を作動させ、当該アクセス制御機能により制限されている特定利用をし得る状態にさせる行為（当該アクセス制御機能を付加したアクセス管理者がするもの及び当該アクセス管理者又は当該識別符号に係る利用権者の承諾を得てするものを除く。）
(中略)


三　電気通信回線を介して接続された他の特定電子計算機が有するアクセス制御機能によりその特定利用を制限されている特定電子計算機に電気通信回線を通じてその制限を免れることができる情報又は指令を入力して当該特定電子計算機を作動させ、その制限されている特定利用をし得る状態にさせる行為

要約すると「本人の許可なしに認証情報/脆弱性を使って操作をしてはいけない」という内容だろうか。たしかにこれは倫理的にも問題がある行為だし、内容としては妥当な法律であるかもしれない。

では、ちょっと別の事例を考えてみよう。あなたの所属するインテリジェンスチームでは「自組織に関連するサイバー脅威のIoCを収集し、信頼性の高いものをSOCに提供してほしい」というインテリジェンス要求を達成する必要があったとする。アナリストは自組織のネットワーク境界やインターネットから日本に関連するであろうサイバー攻撃関連のIoCを収集し、評価・分析をして継続的にSOCにインテリジェンスを配布することになるだろう。

日本にばらまかれるマルウェアには様々な種類のものがあるが、ここではAgent Teslaという情報摂取型のマルウェアについてとりあげてみよう。
このマルウェアは感染した端末のクレデンシャル情報を収集した後、他の感染者(攻撃者が独自で作成したものの場合もある)から認証情報を盗んでコントロール配下となったメールやFTPサーバに対して認証を行い、盗んだ情報を転送するといった動作をする。
news.sophos.com


例えば、以下の検体は日本のIPアドレスからANY.RUN というオンラインサンドボックスに投稿された、FTPサーバに対して情報を転送するタイプの例である。
app.any.run


ここで一つの疑問が生まれる。『意図的にオンラインサンドボックスにマルウェアをアップロードした結果、他人の認証情報を勝手に使用してアクセスしてしまった場合は不正アクセス禁止法に該当するのだろうか?』と。

。。。筆者が文面を読む限りでは、このようなケースも「不正アクセス禁止法に該当する」のではないかと思われる。いきなり「逮捕！！」という事態にはもちろんならないとは思うが、不正アクセス禁止法は非親告罪である以上、当人や当人を含んだ所属組織に恨みのある第三者によって「あの人、このサービスを使って他人の許可なく認証情報を入力して不正利用しましたよ！！」と告発されてしまったら、当人が貶められるなんてことは十分考えられるだろう。(筆者は法律の専門家ではないため、もしかしたら見当違いのことを話しているかもしれない。そうであったら申し訳ない。)

では検体をアップロードまではしなくとも、インテリジェンスで重要な再現性をとるために、ANY.RUN にある "Restart" ボタンを押してもう一度解析を行い挙動を確認してIoCを整理したとしよう。これは、どうだろうか? 同じく、VirusTotal にある Reanalyze ボタンを押した場合は? 。。。どちらも再度通信は飛んでいくため、アウトな気がしてならない。

「じゃあ細かい操作は一切せずに結果だけ確認すればいいではないか」という話であるかもしれない(そもそも論として、結果を収集するのみで独自で分析をしないという行為はすでにインテリジェンスではないのだが、一旦脇に置いておこう)。では他の誰かがインターネット上に情報を公開するのを待ち、その結果だけを受け取れというのは果たして誠実な行いなのだろうか。これは言い換えれば、「君がやると犯罪になるかもしれないけど、他の誰かがやったものの結果だけを閲覧する分には犯罪じゃないから、誰かがやるのを待ちなさい」という、ただただ実行犯を自分以外の誰かになりすつけるだけの言葉な気がして、筆者は倫理的な問題を抱えているような気がしてならない (筆者の倫理観が狂っているということもあるのかもしれないが)。ここまで疑心暗鬼になるとすべてをローカル環境で分析するしかなくなってしまうのだが、これが「外部のインテリジェンス要求にこたえるための活動のはずなのにそのインテリジェンスの詳細を外に出しにくい」というなんとも不合理な現実を生み出すのである。

これはあくまで一例であるが、そのほかにも権限設定があまいAPI keyや攻撃者が設置したWebshellなど、調査を深ぼりしていくうえで「これってどこまでやったら法で裁かれるんですか?」という場面にはたびたび遭遇する。現実問題、筆者も何度も直面した経験があるため、チームに「これ、やってもええと思いますか?」と議題を投げかけることがたびたびある。そのほかにも、「IPアドレスを入れるとサービスを調査しますが脆弱性検査まではしませんよ」と謡っておきながら、悪性パケットを送り付けているサービスも存在するかもしれない。「hogehoge はしてはならない」と論じるのは容易いが、実際のアクティビティが本当に「hogehoge」を含んでいないことを保証できるかというのは技術に対して深い造詣がなければなしえず、初～中級者にとっては注意喚起をされてもその境界は不明瞭のままであろう。殊更"倫理"に関しては、個人による事象の受け止め方の差が激しく、より一般論的に語ることが困難である。

守破離


ここまで散々倫理・法について述べてきたが、筆者は善悪問答がしたいわけでも倫理に関する哲学をしたいわけでもない。先で述べたかったことは、「OSINTを生成する以上、その生成過程においていずれ倫理・法的な問題に直面する」ということであり、これに疑問を呈する方は、おそらくそのインテリジェンスがどのようにして生成されてきたかについて無知でいられる人間だけであろう(少々、表現方法がよくない気がするが)。

しかしだからと言って、OSINTについて紹介や研修をする人間・組織が「OSINTは倫理や法の問題が付き物だから、ライン見極めながらどんどん調査をしていこうね」なんてことを無責任に唱えることはまずできない。特に不正アクセス禁止法もアウトの境界線が明瞭でない以上、日本では一歩道を外れたら違法になるようなOSINTという存在は、一般論的には制約をかけた状態で紹介せざるを得ないだろう。筆者もOSINTに関する研修を作成したことがあるが、外部の人間にも話す以上不幸があってはいけないと思い、ツールやサービスの紹介では注意事項を執拗に記述していた。このような背景が、「OSINTは倫理・法に背くアクティビティを含んではならない」と考えている人の多くにあるのかもしれない。ある意味、日本における"守"的なOSINTの考え方である。

しかしながら、組織・消費者のインテリジェンス要求に対して少しでも価値の高い答えを返そうとすると、"守"のみの考え方は厄介な"限界"として立ちはだかってくる。このあたりの課題感が、ちらほら見られた「倫理・法の遵守は無理がある」という"破", "離"側にいるアナリストの考えなのではないかと思われる。この課題に遭遇した場合、個人の判断で調査を継続するにはリスクが大きすぎるので「ここまでは調査しましたがここから先は法的にグレーゾーンになります。しかし、深ぼりすればより価値の高いインテリジェンスになると思うのですが調査を継続しますか?」といった具合で組織側の意思決定に委ねてもらうのが最善手になるのではないだろうか。情報処理安全確保支援士などの資格もこのあたりの倫理を縛ってくる一方で、活動の幅を広げてくれるような特権は何一つ与えてくれない。保守的な組織では活動が非常に制限されてしまっているため、真面目に取り組んでいるアナリストほど守的なOSINTに対する限界に嘆いているのではないかと思われる。

なお、本記事も「これがOSINTなんだ!!」といった"守"寄りの内容ではなく、"破"に向かっている捻くれた人間が書いているものである。一般論ではなく、話半分で見てもらうほうがよいだろう。

これからのOSINTの話をしよう

さて、話が少しずれたのでまた本題に戻そう。『Intelligence ≠ Collection』の節において、筆者なりのOSINTの定義とは「組織・顧客のインテリジェンス要求を達成すること目的として公開情報を収集・分析し、 組織の情報戦に関わる意思決定に継続的に貢献すること」であることと述べた。
しかしながら、界隈でここまで様々な意見が飛び交うことを踏まえても、OSINT という単語の解釈は個々人によって解釈に大きな開きがある。ここでは一旦「なぜここまで解釈の幅が広くなってしまったのか」という理由を整理し、それをもとにこのOSINTという単語をどう扱っていくべきか再検討を試みる。

なぜOSINTの解釈がここまで広いのか、に対する一考察

それが虚無ならば虚無自身がこのとほりで
ある程度まではみんなに共通いたします
（すべてがわたくしの中のみんなであるやうに
　みんなのおのおののなかのすべてですから）

まず、どうしてOSINTという言葉にはこんなにも解釈に違いがあるのか、筆者なりにいくつか仮説を立ててみた。

  • そもそも "Intelligence" という言葉の認識が多くの人に誤解されている。
  • 『公開情報』から調査したことを、広義的な意味で"OSINT"と紹介している人・記事がある
  • ネタ的なコンテキストで使われた"OSINT"がそのまま公的な場面で使われる

どれも当たらずとも遠からずな仮説だが、筆者の考えでは"OSINT"という言葉を使う人が増えたことが影響として大きいのではないかと考えている。少々乱暴な表現をするならば、『専門用語の認知度があがりすぎて非専門家がこのワードを多用することになった』ことが現在の事態に拍車をかけているのかもしれない。OSINTという言葉が少々キャッチーな言葉なので、使用することによって検索に引っかかりやすかったりすることもあるのだろう。『Joint Publication 2-0: Joint Intelligence』の冒頭だけを切り取って解説したようなWeb記事を見て、「公開情報をいい感じに使ってもっと価値のある何かにすればそれがインテリジェンスなのか!」といった少々異なる理解をしてしまった方もいるのかもしれない。

それとは別に、「OSINTで特定しましたw」のようなちょっとしたネットミームチックな表現を見て、「これもOSINTって言うんやな」と解釈をした人もいるのだろう。様々な理由が考えられるが、OSINT という言葉が様々なコンテキストで使われるようになった真髄には、その汎用性の高さが背景にあるのではないかと筆者は考えている。「公開情報を使っていい感じに何かしました」というふわっとしたニュアンスで、技術的に詳しくない相手に対してもそのイメージを伝える言葉として優秀なのだ。「〇〇というWebサイトで△△について調べて、発見した××をまた別のツールで...」なんてことをわざわざ言わなくても、「OSINTした」というだけで「あーなんかいい感じに調べたら見つかったんだろうなー」と相手が解釈してくれれば、それでコミュニケーション自体は成立するのである。本来の"OSINT"の意味からは乱れが生じていても、"ある程度まではみんなに共通"するイメージによって相手が都合のいいように解釈してくれる。そのような魔力が、このOSINTという言葉に備わっているのかもしれない。

その一方で、ある一定数の人間にとってOSINTという言葉は "みんなに共通" するイメージから逸脱してしまっている、というのが今回の騒動によって明るみになったことだろう。現に、元来の言葉の意味から大きく外れたものも「OSINT」の派生として解釈されているため、専門家にとってはコンテキストをきちんと把握しなければそれが自分が普段扱っているOSINTなのかを判断できない状況に陥っている。同じような騒動を繰り返さないためにも、「我々はOSINTという単語をどう扱っていくべきか」ということを今一度考え直す必要があるのかもしれない。

我々はOSINTをどう扱うべきか


筆者が考える "OSINT" という単語を使用する上で留意すべき事項は次の二点である。

  1. 単語の共通認識が確立されている組織内でのみ使用すること
  2. そもそもの使用を避けること

しかしながら、どちらの事項についてもこの記事を読んでいる人よりもOSINTという単語を雰囲気で使い続けている人に宛てているので、果たして本記事で言及することで現状が改善されるかというとそれは定かではない。もし上記を逸脱しているような使い方を確認した場合、ぜひあなたが警察として動いていただきたい。

まず一つは、OSINTというワーディングの使用に際して、それ含む専門用語の共通認識が確立されている組織でのみ持ち出すべきという点である。もっともインテリジェンスに携わる業務をしていれば、OSINTに限らずそれにかかわる専門用語は山のように出てくるわけであるが、解釈がブレる最たる例が推定確率言語といった信頼水準を表現するワーディングだろう。推定確率言語はインテリジェンスの信頼性を表現するうえで必要不可欠であるが、これに世界標準的なものは存在せず、どのようなワードで信頼性を表現しても間違いではない。しかし、使用するワードの認識が統一されていなければその信頼性の評価は真価を発揮しないのは明らかである。
en.wikipedia.org


そのため、インテリジェンスチームに所属するアナリストは「蓋然性が極めて高い」や「蓋然性が非常に高い」といった言葉を雰囲気で使い分けているわけではない。「信頼性が99.9%なら"極めて高い"を、80%以上程度ならば"非常に高い"を使用します」という取り決めを組織に認識させたうえで、チームのアナリストにもこの意味での使用を統一させているのである。

筆者が所属するインテリジェンスチームの場合、内部で使用される専門用語は『脅威インテリジェンスの教科書』にほぼ統一されており、意思決定者に語彙の詳細な意味を問われた場合は「教科書のP.〇にあるこの定義に沿っています」と返すことができるようにしている。インテリジェンスサービスによっては「弊サービスは以下のような確証度に基づいて推定確率単語を使用しています」といった共通認識をすり合わせるためのページを用意してくれているものも存在するだろう。
gihyo.jp


これは極端な例であるが、それでもインテリジェンスというものは用語集の準備や意思決定者とのコミュニケーションなどを組織的に取り決めて推進していかなければ、その共通認識をすり合わせること自体が困難なのである。もしかしたら組織内部でのコミュニケーションを円滑にするために、ある組織では一般とは少し異なる意味合いで解釈を統一している単語というのも存在するかもしれない。そのため、第三者同士がいきなり対面して「OSINTが~」なんて話をしても、最悪の場合「全く学習をしていないけれども専門用語を雰囲気で使っている」というケースも存在する以上、本人の意図通りに相手に内容が伝わるかはかなり怪しい。
ちなみに、筆者は「インテリジェンス業務やってます」と言った流れで「業務の一環で"OSINT"もやってますよ」と言った結果、対話相手に「ダークウェブを監視している人」として認識されたことがある。面倒なので訂正はしなかったが、おそらくその組織におけるOSINT業務というのは、ダークウェブをモニタリング・分析して得られたインテリジェンスが主となって回っているのだろう。その組織においてそれが"OSINT"だと定義されているとしても、筆者はそれが間違っているとは思わない。しかしながら、"OSINT"という言葉に対する理解と認識はその人の生活圏によって大きく異っているおそれがあり、例え自分が正しく言葉を使用していたとしても、異文化同士のコミュニケーションになりうるということは念頭に置く必要はあった。皆も筆者のような誤解を生まないためにも、共通認識が確立された同じ文化圏でのみ、インテリジェンスにかかわる用語を使っていただいたほうが賢明である。


そしてもう一つ、これを言うと元も子もないのかもしれないが、OSINTという単語をそもそも使用しないように心がけるということだ。よくよく思い返してみると、筆者はインテリジェンスチームに所属してからかれこれ1年半になるが、業務中に"OSINT"という単語が飛び交っていたことはおそらく1度か2度くらいしかない。アナリストは「〇〇について△△で分析した結果と、それに対する考察です」といった具合で非常に正確な言葉を使用するし、分析を終えたアナリストも「これ、ほんとうにインテリジェンスだったんかな～」という感想を漏らすことさえある。最終的に意思決定者にレポーティングする際は「OSINT」といった体裁を整えた文面を使用するが、フィードバックを終えていない段階で"インテリジェンス"という単語を土俵に出すのは、アナリスト側にとっても勇気のいる行動ではないかと思う。そういった背景があってか、筆者も"OSINT"という単語を持ち出すことは滅多にない。本年筆者がJSACに持ち出した講演のタイトルは「Investigation for Continuous Cyberespionage Based on Open Source (公開情報を基にした標的型攻撃の調査)」であって、情報収集とその分析手法について述べられてはいるが、果たしてインテリジェンスの定義を満たしているかというとそれは要議論であったため、そこに "OSINT" という文面は存在していないのである。*4(内部資料でも使用していない)


忘れてはいけないことだが、OSINTはれっきとした専門用語である。その道に詳しくない人に対して、そうやすやすと濫用すべき言葉ではない。「If all you have is a hammer, Everything looks like a nail (ハンマーしか持っていなければ、すべてが釘に見える)」 なんていう諺にあるとおり、人間は道具を手にすればなるべくそれを使ってみたくなるし、新しい言葉を覚えた日にはなるべくその言葉に当てはめてみたくなるものである。あなたがOSINTという言葉のハンマーを手にしているとき、「打とうとしているモノは果たして本当に釘なのだろうか」という思考は頭の片隅においておくべきだろう。特に、インテリジェンスを生成するための単発のアクティビティをOSINTと表現しているものについては、そっくりそのまま短い日本語で表現できるものが非常に多いのは事実である。「Googleで〇〇と画像検索して見つけた」, 「Shodanで〇〇というクエリで検索した」, 「URLhaus から〇〇にかかわるIoCの一覧を取得した」などである。こちらのほうが理解しやすいし、OSINT警察に突っ込まれることもなくなるだろう。特に公的な場ではさらなる乱れを生まないためにも、正確な単語をチョイスすることを推奨したい。


最後に、筆者は決して「OSINTという単語を俺の前で使うな」と主張したいわけではないことを補足しておく。筆者が伝えたいのは「OSINTというのはあくまで一般人が直感的に理解することが難しい"専門用語"であることを忘れてはいけない」ということであり、インテリジェンスアナリストやベンダーを咎める意図は全くない。
筆者も、『直近1か月分の、公開情報をもとに調査した敵対国に関する国際情勢とサイバー空間上での動向分析、および自社の対応にかかわる提言書です』と言われたら「なんのこと??」と頭にクエスチョンマークが浮かぶが、『Monthly OSINT Report』と言われれば「あーね」といった心持ちで文書に目を通すことができる。話し手と聞き手に用語への共通理解があれば、まどろっこしい言い回しをいい感じに表現できる便利な単語であることは揺るぎない事実である。


おわりに

ここまでOSINTについて論じてきて最後の最後にはしごを外すのも申し訳ないが、筆者は"OSINT"という単語を原理主義的なまでに正しく使うべきだとは思っていないし、究極的なところ雰囲気で使っている人がいても別にいいとも思っている。 要は"OSINT"という単語の存在によって言語コミュニケーションが円滑になり、なおかつ使用者が所属しているインテリジェンスチームが組織に対して価値のあるアウトプットを出し続けられさえすればそれでいいのだ。Shodanでの調査結果を「素晴らしいOSINTですね!」とCIOやCISOがコメントしたことに対して、「いやいやオンラインサービスを利用した調査自体はOSINTとは言わんのですよ!」と角が立つことを言わなくても、"ある程度まではみんなに共通"するものが伝わっていればそれでよいとさえ思う。

しかしこれはローカルに閉じた環境での話であって、このノリを世間一般に対して持ち出すと途端にコミュニケーションのミスや筆者のようなOSINT警察の発現につながることだろう。なぜなら、あなたの想像している"OSINT"と、別の誰かが知っている"OSINT"は似て非なるモノかもしれないからだ。『A Nice Derangement of Epitaphs (墓碑銘のすてきな乱れ)』を"異名のすてきな言い回し"と、聞き手がすてきな乱れによって解釈してくれる保証はどこにもないのである。
サイバーセキュリティの文脈で"インテリジェンス"という専門用語を持ち出す場合、果たしてそれが最も適した表現であるかというのは使用者側が今一度考えたほうがいいかもしれない。


そういえば、筆者がどんなことをしている人間なのか話すのを失念していました。『自組織に対する脅威の調査やそれに関連するシグネチャ作成および脆弱性のPoC検証といったセキュリティ技術・運用支援』と表現するには視点がミクロすぎるし、『多角的視点からの分析による、中長期的なセキュリティ施策および意思決定支援』と語ってしまうと抽象的すぎて何も伝わりません。。。そうだ、『脅威インテリジェンス』やってますと表現するのが一番しっくりきますかね。
......ここまでの駄文に付き合っていただきありがとうございました。

*1:『Joint Publication 2-0: Joint Intelligence』, https://irp.fas.org/doddir/dod/jp2_0.pdf

*2:もしプロセスや能力部分の内容をビジュアルに確認したい方がいらっしゃれば、『The Sliding Scale of Cyber Security』というWhitepaperを参考にしていただきたい。

*3:https://elaws.e-gov.go.jp/document?lawid=411AC0000000128

*4:ちなみに、同じようにJSACにて講演を行った瀬治山さんについても、タイトルは「公開情報により攻撃動向の予測を行う新たな試みと調査手法の共有」であり、OSINT という単語はabstract中にも用いられていなかった。

日本の標的型攻撃で利用される某国製RATの自動解析ツールの使い方

tl;dr

本稿は JSAC2023 で紹介したLODEINFOマルウェアのトリアージツールの使い方をまとめたものです。有事の際はご参照ください。

はじめに

JPCERT さんから "LODEINFO" という日本に対する標的型攻撃で使用されるRAT(マルウェア)が報告*1されて早3年が経ちますが、2023年3月現在でも少しずつTTPsを変えながら継続して使用されています。このような背景からインシデントレスポンス対応者への一助として、下記のGithubにて暗号化されている通信を復号するためのツールを公開しました。

github.com

本ツールについては JSAC2023*2でも簡単に紹介しましたが、使い方には一切触れなかったのでどのように扱うのが効果的か把握できていない方もいらっしゃるかと思います。本稿ではこれまでわかりにくいREADMEだけ書いて放置していた解析ツールの使い方を簡単に紹介します。LODEINFO 関連のインシデントに対応している方の一助になれれば幸いです。

復号の基本原理

LODEINFO が C2 server との communication で使用するデータフォーマットおよびデータの変換方式は様々な記事、カンファレンスでまとめられているので好きなものを参考にしていただければと思います。今回は JSAC2023 で紹介されたPDFの画像を引用しながら説明します。

まず、LODEINFOマルウェアがC2 serverとやりとりするフォーマットはヘッダー部(前半部分)とデータ(後半部分)の2つのデータがそれぞれ異なる方式で暗号化された後、文字列として連結された状態で送信されています。なので、復号するためには固定長のヘッダーを切り分け、それぞれのデータごとに復号する必要があります。

LODEINFO データ構造

具体的には、以下のようなロジックで復号を行います

  • ヘッダー部分
    1. vigenere cipher (文字列のインデックスをベースにした換字式暗号)
    2. 一部の文字列を置換したBase64
  • データ部分
    1. 一部の文字列を置換したBase64
    2. データの一部にsingle byte XOR
    3. AES-256-CBC
    4. QuickLZ

これだけだとイメージがわかないと思うので、具体的な通信データのイメージを見せると以下の図のようになります。黄色部分が固定長のヘッダー部分の文字列なので、そこでデータを区切ってそれぞれに上記の復号処理をかけることで中身を見ることができるようになるわけですね。

具体的な通信でみられるデータ

python を使って通信を復号する

上記の復号ロジックを python のコードにしたものが decode_connection.py となります。同ディレクトリにある requirements.txt から必要なライブラリをインストールするだけで使用できます。*3

github.com

ただし、LODEINFO は検体ごとに異なるAESのKeyとIV, vigenere cipher keyを使用します。検体を解析してそれらの情報を取得し、KEY, IV, VIGENERE_KEY の3変数に設定してください。

コードの変更部分

変数が設定できたら、最後に通信として観測できたデータを SAMPLEDATA 変数へ入れましょう。あとは下記のようにただ decode_connection.py を実行するだけで、データが復号されるはずです。なお、client => C2 server 方向の通信であれば vigenere cipher の key は毎回変わるので、VIGENERE_KEY の変数は使用しません。C2 server => client 方向の通信には検体内部にハードコードされた vigenere cipher key を使用するため、変数に値を入れる必要があります。

#  KEY = a2b_hex("20AD7B28FE0D2D223C48A76E35EE0DA3AEA2B1175D69804605EC43EA4687F785")
#  IV = a2b_hex("8D5291164B7414118D0C8AC7C050FD1E")
#  VIGENERE_KEY = "zlApZbCgpp_"
#  SAMPLEDATA = "AB34bTyi5o_=w8VCUPIIRBvPp08lpwxFeug1tuEhYA2BB2MGCvH...(snip)"

❯ python decode_connection.py 
HEADER(sha512_128=b'e87d884fa9005a7c2963b7a41bca4ad2', payload_size=244)
BEACON(data_size=62, random_data_size=24, date=datetime.datetime(2022, 8, 18, 19, 11, 46), ansi='932', mac_addr='000C2932F71A', computer_name='DESKTOP-81OMVP8', xor_key='zlApZbCgpp_', version='v0.6.3', random_data=b'cV4dXd7e5tIKGmK8ZdHBtw..')

直接コードの変数に手を加える必要があるお行儀が悪いコードになっていて申し訳ありません。ゆくゆくは外部のyamlファイルなどに値を書く方式にしたいかなと思っています。ひとまずは、RATが行った通信を簡単に復号するためのPoCとして利用できるかなと思います。

IDAPython を使って暗号化に必要な情報を一括で取得する

前項では 『AES のKeyとIV, vigenere cipher keyを取得する』とサラッと書きましたが、復号に必要な情報を集めるためには LODEINFO 本体の静的解析が必須になります。つまり、アナリストがshellcodeを読み該当の領域を特定する必要があるのですが、リバースエンジニアリングに精通している人でなければこの作業を行うのは少々酷です。そこで、「スクリプトを使うことで復号に必要な情報を簡単に抽出しよう」という思想から作成したツールが下記の triage.py となります。

github.com

本ツールは IDAPython コードとなっており、IDA Pro を使える方ならば LODEINFO の暗号化された shellcode (BLOB ファイル)をIDA Proで開き、メニューバーから "File" -> "Script files..." の順にクリックして上記の triage.py を開くだけでOKです。実行後は自動的に復号された shellcode とその .idb ファイルが開かれ、検体のバージョン情報, AESのkeyとiv, vigenere cipher key などが Output 画面に表示されていることでしょう。この文字列をコピペして、先ほど紹介した decode_connection.pyに書き込めば通信が復号できるようになります。

triage.py 実行後

なお、「暗号化されたBLOB ファイルがわからない!」という方は、正規の署名付き実行ファイルとDLLの同ディレクトリにあるPE形式ではないファイルを探してみてください。例えば、LODEINFO v0.6.3 の場合は K7SysMon.Exe.db が該当します。(下記画像参照)

BLOB ファイル(K7SysMon.Exe.db)

2023年3月現在で観測している最新のバージョンでも動作することは確認していますので、IDA Proが使える方は活用してください。

おわりに

現在も日本で猛威をふるっている標的型検体のトリアージツールについてドキュメントを残しました。

一部のスクリプトはIDAPythonで書かれているため、IDA Proを持っていない人には使えないというのが現状の課題かなと思っています。もし Ghidra script 版や機能追加の希望があれば、Issueを立てていただけると次回ツールを作る際の参考やモチベにさせていただきます。

皆さんのインシデント対応が少しでも楽になりますように。

*1:https://blogs.jpcert.or.jp/ja/2020/02/LODEINFO.html

*2:https://jsac.jpcert.or.jp/archive/2023/pdf/JSAC2023_1_6_minakawa-saika-kubokawa_jp.pdf

*3:python でエラーが出る! という方は、python のバージョンを3.9くらいまであげてください。古いバージョンだとtyping回りでエラーとなります。3.7 もあと数か月でEoLなのでこの機会にあげてしまいましょう!!

ノンペンテスターの OSEP 合格体験記 (2022/10)

はじめに

2022年10月 に OSEP という中級(?)ペネトレーションテスター向けの資格に合格しました。

私はブルーチーム寄りの開発チームに所属しているのでペネトレーションテストは専門外ですが、それでも知見として有益なものが非常に多い内容でした。
もし私のように「レッドチームではないけど受講を考えている」人がいれば参考にしていただければと思います。

What is OSEP & PEN-300 ??

OSEP とは Offensive Security Experienced Penetration Tester の略で、巷でブームとなっている OSCP ( Offensive Security Certified Professional ) より一段上位に位置するペネトレーションテスター向けの資格です。

www.offensive-security.com


上位とは書きましたが、では具体的にOSCPと何が異なるかというと

  • AntiVirus ソフトなどに対する検知回避技術
  • 企業ネットワーク環境を想定した侵害

への理解が求められるのが大きな違いです。OSCP やその他一般のペネトレーションテスト学習サービスの場合、ハンズオンのために用意される環境というのはマシン1台でそれのroot shellを取得することが目標というのが多いです。そして、内部のマシンはWindows DefenderやAnti-Virusなどが導入されていないノーガードなマシンが大半です。しかし現実の企業環境はそうではありません。一つのマシンを完全に侵害した後はより侵害する価値のあるマシンへ攻撃者は移っていきますし、もちろん Anti-Virus ソフトウェアが導入されている企業も多いです。ソフトウェアアップデートも行っているためメジャーな脆弱性も簡単には刺さらないでしょう。このようなより実践的な環境で検知機能を掻い潜り、ネットワーク全体の侵害を目指すというのがこのOSEPという資格のメインテーマとなっています。これはOSEPのためのトレーニング PEN-300 のコース名が『Evasion Techniques and Breaching Defenses』となっていることからも間違ってはいないと思っています。

そのため、HackTheBox の Easy box のノリで作成した meterpreter 製 reverse shell file や権限昇格の調査に使う winPEAS なんてそのままuploadすればすぐに検知されてしまいます。これらの既存のツールに頼り切るのではなく、自分で脆弱性やexploitの原理を学び、コードを書き、実際にターゲットマシンを侵害するための手法を学ぶことができるのがこのPEN-300コースです。

なお、PEN-300 で学ぶ Evasion の対象は、以下のような自動化された検知メカニズムを対象としています。

そのため、ログ分析や脅威ハンティングと言った ブルーチームの人間による検知を回避する ことまでは対象としていません。トレーニングで紹介されている手法をそのまま使用するとすぐにEDRやSIEMでのクエリに引っかかってしまうということは十分あります。しかし、PEN-300 のトレーニングにはAntiVirus/アプリケーションホワイトリスト/Windowsイベントログが導入された検証用Windowsマシンが用意されているため、『イベントログレベルまでevasionしてやるぞ!!』というモチベーションのある人はここまで拘ったexploitの検証をすることもできます。私はブルーチーム寄りの人間なので、『自分が作ったexploitがイベントログとしてどう見えるのか』 =>『ではイベントログから消すにはどうしたらいいか』 => 『消えたけど何かオプションを有効にすることで検知できる手法はないか』とあれこれ試行錯誤しながらトレーニングを楽しんでいました。自由に疑似企業環境を触れる機会なんて滅多にないので、非常に有意義な時間だったと思います。

Examination & How to pass

正直なところ、試験の詳細やトレーニング内部で扱っているラボの内容、きちんと学んだ方がいい内容については先人の素晴らしい方々がブログにて説明してくれているのでそちらを見ていただいたほうがいいかなと思います。

GkKeeg さん『完全未経験の文系事務員がOSEPを取得するまで』
qiita.com

おまどん さん 『OSEP: OSCPの続編的な資格を取った話』
ommadawn46.hatenablog.com

yuyuyu_sec さん『OSEP受験記』
yuyuyu-sec.hateblo.jp


自分が書いても二番煎じだと思うので、いくつか自分なりのポイントをまとめます。

試験基本

前節に書いた通り、OSEP は企業ネットワークを模した環境のペネトレーションテストの資格なので、試験も実際の企業を模した大規模ネットワーク環境で構成されています。用意されているマシンの数は多いですが入り口は限られているので、企業ネットワークへの侵入口を見つけてそこを足場としながら横展開を繰り返し、最も価値のあるマシンへ向かって進んでいくことになります。
そのため、試験時間もとにかく長く、

  • 47時間45分の実技試験
  • 実技試験終了後 24時間以内のレポーティング

という約72時間ぶっ続けの試験となります。正直なところ、しばらくshellが取れないと頭がおかしくなりかけます。当たり前ですが試験中に"寝たいです!!"とチャットで提言すれば仮眠もできるので、詰まったら潔く横になりましょう。自分は合格点に達するまでは緊張から横になっても一睡もできませんでしたが、安全圏に入ると7時間ほど寝られました。

合格要件

OSEP 試験は、以下のいずれかの条件を満たした場合に合格できます。

  • local.txt, proof.txt という、企業ネットワーク内部の端末を侵害すると得られるスコアを合計100ポイント以上になるまで取得する
  • secret.txt という、企業ネットワーク内部で最も価値のあるマシンを侵害すると得られる情報を提出する

侵入口から secret.txt を入手するためのパスは複数存在しますが、secret.txt を取得できそうにない場合は100ポイント以上獲得するために複数のパスからの攻略を試す必要があります。
自分は当初「絶対にsecretをとってやるぞ!!」という意気込みで受けましたが、試験開始24時間経過後くらいにその手前で詰まってしまい、焦りや精神的な辛さからプライドを捨てて別のパスを探して攻略を行い結局100ポイント以上獲得の方で合格しました。

secret.txt 獲得の直前までに17時間かかったので、早々にプライドを捨てていれば約19時間で合格点には達せたかなと思います。一番時間を要したのは入り口で、入り口から足場を築くまでに10時間を要して本当に気が狂いそうになりました。自分はOSCPの実技試験を7時間で終えたので正直OSEPを舐め腐っていたのですが、そのバチが当たったかなと思っています。そのあとは順調に進み、自分が見えている範囲でマシンが残り2台というところで時間切れになりました。なので、複数あるパスの一つで詰まったときはプライドを捨てて別ルートに進んだほうが精神衛生上いいですしオススメです。

最後に、これらのスコアとして計上するテキストファイルはスクリーンショットを取得のうえレポートに添付して提出する必要があるのですが、RDP でのスクショはNGということだけは注意してください。せっかくshellを取得してもスコアとして計上されなくなってしまうので、面倒ですがここからさらにmeterpreter shellを接続させたりimpacket-psexecを使用したりしましょう。詳しくは公式を確認してください。

help.offensive-security.com

勉強方法やツール

これに関しても試験を受けた方々がすでに語られていますが、本試験を合格するだけならば「全18章構成のトレーニングマテリアルを自分の頭の中できちんと理解できるまでやりこみ、6つ用意されている企業模擬環境のLabを『完全に理解した』 状態になるまで取り組む」ことが一番地道でありながら近道なんじゃないかなと思います。

前節で紹介したおまどんさんの合格体験記によると、OSEPの試験は2021年11月の新形式から難易度が上がったらしく、いわゆる「素直」な問題ではなくなったらしいです。確かに自分も「トレーニングマテリアルに載っているやり方をそのままやるだけでは無理だな」と思う場面に試験中何回か遭遇しましたし、そもそも全く書かれていないexploit vectorを自分でググって探してくる作業もありました。しかし、既存のツールに頼り切ったenum., exploitをするのではなく、泥臭いenum.をしたり、「exploit が成功しないのではなく検知されてしまっているのでは?」と仮説を立てたときにすぐに手が動く下地を作れていれば問題ないんじゃないかなと思います。この下地はトレーニングマテリアルを丁寧にやっていればできていくはずなので、「難しくて何もわからん」となっても焦らず丁寧にやっていきましょう。1章ずつ丁寧にやっていけば、自分のようなnoobでも自作できるexploit toolの幅は広がっていきます。意地の悪い書き方をするならば、「試験ですぐ使用できるような自作の検知回避用ツールをどれだけで準備できるか」で心の安泰が異なりますし、Windows やそれに伴うAnti-Virusソフトの仕組みへの理解につながるんじゃないかなと思います。例えば、以下のような事項に対して自作のツールがすぐに出てくれば準備としてはOKですし、ダメならば試験までの準備が足りないのではないかと思われます。

  • AMSI (Anti Malware Scan Interface) に検知されてしまうので、AMSIをbypassできる powershell コードを実装する
  • AppLocker ( アプリケーションホワイトリスト) に実行制御されてしまうので、bypass して任意コードを実行するコードを実装する
  • PsExec を使用して横展開したいが検知されてしまうので、Windows から Fileless lateral movement するコード(DCE/RPC インターフェースを触ってサービスコントロールマネージャからサービスの実行)を実装できる
  • mimikatz の実行ファイルが検知されてしまいpowershellのログも残したくないので、自作でlsassのメモリを触りパスワードをダンプするコードを実装する
  • PrintSpoofer を使って権限昇格をしたいが検知されてしまうので、printerbug と pipe を利用してSYSTEMアカウントを偽装したプロセスを生成する (超重要)


とまぁ人をビビらせるようなことを書きましたが、コードの雛形は有志の方がGithubに公開してくれています。以下のプロジェクトを参考に仕組みを理解し、必要な部分のコードを埋められるようになりましょう。

github.com

ここまでは主に Evasion のためのテクニックについて書きましたが、企業ネットワークに対して横展開を進めていくためにはWindows Active Directoryの知識もたいへん重要になります。詳細はトレーニングマテリアルの12章あたりから書かれているため個別に別途教材を買って学ぶ必要はないと思いますが、「Zerologonの脆弱性使ってEasy Win」なんてことはあるはずがなく設定不備や過剰な権限を利用していくことになるため、exploitation に使える材料は揃えておいたほうが良いでしょう。私は以下のプロジェクトをよく参考にしていました。

github.com


そして、Active Directory 環境のenum.で欠かせないツールとして BloodHound がありますがこちらはトレーニングマテリアルで紹介してくれていません。あるとないとではenum.に雲泥の差がでるので、Labで使い方を学んでおきましょう。きっと試験でも役立ちます。しかし、便利だからといってBloodHoundに頼りすぎると試験で痛い目を見ると思うので、手動のenum.方法もきちんと学んでおくことをオススメします。これは、OSCPにおけるautoreconの立ち位置と同じですね。

github.com


最後に自分の勉強方法について軽く紹介します。自分はトレーニングのエクササイズ全部を1周、Labを2周して自作のチートシートを2週間くらいかけて作り試験に臨みました。チートシートは以下のような感じで、自分の知識を全てダンプしたものをHackMDに残しておいて困ったときに検索できる状態となっています。

自作チートシート


別にチートシートを作る必要はないのですが、自分の場合これをすると知識の整理ができるのでOSCPのときも同じやり方を取りました。チートシートは試験時間中半分くらいしか使わなかったのですが、HackTheBoxなどをやっていて時々起こる「方針が何も分からなくてただただ Google 検索しているだけで時間が過ぎていってしまう状態」があまり訪れなかったのでよかったのではないかと自己評価しています。

PEN-300受講のススメとトレーニングから得られるもの

顧客ロイヤリティを測る指標としてNPSというものがありますが、NPS風に「あなたはPEN-300を他人に勧めたいと思いますか?」という視点から本研修を振り返ってみると、おそらく10をつけるのではないかなと思います。お勧めする対象は、オフェンシブ/ディフェンシブ/オペレーションを担当しているエンジニア全てです。ここまで幅広い対象に対して強くオススメするのには理由があり、PEN-300を通して学べるものにはぱっと思いつくだけでも以下のようなものがあります。

  • 「AntiVirusだけだとなぜ防御ができないのか」に対して具体的な理解をすることができる
  • 攻撃者が侵入後にどのようなツールを使用して調査をするのか、痕跡としてどのようなイベントログが残るのか、イベントログを出さずに調査できる手法としてどのようなものがあるかを知ることができる
  • 堅牢な Active Directory にするにはどんな設定を見ればいいか、とりあえずWindowsサーバを構築するとどのような権限が付与されるかを理解することができる

これらを疑似企業環境を通して学ぶことができるのは非常に強力で、唯一無二の研修なのではないかと思います。

少々話は逸れるのですが、一方で私はPEN-200(OSCP)の研修をあまり人に勧めません。それには、以下のような理由があります。

  • 現在はHackTheBoxやTryHackMeといったより安価で体系的にまとまっているペネトレーションテスト学習用サービスが存在する。そちらを利用しても良い。
  • 今どき、2015年前後のPoCを刺すだけでshellを取れる環境はあまりない。
  • 試験環境があまり実践的とは思えない。(弊社ではマシンガチャとか呼ばれている)

しかし、PEN-300 はこれらの問題は全てカバーされており、環境には最新のパッチが当たっていますし、Labや試験は生きたネットワークを想定しているため非常に実践的です。「攻撃者がどのような視点で見ているのかを知る」という意味でも、自分はこのPEN-300の方がオススメできます。Twitterから「いきなりPEN-300できます?」という質問もいただきましたが、初期アクセスや権限昇格についてはカバーしていないというだけで、2021年以前のHackTheBox easyが何も見ずに30~40台root取れる能力があれば大丈夫だと思います。Labでも試験でも入口に対する深いenum.は要求されないので、方針がわからず詰むということはないはずです。

特にブルーチームに所属している方々は、ベンダーが公開しているレポートに対して深い理解ができるようになるためその点でも非常に効果があると感じています。自分はトレーニング中に「検知されたくない! イベントログもなるべく隠したい!!」とコードを改良していたら最終的に国家APTがよく使うようなRATのローダのようなものが出来上がり、「あーなるほどEvasionを突き詰めていくとこうなるんだなー」と感心しました。Evasion の技術を正しく知るということは、マルウェア解析やインテリジェンス生成の精度にも大きく影響します。普段ニュースやレポートを見てポエムを垂れ流すことしかできないという人も、PEN-300 を学ぶことで攻撃技術を正しく紐解いて具体的な防御へ活かしていくことができるでしょう。


OSEP の合格を目指すあなたへ

最後に、現在PEN-300を受講している人やOSEP取得を考えている人向けにちょっとしたアドバイスを上から目線でします。

家族がいる方はまず理解を得よう

意外とこの内容が書かれている記事がないのですが、家族と一緒に過ごしている環境で Offensive Security 系のトレーニングに挑戦する場合、受講する前に絶対に家族に話をして理解を得てから始めたほうがいいです。

弊社の資格支援制度は試験合格後にその費用全てを賄ってくれる形式となっています。しかし、30万円近いトレーニングを一旦自腹して「これ世間でも有名で評価されている研修なんだけど、転職にも有利になるんだわ。先行投資！先行投資！！」なんて説明した挙句、3ヶ月近く夜遅くまで仕事部屋に篭って体調悪そうな顔して家族と接していたら「この人、情報商材に騙されているんじゃないだろうか?」と心配されます。

ここまで行かなくても3ヶ月間のプライベートな時間はほぼ全てトレーニングに捧げることになりますし、72時間の試験と向き合う場合家族へのサポートはできなくなるため、数日の身の回りのことは家族やパートナーに全てお任せすることになります。誤解やすれ違いを生まないためにも事前にしっかりと話をして、トレーニングが終わった後にはたっぷり家族サービスをすることを約束しましょう。

ぶっちゃけ独占資格系のものでもないので、家庭環境を悪くしてまで取るような資格ではないと思います。

「まぁうまくいったからいっか」をなるべく解消する

HackTheBox や OSCP を受講した人は、Labに取り組んでいる最中以下の内容でかなり試行錯誤したのではないかと思います。

  • 「脆弱性がある」と思った(推測した)箇所は本当に脆弱なのか?
  • Exploit code は正しく動いているか? (間違っていないか? 細かい修正が必要か? )

OSEP でもこれらにもちろん悩まされるのですが、これに加えて「Exploit は可能だがペイロードが検知されているのではないか?」というポイントにも気をつける必要があります。「Excesize のやり方でうまくいったからいっか」と思ってコピペだけしていると、Labや試験で痛い目に合うでしょう。これは「Excesize の資料が約2年前をベースにしているけれども最新のAnti-Virusソフトはすでに対応されて回避できなくなっている」ことを意味している場合があります。LabでExploitが成功しなかった場合、「何が原因で検知されてしまっているのか」を根気よく探す訓練はしておくことをオススメします。

あともう一点、Post Exploitation 目線でもお話しすると、いくらadministrator shellを取得したからといって取り返しのつかない作業をいきなりやることはやめたほうがいいです。例えば、サービスアカウントやadministrator のパスワード変更などです。OSEPの試験やLabは単体のマシンを攻略するのではなく、生きたネットワークを攻略することになります。なので、サービスアカウントが使用していたパスワードはネットワークで生活している特定のユーザのパスワードかもしれませんし、いくつかの管理端末上で使い回されているかもしれません。そのようなことを考慮せずに「WinRMから正規ユーザとしてログインしたいからパスワード変更!!」とかをいきなりやると横展開に必要な情報が消えて詰むことがあります。私はとある癖が抜けず、Labの最後が攻略できない理由が癖でやっていた自分のクソオペレーションのせいだと知ったときに絶望しました。特に試験中だと取り返しのつかない作業をしてしまった場合はネットワークのマシン全てをリセットする必要があるため、本当に手が震えると思います。自分のような失敗をしないためにも、御行儀がいいやり方での攻略をすることをオススメします。

困ったら仲間を見つけて聞こう

Offensive Security training のスタンスは『Try Harder』なので、わからないことがあっても基本的には教えてくれません。しかし、自分は『15分迷ったら聞いてね派』なのでこの考えは好きではありません。これは考え方の違いなので文句を言ってもどうしようもないのですが、同じ考え方をしている人は受講者の中に必ずいるはずです。考え方を変えて、そういう人を見つけて知見を共有しましょう。
Offensive Security の training には受講者のみが入れるフォーラムと誰でも入れるdiscordがあります。どちらかに書き込むか、"plz DM!" などと書いている人を見つけてDMを送り受講者通しで交流をしてみましょう。
discord.com

自分は「ラボのできているところまでのレポート見せ合いませんか?」とガバガバ英語で交流して、お互いにラボでやったことをコマンドレベルで共有することができました。そのおかげでもっと楽なやり方や便利なツールを知ることができたので、自分のような能力の高くない人ほど閉じこもりすぎず他人の力も借りた方がいいのではないかと思います。

......とは書きましたがこちら側からもGiveができないと1から10まで聞くことは難しいので、堅実に Excesize をこなし、Labを進めて詰まってきたら交流をしてみましょう。ここまでくれば自分でも「試してみたこと」「うまくいったこと」があるはずなので、いいGive and Takeができるはずです! Offsecのstaffは当事者ではありませんし、すでにパスした人の情報も半年すれば環境が違っているので、最も役に立つのは今トレーニングを受けている仲間の情報ではないかなと思います。

おわりに

合格ツイートに対して意外と反応があったので、合格体験記と称して知見をアウトプットしました。伝えたいことを一言で表すならば、「別にOSEP試験に合格しなくても、PEN-300を受講して学べるものは大きいので興味と体力と時間がある方にはオススメです」になります。

資格の話をすると「意味ある派」と「意味ない派」が現れて対立する姿が見られますが、私はどちらかというと「意味ない派」の人間です。OSEPそのものが価値を創造しているわけではないですし、PEN-300を通して学んだ知見をどう業務に活用するかの方がよほど大切だと思います。しかし「資格を取っても意味がないよね」=「意味がないから勉強をしなくてもいいよね」という考え方は間違っていると思っていて、特にPEN-300には 攻撃/防御/運用 全ての人にとって重要な知見が詰まっていると私は考えています。特にブルーチーム寄りの仕事をしている私の見方でも、「この程度の知識は理解しておかないと攻撃を絶対に防げないし気付かないよな」と思う部分は多々ありました。本ブログの内容を見て「1=1みたいなこと書くなよ」という感想を抱いた人は本当に「OSEPを取得する意味がない」人だと思いますが、「うーんこれどうやって検知するんだろう?」という疑問がわいた方は、勉強をするための一つのきっかけとして、OSEP / PEN-300 の受講を検討してみるのはいかがでしょうか。

最後になりますが、もし受講に悩んでいたりLabで詰まっていることがあれば(日本語限定で)わかっている範囲で答えますので、TwitterにでもDMしてください(ただし、捨て垢とかからは怖いのでやめてください。。。)。試験内容までは答えられませんが、いくつか参考になることをお話しできるかなとは思います。それでは👋