二年ほどチームリードをやったときに考えたことと把握に努めたことのメモ

GWなので振り返ってみたらいろいろあった＆そのうち忘れそうなので、メモがてら残しておく

お断り

• 「チームリードとはかくあるべき」などと言うつもりは一切ないこと
• ケーススタディレベルであること
  • 状況的にやらざるを得なかったことや、本来やるべきではないかもしれないけど状況を良くするなら把握すべき、と考えたこと等を過分に含んでいる
• 独学我流の内容であること
  • 大学やMBAなどでの専門的な勉強は、一切行なっていない
  • 組織論やマネジメント関連の本はボチボチ目を通した
    • 累計だとたぶん100冊ぐらい
    • 古今東西を問わない
    • 使えるものは使う精神
• 再現性のある内容ではないこと
  • 組織やマネージャーによっては身動きが取れずにうまくいかないケースは確実にある
  • メンバーが強力かつ協力的であったために、結果的に上手くいったモノもある

---

立場とやっていたこと

• この記事内の「チームリード」の立場は以下
  • プロダクト・システム等ではない、人的サービスを提供しているチームに所属
  • 社内の役職としては"現場メンバー"と同列
  • 実働における立ち位置は、マネージャーとメンバーの間
• 組織における権限やら責任だとかの細かい部分は省略
• ざっくりやっていたこと
  • 自チームのマネジメント系
  • 自チームのデリバリ系
    • 既存サービスの管理
    • 新規サービスの開発
    • 自身でのサービス提供
  • 他チームとの関わり系

マインドマップ

ざっくりやっていたことに対して、考えたこと、その中で「把握すべき」と判断し収集・整理に努めた情報等、それらを踏まえて行なったことをざっくり書いてみた。抜け漏れはたぶんある

根本的な考え方

• 個人"至上"主義ではない
  • "個人"の尊重が大きい声で唱えられている世の中ではあるが、組織ないしチームに属している以上、個人至上では組織・チームはそのうち立ちいかなくなる
  • 逆に、組織/チーム至上に傾けば個人が蔑ろにされやすい
  • このことから、組織/チームがうまくいっている状態を持続しつつ「個人が好き勝手やれる"環境"を作る」ことを命題とする
• 組織/チームがうまくいっている"ように見せる"
  • 売上や稼働率など組織・チームで設定されているKPIが"最終的に"（Q4頭〜中盤あたりに）達成できている状態を目指す（できるとは言っていない）
    • 多くの経営層・マネージャーは達成さえすれば、達成後に経過は問われない（ことが多い印象な）ので、途中の小言はケースバイケースでスルー
    • "平均値"などの割合（率）が目標に含まれている場合、その項目にだけ日頃から（週単位等で）気を付ける
  • 各個人レベルでの不満は極力少ない
    • 全員が「不満がない」状態の構築は、人間に欲がある以上、根本的に無理
    • "抱いた不満を解消できる"環境・状態であることに注力
    • 不満は都度細かい粒度で把握し、解消に使える材料は探す or 作る
• 成長持続性の担保
  • 個人が「成長」し続けられるサービスの立て付けやアサイン管理、プロジェクト管理を行う
    • 「成長」は、精度向上、速度向上、対応可能範囲拡大、視点・観点の深化/拡大、と定義
    • 組織・チームの成長性は「（基本的に）各個人の成長性に帰着する」と定義
      • 組織・チーム・個人の成長周りの話はおそらくニワトリタマゴ、逆に言えば「相関がある」
      • 前提として"人的サービス"を提供するチームであるため、各個人を軸とする
        • 組織/チーム/サービス vs 個人で考えたときに「どちらでも良さそうな場合に」個人を優先する程度
        • 多くのケースは「チーム優先の結論」あるいは「個人A vs 個人B」になるので、この軸が効くタイミングは少ない
      • サービスクォリティはまた別
    • 各個人の成長の方向付け、成長の"意味付け"をほどほどにサポート
      • 成長軸は「個々人が考えているもの」とするが、必要に応じて結果の出方・見え方を組織やチームが求めているものに「ズラす」
  • チーム成長の方向性は、企業や組織のミッション、成長戦略に"沿う"形にする
    • 完全一致させる必要はない
    • 少なくとも、成長のための"相互作用"を発生させられる方向には整理

目標設定

• リードになった際には、三年後の理想の状態と、理想に基づいた各年・直近半年等での目標を設定
  • 売上目標の絶対値と推移
    • 予想
  • 案件の絶対値と推移
    • 理想
    • 予想
  • 各タイミングでの、各人におけるデリバリ能力の絶対値と推移
    • 理想
    • 実現性・実現条件
    • 予想
• 目標を設定する上で必要となる情報は、マネージャーやメンバー等、上・同・下レイヤに対して必要な分会話

---

二年後の結果と考察

二年経ったタイミングでいろいろあって異動することになったので、その時点での結果・見え方を記載

