この記事の概要
2026年5月、DevOpsエンジニアのLinux環境を標的にした新型マルウェア「QLNX（Quasar Linux RAT）」がTrend Microにより発見された。
~/.aws/credentials や ~/.kube/config など日常的に使うファイルを丸ごと窃取し、そのままクラウド環境への侵入やサプライチェーン攻撃に悪用される。
本記事では脅威の実態と、今日から実践できる具体的な防御策をまとめる。
.aws/credentials が今この瞬間も狙われている
「自分の開発PCがマルウェアに感染するとは思っていなかった」——これが多くのエンジニアの正直なところではないでしょうか。
しかし2026年5月、セキュリティ企業Trend Microが発表したレポートは、その油断がいかに危険かを突きつけています。
QLNX（Quasar Linux RAT） は、Linux開発環境に静かに潜り込み、次のファイルを標的にして認証情報を根こそぎ持っていきます。
~/.aws/credentials― AWSへのアクセスキー~/.kube/config― Kubernetesクラスタへの認証情報~/.docker/config.json― DockerレジストリへのAPIトークン~/.vault-token― HashiCorp Vaultのトークン~/.config/gh/hosts.yml― GitHub CLIのトークン~/.git-credentials― Gitリポジトリの認証情報.npmrc/.pypirc― npm/PyPIの公開用トークン.envファイル ― 各種APIキー・シークレット
これらはインフラエンジニアが日常的に使うファイルばかりです。
これが盗まれると、単に「自分のアカウントが乗っ取られる」だけでは済みません。
本番のAWS環境への侵入、KubernetesクラスタへのバックドアPod展開、npmやPyPIへの悪意あるパッケージの公開——つまりサプライチェーン攻撃の踏み台にされる可能性があります。
なぜQLNXはDevOps環境でここまで厄介なのか
QLNXが特に危険な理由は、単体の機能が優れているのではなく、複数の回避技術が連鎖して動作する点にあります。
フィレスで動き、カーネルスレッドに偽装する
QLNXはディスクにファイルを残さず、メモリ上で動作します（フィレス実行）。
さらに、自身のプロセス名を kworker や ksoftirqd といったLinuxカーネルのワーカースレッドに偽装します。
ps aux を眺めても、一見して怪しい何かは見当たりません。
2層のルートキットで隠れ続ける
検出を避けるため、QLNXは2種類のルートキットを持ちます。
ユーザーランドルートキット（LD_PRELOAD）
└── ps, ls, netstat などの標準コマンドの出力を改ざん
→ プロセス・ファイル・ネットワークポートを隠蔽
カーネルレベル eBPF コンポーネント
└── C2サーバーからの指示でカーネル側でも隠蔽
→ より深いレベルで痕跡を消す
eBPF（Extended Berkeley Packet Filter）はもともとカーネルレベルの高度なネットワーク処理や可観測性のために使われる技術ですが、QLNXはその仕組みを悪用しています。
7種類の永続化メカニズム
感染後、QLNXは次の7つの方法でシステムに居座り続けます。
# QLNXが利用する永続化手法（概念的な例）
systemd サービス登録
crontab へのエントリ追加
~/.bashrc へのシェルインジェクション
~/.profile / ~/.bash_profile への追記
LD_PRELOAD による共有ライブラリロード
PAMモジュールへのバックドア埋め込み
/etc/ld.so.preload の改ざん
一度感染すると、単純にプロセスをkillするだけでは除去できません。
PAMバックドアでSSHパスワードも盗む
さらにQLNXは PAM（Pluggable Authentication Module） にバックドアを仕込み、SSH認証時に入力された平文のパスワードを横取りします。
多要素認証を使っていても、ログイン時の認証情報はPAMを通る以上、この攻撃の射程に入ります。
合計58のコマンドで完全制御
C2（Command & Control）サーバーへの通信はTCP・HTTPS・HTTPを切り替えながら行われ、オペレーターは合計58種類のコマンドを使って感染ホストを自由に操作できます。
シェルコマンドの実行、ファイル操作、スクリーンショット取得、キーロギング、SOCKSプロキシの設定、P2Pメッシュネットワークの構築まで——一通りのことは全部できます。
実際に何が起きるのか：LiteLLMサプライチェーン攻撃の事例
「これは海外の話で、自分には関係ない」と思った方に、ぜひ知ってほしい事例があります。
2026年3月に発覚した LiteLLMのサプライチェーン攻撃 は、まさにQLNXが狙うシナリオそのものです。
あるパッケージメンテナーの開発PCが侵害され、盗まれた .pypirc のPyPI公開トークンを使って、1日340万ダウンロードを誇るPythonパッケージにバックドアが仕込まれました。
graph LR
A[開発PCへの初期感染] --> B[.pypirc からPyPIトークン窃取]
B --> C[悪意あるコードをパッケージに注入]
C --> D[PyPIへ公開]
D --> E[340万ダウンロード/日のパッケージ経由で拡散]
E --> F[下流ユーザーの環境も侵害]
一人のエンジニアのPCが感染したことで、そのパッケージを使う何百万ものユーザーが影響を受けました。
OSS開発に関わるエンジニア、特にパッケージを公開している方はひとごとではありません。
具体的なシナリオで考える
たとえばあなたが次の状況にあるとします。
# よくある開発環境の状態
$ cat ~/.aws/credentials
[default]
aws_access_key_id = AKIA...（本番環境のAdminロール）
aws_secret_access_key = xxxxxxxx
$ cat ~/.kube/config
# 本番Kubernetesクラスタへのフルアクセス設定
これがQLNXに盗まれた場合、攻撃者はあなたのAWS本番環境に管理者権限でログインし、EC2インスタンスを立ち上げてクリプトマイニングに使ったり、S3バケットのデータを外部に流出させたりすることができます。
AWSのCloudTrailには「あなたのアクセスキーで操作した」という記録が残ります。
今日からできる5つの防御策
「じゃあどうすればいいのか」——ここからが本題です。
完璧な防御はありませんが、QLNXのような攻撃に対して有効な対策を5つ紹介します。
1. 長期有効なクレデンシャルを廃止する
~/.aws/credentials に書かれた長期アクセスキーは、盗まれたら即アウトです。
# AWS CLIのIAM Identity Center（SSO）へ切り替える
aws configure sso
# または短期クレデンシャルを発行する
aws sts get-session-token --duration-seconds 3600
IAM Identity Centerを使えば、セッションごとに短期トークンが発行され、盗まれてもすぐに失効します。
EC2やLambdaはIAMロールを使い、アクセスキーをファイルに書かないことが原則です。
2. Kubernetesアクセスを最小権限に絞る
# 開発者向けの制限されたRoleの例
apiVersion: rbac.authorization.k8s.io/v1
kind: Role
metadata:
namespace: dev
name: dev-readonly
rules:
- apiGroups: [""]
resources: ["pods", "services"]
verbs: ["get", "list", "watch"]
# exec や create は付与しない
本番クラスタへのフルアクセスを開発者が常時持つ構成は見直しましょう。
Just-in-Timeアクセス（必要なときだけ権限を付与）の仕組みを導入するのが理想です。
3. Git pre-commitフックでシークレットの混入を防ぐ
# git-secretsのインストール（macOS）
brew install git-secrets
# AWSクレデンシャルパターンの検出を有効化
git secrets --register-aws --global
git secrets --install ~/.git-templates/git-secrets
git config --global init.templateDir ~/.git-templates/git-secrets
detect-secrets や gitleaks も同様の目的で使えます。
コミット前に自動検査することで、うっかり .env をコミットするミスを防げます。
4. プロセスの異常を監視する（Falco）
# Falcoルールの例：LD_PRELOADの悪用を検知
- rule: Suspicious LD_PRELOAD
desc: LD_PRELOAD environment variable set in a suspicious context
condition: >
spawned_process and
proc.env contains "LD_PRELOAD" and
not proc.name in (known_preload_programs)
output: >
Suspicious LD_PRELOAD (user=%user.name command=%proc.cmdline
parent=%proc.pname env=%proc.env)
priority: WARNING
Falcoはカーネルレベルでシステムコールを監視し、QLNXが使うLD_PRELOAD経由の共有ライブラリロードや、異常なプロセスのfork/execを検出できます。
5. 定期的なクレデンシャルのローテーションと失効確認
# GitHub CLIトークンの確認・失効
gh auth status
gh auth logout
# npmトークンの確認
npm token list
npm token revoke <tokenId>
# AWSアクセスキーの棚卸し
aws iam list-access-keys --user-name <username>
aws iam delete-access-key --access-key-id <keyId>
使っていないトークンが残っていないか、定期的に棚卸しする習慣をつけましょう。
GitGuardianの2026年レポートによれば、2022年に漏洩した有効なシークレットの64%が2026年現在もまだ失効されていないとのことです。
インフラエンジニアは「ターゲット」であることを自覚しよう
QLNXが示すのは、インフラエンジニアやDevOpsエンジニアの開発PCが「最も価値ある踏み台」になっているという現実です。
一人のエンジニアが持つ ~/.aws/credentials には、場合によっては数十のAWSアカウントへのアクセス権が詰まっています。
攻撃者にとってこれほど効率的なターゲットはありません。
最後にチェックリストとして整理します。
- [ ]
~/.aws/credentialsに長期アクセスキーを書いていないか - [ ] Kubernetesクラスタのアクセス権が必要最小限になっているか
- [ ] コミット前のシークレット検査ツールを導入しているか
- [ ] 使っていないnpm/PyPIトークンを失効させているか
- [ ] Falcoやauditdでシステムコールの異常監視をしているか
- [ ] 本番環境への直接ログインに短期クレデンシャルを使っているか
一つでも「できていない」があれば、今日から対応を始めることをおすすめします。
まとめ
QLNX（Quasar Linux RAT）は、DevOpsエンジニアの開発PC上にある認証情報ファイルを標的に、フィレス実行・多重ルートキット・PAMバックドアを組み合わせた本格的なLinuxマルウェアです。
感染すると検出も除去も難しく、クラウド環境への侵入やOSSサプライチェーン攻撃の踏み台として悪用されます。
対策の基本は「盗まれても使えないクレデンシャル管理」です。
長期アクセスキーの廃止、短期トークンへの移行、git pre-commitフックによる混入防止——難しい技術は不要で、今日からでも始められます。
コメント