この記事では、AWS の 2 つの EC2 インスタンスが関係する、あるインシデントの調査で明らかになったいくつかの事実をご紹介します。これらのインスタンスは、ランサムウェアや仮想通貨マイニングを始めとするいくつものマルウェアに感染していました。

滅多にない恐ろしい出来事に遭遇したように思われるかもしれませんが、攻撃者によるホストへのアクセス方法は実際にはそれほど高度なものではなく、こういった攻撃は、クラウドだけでなく、あらゆる環境で発生する可能性があります。この記事では、攻撃者のホストへの侵入方法を検証し、今後の記事で、RDP 総当たり方式攻撃の対策のヒントをご紹介します。また、それらのインスタンスに対する攻撃の詳細も解説する予定ですので、ネットワークの感染したホストを確認する際の参考にしていただければ幸いです。

攻撃者は最初に、インスタンスにアクセスするために、クラウドでホスティングされている仮想マシンに対する RDP 総当たり方式攻撃を実行していました。RDP（リモートデスクトッププロトコル）は、Windows マシンで使用される、ユーザによるリモートデスクトップのログインと表示を可能にするプロトコルです。たとえば、RDP を使用すると、クラウドでホスティングされている Windows サーバにログインしたり、オフィスにあるコンピュータに自宅からログインしたりできます。総当たり方式攻撃とは、攻撃者がデフォルトの管理者アカウントのパスワードを繰り返し推測しようとするものです。

これらのインスタンスはいずれも、サードパーティのソフトウェアをテストする目的で私が使用していたアカウントに設定していたものであり、業務で使用する重要なネットワークやデータに接続していたわけではありません。侵入が明らかになった段階でネットワークをロックし、これらのホストからマルウェアがインターネットの他のホストに拡散しないようにしました。ネットワーク構成は基本的にはネットワークファイアウォールルールなしのものと等しく、MFA もなく、パスワードも推測しやすいものにしていました。また、総当たり方式攻撃を防止するためのレート制限もインスタンスに設定していませんでした。さらには、ネットワークトラフィックフロー経由でインスタンスに送り込まれるマルウェアの検知に役立つ、WatchGuard Firebox Cloud などのネットワークセキュリティアプライアンスも使用していませんでした。つまり、これらのホストは、攻撃者が容易に侵入できる標的だったのです。

攻撃の詳細を確認しようとして最初に直面したのは、AWS アカウントにログが存在しないという問題でした。CloudTrail と VPC FlowLog を有効にしていない方は、今の作業を中断し、すぐに AWS アカウントにアクセスしてログを有効にすることをお勧めします。やるべきことは他にもたくさんありますが、まずはこれが出発点です。オンプレミスのデータセンターで運用されている場合は、ネットワークログとアクセスログを有効にし、ネットワークのどのシステムに誰がアクセスして何を行ったのかを確認できるようにしておくことをお勧めします。セキュア NTP ソリューションを使用して、どのタイプのログでもすべてのタイムスタンプが正しい順番に並ぶようにしておきます。

前述のアカウントでログを有効にしましたが、過去のデータは利用できなかったため、Windows EC2 インスタンス（AWS クラウド上の仮想マシン）を調べてみることにしました。そして、さまざまな手段を使うことで、インシデントの発生日とおおよその発生時刻を特定できました。感染した両方のインスタンスのログを確認したところ、その期間のほとんどのログが消えていることがわかりましたが、前後に発生していたと思われる出来事の手掛かりが残っていました。この調査では、次のようなことがわかりました。

世界中のさまざまな IP アドレスが、短い間隔でこれらの EC2 インスタンスへのログインを試行していた

イベント ID 4625 を使用することで、Windows セキュリティイベントログでこれらの試行を検索できます。ただし、ネットワーク経由でこのような試行を停止する方がおそらく簡単でしょう。これについては、Secplicity の次回以降の記事で説明する予定です。

インシデントの直後に RDP イベント 4625 がなくなった

これは、誰もログを調べていないと考えた攻撃者が、パスワードの総当たり方式攻撃を加速させた可能性があることを示しています。そして、攻撃を加速させたことで、パスワード推測の速度も上がったようです。完全なログがなく、攻撃者の行動を正確に知ることはできないため、あくまでもこれは仮説に過ぎませんが、おそらく妥当な推測でしょう。

ドメインコントローラのパスワードがインシデントの発生時に変更された

インシデントの直後に、ドメインコントローラのパスワードが変わっていました。さらには、このアカウントのパスワードが同じ 2 つのインスタンスがほぼ同時に感染したことから、攻撃者が総当たり方式で片方のインスタンスのパスワードを突破し、そのアカウントの他方のインスタンスにも試してみた可能性があります。攻撃者が総当たり方式でパスワードを突破したのではなく、他の何らかの方法で脆弱性にアクセスしただけだったのであれば、両方のインスタンスがほぼ同時に感染したのは奇妙に思えます。

Windows のイベントログが削除された

攻撃者は攻撃の直後に、管理者だけが実行できる多くの操作をすぐに実行できるようになったようです。イベントの発生時までの重要なログが、両方のマシンで削除されていました。

ログインの成功と IP アドレスが RDP ログに記録されていたはずである

RdpCoreTS Windows ログとこのインスタンスに RDP ログインを試行した IP の例を以下に示します。残念ながら、攻撃の前後のログはすべて消えていました。

ログがないため、実際の出来事を知ることはできませんが、インシデント以降の出来事から、起きたであろう出来事を高い確度で推測することはできます。今回ご紹介した情報は、総当たり方式の RDP 攻撃をどのようにログで確認できるかを示しており、この記事をお読みいただいたことで、すべてのログを有効にし、保存しておくことの重要性を再認識していただけるものと思います。今後のブログ記事では、RDP の総当たり方式やこれらのインスタンスを感染させる恐れがある他の攻撃からの保護について、詳しく解説する予定です。感染した Windows ホストの特定に役立つ、マルウェアに感染した場合の具体的な兆候も提示します。— Teri Radichel（@teriradichel）