Arch Linux AURで大規模サプライチェーン攻撃「Atomic Arch」──放置パッケージ乗っ取りの手口と検知・防御策

「便利なツールがAURにあったから、yayでサッと入れた」——Arch Linuxユーザーにとって当たり前のこの一手が、2026年6月に発覚した大規模なサプライチェーン攻撃の入口になりました。セキュリティ企業Sonatypeが「Atomic Arch」と名付けたこのキャンペーンは、放置されたAUR（Arch User Repository）パッケージを攻撃者が乗っ取り、インストール時にマルウェアを忍び込ませる手口です。

この記事では、攻撃者の視点から「なぜ放置パッケージが狙われるのか」「どうやって乗っ取られたのか」を分解したうえで、SOCや情シスが取るべき検知・防御のポイントを整理します。具体的なパッチ適用手順そのものより、攻撃手口を理解して自社の検知体制に落とし込むことに軸を置きます。不安を煽るためではなく、正しく知って正しく備えるための解説です。

Atomic Archとは？（概要・なぜ重要か）

Atomic Archは、2026年6月11日にSonatypeが公表した、AURを標的にしたサプライチェーン攻撃の総称です。AURとは、Arch Linuxの公式リポジトリには含まれないソフトウェアを、コミュニティのユーザーが自由に登録・共有できる仕組みのことを指します。yayやparuといったAURヘルパーがこの仕組みを使ってビルド・インストールを自動化するため、Arch系ユーザーには欠かせない存在です。

今回の攻撃で乗っ取られたパッケージ数は、Sonatypeのカウントで初動の第1波が408件。その後の複数波を合わせると、暫定で約1,500件規模に達したと報告されています。一つひとつは小さな個人ツールでも、それだけの数がまとめて汚染されたとなると、影響範囲は無視できません。攻撃者にとっては「広く薄く」感染を広げられる効率の良い標的だったわけです。

なぜこれが重要なのか。サプライチェーン攻撃の怖さは、利用者が「信頼している入手経路」そのものが汚染される点にあります。怪しいサイトから野良バイナリを落としたわけではなく、いつも使っているAURから、いつもの手順でインストールしただけ。それでもマルウェアが入り込む——この「正規ルートの汚染」こそが、従来のウイルス対策の発想では捉えにくい脅威です。

攻撃の仕組み——放置パッケージの「引き取り」を悪用する

攻撃者の視点で手口を見ると、その狡猾さがよくわかります。鍵になったのは、AURに備わっている「adoption（引き取り）」という正規の制度でした。

AURのパッケージは、元のメンテナが管理をやめると「orphaned（放置状態）」になります。コミュニティ運営の仕組みとして、放置されたパッケージは別のユーザーが引き取って管理を引き継げるようになっています。本来は善意の引き継ぎを想定した制度です。攻撃者はこの制度を逆手に取り、放置されたパッケージの所有権を次々と要求して掌握しました。アカウントを不正に乗っ取ったのではなく、用意された正規の手続きを悪用した点がポイントです。

所有権を握ったあと、攻撃者が改ざんしたのが PKGBUILD です。PKGBUILDとは、AURパッケージのビルド手順を記述したスクリプトで、yayやparuはこれを読み込んでインストールを実行します。攻撃者はこのPKGBUILDに、インストール時に悪意あるnpmパッケージを取得する処理を仕込みました。Sonatypeが確認した悪性npmパッケージは atomic-lockfile（主体）、js-digest、lockfile-js の3つです。利用者がパッケージをビルドした瞬間、これらが裏で引き込まれる構造でした。

ここで攻撃者視点の「効率の良さ」を整理しておきます。放置パッケージは元から信頼の蓄積（過去のインストール実績やコメント）があるため、利用者が警戒しにくい。しかも引き取り制度を使えば、不正アクセスのような派手な侵入の痕跡を残さずに所有権を得られる。手の込んだゼロデイを開発するより、「正規の入口を静かにすり替える」ほうが圧倒的に低コストなのです。

