CSIRT演習 writeup（事前課題）
Bono（@Bono_iPad）です。
去る2015年11月8日、SECCON2015 大阪大会 CSIRT演習に、チームbinjaとして参加しました。結果は2位。
CTFチームのbinjaとしてはかなり健闘したと思います……が、やはり本職中の本職集団NWには勝てず、本選への切符を手に入れることはできませんでした。
しかし、事前課題や本戦を通じて、CSIRTや危機管理について楽しく学ぶことができ、得るものが大きかったイベントでもありました。
それから１年。実は公開の準備をしておきながら、忙しさにかまけて公開のタイミングを逃し続けていたSECCON 2015 大阪大会 CSIRT演習の事前課題ですが、CTF Advent Calendar 2016に乗じて（厳密な意味でのCTFとは言えないかも知れませんが、misc扱いということで）公開してみようと思います。この記事は、CTF Advent Calendar 2016の7日目です。
SECCON大阪大会は、予選として事前課題の提出が求められました。内容は「CSIRT の窓口対応」について問うもので、実際に起こりそうな情報セキュリティ関連のトラブル５問に対して、それぞれに「どのような初動対応を行うか」「どのような原因が考えられるか」「どのような調査を実施するか」につき記載するものでした。 今回は、この事前課題を公開します。
事前課題は、binjaチームのslackで検討を重ね、最終的に私（@Bono_iPad）がまとめました。
課題の書き方の戦略として、初動対応については共通の対応・対策が相当あるので、問題1で共通部分についてはあらかじめ全て書いてしまい、問題2以降は、各問題に特有の話を中心に記述するようにして、できるだけ重複を排除できるようにしました。
なお、私はITとあまり縁のない職についていることもあり、チームの助言を頂いてはおりますが、内容の正しさなどについては保証できません。内容の誤り、誤字・脱字などの問題がありましたら、ご指摘頂ければ嬉しいです。
あくまで参考資料として、何かのお役に立てば幸いです。
以下、提出した事前課題
初動対応の原則：
インシデント報告への全ての対応につき、必ず時刻付きで記録する
インシデントの優先度の判断（トリアージ）を行う
CSIRTチームにおける情報共有、必要に応じて招集
関係者以外への情報規制方針を決定
初動対応として、インシデントがいつ覚知され、どのように扱われたかは、記録すべき情報である。インシデントの状況は刻々と変化する。怪しい動きに気付いた攻撃者が、証拠を消しにかかるかも知れない。どの段階で何をしていたか、何をしなかったが分かることは、事後の分析、さらに責任の明確化のため重要である。さらに、時刻を明確化することで、対応中に新たに起こった事項を洗い出すことが可能となる。
また、今回の例のように「『何か検知した』という連絡があった」というレベルの段階で、すぐにCSIRTに情報が上がる環境は整備しておく必要がある。インシデントでないかも知れない、と発見者が連絡をためらったがために、事態が急速に悪化する可能性もある。インシデントが疑われた段階で報告をする窓口が、可能であれば電話・メール・FAXなど、複数の経路で設けられている必要がある。外部からの情報の対応にあたる人間全てがITの専門家ではない。インシデントの重要さや優先度はCSIRTの判断すべき事項として、全てのインシデント疑いの事例がCSIRTに報告される体制が必要となる。
CSIRTが全ての報告に最高の対応ができればそれに越したことはないが、ほとんどの場合、人員や使える設備は限られている。限られた資源の中で効果的な活動を行うため、寄せられた報告や情報に対してCSIRTが対応すべきか否か、対応の優先度はどの程度かを判断する必要がなる。これをトリアージと呼ぶ。事実関係の確認、CSIRTの対応の必要性、関係各所への情報提供の必要性の判断が、この段階での主要な判断事項となる。この判断を迅速かつ冷静に行うため、CSIRTの活動ポリシー（何を守るのか）や、判断基準は、あらかじめ明確にしておく。また、原因究明は、優先度の判断が遅れてしまうため、原則としてトリアージの範囲を超える。あくまで、起きている内容（いつ、どこで、誰に、なにが、どのように起きたのか）から優先度を判断する。
CSIRTにおいては、情報共有を常に行い、必要に応じて容易に招集が可能としておくことが必要となる。CSIRTの初動対応を行う際、CSIRTが独立部署として存在する、いわゆる「専任型」の組織である場合は、そのままCSIRTとして活動できるが、そのようなCSIRT実装はまだ少ない。日本シーサート協議会加盟組織一覧2014 年版（http://www.nca.gr.jp/imgs/nca_teams_2014.pdf ）によれば、CSIRTが独立部署として存在する、いわゆる「専任型」は19%に過ぎず、部署横断型、つまり「兼任型」の組織が67%、その他が14%となっている。そのため、常に情報共有を行い、必要に応じて即座にCSIRTチームが招集できる体制が必要である。特に、連絡手段の確保や、最初に情報を受けたメンバーがどのように対応するか、どのように報告を上げるか、という判断基準や、報告を受けた人間が誰にどのように指示を出すのかと言った指揮系統は、あらかじめ明確化しておく必要がある。チーム招集や必要な指示が遅れてしまうことは、対応の失敗に繋がりかねない。
また、情報の規制方針を早期に決定することも非常に重要である。関連各部署や責任者への状況の逐次報告・意思疎通が重要である一方、無関係の人間への情報流出も抑える必要がある。「人の口に戸は立てられぬ」の言葉通り、一度漏れた話は水面下で一気に広がりうる。それによって、関係者が協力に二の足を踏み始めて調査が困難になる場合や、リークによってメディアが動いてしまい株価が下落するなど、深刻な事態に陥る可能性がある。情報は、必要な時に必要な人員と共有する。
以降の問題については、上記原則を踏襲した上での対応となる。
・トリアージ：早期対応の必要あり（少なくとも技術的な原因究明は即座に必要）
今回の事例は、外部の人間より、自社Webサイトアクセス時にウィルススキャナが反応した、という内容である。事実とすれば、自社Webサイトよりマルウェアがユーザーに送信されている可能性を示唆する。技術的な部分も含め、調査は必要である。
・過去に同様の報告がないか、その時どのように対応したか確認する
同様の報告が相次ぐのは悪い兆候である。誤検知である場合も、少なくともそのスキャナを使っているユーザーは自社サイトを怪しい物と判断しうるということである。また、過去の対応での見逃し、あるいは、今度こそ本物、という可能性も否定はできない。対応内容を検討し、抜けがあれば再調査することも必要である。
・該当ページ、検知した状況、スキャナのメーカー、バージョンの確認
・Web管理部門があれば即座に連絡、状況を確認する
・Webサーバーのスナップショット、ファイル、現存するログの保全
まず、現存する証拠を保全する必要がある。もしサーバーへの侵入が行われていた場合、すでに攻撃者は証拠の隠滅に動いているかも知れない。また、サーバー管理者がデータを誤って消去するような状況も避けなくてはならない。部署が異なる場合、連絡を密にして、可能な限り現状を保存しておく必要がある。また、ページが改ざんされた場合、攻撃コードを仕込まれている可能性があるため、不用意に該当ページにアクセスしてしまうと被害に遭う危険がある。他部署に連絡を取る際は、安全が確認されるまではブラウザでのアクセスを止めるよう伝えておく必要がある。
・既知・未知の脆弱性を突かれてWebサーバへ侵入された上での破壊・改竄行為によるもの
深刻な事態である。自社Webサーバーが、実際に悪意あるWebページを表示している状態である。ページが完全に改ざんされてしまう場合であれば明らかであるが、一方でjqueryなど、ユーザーからは見えにくいファイルに悪意あるコードが埋め込まれている場合、一見ページは正常に見える分、気がつきにくい。一刻も早くサーバーをネットワークから切り離し、ファイルの正当性を検証する必要がある。
また、サーバーが共有である場合、symlink attackなどを通じて他ユーザー、あるいは他ユーザーの権限でアクセスしている攻撃者が、同じサーバー上のファイルを改ざんしている可能性がある。
・アクセス元のプロキシキャッシュ汚染によるもの
プロキシを介したアクセスが行われる際、プロキシサーバーが攻撃者の手に落ちていると、キャッシュを汚染させることで悪意あるページを表示させることが可能となる。実際は自社ではなく、通報元のプロキシサーバーに対する攻撃によって今回の事態が起こっている可能性もある。
・ウィルススキャナ、IDS/IPS、次世代FW、UTM等の誤検知の可能性
Malwareの増加や多様化に伴い、新たな検知方法が次々導入された結果、誤検知も増え続けている。
・管理者、あるいはWebページ制作担当者PCのmalware感染などによるWebページへの埋め込み
リモートからのみが感染経路ではない。ローカルPCでmalware感染が発生し、その際、ウィルスがアップロードするファイルに悪意あるコードを仕込む可能性がある。感染したhtmlを気付かずアップロードしてしまった場合、悪意あるページが表示されてしまう可能性もある。
・サーバーへのアクセス権限を持つ者の内部犯行
常に内部犯行の可能性は考慮に入れる必要がある。攻撃者としては最も容易である一方、調査は困難が伴う。関係各部署との連携が必要となる。
・Webサーバーと接続されたPCのmalware感染による、イントラネット内感染の一部
イントラネット内にmalwareが蔓延した結果として、悪意あるページが表示されている可能性がある。
・スキャナが反応した状況の再現
自分がmalware被害に遭わないよう十分な対策を行った上で、同様の環境を構築し、スキャナが異常を検知するか確認する。
・サーバーファイルのバックアップとの比較（存在すれば）
大量のファイルが存在した場合でも、以前のファイルとの比較で即座に悪意あるファイルが特定できる可能性がある。
・既知の脆弱性にヒットしていないか、プロダクトのリリースノートや脆弱性情報の確認
使用しているプロダクトが常に最新となっているとは限らない。また、未修正の脆弱性が存在するかも知れない。既知の脆弱性が存在しないか、再度確認する。
・脆弱性の確認と怪しいログの洗い出し
データベースや動的Webページに対して、通常あり得ないようなリクエストがログに残っていないか、消された後はないか確認する。これを通じて未知の脆弱性を発見する可能性もある。脆弱性が発見された場合、IPAなどへの通報も考慮する。
・悪意あるソフトウェアが確認された時の挙動の確認
悪意あるソフトウェアがサーバーに存在したのを発見した場合、そのファイルの挙動を確認することができれば被害範囲の想定や対策に非常に有利となる。ただし、高度な知識を要求されることもあるので、可能な場合に限られる。
・同一サーバーを使っているユーザーで、同様の事態が発生していないかの問い合わせ
共有サーバーの場合、共有サーバーそのものが攻撃されてしまう場合や、symlink attackにより、あるユーザーが他の同一サーバーのユーザーを攻撃する場合があり得る。
・当該ページの一時閉鎖
・（ページ一時閉鎖が不可能であれば）ファイルの改ざんの有無の確認、改ざんファイルがあれば以前のバックアップの書き戻し
攻撃コードが該当ページに仕込まれていた場合、対応が遅れれば、それだけ被害が拡大する。当該ページは一時閉鎖、あるいは攻撃コードが仕込まれていない状態にする必要がある。当該ページや疑いのあるサーバーを一旦ネットワークから切り離すことが可能であれば、それが最も望ましい。どうしても不可能な場合、現状保存が完了次第、アクセスしても攻撃コードが含まれないページが表示されるようにする必要がある。ただし、攻撃者が再び攻撃コードをページに仕込む可能性があることは、常に留意する。
・標的型攻撃の可能性を考慮する
標的型攻撃の一環として、特定の接続元の時のみ挙動を変えるソフトウェアが仕込まれている可能性もある。
・社内PCやネットワークに悪意あるソフトが存在する可能性はないか、特に当該Webサーバーに接続されているPCやサーバーは大丈夫か確認する
大規模なマルウェア感染が水面下に起こっている可能性がある
・通信のモニタリングを行う
C&Cサーバーとの通信や、感染を誘発する通信など、怪しい通信が存在しないか確認する。ただし、情報が暗号化、あるいは偽装されており容易に発見できない場合もあり、モニタリングで何も引っかからなければ安全という訳ではないことに注意を要する。
問題1の回答に記載した原則を踏襲した上で、対応する。
・トリアージ：事実であれば、対応の必要あり
社内情報がアップローダに掲載されているのを確認した、という事象であり、報告者については不明である。まず、それは本当に社内情報か、公開の範囲はどの程度のものなのか、アップローダに存在してはならないものなのかを確認する。単純に報告者は関係者ではなく、当該情報を社内情報と思い込んでいるだけで、すでに公開情報として存在する可能性もある。まず、当該情報を扱う部署に事実関係を確認する。事実であれば情報漏洩としてCSIRTが対応する必要がある。
・アップロードされた内容の確保と確認
・当該情報を扱う部署と人員の確認
・情報の保存場所の確認（データベース、Webサーバー、社内PCなど、当該情報の存在する場所すべて）
・ネットワークログの確保
証拠の保全と、情報の流出経路の確認が最も重要となる。まず、当該データへのアクセス履歴や、アクセスが可能であった人物の洗い出しを行う。
・アップロードされた元データへのアクセス経路封鎖
内部犯行において繰り返しての犯行だった場合を疑い、さらなる被害を防ぐため、情報を信頼された管理者の下におき、アクセスログの取得を徹底する。特に、アクセスログは平時に取得していないような場合もあるため、再犯に備えてログ取得を徹底する。
・可能であればアップローダ管理者に削除依頼
このような依頼については慎重に行う。失敗し逆に衆目を集め、データを保存されたり拡散されたりすることにより、被害がさらに拡大する可能性がある。
・盗難・紛失により、情報が悪意あるユーザーに渡ってしまった
悪意を持った外部の人間が物理的に侵入し、情報を窃取しアップロードしたケース （産業スパイ等）や、紛失したUSBメモリの中に情報が入っており、悪意あるユーザーの手に渡ってしまった場合などが考えられる。
・P2Pソフト使用などによる流出（設定失敗、マルウェア感染）
誤ってP2Pファイル交換ソフトなどでファイルを共有してしまい漏洩するケースや、いわゆる暴露型ウィルス感染によって漏洩してしまうケース。
・別のファイルと間違えて内部の人間がアップロードした
悪意はない失敗でアップロードしてしまうケース。社内情報を扱うPCで不特定多数へのアップロードを行うこと自体に問題があるが、それに失敗が加わり大事故となった。
・Webサーバーなどにファイルが置いてあり、誤って公開にしてしまった。
近年、NASに機密情報を保存してWeb共有が知らずに有効化されていた場合、合格者名簿など、ある情報の公開時期の前に、パーミッションの設定ミスで情報を公開してしまった場合、など。
・悪意を持って内部の人間がアップロードした
内部犯行の可能性は常に存在する。関係各部署との連絡を密にする。
・外部からのクラッキングにより流出した（ネットワーク経由）
外部から情報の共有されている社内ネットワークなどにアクセスが行われ、情報が流出したケース。
・当該情報にアクセス可能であった人物の洗い出し
・ログがあれば、当該情報へのアクセス履歴の洗い出し
完全なアクセスログがあれば、その中に漏洩に関わった人間のアクセスが存在するはずである。ログの洗い出しが必要となる。
・可能であれば、流出への関与が疑わしいPCを一時的に使用禁止にして、forensicのため保全する
ネットワークのアクセスログなどから疑わしいPCを割り出し、malware感染などがないか確認する。
・情報流出範囲の確認（実は同様のファイルが他でも発見されていないか？）
すでに情報が多方面に流出していないか、どこまで情報が流出したかを確認する。
・情報の重要性の確認
漏れても特に影響の少ない情報か、自社の株価が急落しうるほどの危険な情報か、それは誰に影響するかなど、影響の範囲を確定させる。それによって関わった人間を絞り込むことが可能となることもある。
・ファイルのアクセス権の調査（実は本来アクセスできてはならないところからアクセスできるようになっていないか？誤ってWebで公開したりしていないか？）
実は自分たちが普通に公開してしまった可能性がある。
・アップロード経路の可能な範囲での洗い出し（社内IPからアップロードされていないか？など）
社内からアップロードされていることが分かった場合、少なくとも関与したPCは一気に絞り込める可能性がある。
・当該情報がパスワードなど、さらなる情報流出を招くものであれば、当該パスワードなどの速やかな変更、一時的なアクセスの遮断、公開されたと思われる時期から現在までのアクセスログの確認
リスト型攻撃のリストに使われるリスクが高い。同様のパスワードは可能な限り無効にする。
・関与したPCやサーバーの脆弱性の有無
脆弱性をついた攻撃の一環の可能性がある。
・アップロード原因となったPCが特定できた場合、そのPC内にmalwareが存在しないかの確認
悪意あるソフトウェアによるアップロードが発生した可能性を考慮する。
・社内からインターネットへのアクセス経路に関するログの収集 (社内プロキシ、FWなど)
再び悪意を持ってアップロードが行われたり、malware経由でデータが送られたりする可能性がある。その情報がログに残った場合、犯人や問題PCの特定に有利に働く。
問題1の回答に記載した原則を踏襲した上で、対応する。
・トリアージ：緊急対応の必要あり
自社社員が顧客情報入りのPCを紛失したという事例である。即時対応すれば、紛失したPCの発見の可能性が高まる一方、対応が遅れれば、顧客情報の漏洩と、それによるSPAM送信、標的型攻撃の発生、信用の喪失など、最悪の事態に繋がりかねない。緊急対応を行い、事態の悪化を防ぐ必要がある。
・紛失した人間の確認と、CSIRTとしては責任追及を行わない旨を伝えた上での協力要請
・紛失の場所、状況の確認
・PCの暗号化の有無の確認
・顧客情報の内容の確認
「いつ、どこで、誰が、何を、なぜ、どのように」紛失したのかの確認。
紛失後時間が経過すればするほど状況が悪化するため、このようなインシデントが起こった場合に即座に（可能であれば分単位で）情報がCSIRTに上がるような体制をあらかじめ作っておく。また、紛失した人物がそのノートパソコンの紛失直前の状況をよく知っている有力証人でもあることに留意する。当初より責任追及を行うと、情報を隠されてしまう可能性があり、危険が増大する。
・リモートで遠隔操作が可能であれば、当該PCが操作可能であるか確認した後、ロックやデータ消去などの必要な処置をとる
データが安全に消去できれば、悪意ある人間の手に情報が渡った場合でも、被害を最小限に食い止めることができる。また、追跡が可能であれば、当該PCの場所を検索することも可能かも知れない。
・関係部署への連絡（警察への紛失届の提出の是非や時期は規定があればそれに従う）
情報の共有範囲や規制、情報を共有した場合のリスクを検討した上で、必要な範囲内で行う。
・顧客情報を紛失可能性のあるPC内に保存していたこと
避けることが望ましい。
・情報の通り、紛失
意図しない紛失はいつでも起こりうる。
・盗難（偶然による、あるいは内部の情報を知る者による）
ノートパソコン自体高価であり、狙われる可能性は常にある。
さらに、ノートパソコンに欲しい情報が入っていると知っている人間がいた場合、そのノートパソコンごと盗んでしまおうと考えるのは、自然である。
・狂言
「情報売買の隠蔽」といった深刻なもの、あるいは個人的な恨みによる「困らせてやろうと思った」という関連など。紛失したことにすることで、何らかの利益が本人にある場合。
・内部犯行（内部の人間によりPCが持ち去られた、など）
上記の事態が、紛失した本人以外の内部の人間により行われる可能性も常にある。
・（可能であれば）PCをリモートで追跡、内容を消去
追跡が可能であれば、PCの奪還が可能かも知れない。また、場所が不明でも、データを消去することで被害を最小限に食い止められる。
・紛失の場所と状況の精査
本当に紛失したのなら、現場付近で再び出てくる可能性はある。
・流出情報の精査と影響範囲の確認、関連アカウントのロック
流出情報は、PC内の顧客情報にとどまらない。メール、Webアプリケーションなど、PCに記録された認証情報によりリモートでアクセス可能なシステムも存在しうる。そのようなシステムのアカウントロックを怠ると、さらなる情報流出を招く。
・流出情報の漏洩の有無の確認
PC内の顧客情報がWeb上などでリークされたりしていないか、可能な範囲で確認する。
・関係者への連絡とインシデントの告知、速やかな謝罪
確認がとれた場合、それを利用したスパム、フィッシングの二次災害に繋がる恐れがあるため、なるべく早く注意喚起と謝罪が必要。例えPCが発見されたとしても、一度紛失したことは事実であるため、速やかな謝罪と対応内容の説明が必要。
・責任の所在と情報を扱う上の社員教育
顧客情報を紛失可能性のあるPC内に保存するなど、今回の事例に至るまでに問題行動が存在する。状況を許容していた責任の所在や業務内容の精査、改善、社員教育が、再発を予防する上での急務となる。
問題1の回答に記載した原則を踏襲した上で、対応する。
・トリアージ：詳細を確認し、事実であれば緊急対応が必要
外部からの情報で、自社からの不正通信が発生しているという指摘である。事実とすればmalware感染の可能性などが考えられ深刻な事態であり得る一方、発信元偽装で自社からの通信と思われている可能性、そもそも不正通信でない可能性もある。詳細を確認し、不正通信であることが疑われる場合は、技術的解析を含めた緊急対応が必要となる。また、通報者が実は攻撃者であり、CSIRTが何らかのアクションを起こすことで、利益を得たり攻撃を進めたりしようとしている可能性もある（例：あるサーバーがダウンすると攻撃者が利益を得られる場合、攻撃者が「あるサーバーが不正通信を行っている」と通報することで、CSIRTが「緊急対応」してしまうのを狙ったケース、など）ため、調査・対応には慎重を要する。外部からの情報は、それがソーシャルエンジニアリングによる攻撃である可能性もあることを、常に留意する。
・本当に当該通信が行われているかの確認、および不正通信の内容
・不正通信を確認した経緯の確認（不正通信の被害者？たまたまキャプチャした？）
・ログの保全、モニタリングの開始
実際に当該通信が発生しているのか、それとも偽装により当該通信が自社から発生しているように「見える」だけなのか、確認が必要。さらに、不正通信が存在する場合、それは一台のPCのみからなのか、実はマルウェアによって社内のネットワークがほとんど掌握されてしまっているのか、同様に確認が必要。ログは即座に保全し、証拠を残す。モニタリングが不十分であれば、即座に開始し、証拠を集める。
・マルウェア感染
・外部からの踏み台が形成されている（C&Cサーバーとなっている、など）
DDoSの踏み台となっている場合や、攻撃の踏み台として利用されている場合を考慮する必要がある。
・検証用途などの意図的なアクセス
何らかの事情により社内より行った意図的なアクセスが、たまたま不正通信と誤解されてしまった可能性がある。
・ソフトウェアの意図しない暴走
テストでソフトウェアを作成している最中、誤ってゾンビプロセスが大量の不正リクエストを生成してしまったなど、意図しないところで暴走により不正通信が発生した可能性がある。
・内部犯行（社内からクラック行為を行う人間の存在など）
悪意を持った人間の存在は考慮に入れる必要がある。
・狂言
前述のように、ソーシャルエンジニアリングによる「CSIRTの誤った対応で攻撃者が利益を得ようとしている可能性」も考慮する必要がある。
・「不正通信」の事実確認、事実であれば発生源の確認
不正通信の発信元が本当に自社であるか、内容がどのようなものかについて調査、確認する。可能であれば、通報元からの協力を得て調査するとやりやすい。ただし、必ずそれ以外の情報源（自社技術チームなど）による確認が必要。
・当該PCの発見と速やかな不正通信の停止
不正通信が確認された場合、実際に通信しているPCやサーバーは、可能な限り速やかに停止する必要がある。該当PCの特定と通信の停止は最優先で行う。
・不正通信の解析と、通信を発生させているプログラムの発見
・不正通信の目的の解析（マルウェアの通信か、情報の不正取得か、DDoSの踏み台か？）
・他のPCへ及ぼした悪影響の確認
可能であれば対象PCに対するforensicは、攻撃の目的や、攻撃がいつから行われていたかを追求するために有効な手段である。
問題1の回答に記載した原則を踏襲した上で、対応する。
・トリアージ：技術的詳細の確認が必要、対応は慎重に
多数のリクエストが運用中のサービスに送信されていることを検知したという事象である。パスワードリスト攻撃と思われる一方、別の原因も考えられる状態であれば、誤ったbanにより、かえって被害を出してしまう可能性もあり得る。パスワードリスト攻撃と一口に言っても様々な種類があり、対策も異なるため、技術的詳細を緊急で確認した後、対応を慎重に検討する。
・ログの保全、必要に応じてモニタリングの開始
証拠保全は常に行う。証拠が不十分であれば、その時点からでも集める。
・リストが何らかの形で流出したこと
現在複数のリストがすでに流出により出回っている。また、内部情報の流出により、自社の人間のIDとpasswordなどが流出して、それが使われている攻撃の場合、リストの流出経路の特定も必要となる。
・指摘の通り、リスト攻撃
リスト攻撃により、サービスアカウントの１つを割り出そうとしているケース。
・リスト攻撃ではない可能性（当該サービスを大人数で利用している団体が、まとめて処理を行えるよう自動化スクリプトを制作している、と言った可能性）
悪意ではないが、たまたまリスト型攻撃のように見えるリクエストを送ってしまったケース。
・別の攻撃の隠蔽
リスト攻撃の大量のリクエストに紛れて、SQL injectionやバッファオーバーフローなどの別の攻撃を行うリクエストを混ぜ、それを成功させているケース。
・パスワードリスト攻撃なのか、別の原因か、リスト攻撃であれば、規模や手口はどのようなものかの技術的確認
リクエストの種類や発信元の確認を行った後、攻撃の種類を特定する。リスト攻撃と判明した場合、単純にリストに存在するIDとpasswordの組み合わせを順に試しているのか、ブルートフォース（IDを固定してpasswordをリストのものを次々変更している）なのか、リバースブルートフォース（パスワードを固定してIDを変更していく）なのか、など、攻撃のタイプにより対策を変えていく。また、リスト攻撃として明らかに異常なデータ（IDやpasswordが異常に長い、本来使わないようなnull文字などの特殊文字が混入している、など）が存在しないかも、併せて確認する。発信元が分かれば、事情を問い合わせる。
・攻撃の規模や時間の確認
発信元は分散して実行されているのか、単一のPCからの施行なのか。短時間に続けて行われているのか、長時間かけてゆっくり行われているのか、確認する。
・リストの流出時期や内容の想定
リストの内容が既知のものかどうか、分かる範囲で良いので確認する。既知のリストであった場合、リスト内に乗っているようなIDとpasswordの組み合わせを一時的でも無効化し、当該ユーザーに注意喚起とpassword変更を依頼する。
・当該IPのbanで対応できるようであれば、関係部署に連絡して依頼する
有効ではあるが、危険性も高い。送信元がプロキシやCDNなどSNATされたIPでない場合に限られる。プロキシを遮断した結果、重要なアクセス元まで遮断してしまい、サービスに深刻な影響を出してしまう事態は避けなくてはならない。
・（可能であれば）関係部署に連絡して早期にリスト攻撃に対する対策を行う（認証にかかる時間を延ばす、あるいは一定数のログイン失敗でban、など）
以上となります。
誤字だけ一部直してMarkdown形式とした他は、SECCONに提出したものと同一です。
資料作成にあたり参考にしたサイトの一部（現時点で覚えているもの）：
日本コンピュータセキュリティインシデント対応チーム協議会( http://www.nca.gr.jp/ ) より
CSIRTスタータキット ( http://www.nca.gr.jp/imgs/CSIRTstarterkit.pdf )
CSIRT構築のために必要な知識がまとまっている。
JPCERT ( https://www.jpcert.or.jp/ )より
CSIRTマテリアル ( https://www.jpcert.or.jp/csirt_material/index.html )
実際にCSIRTを構築・運用する際に必要となる資料がまとまっている。「コンピュータセキュリティインシデント対応チーム（CSIRT）のためのハンドブック」「インシデントハンドリングマニュアル」など、参考になる資料が多かった。
内容が課題執筆当時より新しくなっていた。
ENISA ( https://www.enisa.europa.eu/ )
Trainings for Cyber Security Specialists ( https://www.enisa.europa.eu/topics/trainings-for-cybersecurity-specialists )
欧州ネットワーク・情報セキュリティ機関が発行しているCERT演習の資料。充実している。
Initial Security Incident Questionnaire for Responders（ https://zeltser.com/security-incident-questionnaire-cheat-sheet/ )
インシデント発生時、まず何を考えるべきかを箇条書きにしてあるメモ。
ともあれ、この事前課題で何とか予選を通過。本戦に参加することとなったのです。
機会と気力があれば、大会のお話も、またいつか……。
CTFは、ITセキュリティの技術を楽しみながら学べるという側面があり、その意味で、SECCON 2015 大阪大会 CSIRT演習は（CTFとしては本流から逸れたきらいはありますが）良いCTF関連イベントだったと思います。来年は、また社会人参加もできるようなイベントもあるといいなあと思いつつ（参加できるかは未知数ですが……）CTF Advent Calendar 2016 7日目(12/7)の記事を終わりにしたいと思います。
明日はしゃろ（@Charo_IT）さんのOmegaGo(HITCON 2016 Quals pwn350) writeupです。