nknskn ネタ置き場

IT使ってなんかやってる人間のたわごと

Offensive Security - OSDAのケーススタディ

覚えてる範囲で雑に書く.

OSDA is 何

この辺のブログ参照

印象

わたしの場合どうだったの

事前知識

OSCP・OSEPの取得、Red Team / Penetration Testの経験がボチボチ、というところで、コースで出てくるような攻撃側の知識はだいたいあった. 一方で、SOC側としての知識は0レベル(攻撃の検証で軽くログを見るぐらい)というところ.

事前勉強

勉強開始〜試験挑戦はおおよそ1ヶ月(2023年3月上旬〜2023年4月17日試験)で、勉強は"コースのLab"と"GOADのELKを使って、自分で攻撃した場合のログを見る"という形で行った. 基本的な知識とログ分析の感覚を掴むのにLabを使って、いろんな攻撃パターンの把握と攻撃原理の理解にGOADを使う、という流れ.

業務の中で"Red Teamとしての攻撃シナリオやらツールの作成"とか、"Blue Team向け攻撃シナリオの作成"だとか(ついでにその手のサービスリリースとか)もやった経験があるので、「実際の攻撃に寄せつつ仕込むとしたら〜」的なメタ読みは(良くも悪くも)それなりにできてしまった.

事前準備

報告書はMITRE ATT&CKベースにフェーズごとのテンプレートを作成した. 準備した内容と本番で記載した内容のレベル感が全く合っていなかったので、正直なところあんま役に立たなかった. 丁寧にテンプレを作るなら、上の他の人がやったみたくOffSecの人にレビューを依頼した方が絶対に良いと思う.

その他、KQLのテンプレだったりWindows Event IDとかの参考リンクは用意したが、ほぼほぼ使わなかった. 結果的には、KQLをサラッと叩いたあとExamに飛び込んだような感じになった.

試験前のゴタゴタ

一回の試験を受けるために予約を計二度やっており一度目は4月頭だったが、試験開始の6時間前ぐらいに「試験環境でトラブル起きたから今日の試験は提供できんわすまんな」というメールが来た. 一応リスケ用リンクは送ってもらったが、すぐに予約可能期限が切れるわ予約できないわということもあり、メールでゴネにゴネて期限を延ばしつつなんとか日程を押さえるに至った.

試験

23h45mの試験なので、OSCPと似た感じの時間管理を想定して挑んだ. 具体的なポイントは以下

  • 〜試験開始12時間後ぐらい
    • 攻撃の全容を把握し、あらかたのテキストログを残す
    • 画像ログも(可能な範囲で)取得
    • 発見漏れの可能性がある箇所(攻撃の詳細がいまいち言語化できない箇所等)はメモに残しておく
  • 残り時間
    • 報告書作成
    • 説明用の詳細なログは分析結果を再確認しながら取得
    • 発見・分析漏れがないかもここで確認

おおよそ想定通りの時間管理で試験は行えた. ただ想定よりも分析漏れを"残り時間"で発見したこと、前半に取得したログが報告書に使えなかったことから、試験終了間際は非常にバタバタしていた.

この辺は、適当にシナリオ作ってGOADで試し、一回レポートを書く、みたいなことをやっとけば慌てずに済んだかなーと反省.

報告書

前述の通り事前に用意していたテンプレはほとんど役に立たなかったので、とりあえず論理がおかしくならないことに気を配りつつ頑張ったとしか言えない. 強いてコメントするなら、ログはこれ(とこれとこれ)、これ(ら)はこういうものなのでこのログから読み取れることはこう、つまり攻撃者はこういうことをしたかったと推察される、そしてそれは成功したor失敗したと見られる、という流れでだいたいを書いた.

合否連絡

3〜4営業日後ぐらいにメールが来た. OSWE, OSEPのときはもうちょい早かったので、今回のレポートの出来はあんま良くなかったかなー(連絡が早ければ早いほど読みやすく、かつ明確なレポートを書けているということじゃなかろうか)と推測.

所感

  • 勉強になった > ツイートの通り
  • 24,365なSOCの仕事はおじさんにはもう無理だよ

Offensive Security - OSEPのケーススタディ

所感とかやったことを覚えてる範囲で雑に書いとく.

OSEP is 何

この辺のブログ参照

わたしの場合どうだったの

普段の業務でRed Team / Penetration Testが含まれていること、またその中で検知回避もボチボチ頑張った経験があったため、特段"新しいテクニックを学んだ"ということはなかった.

一方で、実際の案件で"AppLocker/CLM使って守りを固めた"というような環境は経験上まれなので、「そういう環境にぶち当たった場合、持っている手札をどう組み合わせて攻略するか」というケーススタディとして非常に役立った.

Examは"OffSec Lab"+実務経験で合格した.

基本的なエッセンスはLabにすべて入っているように感じたので、Labをやりこんでいれば(根拠を持ってどの攻撃をするか都度判断できていて、かつ用意されている環境をすべて攻略していれば)まあボーダーには到達するでしょう、という印象.

レポーティングは試験前に8割(汎用的な手法・攻撃テクニック、利用できる手法をどう見つけるか、Bypass techniques、作ったツールの説明、参考リンク等もろもろ)を書き終わっていたので、OSCPのときと同様に4時間ぐらいで仕上げて(環境に合わせて穴埋めして)、酒飲んだりリフレッシュしつつレビューして、内容に満足したら提出、という感じだった.

# レポートのテンプレ化は、他人に説明する資料として書くこともあり、「攻撃フローをしっかり理解できる」、かつ「根拠が弱いとこ(知識が少ないとこ)がハッキリ出る」ので、手間だけど良いぞ、と勧めておく. あと合格後にOSEP持ちのメンバーでレポートを見せあったら、「商用みたいなレポートっすね」と言われた.

提出後、2営業日足らずで合格のメールが届いた. 2023年2月上旬あたり

試験用に作ったツールの話

