WHY DON'T YOU DO YOUR BEST!!
諸事情により先日、MISP をインストールして画面を触ってみたのですが、ぱっと見、どこにIoCが格納されているのかわかりづらかったので、ここに記載しておきます。
MISPのトップページ（Home）にてEventリストが表示されていると思いますので、その項目の中からIoCを確認したいEventの「ID」をクリックします。
このEventが個々の脅威と考えてようさそうです。
Eventの「ID」をクリックするとそのEventの詳細情報が表示されますので、画面を下にスクロールさせます。
すると、マルウェアのハッシュや Virus Totalのレポートへのリンクと思われる情報を見つけることができます。
ある理由から AbuseIPDB にIPアドレスを投げてその評価結果を受け取るPythonプログラムを作成しようと思いググったところ、以下のYoutube動画を見つけました。
そこで真似して作成してみることにしました。
なお、上記動画で紹介しているPythonプログラムは以下のGitHubで公開されています。
https://github.com/Mostafayahia-hunter/AbuseIPDB-API-Python
だだし、最近、AbuseIPDBからのレスポンスが変わったのか、一部の箇所でエラーがでたので、csv_columnsの定義の部分を以下の通り書き換えました。（’isTor’を追加しました。）
csv_columns = ['ipAddress','isPublic','ipVersion','isWhitelisted','abuseConfidenceScore','countryCode','usageType','isp','domain','hostnames','isTor','totalReports','numDistinctUsers','lastReportedAt']
また、Pythonプログラム実行時に要求される IPリストとして入力するcsvファイルとしては、以下のような内容を用意しました。
IP, 88.29.56.3, 1.158.10.11, 161.35.146.242, 177.84.141.183
そしてコマンドプロンプト上で実行した結果がこちらです。
実行するとAbuseIP_results.csvというファイルが出来上がっており、それを開いてみた結果は以下の通りです。
プログラムをいろいろいじってみて CSVライブラリの使い方あたりがとても勉強になりました。
Power Automateから２段階認証を行なっているGmailのメールサーバ経由でメールを送信する場合、Gmail で使っている通常のパスワードではなく、Googleからアプリパスワードを取得する必要があります。
ここでは、そのアプリパスワードの取得方法を記載しています。
Googleのサイト（https://www.google.com/）にアクセスすると、右上に自分のアイコンがありますので、それをクリックします。
クリックすると「Googleアカウントを管理する」というボタンが表示されるので、それをさらにクリックします。
すると、「Google アカウント」という画面が表示されますので、その画面の左メニューから「Security」をクリックします。
セキュリティ画面に移ると、２段階認証の設定項目がありますので、それをクリックします。
２段階認証の画面に移ったら、ページを一番下までスクロールさせると「アプリ パスワード」の設定項目がありますので、それを再度クリックします。
アプリ パスワードの画面の下側でパスワードを利用する「アプリ」と「デバイス」を選択し、「生成」ボタンを押します。
するとアプリ パスワードが生成されますので、これをGmailにアクセスさせるアプリに設定します。
色々な企業でVPNの脆弱性から社内ネットワークに侵入されている事例を見るにつれ、自分の家のルータは大丈夫かと心配しておりました。
そんな中、横浜国立大学さんの方からルータのセキュリティをチェックしてくれるサービスがあると聞き、さっそく試してみました。
DDoSを引き起こしてしまうようなマルウェアに感染していないかチェックするには、以下のサイトから３つの項目を入力して「感染診断をはじめる」のボタンを押すだけです。
am I infected? https://amii.ynu.codes/
【入力項目】
・自分のメールアドレス（ここに検査結果がメールされる）
・現在の環境をプルダウンメニューから選択（自宅のルータかどうかなど）
・このサイトを知ったきっかけをプルダウンメニューから選択する
感染チェックが完了すると、先ほど入力した自分のメールアドレスに届きます。
たしかWebには５分くらいかかりますと書いてあったと思いますが、実際には２〜３分くらいでメールが届きました。
２．で届いたメールに書かれているリンクをクリックすると診断結果を確認できます。
我が家のルータは幸いにも安全な状態でした。ファームアップの連絡が届いたらすぐに適用しているので、それが幸いしているかもしれませんね。
みなさんも１度といわず、定期的にチェックしてみるといいと思いますよ。
前回、ATT&CK活用の１回目を書いてみました。
そして前回の続きで、今回は第４位（出現数：８８）に入っている以下のテクニックについて調べてみた。
T1105 Ingress Tool Transfer （侵入ツールの送り込み）
すると、ATT&CKのDETECTIONには以下の記載がある。
この中から「DS0029 Network Traffic」のそれぞれについて検索してみると、以下の通り書かれている。
Network Connection Creation
Monitor for newly constructed network connections that are sent or received by untrusted hosts or creating files on-system may be suspicious. Use of utilities, such as FTP, that does not normally occur may also be suspicious.
Network Traffic Content
Monitor network traffic content for files and other potentially malicious content, especially data coming in from abnormal/unknown domain and IPs.
Network Traffic Flow
Monitor network data for uncommon data flows (e.g., a client sending significantly more data than it receives from a server). Processes utilizing the network that do not normally have network communication or have never been seen before are suspicious.
これらの検知について、SIEMに検知ルールが実装されているか調べてみた。
検索条件としては「ATT&CK Technique：T1105」と「Data Sources：Network Communication」としてみた。
すると以下のとおり２つヒットした。
Spike in SMB Traffic
こちらはルールも見えますね。
サンプルデータも入ってました。
Suspicious Network Connectionの方。
こっちはUBA機能がないとだめっぽい。
ATT&CKを使って、特定のグループのテクニックを調べ、それを検知できるようにすることも考えられる。
しかしながら、その企業がどの攻撃グループに狙われるか、事前に想定するには難しいし、常に同じグループから狙われるとも限らない。
そこで、ATT&CKの中から、特に多く使われているテクニックから焦点をあてて監視実装をしていくのが適切と考える。
たとえば、最近のテクニックのトレンドはNECさんが定期的に以下のようにまとめていたりする。
NECセキュリティブログ MITRE ATT&CK 頻出手口 トップ10 Vol.3（2022年5月版） https://jpn.nec.com/cybersecurity/blog/220527/index.html
これをまず、ATT&CKにマッピングしてみる。
これをみると一番多く利用されているテクニックは以下になっており、出現数は152回のようだ。
T1059 Command and Scripting Interpreter （コマンドとスクリプトインタプリタ）
これをATT&CKで調べてみよう。
すると以下のように大きく４つの検知方法が示されている。
この中からさらに「Command Execution」を見てみる。
すると「T1548 Abuse Elevation Control Mechanism」や「T1087 Account Discovery」など、攻撃のフェーズは異なるが、いろいろなコマンド実行があることがわかる。
さらに、「T1548 Abuse Elevation Control Mechanism」の中から「T1548.002 Bypass User Account Control」を見てみよう。
すると、ページの中にところどころ、「eventvwr.exe」や「sdclt.exe」などのコマンドがかかれている。
このコマンドを調べてみると、以下のサイトなどで調べてみると、どうやらこれらのコマンドには、権限昇格時にユーザーに確認することなく権限昇格を行うことが可能な設定がなされているようです。
UAC回避機能を複数搭載したランサムウェア「HkCrypt」 https://www.mbsd.jp/blog/20171012.html
この検知を実装しているSIEMがあったので参考に載せておく。
前回、特定の攻撃集団の攻撃テクニックを確認する基本的なATT&CK Navigatorの使い方を確認してみました。
そこで今回は複数の攻撃集団の攻撃テクニックを重ねて表示する（色塗りする）方法を記載しておきます。
なお、この方法は、先に色塗りした攻撃グループの攻撃テクニックが、後で色塗りした攻撃グループのテクニックで塗り潰されてしまうので、注意してください。
まず１つ目の攻撃集団 BlackTech のテクニックを検索します。
検索窓から攻撃集団の名前を入れると「Threat Group」に検索にヒットした集団の名前が表示されるので、その中の「select」ボタンを押します。
その後で、下図のように好きな色をカラーパレットから選べば、その色で攻撃集団のテクニックが色塗りされます。（下図の場合は赤色）
色塗りをした後は「deselect」で選択を解除しておきます。
１．と同じ要領でLazarus Groupの攻撃テクニックを色塗りします。
Kimsukyについても同様に行います。
このように攻撃集団のテクニック毎に色を分けて塗りつぶすことができました。
ただし、今回の方法では、先に述べたように先に色塗りした攻撃集団のテクニックが後に色塗りした攻撃集団のテクニックで上書きされてしまいます。
もっとよい方法が無いか、もう少し調べてみたいと思います。
諸事情によりMITER ATT&CKを利用して、特定の攻撃集団が得意な攻撃テクニックを抽出する方法が知りたくなったので、実際にATT&CK Navigatorを使って操作してみました。
下記のMITERのサイトにアクセスします。
https://attack.mitre.org/matrices/enterprise/
すると、以下のようなサイトが表示されるので、右上にある「View on the ATT&CK® Navigator」のリンクをクリックします。
以下の画面が表示されたら、「Create New Layer」から企業向けと思われる「Enterprise」を選択してみます。
すると、ATT&CK Navigatorが表示されます。
ATT&CK Navigatorが表示されたら、上のツールバーの虫めがねマークをクリックし、検索窓から攻撃グループを指定します。
ここでは、台湾や日本を狙った中国の攻撃集団と言われている「BlackTech」を指定しています。
すると、「Threat Groups」の中に「BlackTech」が表示されるので、そこにマウスのカーソルを当てると、その攻撃集団が利用すると思われるテクニックはハイライトされます。
さらに、漏斗のアイコンをクリックすると、OSの種類やオンプレ/クラウドなどの環境を絞ったテクニックのみ表示させることも可能です。
なお、最近トレンドマイクロが発表していた「主な標的型攻撃集団」を確認してみたところ、以下のようになっていました。
| 攻撃集団 | ATT&CK Navigatorでの検索可否 |
| BlackTech（ブラックテック）中国が拠点 | ○ |
| Earth Tengshe（アーステンシェ）（≒APT10？なら中国が支援していると言われている） | ×（APT10（menuPass）なら○） |
| LODEINFO（ロードインフォ）（≒APT10？なら中国が支援していると言われている） | ×（APT10（menuPass）なら○） |
| Lazarus Group（ラザルス）北朝鮮が拠点 | ○ |
| Kimsuky（キムスキー）北朝鮮が拠点 | ○ |
私の調べ方が悪い可能性や別の名前で登録されている可能性がありますが、すべての攻撃集団が登録されているわけではなさそうです。
新しい攻撃集団が出た場合は、その全容を調べるのに少し時間がかかるのかもしれませんね。
＜参考サイト＞
・日本を狙う標的型攻撃に立ち向かうために、知っておくべき5つのこと（トレンドマイクロ）
https://www.trendmicro.com/ja_jp/jp-security/22/e/securitytrend-20220510.html#3
・MITRE ATT&CK徹底活用（＠IT）
https://atmarkit.itmedia.co.jp/ait/articles/2209/08/news004.html
先月６月１６日に、徳島県つるぎ町立半田病院のコンピュータウィルス感染について調査報告書がまとめられております。
それをあるきっかけで読んでみたところ、大変学ぶところが多かった為、特に印象に残った部分を記録しておきます。
報告書を読んでみて、まず病院側のランサム 事案発生後の対応が素早いと感じました。
これは報告書の中にも書かれているとおり、ランサム を想定したものではありませんが、大規模災害発生時に備えて、BCP をちゃんと作成されていたためだと思います。
一方で、病院のシステムを構築したベンダー側（A社、C社）は、システム構築時にいろいろと不手際があったことはいなめないかなという印象です。
特に構築時の対応としてまずいかなとおもったのは以下の３点です。
１．VPN装置（FortiGate E60）がインターネットのどこからでもアクセスできるようになっていた。
２．Active Directoryにてログオンにいくら失敗してもロックアウトされないようになっていた。
３．各サーバ/PCにてWindows Updateが止められており、またウィルス対策ソフトが導入されていなかった。
ただ、運用時においてFortiGate E60の脆弱性をそのまま放置し続けていた点については、システム管理者が1人しかいなかったとはいえ、病院側の対応もまずかったのではないかと思います。
FortiGateの脆弱性は何度もニュースで流れていましたからね。
１．VPN装置（FortiGate）を慌ててアップデートしてログを消失
慌てていたとは言え、この点はかなりまずかったですね。
この作業をしていた時点で侵入経路がわかっていなかったとはいえ、あわててファームウェアをアップデートしたということは、ここからの侵入の可能性があったわけです。
そうであれば、まずはログの確保が優先だったのではないでしょうか？
ファームウェアのアップデートでログが消えるということを知らなかったのかもしれませんが。
まず、抜線隔離し、ログ確保ということですね。
２．端末調査のためにサーバやPCを自社に送付させ、その輸送中に機器が壊れる
ここは送ってほしい気持ちはわかります。調査の設備的に、会社に送付してもらったほうが十分は調査ができるので。また現地のプレッシャーの中で調査するのは躊躇われるのも理解はできます。
ではどうすればよかったか。正直、精密機器専門の業者に輸送をお願いするくらいしか、私には思いつきませんでした。
３．ファストフォレンジックだがなかなか解析が終わらない、復旧したはずのサーバが復旧しきれていない
うーん、ここの技術的にはかなり難しいとおもうので一概に責められない気はしています。
ただ復旧したかどうかの確認は、もう少し手厚くやるべきだったのかもしれません。ネットワークにもどしてまた再発すると最悪なので。
４．ベンダーが何らかの方法で暗号化されたファイルを復号。本事案について攻撃者からの脅迫はなし・・・ここの関係は？
ここはベンダー側の説明があまりなかったということなので、今のところ判然としていないようですが、このレポートだけみると、なんらかの裏取引があったようにも見えてしまいます。
本編のレポート意外に技術編のレポートもありますが、このレポートも学びがたくさんありました。たとえば、以下の点です。
・ランサム の暗号化には楕円暗号も使われている
・ランサム の暗号化速度は１G〜１０G/１分くらい
・暗号化を高速にするために先頭だけ暗号化していることが多い
・パスワードは１６文字以上で利用する文字の指定をしないのがおすすめ
・RDPはログインログがデフォルトで残るが、それはやめたほうがいい
・RDPサーバは多要素認証できないので、その手前に多要素認証できる機器を置く
などなど。
正直、１度ざっと読んだだけでは気がつかないこともありそうなので、もう１回は読んでみたいと思っています。
2022.07.17 追記
もう一度技術編で気になっていた、封じ込め、復旧のところを読んでみました。
＜封じ込め＞
ここでは侵入者の締め出し観点で以下の対応を行うということだと思います。
１．VPN装置のLAN抜線（PCじゃないのでシャットダウンしてもよい？）やインターネット接続のホワイトリスト化（できれば全遮断。。。できるか？）
２．侵害された可能性のあるパスワードの変更
３．ADで不審なアカウント操作の確認などを行い、あやしいアカウントは削除
４．ログの分析と一元管理
＜復旧＞
１〜３あたりは普通やりそうですが、４、５まで出来たら完璧ですねー。
１．フォレンジックの実施
２．ウィルススキャン（封じ込め段階で実施するとまずいらしい。。メモリ上の痕跡や消えたり、ログが大量になってしまうから？）それでもだめなら初期化
３．データの復元
４．漏洩した可能性のあるデータの監視（ここは専門のベンダーに任せるしかないのかな。）
５．対応手順の更新（ここまでできるとすばらしいですねー。）
・コンピュータウイルス感染事案有識者会議調査報告書について（つるぎ町立半田病院）
https://www.handa-hospital.jp/topics/2022/0616/
最近、セキュリティ人材の不足やアラートの増加などの理由から、SOAR（Security Orchestration Automation Response）というカテゴリの製品が、少しずついろいろな会社に導入し始めているのではないかと思います。
しかし、いざSOARを使ってインシデント対応を自動化しようとしたときに、どこから手をつけはじめたらよいのかわからないといったお悩みを持つ方が、たくさんいらしゃるのではないでしょうか。
そんな中、今回いろいろなセキュリティや自動化に関するサイトも参考にしながら、既存のインシデント対応手順をどう自動化していけばいいか考察してみました。
以下、私の方で考えた自動化検討の手順になります。
１．インシデント対応を手順書化
２．インシデント対応をフローチャート化
３．定型的な判断・処理がないか洗い出し
４．SOARで連携可能なシステムを確認
５．自動化の優先度を検討
普段、実施しているインシデント対応手順を手順書に落としてみます。
そのときに対応の流れを記載するだけではなく、人が判断している部分や処理している部分をより具体的に書くとよいでしょう。
具体的に書けるということは、定型化できる可能性があるということになります。
手順書ができたら、次にそれをベースにフローチャートを書いてみましょう。
このときに、通常であれば、ある役割の人からある役割の人へと、人（もしくは部署）をベースとしてフローをつなげていくと思います。
しかし、自動化する場合には、人だけではなくシステム（メール、SIEM、インシデント管理、セキュリティ機器など）も含めてフローチャート化してあげるとよいでしょう。
こうすることにより、あるシステムから別のシステムに対して人が介在していることが明らかになり、そこが自動化検討のポイントになってきます。
ただし注意が必要なのは、人から人への流れであったとしても自動化できることがあるかもしれない、ということです。
例えば、SOAR製品によってはメールを人に送信し、そのメール内のリンクをクリックさせることでSOARが提供しているWebインターフェイスにアクセスさせ、その人から何らかのレスポンスを返信させる、といったことが可能な場合があるからです。
ここまでは今、実際にやっていることが対象となっていますが、追加で考えておくとよいことがあります。
今はいろいろな事情でてきていないけれども、可能であれば今後、やってみたいと思っていることです。
自動化によりインシデント対応のスピードアップが計れるようになります。しかし、そこで考えを止めておくのは少しもったいないかと思います。
スピードアップにより空いた時間を使い、これまでできなかったことを行える余裕が出てくる可能性がありますので、それらも自動化の検討対象に入れておくとベストだと思います。
以上により自動化検討のポイントが明らかになったら、次はそのポイントにおいて普段、定型的な判断や処理をおこなっていないか確認します。
つまりパターン化されていないかということです。もしパターンかされているのであれば自動化のロジックを作成できる可能性があります。
たとえば、あるシステムから取り込んだデータにおいて、その中のある項目の値によって決まった処理をおこなっていたり、追加調査などを行っていないか、などです。
こうして検討を進めていけば、以下のような処理以外はすべて自動化できる可能性が見出せるでしょう。
・どうしても人の経験値に頼って判断せざるを得ない部分
・関係者の総意が必要となる重要な意思決定
・ネットワークでは対処できない物理的な作業（被疑PCの利用者からの回収など）
もしすでに導入済のSOARがあるのであれば、それがフローチャートに書き出した各システムと連携できるかどうかを確認します。
もしSOARがそのシステムと連携できるのであれば、その部分は自動化候補となります。
また、直接連携可能となっていないシステムであっても、自動化できる可能性はあると思います。別途そのシステムと連携可能なプログラムを個別に作成し、それとSOARを連携させればよいのです。
しかしこのとき注意が必要なのは、個別開発したプログラムとSOARとの間でトラブルが発生しても、SOAR提供ベンダーによってサポートされない可能性があるということです。
この場合、自己責任で対応しなければなりません。それを避けたいのであれば、SOARがサポートしていないシステムとの連携は避けたほうがよいでしょう。
もしSOARをまだ導入していないのであれば、フローチャートに記載した連携対象の各システムを数多くサポートしている、もしくはどうしても優先的に連携させたいシステムをサポートしているSOARを、購入の検討対象にあげるとよいと思います。
なお、今後自動化の対象範囲を広範囲に広げる場合には、それにより新たに連携が必要となるシステムとも連携が可能か、検討に含めておくとよいでしょう。
自動化できる部分をピックアップし、それが複数ある場合には、どこから先に手をつけるかを検討する必要があります。
この自動化の優先度決めについては、自動化により何を目指しているかによるでしょう。
自動化のメリットとしては、以下のものが考えられます。
・スピードアップ
・人手不足の解消
・対応品質の均一化
これらをキーワードに自動化可能なポイントに優先順位をつけて検討していくとよいでしょう。
以降、2022.5.4 追記
例えばスピードアップを目指す場合、現在、その対応にどれくらいの時間がかかっているか、整理してみるとよいでしょう。
時間がかかっている処理を自動化するほうが、ROI（Return On Investment）は高いですよね。
人手不足の解消ということであれば、頻繁に発生している処理を自動化するほうがROIは高いですね。
これは自動化というよりその一歩手前のインシデント対応の手順書化によるメリットなのではないかと思います。
したがって、自動化という意味であれば、優先順位は低いかもしれませんね。
・セキュリティ運用④－「セキュリティ運用自動化」を実現するSOAR 導入の3つのステップ（MACNICA）
https://www.macnica.co.jp/business/security/manufacturers/fireeye/feature_07.html?utm_source=pocket_mylist
・インシデント対応の切り札「SOAR」とは何か？自動化とセキュリティ人材育成の強い武器に（NEC）
https://www.nec-solutioninnovators.co.jp/ss/insider/column17.html?utm_source=pocket_mylist
・「情報セキュリティ事故対応ガイドブック」の公開（情報セキュリティ大学院大学）
http://lab.iisec.ac.jp/~hiromatsu_lab/sub07.html
・「SOAR」は魔法の自動化ツールなのか！？ ～失敗しないセキュリティ運用自動化への道～（MACNICA）
https://mnb.macnica.co.jp/2021/03/soar.html?utm_source=pocket_mylist