AIハーネスを追う：Cairn・ARTEX・PentAGI

AIを使った侵入では、役立つ情報を見つけてから次の操作を試すまでの時間が縮まります。作業自体は見慣れたものです。API仕様を読み、認証の流れを試し、レコードを変更し、シェルを動かし、別の資格情報を得る。ハーネスは結果をワーカー間で共有し、失敗した経路の次の作業を組み直して、処理を継続します。

MicrosoftのStorm-0940に関する報告では、ConnectWise侵害後に2,250超のテナントへのサインインが試みられ、ARTEXを使った一部の攻撃では3時間以内にクラウドの特権アクセスへ到達しました。別のパスワードスプレーは8組織の327アカウントを狙いましたが、成功したサインインはありません。CrowdStrikeのVapor Pandaに関する報告では200超が標的となり、9組織で侵入後の活動を確認しています。指標も事例も別で、標的数は侵害件数ではありません。THNのMicrosoft報道とCrowdStrike報道で確認しました。

必要なのは、同じ活動を複数の証拠から追う、繰り返せる調査手順です。本稿を5つの視点、クエリ14本、受動的な検索6本のフレームワークに拡張しました。代表的なクエリ6本は本文にも掲載。ハント集には全14本、運用上の注意、対応表、レビュー記録を収録しています。

1. ハーネスと、その信頼境界を把握する

モデルが作業を提案・選択し、周囲のソフトウェアがツール、記憶、スケジュール、資格情報、運用者の画面を提供します。複数のワーカーは業務時間外も別々の経路を調べられますが、人が途中で指示を変えることもできます。自律的な処理があることと、人が一切関わらないことは同じではありません。

図1：固定した上流資料に基づくオリジナル概念図。管理面にも独自の保護境界が必要。

コンソールは管理面でもあります。プロジェクトの証拠、実行権限、モデル利用、保存セッションを扱い、乗っ取られれば正規のテスト担当者の資源を別の運用者に使われかねません。コンテナーだけで境界を判断せず、ホストのDockerソケットのマウントや、利用者の権限で動くローカルワーカーも確認します。

ハーネス	管理面で確認した点と調査への示唆
Cairn	固定した版のComposeは8000番を公開し、ディスパッチャーへDockerソケットをマウント。確認したFastAPIアプリとルーターには組み込みの認証依存やミドルウェアがありません。外部の認証プロキシで守られている可能性は別に確認し、全ルートを対象にします。
ARTEX	Unit 42はnginxの応答にHTTP Basicのrealm `ARTEX`を観測。提供されたRST参考文は8787番、翻訳版、改名した派生版を記載。認証・ポート・名前は版で異なり、タイトルは発見の手がかりです。
PentAGI	固定した版のComposeの既定は127.0.0.1:8443。READMEはログイン、初期のローカル管理者、既定パスワードの変更を説明しています。公開到達できるかは導入時の選択であり、既定のバインドからインターネット公開とは判断できません。

固定したCairnとPentAGIのソースを読み、公開アセットのハッシュを計算しました。フレームワーク自体は実行していません。Cairnのローカル実行モードは、利用者の権限で動き、サンドボックスがないと明記しています。対策を決めるときは、実際に導入した版で確認してください。

Cobalt Strikeとの比較が役立つのは、正規のテストと侵入で同じ道具が使われ、名前が変わっても派生版に機能が残るという点です。特定の所有者への判定にはなりません。レッドチーム演習、CTF、侵入のいずれにも、似たクライアント、バナー、スクリプトが現れます。

2. 5つの視点を調査に適用する

図2：オリジナルの5視点フレームワーク。各段階に入力と、責任を持って残す結果を定める。

範囲。 正式な資産台帳、時間範囲、許可された演習、利用可能なログから始めます。どのプロキシが実クライアントIPを記録し、どのサーバーが対象リソースを持ち、誰が権限の正当性を判断できるかを記録。クラウド事業者のASNや国は自社資産の境界ではありません。借りた1つのクラウドIPなら、事業者全体のアドレス帯ではなく、許可されたIPや/32を指定します。

