2万社以上に安全なメールサービスを提供しているサイバーソリューションズ（東京都港区）の子会社で、15年ほどサイバーセキュリティインシデント対応支援サービス提供経験を有するセキュリティ技術者が設立したインターネット・セキュア・サービス株式会社（東京都港区）の最高サービス責任者である筆者が、サイバーセキュリティ侵害の侵入経路の傾向と対策について解説します。

 

今回は調査からわかった本インシデントの特徴と復旧作業の内容を解説します。

インシデントの特徴

調査を進めていくと、今回のインシデントにはいくつか特徴的なことがありました。

1.カスタムマルウェアの利用

この攻撃の過程で、攻撃者は被害企業のWindowsドメイン等の環境情報を入手し、その環境内で最適に動作する、いわゆる「カスタムマルウェア」を構成していたことが判明しました。

2.過去のインシデントとの関係

1年以内のインシデント情報をまとめ、いくつかのインシデントに対して追加調査を実施すると、約8カ月前のマルウェア感染インシデントが関係していることが分かりました。8カ月ほど前、ある攻撃ツールがアンチウィルスによりマルウェアとして発見・隔離され、SOCが対応していました。その時のSOCは、隔離された検体の確認とその地域の全サーバーのウィルススキャンを実施し、他に同様の検体が存在しないことを確認してクローズしていました。しかし結果としてこの対応は不十分でした。検知・隔離したものはウィルスではなく攻撃ツールであり、保存した実行者が存在します。そしてその実行者は不正アクセスを行っているはずです。保管されていた当時のVPNログを筆者チームで確認したところ、攻撃ツールが保存された時間と極めて関連性が強いVPN経由のアクセスを確認しました。この時使用されたアカウントが、この事例の不正アクセスに悪用されたアカウントと同一だったのです。

3.発見が困難なバックドア

ヒアリング当初の「CSIRTの気になる点」に従いサーバーを調査したところ、シンプルですが通信からは判断が難しいバックドアが発見されました。このバックドアは、あらゆる通信をHTTPSでカプセル化する機能しか有していません。「QuasarRAT」や「PoweShell Empire」などの有名な多機能バックドアとは全く異なります。今回の事例ではRDP（Remote Desktop Protocol）をHTTPSにカプセル化し、「RDP over HTTPS通信」を作るためだけに存在していました。FirewallログからはAWS（Amazon Web Services:アマゾンのクラウドサービス）上のホストへのアウトバウンドのHTTPS通信としてしか見えず、極めて発見が困難なバックドアだと言えます。CSIRTはこのアウトバウンドのHTTPS通信を気にしていたのです。AWSへの通信は通常の業務サーバーでも生じているため、確信を持つまでには至っていませんでした。攻撃者がAWS上のバックドアサーバーに接続すると、バックドアサーバーは攻撃者の通信とバックドアの通信をリレーし、攻撃者がRDPでホストに接続できるようにします。

画像を拡大 今回見つかったバックドアの動作