Active Directory 内のダイナミックオブジェクト: ステルス性の高い脅威

Active Directoryの「ダイナミックオブジェクト」機能は、攻撃者に完璧な回避手段を提供します。 これらのオブジェクトは、痕跡を残さずに自動的に自己破壊するため、攻撃者はクォータを回避し、アクセスリストを汚染し、クラウドに持続することができます。

ActiveDirectoryでは、管理者はあらかじめ決められた時間になると自動的に削除されるエントリーを作成することができます。 しかし、ダイナミックオブジェクトと呼ばれるこれらのエントリーは、フォレンジックな痕跡を残さない複数の方法で、攻撃者にこっそりと悪用される可能性があります。 これらの脅威の詳細と、組織を保護する方法については、こちらをお読みください。

ダイナミックオブジェクトとは何か？

簡単に言えば、ダイナミックオブジェクトとは、タイマーを内蔵したADオブジェクトのことです。 これを作成する際、TTL（time-to-live）を割り当てます。

• 属性entryTTLはカウントダウン（秒）として機能します。
• カウンタがゼロになると、ADガベージコレクタは即座にオブジェクトを削除します。
• 標準的なADオブジェクトとは異なり、ダイナミックオブジェクトはごみ箱にも移動せず、追跡可能なトゥームストーンも残りません。完全に消失します。

この「トゥームストーン回避」は、攻撃者がダイナミックオブジェクトを悪用した場合に、フォレンジック調査を著しく困難にします。オブジェクトの有効期限が切れると、そのメタデータは完全に消失します。それを復元したり、誰が作成したかを確認する方法はなく、壊れたリンクや未解決となったセキュリティIDのような間接的な成果物だけが残ります。

ダイナミックオブジェクトをより技術的に見る

これらの一時オブジェクトを作成するには、作成時に補助クラスdynamicObjectを指定します。 これは、TTLの期限が切れると、ADガベージ・コレクタ（GC）によってオブジェクトが自動的に削除されるようにスケジュールします。

ダイナミックオブジェクトには、オブジェクトがいつ削除されるかを示す2つの属性があります。 これらは同期していますが、異なるフォーマットで日付を表しています。

• msDS-Entry-Time-To-Die： ディレクトリ内のダイナミックオブジェクトの絶対有効期限を保持します。
• エントリーTTL オブジェクトの自己削除までの秒数を表します。 期間を短縮または延長するために更新することができ、それに応じてmsDS-Entry-Time-to-Dieも更新されます。

前述のように、ダイナミックオブジェクトの有効期限が切れると、それらは完全に削除され、ログ、キャッシュされたKerberosチケット、他のオブジェクトのリンクされた属性などの間接的な成果物だけが残ります。

しかし、ダイナミックオブジェクトは、TTLがゼロになった瞬間にパージされるとは限りません。 我々のテストでは、再起動したばかりのドメインコントローラーでは削除は瞬時に行われましたが、24時間以内のシステムでは最大15分の遅延が観察されました。 セキュリティチームにとって、この遅延は、オブジェクトが永久に削除される前に、フォレンジック調査目的でオブジェクトの属性を検査したりバックアップしたりするための短い猶予時間を生むため、重要です。

ダイナミックオブジェクトは技術的には1秒から1年の間のTTLをサポートしますが、実際の制約はConfigurationパーティションのmsDS-Other-Settings属性で管理されます。 この属性は、許容される最小持続時間(DynamicObjectMinTTL) と、オブジェクト作成時に値が指定されなかった場合に適用される既定の持続時間(DynamicObjectDefaultTTL) の両方をコントローラーします。

ダイナミックオブジェクトは、コンフィギュレーション・パーティションとスキーマ・パーティションではサポートされていません。 これはセキュリティと安定の観点から非常に重要です。Active Directoryの最も機密性の高い領域で、これらの一時的なオブジェクトが使用されることを防ぎます。 例えば、スキーマ・クラスが自動的に消滅した場合、そのクラスに依存しているオブジェクトは破損し、整合性に重大な問題がリードすることになります。

基本的なコンセプトについては、コンサルタントを参照してください。

• https://learn.microsoft.com/en-us/archive/blogs/pfesweplat/ad-object-detection-detecting-the-undetectable-dynamicobject
• https://medium.com/@nannnu/fun-with-dynamic-objects-in-ad-part-1-743c21dd934f

次に、攻撃者がダイナミックオブジェクトをどのように武器化するかを示す6つのシナリオの概要を説明します。

