12
6

Delete article

Deleted articles cannot be recovered.

Draft of this article would be also deleted.

Are you sure you want to delete this article?

More than 1 year has passed since last update.

Microsoft Security Advent Calendar 2022Advent Calendar 2022

Day 12

ランサムウェア対策としての AD Security

Last updated at Posted at 2022-12-12

はじめまして 小町 と申します。
Microsoft Security Advent Calendar 2022 12日目 に参加させていただきます。

はじめに

昨今、ランサムウェアの猛威は拡大し続けています。そのため、ランサムウェア対策という名目で様々なソリューションが世の中に出回っています。
しかしながら、昨今のランサムウェアはその攻撃の本質をきちんと理解していないと効果的な対策をすることができず、場当たり的なソリューション導入で終わってしまう事も多くあります。
今回はランサムウェアの攻撃の傾向と、その抜本的な対策としての AD Securityをご紹介していきたいと思います。

最近のランサムウェア傾向

以前はWannaCryのような「ばらまき型」と呼ばれるタイプが主として攻撃に使われていました。このタイプのランサムウェアは不特定多数にマルウェアを送り込み、運悪く感染してしまったユーザーから身代金を巻き上げることを目的にしています。しかしながら、このタイプの攻撃は攻撃者にとって効率よく稼ぐことができず、昨今はより効率よく、より高額の身代金を手に入れるために「 Human-Operated Ransomware (人間が操作するランサムウェア)」が主流となっています。
Qiita.jpg
このタイプの攻撃は、送り込まれたマルウェアに感染しても即暗号化されるような事はなく、攻撃者はその端末を起点に組織のネットワークにより深く侵入します。侵入した攻撃者は複数の端末を乗っ取りいくつものバックドアを作りながら最終的には組織の管理者権限、多くの場合は Active Directory の特権アカウント(Domain Admin 等)の権限を奪取する事を目標に行動します。組織の特権アカウントを乗っ取られた場合、攻撃者はその組織内であらゆる事が可能となります。多くの場合は特権アカウントの権限を使いあらゆる機密情報を盗み出した後、確実に金銭を得るために(そして自らの痕跡を消すために)ここで初めてランサムウェアで暗号化を実施します。
Qiita2.jpg

このあたりの詳細が知りたい方は以下の公開情報もご覧ください。
https://learn.microsoft.com/ja-jp/security/compass/human-operated-ransomware

よくあるランサムウェア対策

ランサムウェアの直接的な脅威はその暗号化能力にあります。暗号化することでユーザーが機密データにアクセスできなくなり、またシステムが正常に動作できなくなるため業務が停止します。そのため、対策としてバックアップに目が行きがちです。
業務継続性を考えた場合バックアップは有効な手段です。

しかしながら上記のような Human-Operated Ransomware の場合、バックアップを使い業務を一旦復旧できたとしても

・すでに情報は漏洩しており、引き続き攻撃者からは脅迫を受け続ける
・社内ネットワークに潜んだ攻撃者は排除できず、特権アカウントを奪われたままである
・バックアップから復元したデータを再度暗号化される恐れがある

という問題に対応できておらず、その場しのぎにしかなりません。
そのため、ランサムウェア対策としてはこれらを考慮にいれた方法を検討する必要があります。

あるべきランサムウェア対策

では、どのような対策が有効なのでしょうか?
ウィルス対策ソフトを常に最新にする? EDRを導入する? 脆弱性対策ソリューションを導入する?
いずれも有効ではありますが、今回皆さんに認識していただきたいのはActive Directory の特権アカウントを守る という部分です。
攻撃者は様々な方法・ルートで組織のネットワークに侵入してきます。しかしながら、いずれの場合も多くはActive Directory の特権アカウントを奪取することを目標としており、逆に言えばその特権アカウントさえ防衛できれば最悪の事態は回避する事が可能となります。

