CI/CDパイプラインからクラウドへと侵入するソフトウェアワームを特定
提供: フォーティネットジャパン
本記事はフォーティネットジャパンが提供する「FORTINETブログ」に掲載された「CI/CDからクラウドデータへ:Shai Huludによる永続化がRedshiftの侵害へ発展する仕組み」を再編集したものです。
米国時間2026年6月26日に掲載されたフォーティネットブログの抄訳です。
影響を受けるプラットフォーム:Amazon Web Services(AWS)
影響を受けるユーザー :あらゆる組織
影響 :クラウド認証情報が窃取され、重大な経済的損失および機密情報の侵害
深刻度 :高
最新のCI/CDパイプラインを運用する組織は、Shai Huludによるサプライチェーン攻撃の脅威に直面しています。Shai Huludは、2025年後半以降npmおよびPyPIパッケージを標的とし、TeamPCPによるものと判断されているソフトウェアワームです。映画「デューン 砂の惑星」に登場する巨大なサンドワームにちなんで名付けられたShai Huludは、インストール時やCIジョブの実行時に動作する悪意のあるパッケージを埋め込み、ビルド環境の認証情報を収集してクラウドインフラストラクチャへ侵入します。
最新のCI/CD環境を運用している組織は、Shai Huludによるサプライチェーン攻撃を通じて、重要な教訓を突き付けられています。ビルドの依存関係が改ざんされると、CI/CDパイプライン内にとどまらず、本番のクラウド環境へ侵入するための足掛かりとなるのです。
2026年5月、FortiCNAPPは、このワームの影響を受けたAWS環境の特定を支援しました。5月中旬までに、調査担当者は、Shai Huludによる認証情報の収集パターンと一致する、Jenkinsランナーへの継続的なアクセスの証拠を確認しました。調査の結果、運用者がインターネット経由でJenkinsのロールを悪用し、権限を昇格してクラウド管理者の完全な権限を入手し、データベースへのネットワークアクセス制御を変更し、Amazon Redshiftからデータを抽出していたことが判明しました。さらに、オブジェクトストレージやメールサービスを悪用する活動も行っていました。
リーダーにとって重要なポイントは、CI/CDパイプラインのアイデンティティは、そのまま本番環境のアイデンティティとなり得ることです。一方、実務担当者にとっては、着目すべきポイントを押さえていれば、残されている豊富な証跡を利用できます。本ブログでは、CloudTrailおよびホストのシグナルの詳細をもとに、FortiCNAPPが「侵害された可能性のあるキー」というアラートで侵入を検知し、アナリストによるホストおよびクラウドのタイムラインの再構築をどのように支援したのかを解説します。
Shai Huludとクラウドへの脅威
2026年4~5月に発生した「Mini Shai Hulud」キャンペーンでは、Shai Huludワームの検知件数が急増しました。これまでに観測されたインシデントから、以下のような攻撃モデルが繰り返し確認されています。
・悪意のあるパッケージのバージョンが、インストール時またはCIジョブの実行時に動作します。
・ペイロードがビルド環境から認証情報を収集します。収集する対象には、パッケージレジストリのトークン、GitHubトークン、AWSの認証情報、Kubernetesシークレット、SSHキーなどが含まれます。
・窃取した認証情報によって、改ざんされた別のパッケージが自律的に再公開されます。
・最近の亜種では、GitHub Actionsの信頼されたOIDC公開機能を悪用し、ランナーが攻撃者の管理下に置かれていたにもかかわらず、正規の証明を受けたように見えるアーチファクトを生成しています。
CI/CDランナーは、クラウドの攻撃対象領域を急速に拡大する攻撃ベクトルとなっています。Jenkins、GitHub Actions、およびセルフホスト型エージェントには、EC2インスタンスプロファイル、長期間有効なシークレット、データ層へのネットワークアクセス権限などが保持されていることが多くありますが、これらはまさに、Shai Huludが収集している情報です。
タイムライン
| フェーズ | おおよその時期 | 発生した事象 |
| サプライチェーンの侵害 | 2026年5月上旬 | Shai Huludによる活発な攻撃の影響を受ける |
| CI環境における永続化の疑い | 2026年5月中旬まで | Jenkins / ビルドインフラに攻撃者のアクセス権が残っていた可能性 |
| クラウドへの侵入とデータの抽出 | 2026年5月中旬 | Jenkins EC2インスタンスロールの外部からの使用、IAMの権限昇格、RDS/Redshiftを標的とした攻撃とデータの流出 |
表1:Shai HuludとJenkinsランナーとのつながり
ワーム感染によってクラウドが侵害されたことを示す決定的な証拠はありませんが、両者のつながりを示す強力な状況証拠があります。
・時系列の一致:2026年5月上旬のサプライチェーン侵害に続き、およそ2週間後にクラウドでの不正な活動が発生しています。この時系列は、攻撃者が永続化を確立した後、攻撃準備の基盤を整える一般的なパターンと一致しています。
・最初に悪用されたクラウドアイデンティティ:CloudTrailで最初に確認された悪意のある活動では、JenkinsのEC2インスタンスロールが使用されていました。これは、Shai HuludファミリーがCIホストから窃取していることが確認されている認証情報と同じタイプです。
・既知のワーム機能:TeamPCPツールは、クラウドおよびCI環境のシークレットを収集し、被害者のネットワーク外で再利用するよう設計されています。EC2インスタンスの認証情報が外部から使用される手法は、Shai Huludの手口と一致しています。
特定の悪意あるパッケージのアーチファクトから5月中旬に確認されたセッションに至るまでの、攻撃経路全体を追跡するホストレベルのフォレンジック調査および分析は、現在も継続して行われています。
以下の図1では、クラウドインフラストラクチャ内でのラテラルムーブメントを可能にした攻撃によるアイデンティティ侵害の概要を示しています。
以下では、認証情報の窃取後に実行され、FortiCNAPPのアラートによって検知されたクラウドでの活動段階について説明します。
1.最初のクラウドアクセス:侵害されたEC2インスタンスメタデータから、認証情報が取得されました。その後、このロールはインスタンス上ではなく、外部IPアドレスから呼び出されました。
2. 権限昇格:攻撃者はcloudops-monitorという名前のIAMユーザーを作成し、管理者権限とアクセスキーを付与しました。
3.インフラの改変:攻撃者はセキュリティグループを作成し、EC2インスタンスを展開するとともに、ModifyDBClusterまたはModifyCluster APIを変更し、これらのグループをAuroraおよびRedshiftに関連付けました。
4. 認証情報およびデータへのアクセス:Secrets Managerに保存されている多数のシークレットを列挙し、標的となるデータウェアハウスのシークレットにアクセスしました。Redshift Data APIを使用してクエリを実行しました。
5. 流出:攻撃者は、exfil-s3-writeおよびexfil-s3-fullというインラインポリシーを作成して使用しました。セッション名exfilを指定してAssumeRoleを使用し、マネージドインスタンスに対してSSM SendCommandを実行しました。
6. 次の攻撃への準備:Amazon SESの送信クォータを確認し、アイデンティティを検証しました(以下では企業のメールアドレスはマスキングしています)。
| MITREの手法 | 代表的な攻撃手法 | 観測された活動 |
| 初期アクセス | T1195.002(サプライチェーンの侵害) | 過去にShai Huludによって侵害されており、Jenkins環境で永続化された疑いがあります。 |
| 有効なアカウント | T1078.004(クラウドアカウント) | Jenkins EC2インスタンスロールが外部IPアドレスから使用されました。 |
| 権限昇格 | T1098(アカウントの改変) | cloudops-monitorというIAMユーザーが作成され、管理者ポリシーが付与されました。 |
| 探索 | T1580、T1526(クラウドインフラストラクチャ / IAM) | S3、VPC、RDS、Redshift、およびSecrets Manager内のシークレットが列挙されました。 |
| 永続化 | T1578(クラウドコンピュートインフラの変更) | セキュリティグループ、EC2、セキュリティグループの関連付け。 |
| 認証情報へのアクセス | T1552.005(クラウドインスタンスメタデータ)、T1555 | ランナー上でのIMDS curl、Secrets Manager、GetClusterCredentials |
| 収集 | T1530(クラウドストレージからのデータ取得) | Redshift Data APIのExecuteStatement(大量実行) |
| 流出 | T1537(クラウドアカウントへの転送) | S3ポリシーの準備、exfilという名前のAssumeRoleセッション* |
| 影響 | T1496(リソースの乗っ取り) | SESのアイデンティティの検証の準備 |
表2:MITRE ATT&CKの手法と観測されたマルウェアの動作
ホストとクラウドの関連性:ポート8080とEC2インスタンスメタデータ
最も早い時期に高い確度で確認されたクラウドでのシグナルは、Jenkins インスタンスプロファイルがAWS外部から使用されたことでした。FortiCNAPPはこれを、インスタンス認証情報の外部からの不正利用として検知しました。
Jenkinsホストでは、調査担当者が、認証情報の窃取が目的とみられるインスタンスメタデータサービス(IMDS)へのアクセスを確認しました。
curl -s --connect-timeout 3 hxxp://169[.]254[.]169[.]254/latest/meta-data/iam/security-credentials/
curl -s hxxp://169[.]254[.]169[.]254/latest/meta-data/iam/security-credentials/jenkins
これらの操作から、ロールの認証情報がどのようにEC2インスタンスから持ち出されたのかは説明できますが、より判断が難しい問題は、その後誰がこれらの認証情報を管理したかです。
この裏付けとなる重要な証拠の一つが、ビルド環境のネットワークテレメトリです。調査期間中、89[.]22[.]231[.]63のTCPポート8080に対する異常なアウトバウンド通信が確認されました。その後、このIPアドレスは、cloudops-monitorというアイデンティティによる操作や、その後の権限昇格の通信元としても観測されています。このIPアドレスが再利用されていたことは、Jenkinsランナーでのホストの活動と、クラウドログに記録された運用者のインフラストラクチャとの間に強い関連性があることを示しています。また、FortiCNAPPが検知したこの相関関係は、個々の検知シグナルよりもはるかに強力な侵害の指標となりました。
CloudTrailログから確認された、一連の攻撃の経緯を示す2つの外部IPアドレス:
| IP | インシデントでの役割 |
| 185[.]204[.]1[.]225 | Jenkinsロールの悪用が最初に観測された通信元(偵察、IAM権限昇格) |
| 89[.]22[.]231[.]63 | 権限昇格後の運用者の主なIPアドレス、ポート8080経由のホストからのアウトバウンド通信 |
ステージ1:インターネット経由でのJenkinsロールの悪用
侵害されたEC2から一時的なインスタンス認証情報を取得した後、Jenkinsのassumed-roleセッションを使用して、GetCallerIdentityおよびListBucketsが実行され、クラウド環境へ初期アクセスされたことが検知されました。FortiCNAPPは、これらの認証情報がインスタンス以外のIPアドレスから使用されていることを検知しました。このような場合は、インスタンスプロファイルの無効化や制限、ならびにJenkinsランナーの隔離など、直ちに封じ込めの措置を講じる必要があります。
これらの呼び出しにおけるUser-agent文字列は、2つのグループに分類されます(「指標」を参照)。1つは最初のIPアドレスからアクセスしたFedora/Qubes AWS CLIビルドに関連しており、もう1つは、その後の活動の多くで使用されたUbuntu 26 AWS CLIビルドに関連しています。このパターンは、侵害に複数の運用者が関与していたこと、あるいは侵入時に使用するツールチェーンが変更された可能性を示唆しています。
ステージ2:cloudops-monitorからのIAM権限昇格
Jenkinsロールとして認証された状態で、脅威アクターは次の操作を実行しました。
・Jenkinsロールに関するポリシーの列挙。
・cloudops-monitorというIAMユーザーの作成と、AWSが管理するAdministratorAccessの付与。
・有効なアクセスキーの発行。
FortiCNAPPは、CreateUser、AttachUserPolicy、およびCreateAccessKeyを、MITRE ATT&CKのPrivilege Escalation(TA0004)におけるT1078およびT1098に対応する攻撃としてマッピングしました。
6:35(UTC)以降の活動の大半は89[.]22[.]231[.]63からcloudops-monitorとして実行されました。
ステージ3:ネットワークでの永続化とデータストアコントロールプレーンの悪用
a. セキュリティグループの作成とコンピューティングリソースの準備
脅威アクターは、「CloudOpsの監視」のような一見無害に見える説明を付けてセキュリティグループを作成しました。さらに、0.0.0.0/0からのSSHアクセスを許可し、IAMユーザー名をタグ付けしたEC2インスタンスを起動しました。最初の起動に失敗した場合は、別のサブネットを試行していました。また、DescribeSubnetsおよびDescribeRouteTablesが複数回呼び出されていたことから、本番環境のVPC構成を意図的にマッピングしていた可能性があります。
b. Aurora RDS:ModifyDBCluster
本番環境のAurora PostgreSQLクラスタに対して、CloudTrailには次の操作が記録されていました。
◦ クラスタの偵察(DescribeDBClusters)
◦ applyImmediately: trueを指定したModifyDBClusterの実行。この脅威アクターは、マスターパスワードのローテーションを試みた後、攻撃者が管理するセキュリティグループをクラスタに関連付けようとしました。
これはコントロールプレーンへの攻撃であり、脅威アクターは認証情報を窃取するだけにとどまらず、データベースへのアクセス方法や認証方式も変更しようとしていました。
c. Redshift:ModifyClusterとポート5439
脅威アクターは、Redshiftに対して次の操作を実行しました。
◦ 開発環境および本番環境のデータウェアハウスの標的を列挙しました。
◦ ModifyClusterを呼び出し、RDSで使用したのと同じ攻撃者が管理するセキュリティグループを関連付けました。
◦ AuthorizeSecurityGroupIngressを呼び出してTCPポート5439(Redshift)への通信を許可し、攻撃のために事前に用意したセキュリティグループからデータウェアハウスのセキュリティグループへアクセスできるようにしました。これにより、データプレーンへのネットワーク経路を確立しました。
FortiCNAPPは、これらのAPI呼び出しについて、不可能な移動および機密インフラストラクチャの探索を検知しました。
ステージ4:Secrets Manager:標的となったデータウェアハウスの認証情報
脅威アクターは、ページネーションを伴うListSecretsを数百回実行した後、リージョンごとのRedshiftデータウェアハウスやレポートパイプラインに関連することが明らかなシークレットに対して、GetSecretValueを実行しました。標的となったシークレット名には、datawarehouse_redshift_* やtruedata_reporting_redshift_*といったパターンが含まれていました。
FortiCNAPPは、cloudops-monitorによるこれらの操作を、「クラウドシークレットの不審な列挙」および認証情報へのアクセス(TA0006)として検知しました。
IAM権限は持っているもののネットワークアクセスが制限されている管理者にとって、Secrets Managerは接続文字列を最も迅速に取得できる手段であり、今回観測された脅威アクターの行動は、このフェーズの特徴と一致しています。
ステージ5:Redshift Data API:データ収集と流出
ネットワーク経路を確立し、シークレットにアクセスした後、脅威アクターは次の操作を実行しました。
・本番環境のデータウェアハウスクラスタおよびデータベースに対して、GetClusterCredentialsを繰り返し呼び出しました。
・同じ外部の運用者のIPアドレスから、Redshift Data APIを使用してExecuteStatementを実行しました。利用可能なログセットでは、約90回にわたって、ExecuteStatement → DescribeStatement → GetStatementResultの一連の処理が確認されました。
CloudTrailでは、リクエストパラメータに含まれるSQL文はマスキングされるため、ログだけでは実際に実行された個々のSQLクエリを確認することはできません。しかし、このような継続的かつ対話的な操作が大量に行われていたことから、一時的なヘルスチェックではなく、データの収集および流出を目的とした活動であったと判断できます。この評価は、データウェアハウスへの侵害が確認されたとする被害組織の報告とも一致しています。
FortiCNAPPが検知した収集(TA0009)および影響(TA0040)も、この攻撃フェーズと一致しています。
ステージ6:データ流出の手口 ― IAMとSTSに残された露骨な命名
インラインS3ポリシーが既存の分析用ロールに関連付けられていました。脅威アクターは、PutRolePolicyを使用して、分析ワークロードで使用されていたロールに対し、S3データレイクに対する対象を特定したアクセス権限を追加しました。
| ポリシー名 | 権限 | 推定される目的 |
| exfil-s3-write | 本番データバケットに対するPutObject、GetObject、ListBucket | データの一時保存(ステージング) |
| exfil-s3-full | 上記に加えてDeleteObject | オブジェクトのライフサイクル全体の制御 |
exfil-s3-* のようなポリシー名は、脅威アクターにとっては格好の手掛かりとなりますが、一方で、命名規則だけを信用し、ポリシーの内容を確認していないチームに対する警鐘でもあります。
セッション名exfilを指定したAssumeRole
攻撃者が作成したcloudops-monitorとは別の緊急用IAMユーザーが、複数回アクセスが拒否された後に、roleSessionName: exfilを指定してAssumeRoleを実行し、高い権限が付与された緊急アクセス用ロールへ切り替えました。その後、exfil10およびexfil12というセッション名でListRolesおよびSendCommand操作が実行されています。
SSM SendCommand
これらのセッションでは、脅威アクターはマネージドEC2インスタンスに対してAWS-RunShellScriptドキュメントを使用してSendCommandを実行しました(ログではパラメータはマスキングされています)。コマンドの呼び出しに成功していることから、攻撃者は外部からのCLIアクセスが制限されている環境でも、VPC内部でコマンドを実行していたことが分かります。このような手法は、ツールの配置、データのアーカイブ、あるいはデータを外部へ持ち出すための中継地点への転送などで一般的に利用されます。
ステージ7:SES—外部送信用メールの準備
調査期間の終盤、cloudops-monitorおよび関連するプリンシパルは、GetSendQuota、GetIdentityVerificationAttributes、VerifyEmailIdentity、ListIdentitiesを実行しました。送信元として使用するため、複数の企業のメールアドレスが認証対象として登録されましたが、公開ポリシーに従い、本ブログではそのアドレスは伏せています。
一部のSES呼び出しは、外部の運用者のIPではなく、攻撃を受けた組織の環境内のEC2インスタンスから実行されていました。これは、コントロールプレーンの不正な操作を続けながら、攻撃者が被害組織のVPC内で処理を実行する段階へ移行したことを示しています。
SESの利用準備は、フィッシング、恐喝、あるいはドメインレピュテーションを損なう攻撃に先行して行われることが多いため、データ流出が別の場所で発生した場合であっても、このような動作を監視することが重要です。
FortiCNAPPによる検知:「侵害された可能性のあるキー」
FortiCNAPPはCloudTrailログとIAMアイデンティティのコンテキストを取り込み、このインシデント発生期間中に1,095件の観測結果を生成しました。顧客向けには「侵害された可能性のあるキー」というインシデントとして提示され、実務担当者が攻撃の全体像を把握するために必要な情報を提供しました。
| 観測カテゴリ | 数(概算) | 重要な理由 |
| 不可能な移動 | 202件 | 運用者 / APIの地域がベースラインと一致しない |
| MITRE探索 | 170件 | S3、RDS、Redshift、IAMの偵察 |
| 機密インフラストラクチャの探索 | 128件 | クラスタとセキュリティグループの改変 |
| プリンシパルによる初めてのAPI呼び出し | 120件 | 侵害されたアイデンティティによる初めてのAPI利用 |
| 永続化 | 62件 | SGとクラスタの変更 |
| 権限昇格 | 52件 | ユーザー作成、インラインポリシー |
| 外部接続 | 49件 | クラウドアイデンティティに対する外部IPからのアクセス |
| 認証情報アクセス | 41件 | Secrets Manager、GetClusterCredentials |
| EC2インスタンス認証情報の外部利用 | 20件 | 非AWS IPからのJenkinsロールの利用 |
表3:検知された侵害を示す可能性のある活動
エクスポートデータに見られる代表的な観測内容を以下に示します。
・外部IPからのAWSインスタンスの認証情報の使用 — Jenkinsロール
・AWSユーザーの作成 — cloudops-monitor
・権限昇格(TA0004)を示すAWS API呼び出しの観測
・クラウドシークレットの不審な列挙の検知
・短時間での不可能な移動の検知
このプラットフォームの価値は、これらのイベントを単一のアラートタイトルのもとで関連付けている点にあります。Jenkinsロール → cloudops-monitor → データストアAPI → exfilセッション命名という一連の流れを統合して可視化しており、アナリストが6時間にわたる1,300件以上のCloudTrailイベントを手作業で関連付ける必要をなくしています。特に、外部からのインスタンス認証情報の使用を特定することが、ホストベースの脅威とクラウドベースの攻撃を結び付けるために非常に重要となっています。これらの脅威をホストからクラウドへとマッピングする作業は従来は複雑で手作業でしたが、FortiCNAPPは効果的に自動化しています。
防御側への推奨事項
1. CI/CDランナーをTier 0(最重要)のアイデンティティとして扱う:最小権限のインスタンスプロファイルを適用し、管理者権限への経路や、ビルドロールからの広範なSecrets Managerやデータストア管理者権限を排除します。
2. インスタンス認証情報の外部からの利用を検知する:これはクラウドにおける最も初期のシグナルでした。これをホスト側の送信ルールと組み合わせ、予期しないアウトバウンド通信(例、非標準ポートへの外部運用者のIPからの接続)を検知します。
3. データストアのコントロールプレーンを保護する:ModifyDBCluster、ModifyCluster、および5432/5439ポートへのセキュリティグループのインバウンドルール変更について、アラートを設定して、変更管理を適用します。
4. 攻撃者による明示的な命名を検知対象にする:ポリシー名(exfil-s3-full)やSTSセッション名(exfil、exfil12)を、高精度な検知ルールに組み込む必要があります。
5. パッケージからデータウェアハウスまでの一連のシナリオで机上演習を行う:Shai Huludの事例は、パイプラインの依存関係が改ざんされると、現実的にクラウドデータが流出することを示しています。
フォーティネットのソリューション
本レポートで説明したマルウェアは、FortiGuardアンチウイルスにより以下の脅威として検知およびブロックされます。
JS/Agent.B067!tr
JS/Agent.3A86!tr
FortiGuardアンチウイルスサービスエンジンは、FortiGate、FortiMail、FortiClient、およびFortiEDRに統合されています。これらの製品を最新のシグネチャを利用して運用しているお客様は、本レポートに記載されているマルウェアコンポーネントから保護されます。
FortiGuard Webフィルタリングサービスは、C2サーバーをブロックします。
基礎的なセキュリティ意識の強化を目指すお客様は、サイバーセキュリティに関するフォーティネット認定ファンダメンタルズ(FCF)トレーニングの実施もご検討ください。このモジュールでは、エンドユーザーはさまざまなフィッシング攻撃を識別して自らを保護する方法を学習できます。
FortiGuard IPレピュテーションおよびアンチボットセキュリティサービスは、フォーティネットが全世界に展開するセンサーネットワーク、CERTの連携、MITRE、信頼できる業界パートナー、その他のインテリジェンスソースから収集した悪意のあるIPインテリジェンスを相関させることで、このキャンペーンに関連するインフラストラクチャをプロアクティブにブロックします。
このようなサイバーセキュリティの脅威の影響を受けていることが疑われる場合は、グローバルのFortiGuardインシデントレスポンスチームにお問い合わせください。
公開されたIOC(Indicators of Compromise:侵害指標)
これらのIOCをブロックする前に自社環境で有効性を確認してください。ユーザーエージェントは時間の経過とともに変化する可能性があることに注意してください。
IPアドレス
| IP | コンテキスト |
| 185[.]204[.]1[.]225 | Jenkins ECインスタンスロールの最初の外部からの不正操作 |
| 89[.]22[.]231[.]63 | 権限昇格後に運用者が主に利用しているIP、ホストからポート8080へのアウトバウンド接続 |
攻撃者が作成したIAMアカウント
| タイプ | 値 |
| IAMユーザー | cloudops-monitor |
STSロールのセッション名
| セッション名 | コンテキスト |
| exfil | 緊急アクセス用 / スーパー管理者ロールの引き受け(AssumeRole) |
| exfil10、exfil12 | SSM SendCommandおよびその後の活動で使用されたセッション |
攻撃者が作成したIAMインラインポリシー名
| ポリシー名 | コンテキスト |
| exfil-s3-write | 本番データバケットに対するS3の書き込みおよび一覧取得 |
| exfil-s3-write | 同じバケットでのs3:DeleteObjectの追加 |
代表的なUser-agent文字列の例
Ubuntu運用者のツールチェーン(主要な攻撃元IP 89[.]22[.]231[.]63):
aws-cli/2.31.35 md/awscrt#1.0.0.dev0 ua/2.1 os/linux#7.0.0-15-generic md/arch#x86_64 lang/python#3.14.4 md/pyimpl#CPython ... md/distrib#ubuntu.26
Boto3/1.40.72 md/Botocore#1.40.72 ... os/linux#7.0.0-15-generic ... lang/python#3.14.4
Fedora/Qubesツールチェーン(初期のJenkinsロールの不正利用、IP 185[.]204[.]1[.]225):
aws-cli/2.34.29 md/awscrt#0.31.2 ua/2.1 os/linux#6.18.15-1.qubes.fc41.x86_64 md/arch#x86_64 lang/python#3.14.3 md/pyimpl#CPython ... md/distrib#fedora.42
本記事はアフィリエイトプログラムによる収益を得ている場合があります
この記事の編集者は以下の記事もオススメしています
-
sponsored
サイバー犯罪懸賞金プログラム「Operation Silent Vector I」がスタート -
sponsored
AI関連文書を装ってマルウェア「AsyncRAT」を配信する攻撃キャンペーンを確認 -
sponsored
JavaScriptを用いて機密データを収集するPureLogs亜種を分析


