Axiosに対するサプライチェーン攻撃がNPMから悪意ある依存関係を引っ張る

概要

悪意のあるnpmパッケージ、 plain-crypto-js@4.2.1は公開され、その後広く使用されているJavaScript HTTPクライアントAxiosの脆弱なリリースを通じて、推移的な依存関係として取り込まれました。このパッケージは、ポストインストールスクリプトを使用してWindows、macOS、Linuxをターゲットにした多段階のリモートアクセス型トロイを提供します。この攻撃は長期間有効なnpmトークンに依存しているようで、脅威アクターがプロジェクトの通常のリリースワークフローの外で悪意のあるバージョンをプッシュすることを可能にしていました。改ざんされた依存関係を早期に検出することで、影響を受けたシステムでのRATの実行を防ぐことができます。

調査

Socket Researchは、 setup.js ドロッパーの静的解析とエンコードされた文字列をデコードして、C2ドメイン、ペイロード配信ロジック、および標的とするファイルシステムパスを暴露しました。研究者たちは、3つの脆弱なAxiosバージョンと、同じ悪意のあるコードを含む2つの追加のnpmパッケージを特定しました。また、検出エンジニアリングとルールの作成に使用できるネットワークインジケータ、ファイルパス、ユーザーエージェント文字列を抽出しました。

緩和策

組織は、長期間有効なnpmトークンを無効化し、潜在的に影響を受けるアカウントの資格情報を回転させるべきです。脆弱なAxiosバージョンと、 plain-crypto-js@4.2.1 に依存しているパッケージはすぐに削除またはダウングレードされるべきです。チームはまた、ロックファイル、CI/CDパイプライン、ソフトウェアサプライチェーンのセキュリティコントロールを確認して、無許可の公開活動を特定し将来のパッケージの侵害の機会を減少させるべきです。

対応

セキュリティチームは、 plain-crypto-js@4.2.1 および影響を受けたAxiosバージョンへの参照をnpmインストールログで監視するべきです。ポストインストールフックの実行や、 sfrclak.comへのネットワークアクセス、悪意のあるユーザーエージェント文字列を対象とした検出ルールを作成するべきです。侵害が確認された場合、影響を受けたシステムは隔離され、分析のために揮発性メモリを収集し、RATが発見された場合にはホストを再イメージする必要があります。

シミュレーションの実行

前提条件: テレメトリ＆ベースラインの事前チェックが合格する必要があります。

根拠: このセクションでは、検出ルールをトリガーするように設計された具体的な敵の技術（TTP）の実行を詳述します。コマンドと物語は、特定されたTTPを直接反映し、検出ロジックが期待する正確なテレメトリを生成することを目的とする必要があります。

• 攻撃の物語とコマンド:

  制限されたユーザー権限を持って妥協された作業環境での攻撃者は、正規のnpmパッケージを介して悪意のあるVBScriptペイロードをダウンロードしたいと考えています（供給チェーンのシナリオ）。一般的なPowerShell検出を避けるため、攻撃者は powershell.exe を新しいファイルにコピーします powershell_renamed.exe ただし、ファイル名に「powershell」というサブストリングを保持しています （したがって、 Image|contains チェックがまだ一致します）。その後、攻撃者は「where powershell」検索を実行してリネームされたバイナリのパスを列挙し、最終的には悪意のあるVBScriptペイロードを cscript //nologo を使用してシンプルに起動し、ロゴバナーを抑制します。

• 回帰テストスクリプト:

  # -------------------------------------------------
  # ステップ1: powershell.exeのリネームコピーを作成
  # -------------------------------------------------
  $src = "$env:SystemRootSystem32WindowsPowerShellv1.0powershell.exe"
  $dst = "$env:Temppowershell_renamed.exe"
  Copy-Item -Path $src -Destination $dst -Force
  
  # -------------------------------------------------
  # ステップ2: 'where'を使用してリネームされたバイナリを参照
  # -------------------------------------------------
  $whereOutput = & where.exe powershell_renamed
  Write-Host "リネームされたPowerShellを次の場所で見つけました: $whereOutput"
  
  # -------------------------------------------------
  # ステップ3: 簡単な悪意のあるVBScriptペイロードを作成
  # -------------------------------------------------
  $vbsPath = "$env:Tempmalicious.vbs"
  @"
  Set objShell = CreateObject("WScript.Shell")
  objShell.Run "cmd.exe /c echo pwned > $env:Temppwned.txt", 0, False
  "@ | Set-Content -Path $vbsPath -Encoding ASCII
  
  # -------------------------------------------------
  # ステップ4: cscript //nologoを使用してVBScriptを静かに実行
  # -------------------------------------------------
  & $dst -Command "cscript //nologo `"$vbsPath`""
  # -------------------------------------------------
  # シミュレーション終了
  # -------------------------------------------------

• クリーンアップコマンド:

  # リネームされたPowerShellバイナリを削除
  Remove-Item -Path "$env:Temppowershell_renamed.exe" -Force -ErrorAction SilentlyContinue
  
  # 悪意のあるVBScriptファイルを削除
  Remove-Item -Path "$env:Tempmalicious.vbs" -Force -ErrorAction SilentlyContinue
  
  # 実行の証拠を削除
  Remove-Item -Path "$env:Temppwned.txt" -Force -ErrorAction SilentlyContinue