シナリオ1 - マシンアカウントのクォータをバイパスする

デフォルトでは、ms-DS-MachineAccountQuotaは、認証されたユーザが10個のコンピュータオブジェクトを作成することを許可します。 攻撃者は、リソースベースの制約付き委任(RBCD)の悪用やsAMAccountNameなりすまし攻撃(具体的には、攻撃者がドメインコントローラーになりすますためにマシンアカウントの名前を変更するCVE-2021-42278とCVE-2021-42287)のようなテクニックのために、これらのコンピュータアカウントを作成します。

しかし、クォータがいっぱいになると、攻撃者はブロックされ、悪意のあるアカウントは証拠として残ります。 あるいは、攻撃者が特権の昇格に失敗した場合、作成したマシンアカウントを削除することはできません。 これでは、守備側に永久的な証拠を残すことになります。 

しかし攻撃者は、例えばPowerMadを使ってスクリプトを修正し、動的なマシンアカウントを作成することができます。 New-MachineAccount関数は、必要な属性を入力し、マシン・アカウントを作成。 この目的のためにダイナミックオブジェクトを使うには、以下の行を置き換えるだけでよいのです。

$request.Attributes.Add((New-Object "System.DirectoryServices.Protocols.DirectoryAttribute" -ArgumentList "objectClass", "Computer"))> $null

...これで

$request.Attributes.Add((New-Object "System.DirectoryServices.Protocols.DirectoryAttribute" -ArgumentList "objectClass", "dynamicObject", "Computer"))> $null

^{期限切れ属性を強調表示したADダイナミックオブジェクト（コンピュータ）の詳細表示}

攻撃が失敗または終了した場合、マシンアカウントは24時間後に自動的に削除されます。 クォータ・スロットは再使用のために解放され、悪意のあるコンピューター・アカウントの証拠は完全に消えます。

このプロセスをもう少し詳しく見てみましょう。

私たちは、60秒という短いTTLをカスタムで定義しようと試みました。 しかし、標準ユーザーアカウントに適用される特権の制限により、このリクエストは拒否されました。 その結果、TTLを指定せずにリクエストを再送信しなければならなりませんでした。 その結果、システムは、msDS-Other-Settings\DynamicObjectDefaultTTLで定義されているデフォルトの有効期限値（24時間（86,400秒））を適用しました。

この期間が終了すると、マシンアカウントは、標準的な保持メカニズムをバイパスして、静かに完全に削除されます。

注：PowerShellのコード例（Microsoft提供）を使って動的なユーザーやグループを作成すると、Active Directory Users and Computers（ADUC）管理コンソールでentryTTLとmsDS-Entry-Time-To-Die属性の値を見ることができます。
 

^{アクティブなエントリTTLカウントダウンとそれに対応する削除タイムスタンプを示す、ADダイナミックオブジェクト（ユーザー）の属性エディタ・ビュー。}

