はしがき
・著者は、文章を書くのが苦手です。
・この記事は、大変長く冗長になっています。
・この記事は、間違っていることを多く含んでいる可能性があります。
・この記事は、あなたの学習における大きなネタバレとなる可能性があります。
・この記事は、誤字・脱字が多いです。
記事の目的
本記事は、OSCP取得の直後から著者が歩いたOSEP取得までの過程を残した記事です。
記事の妥当性
私自身は、自己学習の範囲内で1年ほどのセキュリティの経験しかないただの事務員です。業務で診断業務やペネトレーション・Red Teamingをしたこともなければ、大規模なシステムやサーバの管理・プログラム開発をしたことはありません。よって記事の内容の妥当性には大いに疑問が残ると思います。一方で完全な未経験ながらの視点や疑問を残しつつ、入門者がどういった行動に出るのかという点を残すことは意味があることだと著者は思います。
突っ込みどころが満載かと思いますが、もしも指摘点等があればお知らせください。
OSEPとは
OSEPとは、 Offensive Security Experienced Penetration Tester の略で Offensive Security 社によるAnti-Virus等の防御策を回避等し、一般的な組織のネットワークの侵害技術を図る認定資格です。日本語でいえば、「攻撃的セキュリティ熟練ペネトレーションテスター」といったところでしょうか。 合格するためには、初期調査(Initial Recon) → 初期攻撃・足がかり(Foothold) → 侵入後調査(Post Exploitation) → Privilege Escalation(権限昇格) → 完全侵害 (Fully Compromise) & 侵害後調査(Post Exploitation) → 横移動(Lateral Movement) といったOSCPで学んだ基本技術が前提として求められます。さらに現実的な環境では、Antivirusなどの防御策が取られていることが普通であるため、これらを回避し攻撃の実行を妨げられないようにする技術を身に着ける必要があります。
OSEPを取得するための試験に挑戦するには、必ずその試験用の学習コースであるPEN-300というものを購読する必要があります。購読する必要があるだけで、購読した資料を使って実際にコースの学習をする必要は強制ではありませんが、しない人は・・・いるのかな?という感じです。
OSEP取得を目指した際の私のレベル
ネットワーク
WireSharkやTCPDump等のパケットアナライザーを使用して、トラフィック内容を理解したりすることに抵抗はありませんでした。
ルーティングプロトコル等の深い理解はありませんでした。現実の攻撃では、ルーティングプロトコル等は、主にLAN内における攻撃(spoofing等)を実行する際に理解が求められると思っています。ただこれらの攻撃を再現するのは、コスト的に問題なのか技術的にめんどくさいかはわかりませんが、能動的にこれらの攻撃を学習できる仮想環境はあまり見かけません。よりRed寄りなテストほど、理解が求められる部分になると思います。
クラウド
全く分かりませんでした。現実目線で考えれば、この分野に弱いのは致命的だと思います。個人的に今後強化していく優先事項です。ただ試験ではすべてオンプレの環境での侵入技術を問うものであるため、この分野の知識が問われることはありません。またセキュリティの初学者がいきなりこの分野に手を出しても、そのレベルの理解で手が届く学習リソースが少ないし、基本オンプレである程度経験を積んでる人とかをベースにしている話が多いと思います。だから、これについては、個人的に学習順序がおかしかったかなとは思ってないです。
プログラミング
C,C++,PHPあたりは読もうと思えば読めるぐらいでした。その他の言語についても、コードが提示されればとりあえず読み、なんとなくやってる処理が想像できるぐらいではあったと思います。
C#,Pythonあたりは、基礎文法は知っていて、時間はかかりますが書こうと思えばなにかは書けるぐらいでした。正直なところ、あくまで業務ではないレベルでセキュリティの勉強をしていると、あんまりコードを書くことはなく、Path Tarversal等でソースコードが見えてしまっていたり、侵入後に興味深いバイナリとかがあって、それをデコンパイル等して、そこから脆弱性等を見つけるといった「読み」に傾倒していることが多いと思います。この分野で比較的コーディングが出てくるといえば、Exploit Developmentだと思いますが、ここでのコーディングはExploitの全過程をプログラムで単に自動化しているだけだと思います。書くこと自体は、順番に特定の文字列をprint関数で表示するようなもので難しくなく、その過程、つまり脆弱性を見つけたり処理を追っていき組み立てるのが本質でそれが難しく、考えればわかりますがここの部分の多くは「読み」やロジックを組み立てることであり、別にコードを書くといってもプログラミングの能力(具体的に定義してないですが)が鍛えられるわけではないと思います。
サーバアプリケーション
Apacheがヘリコプターだと思ってたのが懐かしく感じます。HacktheBox等を通して、いろいろなサービスに触れてきたので、ある程度知名度のあるサービスやアプリケーションは知っていて、未知のサービスでもマニュアルを参照して危ない機能を見つけ出すための考え方ぐらいは身についていたと思います。例えば、DevOPS関連のサーバだなと感じたら「シェルと対話したり、特定のコードを走らせる機能があるかも?」なんて考えるようになります。CMS等であれば、「データはどういうふうに保管している?バックエンドのデータベースサーバが必要であれば、接続用のクレデンシャルが落ちているはず・・・」と基本的なところではありますが、知らないサービスでもなんとなく想像できるといった感じです。個々のサービスに精通することももちろん大切だとは思いますが、それよりも未知のサービスを見たときにある程度機能が想像できて、攻撃者にとって都合のよい危険な機能とかクレデンシャルの扱い方を予測する力が重要だと思います。
オペレーティングシステム
Windowsがユーザフレンドリーで、Linuxの黒い画面が怖いと思っていたのが懐かしいです。Windowsに関する認証・認可周りの理解は、下記の記事等を参考にしつつ、ぼんやりですが理解はしていました。具体的には、NTLM Authentication, Kerberos Authentication, Access Token, DACL, SACL, ACE, Access Rights等のキーワードに関連するところです。OSが異なる場合に、多分攻撃者からして一番気になるところってたぶん認証・認可周りの制御だと思います。時点で防御機構とかになってくるのかなぁと思います。Windowsに関する防御機構については「名前は聞いたことあるけど攻撃でどう作用してくるかはわからない」といったレベルです。知れば知るほどWindowsも相当に複雑で、Windowsは一昔前の自分みたいな一般人の使用も想定されるOSであり、ユーザフレンドリーなところや安全性を実現するために様々な処理が走っていて、それを実現するために複雑になっていることに少しずつ気が付いてきていました。
Linuxは、正直どの程度理解しているとかはわかりません。侵入後に動き回るのにこの操作をすればよいっていうのはできるぐらい、もしくはやりたいことを実現するためのコマンドを探し出す能力ぐらいならあったと思います。各Enumerationのスクリプトがあげてくる情報も大体は意味が分かっています。D-Busとかマイナーな分野になってくると昔勉強したノートを読み返さないとわからないってぐらいです。Windowsに比して、一般ユーザの使用が想定されていなく、防御機構等も薄く攻撃面で理解しておかなければならないものはWindowsに比べ少ないと思います。
英語
ずっと変わってません。
OSEPを選択した理由
OSCPの合格後の主なPathとしては、OSWE, OSEP, OSEDのどれかになると思います。人によってはOSWPや最近追加されたOSWAになると思います。私が、OSEPをまず真っ先に選択したのは、やはりペンテスターへのあこがれです。
もちろん現実では私みたいなのがいきなりその道に入れないことは分かっています。案件の数といった世の中の需要を考えれば、Webの脆弱性診断といった方がまだ未経験者には入りやすいと思います。※ その意味でOSWEを選択するのが一般的だと思います。OffsecのOSCP合格メールにも「次はOSWEでもどうですか?」といった内容があります。OSWEで要求される基本的なWeb攻撃は、主にFile Upload Abusing, SQL Injection, Command Injection, Insecure Deserialization, XML External Entity Attack, Local / Remote File Inclusion, Path Traversal / Server-Side Request Forgery, Server-Side Template Injectionあたりだと思います。Client-Sideの方が現実の診断業務ではよく見かけ報告する機会が多そうでRCEにつながる致命的なものは少ないと思いますが、試験はシェル奪取が最終ゴールなのでとりあえず除外しています。
一方でこれらについては、過去にある程度網羅的に学習していて、各攻撃ごとにある程度の深みまでは勉強したことがありました。もちろん約1年前の話なのですし、正直記憶が怪しくノートを見返さないとわからないことが多いですが、それでもノートさえ見れば思い出し、攻撃を再現できるレベルではありました。またWebは、ペネトレーションでは、CommonでHigh Vauleなターゲットで重要だと思いますが、幸運なことにレイヤが高いため、きれいに別分野としても切り分けられるところだと思います。Exploit Developmentや今回のような回避技術については、どうしてもReversing等の技術が共通的に使われていて結果低いレイヤの話になってきて、Webとは距離が遠いと思います。だからOSEP,OSWE,OSEDといったレイヤが上下するやり方だと「なんとなく非効率かなぁ」なんて思ってました。その考えのもと自分はやはり低いレイヤが好きで、また前述したように自分の欲求には勝てなかったので、OSEPが私の中で見えていたPathでした。
※もちろんこれは、診断業務がペネトレーション業務より劣っているとかそんな話ではありません。どちらも私にとっては尊敬できる仕事で本当に格好いい仕事だなと思います。
PEN-300受講前にやったこと
はっきり言って特に何もありませんでした。OSCPに挑戦しようと思ったときと同様に、「絶対合格するわ!」ぐらいのある意味幸せな思考をしていて、前準備はまったくしませんでした。以下のブログあるように、「HacktheBoxのProLabが前準備に良いという声があったけど必要ない」という意見は、私も同じ意見です。また私のOSCPの長々とした体験記を見てくれた方にはわかると思いますが、そもそも1回目の試験が落ちた直後にクールタイムで暇なときに受講を開始しています。ですから準備なんてものは本当に0でした。能天気すぎる。
PEN-300受講における前提必須条件
OSCPに合格するだけの技術
OSCPに落ちてから受講を開始した私が言うのもなんですが、このレベルの知識は確実に要求されます。基本的な侵入技術については一切説明がありません。
プログラミング能力
OSEPにおいて最も重要だと言える能力がこれだと思います。これまでセキュリティの勉強においては、あまりコーディングをしてこなかったと前述しましたが、OSEPは大きく異なります。自分で検知を回避するツールを作成したりする必要があるため、どうしてもプログラミングがある程度必要になってきます。いずれの言語でもよく、簡単なプログラムで良いので、とりあえず何か自分で作ろうと思って作ったことがあればそれでよいと思います。大事なのは、その状態から「んじゃコーディングしてね」と言われて投げ出さない姿勢で、それさえあればOSEPで問われるコーディング能力は自然と身についていきます。コース資料では基本的な文法の説明がありませんが、何らかの言語を触ったことがあり、一通りの基礎文法を知っていれば理解できる内容になってます。
またOffsecのコース資料にも、このことについて冒頭で述べられています。これは「Is programming required for penetration testing?」といった問題提起から始まり、「formalなプログラミング教育は必要ではないと思うけど、プログラミングに関する幅広い知識はとても役に立つ」と言っています。私からしたら少しぼやけている回答で、コースを学習した過程を振り返ると、結局ある程度のプログラミング能力は必要だと思います。ただハリウッド映画にあるような高速にガリガリすらすらかける必要は全くないと思います。私は以下の動画が好きです。(どうでもよい)
PEN-300受講における前提推奨条件
ここでは「事前に知っておかなくても試験自体は合格できるけど、予め学習しておいた方が学習の効率と効果が上がる」というものを上げています。
オンプレミスのActive Directoryに関する基礎知識
オンプレミスのActive Directoryを利用しているある程度の規模のネットワーク環境への攻撃が舞台となるので、基本的なオンプレADの理解はある程度あった方が良いと思います。(以降単にADといっていたらオンプレADのことだと思ってください。)特にAD Objectとか何?といったレベルだとBloodhoundが示してるノードの意味とかも分からずに操作していると思います。私も最初は「きれいなアイコンだなぁ()」ぐらいで、適当にポチポチしてよくわかっておらず、けどそれでもなんとなく答えが見つかるみたいな状態でした。GUIのよくもあり、わるいところはこういったところだと思います。ですから基本的なActive Directoryの基礎知識を身に着けておきましょう。以下のサイトはADにおいて「あれここはどうだっけ?」と感じたときによく参照するサイトです。
C#
OSEPでのツール開発はC#かPowershellがメインとなります。去年の夏ごろにたまたま一通りのC#の基礎文法を入門的な書籍を用いて学習していたので、朧気ではありましたが理解はありました。なので再度コーディングしていくうちに思い出しながら書いていたと思います。もしこの事前のC#の理解がなかったとしたら少しつらかっただろうし、もう少し合格まで期間が必要だったと思います。コース資料にあるコードを多少改良するだけでも合格に達するツールは作れると思いますが、それだとあまり学習としての効果が望めなくただ資格を取るだけになってしまうと思います。せっかく高いお金を払っているのでしゃぶりつくしませんか?
Powershell
Powershellをメインで開発をしていくなら、もちろんC#と同様にある文法の知識が必要だと思います。自分はC#の方が好きだったのでいまだにPowershellでゴリゴリかける自信はないです。正直Powershellにアクセスできるなら、そこから言語的な機能としてPowershellでできてC#でできないことあるの?という恥ずかしいことを言ってるかもしれないですが、そんな認識です。読むことはC#を読むことと大差がないので、「ある程度のコマンドレットが使えればいいかな」というのが個人的にPowershellに今感じてるところです。
PEN-300受講におけるその他の推奨事項
ここでは「PEN-300受講における前提推奨条件で紹介したものほど優先度は高くないが、理解があれば学習がより効果的」というものを上げていきます。個人的には、以下に挙げる要素は、確実に今後のセキュリティの世界での理解を助けるもので、特にマルウェア解析などではWinAPI等の理解は当然のように出てくるものだと思います。ですから事前に準備できなくても、コースの中で「少しでもものにしてやる」ぐらいの気持ちはあるとよいと思います。
C言語と低レイヤ操作
私はプログラマではないので言語の歴史はよくわかりませんが、それでもC言語が古株だってことぐらいは分かります。そしてその古株は今でもバリバリの現役言語なわけです。んじゃあ具体的にどこで?って話になると、それは使えるリソース(メモリとか)に限りがあり、パフォーマンスを追求しなくてはならない組み込み系のシステムとかがまず挙げられると思います。私のようなひよっこなセキュリティを学習している人間からするとその辺のハード系の領域はまだ手足が届きませんが、なんとか手足がちぎれそうにはなるけど届く領域ではOSがいます。そしてOSの本質に近づこうとする場合、やはり「C言語からは逃げられない」というのを感じてきます。
PEN-300のツール開発の過程では、多少なりともメモリ周りの低いレイヤの話が出てきます。そしてメモリの内容を取得したり、メモリの内容を書き換えたりといった操作をします。もちろんそこまで複雑な操作ではないため、正直に言えば、ポインタや構造体を理解していなくてもガイドにあるコードをそのまま利用するだけでもなんとかなるでしょう。しかし同じように「それでいいの?」となるわけです。やはりより高度なツールを作ろうとすると、低いレイヤ操作がどんどん要求されてきます。C#からメモリを操作しようとするにはいくつか方法があると思いますが、いずれにせよポインタや構造体の知識がなければこれらを正しく行うことは無理です。コース資料にある範囲ならできるけど、今後自分で何かやろうとしたときにはできないことになると思います。それだとただ資格を取るだけで終わってしまうと思いませんか?
例えば、実際に自分がツール開発をしていたときのケーススタディを挙げてみます。WinAPIを使用してOSと対話をしているとたまにx86とx64で構造体のメンバのOffsetが異なったりするケースがあります。これを意識しないでメンバを取得しようとすると、手動でOffsetを計算して取得しようとしない限りは、位置がずれて当然無茶苦茶なところから値を引っ張り出すことになりエラーとなります。
自分の場合では、開発期の初期だったと思いますが、SYSTEM_HANDLE_INFORMATION構造体を使っているときに起こりました。ある機能を実現しようとしたときに、ネットにあるコードを部分的によく確認せずコピーして使ったのがおおもとの原因です。.exeとしてその機能を単体で使用すると正しく動くのに、Powershellのコマンドレットとして実装した時はなぜか正常に動きませんでした。そこでVisual Studio からデバッグをコマンドレットに対してかけます。Visual Studioでは、構造体であればメンバの内容を表示してくれますが、その部分はメモリを確保してポインタ(IntPtr)だけを渡して操作をしていたので、当然ながら型がわからないためメンバなんてものは表示できません。だから、エラー自体がなぜ起きているのかすぐには分かりませんでした。(この時はすぐにプロセスのメモリを確認するとか、IntPtrに型を与えて構造体としてメンバを見るみたいな操作がよくわからずできませんでした。) この構造体はドキュメント化されていない構造体ですが、以下のリンクにレイアウトがあります。具体的にどんな構造体かはここでは説明しませんが、連なっている最初のSYSTEM_HANDLE_TABLE_ENTRY_INFO構造体へのハンドルのオフセットが x86では0x4なのに対して、x64では0x8となっています。私がコピペした部分は、最初の構造体へのポインタを取得するために、オフセットを0x4として計算して取得していました。つまりx86としての利用を想定したもので、x64では想定されておらず、当然ながらx64では本来は構造体の先頭アドレスから0x8バイト離れたところから参照するべきなのに、これを0x4バイト目から参照しているので、不正な値となっていたわけです。C言語がわからない人にとってはここら辺の話はよく分からないと思います。ですがこういったポインタとか構造体の話がわからないと修正の糸口すらつかめず開発がストップしてしまいます。
今考えてみればすごい初歩的なことだと思いますが、こういった一連の低いレイヤ操作は自分の思い通りのツールを作ろうとするとバシバシ出てきます。そしてより高度な検知回避の技術を学ぼうとすると残念ながら低いレイヤの話がほとんどです。今はゼロトラストなんて言葉があると思いますが、そんな環境で回避とかをしたいってなるとやはりもっと勉強して、その勉強をするにはやはり低いレイヤがわかってないとダメなんじゃないかと個人的に思ってます。OSEPはゼロトラスト環境での侵入技術を問うものではないので、ハードな低いレイヤ操作は求められませんが、いずれゼロトラスト環境でのPEN-400とかで出てくる(出てきてほしい)んじゃないかとこれまた勝手に思ってます。
WinAPI
先ほど「OSと対話する」といった表現をしましたが、その対話に使用するのがまさにWinAPIなわけです。ツール開発ではもうこいつとは切っても切り離せないといっていいほどの付き合いとなります。逃げられません。コース資料では、C#やPowershellからどのようにAPIをコールするのか?といった初歩的なところから解説が始まり、コースで使うAPIに関しては、ある程度APIごとに細かく引数を解説してくれます。もちろん0210ではなく、どうでもよい引数の解説とかは「気にしなくてよい」ぐらいで流されるところもあります。ただそこは「気になるなら自分で調べてみてね」っていうTryHarderの表れだと思います。
正直まともなコーディングをしたことがないのにWinAPIについて事前に知っておくことの難しさは、私も理解していますし、たぶん無理だと思います。事実私がそうで、もちろんほとんどのAPIについて知らなかったし、使ったことすらありませんでした。ただ事前にC言語等でWinAPIを使用したことがあれば、WinAPIの独特な部分等について悩まなくていいのかなと思います。C#側からWinAPIを呼び出すには、P/invokeという機能を使用して呼び出すことができるのですが、APIの引数のデータ型はどういう風に宣言すればよいとか結構頭を悩ませたり、いろいろな難しいことが慣れないうちはあります。
英語
ここまで読んでくれた人はなんとなく感じていると思います。英語がある程度できることで、それができないことに比べとんでもない差が生まれます。私は、海外でサイバーが進んでいる理由の1つは、絶対ここにあると確信しています。正確には進んでいるというか、制限されていて進めていないという方が正しいかもしれません。もちろん海外というと母数が違いすぎて、単に日本人の母数と比較することは不適切だと思いますが、それでもなんとなく言いたいことはわかっていただけると思います。
事実何もわからなくて、英語だけが少しできた自分が1年ほどでここまでこれたのは、まず間違いなく英語という武器があり、偉大な先駆者たちが残してくれた貴重な情報資源にたくさんアクセスできたからだと思います。英語圏の人々は、英語で共有されているすべての情報に最初からアクセスし放題なわけです。しかし言語的なハードルがあるとこの部分が制限され、英語圏の人からすれば「当たり前だろ」って知識も、制限のある側からすると「なにこれ?」もしくは「解読に時間がかかって、実質追いつかない!!!」となると思います。
ネイティブのようになる必要はないと思いますが、少なくとも「読み」は磨いた方が良いと思います。私も読み以外は適当です。「書き」なんていまだに時制がおかしいことになってたりなんてことがよくあります。しかしヒトの使う「言語」のいいところは、コンピュータと違って当然ながらヒトが相手であることです。多少間違っても向こうは理解してくれます。コンピュータだとそうはいきませんが、ヒトにはコンピュータにはない賢さがありますし利用するべきだと思います。
PEN-300で学べること
セキュリティ機構の回避と実験の仕方
まずPEN-300の目玉として挙げられるのが、Anti Virusの回避技術だと思います。今は標準でDefenderという厄介なものが備わっていますし、これらの回避技術なし現実の世界でのペネトレーションは考えられないということだと思います。ただNGAVといったより高度なAVに関する回避技術については残念ながら触れられません。またこれらEPPとは異なるEDRに置ける回避技術についても、それ自体が高度な内容になるため当然ながら解説はありません。
「じゃあ回避といっても学べることは少なそうなのかな・・・」と思ってしまうかもしれません。ですがそうではありません。上記に挙げたような記事は、正直OSCPを合格したばかりの人には内容がわからないと思います。ですがOSEPを合格した私には、この記事が以前よりかは理解できるようになりました。そして自分で「とりあえずうまくいくかはわからないけど実験をしてみたい」という気持ちになるぐらいには、技術的ななにかが得られるわけです。つまり今後回避の技術を磨いていくために必要な「未知の領域における自分の力による実験や解決」がほんの少しできるようになります。「ほんの少し?」なんて思うかもしれませんが、技術的な領域でこれらの領域へのヒントが得られることってすごい幸せなことで重要なことだと思います。これを起点にもっと多くの実験等ができれば多くの制限を回避できるようになると思います。まだまだひよっこですが、少なくとも未知の制限に足を踏み入れるのに必要な最低限の道具の一部は持てたかなぁと思います。
またAnti Virus以外のセキュリティ機構としては、アプリケーション制御などがありますが、それらを回避することも学ぶことができます。そして同様にその回避の見つけ方のヒントが得られます。私にとってはこちらの見つけ方が重要です。
オンプレミスのActive Directoryに対する攻撃技術
今はAzure ADといったオンプレADとは異なるものがあり、私もそこを次は勉強しないといけないなと感じているところです。ただオンプレのActive Directoryの理解なしに、Azure ADが理解できるのか?とも思います。両者は異なるものだと思いますが、似ているところがあると思います。だからこそオンプレADとAzure ADの機能比較表なんてものがあるわけです。
PEN-300ではオンプレADへの攻撃ですが、ある程度のことが学べ、足りない部分は自己学習で後は理解できるといったところまで生徒を運んでくれます。例えば、ACL AbusingやDelegation Attacks等のオンプレADの攻撃における基本的なところは教えてくれます。一方でExchangeサーバの悪用とかは教えてくれません。ただそれらはOSEPのレベルまで来たら、あとは勝手に自分で調べて理解できるものばかりだと思います。事実としてChallenge Lab(コース資料を読み終えたらやるラボ)ではコース資料にないような攻撃をわざとたまに出題してきますが、調べたらなんてことはないというようなものでした。 つまり単純に手数を後は増やすだけです。「手数を増やしたいけど技術的に高度で手が出せない」といったものは、他のAD攻撃の解説記事を見ても少なくなったと思います。
WinAPI
WinAPIの使い方が学べるのも大きいところです。WinAPIの理解は何もペネトレーションだけに必要なことではないと思います。マルウェアはWinAPIをゴリゴリ使いますし、それなしでマルウェア解析を語ることは無理だと思います。私自身は、Reversingに関する能力がまだまだ全然ないので、あまりこの領域では多くのことは言えません。ただ去年買ったマルウェア解析の本を見たときには正直「人間の言葉かな?」と思いましたが、今見てみたら自分がツール開発でよく使っていたAPI達で少し親近感を覚えるぐらいにはなりました。それもそのはずで、マルウェアはまさに検知回避とかの技術が詰まっている宝庫だと思います。PEN-300ではその検知回避の技術をまさに学ぶわけで、マルウェアが使用している技術を違う角度からではありますが学べることに不思議はありません。
去年はよくわからない長々とした名前の構造体や異様にメンバの数が多い構造体、「どんだけ引数あるんだよ」と思うAPIなど、見た瞬間にニコニコしながら本をパタンと閉じていましたが、最近買った解析本を見たときはそのようなことはありませんでした。本当にこの辺りは、自分がツール開発をしてWinAPIに慣れることができたおかげだと思いますし、PEN-300には本当にこの点でも感謝しています。
具体的なレベルでいえば、例えばPotatoesは、WindowsではおなじみのExploit Toolsなわけです。SeImpersonateがあるコンテキストのシェルが取れることは結構あって、Potatosはまさにそこで活躍するわけです。そしてこいつらもやはり内部でバンバンAPIを使っていて、その仕組みを理解しようとしたら、時間はかかりますし、理解できないこともありますが、ある程度の流れを追っていけるようになります。
PEN-300で作ったもの
見たくない人は飛ばしてください。また技術的な解説はありません。あくまでコース資料を完了しているぐらいの知識が要求されます。また以下のものが私が作成したすべてのツールではありません。また完成度としてもコードが汚く、あくまで素人が作ったものなのでまだまだ改良の余地があるかなと思ってます。
基本的な開発方針としては、以下のようになっています。
・使用言語は、C#
・主な実装形式はコマンドレットを含んだ.dllでたまに.exe
→CLMさえBypassできれば、アセンブリをロードしてAWLを気にする必要はなくなるため
→コマンドレットの実装を個人的にしたかったため
→引数管理が楽
All-in-One for AWL CLM AMSI Bypass
マシンの中にはAWLやCLMが有効になっているものがあります。これらは非常に煩わしく、攻撃者にとって邪魔な存在となります。そのためできれば最小限の回避で永続的に回避をしたいところです。よって私はAWL によるアプリケーション実行制限を回避しつつ、永続的にCLMとAMSI潰すツールを作りました。このツールによって以降のCLMとAMSIが永続的につぶされ、Interactiveな新規のShellがPopupし、OSEPレベルの防御機構はほとんど無力化されることになりました。またWebshellのようなNon Interactiveの実行からでもAWLをBypassして、CLMとAMSIをつぶしたReverse ShellをPopupさせるようにもしています。つまり普段のBox攻略と異なることはC言語等で記述されたPEのOn Diskでの実行制限とネットワーク監視ぐらいになりますがこちらは他のテクニックで回避します。
Encrypted Shellcode Injection
Remote, Local, CLIから暗号化・エンコードされたShellcodeを入力として受け付け、それらをProcess Injection, Process Hollowing, APC Injection等の各種Injectionにまでもっていくものを作りました。これのおかげでDefenderがボヤを起こすことなくMeterpreterを簡単にPopupさせることができます。Meterpreter Danceし放題。やったぜ。ただし、Memory Inspectionに関しては、また別の話になります。詳しくは、以下のページがおすすめです。特に2番目の記事の「Also during testing it was found that some processes didn’t trigger Windows Defender even though they made calls to those WinAPI functions. So another potential bypass would be to simply inject your Meterpreter payload within either process and you would bypass Windows Defender’s memory scanner. Although unconfirmed we believe this may have been a performance optimization as those two processes often call CreateProcess.」あたりは、良いヒントになります。
Encrypted PE Injection
こちらはShellcode Injectionではなく、C言語等で記述されたOn diskからでないと普通は実行できないPEをメモリに直接注入してProcess Injection等としてFire Upさせるものです。C言語等で記述されたPEをDefenderに気づかれないように実行したいときにはこちらを使います。技術的にはRelocationという行為をPE Loaderの代わりに自力で実装する必要があります。これによってPEヘッダに関連するプログラミングに少し慣れることができ、自然な形でPEヘッダの構造を少し理解することができたと思います。このコマンドレットは、まだうまく動かないというか、とある機能が欲しいところがあるので改良を続ける予定です。
また正確に他のプロセスメモリにPEを書き込む必要があるため、PEヘッダ等をちゃんと書き写すことはもちろんですが、relocationにおいて「修正するべきアドレスが正しく変更されているか?」といったことや「Imagebaseは書き換えられているか?」ということを確認する必要があり、この際にバイナリエディタ等で他のプロセスメモリを覗いたり、他のプロセスメモリの内容を引っ張り出して、それをPE Parserで解析して、「ヘッダが正しく認識されているか?」とか「正確にヘッダの内容が変更できているか?」とかを調べたり、あとは「PE全体をメモリから切り出して保存し、それが正しくバイナリとして動くか?」とかうまい表現が見つかりませんが、必要に駆られてこれらのデバッグツールに少しだけ触れることができたと思います。個人的にこの必要に駆られてというのが非常に良かったかなと思います。
SQL Server Interactive Client
こちらは対話型のSQL Server クライアントです。コース資料のクライアントは非対話で何回も実行を呼び出す必要があったため、対話形式に作り直しました。使用感は、まさにMySQLのクライアントと同じように、プロンプトに接続しているデースベースを表示し、レコードもカラムの名前をしっかりと返す形で視覚的にもわかりやすく情報が返ってくるようにしました。
SharpCat
自作のNetcatをC#で実装しました。一番の活躍頭はこいつでした。自分でtcp_reverseのC# payloadを実装するようなものです。もちろんreverse shellだけではなく、すべての機能はありませんが普通のnetcatとしての機能もありserverとclientの機能があります。完全に自作なためまずAVの検知に引っかかりません。AntiscanMeでは初期実装時から常に検出率は0でしたし、On Diskでおいても一度も検知されたことはありませんでしたし、開発時に実験台にしていたWindows11のDefenderも既存のNetcatにはHack Toolとしてフラグをたてます(たぶん変更のない生のNetcat自体のシグネチャが単に悪意のあるツールとして登録されているだけだと思うので変数名とか変えたり、Junk Codeを挿入したりしたら回避できるかも)が同じ挙動をするSharpCatに文句は一切いってきませんでした。
SharpCatのおかげでWord等に含む記述は相当軽いものになり、必然的にWordマクロ等からの検出率を下げることも出来ました。例えばダウンロードして、それを起動するといったことをするだけです。またエンコードしたバイナリを埋め込むことで、ダウンロードの必要性すらなくなります。いきなりWordマクロにAPIをぶっこんだShellcode Runnerを実装するとそれだけで怪しいものです。AVベンダの対策もあってか、そのパターンやシグネチャは相当蓄積されているようで、AVによっては「Powershellの呼び出しだけでPowershell Downloaderとしてフラグを立ててない???」というふうに見えるものがあり、Powershellや埋め込みのAPIに依存しない形でこういったPhishingマクロが作れるのは非常に大きいと思いました。
よって自分はShellcode Runnerは一切使ってません。※すべて初期シェルはSharpCatからとり、安全にCLIからMeterperterを召喚してました。ただ正直今振り返れば、Meterpreterすらいらなかったなとも思えます。Meterpreterを使ったのは、「手軽にSeImpersonateからSystem取りたいな」と思った時ぐらいで、C2としての機能を使用しなければならないような困難な問題には一切遭遇しなかったと思います。ここでは紹介していませんが、自力でincognitoの機能を簡易的に実装した(自力で実装してみたい方は、以下のリンクの参照をおすすめします。)のでToken Abusing周りでもMeterpreterに頼るシーンはなく、Challenge Lab 4までは一切Meterpreterは使わないでやってました。ただC2に対して馴染みがないのもそれはそれで問題なので後半からは使うようにしました。
※もちろん作り方を勉強しなかったというわけではなく、ある程度のRunnerを作ってからこちらにシフトしました。
学習の進め方
PWKと異なり背景知識がC#以外はほとんど0であったため、少し心配でしたがどうやらPEN-300に対する情熱がそれをなくしてくれました。私は特にセキュリティ以外に今やりたいことがないので、使える時間はすべてPEN-300やほかのセキュリティの学習にあてていました。
まず概要を掴む程度で各章ごとに1日をかけ、コーディングや複雑な理解が必要な章はゆっくり数日の時間をかけてコース資料からもはみ出す(例えば、先の例のPE InjectionやAPC Injection)というスタイルでした。これはコースの内容を完全になぞって学習するスタイルだと得られるものが少なく、コースの内容を起点にすれば手が届きそうなトピックがいくつかあると思ったからです。コーディングでは、さっとコース資料をまずはみて、あとは内容を思い出しながら考えてブラインドでコース資料のツールを書くといったようなことをしました。思い出すという行為によって、ゆっくりですがある程度そのまま見て書き写すより考えて書いていく必要があるので「ん?この処理どういうこと?」ってところでちゃんと立ち止まることができて、そこをメモして時間がかかりそうなら後で戻ってくるという風にしていました。そして100パーセントの理解ではありませんでしたが、だんたんわかってきたら独自のツールを作り込んでいきました。
ツール開発に関係ないところは自分のやり方を身に着ける必要は別にないし、実際の攻撃でも同じことをするので資料通りにある程度なぞってやりました。「どうでもよさそうだなぁ」とか「自明では?」と思うような演習は飛ばしました。いろいろな人のレビューを見るとすべてやった方が良いといった意見があるので人それぞれだと思います。私はとにかく早く開発がしたかったため、たぶん演習自体は半分もやらなかったと思います。「おいおい」と思うかもしれませんが、コーディングの部分の演習はツール開発で学べますし、そこの演習部分は丸ごとスキップされていましたので、私のやり方はそんな感じでした。
またChallenge Labをする前にある程度の完成度を持った自作ツールを作ることは一つの目標でした。というのもある程度規模のネットワークの学習環境はそうそうあるものではなく、貴重な初見の状態こそが経験になり、その初見の状態で色々考えて学習をしたかったという思いがあります。だから完成度の低いツールのせいで攻略を見る羽目になるとかそういう貴重な経験が台無しになるところは避けたかったという思いがありました。ですからある程度完成度があるツールを作り、ペネトレーションの経験を積むという側面も保ちつつ自分で作り上げたツールの評価テストをするという意味も持たせながらChallenge Labには臨みました。
よってツール開発にかける時間が最も多くなり、全体的にコース資料にかけた時間は1.5割程度で7割がツール開発、残りの1.5割がChallenge Labだったと思います。Challenge Labでフォーラム※を見た個所は、2か所でした。ツールの修正も多少修正する必要があった部分もありましたが、根幹をひっくり返すような修正はなく結果的に良いものを作ることができ、試験でも大幅にそれに依存するほどのものになりました。事前に攻撃環境を攻撃者として想像して「ああこれがあると検知されただめだ」とか「検知は回避できるけどスマートじゃない」だとか計画的にツールを作っていくところとかまさにhackerぽくて本当に楽しかったです。(といっても別にものすごいツールを作ったわけではなく、普通にPEN-300で問われる範囲内に＋して少し発展的なものといった感じです。) 特にこの「スマートさ」が今の自分にまったくなくて、今後もしも何かの奇跡が起こって自分がRed Teamerになれるとしたら、そこが一番必要な課題だと思ってます。「スマートさ」というと漠然としているので具体的に言うと「いかに痕跡を残さず静かに行動できるか?」とかそれだけじゃないですが、そんなところです。これはHTBとかのサービスやCTFをただ攻略しているだけでは絶対身につかないと思います。真摯にログと向き合ったりして「自分がどれだけの音を立てているのか?」とかを確認したり、それこそ生の人間の思考をつくようなものが求められると思います。
Linuxに関係する章は既知のものも多く、特に深く勉強する必要もないと思ったので結構飛ばしたりして詰まったら戻るぐらいの感覚でした。例えば、DevOPSとかはHigh Vauleなターゲットなのでクレデンシャルとか設定ファイルの位置、危険な機能を押さえましたが、権限昇格とかはひとつの手法に過ぎないため深入りはせず、こんなものもあるんだなぁぐらいでした(というか既知のものだった気がします。)。
※Offsecが私のアカウントをフォーラムに追加するのを忘れていたらしく、コース資料を終えるまではフォーラムの存在すら知りませんでした・・・(笑)
学習する際に注意点
余計なおせっかいと思うかもしれませんが、これはやらない方が良いと思ったことを紹介します。
BloodHoundに頼り切った列挙
BloodHoundは強力なツールです。ですがその音は犬が吠えるようにうるさく、もしもRed寄りのテストや実際のRedでそのまま使うことはないと思います。これは個人的にも少し思っていましたが、PEN-300のChallenge Labが終わってから受講を開始したPentester Academyの「Attacking and Defending Active Directory Lab」のAuthorであるNikhil Mittal氏(Nishangの作成者)もこれについて言及をしていて、自分の思っていることは間違いではなかったんだなと思いました。よってPentester Academy※ではBloodHoundは紹介程度にとどまり、あくまでPowerViewやAD ModuleによるEnumerationをメインとしています。PEN-300でもBloodHoundは紹介程度にとどまり、あくまでPowerViewによる列挙に限られています。
※宣伝とか抜きにして、本物のRed Teamerの人が解説してくれるPentester Academyって本当にすごいと思います。(しかもこれで250$) 内容はしっかりしてるし、PowerViewもADモジュールとセットで比較的網羅的に説明をしてくれています。またACLの概念やForestとかのADの基礎的なところも説明してくれます。(ただ字幕とかはないので言語的ハードルは高いです。)
まったくBloodHoundを使うなというわけではありません。Nikhil Mittal氏もBloodHoundの視認性は大いに助けになるし、検知とかを気にしなくてもよいBlueでは大きな力となるといっています。ですがいきなりBloodHoundをドメインにぶっ放して列挙をするみたいなことはやめるべきです。PEN-300は検知回避がひとつの目的なのに、いきなりBloodHoundを使うのは少し矛盾していると思います。自分からすればなんで成功するかわからないKernelExploitを乱射してEoPをする感覚に似ています。自動化は大変良いと思いますが、その過程で何が起こっているかわからないのは極力避けるべきだと思いますし、PowerViewがまともに使えないのにBloodHoundを使っている自分にはなりたくなかったので、個人的にはまずはPowerViewでできる限りの列挙を行い、それで攻略出来たら次はBloodHoundで攻略する。ただし、わからなければBloodHoundも使ってよいという風な形にして、両方のツールの使い方を学ぶようにしました。
これによってPowerViewの列挙でも十分に私は対応できるようになり、BloodHoundの勉強は主に独自のCustom Queryに当てることになりました。例えば、非特権ユーザ定義のドメインユーザアカウントで、危険な権限を持ってるユーザアカウントを列挙するCustom Queryの例としては以下のようになります。このクエリの意味は、まずユーザオブジェクトの条件でadmincount: Falseと指定して非特権者を指定し、その後の条件で危険な権限の一覧を書き、その権限の矛先をすべてのノードとして指定し、最後にRIDが11で始まる(500番台とかはPredefinedだとおもいます)アカウントを対象に検索をかけています。
MATCH result = (user:User {admincount: False})-[:Owns|WriteDacl|GenericAll|WriteOwner|ExecuteDCOM|GenericWrite|AllowedToDelegate|ForceChangePassword]->(all) WHERE user.objectid STARTS WITH user.domainsid + "-11" RETURN result
CheetSheetの作り方と使い方
PWKでも皆さんいろいろなCheetSheetを作成されたと思いますが、ここでは少し私のCheetSheetの作り方を共有したいと思います。
まずよく使うツールやコマンドはLinuxのテキストファイルに入れてます。そしてIP Addressが変わるたびにFind and Replace Allで置き換えたりしてネットワーク環境が変わっても簡単に利用できるようにします。
比較的利用頻度の少ないコマンドや各サービスごとのコマンドは、Kaliに入っているCheeryTreeに格納しています。
※画像のは結構前のCheetSheetです。
また各サービスの調査するべきところをチェックシートとして作ってあります。
このような構成で各コマンドを管理し、まるで魔導書から呪文を詠唱するように各チートシートからコマンドをコピペして実行しています。(ダサい)そしてひとたび抜けているところがあればこれらに追加をしていきます。またPEN-300では、攻略中に使用したコマンドは、なるべく記録しておき事後その内容を評価して使えそうなものは各シートに追記をしていくという形を取っています。実際の記録を公開したいのですが、これはOffsecのコンテンツを大きく公開することになるのでできません。
使用したツール
ここでは私がPEN-300で使用したC2と自作ツールとWeb系のツール以外の「すべて」のツールを紹介します。本当にこれ以外は使ってません。私自身のメモリが小さいため、多くのツールが使いこなせません。あと多くのツールを統合的に自動化するようなものは好きじゃないです。少なくとも相手の環境で使うものは、裏でどのように動いているのか、すべては不可能ですがある程度見る必要があり、それは大変です。
Nmap
語る必要はないと思います。
Chisel
トンネリングツールで有名ですね。On Diskで検知される場合には、Sharp-Chiselを使います。C2にも、これらの機能があると思うのでそれでも良いかも。
Proxychains
Chiselで生成したSOCKSプロキシを利用して内部ネットワークにトラフィックを運べます。設定自体は/etc/proxychains4.confで行います。
WinPEAS
WinPEASも語ることは特にないと思います。
BloodHound
SharpHoundはBloodHoundのIngester(クエリを飛ばしまくってデータを収集するやつ)で、BloodHoundはその収集したデータを解析する方です。勉強する際は、静かな使い方とCustom Queryの使い方(主にCypherの書き方)を勉強するとよいと思います。
PowerView
コマンドは勉強しましょう。それをすることでADの勉強に確実につながります。一番ツールの勉強で時間を割いたのが、このPowerViewでした。
Mimikatz
Mimikatzの使いどころは、主にPtHやPTTやTicket Forging等のKerberos周りの操作と侵害後のPostExploitationになると思います。
Rubeus
C#実装ですし、Kerberos周りで使うならMimikatzよりいい気がします。
Impacket
主にLateral MovementやExfiltration系のツールが詰まってるものです。
試験のルール
あくまで試験ガイドに記述されている範囲内で、個人的に抑えておいた方が良いところを挙げます。
・試験は、ラボ攻略に47時間45分、レポート作成に24時間が与えられています。
・試験は、最終目標に至るまでの複数のPathがあり、いずれかのPathでそれを達成すると合格です。
・最終目標を達成できなくても、100点分のフラグを集めることでも合格とみなされます。
・EoPを実行する必要があるマシンもあれば、いきなり管理者権限を取得できるマシンもあります。
・カスタムコード(ツール含む)はすべてレポートに含める必要があります。
・商用ツール以外のツールはすべて使用が許可されていて、商用でない各種C2 Frameworkは使い放題です。
・ ARP, DNS, NBNS, or IP等へのspoofingは禁止
・フラグの取得は、遠隔の攻撃者から操作できるシェルによって行い、RDP等は認められません。※
※フラグの取得は、攻撃者のマシンから操作できるRemote Interactive Shellのみが認められています。RDPが使えないというわけではないので、そういうときはRDPからリバースシェルをspawnさせればよいです。
試験について
当然ですが、試験の内容はあまり話せません。OSCPの数ある体験記のように、この順番でフラグをとってとかも言えません。結果としては、約20時間程度ぐらいだったと思いますが、最終目標にたどり着きました。躓いたのは最後のところだったと思います。原因は「スマートにやりたい」と思いすぎて、泥臭いやり方を取らなかったことです。たぶんスマートにやる方法はあったと思いますが、今の私の技量だとダサいやり方でないとダメでした。また最終ゴールにたどり着いた後も、他のPathでも挑戦して、そちらのPathでも最終目標への攻略を解読することができました。睡眠をとったのは、ぶっ続けで20時間やった(試験楽しすぎた)後の6時間程度、そのあとは試験終了までレポートの証跡を取ったり、他のPathを試してみたりとかやってました。私にとって大きい規模の仮想学習環境はすごい貴重なので、試験においても盗む姿勢を変えるつもりはありませんでした。試験官の人は、「はよ終われ・・・」と思ってたと思います(笑)正直Learn Unlimitedの恩恵を借りて、わざとレポート出さないで落ちてもっかい受験して別の環境をやろうかなと少し思ったぐらいです。
あとOSCPのときは特段のトラブルはなかったのですが、OSEPでは環境が大きいこともあり、トラブルがありました。まずドメイン全体の挙動がおかしくなって、Revertする羽目になりました。その時はスクショを取ったり、攻略に至るまでのメモをちゃんと取っていて、最終目標も終えたときだったので良かったのですが、あれが攻略中に起きたらキレてたと思います。また他のPathを試行しているときに、VPNから1時間ほど切断され、復旧後も1時間か2時間ほどマシンに接続できないことがありました。まだゴールが達成できてないのに起こったらマジギレです。試験官の人があまりに早く終わってほしく電源コードに足を引っかけたのかもしれません。
要求される知識や技術は、OSCPよりも確実に上ですし、OSCPでは教えられない脆弱性やその攻撃テクニックもありました。Challenge Lab で出てこないテクニックも何個かありましたが、このレベルまで来ているとそれをリアルタイムで調べて使うっていうのが要求されているなと思います。「いつまでも学習の中だけでのテクニックで通用するとは思わないようにしましょう」っていうOffsecからのメッセージだと思います。一方で中にはHTBやこれまでの学習で知っていたものだったので、特に苦労はなかったと思います。私はOSCPの1回目の受験で0点を取っていますが、本当にあの時の方が難しかったし今でもまったくわかりません。ただこれは一つどうしようもないものだと思うんですが、どうしてもメタ的な推理でPathがわかってしまうのが少し残念でした。Challenge Labもそうでしたが、大規模といっても現実のように何百台もマシンがあるとかいう意味での大規模ではないので、ゴールとされるところからPowerViewやBloodhoundの列挙をもとに逆順にたどっていくことで、Pathが見えてしまいます。なので個人的には、最初のドメインユーザのcontextを得たときに、すでに攻略Pathは大体頭の中でわかっていて、結果その通りでした。問題だったのは、横移動するときに特殊な設定とかが必要でそっちの方に手間取った感じです。まさに経験の浅さが出ているなぁといった感じです。
レポートは、自作ツールを結構な程度で使っていたので、そのコードを乗せることもありページ数は150ページぐらいになりましたが、説明に使ったのはそのうちの90ページぐらいです。あと、さすがに他のPathのスクショまではトラブルもあり検証とか撮影しきれなかったので、レポートには最初のPathの方の説明だけを書き、「結果的には複数のPathが見つかり、他のPathを防ぐならまずそのPathに至る最初の起点のここを修正するべきで、その後にこういうのがあったからそれもなおしとき」といったような感じにしました。また、SharpCatとかは本当は公開したくなかったんですが、試験ではカスタムコードはすべて載せることになっているので載せました。ただロードしたアセンブリには未使用ではありますが、他のコマンドレットのコードもあり、それをのっけたらもっと長くなっていました。ただそれはさすがに億劫だし冗長になるので、もしも本当にすべてのコードの検証が必要なら別の方法でアップロードさせてほしいと最後の方に書きました。
最後に
PEN-300は、確実に私自身を大きく成長させてくれたと確信しています。今後はこのコースで作った自分のツールをどんどん改良していき、プログラミングの学習として充てていこうと思います。また次は、さらにレイヤが低くなるOSEDを受ける予定です。OSEDは、デバッガを使ったコースで、まさに今自分が欲しいReversingの技術やPwnの技術に触れることができるため挑戦していきます。ただOSEPのようにすぐに手を付けるかはわかりません。なんかOffsecの資格マスターみたいになってますが、まあUnlimitedを勢いで買ってしまったし、今年はそれをしゃぶりつくす予定なので当面はこんな感じになると思います。Offsec以外では、OSEPで作ったツールの改良をし、クラウドの勉強も始めるのでAWSかAzureに手を出し(たぶんAzure)、CTF関連ではOSEDとの兼ね合いもありPwnの勉強を再開し始めました。
今回は短くする予定でしたが、いろいろと書いているうちに伝えたいことが出てきてしまって、結局長々のダラダラ作文になってしまいました。ここまで読んでくれた人には本当に感謝しかありません。そして、おそらくですが、この最後の一文を見てくれている多くの人は、これから何かに挑戦することになる人たちだと思います。同じセキュリティの世界にいるかはわかりませんが、一緒に成り上がっていきましょう!!!
関連投稿