公開面。 インターネット検索基盤に保存された情報を探し、応答と導入版で系統の特徴を確かめます。IP、ポート、プロトコル、観測時刻、出典をサービス単位で残し、IP総数は別に集計。Basic認証でタイトルが見えない場合や、名前だけ変えた派生版もあります。一方、同じfaviconをコピーした無関係なページもあります。

操作の影響。 対象側で起きたAPI読み書き、子プロセス、ファイル、認証、ディレクトリ変更、外向き通信を調べます。Unit 42の事例は受理された書き込みと読み戻しが中心です。JPCERT/CCの注意喚起では、ケースEに設定・バックアップ窃取や公開WSUSへの試行があります。APIのBとJSP WebシェルのDは別のケースで、AI利用の帰属ではありません。

関連付け。 共有IPより、検証した主体、実際のリソースID、プロセスの親子関係を優先します。取り込み遅延を考慮し、発生時刻とアプリの認可判断、実際の変更を残します。2xxは汎用ページ、非同期の受付、正規の保存かもしれません。後の403も先に成立した変更を取り消しません。関連付けのために生のBearerトークンをログへ保存しないでください。

対応。 確度、担当、次に求める証拠を決めます。時間間隔の異常は調査のきっかけになります。認可されない資格情報変更が確認できれば、承認済み手順で迅速に封じ込めます。最初の経路を止めた後も、別のセッション、資格情報、永続化を調べ、項目不足やセンサーの穴、不適切な照合をログ設計へ戻します。

3. 公開面の発見を、そのまま帰属にしない

提供されたRST Labsの11月2日付参考文は、Cairn 56、ARTEX 834、PentAGI 459、系統横断でユニークIP 1,341と報告しています。今回、その集計、国別分布、評判確認、検索事業者の網羅性を再現したわけではありません。系統別の合計は1,349ですが、同じIPが複数の系統を持てば和集合とは一致しません。データを統合する際に重要な区別です。

参考文には保存済みの検索情報と、Netlasによる対象を絞ったスキャンの両方が記載されています。今回の改訂では、どちらの再集計も、新たな全世界検索もしていません。以下は自社または許可を得た資産向けの受動的なShodan検索例です。1行ずつ検索して結果を統合し、保存された応答で系統の特徴を確認してから重複排除します。Next.js、Vite、uvicornだけではハーネスを識別できません。

# Passive Shodan inventory starters. Replace with an OWNED/authorised IP or CIDR (use /32 for a single cloud IP).
# Execute each line separately, union the results offline, verify stored banners and deduplicate IP+port before IP totals.
# These are not malicious-host lists; no search or third-party console access was performed for this article.
net:REPLACE_WITH_OWNED_CIDR product:"Cairn"
net:REPLACE_WITH_OWNED_CIDR http.title:"Cairn" http.server:"uvicorn"
net:REPLACE_WITH_OWNED_CIDR http.title:"ARTEX — 自主渗透测试控制台"
net:REPLACE_WITH_OWNED_CIDR "WWW-Authenticate" "ARTEX"
net:REPLACE_WITH_OWNED_CIDR ssl.cert.issuer.cn:"PentAGI CA"
net:REPLACE_WITH_OWNED_CIDR http.favicon.hash:-1596753120

検索6本をダウンロード。検索式と網羅性は事業者で異なります。NetlasやCensysではその製品の証明書・本文・ハッシュ項目を使い、Shodanの式をそのまま貼らないでください。検索で見つかっただけの第三者のコンソールへアクセスしたり、既定パスワードを試したり、スキャンを始めたりしません。

図3：オリジナルの識別ガイド。再現した2つの値は別ファイル・別方式で、同じバイト列の競合するハッシュではない。

PentAGIの2つのfavicon値は、固定した版の別々のファイルで再現できました。 /favicon/favicon.icoを改行付きBase64へ変換してShodan方式のMurmurHash3を計算すると**-1596753120**。/favicon/favicon-96x96.pngのSHA-256は2a620e3c5f7b49dfc6f5278352607f7931f8c38ef9d4689908af65538dd95366です。ICOそのもののSHA-256は別の値です。ダウンロードの記録に全値と出典パスを残しています。