なお本記事は防御を目的に手口の構造を解説しています。具体的な悪用コードや再現手順は扱いません。どこから入り込むかの「経路」を知ることが、検知設計の出発点になるという立場です。

ビルド時に実行される、という見落としやすい盲点

もう一つ攻撃者が突いたのが、「パッケージのインストール＝ビルドスクリプトの実行」というAURの特性です。公式リポジトリのバイナリと違い、AURは手元でPKGBUILDを実行してビルドします。つまりインストールの過程で任意の処理が走りうる。利用者が「インストールしただけ」のつもりでも、その裏でスクリプトが外部から別のコードを引き込めるわけです。この「実行を伴う入手」という性質が、サプライチェーン攻撃の温床になりました。

ペイロードの正体——eBPFルートキットと認証情報の窃取

乗っ取られたパッケージをビルドした端末には、何が仕込まれたのか。Sonatypeの分析によれば、投下されたのは eBPFベースのrootkit（ルートキット） でした。ルートキットとは、自身の存在をOSから隠しながら居座り続けるタイプのマルウェアを指します。

厄介なのは、このルートキットがカーネルレベルで動く点です。Sonatypeは、特定のプロセスやファイル、ソケットを一覧から隠す挙動（hidden_pids / hidden_namesといった隠蔽リストや、ディレクトリ列挙のgetdents64へのフック）や、デバッガによる解析を検知して妨害する仕組み（PTRACE系の検知）を確認しています。つまり「動いていることに気づかせない」「調べようとすると逃げる」という、防御側のレーダーを潜り抜ける設計です。

さらに、このマルウェアは認証情報の窃取機能を備えていました。Sonatypeが挙げた標的には、SSH鍵、GitHubの認証情報、HashiCorp Vaultのトークン、ブラウザのCookieデータベース、Slack・Discord・Microsoft Teams・Telegramといった認証情報が含まれます。開発者の端末を踏み台に、社内のリポジトリやシークレット管理へ横展開する——攻撃者にとって、開発者環境はまさに「鍵束」だったわけです。

項目	Atomic Archでの内容
キャンペーン名	Atomic Arch（命名: Sonatype）
公表日	2026年6月11日（初動）/ 6月12日に第2波
影響パッケージ数	第1波408件 / 複数波合計で約1,500件規模（暫定）
侵入経路	放置AURパッケージの引き取り制度悪用 → PKGBUILD改ざん
悪性npm	atomic-lockfile / js-digest / lockfile-js
ペイロード	eBPFルートキット + 認証情報窃取
識別子 / 深刻度	Sonatype-2026-003775 / CVSS 8.7

表のとおり、CVSSは8.7と高い値が付いています。識別子はSonatype独自のもの（Sonatype-2026-003775）で、執筆時点ではCVE番号は割り当てられていません。CVE番号での管理に慣れていると見落としがちですが、サプライチェーン系の脅威はベンダー独自IDで先に出回ることが多い点も、検知運用では押さえておきたいところです。

SOC・情シスはどう検知するか

では、守る側はこの種の攻撃をどう捉えればいいのか。ポイントは「入手の入口」と「ビルド・実行の挙動」の両面を見ることです。攻撃者がPKGBUILDというビルド手順を改ざんし、ビルド時に外部からコードを引き込んだ以上、ファイルの中身だけを疑うアンチウイルスの発想では取りこぼします。

検知の着眼点を、攻撃の流れに沿って並べます。