不思議なことに、MAQ経由で作成されたダイナミック・マシン・アカウントの場合、entryTTL属性はADUC内では表示されません。しかし、LDP.exeによる検証では、この属性が正しく設定されていることが証明されており、マイクロソフト管理コンソール（MMC）の制限を示しています。(同じ "DynMachine "オブジェクトに関連するLDP.exeのスクリーンショットを参照してください）。

^{ADダイナミックオブジェクト（コンピュータ）のAttribute Editorビューで、entryTTL属性が誤って<not set>と表示されます。}

しかし、msDS-Entry-Time-to-Die属性は期待通りに表示されます。
 

^{ADダイナミックオブジェクト（コンピュータ）の属性エディタ・ビューで、msDS-Entry-Time-To-Dieタイムスタンプが表示され、同時にentryTTLが表示されません。}

MAQをゼロに設定することで事実上無効化することです。 Tenable Identity Exposure は、「Users Allowed to Join Computers to the Domain」(IoE) インジケータを介して脆弱な構成にフラグを立てることで、このハードニングプロセスを容易にします。

シナリオ2 - プライマリー・グループIDの破損

この攻撃シナリオでは、攻撃者はユーザーのPGIDをダイナミックグループの相対識別子(RID)に設定することで、primaryGroupID(PGID)属性を利用します。 これは、標準的なツールのmemberOf属性に表示されない暗黙のメンバーシップをユーザーに付与し、一般的な管理ツールで「不可視」にします。 ただし、Kerberosチケットとアクセストークンについては、メンバーシップは完全に機能します。

ダイナミック・グループの有効期限が切れて削除されると、ユーザーには存在しないRIDが残されます。そのため監査が非常に難しくなります。さらに、ADはグループが削除されたときにPGIDを自動的にクリーンアップしないため、ユーザーは存在しないオブジェクトへの壊れた参照を指す破損した属性を残されることになります。

もう少し詳しく見てみましょう。

通常、グループのPGIDをユーザーに割り当てた場合、そのグループを削除することはできません。
 

^{セキュリティグループがユーザー (TestUserPGID) のプライマリグループに設定されているため削除できないことを示す ADUC のエラーメッセージ}

ここで、「PGIDグループ削除の保護は、ダイナミックオブジェクトのTTLよりも優先されるのか」という疑問が生じます。

このシナリオでは、ダイナミック・グループ "DynGroup "を作成し、グループのメンバーとして "TestUserPGID "を追加した。 最後に、「DynGroup」のPGIDを「TestUserPGID」に設定します。

これをテストするために、次のようなコンフィギュレーションを確立しました。

1. DynGroup」というダイナミック・グループを作成。
2. メンバーとして "TestUserPGID "を追加。
3. ユーザー "TestUserPGID "のprimaryGroupIDを更新し、ダイナミック・グループのRIDと一致させる。

まず、標準的な管理ツールを使って手動でグループの削除を試みました。 予想通り、前のテストで見られたのと同じ整合性エラーにより、操作はブロックされました。
 

^{動的グループを削除しようとしたが、現在ユーザーのプライマリグループとして割り当てられているため、削除に失敗しました。}

その後、オブジェクトの有効期限が切れると、ダイナミック・グループはシステムによって自動的に削除されました。 しかし、この削除はユーザーのprimaryGroupID属性のクリーンアップを引き起こしませんでした。 その結果、存在しないオブジェクトを指すようになりました。
 

^{動的プライマリグループの失効後、グループ情報が消失し、MMC 上でプライマリグループが <None> と表示されるユーザーアカウント。}

これは予期せぬ副作用のリスクをもたらします。 少なくとも、これは参照整合性を壊し、ADデータベースに持続性のある "ゴミ "を発生させます。

さらに、このダイナミック・グループが高レベルの権限を持っていた場合、その自動削除は重大なフォレンジック調査のギャップを生むことになります。 ダイナミックオブジェクトは標準的なトゥームストーンのライフサイクルをバイパスするため、守備側はグループ自体の記録を見つけることができません。 この一時的なライフタイムは、ユーザーの特権の起源を不明瞭にし、根本原因の分析とインシデント対応を複雑にします。

このリスクを軽減するために、組織はprimaryGroupID属性の変更を厳しく制限すべきです。 セキュリティチームは、Tenableアイデンティティエクスポージャーを活用して、ユーザプライマリグループIoEを使用して、これらの逸脱を継続的に監視することができます。

シナリオ 3 - オーファン SID と AdminSDHolder の汚染

ダイナミックオブジェクトのライフサイクルを理解すれば、このシナリオが最初に思い浮かぶリスクとなるでしょう。 

その深刻度を示すために、標準的なファイル・サーバーのACLだけを見てはいけません。 AdminSDHolderオブジェクトをターゲットにします。

なぜAdminSDHolderなのでしょうか。このターゲットを選んだのは、ADのすべての特権グループとユーザーのセキュリティ・テンプレートとして機能するからです。ここで追加されたパーミッションは、SDPropプロセスによってすべてのTier-0アカウントに自動的に伝搬されます。その結果、セキュリティツールは、管理者権限を持つ「未解決のSID」（数字の羅列）にフラグを立てます。 調査担当者は誰かがアクセスしたことはわかるが、それが誰なのかは特定できません。 これによって、一時的なオブジェクトひとつが、60分以内にドメインの特権ランドスケープ全体を汚染してしまうことを実証することができます。

そのプロセスをもう少し詳しく見てみましょう。

このテストでは、標準的な削除と動的な期限切れの動作を比較してみましょう：

1. ユーザーを2人作る：
   1. 「User_Standard」： 通常のADユーザー。
   2. 「User_Dynamic」： TTLの短いダイナミックユーザー。
2. AdminSDHolderのACLに、両ユーザーのアクセス制御エントリ（ACE）を追加します。
    

^{一時的なダイナミックユーザーアカウント (Ace[9]) と標準ユーザーアカウント (Ace[10]) に割り当てられた 2 つの ACE を比較するセキュリティ記述子の LDP 表示}

3. 削除:

a. システムによって完全に削除された「User_Dynamic」のTTLが切れるのを待つ。
            b. その直後、"User_Standard "を削除し、ごみ箱/トゥームストーンへ。

では、AdminSDHolder ACLを見てみましょう。
 

^{2つのACEを示すセキュリティ記述子のLDPビュー：期限切れのダイナミックオブジェクト（Ace[9]）に由来する「不明なSID」と、削除済みオブジェクトコンテナ（Ace[10]）内の標準的な削除済みオブジェクトを指すDN。}

通常60分ごとに、AdminSDHolderバックグラウンドタスクは、すべての特権オブジェクトのACLをコンテナのセキュリティ記述子に合わせてリセットします。

• 「User_Standard」： セキュリティツールはSIDにフラグを立てますが、オブジェクトはまだADに存在しているからです。SIDは名前、削除日、その他の属性に解決することができます。
• 「User_Dynamic」： SIDはまったく解決できません。 これは "Orphan SID "です。

これは、SOCアナリストやインシデント対応担当者にとって大きな労力となります。 セキュリティ・ツールは、最も重大な資産に対して「権限が昇格した不明なSID」を報告します。

フォレンジック捜査は直ちに危険にさらされます。

• オブジェクトの回復はない： ダイナミックオブジェクトはごみ箱をスキップするので、復元するオブジェクトはありません。
• トゥームストーンはない: ディレクトリには、オブジェクトのメタデータのフォレンジック調査のトレースはありません。

ブルーチームは、これが単純な設定ミスではなく、破損の問題なのか、ステルス持続性メカニズムなのかを検証するのに時間を浪費します。 これはノイズと混乱を引き起こし、現実の脅威から目をそらすことを意図している可能性があります。

これを捕捉するには、ACLとオブジェクトの状態の関係をリアルタイムで追跡するセキュリティ・モニタリングが必要です。 Tenable Identity Exposureは、「Ensure SDProp Consistency（SDPropの整合性の確保）」など、重大度資産に関する危険なACEを報告する複数のIoEを通じて、このような異常の特定を支援します。 この汚染を即座に浄化することができます。

シナリオ4 - 未解決のgPLink (GPO)とgPCFileSysPathの乱用

このシナリオでは、攻撃者が、攻撃者のコントローラーであるサーバー上の悪意のあるスクリプトを指す動的GPOを作成します。 彼らはこのGPOを組織単位（OU）にリンクさせ、被害者のマシンでコードを実行します。

TTLが切れると、GPOオブジェクトは削除されます。 その結果、 OU上のリンクは残っていますが、GPO自体がなくなっているため、「壊れて」います。 捜査担当者には壊れたリンクだけが残り、解析対象のペイロードは残りません。

もう少し詳しく見てみましょう。

標準的なGPOは、LDAPオブジェクトで表されるグループポリシーコンテナ（GPC）と、SYSVOLフォルダ内のファイル（GPT）の2つの部分から構成されます。 GPCにはgPCFileSysPathと呼ばれる属性があり、実行するファイルの取得先をコンテナに伝えます。

注：これまでのテストとは異なり、ADのごみ箱を有効にして、削除後も標準オブジェクトのgPCFileSysPath値が持続するようにしました。

Synacktivの "GPODDITY "リサーチで詳述されているように、攻撃者はこの属性を変更することで、SYSVOLではなく、悪意のある攻撃者コントローラーのSMB共有を指すようにすることができます。

このなりすまし攻撃とダイナミックオブジェクトを組み合わせることで、攻撃者は次のような攻撃を仕掛けることができます。

1. 攻撃者は動的GPO（dynamicObjectクラスとgroupPolicyContainerクラスを持つ）を作成し、短いTTLを使用します。
2. 彼らはgPCFileSysPath属性を設定し、悪意のあるサーバーを指すようにします。
3. この GPO を機密性の高い組織単位（OU）にリンクするには、OU のgPLink属性を変更します。
4. そのOUのコンピュータはポリシーを更新し、悪意のあるパスを読み、ペイロードを実行します。

前のシナリオと同様に、ダイナミックオブジェクトと標準的なオブジェクトの動作を比較します。
 

^{自己削除する gPCFileSysPath を持つ一時ポリシーが OU にリンクされる様子を示す、標準 GPO と dynamicObject GPO の LDP 比較。}

5. TTLが切れると、システムはGPOオブジェクトを完全に削除します。 標準オブジェクトとの比較を容易にするため、この段階で「StdGpoOu」も削除します。

^{gPLink 属性に期限切れダイナミック GPO を参照し続けている OU と、GPO オブジェクトが完全に削除されたことを示す検索結果の LDP 表示。}

標準GPOが削除されると、ごみ箱か墓標に行きます。 分析者はこれを復元して、実行されたスクリプトやgPCFileSysPathが指し示す場所を確認することができます。

ダイナミックGPOでは、トゥームストーンはありません。 オブジェクトはもうありません。 悪意のあるパス（gPCFileSysPath）を含む属性は破棄されます。 残された唯一の証拠は、もはや存在しないグローバル一意識別子（GUID）を指す、OU上のgPLinkだけです。 分析者は「リンク切れ」を見ますが、この欠落したオブジェクトがコード実行の原因であることを証明する方法はありませんし、ペイロードを分析するために攻撃者のサーバーへの経路を取得することもできません。

Tenable Identity Exposureでは、「GPO Execution Sanity」IoEを介してこれを即座に検出できます。 これらの物体の検出は、スキャンが行われる前に消えてしまうことが多いので難しいです。 その代わりに、彼らが残した痕跡や矛盾を探すことができます。 ダイナミックオブジェクトが GPO であるこのケースでは、単なる LDAP アーティファクト以上のものを残します。「リンクされていない、無効、または未解決の GPO」IoE と同様の方法（オブジェクトそのものではなく、構造的な不整合を探す）を使って特定できます。

シナリオ5 - 一時的なDNSレコード

第5のシナリオでは、攻撃者はダイナミックDNSレコードを作成してトラフィックをリダイレクトし（例えばファイルサーバーになりすまし攻撃）、ADの標準オブジェクトに過ぎないDNSレコードを利用して認証情報を取得することができます。

その結果、被害者のコンピューターはサーバーに問い合わせ、悪意のあるIPアドレスをキャッシュします。 ダイナミックDNSレコードの有効期限が切れ、ADサーバーから消えます。

その結果、被害者は（キャッシュされたIPを使用して）まだ危険にさらされているが、DNSサーバーは完全にきれいに見えます。 アナリストがサーバーのログをチェックしても、悪意のあるエントリーの記録は見つかりません。

もう少し詳しく見てみましょう。

ユーザーやグループと同様に、AD統合DNSレコードはDomainDnsZonesまたはForestDnsZonesパーティションに格納されている標準的なLDAPオブジェクト（クラスdnsNode）です。 コンフィギュレーション・パーティションにもスキーマ・パーティションにも存在しないので、ダイナミックにすることができます。

この機能により、攻撃者はディレクトリに永続的な足跡を残すことなく、正規のサーバーになりすましたり、中間者攻撃（man-in-the-middle technique）により認証情報を取得したりするなど、一時的なトラフィックのリダイレクトを実行できるようになります。

攻撃者はダイナミックDNSレコードを作成し、次のような結果をリードする可能性があります。

1. DNSサーバーはそれを読み、クエリに答えます。
2. クライアントは答えをキャッシュします。

フォレンジック調査への影響を説明するために、標準的なDNSレコードと比較してみましょう。
 

^{dynamicObject として作成された「malicious-dyn-website」レコードを示す DNS マネージャーと LDP の表示比較。}

3. ダイナミックオブジェクトは自己破壊します。

4. 攻撃者が悪意のあるデータをローカルキャッシュに保持する一方で、DNSサーバーは痕跡を完全に消しているため、攻撃は継続されます。

^{ディレクトリから完全削除された期限切れ動的 DNS レコードと、残存する標準 DNS レコードの比較。}

注：それでもDNS Managerにレコードが表示される場合は、DNSキャッシュが原因です。 手動で更新すると、表示が更新され、削除が確認されます。
 

^{ゾーン更新と期限切れレコード削除のために手動実行される「Reload」タスクを示す DNS マネージャー MMC。}

この結果、攻撃者はエンドポイント上で持続するが、発生源となった証拠はインフラにはもはや存在しないという矛盾が生じます。

彼らを追跡するのは簡単ではないからです。

• 標準的なDNSログは、パフォーマンスを低下させるデバッグモードが有効になっていない限り、一時的なレコードを捕捉することはほとんどありません。
• 前のシナリオと同じように、トゥームストーンもなければ、ADの記録もありません。
• 奇妙な接続を調査しているアナリストは、DNSサーバーをチェックし、完全にクリーンなゾーンを見つけるでしょう。

証拠が自壊するため、事後分析が難しくなります。 リアルタイムで設定変更をキャッチしようと試みることはできますが、悪意のある記録と正当な記録を区別することは難しく、誤検出を起こしやすくなります。

最も確実な検出戦略は、異常そのものにフラグを立てることです。 ダイナミックオブジェクトであるDNSレコードを報告します。 これは、ADレプリケーションフローに基づくリアルタイムの検出、またはイベントログで行うことができます。

シナリオ6 - エントラIDのハイブリッド同期ギャップ

この最後のシナリオでは、ダイナミックオブジェクトが、オンプレミスのドメインを越えてEntra IDに拡張する持続性のある成果物を作成する方法を示します。

攻撃者が Active Directory 上で動的ユーザーを作成すると、Microsoft Entra Connect は通常通りそのユーザーをクラウドに同期します。 しかし、Entra Connect のデルタ同期は、削除されたオブジェクトを識別するために「トゥームストーン」に依存しているため、ダイナミックユーザーの期限が切れると検出できません。 

これらのオブジェクトは痕跡を残さずに自己破壊するため、同期エンジンがテナント内の削除をトリガーすることはありません。 その結果、クラウド・ユーザーはクラウド側でアクティブなまま、未解決となり、完全に機能します。

この同期のズレについて詳しく見ていきましょう。

それを視覚化するために、同期化されたダイナミック・ユーザーのライフサイクルと、標準的なユーザーのライフサイクルを比較してみましょう。
 

^{比較のため、dynamicObject（UserForCloudDyn）と標準ユーザー（UserForCloudStd）が Entra ID に同期される様子を示すハイブリッド ID 表示。}

TTLがゼロになると、ダイナミックオブジェクトはトゥームストーンなしで自己削除され、標準オブジェクトを手動で削除して差異を特定します。

^{同期後も、期限切れのオンプレミス動的ユーザー（UserForCloudDyn）が Entra ID 上で有効なままであることを示すハイブリッド ID 表示。}

標準オブジェクトの削除は、Entra ConnectによってEntraユーザーが削除されたEntraテナントにリプリケータされましたが、ダイナミックオブジェクトの削除はされなかったため、同期ギャップが発生しました。

さらに、（パスワードのリセットなど）オブジェクトを管理しようとする試みは、オンプレミス側の元オブジェクトはすでに削除されているにもかかわらず、オブジェクトがクラウド上でまだアクティブで有効であることを証明します。
 

^{管理上のデッドロックを示す Microsoft Entra の管理センター表示：クラウド ID が、すでに有効期限が切れて Active Directory から削除されたオンプレミスソースにリンクされたままであるため、パスワードのリセットがブロックされています。}

注：未解決となった Entra ユーザーは、Entra Connect で手動による完全同期をトリガーすることで、すべての AD オブジェクトを再評価することによってのみ削除できます。

まとめ

ADのダイナミックオブジェクトを悪用すると、標準的だがめったに見られない機能が、フォレンジック調査の悪夢に変わります。 自己削除を活用することで、攻撃者はMAQやDNSスプーフィングのようなメカニズムを悪用しながら、ごみ箱を完全に回避することができます。 その影響は地元だけにとどまりません。この攻撃はクラウドに伝播し、攻撃終了後もEntra IDに同期のずれを生じさせます。

事後分析が非常に困難な場合が多いため、唯一の有効な防御策は積極的に行動することです。 Tenable One Identity Exposure は、IoE(Dynamic Objects Misconfiguration and Usage) 専用で、これらの一時的な脅威を発見し、フォレンジック調査のギャップを埋めるために必要なリアルタイムの可視性を備えています。 このアイデンティティ・ファーストのエクスポージャー・コンテキストをTenable One サイバーエクスポージャー管理プラットフォームに投入することで、企業は、ホストの脆弱性やクラウドのリスクと並んで、これらのステルス・リスクが自動的に優先順位付けされるようにすることができます。 この統一されたアプローチにより、たとえオブジェクトが「自己破壊」したとしても、そのオブジェクトが生み出したリスクの高まりは、アタックサーフェス全体の中ですでに優先順位付けされているため、攻撃者はどこにも隠れることができず、痕跡を消すこともできません。