Initial Accessのためだけに、"PowerShellワンライナーレベル"、かつ"CLMには引っかからないBeaconタイプ"のめっちゃシンプルなC2フレームワーク(Implant & Server)を作った. これは「exeやらdllやらを"初弾"で送り込んでReverse Shellを取る」ってことをやった場合、うまく動かないとき非常にデバッグしづらい、という経験があったため. 侵入後は雑にDefender BypassしたMetapreter/reverse_httpのDLLとかで操作していた.

Windowsのセキュリティ機構は、権限昇格できたらDefenderの除外リストにディレクトリを突っ込むとかで、まあ「良い子良い子」してやればいいので、権限昇格用のツール(UAC Bypassツールとかsystem("rundll32 ,mal")だとか叩くサービスバイナリとか)を用意していた. どれが役立ったかは省略.

勉強用環境のすゝめ

Labと GitHub - Orange-Cyberdefense/GOAD: game of active directory やっとけば、ボーダークリアには十分な気がする. それ以外となると私自身が探してないのでNo idea.

感想

  • 監視を考えなくていいおかげで何の遠慮もなく除外設定を突っ込んだりできるので気は楽
  • 実際の案件で全部が全部使えるわけではないけど、知らんよりはまあ...という感じ. 正直Evasionは基礎の基礎、AD Compromiseが若干実践的か?という印象.
  • EvasionをガチるならOSED/OSEEやれ

一年の計を元旦にするための2022年棚卸し

ドM「一年の刑は元旦にあり」

ということらしいので、2022年振り返りと、来年のざっくり方針を書いた。具体的にどうするかは正月に考える。

ブログ主は基本的にRedTeam/セキュリティ診断サービスのデリバリをやってる人間で、今年主力サービスのリードと、診断部部長(的な人)のサポートを行うようになった管理ペーペーである。

2022年にあったこと・やったこと