「証明書はfaviconより強い」といった固定的な順位は単純すぎます。既定の証明書もコピー・変更でき、特定の版の本文の方が絞り込めることがあります。独立した特徴を組み合わせ、実際のバイト列と観測日を確認します。国はホスティングの場所であり、運用者の国籍ではありません。VirusTotalの検知数ゼロも、その時点で参加エンジンが検知しなかったという意味で、安全や未報告の証明ではありません。

4. データと問いからハンティングを選ぶ

図4：全14本のオリジナル対応図。取得していないデータは調査の穴として残す。

対応表をCSVでダウンロード。

ハント集はSentinel KQL 7本とFalcon CQL 7本です。全例に対象の置き換えと結果上限100件があります。Sentinelはコードで24時間に限定し、S7だけ7日間のセンサー情報を使います。Falconは画面の時間範囲を直近1時間に設定。Webの順序を調べる例は古い方から10,000件が入力上限のため、多い場合は時間範囲を分けます。

今回、Microsoftが公開するAzure Monitorのテーブル定義を確認しました。Sentinelへ取り込んだDefenderの時刻列は**TimeGenerated**です。Defender Advanced HuntingではTimestampを使います。また、DefenderのDeviceId、Falconのaid、公開のクライアントAppId、テナント内のサービスプリンシパルのオブジェクトIDは異なります。必要なコネクター、保持期間、読み取り権限がなければ、テーブル不在は調査の穴であって陰性結果ではありません。

Sentinelで調べる7つの問い

ハントとダウンロード	必要なログ
S1 · 探索に続くAPI書き込み	`ASIM _Im_WebSession`
S2 · 報告されたプローブファイル	`DeviceFileEvents (Defender ingestion)`
S3 · 失敗だけのスプレーも調べる	`SigninLogs`
S4 · ワークロードのサインイン後の変更	`AADServicePrincipalSignInLogs + AuditLogs`
S5 · 近いサイズの外向き通信の反復	`CommonSecurityLog (CEF proxy)`
S6 · コールバックサービスへの接続	`DeviceNetworkEvents (Defender ingestion)`
S7 · 資産台帳とセンサーの差を調べる	`DeviceInfo (Defender ingestion) + supplied inventory`

S1は探索と受理されたAPI書き込み、S2は報告されたファイルの特徴を調べます。ファイル名だけの判定はしません。S3は成功がないスプレーも残し、S4はサインイン後に同じアプリ主体が行った変更を見ます。S5は要求単位の外向きバイト数、S6はプロセスに結び付くコールバック先の接続、S7は入力した正式な台帳とセンサー記録の差を調査します。EDRの画面だけを完全な台帳とは扱いません。Falconだけの環境では端末一覧の出力をCMDBと比較します。イベント検索で、まだ観測していない資産を列挙することはできません。

Falconで補う7つの問い

ハントとダウンロード	必要なログ
C1 · 同じリソースへの書き込みと読み戻し	`CPS web logs + neighbor()`
C2 · Webプロセスが起動するシェル等	`ProcessRollup2`
C3 · プロセス内の報告済みマーカー	`ProcessRollup2`
C4 · コールバック先のDNS調査	`DnsRequest`
C5 · 書き込みエラーから成功への反復	`CPS web logs + neighbor()`
C6 · 対象を絞った操作間隔のプロファイル	`CPS web logs + neighbor()`
C7 · 自社Cairnコンソールの変更・出力	`CPS reverse-proxy web logs for your own Cairn`

C2〜C4は端末の生イベント、C1・C5〜C7はFalcon Next-Gen SIEMへ取り込んだWeb・リバースプロキシのログです。 端末センサーだけでは遠隔の攻撃者のHTTPパスは得られません。DNSの一致は名前解決であり、HTTPコールバックの証明ではありません。C1・C5・C6は信頼できる主体情報を必要とし、user.idがなければ除外します。C7はその項目がないコンソールの操作も残すため、認証監査で別途確認します。未認証・IPだけの版は、確度の低い別調査として扱います。