なぜ AD Security があまり注目されないのか?
これは様々な考え方があると思いますが、私が思うに最大の原因は
・地味
・面倒
の2点だと思います。

Active Directory の防衛方法自体は弊社から様々なドキュメントがリリースされており、またその歴史も長いことから様々なナレッジがパートナー様からも共有されています。
しかしながら、基本的には運用のナレッジが多く(地味)、また監視する必要があるログも多い(面倒)ことから積極的に今ADのSecurityを考えるお客様は少ない印象です。
実際にこんなベストプラクティスはリリースされていますが、これ読んだことある方どの位いらっしゃいますかね?
https://learn.microsoft.com/ja-jp/windows-server/identity/ad-ds/plan/security-best-practices/best-practices-for-securing-active-directory

しかしながら、上記の理由からもわかる通り、今後ランサムウェア対策として組織のADの防衛は改めて考えなければならない項目です。
では今後、どのように(楽を)してADを防衛していくべきか?
小町はここでMDI(Microsoft Defender for Identity)を推したいと思います。

MDIのメリット

正直な話、MDIを導入すればADは防衛できる!という事は絶対ありません。
そんな魔法のようなツールがあったら教えてほしいです。
※ 最近 EDR さえ入っていれば社内NWは安全! 的な誤解が多く見られますが、AD 防衛も同じです。 これ導入すれば安全! とうたってる製品があったら小町は詐欺だと思うことにしてます。

ただ、MDIはこれまで地味で面倒だったADのSecurity を楽に効率よく運用できるような支援は可能です。
例えば、ドメインコントローラーへの総当たり攻撃のような場合、ログインエラーのイベントログで検知する事はこれまでも技術的には可能でした。
しかしながら、1日で数ギガ発生するドメインコントローラーのイベントログ、それもユーザー毎の失敗の監査ログをリアルタイムに拾って他のユーザーの失敗率を比較しながら総当たり攻撃を判断する、となると運用の負荷も大きいため見過ごされているのが現状です。
しかしながらMDIであればそれらが容易に可能になります。
Qiita3.jpg

また、検知の機能ベースのお話ではなく日常の運用で絶対必要な

・特権をもっているアカウントの数(その内休眠アカウントが存在しているのか?)
・特権アカウントがどの端末で利用されているのか?(Domain Adminアカウントをサービスアカウントとしてどこかで利用されていないか?)
・特権アカウントを共有アカウントとして利用されていないか?(Domain Adminアカウントを複数の端末で利用されていないか?)

なども容易に確認できるようになります。
Qiita4.jpg

これらはADの運用上必ず日々の確認が必要な項目ですが、ログから確認するには手間がかかり過ぎたりで黙認されることが多かった部分です。
これらをMDIを使う事で、楽に効率よく運用に組み込めることができるようになります。
その結果、特権アカウントの管理がより厳密なものとなり、AD のSecurity がより高いレベルで確保できるようになります。

まとめ

このようにMDIを入れること(だけ)で、直接的にAD のSecurityが強固になるわけではないですが、確実にその支援をすることは可能になります。
その結果、特権アカウントの管理が厳密になり、もし攻撃者が社内に侵入してきたとしても容易に特権アカウントを奪取されるような事にはならず、逆にその間に攻撃者を検知して排除する という流れが生まれます。

ランサムウェアで組織を脅迫し金銭を得ようとする攻撃者から身を守るには、発動してしまったランサムウェアからの復旧を目指すのではなく、ランサムウェアを発動させるところまで進行させない、その手前で止めて検知するために何ができるのか?をぜひ改めてAD 防衛の観点から検討いただければ幸いです。

ここまで読んでいただきまして、ありがとうございました。

12
6
0

Register as a new user and use Qiita more conveniently

  1. You get articles that match your needs
  2. You can efficiently read back useful information
  3. You can use dark theme
What you can do with signing up
12
6

Delete article

Deleted articles cannot be recovered.

Draft of this article would be also deleted.

Are you sure you want to delete this article?