マルウェア
「QAKBOT」が有効なコード署名を悪用:その出所を探る
「QAKBOT」は、EMOTETと並んで近年最も盛んに活動しているボットの1つであり、2007年にその存在を確認されて以来、多くの事例が報告されてきました。本記事では、2022年の6月から7月にかけて確認されたQAKBOTに関する発見事項と、当該グループによる攻撃への対処法について解説します。
「QAKBOT」は、EMOTETと並んで近年最も盛んに活動しているボットの1つであり、2007年にその存在を確認されて以来、多くの事例が報告されてきました。トレンドマイクロでもQAKBOTとその背後の攻撃者の活動に関してこれまでに幾度か報告してきましたが、今年に入ってからの調査の中で特に注目すべき点が2つありました。それは、QAKBOTがFollinaと呼ばれる脆弱性「CVE-2022-30190」を利用した際の手口と、QAKBOTを用いてランサムウェア「Black Basta」が標的システムに侵入した際の手口です。本記事では、2022年の6月から7月にかけて確認されたQAKBOTに関する発見事項と、当該グループによる攻撃への対処法について解説します。
QAKBOTによるコード署名の悪用
トレンドマイクロは最近、コード署名が施されたQAKBOTのモジュールを発見しました。そのコード署名には、公的に信頼される認証局(CA:Certificate Authorities)が発行した証明書が使用されていました。このことから、QAKBOTが当該証明書の秘密鍵を所有していた可能性が示唆されます。
今回の攻撃で確認された感染フローの具体例を、下記に示します。
重要な発見事項
QAKBOTのモジュールを調査したところ、有効な証明書で署名された検体が、複数発見されました。こうした証明書の内容を調べたところ、これらは不正な目的で架空の組織に対して発行されたものではなく、適切な手続きを経た実在する企業や組織に対して発行された有効なものであることが判明しました。
有効なコード署名証明書の不正使用の事例はこれまでにもありましたが、頻繁に見られるものではありません。さらに、有効な複数のコード署名証明書や秘密鍵が、単一の攻撃グループによって断続的に取得され続けたことは注目に値します。
証明書や秘密鍵の出所について、現状では未確定ですが下記2つの可能性が考えられます。
- 従来からの手口によって、感染した端末から秘密鍵をダンプ、窃取
- 以前にも報告した通り、QAKBOTは証明書関連の情報収集に強い関心を持つと同時に、その技術を有している。ユーザが証明書の発行に際して鍵データ生成用のハードウェアトークンを使用しなかった場合、QAKBOTによってその証明書や鍵データが窃取される可能性がある。また、QAKBOTが時折使用する攻撃ツール「Mimikatz」にも、証明書や秘密鍵の窃取機能が備わっている。
- ただし、QAKBOTが実際に秘密鍵をダンプするような活動を積極的に行っていたかについては、疑問の余地がある。どちらかと言うと下記のように、証明書の発行手続き自体を不正使用して、証明書を直接的に受け取った可能性もある。
- なりすましなどにより、証明書の発行手続き自体を不正使用
- 不正使用された証明書は、農業関係など技術分野と無関係なマイクロカンパニー(規模の小さな会社)に対して発行されていた。
- 不正使用された証明書に登録されたメールアドレスについて、下記の不審な点が見られた。
- 同じフリーメールアドレスが異なる証明書に使用されていた。
- 証明書の発行直前に、メールアドレスのドメイン名に対してIPアドレスが割り当てられた。
コード署名は信頼性を確立する上で役立ちますが、その信頼性自体が不正な目的に転用される可能性があることを、セキュリティチーム側では警戒する必要があります。有効なコード署名があるだけではモジュールが安全であるとは言えず、マルウェアにも有効なコード署名が施されている可能性を踏まえ、コード署名証明書の内容を注意深く観察していく必要があるでしょう。
コード署名付きマルウェアの活動に関する歴史的経緯
トレンドマイクロは最近、有効なコード署名付きの正規アンチチート用ドライバが特権回避に不正使用された事例について報告しました。この件以外にも、コード署名証明書や秘密鍵が不正使用された事例は、以前から報告されています。
特に目を引く先駆的な事例として、2010年のマルウェア「Stuxnet」が挙げられます。本事例では、実在する複数の会社から窃取された有効なコード署名証明書や秘密鍵が不正使用されました。
この他、マルウェア「Flame」も注目すべき事例の1つであり、偽造した証明書がマルウェアの署名に利用されました。この証明書はMD5のハッシュ衝突によって生成され、最も信頼される規格の1つである「マイクロソフトコード署名証明書」に適合し、APT攻撃に用いられました。Flameが用いた手口は大変に高度なものでしたが、偽造した証明書は元の証明書と内容上の差異があるため、不正を検知すること自体は可能でした。
トレンドマイクロによる2018年の調査報告では、以上の他にも、信頼される有効な証明書を取得する各種手口が述べられています。この調査では、攻撃者が正規の企業や組織になりすまして、信頼される認証局(CA:Certificate Authority)から証明書を取得できること、さらに、こうした証明書や秘密鍵がブラックマーケットに売り出されることが判明しました。
最後に、2017年のセキュリティ会議「Conference on Computer and Communications Security Conference(CSS’17)」でMaryland大学のKim Doowonが発表した調査「Certificate Malware: Measuring Breaches of Trust in the Windows Code-Signing PKI」では、盗まれた秘密鍵から作られた証明書が72件、正規企業へのなりすましによって発行された証明書が22件、さらに実体のないペーパーカンパニーに発行された証明書が5件発見(調査時点)されました。調査で使用したデータセットから、マルウェアの事例が188,421件特定され、コード署名付きマルウェアの事例14,221件に対する解析が行われました。StuxNetが発見された2010年から2017年にかけて、PUAs(Potentially Unwanted Application:マルウェアのような不正さはないが、多くの場合削除することが望ましい)を除く10件以上の陽性検体に対する分析が、マルウェア解析ツール「Virus Total」によって行われました。
7年の間に不正使用された証明書が合計72件というのは、予想より少ないように感じるかも知れません。しかしそもそも証明書の不正使用はあってはならないことです。また相対的に、最近のQAKBOTがいかに積極的に証明書や秘密鍵を不正使用する機会を狙っているかも示しています。実際にQAKBOTは、その活動が最も盛んに見られた2ヶ月の間(2022年6月から7月)だけで、少なくも7件の証明書を不正使用したことが判明しました。
MITREのWebサイトでは、コード署名を不正使用した過去の事例を参照できます。また、特定少数の証明書に限定した標的型攻撃(APT:Advanced Persistent Threat)の事例も多数確認することが可能です。QAKBOTは数年に渡って断続的に、正規の証明書を複数回に渡って取得してきました。
QAKBOTが用いる証明書の種類
図1の例に該当する検体を調査した結果、チェコ共和国のマイクロカンパニーが関与していることが分かりました。本証明書に登録されたメールアドレスはフリーメールのものであり、同じメールアドレスが他の証明書にも登録され、不正使用されていました。
特に不審な点は、証明書が付与されたのと同じタイミングで、メールアドレスのドメイン名に対して新しいIPアドレスが付与されたことです。また、当該ドメイン名からは、対象の会社に関連するコンテンツは一切ホストされていませんでした。以上を踏まえると、当該証明書の発行手続きにおいては、通常とは異なる特異な事象が介入したものと考えられます。
これは、ただ1つの証明書発行機関に限った問題ではありません。上記とは別の発行機関からイギリスのマイクロカンパニーに発行された証明書についても、不正使用が確認されました。
不正使用された証明書の出所
不正使用された証明書の出所について、現時点では断定できませんが2つの可能性が考えられます。
第一に、QAKBOTは証明書や秘密鍵を列挙してダンプする技術を持っています。そのため、ユーザが証明書の発行に際して鍵データ生成用のハードウェアトークンを使用しない場合、これらの情報がQAKBOTに窃取されるパターンが考えられます。QAKBOTのモジュールを分析したところ、秘密鍵をダンプ可能なAPI「PFXExportCertStore()」などが使用されていました。
また、QAKBOTは攻撃用ツール「Cobalt Strike」を使用することがありますが、このツールにも、証明書や秘密鍵をダンプ可能な「Mimikatz」が組み込まれています。しかし、QAKBOTが実際に秘密鍵のダンプを積極的に行っていたかどうかは、依然として不明です。
第二に、不正使用された証明書は、技術分野とは関係の薄いマイクロカンパニーに対して発行されていました。証明書の発行手続き自体が不正使用される状況の一例として、なりすましが挙げられます。不正使用された証明書の内容から判断すると、攻撃者は正規の会社や組織になりすまし、公式に信頼されるCAから証明書を直接受け取ったように見受けられます。
この他、農業関係の会社に発行された証明書も発見されました。実際にこの会社がビジネス目的で証明書を受け取った可能性も、考えられなくはありません。しかし、別の可能性として、攻撃者が当該の会社情報を盗み出し、なりすましによって証明書発行の手続きを不正使用することで、公式に信頼されるCAから証明書を直接受け取ったことも考えられます。
ユーザの秘密鍵を保護する方法
今回の事例では、攻撃者がユーザから秘密鍵を盗み出したというよりは、証明書発行の手続き自体を不正に行って証明書を直接受け取った可能性が高いと考えられます。しかし、ユーザによる秘密鍵の保護は、依然として大きな課題の1つと言えます。
ユーザ側でコード署名証明書の秘密鍵を保護する取り組みも、時間をかけて進歩し、改善してきました。しかし依然として、誰にとっても安全と言うには不十分な状況にあります。
先に挙げたQAKBOTが使用するAPI「PFXExportCertStore()」は、秘密鍵がWindows証明書ストア上にエクスポート可能なフラグがついた状態で格納されている場合にのみ、それを窃取することが可能です。言い換えると、鍵データが一定の基準を満たすハードウェアトークン(ICカード、HSM:Hardware Security Manager、TPM:Trusted Platform Moduleなど)によって生成される場合、当該APIを用いても秘密鍵の窃取や再利用はできなくなります。これは、秘密鍵がWindows証明書ストアではなく、トークン内に格納されるようになるためです。
コード署名証明書の要件を定義したドキュメントとして、「Baseline Requirements for the Issuance and Management of Publicly-Trusted Code Signing Certificates(v.3.1)」が挙げられます。証明書を発行するCAはこの要件に従い、ユーザに対して基準を満たすトークンによって秘密鍵を保護するように、推奨することが求められます。また、2022年11月15日までに、CAは、ユーザに対して基準を満たすハードウェアトークンを用いて秘密鍵を保護するように、推奨しなければなりません。さらに、ユーザ側からも、秘密鍵を保護する旨の意思表明も得なければなりません。意思表明の具体的な内容は、認証されたハードトークンを使用するか、少なくとも署名作業を行わない期間中は鍵データを端末から物理的に隔離するといった対策を取ることです。
コード署名証明書を販売する企業が鍵データをどのように提供しているかについて調べたところ、現状では多くの場合、リモートからの窃取が困難なスマートカードやその他ハードウェアに格納する形で配布していることが分かりました。
一般にハードウェアを用いた鍵生成が安全であることは広く理解されていますが、ソフトウェアによる鍵生成方式も、PKCS#12形式で容易にバックアップを取れることや、ハードウェアトークンを使用する手間を省けるといったユーザ目線での簡便性があることから、依然として使用される傾向にあります。CAの中には、今日もこうしたソフトウェア方式を選択肢の1つとして提供し続けているものも存在します。最終局面での取れる対策として、ユーザが鍵データをトークンにインポートしてオフライン状態に保っておけば、その鍵はユーザの手の内に留まり、外部からのアクセスはできなくなるでしょう。
上述の攻撃が続いている状況を踏まえると、鍵生成や証明書発行の方法について再考することも必要です。2022年11月15日より、前述の基本要件「Baseline Requirement」では、秘密鍵の保護に関してより強い条件が課せられるようになります。この要件によると、CAは当該日以降、ユーザの秘密鍵が適格なハードウェアで生成されることを保証しなければなりません。これは、最終局面の対策がユーザ自身の手に委ねられていた状況と比べると、確かな前進と言えます。しかし、秘密鍵をソフトウェアに保管する状況を目にしなくなるまでには、もうしばらく時間を要する可能性があります。
WebPKIの状況
ここまで、なりすましなどによってコード署名証明書の発行手続きが不正使用される可能性について解説しました。攻撃者が実在する会社や組織になりすまして証明書を直接受け取るシナリオは、コード署名に限らず、HTTPS通信に必要なTLS証明書をWebPKI(Webの公開鍵基盤:Web Public Key Infrastructure) 経由で取得する場合にも当てはまります。
WebPKIでは、証明書の透明性(CT:Certificate Transparency)という仕組みが2015年に導入されました。これにより、公式に信頼されるHTTPS用のサーバ証明書が発行された際には、その履歴が全てCTログ上に公開されるようになりました。この履歴はインターネット上から誰でも参照可能なため、ドメイン名の所有者が気づかない間に、その証明書が第三者によって不正に申請、取得されるような事態を検知しやすくなりました。
以上のようにWebPKIではCTログを用いることで、会社や組織に対する想定外な証明書の発行を監視することが可能です。しかし、コード署名証明書についてはCTの仕組みが導入されていないため、WebPKIと同じ方法での監視はできません。
証明書の取り消し
発行済み証明書が不正使用される問題への対処法として、当該証明書の取り消しが挙げられます。
しかし、Doowon KimとBum Jun Kwonによる2018年の調査「The Broken Shield: Measuring Revocation Effectiveness in the Windows Code-Signing PKI」によると、仮にコード署名証明書が取り消されたとしても、すでに作成された署名については有効なものとして機能し続ける可能性があります。これは、取り消しや認証方法の仕様によるものであり、仕組み上の課題と言えるでしょう。
なお、今回不正使用が確認された証明書については、現時点で全て取り消されています。
コード署名証明書の不正使用への対策
ユーザが実施できること:
第一に、秘密鍵を保護してください。コード署名担当の方は、秘密鍵の保管に関する新しいベストプラクティスの実践を推奨します。秘密鍵は適切なハードトークンに保管の上、実際に署名処理を開始するまではオフライン状態に保つことも重要です。最近では、クラウド上で秘密鍵の保管や署名を行うサービスも提供されています。
第二に、自身の識別情報や身分情報を保護してください。今回不正使用された証明書の出所は現状では不明ですが、攻撃者は被害者の全く知らない会社名になりすまし、発行された証明書を不正使用した可能性が考えられます。こうした事態を想定すると、なりすましに繋がるようなことが身の回りで起きていないかどうか警戒することは必須と言えるでしょう。状況の解明には時間を要しますが、証明書の発行機関が原因調査を進める中、ユーザ側でも自身を守るように行動することが、証明書の不正使用による被害を回避する上で重要です。
今回の攻撃者は、実在する会社と類似するドメイン名を事前に取得し、そのドメイン名を保有する事実を利用することで、証明書の発行に至らせた可能性があります。しかし、WebPKIに存在するCTの仕組みがコード署名証明書に存在しないため、この点について効率的に検証することは、現状では難しいでしょう。
信頼性を利用した手口の検知と監視
セキュリティチームは、信頼性が不正使用されている状況に注意することを推奨します。有効なコード署名があるだけでモジュールが無害なものと断定することはできません。正規のモジュールになりすましたマルウェアではないことを確認するためにも、証明書の内容についてより一方踏み込んだ調査を行うことが、有効な対策の1つとして挙げられます。
今回不正使用された証明書には、下記の特徴が見られました。
- 技術分野と無関係な会社名が見られた
- 世界各地のマイクロカンパニーに対して発行されていた
- フリーメールのメールアドレスが登録されていた
- メールアドレスのドメインが会社名のように見えるが、そのドメインからはいかなるコンテンツもホストされていなかった
- ドメイン名のトップレベルドメイン部が、企業としてはやや稀な「co」となっていた
- 証明書の発行直前にIPアドレスが付与された
幸い、こうした証明書の不審な点は、注意深い観察によって検知可能です。
結論およびトレンドマイクロのソリューション
QAKBOTは侵略的なマルウェアとしてさらなる進化を遂げようとしています。有効なコード署名の利用により、不正なファイルの識別はより一層困難なものとなります。また、標的端末への侵入状態が永続化することで、当該端末が接続しているネットワーク自体が深刻な被害のリスクに晒されます。一方で、証明書の発行側でもこうした脅威への対策を進めています。
QAKBOTの感染がExcelファイルから始まることを踏まえ、Microsoftアプリケーションのマクロ無効化についてご検討ください。なりすましメールへの対策として、送信者情報やフォーマットを確認することを推奨します。また、メール監視機能を備えた「Trend Micro Deep Discovery」を用いることで、より一層のセキュリティ確保が可能です。QAKBOTは.DLLファイルからドロップされるため、エンドポイント側では「Trend Micro Vision One」を用いることで、永続化活動の兆候を検知することが可能です。
侵入の痕跡(Indicators of Compromise、IoC)
侵入の痕跡(IoC)はこちらで確認してください。
参考記事:
Where is the Origin?: QAKBOT Uses Valid Code Signing
By: Hitomi Kimura
翻訳:清水 浩平(Core Technology Marketing, Trend Micro™ Research)