artex-probe-*、ArtexProbe、artxを含むパスは、提供されたRST参考文がGTIGの事例として記載したものです。この環境からGTIG原文は取得できていません。削除可能な手がかりであり、正規のテストでも一致します。webhook.siteのようなコールバックサービスも共有基盤で、それ自体が悪性の宛先ではありません。

5. 代表的なクエリ6本と解釈

全14本は上のリンクとZIP集にあります。READMEに各例の項目、対象、調整、誤検知、見落としを記載。まず、調査済みのアラートや事案から得たIP、1つのアプリ・ホスト、小さな時間範囲で始め、既知の正常イベントが見えることを確認してから結果なしを解釈します。

S3 · 失敗だけのスプレーも見失わない

送信元とクライアントアプリを指定します。5分間で10アカウントの失敗という値は調整の出発点で、報告された攻撃の最大速度から導いたものではありません。選んだ失敗コードにはMFAの要求を含めていません。NATの背後では同じIPの別利用者が成功することもあり、成功は分けて確認します。

// Illustrative hunt; not executed in a live Sentinel or Falcon tenant.
// Sentinel SigninLogs; one source IP and client AppId. Last 24h; at most 100 buckets.
// 50126=invalid credentials, 50053=locked, 50034=unknown account; MFA challenges are not counted as password failures.
// Ten failed accounts in five minutes is a starting threshold, not an AI signature.
let SourceIP = "REPLACE_WITH_SOURCE_IP";
let ClientApp = "REPLACE_WITH_CLIENT_APP_ID";
SigninLogs
| where TimeGenerated between (ago(24h) .. now())
| where IPAddress == SourceIP and AppId == ClientApp
| summarize Failures=countif(ResultType in ("50126","50053","50034")),
    FailedAccounts=dcountif(UserPrincipalName, ResultType in ("50126","50053","50034")),
    Successes=countif(ResultType == "0"),
    AccountSample=make_set_if(UserPrincipalName, ResultType in ("50126","50053","50034"), 10)
    by IPAddress, AppId, Window=bin(TimeGenerated, 5m)
| where FailedAccounts >= 10
| order by Window desc
| take 100

S4 · アプリIDからディレクトリ変更を追う

対話型利用者のMFAアラートだけではワークロードIDが抜けます。同じサービスプリンシパルの成功したサインインと、30分以内にその主体が行った資格情報・所有者・ロールの操作を結びます。時間的な関連であり、同じトークンによる因果関係とは限りません。監査記録と承認を確かめ、Graphとリソースのデータプレーンへ調査を広げます。マネージドIDや他の永続化には追加の範囲が必要です。

// Illustrative hunt; not executed in a live Sentinel or Falcon tenant.
// Sentinel Entra workload sign-ins + directory audit; needs both ingestions and read permission.
// Use a tenant service-principal object ID, not a public client AppId. Last 24h; at most 100 pairs.
let Principal = "REPLACE_WITH_SERVICE_PRINCIPAL_OBJECT_ID";
let Starts = AADServicePrincipalSignInLogs
    | where TimeGenerated between (ago(24h) .. now())
    | where ServicePrincipalId == Principal and ResultType in~ ("0", "Success")
    | project PrincipalId=ServicePrincipalId, SignInTime=TimeGenerated, IPAddress, ResourceDisplayName;
let Changes = AuditLogs
    | where TimeGenerated between (ago(24h) .. now())
    | where Result =~ "success"
    | extend PrincipalId=tostring(InitiatedBy.app.servicePrincipalId)
    | where PrincipalId == Principal
    | where OperationName matches regex @"(?i)(credential|certificate|secret|owner|role)"
    | project PrincipalId, ChangeTime=TimeGenerated, OperationName, TargetResources, CorrelationId;
Starts
| join kind=inner Changes on PrincipalId
| where ChangeTime between (SignInTime .. (SignInTime + 30m))
| project SignInTime, ChangeTime, PrincipalId, IPAddress, ResourceDisplayName,
    OperationName, TargetResources, CorrelationId
