【セキュリティ警告】.aws/credentialsとkubeconfigを狙うLinuxマルウェア「QLNX」— インフラエンジニアが今すぐすべき認証情報防衛策

AWS

この記事の概要

2026年5月、Linuxを標的とした高度なRAT型マルウェア「Quasar Linux RAT（QLNX）」が発見された。.aws/credentials・.kube/config・Terraformトークンなど、インフラエンジニアが日常的に扱う認証情報ファイルを狙い、クラウド環境全体への侵入口になり得る。本記事ではQLNXの脅威の全貌と、今日から実施できる具体的な防衛策を解説する。

DevOps環境は今やサプライチェーン攻撃の最重要標的になっている

ひとりのDevOpsエンジニアのノートPCには、組織全体のインフラへのアクセスキーが集中している。.aws/credentialsにはAWSの全権限が、.kube/configには本番Kubernetesクラスタへの管理者アクセスが、Terraformの認証情報にはインフラ変更の自動化パイプラインがある。

Trend Microが2026年5月8日に公開したレポートによると、「Quasar Linux RAT（QLNX）」と名付けられた新型Linuxマルウェアは、これらの認証情報ファイルを系統的に収集し、攻撃者に送信する。一度でもエンジニアのPCに侵入すれば、クラウドインフラへの侵入、プライベートリポジトリへのアクセス、NPM/PyPIへの不正パッケージ公開まで可能になる。

これはセキュリティチームだけの問題ではない。インフラエンジニア全員が自分のPCを「攻撃の起点」として認識しなければならない時代が来ている。

QLNXが検知困難な理由 — ステルス技術の多重構造

QLNXが特に危険なのは、単一の機能ではなく複数のステルス技術が組み合わさっている点だ。

メモリ常駐・ファイルレス実行

QLNXはディスクに実体ファイルを残さず、メモリ上で動作する。起動後はすぐにディスクから自身を消去するため、従来のアンチウイルスによるシグネチャ検知が機能しない。プロセス名はkworkerやksoftirqdなどのLinuxカーネルスレッドに偽装され、psコマンドで見ても一見正常なプロセスに見える。

二層構造のルートキット

QLNXは2種類のルートキットを使い分ける。

  • ユーザーランドルートキット：Linuxの動的リンカ機能LD_PRELOADを悪用し、ls・ps・netstatなどの標準コマンドの出力から自身のプロセス・ファイル・ポートを隠蔽する
  • カーネルレベルのeBPFコンポーネント：BPFサブシステムを使い、C2サーバーからの指示に応じて動的に隠蔽対象を制御する

7種類の永続化機構

感染後、再起動しても復活できるよう、systemdユニット・crontab・.bashrcへのシェルインジェクションなど7種類の永続化手段を並行して設定する。一つを発見・削除しても他の手段で生き残る設計になっている。

PAMバックドア

さらに悪質なのが、認証モジュール（PAM）へのフック挿入だ。SSHログインなどの認証イベント時に平文パスワードを横取りし、C2サーバーに送信する。動的リンクされた全プロセスに自動注入されるため、認証を行うあらゆるサービスが影響を受ける。

実際にQLNXが狙うファイルと、今日から始められる防衛策

QLNXが収集する認証情報ファイル一覧

~/.aws/credentials          # AWSアクセスキー・シークレット
~/.aws/config               # AWSリージョン・プロファイル設定
~/.kube/config              # Kubernetesクラスタ接続設定
~/.docker/config.json       # Dockerレジストリ認証情報
~/.vault-token              # HashiCorp Vault認証トークン
~/.terraform.d/credentials.tfrc.json  # Terraform Cloud認証情報
~/.config/gh/hosts.yml      # GitHub CLI認証トークン
~/.git-credentials          # Gitリポジトリ認証情報
~/.npmrc                    # npm認証トークン（パッケージ公開権限）
~/.pypirc                   # PyPI認証情報（パッケージ公開権限）
~/.env                      # 環境変数ファイル（APIキー等）

これらのファイルのいずれか一つが漏洩しただけで、組織のインフラ全体が危険にさらされる。

実装例：認証情報の保護強化

1. AWS認証情報をIAM Identity Centerに移行する

.aws/credentialsに長期的なアクセスキーを保存する方法は最もリスクが高い。AWS IAM Identity Center（旧AWS SSO）を使えば、一時的な認証情報のみをローカルに保存できる。

# IAM Identity Centerのセットアップ
aws configure sso
# → SSOスタートURL、SSOリージョン、アカウントID、ロール名を設定

# 一時認証情報の取得（有効期限あり）
aws sso login --profile myprofile

# 認証情報の確認（一時トークンであることを確認）
aws configure list --profile myprofile

