Windowsの権限の悪用手法や、悪用の検知などについて解説されていて良い記事ですね。
medium.com/palantir/windo…:
ーー日本語訳ーー
特権は、Windowsの重要なネイティブセキュリティコントロールです。名前が示すように、特権は、オペレーティングシステム内で特権操作（デバッグ、なりすましなど）を実行する権限をアカウントに付与します。特権と、攻撃者がどのように悪用するかを理解している防御者は、検出と攻撃面の削減機能を強化できます。
このブログ投稿では、特権について簡単に紹介し、その悪用を検出および防止するための推奨事項を紹介します。防御者が特権を保護するために理解する必要のある主要な概念について説明し、監査、検出戦略、および対象となる特権の削除を通じてセキュリティを向上させる方法の例を示します。
Windows特権の概要
特権は、オペレーティングシステム内で特権操作を実行するためにアカウントに付与される権利です。特権（システム関連のリソースに適用される）とアクセス権（セキュリティ保護可能なオブジェクトに適用される）を区別することが重要です。Microsoftは、Access ControlのドキュメントでWindows権限の詳細な説明を提供しています。以下では、最も重要な概念について説明し、虐待からより適切に防御したいかどうかを理解します。
アクセストークン
アクセストークンは、オペレーティングシステムでホストされているセキュリティ保護可能なリソースのすべての承認決定の基盤です。これらは、ローカルセキュリティ機関（LSA）によって承認されたユーザーに付与されます。アクセストークンには、ユーザーのセキュリティ識別子（SID）、グループSID、特権、整合性レベル、およびその他のセキュリティ関連情報が含まれます。
ユーザーが作成したすべてのプロセスまたはスレッドは、トークンのコピーを継承します。このトークンは、セキュリティ保護可能なオブジェクトにアクセスするとき、またはオペレーティングシステム内で特権アクションを実行するときに、アクセスチェックを実行するために使用されます。
アクセストークンは、プライマリトークン または偽装トークンとして存在する場合があります。プライマリトークンは説明どおりに機能し、プロセスまたはスレッドのデフォルトのセキュリティ情報を提示するために使用されます。
偽装により、スレッドは別のユーザーまたはクライアントからのアクセストークンを使用して操作を実行できます。偽装トークンは通常、クライアント/サーバー通信で使用されます。たとえば、ユーザーがSMBファイル共有にアクセスする場合、サーバーは、ユーザーが十分な権限を持っていることを検証するためにユーザーのトークンのコピーを必要とします。実行中のサーバー側スレッドには、スレッドのプライマリトークンに加えてユーザーの偽装トークンが含まれており、偽装トークンを使用してユーザーのアクションのアクセスチェックを実行します。
制限付きアクセストークン
制限付きトークン（フィルターされた管理トークンとも呼ばれます）は、特権または権限を制御するように変更されたプライマリトークンまたは偽装トークンのサブセットです。制限付きアクセストークンにより、システムは特権を削除したり、拒否のみのアクセス制御エントリを追加したり、その他のアクセス権の変更を実行したりできます。
最初のトークン作成プロセス中にユーザーアカウント制御（UAC）が実行されていると仮定すると、LSAは、ユーザーが特権グループのメンバーであるか、IsTokenRestricted関数と同様の機能を使用して機密特権を付与されているかを識別しようとします。制限付きSIDが存在すると、特権が制限された新しいアクセストークンを生成する呼び出しが発生します。
制限付きアクセストークンの例を次のスクリーンショットに示します。
問題のユーザーはローカル管理者ですが、昇格されていないcmd.exeシェルは、少数の特権のみに制限されたトークンを保持しています。管理者として実行するために昇格されると、プロセスはより多くの特権のリストを持つユーザーのプライマリトークンを保持します。
プライマリトークンは、Process Explorerでも検査できます。次のスクリーンショットは、昇格されていないプロセスに接続された制限付きアクセストークンを示しています。
次のスクリーンショットは、昇格されたプロセスにアタッチされたプライマリアクセストークンを示しています。
一般的に乱用される特権
Microsoftは、Windowsの特権定数の概要を示すドキュメントを提供しています。これらの権限は、ユーザーに直接割り当てることも、グループメンバーシップを介して継承することもできます。これらの特権の多くは悪用される可能性がありますが、悪意のあるソフトウェアや攻撃者のトレードクラフトで最も一般的に悪用される特権定数は次のとおりです。
- SeBackupPrivilege
説明：この特権により、システムは、ファイルに指定されたアクセス制御リスト（ACL）に関係なく、すべてのファイルへのすべての読み取りアクセス制御を許可します。
攻撃者Tradecraft：コレクション。 - SeCreateTokenPrivilege
説明：プライマリトークンを作成するために必要です。
攻撃者Tradecraft：特権エスカレーション - SeDebugPrivilege
説明：別のアカウントが所有するプロセスのメモリをデバッグおよび調整するために必要です。
攻撃者Tradecraft：特権エスカレーション。防衛回避; 資格情報へのアクセス - SeLoadDriverPrivilege
説明：デバイスドライバーをロードまたはアンロードするために必要です。
攻撃者Tradecraft：持続; 防衛回避 - SeRestorePrivilege
説明：復元操作を実行するために必要です。この特権により、システムは、ファイルに指定されたACLに関係なく、すべてのファイルへのすべての書き込みアクセス制御を許可します。
攻撃者Tradecraft：持続; 防衛回避 - SeTakeOwnershipPrivilege
説明：任意アクセスを許可されずにオブジェクトの所有権を取得する必要があります。
攻撃者Tradecraft：持続; 防衛回避; コレクション - SeTcbPrivilege
説明：この特権は、その所有者を信頼されたコンピューターベースの一部として識別します。一部の信頼できる保護サブシステムには、この特権が付与されています。
攻撃者Tradecraft：特権エスカレーション
特権の監査と削除
特権のいくつかの主要な概念を示したので、代表的な例である、デバッグプログラム特権（SeDebugPrivilege）の悪用の識別と軽減について見ていきましょう。
SeDebugPrivilegeは、プロセスが他のプロセスのメモリを検査および調整することを可能にし、長い間 セキュリティ上の懸念事項でした。SeDebugPrivilegeを使用すると、セキュリティ記述子に関係なく、トークンベアラーが任意のプロセスまたはスレッドにアクセスできます。Windows資格情報取得ツールのLsadumpは、この手法を使用して、ローカルシステム権限（LSASS）のメモリ空間への読み取りアクセスをプロセスに提供します。マルウェアはまた、この特権を悪用して、信頼できるプロセスへのコードインジェクションを実行します。ターゲットプロセスで新しいリモートスレッドを作成できるためです。
SeDebugPrivilegeには多くの正当な使用例があります。多くの管理ツールは、トラブルシューティングやプロファイリングのために他のプロセスのメモリを検査する必要があります。同様に、システムで実行中のプロセスに独自のコードを挿入する多くの商用アプリケーションでは、正当な理由によりSeDebugPrivilegeが必要です。（たとえば、Symantec Endpoint ProtectionがSeDebugPrivilegeに依存する方法を説明するこの記事を参照してください。）
SeDebugPrivilegeとマルウェアでの使用に関する追加のコンテキストは、いくつかの本と出版物に記載されています。私たちが参照したもののいくつかは、Art of Memory Forensics （ページ：173、186、197–199）、Malware Analysts Cookbook （ページ：58、231、589）およびWindows Malware Analysis Essentials（ページ：143）でした。
特権監査の有効化
次に、潜在的な特権の乱用を識別するために必要なイベントを収集するための手法として監査を見てみましょう。Palantirでは、中央の場所で監査ログを収集するために、ネイティブのWindowsイベント転送（WEF）を使用しています。WEFをデプロイする場合は、以前のブログ投稿とGitHubリポジトリで構成と管理の詳細を確認してください。
Windows 10およびServer 2016のネイティブイベントログ機能は、オペレーティングシステム内での特権の使用の監査をサポートしています。両方の監査機密特権使用と非機密特権の使用は、グループポリシーオブジェクト（GPO）を使用して有効とWEFのサブスクリプションを介して収集することができます。また、新しいログオンに割り当てられた特別な特権を監査して、特権アクセストークンが作成されている場所を特定することも重要です。
ほとんどの環境では、機密特権の使用に関連するイベントのみを収集し、バックアップおよび復元特権の使用の監査を無効にすることをお勧めします。これらの手法は、収集、永続化、および防御回避手法の一部として悪意のある俳優によって使用される可能性がありますが、非常に多くのイベントを作成します。
適切な監査GPOが適用されると、次の特権の使用が収集されます。
- オペレーティングシステムの一部として機能
- トークンオブジェクトを作成する
- プログラムのデバッグ
- コンピューターおよびユーザーアカウントを委任に対して信頼できるようにする
- セキュリティ監査を生成する
- 認証後にクライアントを偽装する
- デバイスドライバーのロードとアンロード
- 監査とセキュリティログの管理
- ファームウェア環境値を変更する
- プロセスレベルのトークンを置き換える
- ファイルまたはその他のオブジェクトの所有権を取得する
特権の使用法の特定
イベントログが一元化された場所に収集されたので、ターゲットを絞った検索により、悪用される可能性のある特権プリミティブを特定できます。
イベントコード4672（新しいログオンに割り当てられた特別な特権）でイベントを収集しているので、フリート全体で検索を実行して、SeDebugPrivilegeを持つユーザートークンが生成される場所を特定できます。イベントの例：
LogName = Security SourceName = Microsoft Windowsセキュリティ監査。 EventCode = 4672 EventType = 0 Type = Information ComputerName = dane TaskCategory = Special Logon OpCode = Info RecordNumber = 17946067 Keywords = Audit Success Message =新しいログオンに割り当てられた特別な特権。件名： セキュリティID： アカウント名：デーン アカウントドメイン： ログオンID：0x5623BE0特権：SeSecurityPrivilege SeTakeOwnershipPrivilege SeLoadDriverPrivilege SeBackupPrivilege SeRestorePrivilege SeDebugPrivilege SeSystemEnvironmentPrivilege SeImpersonatePrivilege SeDelegateSessionUserImpersonatePrivilege
この場合、ユーザーアカウントには、ログオンイベントの一部としてSeDebugPrivilegeが付与されています。これは、このマシンで生成されたユーザートークンが、システムアクセス権を持つ悪意のある俳優によって標的にされ、悪用される可能性があることを示しています。
LogName = Security SourceName = Microsoft Windowsセキュリティ監査。 EventCode = 4703 EventType = 0 Type = Information ComputerName = dane TaskCategory = Authorization Policy Change OpCode = Info RecordNumber = 161204239 Keywords = Audit Success Message =ユーザー権利が調整されました。件名： セキュリティID： アカウント名：デーン アカウントドメイン： ログオンID：0x3E7ターゲットアカウント： セキュリティID： アカウント名：デーン アカウントドメイン： ログオンID：0x3E7プロセス情報： プロセスID：0xa64 プロセス名：C：\ WINDOWS \ System32 \ WindowsPowerShell \ v1.0 \ powershell.exe有効な権限： SeDebugPrivilege無効な権限： -
この例では、ユーザーアカウントトークンが変更され、SeDebugPrivilegeが有効になっています。本質的に悪意はありませんが、これは、PowerShellバイナリを使用してコードインジェクションまたは保護された資格情報へのアクセスを実行する攻撃者の活動を示している可能性があります。
最後に、イベントID 4673（特権サービスが呼び出されました）および4674（特権オブジェクトで操作が試行されました）には、追加のコンテキストまたは他の特権呼び出しが含まれている可能性があります。4673イベントの例：
LogName = Security SourceName = Microsoft Windowsセキュリティ監査。 EventCode = 4673 EventType = 0 Type = Information ComputerName = dane TaskCategory = Sensitive Privilege Use OpCode = Info RecordNumber = 93434404 Keywords = Audit Failure Message =特権サービスが呼び出されました。件名： セキュリティID： アカウント名：デーン アカウントドメイン： ログオンID：0xADF23180Dサービス： サーバー：セキュリティ サービス名：-プロセス： プロセスID：0xf818 プロセス名：C：\ Windows \ System32 \ WindowsPowerShell \ v1.0 \ powershell.exeサービスリクエスト情報： 権限： SeTcbPrivilege
この例では、特権SeTcbPrivilegeがPowerShellバイナリによって通常のユーザーとして呼び出されました。攻撃者はSeTcbPrivilegeを悪用して、偽装で使用される追加の特権または機能を備えた新しいトークンを生成できます。
フリート全体の特権の削除
SeDebugPrivilegeイベントログを分析し、安全に削除できることを確認したので、削除を実行して、この特権を必要とするユーザーのみが確実に削除できるようにします。
まず、Active Directoryにセキュリティグループを作成します（SeDebug-Exceptions-sg）。セキュリティグループに追加されたユーザーは引き続きシステムでSeDebugPrivilegeを使用できます（たとえば、システムレベルのデバッグを実行する管理者）一方で、他のユーザーは特権（たとえば、採用、ヘルプデスク）を失います。
次に、グループポリシーオブジェクト（GPO）を生成し、「デバッグプログラム」の特権のみをSeDebug-Exceptions-sgグループのユーザーに割り当てるように構成します。この設定は、コンピューターの構成\ Windowsの設定\セキュリティの設定\ローカルポリシー\ユーザー権利の割り当てで構成できます。
次に、GPOを展開して、セキュリティフィルタリングを使用して、フリート全体のマシンとユーザーをテストします。
テストと検証
テスト艦隊に展開されたら、テストと検証を実施して、悪影響や問題を特定します。Windowsセキュリティから派生したデータを使用して、影響を受ける可能性のあるユーザーアカウントのきめ細かなホワイトリストを作成します。テストフェーズの最後では、特定のレポートや問題は特定されず、変更によるものでもありませんでした。次に、特権の削除GPOを残りの艦隊に適用できます。
以下の画像は、私たちのマシンの1つからの管理プロンプトです。管理者特権のcmd.exeプロセスに関連付けられている場合でも、SeDebugPrivilegeはトークンに存在しないことに注意してください。
Windowsイベントとホストベースのスクリプトの組み合わせを使用して、艦隊が変更を受信して安定していることを検証できるまで、SeDebugPrivilegeの監視と追跡を続けます。
問題と制限
最後に、ここで説明する特権の削除手法の制限について説明します。
まず、悪用に脆弱なすべての特権（SeBackupPrivilege、SeImpersonatePrivilegeなど）を削除できるわけではありません。この手法は、万能薬ではなく多層防御戦略の多くのレイヤーの1つと考える必要があります。
次に、特権を変更してもシステムレベルのアカウントは制限されません。オペレーティングシステムと関連ツールが機能するためには、これらの権限が必要であり、取り消すことはできません。この例は、SYSTEMユーザーのプライマリアクセストークンに関連付けられた特権の次のスクリーンショットです。このようなアクションは検出とアラートでキャプチャされますが、システムの特権を取得するための絶対的な停止はないことを言及することが重要です。
この例では、管理者ユーザーがpsexecを実行して、cmd.exeシェルをNT AUTHORITY \ SYSTEMとして起動しました。トークンに関連付けられた特権テーブルにSeDebugPrivilegeが存在することに注意してください。ユーザーにマシンへの管理者権限が付与されている場合、このセキュリティ制御をバイパスするメカニズムは複数あります。
結論
提示された手法は、それ自体が決定的な攻撃者を追跡するものではありませんが、自動マルウェア機能をシャットダウンし、すぐに使用可能な攻撃者ツールを破壊することができる貴重な多層防御コントロールです。特権と攻撃者が特権を悪用する方法を理解した武装勢力は、艦隊の強化された検出機能と攻撃面の削減機能を開発および実装できます。
ーー英語原文ーー
Privileges are an important native security control in Windows. As the name suggests, privileges grant rights for accounts to perform privileged operations within the operating system: debugging, impersonation, etc. Defenders who understand privileges and how attackers may abuse them can enhance their detection and attack surface reduction capabilities.
In this blog post, we give a brief introduction to privileges and share our recommendations for detecting and preventing their abuse. We walk through the key concepts a defender needs to understand to protect privileges, and provide an example on how to improve security through auditing, detection strategies, and targeted privilege removal.
Introduction to Windows privileges
A privilege is a right granted to an account to perform privileged operations within the operating system. It’s important to distinguish between privileges (which apply to system-related resources) and access rights (which apply to securable objects). Microsoft provides a detailed explanation of Windows privileges in their Access Control documentation. Below, we walk through the most important concepts to understand if you want to better defend against abuse.
Access tokens
Access tokens are the foundation of all authorization decisions for securable resources hosted on the operating system. They are granted to authorized users by the Local Security Authority (LSA). The access token includes the user’s security identifier (SID), group SIDs, privileges, integrity level, and other security-relevant information.
Every process or thread created by a user inherits a copy of their token. This token is used by to perform access checks when accessing securable objects or performing privileged actions within the operating system.
Access tokens may exist as primary tokens or impersonation tokens. Primary tokens function as described and are used to present the default security information for a process or thread.
Impersonation allows for a thread to perform an operation using an access token from another user or client. Impersonation tokens are typically used in client/server communication. For example, when a user accesses an SMB file share, the server needs a copy of the user’s token to validate that the user has sufficient permissions. The executing server-side thread includes an impersonation token for the user in addition to the thread’s primary token, and uses the impersonation token to perform access checks for the user’s actions.
Restricted access tokens
Restricted tokens (also known as a filtered admin token) are a subset of primary or impersonation tokens that have been modified to control privileges or permissions. Restricted access tokens allow the system to remove privileges, add deny-only access control entries, or perform other access rights changes.
Assuming User Account Control (UAC) is running during the initial token creation process, LSA will attempt to identify if the user is a member of a privileged group or has been granted a sensitive privilege using functionality similar to the IsTokenRestricted function. Presence of a restricted SID will result in a call to produce a new access token with reduced privileges.
An example of the restricted access token can be seen in the following screenshot:
Even though the user in question is a local administrator, the unelevated cmd.exe shell carries a token restricted to only a handful of privileges. When elevated to run as administrator, the process carries the user’s primary token with a larger list of privileges:
The primary token can also be inspected with Process Explorer. The following screenshot shows the restricted access token attached to the unelevated process.
The following screenshot shows the primary access token attached to the elevated process:
Commonly abused privileges
Microsoft provides documentation outlining the privilege constants in Windows. These privileges can be assigned directly to a user or inherited via group membership. While many of these privileges can be abused, the following are the most commonly abused privilege constants in malicious software and attacker tradecraft:
- SeBackupPrivilege
Description: This privilege causes the system to grant all read access control to any file, regardless of the access control list (ACL) specified for the file.
Attacker Tradecraft: Collection. - SeCreateTokenPrivilege
Description: Required to create a primary token.
Attacker Tradecraft: Privilege Escalation - SeDebugPrivilege
Description: Required to debug and adjust the memory of a process owned by another account.
Attacker Tradecraft: Privilege Escalation; Defense Evasion; Credential Access - SeLoadDriverPrivilege
Description: Required to load or unload a device driver.
Attacker Tradecraft: Persistence; Defense Evasion - SeRestorePrivilege
Description: Required to perform restore operations. This privilege causes the system to grant all write access control to any file, regardless of the ACL specified for the file.
Attacker Tradecraft: Persistence; Defense Evasion - SeTakeOwnershipPrivilege
Description: Required to take ownership of an object without being granted discretionary access.
Attacker Tradecraft: Persistence; Defense Evasion; Collection - SeTcbPrivilege
Description: This privilege identifies its holder as part of the trusted computer base. Some trusted protected subsystems are granted this privilege.
Attacker Tradecraft: Privilege Escalation
The “Abusing Token Privileges for LPE” whitepaper provides a comprehensive reference of privilege abuse techniques, refer to section “3.1 — Exploitable Privileges” for more information.
Privilege auditing and removal
Now that we’ve laid out some key concepts of privileges, let’s walk through a representative example: identifying and mitigating abuse of the debug programs privilege (SeDebugPrivilege).
SeDebugPrivilege allows a process to inspect and adjust the memory of other processes, and has long been a security concern. SeDebugPrivilege allows the token bearer to access any process or thread, regardless of security descriptors. The Windows credential harvesting tool Lsadump uses this technique to provide processes with read access to the memory space of the Local System Authority (LSASS). Malware also abuses this privilege to perform code injection into otherwise trustworthy processes, because it permits the creation of new remote threads in a target process.
SeDebugPrivilege does have many legitimate use cases. Many administrative tools need to inspect the memory of other processes for troubleshooting or profiling. Likewise, many commercial applications that inject their own code into running processes on a system require SeDebugPrivilege for legitimate reasons. (For example, see this article that explains how Symantec Endpoint Protection relies on SeDebugPrivilege.)
Additional context on SeDebugPrivilege and its usage in malware can be found in several books and publications. Some of those we referenced were The Art of Memory Forensics (pages: 173, 186, 197–199), Malware Analysts Cookbook (pages: 58, 231, 589) and Windows Malware Analysis Essentials (page: 143).
Enabling privilege auditing
Let’s now look at auditing as a technique for collecting the events necessary to identify potential privilege abuse. At Palantir, we use native Windows Event Forwarding (WEF) in order to collect audit logs in a central location. If you want to deploy WEF, please see our prior blog post and GitHub repository for configuration and management details.
The native event logging facilities in Windows 10 and Server 2016 support auditing privilege use within the operating system. Auditing of both sensitive privilege use and non-sensitive privilege use can be enabled via Group Policy Object (GPO) and collected via WEF subscriptions. Additionally, it’s valuable to audit special privileges assigned to new logons to identify where privileged access tokens are being created.
In most environments we recommend that you collect only events related to sensitive privilege use and disable auditing of the use of backup and restore privileges. While these techniques can be used by a malicious actor as part of collection, persistence, and defense evasion techniques, they create a prohibitively large number of events.
With the correct audit GPO applied, we collect usage of the following privileges:
- Act as part of the operating system
- Create a token object
- Debug programs
- Enable computer and user accounts to be trusted for delegation
- Generate security audits
- Impersonate a client after authentication
- Load and unload device drivers
- Manage auditing and security log
- Modify firmware environment values
- Replace a process-level token
- Take ownership of files or other objects
Identifying privilege usage
Now that event logs have been collected into a centralized location, we can identify potentially abusable privilege primitives through targeted searches.
As we are collecting events with event code 4672 (Special privileges assigned to new logon), we can perform searches across our fleet to identify where user tokens with the SeDebugPrivilege are generated. An example event:
LogName=Security SourceName=Microsoft Windows security auditing. EventCode=4672 EventType=0 Type=Information ComputerName=dane TaskCategory=Special Logon OpCode=Info RecordNumber=17946067 Keywords=Audit Success Message=Special privileges assigned to new logon.Subject: Security ID: Account Name: dane Account Domain: Logon ID: 0x5623BE0Privileges: SeSecurityPrivilege SeTakeOwnershipPrivilege SeLoadDriverPrivilege SeBackupPrivilege SeRestorePrivilege SeDebugPrivilege SeSystemEnvironmentPrivilege SeImpersonatePrivilege SeDelegateSessionUserImpersonatePrivilege
In this instance, the user account was granted the SeDebugPrivilege as part of a logon event. This indicates the user token generated on this machine may be targeted and abused by a malicious actor with system access.
If Authorization Policy Change auditing is enabled, we can additionally receive event notifications when token privileges are enabled or disabled. An example of the 4703 event (A user right was adjusted):
LogName=Security SourceName=Microsoft Windows security auditing. EventCode=4703 EventType=0 Type=Information ComputerName=dane TaskCategory=Authorization Policy Change OpCode=Info RecordNumber=161204239 Keywords=Audit Success Message=A user right was adjusted.Subject: Security ID: Account Name: dane Account Domain: Logon ID: 0x3E7Target Account: Security ID: Account Name: dane Account Domain: Logon ID: 0x3E7Process Information: Process ID: 0xa64 Process Name: C:\WINDOWS\System32\WindowsPowerShell\v1.0\powershell.exeEnabled Privileges: SeDebugPrivilegeDisabled Privileges: -
In this instance, the user account token was modified to enable the SeDebugPrivilege. While not inherently malicious, this could be indicative of adversary activity using the PowerShell binary to perform code injection or protected credential access.
Finally, event IDs 4673 (A privileged service was called) and 4674 (An operation was attempted on a privileged object) may contain additional context or other privilege calls. An example of the 4673 event:
LogName=Security SourceName=Microsoft Windows security auditing. EventCode=4673 EventType=0 Type=Information ComputerName=dane TaskCategory=Sensitive Privilege Use OpCode=Info RecordNumber=93434404 Keywords=Audit Failure Message=A privileged service was called.Subject: Security ID: Account Name: dane Account Domain: Logon ID: 0xADF23180DService: Server: Security Service Name: -Process: Process ID: 0xf818 Process Name: C:\Windows\System32\WindowsPowerShell\v1.0\powershell.exeService Request Information: Privileges: SeTcbPrivilege
In this instance, the privilege SeTcbPrivilege was invoked by the PowerShell binary as a normal user. Adversaries can abuse the SeTcbPrivilege to generate a new token with additional privileges or features that are then used with impersonation.
Removing privileges across the fleet
Now that we’ve analyzed the SeDebugPrivilege event logs and validated they can be removed safely, we perform removal to ensure that only the users who need this privilege have it.
First, we create a security group in Active Directory (SeDebug-Exceptions-sg). Any users added to the security group can continue using the SeDebugPrivilege on their systems (e.g., administrators performing system-level debugging), while any other user loses the privilege (e.g., recruiting, help desk).
Next, we generate a Group Policy Object (GPO) and configure it to only assign the privileges for “Debug Programs” to users in the SeDebug-Exceptions-sg group. The setting can be configured at: Computer Configuration\Windows Settings\Security Settings\Local Policies\User Rights Assignment.
We then deploy the GPO to test machines and users throughout the fleet with security filtering.
Testing and validation
Once deployed to the test fleet, we conduct testing and validation exercises to identify any adverse impact or issues. Using data derived from Windows security, we conduct a granular whitelisting of potentially impacted user accounts. At the end of the test phase, not a single report or issue was identified or attributed to the change. We can then apply the privilege removal GPO to the remainder of the fleet.
The image below is an administrative prompt from one of our machines. Note that the SeDebugPrivilege is no longer present in the token, even when associated with an elevated cmd.exe process:
Using a combination of Windows events and host-based scripts, we continue monitoring and tracking of the SeDebugPrivilege until we can validate the fleet had received the change and is stable.
Issues and limitations
Finally, let’s discuss the limitations of the discussed privilege removal technique.
Firstly, not all privileges that are vulnerable to abuse can be removed (e.g. SeBackupPrivilege, SeImpersonatePrivilege, etc.) This technique should thus be considered one of many layers of a defense-in-depth strategy, not a panacea.
Secondly, modifying privileges does not restrict system-level accounts. In order for the operating system and associated tooling to function, these privileges are required and cannot be revoked. An example of this is the following screenshot of privileges associated with a primary access token for the SYSTEM user. Such an action would be captured in detection and alerting, but it’s important to mention that there’s no hard stop on obtaining the privilege on the system.
In this instance, an administrator user executed psexec to spawn a cmd.exe shell as NT AUTHORITY\SYSTEM. Note the presence of the SeDebugPrivilege in the associated privileges table for the token. If users are granted administrator rights to their machines, there are multiple mechanisms to bypass this security control.
Conclusion
While the presented technique will not by itself stop a determined attacker in their tracks, it is a valuable defense-in-depth control that can shut down automated malware functionality and break some out-of-the-box attacker tooling. Armed with an understanding of privileges and how attackers may abuse them, defenders can develop and implement enhanced detection and attack surface reduction capabilities for their fleets.