| order by ChangeTime desc
| take 100

S5 · 近いサイズの外向きリクエストを調べる

提供されたRST参考文は、ReliaQuestのCairn事例で約1,800バイト単位の持ち出しを記載しています。これは汎用のネットワーク指紋ではありません。この例ではプロキシの1イベントが1回のHTTP処理であり、SentBytesがクライアントから宛先へ送った量である必要があります。5分間に近いサイズの20件は調査用のしきい値です。バックアップやテレメトリーも一致し、TLS、ヘッダー、フロー集約はパターンを隠します。

// Illustrative hunt; not executed in a live Sentinel or Falcon tenant.
// Sentinel CEF proxy: one event per HTTP request; SentBytes must mean client-to-destination bytes.
// Requires CommonSecurityLog, SourceIP, DestinationHostName and SentBytes. Last 24h, at most 100 buckets.
// Near-uniformity is a lead. Do not alert on the ReliaQuest case's reported 1,800-byte payload size alone.
let SourceHost = "REPLACE_WITH_SOURCE_HOST_IP";
let Destination = "REPLACE_WITH_DESTINATION_FQDN";
CommonSecurityLog
| where TimeGenerated between (ago(24h) .. now())
| where SourceIP == SourceHost and DestinationHostName =~ Destination
| where SentBytes >= 256
| summarize Requests=count(), P10=percentile(SentBytes,10), P90=percentile(SentBytes,90),
    TotalSentBytes=sum(SentBytes), UrlSample=make_set(RequestURL,5)
    by SourceIP, DestinationHostName, Window=bin(TimeGenerated,5m)
| where Requests >= 20 and P90 <= P10 * 1.10
| order by TotalSentBytes desc
| take 100

C1 · 同じリソースへの書き込みと読み戻しを確かめる

送信元、アプリのホスト、パス、主体でまとめ、途中のメソッドを残して隣接した操作を比較します。成功したPUT・PATCHの後、5秒以内のGETが対象。通常の保存・再読み込みも一致します。クエリパラメーターで対象を選ぶAPIには正規化したリソースキーを追加し、POSTで新URLが返る場合は対象IDやLocationを別に照合します。そのようなAPIではパスの一致だけでは足りません。

// Illustrative hunt; not executed in a live Sentinel or Falcon tenant.
// Falcon Next-Gen SIEM, CPS web logs. REQUIRED time picker: last 1 hour.
// Replace parser, source IP and host. Requires user.id (principal, never a raw token).
// Resource identifiers must be in url.path; query-selected objects need an extra canonical resource key.
// Only PUT/PATCH pairs; POST creation needs separate Location/object-ID correlation.
// The oldest 10,000 matching input events are retained: split busy windows; output at most 100 groups.
#type="REPLACE_WITH_WEB_PARSER" source.ip="REPLACE_WITH_SOURCE_IP" url.domain="REPLACE_WITH_APP_HOST" user.id=* url.path=*
| sort(@timestamp, order=asc, limit=10000)
| t := @timestamp
| groupBy([source.ip, url.domain, url.path, user.id], function=neighbor(include=[t, http.request.method, http.response.status_code], prefix=prev), limit=max)
| http.request.method=/^GET$/i prev.http.request.method=/^(PUT|PATCH)$/i
| prev.http.response.status_code=/^2[0-9]{2}$/ http.response.status_code=/^2[0-9]{2}$/
| gap := t - prev.t
| test(gap > 0 and gap <= 5000)
| groupBy([source.ip, url.domain, user.id], function=[count(as=ReadBacks), collect([url.path], limit=10)], limit=100)
| ReadBacks >= 3
| head(limit=100)

C2 · 対象サーバー上の実行を調べる

端末側で有用なのは、守るべきサーバーのWebプロセスが何を起動したかという問いです。代表的なWebプロセスがシェルやHTTPクライアントを直接起動したものを抽出。プロセスID、親子関係、コマンドライン、作られたファイルを確認します。正規のデプロイも一致し、間接的な子、プロセス内の実行、記載のないランタイムは漏れます。一致はARTEXの識別ではありません。

