自動化は本当に求められているのか
対話型AIというジャンルの製品を扱う会社にいるため、自動化やチャットボットのトピックにふれることが多くなった。
チャットボットという言葉そのものはよく聞くし、実際にウェブサイトなどで見たりサポートページの右下に待ち構えていたりする。それが自分にとってWelcomeかと言われると、うざったく感じる気持ちのほうが強い（意見には個人差があります）。
普及しているチャットボットを使う中で出てくる課題でよく指摘されるのが、こちらの問い合わせ意図をうまく捉えてくれない、というもの。例えば、旅行会社が提供するチャットボットがあったとして、問い合わせされるものには
- 空港での登場手続きを教えて
- 機内持ち込み可能か知りたい
などがあるだろう。こういった一問一答形式のやり取りには、予めチャットボットが用意しているFAQで対応が可能だろう。しかし例えば、
- 来週の私の東京から旭川までの航空券を確認したい
- それから、大阪行きの分も
と続いたとしよう。すると＃２がかなり難しい。一つの問い合わせに対して回答して終わる仕組みをつかっている場合、文脈を引き継ぐことができない。そうすると、＃２だけを見て判断するが、＃１がないと何を聞きたいのかはっきりしないのだ。
このような文脈を理解して応対できる機構、これが対話型AIを搭載したチャットボット（あるいはバーチャルアシスタントなどとも）の特徴の一つとして言われることがある。なおここで文脈の理解、文章からの意図理解、そして重要情報のピックアップなど、自然言語処理（NLP）や自然言語理解（NLU）と呼ばれる技術が支えている。
このような高機能を世の中は求めているのか？答えはYesと思われる。一つ記事を参考に意訳して進める。
記事元はCIO.comのスポンサー記事から。
同記事によると、このような自然言語処理を活用したサービスは、多くの金融機関で利用されている。
IDC調査によるとグローバルのAI投資は$204B（2025年までに）に到達するとあり、金融産業はその投資において2番目に大きな産業分野であるとのこと。
その中で期待されるチャットボットの活用については、期待とのギャップが指摘されている。フォレスターのレポートでは、その提供者の95％が、お客さまの問い合わせ内容やこれまでの応対について記憶しておいてほしいと指摘している。そしておよそ50％程度のチャットボットしかこのような機構を備えていないとも。
NLPを搭載しているチャットボットであっても、文章中の意図理解や、感情などの把握、複数の意味を持つ言葉による意図の誤認などが課題である。
高度に最適化された対話型AIは、およそチューリングテスト（ある問いかけをしたときの回答が、人間のものかロボットのものか判別できないくらいであれば、テスト合格）を突破できるくらいのものと期待されている。このジャンルを標榜するベンダーは、上述した文脈理解を要する問い合わせに応対できることが期待される。
チャットボット（従来型のとでも表現しよう）から対話型AIへと目線が移るなかで、これまでの課題や手間を解決されることの期待が高まり、加えてAIを用いることが一般的には、お客さまとの結びつき（エンゲージメント）がより高まる傾向が指摘されており、この結びつきがさらなる製品・サービス購入、つまりロイヤリティの高いお客さまを創出・維持できるのではとの期待につながっている。このようなことから、Juniper Researchによると、2023年には、金融業界のチャットボット利用における削減コストは$7.3B、保険業においては$1.3Bにまで到達するだろうと予測している。
問い合わせを受ける製品・サービス提供者側の時間削減にも効果が期待できる。つまり反復性の高いタスクを請け負うことによる社員の時間削減や他の活動への振り向け、それによる労働意欲の向上などである。
お客さまやユーザーの問い合わせデータを集積できることも効果として謳われる。これらを分析することによる洞察と、そこから次の戦略につなげるというものだ。
一方、対話型AIにおける課題としてよく指摘される事柄には顧客データ、PIIなどの保護がある。コンプライアンスやレギュレーションによってはSaaSベースでなくオンプレでの自社管理が必要になることがある。その他の課題として、NLP技術を活用するために十分な学習やテストが必要になるという点だ。ほとんど違和感がないくらいに、お客さまとの応対を実施できて初めて、これらの学習やテストが報われることとなる。
意訳終わり。
対話型AIによるお客さま対応の自動化が期待されていることに間違いはなさそうだ。自動化できる部分は反復性が高いものと途中であったが、これを実現するための開発コストやサービス利用などのコストが、人員の置き換えなどと比較してROIが出るのかどうか、これが普及促進のポイントとなりそうだ。この点についても継続調査する。
お金をもらったら引っ越しするか？
雇用の盛り上がりがスローになり、技術セクターは先月から１０％ほど縮小傾向となっている。Microsoftが採用を縮小している。ストリーミング系ではNetflixが苦しく、４−６月では100万人の退会者が出た（当初２００万人の退会があるかと予想されていたが）、TwitterはElon Muskの件で大盛りあがりだけども雇用凍結、崩壊のシナリオと言い始めている記事もある。
そして、高すぎるシリコンバレーから移住してもらおう、ということで助成金とか手当を出すことで従業員が別の州や街に引っ越しを促すような取り組みが、今あらためて盛んになっている。
こういう企業が、市町村と連携して移住の手助けをしている。
Do what you love, in a place that you love. - MakeMyMove
日本でも、東京圏内から移住することで申請できる移住支援金、地域の課題解決を目的に起業することで申請できる起業支援金などがある。
さて個人の話。お金をもらってまで引っ越ししたいか、については色々考える。家族３人、子どもはこれから色々と経験していく時期に、あえて場所を変えることにメリットがあるかどうか。
この記事を読んでの投稿：
Microsoft TeamsのBotを作るときに知っておきたかったこと
Power Virtual Agent、Bot Framework SDK、QnA Maker、Bot Framework Composerなど、ボットを作ろうと思って調べていくとツールと思われるものがたくさん出てきました。どれが何で、どうやってBotが作られるのか、そしてTeamsへの追加はどうするのか、TeamsのチームでメンションさせたときにBotを起動するのはどうするのか、など見極めが大変でしたので、メモしておきます。（1/7/2022現在）
どのツールを使えばよいのか
ずばりこちらに答えがあります！
ざっくり言ってみると：
- Power Virtual Agentは、ローコードで直感的にデザインできるので、サクッと作ろうと思ったときや手始めに良さそうです。作ったボットを公開するときはPower Appsポータルからと記載があります。Power Automate（Microsoft製品との親和性が高く、また他ツールの連携も簡単に記載できる、処理のフローを作成するツール）も同じツール内機能のような感覚で使えます。
- QnA Makerは、Azure Botサービスがベースとなっています。ドキュメントファイルなどから質問を読み取って、まさにQ&Aのボットを作るときに適したもののようです（あまり試せていない）。
- Bot Framework Composerも、Azure Botサービスがベースです。Bot Framework SDKでガリガリとコードを書きながら開発するのではなく、それに近いけどもローコードのインターフェースを持っていて開発しやすいIDEのような位置づけと思います。
上の記事には、どのツールを選ぶべきか、のヒントも記載されています。
参考URL：
１．Azure Botサービスと、QnA Maker、Teams連携を実現するちょまどさん（@chomado）の記事。スクショが完璧でわかりやすいです。前編でAzure Bot作成周り、後編でボット作成とTeams連携が触れられています。
＃私は後編の3-1: Visual Studio に Botframework テンプレートのところでテンプレートがどうしても出てこず断念しています。。。
２．Teams上で、Power Virtual Agentを作ってみよう、なチュートリアル（公式）
メンション！（アットマークでボットに声を掛けたい！）
先にあげた参考記事を実施すると、Teamsにボットとして左側などにアイコンとともに登場して、そのボットを選択し、ボットー自分で個別にやり取りをする、なーんてことは可能になりました。
ここでやりたかったのは、チーム（Teams上で複数人が入っているチャットの集まり。「チーム名」ー「一般」がデフォルトで存在する）でのチャットのときに、＠でそのボットを呼び出したい。
＃それをどうするかがしばらくわからなかった。すでにボットそのものは入っているように見えるので、これをそのまま呼び出せるんじゃないか、とかトライした結果、これをやるには、カスタムアプリとして他の人も使えるように追加する必要がありました。ボットはインストール済のように見えるのに、更に追加するっていうところが飲み込めなかったのですが、多分自分には見えているけど、他の人向けに展開する、という位置づけなのかと思います。
というわけで、＠でボットをメンションするには、カスタムアプリとして配布をします。先に上げた１の参考記事では、後編の項目５でそれに触れられています。こちらではマニフェストを手で作成する形で紹介されていました。
TeamsではApp Studioアプリを使って、この作業を画面上でできます。ここに触れているのが以下記事です。
３．Teams でメンションすると Planner タスクを作成してくれる bot を Power Virtual Agents で作る37jotter.wordpress.com
この記事を基に補足をすると、
（１）Set up a botの項目で、ScopeにPersonalだけでなくTeam、Group Chatを選択しておくと、意図したことが実行できます。
（２）記事の通りですが、App Studioから直接Installもできそうなのですが、権限関係でエラーに私もなりましたので、一旦Downloadします。ここでzipファイルができますので、これをTeamsから「カスタムアプリをアップロード」で指定します。Teams画面左下の「アプリ」をクリックして表示される画面から、「カスタムアプリをアップロード」をクリックすると実施できます。
（３）この方法で追加したアプリは、「開く」ボタンの横に▼が出て「チームに追加」が選べるようになります。
こうすると、チームのチャット内で、このボットをメンションで呼び出せます！！
私はここまでくるのに２週間くらい掛かってしまいましたが、見えて北ので次に進めそうです。どなたかの参考になると嬉しいです。
RSA Conference 2021 Virtual はじまってます！
無料のDigital Passでも、Cryptographer’s Panelが見れるこの喜び！！
早速NFTについて会話が始まりました。
RSAのA、Adi ShamirはNFTについて好意的な印象を持っている。
一方RSAのR、Ron RivestはNFT、私は買わないねっ、懐疑的だからと。性格が出てますねー。
RSAの暗号システムを破壊できる、と豪語した、3月に出た論文について会話しています。まだこの論文を評価することができていないようですが、ざわついている状況が落ち着くまでもう少し掛かりそうです。この論文で触れているキー長は今使われているものよりも短いようですが・・・。
話題は、このような公開（Disclosure）について、責任を持った公開、倫理的な公開なのかどうか、についての議論も交わされています。RSAについては一社だけでなく世界中のサーバーで使われている中で、本件を隠しておくのか、公にして解決を強いていくのか。このような公開の問題については、20年前くらいから、形は変えつつも変わらない議論である。
-----
さて、今回のセッションの目玉の一つは、SolarWinds CEOのセッションでしょう。彼は今年１月にCEOになることに決まっていた中で、それに向けて準備をしていた12月、FireEyeからのSolarWinds悪用による攻撃についてレポートを受けていました。当初はバックドアとは知っていたがサプライチェーンとは思っていなかったようです。SolarWindsはこの一連の中でリーダーシップを発揮していて、ちゃんと自社ブログなどで何が起こったかなどを明らかにしています。なかなかできないことで、素晴らしいと思います。彼はこの前はPulse SecureのCEOでもあったので、その時の製品の脆弱性に対する対応（パートナー、顧客）を「幸運にも」経験として活用できたと話しています。
M-Trends 2021が出ました 2/N
FireEyeからリリースされたM-Trends 2021。もうそろそろ本家から日本語版が出るかもしれませんが。
これまでのものはこちら。
パンデミックに関連した脅威
サイバー諜報活動の話です。コロナ対策における国家機関によるそれらの活動をMandiantとして確認しているものがあり、それをレポートでは伝えている。
ベトナム、中国、北朝鮮、イラン、ロシアのグループによる諜報活動を追っている。例えば中国関連のAPT41活動で、これは製薬会社のルーターやVPN脆弱性を狙ったもので、2020年1月ころより確認されている。同時期に、ベトナムのAPT32では中国の行政機関、プライベート機関を標的にしており、COVID19の拡散についてモニタリングする目的であったように推察される。
韓国、中国、と続き、そしてイランのUNC788については米国の製薬会社を標的にしていた。米国政府からはアドバイザリなども発行されている。ロシアのAPT28もワクチン調査機関を標的にしていた。北朝鮮関連の活動も同様に観測されている。
これらが指し示すこと
Mandiantの考えでは、COVID19に関連した活動はパンデミックが続く限り行われ、洗練されていくとおおよそ考えている。攻撃のボリュームは増加しないだろうが、標的とする情報や侵害の深さなどは、パンデミック前と比較したときに、影響がさらに増すと考えられる。諜報機関によるものが主ではあるが、金銭目的での活動（ランサムウェア攻撃）によるものも、ほんの一握りではあるが続くだろう。各地政府機関により展開されているコンタクトトレーシングシステムやアプリケーションも、情報収集のための大規模データベース、密売、フィッシングキャンペーン実施などの観点から、標的になっていくだろう。
M-Trends 2021が出ました（前編）
M-Trendsというのは、FireEyeとMandiant（もちろんFireEyeが2014年に買収）が毎年出している、最近のサイバー攻撃の深堀りや脅威のレポートです。約８０ページ。
自分へのまとめと、他情報を添える形で以下にまとめておこうと思います。
全部入れようと思ったけど大変なので前後編に分けてみました。
- 概要
- 数字でみるトレンド
- ランサムウェアについて
- ランサムウェア後のリカバリー、再構成のシナリオ
- （ここから後編にします）最近観測された脅威グループ：FIN11
- パンデミックに関連した脅威
- UNC2452について（SolarWindsの件）
- 事例研究
- 最後に
概要
セキュリティ担当者は、この一年で前例にないような課題と向き合うことを余儀なくされました。ランサムウェアを用いた攻撃者が、医療関係や教育機関、市などのネットワークを攻撃する一方、コロナ禍によりリモワへの移行、それによって企業は、計画とは違う形での適応や成長をする必要に迫られました。
UNC2452：SolarWinds Orionを悪用（＝トロイの木馬化させたDLLを入れ込むことによって）した攻撃の件です。近年で最も洗練されたサイバー諜報活動を行っている、国家などに支援を受けている脅威であり、多くの企業は、リモワが望み通り行われているかを確認するよりも先に、この脅威に起因した、信頼されたプラットフォームからのサプライチェーンアタックに注意を向けなければなりませんでした。
M-Trendがカバーするトピックとしては*1
- Mandiantが調査したインシデントの59%は、その組織内で検知されたものであり、昨年より12％ほど改善された。
- ランサムウェアにおいては、被害組織に対してファイルの暗号化を施すだけでなく、他の複数の手段を使って身代金要求がより飲まれやすいようにしている。
- FIN11という金銭が主な動機の脅威グループがあり、蔓延するフィッシングキャンペーンの主犯である（そのキャンペーンも複数の強要行為が行われている）。
- 広まっているランサムウェア攻撃により、感染前の潜伏期間が身近くなっている。これまでは潜伏期間の中央値は30日を遥かに超えていたが、今回は24日となっている。検知力が上がっているためとも言えるが、ランサムウェア攻撃という意味では最初の侵害から発覚までの時間が短いことも要因と思われる。
- MITRE ATT&CKの63％の利用を観測しており、そのうち1/3のみが、5％以上の侵入で見られている。
数字でみるトレンド
検知状況
- 内部での検知割合が59%と増加しており、検知とレスポンスに関する組織での運用が向上していることを示唆している。
- 潜伏期間の中央値は24日となり、2019年の56日の半分以下となった（2011年は416日）。分布傾向としては、インシデントを最初の30日で発見することが多くなり、700日以上経ってからのインシデント発見については減少傾向である。これを、ランサムウェア関係と、それ以外に分けて話をすると、
- ランサムウェア関係：5日
- それ以外：45日
- この潜伏期間の傾向は米国においては同様だが、アジア地域においては昨年より増加しており、76日となっている（前回は54日）。ランサムウェアに関係する攻撃が昨年より減少していることが原因と見られる。アジア地域においては、潜伏期間が3年を超えるものや9年以上のものも、前回同様継続して観測されている。欧州においても前回と比べて微増である。
- 業界別の傾向については、大きな変化はないが、小売業界、医療関係組織が特に狙われている傾向が今回は顕著となっている。
- 標的型攻撃において、初期の攻撃手法はフィッシングが23%だったが、エクスプロイトによるものが29％と上回っている。攻撃動機は直接的な金銭が36％、一方で2％ほどが知的財産や盗聴などそれらを再販することを意図するものであった。一つの組織に複数の脅威グループによる攻撃が確認された割合は、前回より倍増している。
- これまでMandiantでは2,400以上の脅威グループを追いかけてきたが、現在1,900ほどを継続してウォッチしている。Mandiantが2020年に実施した侵害調査には246の脅威グループが関与していた。
マルウェア・脅威テクニックについて
- Mandiantでは、自社の調査や公開されている報告書、情報などを通じて継続したマルウェア調査を行っており、2020年は昨年同様500以上の新種マルウェアを調査対象とした。攻撃者は、すでに市場で認知されているマルウェアを使うだけでなく、革新的で攻撃対象の環境に特化させたものを用いている。
- 上記の500種類に関して、カテゴリ別にはバックドアが36%、ダウンローダーが16%、ドロッパーが8%、ランチャーが7%、ランサムウェアが5%であった。またMandiantの調査案件で検出したマルウェア種別の分布としては、バックドア41％、ダウンローダー9％、ドロッパー9％、ランサムウェア8％、ランチャー6％だった*2。
- Mandiantにて新しく追跡を開始したマルウェアに関し、広くインターネットに公開されて自由に取得できるものは全体の19％のみであり、多くが、出回っていないものであることが分かっている。
| マルウェア種別 | 主な目的 |
|---|---|
| バックドア | 攻撃者が、インストールされたシステムに対して対話的にコマンドを発行できるようにする |
| 認証情報窃取 | 認証に用いる情報へのアクセス、コピー、窃取を実現する |
| ダウンローダー | 指定されたアドレスからファイルをダウンロード（加えて実行する場合もある）するものであり、その他の機能やコマンド機能などは持たない |
| ドロッパー | ファイルを展開、インストール、場合によっては実行するもの |
| ランチャー | ファイルを展開するもの。ドロッパーやインストーラーの違いとしては、こちらはファイルそのものや設定を包含せず、単に実行かロードするのみである。 |
| ランサムウェア | 暗号化など悪意のある行為を行い、それを回避または復旧するためには金が必要などとして最終的に金銭を被害者に要求するもの。 |
| その他 | ユーティリティ、キーロガー、POS、トンネルやデータマイナーなどを |
- Mandiantにて新しく追跡を開始したマルウェアに関し、広くインターネットに公開されて自由に取得できるものは全体の19％のみであり、多くが、出回っていないものであることが分かっている。
- 同じくMandiantの調査案件で頻出したマルウェアファミリーはBEACON (24%)、EMPIRE (8%)、MAZE (5%)、NETWALKER (4%)、METASPLOIT (3%) であった。マルウェアファミリーの3.4%のみが10案件以上で確認されたが、約7割は単一の調査案件でのみ確認された。
- Windows環境で挙動するマルウェアが大半を締めている。Windows環境で挙動可能マルウェアが全体の94%、Linux環境であれば8％、MacOSは3％という分布である。Windowsでしか動かないマルウェアは89％、Linuxオンリーは3％、Macオンリーは1％。
- 脅威テクニックについて（MITRE ATT&CKフレームワークを用いた話）、攻撃者が利用したテクニックは、MITRE ATT&CKに示されている全テクニックのうち63％と24％のサブテクニックであった。しかしながら、調査案件の5％以上で使われたテクニックは、全体の23％にとどまった*3。
- 頻繁に観測されるテクニックは、ファイルや情報の難読化、暗号化、エンコードによる、検知や分析のハードルを上げること（T1027）であった。またスクリプトやコマンド利用によるさらなる侵入（T1059）が通常行われ、そのうち80％はPowerShellを用いたもの（T1059.001）であった。その他、システムサービスを悪用したもの（T1569、及びT1569.002：Windowsサービス）、リモートサービス（T1021、及びT1021.001：Remote Desktop Protocolにおいては88％を占めている）がある*4。
MITRE ATT&CK テクニックと観測した攻撃分布（一部）
ランサムウェアについて
ランサムウェア攻撃について、これまでは、「ファイルが暗号化されてユーザーから利用できなくなる」「対策はオフライン暗号化だ」というシナリオを私達は理解していた。しかしランサムウェア攻撃はそこから違った形で行われるようになり、それにより組織は、これまでとは違った防御を迫られることになった。それをMandiantでは「多面的強要*5」として、ランサムウェアの変異・進化を特徴化することにしている。
多面的強要の切り口
- ランサムウェアによる暗号化がなされている：攻撃対象組織のファイルが暗号化されてしまい使うことができない。復号鍵やツールのための金銭を攻撃者が要求している。
- 機微情報の窃取：攻撃対象組織のファイルが窃取され、機微情報の公開に関して金銭を要求する。攻撃者優位になる構図。サービス妨害でなくビジネス被害に直結する、すなわち信用の損失、規制違反、訴訟、そしてデジタル変革の失速などである。2019年以前は見られなかったものである。
- 窃取データの「名指しと恥さらし」ウェブサイトへの公開：これらのサイトはTorネットワークにて運営されていることが多く、また攻撃者はセキュリティ・テック系メディアに謀り、被害組織からの支払いがより確実になるように試みる。データバックアップ対策は、この問題を解決できない。
- さらなる強要のしかけ
- 被害組織のインシデントについて、ニュース・メディアに取り上げるよう謀る
- 被害組織に電話を掛けて脅す
- データ窃取に関して、被害組織のビジネスパートナーに通知し、関係悪化と漏えいについて晒す
- DDoS攻撃により更に妨害する
多面的強要による妨害とブランドの損失
- これら多面的強要を用いる攻撃者は、単にバラマキなどによる機会を見つけるアプローチよりも、より複雑さを要求されるキャンペーンに向かっている。防御側の技術も前進しているが攻撃者も同様である。
- これらの攻撃では、攻撃者はランサムウェアを配置する前に機微情報を窃取し、これにより支払額の釣り上げや期日について要求してくる。被害組織のインシデントレスポンスにおいて、データ漏えいに関する通知要件は主要な懸念の一つである。窃取されたデータによっては、規制の観点での行動要件は問われないこともあるが、ブランドの損失やそれによる顧客やパートナーの損失を、攻撃者は持ち上げて要求してくる。
- 以前は、攻撃者は、さらなる攻撃対象ネットワークへの侵入のためにデータ窃取を行っていたが、今日ではそれに加えて機微情報などが探されている。Mandiantが確認した例では契約書、関係解消の合意書、医療情報や暗号証明書などがある。組織によるネットワークのセグメント化次第ではあるが、それぞれの機微情報が別々のシステムにて保管されていると、データが窃取される前に、より攻撃者の検知や隔離ができる可能性がある。
- MAZEランサムウェアを用いた攻撃者は、窃取データを用いて、標的に対してスパムキャンペーンを実施する。一方Ragnar Lockerランサムウェアを用いた攻撃者は、Facebook広告を使って被害者を恥晒しにする。平均して月に一つはそのような「名指しと恥さらし」のウェブサイトが作られている。MAZE攻撃者を皮切りに、SODINOKIBI、DOPPELPAYEMER、NEMTY、NEFILIM、CLOP、Sekhmetそしてm1x攻撃者も後に続いている。
- このようなウェブサイトに名を連ねているのは米国企業で多岐の業界に渡っている。特に製造業が多い。製造のダウンタイムやサイバーセキュリティへの向き合い方などから、この業種の組織は支払いを実施する傾向にある。いくつかのランサムウェアには、生産工程のプロセスを停止させるようなスクリプトを展開するものもある。
ランサムウェアに対する事前のハードニング*6
よく見られる課題は以下がある：
- Active Directoryに多くの特権アカウントがある
- サービスプリンシパル（SPN）が設定された特権を持つ、非コンピューターアカウントがある
- エンドポイントの特権アカウントに関して、その利用や露出を最小限にするセキュリティ対策がなされていない
- ランサムウェアの展開にGPOが悪用される
それぞれ見ていく：
1. Active Directoryに多くの特権アカウントがある
Living off the land （OSにもともと存在するツールなどを使って攻撃を試みる行為を指す）で例えばcmd.exeやPowerShell、WMIなどを使ってActive Directoryから情報を抜き取る、あるいはオープンソースのツールとしてAdFindやBloodHoundなどによりDomain Admin情報を特定する、などを観測している。
Active Directoryの特権アカウントは、単にビルトインのドメイン別特権グループ（Domain Admin、Enterprise Admin、Schema Admin、Administrator、Server Operator）のメンバーシップが割当たっているだけでない。ドメイン別特権グループの他に、多くの組織は、権限を別グループやアカウントに分散させ、高い権限を持ったリソースが非常に多くなる結果を招いている。有効な認証情報やなりすましによりそれらが攻撃者の手に渡れば、そこから水平展開でランサムウェアを多くのエンドポイントに配置できることになってしまう。
以下のようなグループやアカウントに関してレビューを施すこと：
- ドメインのルートにおいて許可が与えられている：例えばDS-Replication-Get-ChangesとDS-Replication-Get-Changes-Allの許可（これらはDCSync攻撃開始に使われることがある）
- ドメインコントローラーへの昇格許可が明示的に与えている
- コンピュータやユーザーオブジェクトが紐付いているOUに対して明示的な許可を与えている
- 多くのエンドポイントに対するローカル管理者権限が与えられている
- Kerberos権限委譲（制限付き・なし）が設定されている
- 権限委譲に対するプロテクト設定がされていない（たとえばProtected User Security Groupのメンバでない、Sensitive and Cannot Be Delegated属性が設定されていないなど）
- AdminSDHolderからプロテクトされている
- GPOの編集、リンク、リンク解除ができる
- 多くのアカウントのパスワード変更ができる（User-Force-Change-Password権限）
- 多くのエンドポイントのリモートログオンを許可するGroup Policyに、ユーザー権限関連付けの許可がされている。
2. サービスプリンシパル（SPN）が設定された特権を持つ、非コンピューターアカウントがある
- SPNはアクティブディレクトリにおいて、ユニークで、Kerberos認証のためのサービスログオンアカウントを持つサービスインスタンスの特定に使われる。非コンピューターアカウントでSPN設定がされているものは、ランサムウェア攻撃者のKerberoasting*7の初期の標的となる。このテクニックでパスワードがブルートフォース攻撃できた場合、水平展開や権限昇格、ランサムウェアの展開に悪用される可能性がある。残念ながら多くの組織では、特権アカウントがSPN設定されている。PowerShellコマンドによって、このアカウントの範囲を確認することができる。SPN設定があされている非コンピュータアカウントは通常存在するが、このアカウントに割当たっているアカウントの許可の優先度を明確し、昇格や水平展開のセキュリティ制御を行うべきである。
get-aduser -filter {(ServicePrincipalName -like “*”)}
3. エンドポイントの特権アカウントに関して、その利用や露出を最小限にするセキュリティ対策がなされていない
以下のハードニングを行う*8：
- 非サービス特権アカウントは保護済みユーザー（Protected Users）セキュリティグループにまとめる
- WDigestやWindows Credntial Managerなど、認証情報をメモリに平文で保存する方法を無効化する。攻撃者などによってローカルで変更されるよな場合に備え、グループポリシー設定にもこの設定が再度適用されるような設定にしておく。
- Windows 10やWindows Server 2016以上にてCredential GuardとRemote Credential Guardを有効にしておく。これ以前のものでは、特権アカウントによるリモートデスクトップ接続が開始された場合にRestricted Admin Modeが使われるようにしておく。
- エンドポイントのビルトインローカル管理者アカウントのパスワードを、Microsoft LAPSや他ツールを使ってランダム化する。
- GPOや認証サイロ利用時に、特権アカウントがどこでどのように使われるかを段階モデル化しておく（Guardrail enforcement）。
- 特権アクションが専用の特権アクセスワークステーション（PAW）や踏み台からのみ行われるようにする。
- 特権アカウントの権限委譲を保護する（例えばSensitive and Cannot Be Delegatedエンフォースメント）
- 水平展開やリモートアクセス、ランサムウェア展開に悪用されるようなプロトコルをWindowsファイアウォールで制限する。
- 水平展開を許すような許可設定のあるアカウントやグループのスコープを制限する。特に、特権アカウントはTier 1やTier 2のエンドポイントにアクセスできないようにする（ローカル・グループポリシーで）：
- ネットワークからこのコンピューターへのアクセス拒否する（SeDenyNetworkLogonRight）
- リモートデスクトップサービスによるログオンを拒否する（SeDenyRemoteInteractiveLogonRight）
- ローカルログオンの拒否（SeDenyInteractiveLogonRight）
- サービスログオンの拒否（SeDenyServiceLogonRight）
- 権限昇格やデータアクセスに使われ許可設定を持つアカウントやグループのスコープを制限する。例えば以下機能を許可するような設定を制限する：
- 例えば攻撃者は、GPOの編集が許可されているアカウントを危殆化したあと、例えばDefault Domain PolicyなどドメインのルートにつながるGPOを標的にし、そして大規模展開や暗号化実行のためのスケジュールタスクやログオンスクリプト、ソフトウェアインストールパッケージを追加する。そのためGPOが編集できる、そしてドメインのリンク・リンク解除ができる既存アカウントのレビューが必要である（既出のMandiant Ransomware Protection and Containment Strategiesを参照）
ランサムウェア後のリカバリー、再構成のシナリオ
理想的には、リカバリーと再構成は、攻撃調査（アクセス取得方法、水平展開、データ窃取、ランサムウェア展開方法など）と並行して実施できるのが理想である。リカバリーと再構成がセキュアに実施されなければ、攻撃者はそのアクセスを維持し続け、結果として継続的なリスク、ダウンタイム、今後の攻撃の可能性につながってしまう。
リカバリー、再構成につながる調査ステップ
事実と証拠に基づいたアクションが、リカバリー、再構成の成功には重要である。これらを計画するためには、以下の質問に答えていくと良い：
- 攻撃者がアクセスを維持しているメカニズム（Backdoorなど）は何か？
- 攻撃者が利用する、入り口、出口、あるいはホストベースのファイアウォールで防ぐ必要があるCnCチャネル（C2）は何か？
- ランサムウェア展開方法は何か（PsExecを使ったマニュアル展開、グループポリシーの改変、スケジュールタスクやログオンスクリプト）？
- ランサムウェアのさらなる伝搬は止めることができ、また鎮めることができるか？
- 水平展開やランサムウェア展開にどの危殆化アカウントが使われたか？
- どのエンドポイントにおいて、ランサムウェアの暗号化が未だ実行中か？
- 初回アクセスの主な手法や流れは何か？
- 特権アカウントはどれか？
これらを明確にしながら、何を隔離し、ハードニングするかを明確にしていく。これらが集約できるまでは、一時的にインターネットアクセスを遮断してトリアージを行い、レビューとセキュアなハードニング、リカバリーの計画を行う。
セキュアエンクレーブの利用*9
- 組織ネットワーク内において、クリーンで信頼でき、攻撃など影響を受けたシステムととの通信を制限されたようなシステムをエンクレーブとここでは称している（VLANなど）。これらエンクレーブ内のシステムは、信頼されたEDRツールなどとのみ通信が許可され、これらツールにてエンドポイントに不正なアクティビティやアクティブな暗号化プロセスがないことを確認する。
- リストア済あるいは新しく作られたドメコンはセキュアエンクレーブ内の最初のエンドポイントになることが一般的で、ランサムウェアの初期拡散の沈静化が成功したあと、そこから他のエンドポイントへの接続へと展開されていく。
リカバリや再構成タスクを妨げるもの
Active Directory Lock-out：攻撃者によってADの管理者が追い出されるような攻撃を確認している。ドメインコントローラーが有効であっても、一度攻撃者がドメイン管理者権限を奪取してしまえば、有効な管理者アカウントのパスワード変更が行われる。そのためリカバリのためにアクセスができないという状況になる。そのため行われる対応として、物理メディアからドメインコントローラーをブートしてcmd.exeを用いてユーティリティマネージャーバイナリ（utilman.exe）の置き換えがある。これによりユーザーがログイン画面にてユーティリティマネージャーをクリックすると、既存アカウントに新規パスワードが設定できることになる。
ドメインコントローラーの再構成課題：リストア、再構成にはまずドメコンが対象となることが多い。この点において、SYSVOLの破損がよく焦点となる。SYSVOLにはそれぞれのドメコンで冗長して持つファイルやフォルダー（グループポリシーテンプレートや設定、スクリプトなど）のセットであり、これが暗号化や破損されてしまうと、すべてのドメコンにカスケード（転送）してしまう。タイムリーなバックアップがないと、リビルドや再構成は複雑になる。ドメコンのシステムステートバックアップを行うことでこれを回避できる。これが難しい場合は、少なくとも以下をバックアップしておく。これらバックアップはオフラインに置かれるか、ドメインアカウントから直接アクセスできないような、論理的にセグメント化されたストレージクラスターに保存されることが望ましい。
ドメコンのバックアップからADのリストアでしか再構成できない場合、バックアップ計画が予めテストされ、スキーマやデータの完全性や可用性を確認しておかなければならない。以下のベストプラクティスは、ドメコンのリカバリ、再構成に関するもので、事前に確認する必要がある：
- オフラインバックアップ：オフラインのドメコンバックアップはオンラインバックアップと別にセキュアに保管されなければならない。
- 暗号化：バックアップデータは転送時、保管時に暗号化すること、あるいはオフサイトにミラーリングすること。
- DSRMパスワード検証：各ドメコンのディレクトリサービスリストアモード（DSRM）パスワードがセットされていること。認可済、非認可のドメコンリストアに必要になる。
- アラートの設定：バックアップデータの可用性、完全性に関するアラート（バックアップデータの削除、メタデータの名前削除、メディアエラー、リストアイベントなど）を設定する。
- ロールベースのアクセス制御：データバックアップを管理するバックアップメディアやアプリケーションへのアクセスについてロールベースのアクセス制御を行う。
- テストと検証：認可・非認可ドメコンリストアについてリストア手順を書面化しテストしておく。
バックアップとリストア手順の準備不足：効率的なバックアップ及びリストア手順が必要である。効率的な手順とは例えば：
- データ・アプリケーションバックアップの管理及び検証の責任に関する明確化
- ビジネス継続性と災害復旧計画（BCP）に照らし合わせたバックアップ・リストア手順の確認
- オンライン・オフラインバックアップの保管ポリシー：開始、頻度、検証及びテスト（ネットワーク内、クラウド内どちらも）
- バックアップインフラがセグメント化されており、予め決められたアカウントのみがアクセスできる。
- 組織にとって重要なデータ（crown jewels）の理解と、それに照らし合わせたバックアップ、フェイルオーバー、リストアタスクの優先度決め
- バックアップメディアやアプリケーションへのアクセスはロールベースアクセス制御を施す
- データだけでなくクリティカルなアプリケーションやサービスについてフェイルオーバーやリストアタスクのトレーニング、検証訓練を行う
- アプリケーションやインフラサポートについてベンダーとSLAを確立する
とりあえずこれで前編終了にします。ADについてよく書いてありますが理解が追いついていないままなところもあります。まとめと言いつつ後半はほとんど訳になっているような気もします。
後編はこんな目次です：
（ここから後編にします）最近観測された脅威グループ：FIN11
パンデミックに関連した脅威
UNC2452について（SolarWindsの件）
事例研究
最後に
*1:数字については、2019年10月1日から2020年9月30日にMandiantが調査したものを基にしていることに注意。調査範囲は全世界だが、地域（米国、欧州、アジア）に分けて数値化されている。この投稿では特筆するもののみ取り上げる
*2:それぞれのマルウェアが持つ最も特徴的な機能で分類しており、複数の機能を持つものでもどれか一つのカテゴリにのみ分類している
*3:ここは理解が難しいのでソースをあたってください。訂正があればお願いいたします。。。おそらく典型的に使われるテクニックは、これとこれである、というように言及するのが難しい、という意図かと思います
*5:Multifaceted Extortionをこう訳してみたんですが・・・
*6:日本ではNISCより、「ランサムウエアによるサイバー攻撃に関する注意喚起について」が2021/4/30に発行されている。
*7:そのうちこれもリンク貼ります！
*8:MandiantのRansomware Protection and Containment Strategies参照
CHIRPを走らせてSplunkでピーチクパーチク言いたかった
CISA（米国国土安全保障省傘下のサイバーセキュリティ機関）がリリースしたフォレンジックツールのCHIRP、これは、攻撃されたSolarWinds Orionを悪用した攻撃のIoC詳細を検知する目的がその一つです。もう一つは、攻撃されたMS Cloud環境における脅威アクティビティの検知（同機関からリリースされているSparrowでIoC検知）。テスト用のWindows Server環境で走らせてみて、Splunkに入れてログを確認してみます。ちなみにツール実行に際してシステム変更は行われないようです。そして終わるまで一時間くらい掛かるようです。。。
１．CHIRPのダウンロード：CISAのGithubにソースコードとコンパイル済実行ファイルがあります。コンパイル済実行ファイルをダウンロードし実行します。
Yaraルール以外、空です。まぁ、良いことなんですが、何も出なかったのでSIEMへの取り込みは不要でした。とりあえずYaraだけでも表示したつもりにでもなっときますか・・・
空振りしました。そんな嵐の日曜日。