台湾の金融機関サプライチェーン攻撃手法の分析

2022 年から 2023 年の間、私たちが監視していた金融機関に対する中国のハッカー組織の攻撃が以前より活発化しました。私たちは調査を通し、原因の多くがサプライチェーンに関連した情報セキュリティの問題と密接に関係していることがわかりました。

サプライチェーンには、もともと様々な種類のセキュリティの問題が存在していたため、被害企業の関係者たちはサイバー攻撃の原因となった原因の共通点を見いだせないでいました。私たちはサプライチェーンの情報セキュリティの問題を分析し、図 1 のようにそれらを 4 つのカテゴリーに分けました。

‍

‍

図 1 の分類の中で、私たちは 2 つの方向からサプライチェーンの攻撃タイプを考察し、最終的に 4 種類の攻撃分類としました。方向としては、初期ハッキング対象機関とハッキング対象のソフトウェアのライフステージの 2 方向です。

1 つめの方向は、【初期ハッキング対象機関の攻撃】で、攻撃者は直接機関を攻撃する前に、まずサプライヤーを攻撃し、そして間接的に攻撃対象機関を攻撃します。私たちはその間接的な攻撃のもととなるサプライヤーを 2 つの役割に分けました。システムデベロッパーとサービスプロバイダーです。

2 つめの方向は、【ハッキング対象ソフトウェアのライフステージ】で、ソフトウェアは、開発、リリース、運用などの異なる段階において、異なる攻撃を受ける可能性があるという考え方です。そこで、サプライチェーンソフトウェアの脆弱性に付け込んだ攻撃と、ソフトウェアの開発段階でマルウェアに感染させるサプライチェーン攻撃に分類しました。

サプライチェーンソフトウェアの脆弱性に付け込んだ攻撃は、よくあるサプライチェーン攻撃で、攻撃者は、ターゲットが使用するソフトウェアのシステムを理解し、そのソフトウェアの脆弱性を見出し、それを利用してソフトウェアの運用段階で対象機関を直接攻撃します。このような攻撃型態は以前から存在していますが、最近サプライチェーンに関する話題の中で取り上げられるようになりました。

それとは相対的に、最近有名になってきているのがソフトウェアの開発段階でマルウェアに感染させるサプライチェーン攻撃（例：Operation Shadow Hammer と呼ばれる攻撃、SolarWinds にバックドアを仕掛けられた攻撃など）です。この手法の場合、マルウェアは正規版のソフトウェアと共に、正規ルートを通ってユーザの機器にインストールされます。マルウェアは合法的なソフトウェア開発フローを通っており、開発企業の保証がある場合も多いため、EDR 等の情報セキュリティ製品の多くはそれを見逃します。ユーザがインストールすると、自動的にバックドアが埋め込まれ、広範で重大な被害をもたらします。この種の攻撃では、そのソフトウェアを使用するすべてのユーザが潜在的な被害者となります。

今回の分類においてサービスプロバイダーも分類の要素となっており、その中でも中間サービスプロバイダーが重要であると私たちは考えました。これに関連する攻撃分類が、アイランドホッピング攻撃とサービスプロバイダーや外部委託業者のデータを直接窃取する攻撃です。昨今のソフトウェアエコシステムでは、ソフトウェアのインストール、メンテナンス、コンフィギュレーションにおいて中間サービスプロバイダーが重要な役割を果たしています。彼らは通常、高いアクセス権限を持ち、サービス対象機関の IT システムにアクセスできます。このような慣習が新たなアタックサーフェス (Attack Surface) を生み出し、いわゆるアイランドホッピング攻撃 (Island Hopping Attack) を導くのです。

アイランドホッピング攻撃とは、攻撃者はまずサービスプロバイダーを攻撃し、VPN、リモートデスクトップなどリモート制御の権限を取得し、そしてその経路を通してターゲット企業の内部ネットワークに侵入するという手口の攻撃です。

サービスプロバイダに対するもう一つの攻撃手法は、アイランドホッピング攻撃と反対の方法です。つまり、攻撃対象である政府機関がサービスプロバイダーや外部委託業者に提供したデータを攻撃者が直接窃取する方法です。