・パッケージ管理操作の監視: AURヘルパー（yay / paru）の実行や、その直後に走るnpm install等の不審な外部取得を、エンドポイントのプロセスログで捉える。「インストール中に想定外のパッケージマネージャが動く」のは強い兆候です。
・外部通信の監視: ビルド・インストール時に普段と違う宛先へHTTP POST（データ送信）が発生していないかを見る。認証情報の持ち出しはこの段階で起きます。
・カーネルレベルの異常検知: eBPFルートキットはプロセスやソケットを隠すため、表面的なプロセス一覧との「食い違い」を検知に使う。EDR/監視ツールで観測した実体と、OSが返す一覧の差分が手がかりになります。
・認証情報アクセスの監視: SSH鍵・トークン・ブラウザのCookieストアといった機微なファイルへの想定外アクセスをアラート化する。窃取の起点を押さえる発想です。

クラウド側のシークレット管理（IAMロールやVaultのトークン運用）が絡む場合の検知・分離設計は、姉妹サイトクラウドマスターズ.TOKYOでも扱っています。窃取された認証情報の悪用範囲を絞り込む参考にしてください。

従来の発想と、サプライチェーン時代に必要な発想

整理のために、検知アプローチの違いを並べます。守る対象が「ファイルそのもの」から「入手経路とビルド時の振る舞い」へ移った、と捉えると分かりやすくなります。

観点	従来の発想	サプライチェーン時代に必要な発想
何を疑うか	ダウンロードした実行ファイル	入手経路（リポジトリ）とビルド手順の改ざん
信頼の置き方	有名・実績あるパッケージは信頼	所有者変更・更新内容を都度検証
検知のタイミング	ファイル実行時のスキャン	インストール・ビルド時の挙動監視
隠蔽への備え	プロセス一覧で確認	カーネルレベルの隠蔽を前提に差分検知

Before/Afterで言えば、これまでは「怪しいファイルを見つけて止める」のが中心でした。サプライチェーン時代のAfterでは、「信頼している入手経路が、いつの間にかすり替わっていないか」を継続的に見張る発想に変わります。

SOCの実務に落とすなら、SIEMにエンドポイントのプロセス生成ログとネットワークログを集約し、「AURヘルパーの実行→直後の外部取得→普段と違う宛先への送信」という一連の流れを相関ルールで拾えるようにしておくのが現実的です。単一のイベントだけでは正常な開発作業と区別しにくいぶん、攻撃は「連鎖」として現れます。点で見るのではなく、ビルドからデータ送信までの線で捉える設計が、この種のサプライチェーン攻撃には効きます。EDRを入れている環境なら、カーネルレベルで観測した実体と、OSが返すプロセス一覧の食い違いをアラート条件に組み込んでおくと、隠蔽型のルートキットを炙り出す一手になります。

中小企業・個人開発者でも今日からできること

「大規模な攻撃」と聞くと身構えますが、防御の第一歩は地味な運用です。AURを使う環境なら、まず次の点から手を付けてください。

・PKGBUILDを必ず確認する: AURヘルパーには更新時にPKGBUILDの差分を表示する機能があります。インストール・更新の前に、外部から何かを取得する処理が増えていないか目視する習慣をつける。
・所有者の変更に注意する: よく使うパッケージのメンテナが最近変わっていないかを意識する。放置パッケージが急に更新され始めたら、一度立ち止まる。
・ビルドは隔離環境で: 重要な認証情報を持つ端末で直接ビルドしない。コンテナや使い捨ての環境でビルドし、本番の鍵束と切り離す。
・認証情報を棚卸しする: 万一窃取された場合に備え、SSH鍵・各種トークンを定期的にローテーションし、不要な権限を削っておく。
・ログを残す: パッケージ操作と外部通信の記録を取り、異常を後から追える状態にする。

どれも高価なツールがなくても運用ルールとして始められます。重要なのは「信頼している入手経路ほど、変化を疑う」という姿勢です。今回汚染されたのは、まさに「いつものAUR」でした。

感染が疑われる場合の初動チェックリスト

Atomic Archの影響が気になる場合、以下を点検してみてください。