• KPI等の数字は達成していたので、上からの文句はなかった
  • マネージャーが良い感じに上をコントロールしていたのもあった（そしてこれがたぶん大きかった）ように思う
  • 数字を伸ばしすぎないようにいろいろ調整するのも、事業的な良し悪しはあれど状況によっては必要
    • 案件過多による負荷にならないように
    • 次年度の目標数値コントロールのために
• メンバーの成長や不満に関して
  • 伸び幅は個々人の資質や努力に基づくのでなんとも言えないが、総合的には大いに成長していた印象
  • アサインに基づく経験幅は、おおよそイメージ通り
    • 受注状況やプロジェクトごとの詳細部分での都合などに左右されるので、ここは運に恵まれた
  • 不満関連
    • 大きな問題に繋がりそうな不満はあまり聞かなかった（拾えていなかった可能性は高い）
    • "即実戦レベルの経験"と"のちのち効いてくる経験"の積み方（アサインの仕方、プロジェクトにおける課題設定）で、「のちのち効いてくる」方はその時点での不満度にハネるケースはあった
      • さらに1年経ったあとで話を聞いたときには「あのときやっといてよかった」的な声もあったので、結果的に方針自体は悪くなかった模様
• サービスを2〜3リリース＆それぞれボチボチ受注
  • 既存サービスへのオプション的な流用やらカスタマイズ案件への流用やら、派生系の元にもなっていた
  • サービス開発において心がけていたこと3点
    • 社会あるいは顧客の成長戦略に沿う、あるいは成長の先に必要となるものであること
    • 汎用性・流用性が高い側面を持つこと
    • 既存サービスの流れを汲んでいる（既存サービスの前・後に置ける可能性がある）こと

やった所感

• 組織・チームの状態や目指す方向性、マネージャーや同僚にも左右されるが、チーム的には「順風満帆、逆に依頼が多くて困る」な状況下での着任だったので、前向きに考えることができた＆取れる手は多かったように思う
  • この状況のおかげで「やらない」選択肢（贅沢な悩み）についても考えることができた
  • 異動先はアレがアレでソレもソレだったので、そっちの状況と比較するといろんな意味で幸せだったように思う
• 自身・他人への"期待感"・"期待値"の持ち方がだいぶ整理された
  • 得手不得手が個々人にある中で「理想や願望に基づく期待」をすると、その「期待」に関連する人間（自分ないし他人）が不幸になる（ストレスを受ける・ストレス値が高くなる）ことが高い印象
    • よくある「勝手に期待して勝手に失望する」やつ
  • 確実にできること、願望（自分・その人の理想）は明確に分ける、少しでも理想に近づいたら一緒に喜ぶ、ぐらいが精神衛生上健全っぽい
• この考え方・やり方も組織や人によって効果の有無は変わりそう＆好き嫌いありそうなので、取れる手段のひとつ程度に考えておくのが無難かも
  • ピープルマネジメント面は特に
    • あんま立ち入られたくない人はいるだろうし、そういったケースで取れそうな手はいくつか考えておくのが良さそう
  • 他のワーク（プロダクト系とかの）マネジメントも面白そうなので時間があるときに考えてみたい

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

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

OSDA is 何

この辺のブログ参照

• OSDA(Offsec Defense Analyst)の受験記 | 株式会社レオンテクノロジー

印象

Labやってましたが、内容はElastic Stack使った攻撃の分析で、分析対象はInitial Access〜Domain Compromise、攻撃パターンはCVE系なしでだいたい押さえてるものの、実務経験アリな人にはあんま新トピックはなさそうです。Examは今試験環境でトラブってて、いつになったら申し込めるやらって感じですね

— ツイッター川(BOD 4.9mg/L)のフナ (@nknskn) 2023年4月3日

そうですね、攻撃の内容を理解する＆手を動かすには良さげです。わたしも一連の攻撃を分析するのは初めてだったので、かなり勉強になりました。試験では分析内容を英語で書かなきゃいけない（Flag形式ではない）ので、新人さんにはその辺が大変かもです。わたしはテンプレ文言をほぼほぼ作りましたw

— ツイッター川(BOD 4.9mg/L)のフナ (@nknskn) 2023年4月3日

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

事前知識

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 何

この辺のブログ参照

• 完全未経験の文系事務員がOSEPを取得するまで - Qiita
• ノンペンテスターの OSEP 合格体験記 (2022/10) - 切られたしっぽ
• OSEP: OSCPの続編的な資格を取った話 - ommadawn46's blog
• OSEP受験記 - ごみばこ
• Offensive Security資格「OSCE3」ホルダーへの道 - NFLabs. エンジニアブログ

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

