この記事の概要
2026年5月、Trend Microが「Quasar Linux RAT（QLNX）」という新種のLinuxマルウェアを詳細公開しました。
このRATはインフラエンジニアのワークステーションを標的にし、~/.aws/credentials・~/.kube/config・~/.docker/config.json などクラウドインフラ操作に直結する認証情報を窃取します。
日本語解説はほぼゼロ。本記事では仕組みと検出・防御の手順を解説します。
あなたのLinuxマシンの~/.aws は今この瞬間も狙われている
突然ですが、あなたのLinuxワークステーションには何が入っていますか？
~/.aws/credentials、~/.kube/config、~/.docker/config.json、~/.vault-token、.env ファイル……。
インフラエンジニアなら、手元の開発機にこれらのファイルが当たり前のように存在しているはずです。
便利だから仕方ない、でも実はこの「当たり前」が、2026年のセキュリティ界で最もホットな攻撃ターゲットになっています。
2026年5月、Trend Microが公開した詳細レポートで「Quasar Linux RAT（QLNX）」の全容が明らかになりました。
これは、インフラエンジニアやDevOpsエンジニアのマシンを狙い撃ちするように設計された、前例のないLinux専用のリモートアクセストロイの木馬です。
感染したマシンは、攻撃者の踏み台に変わります。
あなたのAWS認証情報からS3バケットや本番DBへのアクセスが可能になり、kubeconfig経由でKubernetesクラスターが乗っ取られ、docker credentialsからプライベートレジストリに悪意あるイメージが注入されます。
個人の被害で終わらず、会社全体のインフラが侵害される起点になるのです。
インフラエンジニアのPCが「1億円以上の価値がある」理由
なぜ攻撃者はインフラエンジニアのワークステーションを狙うのでしょうか。
理由は単純で、コストパフォーマンスが圧倒的に良いからです。
一般的なエンジニアのLinuxマシンには、次のような「鍵の束」が格納されています。
~/.aws/credentials— 本番・ステージング・開発環境のAWSアクセスキー~/.kube/config— クラスター管理者権限を持つKubernetes認証情報~/.docker/config.json— Docker Hub・ECR・GHCRのログイントークン~/.vault-token— HashiCorp Vaultの秘密情報へのアクセストークン- Terraform変数ファイル（
terraform.tfvars）— APIキーやDB接続文字列 - GitHub CLIトークン（
~/.config/gh/hosts.yml）— プライベートリポジトリへのアクセス .envファイル — 各種サービスのAPIキーが平文で保存
これらが一台のマシンに集約されているということは、そのマシン一台を侵害すれば企業インフラ全体への侵入経路を一気に手に入れられるということです。
VPNやファイアウォールの外側にある開発機を経由することで、ネットワーク境界防御も無意味化されます。
Trend Microのレポートによれば、QLNXはこうした高価値ファイルをインストール直後に自動的にスキャン・収集して外部送信します。
攻撃者が手動操作する前に、あなたのクレデンシャルはすでに相手の手元に届いているのです。
[フロー図: 攻撃経路]
graph TD
A[攻撃者がQLNX配布
npm/pip/Dockerイメージ経由] --> B[開発者マシンに感染]
B --> C[~/.aws/credentials 収集]
B --> D[~/.kube/config 収集]
B --> E[~/.docker/config.json 収集]
B --> F[~/.vault-token 収集]
B --> G[/etc/ld.so.preload にルートキット注入]
C --> H[攻撃者サーバーに送信]
D --> H
E --> H
F --> H
H --> I[AWSインフラ・K8sクラスター侵害]
H --> J[サプライチェーン攻撃の起点に]
QLNXが実際にどう動くのか — 7つの持続化機構とデュアルレイヤールートキット
QLNXは単純なクレデンシャルスティーラーではありません。
Trend Microが「フルフィーチャードLinux RAT」と呼ぶほど、技術的に洗練された構造を持っています。
主な機能を整理してみましょう。
感染の起点：ソフトウェアサプライチェーン
QLNXの初期感染経路はnpmパッケージ・PyPIパッケージへの混入、または悪意あるDockerイメージです。
開発者が日常的に使うツールに紛れ込んでいるため、「怪しいリンクを踏まない」という防御が機能しません。
デュアルレイヤールートキット：発見を極めて困難にする仕組み
QLNXが厄介なのは、2層構造のルートキットで自身の存在を隠蔽する点です。
第1層 LD_PRELOAD フック: ターゲットマシン上でgccを使ってルートキット用の共有ライブラリをコンパイルし、/etc/ld.so.preload に登録します。
これにより、すべての動的リンクプログラムの関数呼び出しを傍受できます。
ls・ps・netstat などの一般コマンドからも自身のプロセスやファイルを隠蔽します。
第2層 eBPF ルートキットコントローラー: カーネルレベルのeBPFを活用してBPFマップを管理し、ネットワークトラフィックの監視・制御を行います。
通常のプロセス一覧には現れません。
PAMバックドア：SSHパスワードを全て記録する
さらに、/etc/pam.d/ 経由でPAMモジュールとしても自身を注入します。
これにより：
- SSHログイン時のパスワードをすべて平文で記録
- マスターパスワードによる認証バイパス（攻撃者が直接ログイン可能）
- アウトバウンドSSHセッションのデータ収集
58コマンドのRAT機能と7つの持続化機構
感染後は58種類のコマンドを受け付けるフルRATとして機能します。
ファイル操作・スクリーンショット取得・クリップボード監視・ネットワークトンネリングなど、攻撃者がリモートから何でもできる状態になります。
また、7つの独立した持続化機構（systemdユニット・cronジョブ・ld.so.preload・PAM・~/.bashrc・~/.profile・ネットワーク設定）を持つため、一つを削除しても他の経路から復活します。
感染確認コマンドとauditd監視の設定
今すぐできる感染確認コマンド（要root権限）:
# 1. /etc/ld.so.preload の確認（正常なシステムでは空か存在しない）
cat /etc/ld.so.preload 2>/dev/null && echo "WARNING: ld.so.preload が設定されています！"
# 2. 予期しない共有ライブラリのロードを確認
ldd /bin/ls | grep -v "linux-vdso\|libc\|ld-linux"
# 3. PAM設定の不審なモジュールを確認
grep -r "\.so" /etc/pam.d/ | grep -v "^#" | grep -v "pam_"
# 4. 不審なsystemdユニットの確認
systemctl list-units --type=service --state=active | grep -v "\.service$"
# 5. 認証情報ファイルへの最近のアクセスを確認
find ~ -name "credentials" -o -name "config" -path "*/.kube/*" \
-o -name "config.json" -path "*/.docker/*" \
| xargs ls -la 2>/dev/null
# 6. eBPFプログラムのリスト（root権限が必要）
bpftool prog list 2>/dev/null | head -20
クレデンシャルファイルへの異常アクセスを監視するauditdルール:
# auditdで認証情報ファイルへの読み取りを監視
sudo auditctl -w /home -k credential_access -p r
sudo auditctl -w /root/.aws -k aws_credential_access -p r
sudo auditctl -w /root/.kube -k kube_credential_access -p r
# アラートの確認
sudo ausearch -k aws_credential_access --start today
実務での活用シナリオ：感染後の初動対応
もし感染が疑われる場合の対応フローです。
# Step 1: 即座にネットワークを切断（C2通信を遮断）
# → 物理的に or sudo systemctl stop NetworkManager
# Step 2: 揮発性情報の保全（侵害の証跡収集）
sudo ps auxf > /tmp/processes_$(date +%s).txt
sudo netstat -tlnp >> /tmp/network_$(date +%s).txt
sudo cat /etc/ld.so.preload >> /tmp/ldpreload_$(date +%s).txt
# Step 3: 全クレデンシャルのローテーション（マシンより先に実施）
# - AWS: aws iam update-access-key / IAM Identity Centerで再発行
# - Kubernetes: kubectl delete secret / kubeadm certs renew
# - Docker: docker logout && 全レジストリのトークン無効化
# - Vault: vault token revoke -self
# Step 4: マシンのクリーンインストール（パッチ適用では不十分）
# → 7つの持続化機構を全て確実に除去するには再インストールが必要
今日から始めるインフラエンジニアの認証情報保護3ステップ
QLNXへの根本的な対策は「認証情報をファイルシステムに平文で置かない」ことです。
感染されても窃取される情報がなければ被害は最小化されます。
ステップ 1：AWS認証情報をIAM Identity Centerに移行する
~/.aws/credentials に長期アクセスキーを置く運用は今すぐやめましょう。
AWS IAM Identity Center（旧AWS SSO）を使えば、aws sso login による一時的な認証情報のみが使われ、平文キーはマシンに残りません。
# ~/.aws/config に IAM Identity Center プロファイルを設定
[profile my-prod]
sso_start_url = https://my-org.awsapps.com/start
sso_region = ap-northeast-1
sso_account_id = 123456789012
sso_role_name = DeveloperRole
# ログイン（ブラウザ認証、有効期限付き）
aws sso login --profile my-prod
# ~/.aws/credentials に長期キーが書かれていないことを確認
cat ~/.aws/credentials # 空であるべき
ステップ 2：kubeconfig を用途別・有効期限付きに分割する
クラスター管理者権限のkubeconfigを一つのファイルに統合するのは危険です。
KUBECONFIG 環境変数で用途別に分割し、短い有効期限のトークンを使いましょう。
# 用途別にkubeconfigを分割して管理
export KUBECONFIG=~/.kube/prod-readonly.yaml
# EKSの場合、1日有効期限のトークンを使用
aws eks update-kubeconfig \
--name my-cluster \
--kubeconfig ~/.kube/prod-temp.yaml \
--role-arn arn:aws:iam::123456789012:role/EKSReadOnlyRole
# 作業後に削除
shred -u ~/.kube/prod-temp.yaml
ステップ 3：Docker認証情報にcredential storeを使う
~/.docker/config.json にbase64エンコードのパスワードを置くのではなく、OSのキーチェーンやcredential helperを使いましょう。
# macOSの場合：docker-credential-osxkeychain を使用
# ~/.docker/config.json が以下の形式になっていることを確認
{
"credsStore": "osxkeychain"
}
# Linuxの場合：pass（GPGベース）credential helperを使用
sudo apt install pass
docker-credential-pass initialize my-docker-key
まとめ
Quasar Linux RAT（QLNX）は、インフラエンジニアの日常的な作業環境そのものを攻撃ベクタとして設計されたマルウェアです。
ルートキット・PAMバックドア・7つの持続化機構という技術的な洗練度もさることながら、最も恐ろしいのは「日常のツールインストール」から感染するという点です。
対策の核心は3つです。
①長期認証情報をファイルに置かない（IAM Identity Center・credential store）、②/etc/ld.so.preload を定期監視する（auditd活用）、
③感染疑いがあれば認証情報ローテーションをマシン修復より先に行う。
自分のマシンは大丈夫、と思っている方こそ、今日この記事のコマンドを一度走らせてみてください。
コメント