・最近AURから入れたパッケージの一覧化: 6月以降にインストール・更新したAURパッケージを洗い出しているか。
・npmの想定外導入の確認: atomic-lockfile / js-digest / lockfile-js といった見覚えのない依存が引き込まれていないか。
・認証情報の侵害想定: 当該端末のSSH鍵・GitHubトークン・各種シークレットを「漏れた前提」で無効化・再発行したか。
・外部通信ログの確認: ビルド時に不審な宛先への通信がなかったかをログで確認したか。
・クリーン環境での再構築検討: ルートキットは隠蔽性が高いため、深刻な場合はOS再導入を含めて判断したか。

点検の前提は「ログが残っていること」です。記録がなければ被害の有無すら判断できません。まずは見える化から始めましょう。

よくある誤解と注意点

「Arch Linuxを使っていないから関係ない」という受け止めは、半分は正しく、半分は誤解です。今回の直接の標的はAURですが、「放置されたコンポーネントを引き取って汚染する」「インストール時に外部依存を引き込む」という構造は、npm・PyPI・各種パッケージリポジトリに共通する普遍的なリスクです。エコシステムが違っても、サプライチェーン攻撃の発想は同じだと捉えてください。

もう一点、「AURは危険だから使わない」という極論も現実的ではありません。問題はAURを使うかどうかではなく、入手経路の変化をどう監視するかです。最後に、本記事の数値や主張は2026年6月11日～12日時点の一次・準一次情報に基づきます。影響パッケージ数は調査の進展で変動する可能性があるため、対応判断の際は必ず最新の公式情報をご確認ください。

よくある質問（FAQ）

Q1. Atomic Archは具体的に何を盗むのですか？
Sonatypeの分析では、SSH鍵・GitHubの認証情報・HashiCorp Vaultのトークン・ブラウザのCookie・Slack/Discord/Teams/Telegramの認証情報などが標的とされています。開発者端末の「鍵束」を狙う設計です。

Q2. なぜアンチウイルスで防ぎにくいのですか？
正規の入手経路（AUR）が汚染され、インストール（ビルド）時に外部からコードを引き込む手口だからです。ファイルの中身を照合する従来型スキャンでは、ビルド時の挙動や外部取得を捉えきれません。挙動監視と外部通信の監視が必要になります。

Q3. CVE番号はありますか？
執筆時点ではCVE番号は割り当てられておらず、Sonatype独自の識別子（Sonatype-2026-003775、CVSS 8.7）で管理されています。サプライチェーン系はベンダー独自IDが先行することが多い点に注意してください。

Q4. 影響パッケージ数が記事ごとに違うのはなぜですか？
調査が進む過程で発見数が増えたためです。Sonatypeのカウントでは第1波が408件、その後の複数波を含めると暫定で約1,500件規模と報告されています。今後さらに変動する可能性があります。

Q5. すでに汚染パッケージをビルドしてしまった場合は？
まず当該端末の認証情報を「漏れた前提」で無効化・再発行してください。ルートキットは隠蔽性が高いため、深刻な場合はクリーンなOS再導入を含めて判断します。並行して、ビルド時の外部通信ログを点検し、被害範囲を見積もるのが現実的です。

本記事のまとめ

Atomic Archは、AURの「放置パッケージ引き取り」という正規制度を悪用し、PKGBUILDの改ざんを通じてeBPFルートキットと認証情報窃取マルウェアをばら撒いた、典型的なサプライチェーン攻撃です。第1波408件・複数波で約1,500件規模という広がりと、カーネルレベルで身を隠す巧妙さが特徴で、CVSSは8.7（Sonatype-2026-003775）と高く評価されています。

攻撃者視点で見れば、信頼の蓄積がある放置パッケージは「警戒されにくい入口」です。だからこそ守る側は、ファイルの中身だけでなく「入手経路の変化」と「ビルド・実行時の振る舞い」を監視する発想へ切り替える必要があります。PKGBUILDの差分確認、所有者変更への注意、隔離環境でのビルド、認証情報の棚卸しとログ取得——いずれも特別な投資なしに始められます。正しく知って、自社にできる順番から備えていきましょう。