上記説明の通り、サプライチェーンへの攻撃は様々な種類があるため、サプライチェーンのセキュリティは単一の問題ではなく、異なる種類の攻撃手法に対して異なる処置方法を取らなければなりません。例えば、前述のアイランドホッピング攻撃の対策としては、威脅ハンティングや脅威検知メカニズムを採用して外部サプライヤーが内部システムに対して行うアクセス管理を強化することが有効です。しかしこの方法は、外部委託業者によるデータ漏えいの威脅に対しては有効とは言えません。なぜなら、この場合の原因は外部委託業者のシステムにあり、自社の内部が原因ではないからです。そのため外部委託業者のセキュリティを強化しなければ、その問題を解決できないということになります。

‍

サプライチェーン攻撃の事例紹介

私たちは今まで多くの金融機関のサイバー攻撃を調査してきました。その中で私たちは、前述の 4 種類の攻撃分類すべてに遭遇しました。そこでこの記事ではその 4 種類 の分類に沿い、攻撃事例を紹介します。攻撃対象機関のプライバシーを守るため、紹介する事例では、プロセス情報（会社名、ユーザー名、機器名、特定経路など）をすべて匿名化し、攻撃関連の情報だけを残しています。

‍

Type 1：アイランドホッピング攻撃（Island Hopping Attack）

まず最初に、アイランドホッピング攻撃について紹介します。アイランドホッピング攻撃の関連インシデントにおいて、最初の攻撃対象は最終攻撃対象企業から信頼されている組織、つまり、攻撃対象企業にサービスを提供するサービスプロバイダー、外部委託業者、子会社、海外支部組織などです。また、企業の子会社が他の業者とサービスの取引を行ったり、情報システムの代理運営委託などを行う場合がありますが、それらの委託先業者もサービスプロバイダーとみなします。アイランドホッピング攻撃という手法は、金融機関グループ内の子会社を踏み台として他社を攻撃するという方法で、金融機関において特に顕著な攻撃の一つです。この攻撃手法を利用した、2 つの事例を紹介します。

‍

Case #1: Bifrose is Back

このインシデントでは、当時攻撃対象の金融機関の内部取引システムでマルウェアのアクションが検知され、同機関のセキュリティ運営センター (Security Operation Center, SOC) では大量のログイン失敗の記録が見つかりました。そのため同機関は、弊社にインシデント調査の依頼をし、私たちはその原因を調査することになりました。

‍

‍

では、具体的に攻撃プロセスを見ていきます。攻撃者は攻撃対象企業からサプライヤーへ提供されていた VPN アクセスを利用し、サプライヤーが管理する機器 (Server-CARISA)を通って、内部ネットワークに侵入し攻撃しています。攻撃者はその機器でマルウェアを実行し、同一グループ内の別の金融会社を攻撃します。以下、この攻撃インシデントの Cyber Kill Chain と戦術、技術、手順 (Tactic, Techniques, and Procedures.TTP) を整理したのでご確認ください。

このインシデントは 3 つの主要な攻撃手法を使用しています。まず、そのうちの 2 つの攻撃手法について説明します。 1 つ目の【Server CARISA】は、ブルートフォース攻撃でアカウントの Admin と Administrator へのログインを試み、最終的に Administrator アカウントを使用して Server SOON-2 にアクセスしています。この攻撃者は、管理者権限も取得しているはずで、内部ネットワーク内でラテラルムーブメントを実行できます。

‍

‍

Server-SOON-2 はこの攻撃での重要なエンドポイントで、攻撃者はリモートデスクトッププロトコル (Remote Desktop Protocol, RDP) と PsExec でラテラルムーブメントを行い、マルウェアをばらまきました（図4 ）。

‍

‍

ローカル管理者は Server-SOON-2 上で、RDP を利用しログインした後に疑わしい実行ファイル ntxn264.exe を実行し、悪意のある DLL ファイル uNPXtssucPrx.dll に感染させてバックドアを仕掛けました。このバックドア DLL は持続的サービスとして登録され、システムを再起動すると自動的に実行され、後続の攻撃を行います。この DLL は私たちの研究により Bifrose バックドアと確認されています。

‍

‍