// Illustrative hunt; not executed in a live Sentinel or Falcon tenant.
// Falcon Insight EDR / Advanced Event Search. REQUIRED time picker: last 1 hour.
// One sensor AID; requires ProcessRollup2 with parent name and command-line telemetry.
// Direct web-worker children only; baseline approved maintenance before alerting. Output at most 100 groups.
#event_simpleName=ProcessRollup2 aid="REPLACE_WITH_FALCON_AID"
| ParentBaseFileName=/^(w3wp|httpd|apache2|nginx|php-fpm[0-9.]*|tomcat[0-9]*)(\.exe)?$/i
| FileName=/^(cmd|powershell|pwsh|bash|sh|dash|curl|wget)(\.exe)?$/i
| groupBy([aid, ComputerName, ParentBaseFileName, FileName], function=[count(as=Executions), collect([CommandLine, ParentProcessId, TargetProcessId], limit=10)], limit=100)
| head(limit=100)

C6 · 操作間隔を背景情報として測る

提供されたRST・GTIGの記述は2〜25秒間隔のバースト、Unit 42は自社の事例で25〜31秒の小休止を挙げています。作業、モデル、ゲートウェイ、時刻精度で分布は変わります。この例は共通のAI判定帯を置かず、間隔を記述します。対象は0〜600秒の間隔で、それより長い空白時間はこの分布に含みません。通常のブラウザー、テスト、監視、バッチと比べ、並列ワーカーやIP変更で分布が崩れることも考慮します。

// Illustrative hunt; not executed in a live Sentinel or Falcon tenant.
// Falcon NG-SIEM CPS web logs. REQUIRED time picker: last 1 hour.
// Profile only: no universal 2-25s or 25-31s AI threshold. Compare with the app's baseline and independent evidence.
// One source/app, principal required. Oldest 10,000 inputs retained; at most 100 groups.
#type="REPLACE_WITH_WEB_PARSER" source.ip="REPLACE_WITH_SOURCE_IP" url.domain="REPLACE_WITH_APP_HOST" user.id=* url.path=*
| sort(@timestamp, order=asc, limit=10000)
| t := @timestamp
| groupBy([source.ip, url.domain, user.id], function=neighbor(include=[t, url.path], prefix=prev), limit=max)
| GapSeconds := (t - prev.t) / 1000
| test(GapSeconds >= 0 and GapSeconds <= 600)
| groupBy([source.ip, url.domain, user.id], function=[count(as=Gaps), count(url.path, distinct=true, as=DistinctPaths), min(GapSeconds, as=MinGap), max(GapSeconds, as=MaxGap), percentile(field=GapSeconds, percentiles=[10,50,90])], limit=100)
| Gaps >= 20
| head(limit=100)

6. 複数の層から事案を組み立てる

図5：オリジナルの調査経路。名前の出た報告を同じキャンペーンにまとめず、検知性能も主張しない。

具体的な1イベントから始め、近くにある独立した証拠を求めます。受理されたAPI書き込みなら、認証主体、対象ID、変更前後の状態、認可判断を確認。サーバーの発生時刻とプロセスの親子関係で実行を追い、遠隔のIPが同じだけでプロセスとの関係を決めません。

アプリIDの悪用では、サインインした主体、変更を行った主体、対象オブジェクト、追加した資格情報・ロールを区別します。元のベンダーアプリを止めても、別に追加された資格情報が消えるとは限りません。通信量の規則性は方向と要求単位を確認してから解釈。センサー不在は、ホスト名、製品、鮮度を正式な台帳と照合し、停止中のホストを「侵入者が選んだ未管理端末」と決めつけません。

報告された手法は調査の起点になります。Unit 42のAPIの順序はS1・C1・C5、MicrosoftのアプリIDの事例はS3・S4、CrowdStrikeの侵入後の活動はC2とセンサーの点検へつながります。RST参考文にあるCairnの乗っ取りとハーネス侵害はS5・C7の問いに対応します。事例を同じ攻撃者へまとめたり、検知率を検証したことにしたりするものではありません。