ざっくりの時期 立ち位置 あったこと、やったこと 所感とか雑記
2022/1-3 仕事 メンバー 超大規模(1000画面超)サイトのWeb診断をひとりで捌く。RedTeamプロジェクトで使うペイロードのサポート(作ったり教えたり)、新サービス1の開発・リリース、新サービス1の初案件を捌いた まあこんなもんかな(恒例行事)、という気持ち。定時退社
2022/1-3 プライベート メンバー GCPN取得、行政書士の勉強を始める。大学からの付き合いのフットサルには参加していた チーム体制に怪しい動きが見え始めていたので「前々からやりたいと思ってたことを今のうちに」と他分野の勉強を始めたが、時既に時間切れだった。思い立った時点で手を動かさないといかんと改めて思った
2022/4 仕事 リーダー 突発的人事変更に伴いロール(リーダー)引き継ぎ。チーム稼働方針・サービス提供方針の再検討、長期的なビジネスモデルの変更およびメンバー育成を踏まえた新サービス2の開発をひとりで開始。案件提案、採用面談、メンバーのプロジェクトアサインコントロールに巻き込まれ始める。診断案件は変わらず捌いていた。チーム内の月一技術勉強会で発表 ひたすらバタバタした時期だった。仕事を抱え込む余裕すらなかったので自然とタスクを周りにお願いする形になった。結果的には、お願いすることに抵抗がなくなったのでバランスを取れるようになった気がする。バタバタとはいえ引き続き定時で切り上げていたらしい
2022/4 プライベート リーダー 慣れない仕事の疲労でこの辺はなにもできなくなっていたので省略。フットサルは継続 とかいいつつTwitterは相変わらず見ていた模様
2022/5 仕事 リーダー 各メンバーに対する理解深掘り、新サービス2の開発を継続。新サービス2はリリースすることができた。診断はメンバーで捌けなくなった案件を捌くスタイルに変更。チーム内の月一技術勉強会で発表 なお、捌けなくなったものだけのはずなのに毎週2-3案件捌いていた模様。疲労との付き合い方を考え始めた。なお引き続き定時(ry
2022/6 仕事 リーダー 新サービス2の初案件を開始。並行ではないものの診断案件も引き続き実施。サービス提案で口を出し始める。チーム内の月一技術勉強会で発表 この辺りからサービス2とその他関連サービスの最終的な着地地点がぼんやり見え始めてきていた。それに向けて提案内容をコントロールする試みを始めていたらしい。定時(ry
2022/7 仕事 リーダー 新サービス2の初案件を完遂。その他調整で手間がかかりそうな案件のプロマネを始める。面接・アサインコントロール・提案は継続実施。チーム内の月一技術勉強会で発表 ひとりでの新サービス開発はもうやらんと心に誓う。この辺で継続実施しなきゃいけないタスクの要点を把握し、効率化が終わり始める。最終的には「この辺の話に誘導してあの人に投げよう」という方針になった。定時(ry
2022/7 プライベート リーダー 引っ越しをし、2拠点生活(ラボ的な仕事部屋、私生活用の部屋)を開始。会社にOffensive Securityのサブスクを買ってもらっていたことを思い出し、手を出し始める リーダーになる前に「OSCE3全部取ったるわい!」と言って買ってもらったやつだったのでこの辺で後悔し始める。2拠点生活はめっちゃ楽しかった(継続中)
2022/8 仕事 リーダー 提案、プロマネ以外はほぼルーチン化。手間っぽい案件の着地点提示・内容整備を終え「やるだけ」な部分を他メンバーに振る。診断は引き続き実施。余裕ができ始めたのでメンバー育成を本格的に考え始める。チーム内の月一技術勉強会で発表 振るタスクの内容検討、他メンバーへ振る際の適切なタイミングを図り始めた。定時(ry
2022/8 プライベート リーダー OSWEのドキュメントは粗々で読み終え、レポートテンプレの作成を開始 なおラボには手を出していない模様
2022/9 仕事 リーダー 引き続き提案、プロマネアサインコントロール、その他タシャとの絡み等々をよしなにこなす。チーム内の月一技術勉強会で発表。診断案件も引き続き(ry この辺から完全に慣れて何も思わなくなってきた。定(ry
2022/9 プライベート リーダー ssmjp #26にお邪魔した。そのほかOSWE取得 結局OSWEのラボはほぼやらずに取ってしまった。あとでやる(やらない)
2022/10 仕事 リーダー 引き続き提案、プロマネアサインコントロール、その他諸々をよしなに。診断も(ry。メンバーとの1on1を実施し、メンバー理解の促進を試みた。この辺でメンバー育成観点で「期間限定出社でのOJT」(名称:強化月間)を検討し始める。また"2022年での土台作りは完了"と判断し「来年自分がやるべきこと・メンバーにやってもらうべきこと」を整理し始めた ひとつのことに集中する時間が減った影響でもろもろの"開発"ができなくなったので、ストレスをわりと感じ始めてきていたように思う。定(ry
2022/10 プライベート リーダー ssmjp #27にお邪魔した。OSEPの準備を始める レポートテンプレを作成を始め、「こりゃラボやらんと落ちるな」と悟る。仕事で感じていたストレスはOSEPのラボで気分転換するかー、という感じだったのはわりと良かったように思う。なおクリアできるとは(ry
2022/11 仕事 リーダー 引き続き提案、プロマネアサインコントロール、その他諸々をよしなに。年末に向けて診断案件もバタバタし始めていたので、手を動かす時間もそっちに取られる。また「強化月間」も開始しメンター対応を行う この辺りでは「仕事が終わると疲れですぐに寝る」という日もあった。いろいろ余裕がない時期だった。なお定時(ry
2022/11 プライベート リーダー OSEPのラボをちょこちょこ、レポートテンプレの作成を進める。あと不動産投資の勉強と実践をし始めた。ラボをやり始めたのでフットサルに参加しなかった唯一の月だった 仕事したくなくなってきたので不労所得の準備・検討・考察を再開した
2022/12 仕事 リーダー 引き続き提案、プロマネアサインコントロール、その他、「強化月間」のメンター対応を実施。年内案件がほぼ片付いたので、自分のやる気に身を委ねた。身を委ねた結果2023年1月-6月は週休3日で働くことにした ナニモイウコトハナイ

2022振り返り

  • 圧倒的定時退社力(鋼の意志)
  • チームを作り上げる上で「入ってくる可能性のある案件を見る」「メンバーの思考・指向性・能力・方向性を把握する」「メンバーのそれらを踏まえたアサインコントロールを行う」「メンバー〜アサインを踏まえた収支計算とサービスの定義を行う」これらを模索・検討・試行できたのは収穫だった
  • サービスの方向性、ビジネスモデルの模索・検討・移行らへんの頭を養えたようにも思う
  • 仕事、プライベート共に、学びがけっこう多い年だった気がする。来年はボチボチ程度に抑えたい
  • フットサルでは最終的に、試合出場数、得点数、思い出戦闘力("フットサルをした日の3行エピソード"で出てきた回数)で三冠を達成した。やはりというか、試合ごとの得点率ではエースには勝てなかったのが心残り(主はディフェンス側の人間)

2023

  • 仕事はサービスをボチボチ整えるのと、メンバー育成に本腰入れる感じだろうなという気持ち。サービス整備では「提供内容がニーズに刺さるもの」は大前提として、「デリバリをやってりゃOSEPを取れる下地(能力・考え方)が身に付く」程度を目標としてはいるが、「メンバーが一定レベル以上に優秀であること」(「優秀さ」は要言語化・要定義)が条件としてあるので、汎用性はどこまであるのやら、という気持ち。まあ要検討
  • プライベートは引き続きいろいろ遊ぶかーという感じ。さっさとOSCE3と書士系クリアして、MBAだとかの経営系の知識を取りにいきたい。まあいずれにしても遊ぶだけなんでこれこそナニモイウコトハナイ
  • フットサルでは「ディフェンスに関する評価指標」を追加させるようにしたい

以上、来年もがんばるぞい(がんばらない)

OSWE Examをpassした話, 名状しがたいCase Studyのようなもの

9月末にOffensive Security社Certifiedな資格の一つ, OSWEの試験を通ったのでそのWrap upとCase Study.

Offensive Security is 何, OSWE is 何, な人はこの辺参照. 他のブログは適当にググってどうぞ.

試験の内容を要約すると, Web appのソースコードに対する脆弱性診断+悪用(実際にWeb appが動いているマシンのshellを奪取するとこまで)を2台(50点 * 2), 合計100点満点中80点以上を取れば合格できる. 50点/台の点数配分は以下:

  • Authentication Bypass - Web app admin奪取: 35 pt
  • Remote Code Execution - Machine Shell奪取: 15 pt

ということで, 2台のAuthentication Bypassが必須(計70 pt)+どちらかのマシンでRCEができれば(15 pt)合格ライン到達, その後のレポーティングでミスらなければOK, というもの.

ここで書いてること

  • 事前準備に関すること, 特に"やっときゃもっと楽だった"
  • 試験中に関すること, "やらない方が良かった"
  • やらかしたこと, "残しといて良かった"

事前準備

バックグラウンドとして経験を書いておく:

試験に向けてやったことは以下.

  • 報告書のテンプレ作成
    • ハイレベルサマリの記載 - 達成具合で文言を削除すれば提出できる程度
      • 発見した脆弱性と,何をするために何の脆弱性を使ったのか, の枠
      • 各種脆弱性の推奨改善策例, SQL Injection, Broken Access Control等. ここら辺はOWASP Top 10を見ると良い
    • 各マシンに関する報告枠, ざっくり以下のような感じ
      • X. < Machine Name >
      • X.1. Flags
      • X.2. Exploitation Summary and Steps
      • X.3. Authentication Bypass - < Vulnerability Name >
      • X.4. PoC for Authentication Bypass
      • X.5. Remote Code Execution - < Vulnerability Name >
      • X.6. PoC for RCE
      • X.7. Full PoC
    • 各種脆弱性の解説枠テンプレ
      • 脆弱性名, 解説, 影響, 推奨改善策, 該当箇所, 参考リンク, 検証例の記載枠, 検証例の記載テンプレ
  • Cheatsheet作成
  • ドキュメントの流し見とHands-onをちょっと
    • 流し見は最後(11章...だっけ?)まで
    • Hands-onは4章ぐらいまで

Cheatsheetは以下のような感じ. 「脆弱性が見つかればなんとかできるだろ」という見込みで「どういう方針でどう探すか」というメモと, 「いちいち覚える気がないもの」を軸に作った. 作成にはvscode-mindmapを使用.

やっときゃよかったと反省した(やらなかった)ことは以下.

  • 試験週の睡眠不足解消
    • (ブログ主がロングスリーパーなだけだがそれはそれとして)睡眠不足はすべての敵
    • 試験日を艦これのイベント時期と被せたせいなので完全に自業自得
  • 一通りのPythonスクリプト準備
    • requests.Session, urlencoded/multipart request, content-type customize, HTTP Server, Parameter Parser and Server Thread Handling
    • PoCはすべてPythonで実装したが, 上記を試験中に公式のドキュメントやら誰かのブログを見ながら実装するハメになった(タヒ)
  • ドキュメントのExercise, Labs
    • Exercise/Labが重要ということではなく, それらをやった結果として残るPoCのコード/スクリプトが大事, という話
    • 艦これやってる時間あったんだからLabもできたんじゃないですかねぇ(名推理)

この段階での他の反省点は, 試験を(金〜日の三連休で)金曜の0時スタートにしたことぐらい. 単純に仕事疲れを解消できずに試験に臨んだ, ということなので, 三連休初日の朝9時〜昼12時スタートとかであればいいかもしれない.

報告書のテンプレをある程度整えたこともあり, スクショ撮り忘れだとかコード書き漏れだとかのやらかしがなければまあレポーティングフェーズは問題なかろう, というフラグを立てて挑んだ.

試験中

時間経過はメモできるほど余裕がなかったので記憶ベースでのざっくり感しか書けないが, 以下のような状況だった.

  • 1日目終了(24時間経過)時点, 35 pt
    • Machine A - Authentication Bypass: 手の込んだタイプだったものの, コーディングは完了
    • Machine A - RCE: いくつか候補を見つけるものの, 悪用できず
    • Machine B - Authentication Bypass: 候補を一切発見できず. トリッキーなものも一部確認してみたが, Bypassには至らず. コードの脆弱な部分はいくつか発見した
    • Machine B - RCE: 候補は発見したものの, Authentication Bypass優先で深堀せず
    • 自身が混乱状態にあると判断したので, いったん寝ることに. 仕事疲れ&睡眠不足もあって6時間爆睡
  • 2日目12時(36時間経過)時点, 50 pt
    • Machine A - RCE: スッキリ目が覚めて神降臨. これも手の込んだタイプだった. コーディングまで完了. クリア.
    • Machine B - Authentication Bypass: 一通り考え切ってダメだった.
    • 試験前に考えていた設問前提(問題作成フェーズに対するスーパーメタ読み)をひっくり返して, 諦め半分でもう一度探し始める.
  • 2日目15時(39時間経過)時点, 85 pt
    • Machine B - Authentication Bypass: あっさり見つけてコーディングも完了.
    • 合格ラインを突破したのでレポーティングに移行
  • 2日目21時(45時間経過)時点, 85 pt
    • レポーティングの説明部分に多少日本語が残っているものの, 検証の流れ, 各種説明用の画像は取得完了. 合格ラインには達しているだろうと一息つく
  • 2日目23時(47時間経過)時点, 85 pt
    • Machine B - RCE: 最後のあがき(?)兼勉強目的で調査. 怪しい場所は見つけたものの, 悪用までは至らず. そのまま終了

準備段階にも書いたが, スクリプト+ペイロードをほぼ1から書かないといけないような状態だったので非常にしんどかった, というのが最初にくる所感. あと艦これの遠征を3時間目安で小休止を入れる目的(イベント中だったので資源回復目的含め)でポチポチやっていたのだが, 遠征時間の関係で時間ずれが発生して逆に集中が妨げられた. 素直に12時間とかの遠征に出しとくべきだった.

一方で, 良かったと思う点は以下:

  • 要所(1日目終了時点, 2日目12時時点)で思い切った選択ができたこと(寝る, 調査の前提条件をひっくり返す).
  • 2台目のAuthentication Bypassを達成後, レポーティングフェーズにすぐに移行したこと(枠を用意していたものの予想以上に時間がかかった).
    • 時間がかかった要因としては各種脆弱性の説明, 影響, 推奨改善策の記載があったが, そもそもこれRequirementsにないし書く必要なかったのでは?(名推理2つ目)
    • ...こまけぇこたぁいいんだよ(AA略

やるべきことはやったと判断して, 就寝した.

最終日 - レポーティング

やらかし太郎「お ま た せ」

レポーティングの日(3日目), 目が覚めた瞬間に「あれ?2台目Authentication Bypassのコード,一部しか実装してなくね?」と気が付く. そんなわけで3日目は机上デバッグから開始した. 幸いレポートを提出するまではKali VM, VM内のVSCode, Burp等々試験で使用したツールは閉じないようにしていたこともありログは残っていたので, 該当リクエストをRepeater(保存用)とComparer(比較用)に突っ込んでPythonで該当リクエストの再現を行った. 机上デバッグの観点は以下:

  • リクエストフォーマット, urlencoded or multipart
  • Content-Type, header, multipart parameter
  • Session

やらかした部分のスクリプト作成, および日本語解説部分の和訳は午前中に終わったので, 最終レビューののち「机上デバッグのとこのスクリプトが動けばpassすんだろ, なるようにな〜れ」と開き直って昼12時過ぎにレポートを提出, OSEPの勉強を始めた.

翌日の月曜日, 22時過ぎに"passしたよ"という連絡がきていた. 火曜の朝にメールを見て, 「お, あのスクリプト動いたのか. よかったー」という感じだった.

振り返り

ざっくりポイントは以下:

  • (全体)試験はレポート提出までなので, アプリを閉じる, VMをシャットダウンするのはレポート提出後にする
  • (準備)レポートテンプレの作成は引き続き事前にやった方が良さそう
  • (準備)Exercise/Labs(coding)は必ずやる
  • (最中)気分転換・思考整理・睡眠は大事
  • (終了前)抜け漏れ対策として, 自分が採点する側になってレポートを見直す
  • (その他)Cheatsheetは今回あまり役に立たなかったけど, 作ること自体は思考整理にアリよりのアリ
    • 確認項目をCheatsheetに入れとくといいかも

まとめ

ぶっつけ本番, (心臓に)いくない

Burp Suite Private Collaborator Serverを立ててみた

Custom config書いてRoute 53でドメイン取ってEC2上でサーバを動かしてログを見た. そんだけ

Collaborator Serverについて

書いてあるブログはちょこちょこあるので概要はざっくりで.

  • HTTPレスポンスだけで判断するには難しい問題を検知するためのツールで、外部への通信が発生する系の問題を検出できる
  • サポートしているプロトコルは以下. 動作ポートは変更できるが, デフォルトを使用するのが基本的には良いはず
  • 検知できる脆弱性の例は以下

参考URLはこれ

タイトルとか URL
本家(EN) Burp Collaborator - PortSwigger
Deploying a private Burp Collaborator server - PortSwigger
WebAppSec(たぶん本家和訳) Burp Collaborator
プライベートBurp Collaboratorサーバの配備
個人ブログ Burp Collaboratorについてかいてみた①
Burp Collaboratorについてかいてみた②

モチベとClientについて

Collaboratorサーバってどんな感じで処理してるのか気になった. それだけ.

あとはCollaboratorサーバと連携して問題を検出できるのはProfessional or Enterpriseバージョンだけ. なので実際に試したい場合はProfessionalのライセンスを購入する必要あり(Black Fridayで安くなってたんだっけ?確認してない)

構築について

本家のHow to deployに従えばOK. DNSリクエストがどう飛んでくるかとか分かっていると構築はそんな手間取らない(手間取った).

準備したモノ、詰まったとこをまとめると、こう

準備、設定したモノ

  • EC2インスタンス
    • 検証用なのでmicroで良いと思う. ちゃんと運用しようと思ったらもうちょいスペック上げたほうが良いのかもしれない
    • セキュリティグループ、以下を開ける
      • tcp: 80, 443, 25, 465, 587
      • udp: 53
      • 53/tcpは開けなくても困ってない. DNSのクライアント次第の気もするのでtcpも開けといたほうが無難かも
    • Elastic IP
      • 必要に応じて. 検証したやつでは取ってない
  • Route 53でのドメイン
    • Route 53である必要はない. 一つ持っていたやつがあったので使いまわした. ここではexample.comとする
    • NSレコード - burpcollaborator.example.com: ns1.example.com,
    • Aレコード - ns1.example.com: 18.xxx.xxx.x
    • AAAAレコードは設定してないけど困ってない. 設定した方が良いとは思う
  • Collaborator config、最低限で簡単に作るなら以下の感じ、Domainは実際に使っているものからexample.comに変更している. IPアドレスは適当にマスク
{
  "serverDomain": "burpcollaborator.example.com",
  "workerThreads" : 10,
  "eventCapture": {
    "publicAddress" : "18.xxx.xxx.x",
    "ssl": {
      "hostname" : "burpcollaborator.example.com" # Self-signedで良い場合はこう、ちゃんと運用するなら証明書ペアを設定する
    }
  },
  "dns": {
    "interfaces" : [
      {
        "name": "ns1",
        "localAddress" : "172.31.xx.xx",
        "publicAddress" : "18.xxx.xxx.x"
      }
    ]
  }
  "logLevel" : "DEBUG"
} 

Server起動

BurpSuite Professionalをダウンロードして、同じディレクトリにconfig(mycollabo.config)を置いて...

こうじゃ!

sudo java -jar burpsuite_pro.jar --collaborator-server --collaborator-config=mycollabo.config

f:id:news-nknskn:20211129211301p:plain

ログはこんな感じ

f:id:news-nknskn:20211129212309p:plain

ふむ、fromとquery、要は[ ]で囲われたところを見ているわけですね. で、no interaction IDsってのはCollaboratorの例にあるランダムな値(f294gchg2la...r9gfとか)が入ってくるので、サーバはそこを使ってClientと会話している、と.

ということで、Collaboratorサーバを使ってあーだこーだやりたい場合はその辺を見ておけばOKってことですね.

詰まったこと

  • ConfigのNS設定
    • サンプルにもあるけどinterfacesは複数設定可能. サンプルに寄せてns2の設定をlocalAddressと同じ値にして起動したら、ns2の方の設定を起動するタイミングでdnsサービスのbindエラーが起きた. 当然ですね.
    • というわけでNWインターフェースの数に合わせてinterfacesの項目は設定すること
  • Route 53 ホストゾーンのNS設定
    • なにを血迷ったかホストゾーンを削除していて(覚えていない)、ホストゾーン自体のNSがドメインのものとズレていた. バッカじゃなかろか
    • 取得ドメインの方に書いてあるネームサーバをホストゾーンのものに変更して、ゾーン情報が更新されるのを待って、解決
    • ホストゾーンのNSを取得ドメインに書いてあるものに変更しようとしたけど、なんでかできなかった. 出来ないのは当然なのか?(勉強不足

所感

  • おかしなところで躓かなければ1時間かからずに構築できると思う. この手の検証用サーバを簡単に立てられるのは非常に嬉しい. Portswiggerには感謝
  • ドメインの更新をやめた時以外にRoute 53のホストゾーンを削除してはならない(戒め)
  • ぱぱーProfessionalかってー

以上

Office VBA for macOSでのExecutionについてちょっとだけ

Windowsに疲れたのでmacOSで遊んだ話.

事前知識

わたしが持っていたのはこの辺

とりあえずdocのマクロからpythonを実行するとこまでをゴールにしてみた.

既知の実行方法

ブログの内容と, なんとなくWindowsと同じように備わってそうな機能を確認.

  • Private Declare PtrSafe Function system Lib "libc.dylib" + system("echo ...")
  • Private Declare PtrSafe Function popen Lib "libc.dylib" + popen("echo ...")
  • libc.dylib + .slk file
  • Built-in Shell()

だいたいこの辺でsay helloだとかを実行してみた. だが目立つ. libc.dylib もだけど shell() はダメだろって感じ. Objective-See's Blog の解説にもあるが, olevba みたいなマクロ展開ツールがAVとかに入っていて解析していたら即バレする気しかしない.

なのでもうちょい隠せそうな方法を調べてみた.

結論

  • AppleScript(MacScript or AppleScriptTask) + one liner shell

VBA for macOS ではMacScript (AppleScriptString) で AppleScript を実行できる. もうちょい言うとこの関数は廃止済み(まだ一部のバージョンでは動くけど)で, 公式は AppleScriptTask を使うことを推奨している.

そんで AppleScript では do shell script "shell command" でコマンド実行ができる. というわけで, 繋げてこんな感じで書くと VBA から sh -c 'say hello' をAppleScript経由で実行できる.

Function helloViaAppleScript()
    aString = "do shell script " & Chr(34) & "say hello" & Chr(34)
    MacScript (aString)
End Function

ここで攻撃者的に良い点はaStringの内容を適当にエンコードできそうな点. 既知の方法だと実行用の関数とかPrivate Declare PtrSafe Functionで捕まえられそうな気がするが, "do shell script"をエンコードすればolevbaとかだけではそう簡単に解析できなくなるはず. そもそもマクロ内でAppleScriptをどの程度使うのか, って話はあると思うが.

あとは python ファイルを作って実行すればOK. このとき端末へのアクセスはOfficeではなくshellが行なっている点に注意. Officeにアクセス権限を渡していなくてもshell(Terminal.appかも)にFull Disk Access permissionを渡しているとファイル生成を障害なく行える. ね?簡単でしょう?(開発者の人は注意しよう)


10/19 追記

端末アクセスの箇所は勘違いだった. 遊んだ過程で設定ミスがあった模様. 後日再検証する.

以上

ちょっとした読み物枠:初期感染(Initial access)に関する考察 - [RedTeaming][情報セキュリティ][マルウェア配送]


今回は、なんの因果かわからないけど仕事としてRedTeamingをやってみて、攻撃側の情報としてなかなかネットに転がっていなかったりRedTeamingの本とかでも深く掘り詰めてなさそうなところをいろいろ考えたので、後進のRedTeamerあるいは企業のネットワーク設計・管理・運用担当者さんへ向けての参考材料として、以下の方針でメモを書いておきます。

  • 極力技術的に細かい話は書かない、企業ネットワークの設定・構成に関しては細かいとこを気にしてるのでそのあたりは書く
  • 攻撃側が実際にどんなことを考えてプログラムを作ったりするのか、だとかを攻撃者目線で

ToC

そもそもRedTeamingとは

WikipediaさんによるとRedTeamingは以下のような感じです。

ある組織の効率性を改善するように挑む独立したグループで、対象組織に敵対した役割あるいは視点を持つことを前提とし、(省略)侵入テストの担当者は、組織のセキュリティを評価する。多くの場合、対象組織の職員には知らされない。 このタイプのレッドチームは、演習、ロールプレイング、または発表された評価よりも、セキュリティ準備状況のより現実的なイメージを提供する。 レッドチームは、特定の運用環境内でアクティブなコントロールと対策を引き起こす可能性がある。(以下省略)

なんか英語の直訳感があるけど、ざっくり内容を書くと

  • 「攻撃」を提供する企業(以降、攻撃側)と「防御」の実践を行いたい企業(以降、防御側)、双方の合意に基づいた、情報セキュリティにおける攻撃シミュレーション
  • 目的は、防御側が定めたゴール(情報資産の持ち出しやらネットワーク管理者権限の奪取やら)に到達できるかをチェックすること

という感じ。攻撃側は、いわゆる「標的型攻撃」を防御側に対してガンガンしかけていって、その結果・内容を報告する、形になります。会社ごとのサービス内容と契約によって呼び名と内容が「なんかミスマッチじゃね?」ってなることは往々にしてあるので細かいことは気にせず、まあこんなもんなんだって程度で。

実際攻撃側はなにをやるのか

Cyber Kill Chainが定義されて久しいけど、ざっくりこんな感じ。

f:id:news-nknskn:20210410233353p:plain PDF, IoT時代のサイバーセキュリティ確保に向けて, P.8, IPA

「目的達成」のとこはざっくりすぎて防御側が具体的に何をどう守ればいいのかわからん、みたいな話があって別のモデルも考えられてはいるんだけど(Unified Kill Chain、本家のPDFがなくなってた、どっかにアーカイブあるんかな)、この記事では上の画像でいう「武器化、エクスプロイト〜遠隔操作」の部分を深掘りするので、ここでは割愛。

というのも、「目的の達成」の部分は技術的な話になりがちで、かつ「昔から使われている手法からほぼほぼ変わってないし、なんだかんだ情報転がってる」というのが実感としてあるからです。記事の趣旨からズレるからね、仕方ないね。興味ある人はいろいろ調べて、どうぞ。

武器化、エクスプロイト〜遠隔操作について

"じゃあ「武器化、エクスプロイト〜遠隔操作」はなにか変わっているのか"という話。個人的にはここもそんな大きくは変わっていないんじゃないかと考えてます。それならなんでこのブログを書いたんだ、ってとこに関しては、攻撃側の情報としてなかなかネットに転がっていなかったりRedTeamingの本とかでも深く掘り詰められていないように見えている、かつ結構頑張って考えたと自負しているからです(スクリプトも作ったしAVにもたくさん消されたし)。

そんなわけで、以下、安定的な「遠隔操作」の実現に向けて、本気の攻撃者が考えているであろう、かつ極力汎用的なところまで落とし込んだことをつらつら書いていきます。防御側の人は読んでみて、実際の攻撃者への嫌がらせをたっぷり考えていきましょう。

Initial accessの成功条件について

まずマルウェアを標的組織内に送り込んで実行させることを目標とした場合に、攻撃目的からプログラム要件を考えてみます。一般化した場合はおそらく以下のような感じになるでしょう。

  1. ランサムウェアタイプ
    • 外部と通信する必要はない(マルウェアに持たせた公開鍵でファイルを暗号化すれば良い) = HTTP/外部DNSへの通信はいらない
    • 継続的にマルウェアを動かす必要がない = Persistence設定もいらない
    • 端末上のファイル暗号化を行う
    • ローカルネットワーク内の端末を探索し、どんどん感染端末を増やす = ここは想定攻撃範囲次第
    • 初弾で検知されなければある程度問題はない = テストの際一部セキュリティソフトに検知されていても、気にせず送り込める
  2. APT / 情報窃取を目的とした標的型攻撃タイプ
    • 外部と通信する必要がある = HTTP/外部DNSとの通信が前提、企業内ネットワークタイプの想定および準備が必要
    • 継続的にマルウェアを動かす必要がある = Persistence設定が必要
    • マルウェア上で多種多様なコマンド実行を行える必要がある = コマンド実行のためのモジュールが必要
    • ネットワークの探索は自動では行わない(検知される可能性を下げるため)
    • あらゆるAV/EDRに検知されないようにする必要がある(標的組織で利用されているセキュリティソフトの特定前という条件) = 上記の要件を満たす各アクティビティが検知されない仕組みの用意が必要

基本的に、ランサムウェアタイプは初弾が検知されずに実行されれば成功、というシンプルなものに対し、標的型攻撃タイプはいくつか条件があることがわかります。RedTeam的には「C2がうまくいき」かつ「継続的にマルウェアを動作させる」ことができれば大成功、最悪でも外部との通信経路を確認できれば次弾の用意が捗る、という感じです。

今回はRedTeam(APT/標的型攻撃タイプ)を前提にしているので、2について深堀りをします。それでは各項目について考察していきます。

外部と通信する必要がある = HTTP/外部DNSとの通信が前提、企業内ネットワークタイプの想定および準備が必要

そのままで、外部との通信を「どのプロトコルで」かつ「どの経路で行うか」という話です。目的は以下の2つです。

  1. C2サーバと通信を行う(感染端末⇄C2/Exfilサーバ)
  2. 取得した情報を持ち出す(感染端末→C2/Exfilサーバ)

1に関しては説明不要だと思います。攻撃を継続的に行うために、感染端末上で何かしらの操作ができるようにするということです。いろいろな解析ブログでもC2に関しては触れられていますね。

2に関しては1と異なり、完全に端末の掌握はできない場合でも、2回目にマルウェアを送付した際にマルウェア感染・端末掌握の成功確率を引き上げるための戦術になります。具体例を挙げると、端末上のセキュリティ製品情報の持ち出しであったり、外部との通信で利用可能なプロキシ情報であったり、C2通信に利用可能なプロトコル情報など、必要最低限な情報だけを外部に送り、最終的なマルウェア感染は(わざと)しない、というものです(できればラッキー)。

それではまず企業内ネットワークを考えてみます。なにかしらで外部と通信可能という前提で企業ネットワーク内にある端末(内部デバイス)を想定した場合、おおよそ次のようなネットワーク構成があると思います。HTTPプロキシに関しては、外部・内部・その他用途といろいろもっと細分化できると思いますが、数だけ多くなるのでいったんはこのぐらいにしておきます。またCASBなどのサービスは考慮外とします。

f:id:news-nknskn:20210415022928p:plain f:id:news-nknskn:20210415022950p:plain ※図はLucidchartで作成

各図を説明すると以下のような形です。

  1. 左ー上の図、HTTP(S)ではインターネットと直接通信可能な穴があり、プロキシ通しても通信可能、DNSも外部を参照するようになっている
  2. 右ー上の図、用途別にプロキシがある、通信の制御がブラックリスト形式とホワイトリスト形式で異なっており、HTTP(S)のデフォルト通信先はホワイトリスト制御のプロキシに向いている、DNSは端末から外部参照可能
  3. 左ー下の図、HTTP(S) でインターネットと通信するためにはプロキシを通る必要がある、名前解決はプロキシが行なっており、端末からは名前解決できない
  4. 右ー下の図、DNSのみ外部と通信可能

それぞれについて、どのプロトコル、かつ経路で通信可能かを考えてみます。

  1. HTTP(S)/DNSで通信可能、HTTPでプロキシを参照しない方がログに残らなくて良い
  2. HTTP(S)はNot blacklistedなプロキシを指定した場合、もしくはDNSは特に考えずに通信可能、プロキシ情報はpacに記載されていると想定されるのでpac取得した上で指定する必要がある
  3. HTTP(S)でのみ通信可能、プロキシを参照する必要がある
  4. DNSのみ通信可能

だいたいまとまりました。Initial accessでは、1-4すべてで情報の外部持ち出しを試み、かついずれかの通信経路に対応したマルウェアを動作させる必要がある、ということがわかります。

ちなみにですが、その辺に公開されているC2 Frameworkで生成されるマルウェアでは、このあたりのプロトコル調査・経路探索はやれないので自分で準備する必要がありました。標的組織に送り込めるファイルタイプとの兼ね合いもあって、実際の初弾はVBAマクロになりがちです。この辺はもう仕方ないなーと思って白目剥きつつオレオレフレームワークを作ってました(現在進行形)。

対策

マルウェアがHTTP(S)で通信を行おうとした場合レジストリや.pacの参照を行うことになりますが、この辺での検知は非常に難しいので昔からある通りプロキシ(あるいはその他のデバイス)のログを基に検知するしかないと思います。問題は複数プロキシがあり、かつデフォルトがホワイトリスト形式のプロキシに向いている場合です。端末上のデフォルト通信先設定で安心しちゃってブラックリスト形式のプロキシログの監視を行なっていない場合、C2通信の検知ができない恐れがあります。

めちゃくちゃ大変でしょうが、企業内にあるプロキシに関してはすべてについて用途、通信可能・あるいは不可能なドメイン、およびログ監視の有無の棚卸しをした方がよいでしょう。

DNSに関しては、個人的には3. 左下の図の形が良さそうな気がしています。外部への情報持ち出しを止めることは難しいですが端末の掌握自体は防げますし、業務利用を考えても外部との通信が可能な状態を維持したままにできるので(なお構築)。

余談
  • だいたいのC2 Frameworkが出力するマルウェアは、プロキシ情報(レジストリのProxyServer)を参照するようになっているようなので、単にプロキシ置いてレジストリ設定しただけではほぼほぼ通信阻止に至りません(pacの場合はわかりません、全Frameworkを調査したわけではないので)
  • DNSで安定してC2できるFrameworkが少なすぎてつらみ

継続的にマルウェアを動かす必要がある = Persistence設定が必要

それでは次にPersistence設定について考えてみます。インストールされているソフトウェアによって増えたりしますが、パッと思いつくところだとこんなもんではないかと。

  • レジストリ、HKLM, HKCU 配下のRunとかRunOnceとか、LogonscriptとかCortanaとかいろいろ(一部要管理者権限)
  • スタートアップフォルダ
  • スケジュールタスク
  • サービス(要管理者権限)
  • DLL (search order) hijacking / side loading
  • Officeアドインフォルダ
  • Keepass
  • その他プラグイン/アドイン/拡張機能

まずKeepassやらプラグインアドイン拡張機能に関してはインストール済みが条件となるので、汎用性を考えた場合設定対象からは外れます。

次にレジストリですが、実際のInitial accessでもよく用いられるためか、ちょっと(けっこう?)前からVBAからのレジストリアクセスがWindows Defenderに検知されるようになったようでした。コードベースで検知された可能性もありますが、一度でも検知された以上積極的に採用する気にはなりません。またサービスは要管理者権限ですし、よほど運が良くない限り登録できないでしょう。

DLL系は...一発で見つけて、かつPersistenceするのは相当難しいです。検証はしているものの、そもそもsearch orderの設定不備が、標的になった組織でほぼほぼ見られないのであまり採用する気にはなりません。

そのような感じでどんどん絞っていったところ、わりとスタートアップフォルダへのドロップ、およびOfficeアドインフォルダへのファイルドロップは比較的アンチウイルスソフトに検知されにくいような印象を受けました。ただしEDRにはかなり検知されます。さすがに怪しいからね、仕方ないですね。

というわけで、今後Persistence対象として選ばれる可能性が高くなるのはフォルダ系と見ています。

対策

この辺は設定されないように防ぐ、ということは難しいですが、EDRでの検知がめちゃくちゃ強い部分だと思います。アンチウイルスソフトEDRの強いところを組み合わせて、総合的に守っていくようにしましょう。

侵害済み端末かどうか、のところに関してはまずAutorunsとかで確認して、DLL漁っていくとかアドイン探すとかになるのでしょうかね。かなり大変なのであんまやりたくはないですね。

マルウェア上で多種多様なコマンド実行を行える必要がある = コマンド実行のためのモジュールが必要

ここは詳細、対策は省略。攻撃側は公開されているC2 Framework使うとか、商用のもの使うとか、その上でEvasionを頑張るしかないところかと。私は自作のプロトコル・経路探索のやつに、特定のセキュリティ製品の場合だけ任意のタイミングでコマンド実行できるモジュールをロードするようにしてみました。

防御側はEDRとかでのエンドポイント検知を頑張るしかないかと。

ネットワークの探索は自動では行わない(検知される可能性を下げるため)

(やらないので書くことは)ないです。

あらゆるAV/EDRに検知されないようにする必要がある(標的組織で利用されているセキュリティソフトの特定前という条件) = 上記の要件を満たす各アクティビティが検知されない仕組みの用意が必要

はい、ここまでで一通りInitial accessで必要と考えられる要素を挙げてきました。最終的には標的組織内に送り込むファイルに、要件通りのものを仕込んだ上でAV/EDR Evasionやって、メールで送るなら経路上での検知を潜り抜けるようにして、気づかれないように実行してもらうだけですね。頑張りましょう。

あとがき

ここまででRedTeamプロジェクトの始めも始め、というか正直まだ始められてもいない(けど苦労はめちゃくちゃしている)という段階の話です。いかがだったでしょうか。

攻撃者としては、2弾目以降の攻撃で足掛かりになる情報はかなり欲しい気持ちになるので、情報の持ち出しについて深く考えているんじゃないかと思います。

防御側に関しては、外部との通信方法について改めてネットワークを確認いただくことで、ハードニングも捗るんじゃないかと思います(なんの通信も外に出てこなかったりすると、攻撃者は何もわからなくて寝れなくなるんじゃないでしょうか)。ネットワーク構築の際も大変な思いだけして作るのも気が滅入るので、攻撃者にたっぷり嫌がらせができる構成を考えて楽しみつつ実装していきましょう。

Dear real attacker,

f:id:news-nknskn:20210415040223p:plain 進撃の巨人、一巻

以上