マルウェアを検知したエンドポイントを分析したところ、攻撃は別の機器 Server-CARISA から来ていることが分かりました。このエンドポイントは被害者の組織のものではなく、同一の金融グループに属する他の会社の機器でした。さらに調査を続けると、このエンドポイントは、外部のサプライヤーが運営しているものであることがわかり、攻撃元はサプライヤーが割り当てた VPN IP であることも確認できました。このことから、攻撃者はまずサプライヤーに侵入し、サプライヤーの VPN を利用して金融グループ内の企業の機器に入り込み、それから同一グループの他の会社のシステムに入っていったことがわかります。

2 つ目に、この案件の主要なバックドアプログラム【Bifrose】について見てみましょう。

‍

‍

‍

今回の Bifrose プログラムの作動フローとフレームワーク

1. 暗号化された Payload を読み込む
2. PE の形式を解析しプログラムのエントリポイント（開始アドレス）にジャンプして実行する
3. 実行中の自身のプログラム名を検査する
4. C2 に接続し機器の基本情報を送信する
5. マルウェアは後続の制御コマンドを送信する

‍

Bifrose は最初、サービスの起動に伴い ServiceMain 関数を実行して起動し、変異した RC4 アルゴリズムを通して Payload の復号化を行います。ここで注意すべきは、暗号化されているのは Payload だけでなく、クラスローダー内部のコンフィギュレーション情報も暗号化されているということです。この暗号化メカニズムは Bifrose の分析と検査を一層難しくします。

‍

‍

‍

暗号化されたデータを復号化すると、Bifrose はメモリ内で復号化した内容を DLL で実行します。具体的には以下のステップで行われます。

1. Biffose は復号化されたデータ (DLL形式のマルウェア) から PE ヘッダを探す
2. Bifrose は復号化された DLL の各セクションをメモリにコピーし、後続の実行に備える
3. 復号化された DLL の Import Table のライブラリを解析する
4. 復号化された DLL が実行できるようにメモリの適切な位置へ展開し、LoadLibrary を実行して ImportTable を実行時と同じになるよう再配置する
5. 最後に Bifrose はインストラクションポインタ（命令の実行アドレス）を DLL のエントリポイントに移行し、復号化されたマルウェアをメモリで実行する

‍

このプロセスにおいて、Bifrose のすべての操作はメモリ内で実行され、ファイルシステムに痕跡や記録を残しません。そのため、分析がより難しくなります。

基本的な実行が完了すると、Bifrose は機器に関連する情報（Victim ID、Computer name、Username、Version number、Process id、Language など）を C2 サーバに送信します。

• Victim ID: default_zz, set bythreat actor
• Computer Name: GetComputerNameA
• User Name：GetUserNameA
• Version Number: 2120.1
• Process ID: GetCurrentProcessId
• Language: GetLocaleInfoA

‍

‍

Bifrose が C2 サーバに接続すると、攻撃者は以下の操作が行えるようになります。

‍

‍

今回の攻撃に関する TTP と IoCs を以下に参考としてご紹介します。

‍

Case #2: Operation Cache Panda

Operation Cache Panda については、CyCraft のブログでも過去に紹介したことがあります。このインシデントは非常に重要なので、もう一度ここで簡単に紹介することにします。更に詳細の内容は、下記のリンクから関連記事をご覧ください。

中国ハッカーが狙う金融機関のサプライチェーン、徹底調査と対策は急務

2021年 11 月 25 日、証券取引業者が扱うシステムで、大量の異常な取引アクションが発生しました。多くの証券取引業者は、問題のアクティビティを検査するため、取引を一時停止せざるを得なくなりました。当時の初動調査による結論は、その攻撃は、パスワードの不適切な管理とクレデンシャルスタッフィング攻撃が関連していると推測されるものでした。そのインシデント発生後、多くの組織ではセキュリティ意識が高まり、各社は自社の情報セキュリティをより一層強化するようになりました。こうしてエンドポイントの異常検知と対応のマネージドサービス (Managed Detection and Response, MDR) などのサービスが採用されるようになり、継続的にシステムセキュリティのモニタリングが行われるようになりました。