時間範囲、主体・端末・対象のID、許可されたテスト、証拠への参照、未確認点、次の判断担当を記録します。弱い一致の積み重ねから、いつの間にかLLM利用の断定へ進まないようにします。攻撃側の会話記録や出典の確かなフレームワークの痕跡は、要求間隔の分布とは異なる証拠です。

7. 影響を封じ、自社のハーネスも守る

図6：オリジナルの確度と行動の対応図。業務に影響する封じ込めは承認済みの方針で行う。

証拠と業務影響が合う場面で、承認済みの自動化を使います。関連記録と資格情報の変更を保全し、不正なAPI経路の停止や資格情報の失効、必要なサーバー隔離を行い、別のアクセスと永続化を調査します。スプレーの失敗や公開コンソールのタイトルだけなら、業務を止める前に背景と証拠が必要です。

正規に運用する場合は、コンソールを私設インターフェースかVPNに置き、必要なWebSocketも含めてすべてのAPI・管理ルートを認証プロキシで守ります。初期資格情報を変更し、ワーカーを隔離し、Docker・ソケットの権限を絞り、クラウドとモデルの資格情報を用途ごとに制限して利用を監視します。出力や作業のAPIが認証を迂回できれば、ログイン画面だけでは不十分です。

プロジェクト作成、範囲変更、出力、特権操作、認証を、自分たちが管理する層で記録します。確認したCairn Composeは--no-access-logで起動するため、プロキシの背後に置いただけで必要なアクセス記録が残るとは限りません。C7はそのプロキシログを前提にします。乗っ取りがあればコンソールだけでなく、運用者のLLM、SSH、クラウド資格情報、保存セッションも調査。詳しい対応はAPI公開リスク対応プレイブックを参照してください。

最初の1時間、監視の担当、復旧の条件はARTEX対応プレイブックにまとめています。

出典・レビュー・限界

2026年11月4日UTC：フレームワークへ拡張。 前回の4本と初版10本のクエリは既存URLから引き続きダウンロードできます。過去の合成通信試験は初版10本だけの結果です。今回の14本はSentinel、Falcon、本番テナントでは未実行。KQL 7本はMicrosoft.Azure.Kusto.Language 12.4.1の構文解析を通過しましたが、ワークスペースのスキーマ結合や検索結果の試験ではありません。Falcon CQLは静的レビューのみです。

[R] 提供された参考文： RST Labs「Tempo, not technique: hunting the AI harnesses behind today's intrusions」、2026年11月2日。所有者から本文を受領し、元のURLは未提供。公開台数、GTIG・ReliaQuest・NorForge・VULONEの事例、評判の観測は参考文が報告した内容として扱い、独立した再現はしていません。GTIG記事のURLは公開フィードで確認しましたが、本文取得は環境のポリシーで拒否されました。
原文を取得： Unit 42のARTEXノート、JPCERT/CCの注意喚起、確認したコミットのCairn、確認したコミットのPentAGI。既定値と設定の説明は、稼働コンソールではなくこれらのソースに基づきます。
二次報道を確認： THNのMicrosoft・Storm-0940報道、THNのCrowdStrike・Vapor Panda報道。ベンダー原文のホストは環境のポリシーで引き続き利用できません。
項目とレビューの参照： MicrosoftのAzure Monitorテーブル定義、CPS項目の規約、neighbor()。実際のパーサー項目と保持期間は導入環境で確認。背景はAI攻撃基盤の分析へ。

コンソールへのアクセス、既定パスワードの試行、全世界の検索・スキャン、ハーネスやマルウェアの実行はしていません。今回新たに行ったのは、ソース確認、手元のアセットのハッシュ計算、KQL構文解析、掲載内容の検証です。結果なしは、利用できる記録が指定した範囲と条件に一致しなかったという意味にとどまります。

AIハーネスを追う：Cairn・ARTEX・PentAGIのハンティングフレームワーク

30秒でわかる要点