2. kubeconfig の権限を最小化する

本番クラスタのkubeconfigをローカルに常時保存しない運用を徹底する。

# kubeconfig の権限確認
ls -la ~/.kube/config
# → 600（自分のみ読み取り可）になっているか確認

# 不要なコンテキストを削除
kubectl config delete-context 本番クラスタ名

# 本番作業時のみ一時的に切り替える（作業後は削除）
export KUBECONFIG=/tmp/prod-kubeconfig-$(date +%s)
aws eks update-kubeconfig --name prod-cluster --kubeconfig $KUBECONFIG
# 作業完了後
rm -f $KUBECONFIG

3. inotifywait で認証情報ファイルへのアクセスを監視する

# inotify-toolsのインストール（Ubuntu/Debian）
sudo apt install inotify-tools

# 認証情報ディレクトリの監視スクリプト
cat << 'EOF' > /usr/local/bin/watch-credentials.sh
#!/bin/bash
inotifywait -m -r ~/.aws ~/.kube ~/.docker \
  -e access -e modify -e open \
  --format '%T %w%f %e' \
  --timefmt '%Y-%m-%d %H:%M:%S' \
  2>/dev/null | while read line; do
    echo "[ALERT] $line" | tee -a /var/log/credential-access.log
    # Slackやメールへの通知を追加する場合はここに記述
done
EOF
chmod +x /usr/local/bin/watch-credentials.sh

実務での活用シナリオ

複数のAWSアカウントを管理するインフラチームであれば、各エンジニアのPCに長期的なIAMアクセスキーを配布する運用を廃止し、IAM Identity Center経由の一時認証情報に移行することが最優先だ。Terraform実行環境はローカルPCではなくCI/CDパイプライン（GitHub ActionsやGitLab CI）に移し、OIDC経由でAWSに認証させることで、エンジニアのPCに認証情報を保存しない設計が実現できる。

今すぐ実施すべき認証情報管理の3ステップ

Trend Microの分析によれば、QLNXの感染経路はまだ特定されていないが、マルウェアの設計は「侵入後の被害を最大化する」ことに特化している。感染を防ぐことが第一だが、「侵入されても被害を最小化する」設計も同様に重要だ。

ステップ1：長期認証情報のローテーションと棚卸し

まず既存のIAMアクセスキーを全て棚卸しし、90日以上使われていないキーを無効化する。AWSならAWS Config RuleやAccess Advisorで未使用キーを特定できる。

# 90日以上アクセスのないIAMキーをリストアップ
aws iam generate-credential-report
aws iam get-credential-report --output text --query Content \
  | base64 -d \
  | awk -F',' '$NF != "N/A" && $NF < "'$(date -d '-90 days' +%Y-%m-%d)'"'

ステップ2：Gitシークレットスキャンの導入

認証情報が誤ってGitリポジトリにコミットされていないか確認する。

# gitleaksのインストールと実行
brew install gitleaks  # macOS
# または
wget https://github.com/gitleaks/gitleaks/releases/latest/download/gitleaks_linux_x64.tar.gz

# リポジトリ全体のスキャン
gitleaks detect --source . --report-format json --report-path gitleaks-report.json

ステップ3：エンドポイントにおけるファイルアクセス監視の設定

Falco（Kubernetesワークロード向け）やauditdを使い、認証情報ファイルへの予期しないアクセスをリアルタイムで検知する。

# Falcoルール例：.aws/credentialsへの不審なアクセスを検知
- rule: AWS Credentials Access by Unexpected Process
  desc: Alert when .aws/credentials is accessed by a non-AWS CLI process
  condition: >
    open_read and
    fd.name contains ".aws/credentials" and
    not proc.name in (aws, aws_completer, terraform, packer)
  output: >
    Suspicious access to AWS credentials
    (user=%user.name command=%proc.cmdline file=%fd.name)
  priority: CRITICAL
  tags: [credential_access, aws]

まとめ

QLNXは「インフラエンジニアのPCが最も価値の高い侵入口である」という事実を改めて突きつけている。7種類の永続化機構と二層ルートキットを持つこのマルウェアは、従来の検知手法では発見が難しい。

根本的な防衛策は「ローカルPCに認証情報を長期保存しない設計」への移行だ。AWS IAM Identity Center、HashiCorp Vault、CI/CDパイプラインでのOIDC認証を組み合わせることで、エンジニアPCが侵害されても被害を限定的に抑えられる。感染後の検知には、inotifywaitやFalcoによるファイルアクセス監視が有効な第一歩となる。

自分のPCには何の認証情報ファイルが存在するか、今すぐ確認してほしい。

参考リンク

コメント