このインシデントのあと、被害を受けたある金融機関は弊社にインシデント対応 (インシデントレスポンス (Incident Response, IR) を行い、インシデントの原因などを解明するよう依頼しました。

私たちが調査を進めていくと、2021 年 11 月前後に攻撃の前兆がすでにあったことを発見しました。これは、金融業界にセキュリティの威脅がずっと存在していたことを示しています。このほか、インシデント発生後の 2022 年 2 月頃には、新たな疑わしいアクティビティを発見しました。これはいまだに攻撃が続いていたことを示しています。このような理由から、私たちはこのインシデントが単なるクレデンシャルスタッフィング攻撃ではなく、APT 攻撃と関連しているもの、特に TA410 と関連しているだろうと推測したのです。

このインシデントに関して私たちが強調したい点は、情報セキュリティの主な 2 つの問題がいずれもサプライチェーンに関係しているという点です。

攻撃者は、金融機関が常用するソフトウェアシステムの脆弱性に対して攻撃する傾向があり、また、サプライヤーの VPN を踏み台としてラテラルムーブメントを実施するのです。

詳細は先出の解説記事をぜひご覧ください。

‍

Type 2 サプライヤーのソフトウェア脆弱性（Vulnerability in Supplier’s Software）

次に、冒頭で分類した攻撃分類の 2 つ目、サプライチェーン攻撃について紹介します。この攻撃手法は、サプライヤーのソフトウェア脆弱性のカテゴリーに属します。サプライヤー用のソフトウェアは、特定業界では広く採用されており、攻撃者は簡単に脆弱性を利用し攻撃をすることができるため、注意が必要です。

‍

Case #3: Credit Card Leak in Bank

2022 年 4 月、ある銀行で、クレジットカードのデータ漏えいインシデントが生じ、それはサイバー攻撃が原因であると推測されました。この銀行は弊社に今回のインシデントに関する IR 調査を依頼しました。

私たちは、クレジットカードの申請フローを全面的に検査し、侵入される可能性のある重要サーバの調査を実施しました。

‍

その結果、このインシデントはサプライチェーンの問題であることが明らかになりました。問題はクレジットカード管理システムに存在する Web アプリケーションの脆弱性にあり、それは同銀行のサプライヤーが開発したものでした。私たちが注目したのは、攻撃者は迅速に脆弱性を利用しており、システムに脆弱性の利用の痕跡を残さず、直接 Exploit を利用して攻撃しているという点です。またこの特定のシステムは他社で広く使用されているものではありませんでした。そのため、攻撃者は恐らく他のルートからこの脆弱性を発見していたため、これほど速く攻撃することが可能になったのだと推測します。

その後の調査で、いくつかのエンドポイントは既に侵入されていたことがわかりました。その中には業務上重要な役割を持つエンドポイントがありました。ここでは、便宜上そのエンドポイントを Credit Card AP と呼ぶことにします。この Credit Card AP は新しいクレジットカードの申請に関連するすべてのリクエストを処理するエンドポイントです。

クレジットカードの申請リクエストを受けると、すぐに別の 2 つのエンドポイントで認証を実施します。すべての認証プロセスが成功すると、最終的にクレジットカード情報はデータベースサーバに保存されます。この構造において、CreditCard AP とデータベースサーバは最も重要なエンドポイントとなります。これらはクレジットカードのアプリケーションを管理し、データの安全性を確保する非常に重要なエンドポイントであると同時に、攻撃者の標的とされやすい特徴があるのです。

次に、このインシデントの詳細と TTP について説明します。

まず、攻撃者は Web アプリケーションの脆弱性を利用し、最初にアクセスに成功した後、ラテラルムーブメントを行い Credit Card AP にアクセスします。続けざまにデータベースサーバと他のエンドポイントにラテラルムーブメントを行います。このような侵入方法は攻撃者が明確なターゲットがあることを示し、データベースサーバと Credit Card AP という 2 つの重要なサーバに照準を合わせていたことがわかります。

攻撃の初期段階の調査で注意すべき点は、設定ミスです。攻撃対象組織の IT スタッフは、システムのテストサーバは、内部ネットワークからしかアクセスできないはずだと証言しました。ところが、テストサーバの Web ページログを検査したところ、PublicIP からこのサーバへの接続が試みられたことがありました。この点を確認するため、私たちが検証をおこなったところ、テストサーバとの接続に成功し、設定ミスがあったことが確認できました。また、テストサーバでは脆弱なパスワードを使用されているケースも多く、これも攻撃者に利用されるケースが目立つため、今後の大きな注意点だと言えます。

設定ミスの問題に加え、サーバにはファイルのアップロードの脆弱性が存在していました。この脆弱性は “1.aspx” の名前を持つ Webshell のアップロードを許してしまうものでした。これは、.NET フレームワークで作られた動的プログラムコードの読み込み機能を持つ Webshell です。

‍

‍

私たちが発見した Webshell は Behinder Webshell の変種バージョンで、これは攻撃者が見つかりにくいプログラムコードを利用し侵入したサーバを制御できるものです。Behinder は中国のサイバー攻撃グループがよく用いる Webshell フレームワークです。このサンプルが発見されたということは、今回の攻撃が中国からのものである可能性が高いと考えられます。攻撃者は Webshebll に感染させた後、 pystinger と proxy.aspx を利用してトンネル (tunnel) を設けて、内部ネットワークと C2 サーバ (Command & Control) を接続します。

‍

‍

私たちはさらに Credit Card AP サーバにも疑わしいアクティビティがあったことを発見しました。このサーバで、ts_windows_amd64.exe というマルウェアを発見しました。これは Golang 言語で開発したもので、FTP、Samba、Netcat (nc) 、Windows Management Instrumentation(WMI) などの機能の検出機能があります。このほか、PrintSpoofer など権限昇格ツールも発見しました。

‍

‍

さらに、幾つかのエンドポイントで、難読化された Cobalt Strike とウイルス対策ソフトウェアの検出を回避するシェルコードを生成する機能を備えた hoshinoGen と呼ばれるツールも発見しました。これは中国のハッカーたちがよく使用するツールです。

こうして、攻撃者はデータベースサーバへの侵入に成功し、SQL を用いてソフトウェアとデータベースのソフトウェアとデータベースの両方を操作していたことがわかりました。この経路がクレジットカードデータ漏えいインシデントの潜在的な攻撃経路であったと推測されます。

今回の攻撃に関する TTP と IoCs を以下に参考としてご紹介します。

‍

‍

Case #4: Source Code Stolen

2022 年 8 月上旬、ある銀行で疑わしいイベントが検知されたため、弊社がインシデント調査をすることになりました。このインシデントは前の事例と類似しており、取引プラットフォームに存在する脆弱性を利用したもので、脆弱性が攻撃の入口となっていました。このインシデントの取引プラットフォームは、台湾の主要サプライヤーが開発したもので、問題があれば台湾国内の多くの金融機関に影響してしまいます。

このインシデントの攻撃手法とフローについて考えてみます。下図は今回の攻撃プロセスです。

‍

‍

この攻撃では、最初の侵入では SQL Injection の脆弱性を利用し、公開サーバに侵入しています。次にこのサーバを足がかりとして、他の内部 Web サーバに侵入しています。その後、攻撃者は Scheduled tasks と Psexec を利用してネットワーク内でラテラルムーブメントをしています。

このインシデントのプロセスツリーは、SQL Server を中心として大量のコマンドラインプロセスが生成されたことを示しています。これは、 SQL 関連プロセスが CMD プロセスを作成するためで、SQLInjection 攻撃でよく見られるモデルです。私たちが調査したこのインシデントのプロセスでは、別の Webshell も確認されました。これは Tomcat プロセスが CMD プロセスを作成したためで、悪意あるコマンドを実行するためのものです。

‍

今回の案件では、攻撃者は 2 つのトンネルツールを使用しています。一つ目はオープンソースツール NPS で、二つ目は X.DLL です。以下は私たちが見つけたコマンドラインを整理したものです。

‍

‍

このインシデントでもう一つ注意すべき攻撃手法は、資格情報の窃取です。攻撃者はメモリダンプからパスワードを窃取する目的で Avdump と呼ばれる合法ツールで LSASS プロセスのメモリを取得しました。また、それとは別に、彼らは Mimikatz でパスワードを収集していました。今回の攻撃ではアンチウィルスソフトウェアの付加ツールを利用してプロセスメモリをダンプしていましたが、これは攻撃全体の中でも特徴の一つとなっています。

‍

‍

研究チームはまた、攻撃者がその後の侵入の際に 7-Zip で特定のディレクトリを圧縮していることを発見しました。被害者がディレクトリの内容を確認したところ、ソースコードの一部が窃取されていたのではないかとのことでした。

‍

今回の攻撃に関する TTP と IoCs を以下に参考としてご紹介します。

‍

金融機関の情報セキュリティの現状分析

最後に、この攻撃が発生した原因と、金融機関が直面する問題について検討したいと思います。

金融機関は高基準の情報セキュリティ規範に従い、潤沢なセキュリティ予算に基づき、厳格な安全措置を講じていると誰もが考えがちですが、実際には幾つかの困難に直面しています。

‍

高効率なサービス提供を優先したセキュリティ運用

金融業の株式の取引や運営には巨大な計算能力が必要となります。それと同様に、その巨大な計算能力を備えたシステムに対しての高機能のセキュリティソリューションの実装が必要と考えられがちですが、その実現は現実には困難です。実情としては、一般のエンドポイントにだけエンドポイントセキュリティソリューション (Endpoint Detection and Response, EDR) を展開し、先に示した本当に重要なエンドポイントには運用上の理由から展開できていないのです。そのため威脅に対する十全な可視性が得られず、防御網も不完全なものになっているのです。

‍

サプライヤーの競争不足

金融ソフトウェア市場は、数社の主要サプライヤーに寡占されています。ビジネス上の理由から、これらサプライヤーは、セキュリティ機能を優先的に考慮するわけではありません。サプライチェーンの脆弱性問題も、サプライヤーが寡占状態にあるため弊害が生じていることを物語っています。

‍

‍

金融産業の独特なサプライチェーンの問題は、多くの金融会社は実際には金融コングロマリット（複合企業）の一部であることから生じています。この構造において、同一の金融コングロマリットに属する会社ごとに、それぞれ程度が異なる情報セキュリティ規範があり、セキュリティ保護で重視する面も異なってきます。このコングロマリットの中でも、銀行は最も厳格なセキュリティ要求に従い、全面的なセキュリティ監査を頻繁に受けています。一方、証券関係の会社のセキュリティ監査要求はそれほど高くありません。例えば、銀行は高基準の情報セキュリティ規範に従いリモートデスクトッププロトコル (RDP) ログの定例監査を行いますが、同一金融コングロマリット内の証券会社は、 RDP アクティビティの監査や監督を行っていないことがあります。セキュリティのメカニズムと監査要求が異なるため、金融業界サプライチェーンの構造上の独特の問題が生じます。

金融会社の情報セキュリティ能力はコンプライアンスにかかっています。多くの場合、金融組織では、セキュリティ対策は規定のコンプライアンスの一部として扱われています。規定に情報セキュリティの制度が定められていないなら、金融機関はすぐにそれを設立しようとは考えません。

規制の制定では、金融組織の種類に応じて異なる基準が制定されます。銀行や証券ブローカーなどの金融組織が異なれば、管理義務も異なるため、情報セキュリティの強度も異なってきます。同一グループ内では、業務統合の必要から、ITリソースやITインフラの統合が行われます。この結果、今回の事例紹介で指摘したようなアイランドホッピング攻撃のような個別の環境に順応し特化した攻撃を受けやすくなります。

‍

結論

1. 今回の研究では、サプライチェーン攻撃を、初期ハッキング対象機関とハッキング対象のソフトウェアのライフステージに従い、4 種類の異なる攻撃手法に分けました。それは、サプライチェーンソフトウェアの脆弱性、開発時におけるソフトウェアへのマルウェア混入、アイランドホッピング攻撃、サプライヤーデータの漏えいです。私たちは攻撃手法ごとに、異なる情報セキュリティのメカニズムを用いて対応する必要があります。
2. サプライチェーンの攻撃において、金融組織のグループ内の IT システムは高度に整合されているものの、セキュリティ能力は異なるため、特殊なサプライチェーンの問題が生じます。
3. この 2 年で私たちは、4 回の金融サプライチェーンに対するインシデントを調査してきました。この記事ではこの 4 つのインシデントの内容を分析し、攻撃者が使用した TTP と IoC を検討しました。インシデントの詳細を迅速に調査し明らかにすることにより、攻撃手法を明確にし、現状を把握することで、今後のセキュリティ保護が徹底されることが期待されています。