普段の業務で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プロジェクトで使うペイロードのサポート（作ったり教えたり）、新サービス１の開発・リリース、新サービス１の初案件を捌いた	まあこんなもんかな（恒例行事）、という気持ち。定時退社
2022/1-3 プライベート	メンバー	GCPN取得、行政書士の勉強を始める。大学からの付き合いのフットサルには参加していた	チーム体制に怪しい動きが見え始めていたので「前々からやりたいと思ってたことを今のうちに」と他分野の勉強を始めたが、時既に時間切れだった。思い立った時点で手を動かさないといかんと改めて思った
2022/4 仕事	リーダー	突発的人事変更に伴いロール（リーダー）引き継ぎ。チーム稼働方針・サービス提供方針の再検討、長期的なビジネスモデルの変更およびメンバー育成を踏まえた新サービス２の開発をひとりで開始。案件提案、採用面談、メンバーのプロジェクトアサインコントロールに巻き込まれ始める。診断案件は変わらず捌いていた。チーム内の月一技術勉強会で発表	ひたすらバタバタした時期だった。仕事を抱え込む余裕すらなかったので自然とタスクを周りにお願いする形になった。結果的には、お願いすることに抵抗がなくなったのでバランスを取れるようになった気がする。バタバタとはいえ引き続き定時で切り上げていたらしい
2022/4 プライベート	リーダー	慣れない仕事の疲労でこの辺はなにもできなくなっていたので省略。フットサルは継続	とかいいつつTwitterは相変わらず見ていた模様
2022/5 仕事	リーダー	各メンバーに対する理解深掘り、新サービス２の開発を継続。新サービス２はリリースすることができた。診断はメンバーで捌けなくなった案件を捌くスタイルに変更。チーム内の月一技術勉強会で発表	なお、捌けなくなったものだけのはずなのに毎週2-3案件捌いていた模様。疲労との付き合い方を考え始めた。なお引き続き定時（ry
2022/6 仕事	リーダー	新サービス２の初案件を開始。並行ではないものの診断案件も引き続き実施。サービス提案で口を出し始める。チーム内の月一技術勉強会で発表	この辺りからサービス２とその他関連サービスの最終的な着地地点がぼんやり見え始めてきていた。それに向けて提案内容をコントロールする試みを始めていたらしい。定時（ry
2022/7 仕事	リーダー	新サービス２の初案件を完遂。その他調整で手間がかかりそうな案件のプロマネを始める。面接・アサインコントロール・提案は継続実施。チーム内の月一技術勉強会で発表	ひとりでの新サービス開発はもうやらんと心に誓う。この辺で継続実施しなきゃいけないタスクの要点を把握し、効率化が終わり始める。最終的には「この辺の話に誘導してあの人に投げよう」という方針になった。定時（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 何, な人はこの辺参照. 他のブログは適当にググってどうぞ.

• OSWE Web Application Security Training, WEB-300 | Offensive Security
• OSWE認定試験の紹介と受験記: NECセキュリティブログ | NEC
• OSWE合格までの道のり
• OSWE Review(受験記) - 高林の雑記ブログ
• OSWE 2020 review - Qiita

試験の内容を要約すると, 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, というもの.

ここで書いてること

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

事前準備

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

• 仕事: 日本でのWebアプリ脆弱性診断が6年ちょっと, ペネトレ・RedTeam経験が3年ほど
• 資格: OSCP取得済み
• 趣味: 普通のと, 脆弱性検証用(他人に攻撃検証させる目的)のWebアプリ開発が少し(Python, PHP, Ruby, JavaScript, MySQL, SQLite, 各言語のフレームワークぼちぼち), プライベートでのCTF作問(Electron関連)少し
• その他: 脆弱性診断サービス, マルウェア解析経験, 資格取得等はボチボチあるが, OSWEには直接的に関係がないので省略.

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

• 報告書のテンプレ作成
  • ハイレベルサマリの記載 - 達成具合で文言を削除すれば提出できる程度
    • 発見した脆弱性と,何をするために何の脆弱性を使ったのか, の枠
    • 各種脆弱性の推奨改善策例, 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レスポンスだけで判断するには難しい問題を検知するためのツールで、外部への通信が発生する系の問題を検出できる
• サポートしているプロトコルは以下. 動作ポートは変更できるが, デフォルトを使用するのが基本的には良いはず
  • HTTP
  • HTTPS
  • SMTP
  • SMTPS
  • DNS
• 検知できる脆弱性の例は以下
  • OSコマンドインジェクション、curlとかnslookupとか
  • Blind SQLインジェクション
  • SSRF
  • RFI
  • Blind XSS
  • メールヘッダインジェクション
  • ...

参考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

ログはこんな感じ

ふむ、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で遊んだ話.

事前知識

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

• Objective-See's Blog
  • Lazarus APT Targets Mac Users with Poisoned Word Document - SentinelLabs
  • Microsoft Word File Spreads Malware Targeting Both Apple Mac OS X and Microsoft Windows
• GitHub - malware-unicorn/MacOS_VBA_Macro: Example VBA Macro for MacOS Mojave

とりあえず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 を使うことを推奨している.

• VB を使用して AppleScript を実行する | Microsoft Docs

そんで 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 追記

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

以上