サイバー攻撃やマルウェア解析を行っている町のフォレンジック屋さんが、最近気になっている傾向について考えてみた、というお話です。
多分名前出しても「誰、それ？」っていうその辺のオッサンが、なんとなく肌感覚で感じていることをベースに考えてみた、というお話なので、統計的根拠とかはありません。
まあ・・・収集している情報の情報源をイチイチメモっていなかったり、お仕事での経験を直接出すわけにはいかないってのは多分にありますけどね。
認証情報に対する攻撃とは？
今回のネタにしている「認証情報に対する攻撃」とは、不正アクセスに利用するために認証情報を盗むような攻撃、認証方法の不備を突いて認証を突破する攻撃あたりを示しています。
つまり、認証が必要なシステムへの侵入、あるいはデータへのアクセスを可能にするための認証情報の窃盗や脆弱性・プロトコルの性質を利用した認証突破について、のお話です。
なぜこんなことを書いているのかというと、お仕事で監視していたり、サイバー攻撃の被害を調査したり、世の中のサイバー攻撃の傾向を見ていたりすると、どうも最近は「攻撃者が認証情報に強い興味を抱いている」と感じることが多いためです。
IPAの「情報セキュリティ10大脅威 2022」のうち、「組織」のトップは「ランサムウェアによる被害」ですが、将来「認証情報への攻撃による被害」が上位にこないよう、今のうちに考察したり、対策を考えたりしておきたいな、というのが今回の記事の趣旨になります。
認証情報に対する攻撃は、なにも最近始まったものではなく、昔からあります。
30年くらい前では、個人のPCはまだMS-DOSなどで認証もクソもなかったりしましたが、UNIXでは /etc/passwd が狙われた、なんてことは聞き及んでいました。
最近はランサムウェアの被害が急増しているのは事実で、サイバー攻撃被害の分母・分子がランサムウェア被害によって増えた分、そちらが目立つのですが、認証情報に対する攻撃が減っているわけでも脅威が下がっているわけでもなく、むしろいずれも上がっているのではないか、と考えています。
目に付く事例としては、Emotetマルウェアは認証情報の窃盗を行っているケースがあると言われていますし、フィッシングサイトでも認証情報を入力させることによって窃盗を試みています。
そして、漏洩した認証情報を用いて不正アクセスされた結果、情報窃盗だけでなく、ランサムウェアの被害の原因になったり、クラウドメールに不正アクセスされ勝手にスパムメールを発信される、といったケースもみられます。
ロシアの「Conti」ランサムグループのマニュアルが暴露されたという事件がありましたが、そのマニュアルを読んだ研究者は、「不正アクセスで組織に侵入、Active Directoryサーバをハッキングして組織内の情報窃盗しつつランサムウェアを実行する」という手口がマニュアル化されていたことを指摘しています。
(「Conti」から最近流出したランサムウェアハンドブックの翻訳と、それに関する Talos の分析)
認証情報に対する攻撃が増えている背景は？
では、認証情報に対する攻撃が増える理由はあるのか？ということを考えてみます。
以前（特にコロナウイルスが問題になった2020年春以前）と比べると、以下のような点は変わってきたと思います。
(1) リモートワークの普及
以前より、働き方改革の一環として、リモートワークの利用は普及しつつありました。
そんな中、コロナウイルス感染症対策の一環として、リモートワークが推奨されたため、一気に広まったことは記憶に新しいと思います。
この結果、それまではVPNなどが認められていなかった会社・組織でも、外部から社内にアクセスして仕事できるようになったというところが多いと思います。
つまり、外部からアクセスできる入口が増えた、と見ることができます。
問題は、この時は業務優先で「なし崩し的」に導入されたことです。
そこでは、残念ながらセキュリティの観点が十分考慮されたとは言えない会社・組織が多くあったようです。
私の当時の勤務先でも、サイバー攻撃の被害に関する調査依頼が殺到し、調査員(=私)の稼働率が200%超え、複数の調査案件同時並行という酷い有様でした。
恐らく、同業他社も同様の状況だったのではないかと思います。
（これ、誰か日本のサイバーセキュリティ史の黒歴史として記録しておいてくれないかなぁ・・・）
いわゆるダークウェブ、ディープウェブとよばれるサイトでは、様々なデータが売られたり晒されたりしています。
こういったデータは、既知のデータを他の犯罪者が出しなおしているようなケースもよくみられました。
（特に、大規模なリークの「Collection#1～5」に既に収録されているデータが多かった印象。）
しかし、2020年夏頃から暫くの間は、新たなリークデータが多数出た時期でもありました。
今は亡き RaidForums でも、日本の複数企業を含む多くの新データが晒されていたものです。
これらの情報漏洩でも、「認証情報に対する攻撃」が原因になったものがあったのではないか、と考えています。
(2) クラウド利用の増加
クラウドの利用も、以前より普及しつつありましたが、リモートワークへの移行に伴いより促進されたように感じます。
クラウドを利用すると、そもそも社内の環境に接続する必要がなくなり、外部環境で完結するようになります。
また、業務データもクラウドストレージに格納されるようになってきました。
このため、それ以前に社内で作成した境界防御型のセキュリティシステムでは制御しづらい、できないような構成に変化しつつあります。
また、クラウドの利用についても、セキュリティの考慮が抜けているケースがあります。
例として、コロナウイルスの影響でリモートで開発するよう変更したとき、IaaS上に開発用のサーバをインストールして構築するというケースがみられました。
アプリケーションでは、指定のサーバが動作していればよいので、技術的には理に適っています。
しかし、その環境構築の際にセキュリティについての考察が為されていないケースがありました。
それまでの開発環境は、社内で完全にクローズドな環境か、社内ネットワークに繋がっているとしても外からアクセスは踏み台でもない限り無理、というものが大半でした。
こういった開発環境は、開発の上で色々試行錯誤するため、設定をゆるめにしておき、ある程度機能が固まってきたあとに制限をどうするか決める、ということもあります。
また、開発者もあまりセキュリティには詳しくないことが多いです。
その結果、社内環境では許されていた（問題にならなかった）緩い設定の開発環境が、世界中からアクセス可能なWebのネットワーク上に出現する、ということになりました。
こういった環境では、ssh、telnet、ftp、DBなどのポートが開いてしまっていることがあります。
そして、クラウド上に開発環境を作った人たちは、その環境が外部からスキャンされていることも知らず、それらのポートに対し不正アクセスを試みている痕跡を把握、監視するということもしません。
この結果、知らないうちに開発環境からのソースを含めた情報の漏洩や、C&Cサーバへの改造が行われるといったリスクが生じます。
以上、体験や聞いた情報から思ったことを書きましたが、リモートワークやクラウド利用が普及した結果、それらの会社・組織への入口が増えた、あるいは業務の情報がインターネットにより世界中からアクセス可能な場所（クラウドストレージやWebメール）に格納されている、というケースが以前より増えているのは間違いないと思います。
それは、攻撃者が被害者に対しリモートでアクセスしやすくなっている、とも言えると思います。
そして、攻撃者によるリモートアクセスでは「認証情報」は大きな武器になること考慮すると、認証情報に対する攻撃が増えるのは自然といえるのではないか、と考えています。
ユーザにとって便利になる仕組みが、犯罪者にとっても攻撃に便利になるのは皮肉なものです。
認証情報に対する攻撃法の例(Windows)
では、認証情報に対する攻撃はどのようなものがあるか、ということを調べたり考察してみました。
お仕事柄、Windowsのフォレンジックが多いので、今回はWindowsネタになります。
例として、以下のような脅威が思い浮かびました。
- メモリ上のlsass.exeの情報を狙う。
- レジストリのSAMの情報を狙う。
- NTLM認証、SMBv1といった古くて問題が見つかっているプロトコルを利用する（ダウングレード攻撃を伴うケースも含む）。
- ADサーバのkrbtgtのNTLMハッシュを盗み、Golden Ticketによるチケット偽造する。
- Kerberostingを利用してパスワードクラックをする。
こういった行動に対し、どのように監視・検知するか、またはフォレンジック調査でどうやって痕跡を見つけるか、ということを考える必要がありそうです。
メモリ上のlsass.exeの情報やレジストリのSAMの情報を狙うのは、これらから最終的にNTLMハッシュを取得することでしょう。
また、NTLMハッシュをパスワード解析することで、パスワードの解析も可能です。
なお、NTLMハッシュ関係については過去に記事にしていますが、Windows 10の途中からNTLMハッシュの暗号化がRC4からAESに変わっているものの、NTLMハッシュを取得できたあとの仕組みは基本的に変わっていないと思います。
(過去記事)
Windows10の新しいハッシュの暗号化の解析問題の確認メモ（その１）
Windows10の新しいハッシュの暗号化の解析問題の確認メモ（その２）
Mimikatzのようなマルウェアに感染させてlsass.exeプロセスのメモリデータやSAMを解析する方法もありますが、これらのデータをダンプし、攻撃者の環境へ送信して攻撃者のローカル環境で解析する、という方法も考えられます。
このため、フォレンジック解析の観点では、情報窃盗のマルウェアの感染、動作、通信だけでなく、lsass.exeプロセスデータやSAMへのアクセス、ファイルへの出力、送信の痕跡がないか、という観点が必要になると考えられます。
NTLM認証、SMBv1といった古いプロトコルは、中間者攻撃(MITM)が可能だったり、より弱い認証(LM認証など)を使っていたりと、仕様上の弱点が見つかっており、既に危殆化されています。
(*実は、色々設定すれば、ある程度緩和できるという話も聞きます。・・・が、そこで緩和策頑張るくらいなら、素直にKerberos認証やSMBv3使っとけ？な？)
もちろん、最近のデフォルトはKerberos認証だったり、SMBv3になっていたりします。
しかし、設定で下位のプロトコルが許可されている場合、クライアント（を偽装した攻撃者）が下位のプロトコルでリクエストすることで、危殆化されているプロトコルを使用させ、攻撃に利用することが考えられます。
下位のプロトコルが許可されている理由として考えられるのは、以前からADサーバを利用しているが、設定を見直していない、というケースです。
Windows serverの更新に伴ってADサーバをリプレースしても、設定は以前のものを引き継いだまま・・・ということが多いのではないでしょうか。
また、「設定を厳しくした結果、何かの機能が動かなくなったら大問題」という理由で、「運用上問題が無いならば」そのまま、ということも多いでしょう。
ただし、これは「運用上問題が無い」だけで、セキュリティには大問題だったりするんですけどね？
（魔法の言葉「運用」）
Windowsのフォレンジックの場合、イベントログを見ることになると思います。
WindowsのSecurityイベントログには、認証に利用されたプロトコル名なども記録されています。
チケットの偽造やパスワードクラックの成功に関しては、不審なアクセスを監視するくらいしか方法がないとは思います。
もちろん、ADサーバに不正侵入された疑いが僅かにでも生じたならば、krbtgtのパスワードは速やかに変更すべきでしょう。
krbtgtのパスワードのリセットは、2回のリセットが必要など色々注意事項があります。
AD フォレストの回復 - krbtgt パスワードのリセット
認証情報を利用した攻撃のフォレンジック解析でやっていること
「認証情報が盗まれて不正アクセスされているのでは？」というケースでのフォレンジック調査も増えてきました。
こういう場合は、明らかにクロというよりは、グレーだけど不正アクセスではないか念のため確認、というケースが多いです。
ただし、確認した結果クロだったというケースもあるので、こういった勘所も侮れないと思います。
こういった場合のフォレンジック調査での解析の観点と流れについて紹介します。
なお、ここに書いているのはあくまで私がやっている方法で、デファクトスタンダードではないことはご了承ください。
最初は、何らかの兆候をつかむことになります。
ここでは、セキュリティの監視ソフトの能力に頼る必要があります。
エンドポイント系では、アンチウイルスのアラートもアリですが、最近では何らかのEDR(XDR)による検知が無いとキビシイかもしれません。
ネットワーク系では、ブラックリストに登録しているIPアドレスとの通信やドメイン名のクエリなどになりそうです。
最近は、ペイロードが暗号化されていることも多くなっており、ペイロードからの検知は難しくなっているかと思います。
不審な兆候を見つけたら、当該端末で不審な行動の原因を探ります。
単純にマルウェア検知だけでなく、不正アクセスしている攻撃者がコマンドラインやPowershellによるコマンドを実行していることもあります。
Windowsの場合、イベントログが有効な情報源ですが、イベントログは設定によってイベントの記録の有無が変わります。
特に、デフォルトでは割とイベントを記録していなかったりするので注意してください。
(過去記事)
不審な兆候の原因（コマンドやマルウェアらしきプログラムの実行）をイベントログで確認したら、それを実行したアカウントを確認します。
そして、調査ではそのアカウントは攻撃者によって乗っ取られていると仮定して調査します。
そこで、そのアカウントによるリモートアクセスや、実行したコマンドを時系列で洗い出しします。
このとき、最初に発見された端末だけでなく、リモートアクセスされ得る端末は全て確認することが推奨されます。
このため、やはりこういった調査に利用できるようなEDR(XDR)の導入は重要だと思います。
この洗い出しした情報を元に、アカウントを割り当てられている人にログオン時間の確認やコマンド、プログラムの実行についてヒアリングで確認します。
もちろん、洗い出しした情報をアナリストも解析するのですが、正直言って本人に確認するほうが早かったりします。
また、調査対象のIT管理担当者にも、そのアカウントが通常どのエンドポイント名でログオンしているか、などを確認します。
アナリストの解析、本人のヒアリング、IT管理担当者のヒアリング結果が揃ったら、それらの指摘事項を確認します。
業務時間外や本人に身に覚えがない、あるいは業務で使わないコマンドやプログラムの実行が見つかれば、大体アウトです。
そして、それを軸にして芋づる式に引っ張っていくと、攻撃の全容が解析できたりします。
調査員の愚痴
攻撃者が認証情報に対する攻撃を成功させ、取得した認証情報を利用した攻撃をしてきた場合、調査担当者にとってはイロイロ辛い面があります。
そもそも、認証情報を盗まれて不正アクセスされた場合、その検知が難しいです。
だって、認証情報って、元来は「どこからアクセスしてこようが、それが正しければ本人と認める」というルールなんですよ？
それが合ってるんだったら、「正常」と判断するのが本来の姿なんです。
その中から異常を見つけろっていうんだから、原理的に無理があるというのは否めません。
筋論から言えば、「本人と認める」ルールをより確実性の高いものに変えるべきです。
最近では、二要素認証（多要素認証）、二段階認証といった方法が推奨されていますが、これもその一環とみることができるのではないでしょうか。
また、調査員は基本的に「部外者」です。
これは、私のようにそれ専業の会社の人というだけでなく、社内であっても担当が違う、ということになります。
そして、「部外者」である調査員やシステムにとってはアカウントの悪用かどうかの判断はかなりツライものがあります。
理由として、組織の担当者が異常に気付く点が、ローカルルールから逸しているからということが多いからです。
異常に気付く理由として、以下のような例があります。
- アカウントのユーザに貸与した端末と違うコンピュータ名
- アカウントのユーザの業務時間外のアクセス
- 管理者用アカウントが通常業務上のアクセス対象外へアクセス
- 管理者でも業務で実行していないコマンドの実行
そして、調査員やシステムからすれば、「そんなもん知らんがな」ということになるわけです。
こういったことも考えると、こういったインシデントの調査は必ずしも技術的なものだけでは解決しないということです。
技術的な解析を行った結果に対する検証は、調査される側の人々の協力によってもかなり大きく変わるため、その協力の度合いによって調査結果の質が大きく変わります。
サイバー攻撃のインシデント調査でより実りの多い結果を得るためには、依頼側が「お客様」として依頼を投げつけるだけでなく、問題解決のチームとして取り組むほうが良いと思います（どーせ同じ金額払うなら、ね？）。
さいごに
認証情報に対する攻撃について、私の個人的な感想とその調査についての「お気持ち」（愚痴）という内容になっていました。
具体例が出せない（「無い」のではなく、「出せない」）ため中々説得力が無いかもしれませんが、理屈で考えても「認証情報」って悪用の幅が広がってきているというのは分かるのではないかと思います。
さて、「さいごに」と言いつつ、これのタイトルは「その１」。
つまり、「その２」があるんだなコレがぁ。
「その２」では、認証情報に対する攻撃でも、最近特に気になってる（＝どう解決していいのか私もわからん）方法について書こうかと思います。
話題の二要素認証（多要素認証）、二段階認証を突破する方法のしくみと考察（というほどでもない、多分私の感想かお気持ち）を書く予定です。
いつもどおり、だらっとした文章になるので、それほど期待せずゆるーく待っていてください。