Process Protection as a Communication Isolation Mechanism Alternative approach – protection level manipulation: If a telemetry component is not "killed," but we elevate it to PP-WinTcb or PPL-WinTcb, it may stop communicating due to kernel security model restrictions: kvc protect DiagTrack PPL WinTcb // Elevate to WinTcb protection level kvc protect utcsvc PP WinSystem // Maximum protection isolation How kernel isolation works: Object Manager Security – PP/PPL processes have limited capabilities to create named pipes or sockets. Token Security Level – inter-process communication requires matching or lower protection levels. Network Stack Isolation – the kernel network subsystem may block TCP/UDP initiation from over-protected processes. Registry/File System ACL enforcement – elevated protection can prevent access to configuration keys. WinSock LSP/TDI filtering – protection level affects network provider chain access. This can be effective The telemetry process still "lives" (doesn’t trigger Defender suspicion). But it cannot send data due to kernel security boundaries. Microsoft likely did not anticipate this as an attack vector. Effectively, it isolates telemetry without killing it. I did not consider this aspect in the original analysis – this is a very advanced use of kernel protection mechanisms as an anti-telemetry technique.
@IXMas System Informer has SystemInformer.sys (288 KB, Microsoft-signed), yet still can't dump LSASS - this reveals the key architectural differences. While System Informer presents itself as a polished, impressive GUI-based tool that looks professional and user-friendly, it's fundamentally designed for different purposes than aggressive memory analysis. KVC Architecture: Aggressive kernel driver: Implements direct memory manipulation techniques User-mode controller: Communicates via custom IOCTL interface with embedded kernel driver extracted from application resources using an obfuscated key (whitespace-padded for steganographic purposes) - driver is concealed within kvc.ico file, invisible to compiler analysis Bypass-focused design: Specifically engineered to circumvent Windows protection mechanisms Unsigned/custom signed: Not constrained by Microsoft signing requirements System Informer Architecture: Conservative kernel driver: Microsoft-signed, adheres to Windows Driver Framework guidelines Monitoring-focused: Designed for system observation rather than memory extraction Policy-compliant: Respects Windows security boundaries (PP/PPL, integrity levels) Production-safe: Built for stability and compliance with Windows security model Aspect KVC System Informer Driver design Aggressive memory access Conservative monitoring PP/PPL handling Active bypass techniques Respects protection policies LSASS access Direct memory extraction Blocked by process protection Signing policy Custom/unsigned (full freedom) Microsoft-signed (constrained) Memory operations Raw physical/virtual access API-mediated access Protection bypass Implements advanced techniques Limited by signing requirements Target use case Security research/red team System administration/debugging Windows compliance Intentionally non-compliant Policy-compliant Key insight: Having a kernel driver doesn't automatically grant unlimited access. Microsoft-signed drivers must adhere to specific behavioral constraints and cannot implement aggressive bypass techniques that would violate Windows security model. KVC's advantage lies in its unrestricted kernel implementation, allowing direct manipulation of protected memory structures that legitimate, signed drivers cannot touch. The fundamental difference isn't just Ring-0 vs Ring-3, but rather compliant kernel access vs unrestricted kernel manipulation. P.S Currently exploring Ring -1 territory: I'm working on UEFI-level persistence mechanisms that operate below the kernel layer, targeting signed but vulnerable EFI drivers rather than revoked certificates. The approach involves leveraging legitimate, trusted EFI components to establish pre-boot execution - similar to BlackLotus methodology but utilizing currently valid trust chains. This represents the next evolution beyond kernel-mode access: hypervisor-level control established before Windows even loads.
@ASA 2's concept is not only correct but absolutely elegant - instead of brutally killing telemetry processes, we can use the system's own security mechanisms against it by creating a "golden cage" for telemetry components. This direction is spot-on. Isolation through protection escalation (PPL) is incredibly effective. The program directly manipulates the _EPROCESS structure in kernel space, modifying the Protection field (which is of type _PS_PROTECTION). By granting telemetry processes PPL-WinTcb level (the highest possible "personality" level - Trusted Computing Base), we achieve several key effects: IPC Isolation (Inter-Process Communication): A process with higher Signer level (e.g., WinTcb) cannot open a handle to a process with lower Signer level (e.g., Windows) with rights like PROCESS_VM_WRITE or PROCESS_CREATE_THREAD. This prevents other "normal" telemetry processes or Task Scheduler from injecting code or reading memory of the protected process. Communication can only flow "downward". Resource Access Blocking: The protected svchost.exe process with PPL-WinTcb will encounter issues accessing registry keys: If keys used for telemetry configuration (e.g., in HKLM\SOFTWARE\Microsoft\Windows\CurrentVersion\Policies\DataCollection) have ACLs that don't grant access to WinTcb-level processes (and they usually don't, since that's system-level, not telemetry-level), read/write operations will fail with ACCESS_DENIED. Log files: Similar situation may affect directories like C:\ProgramData\Microsoft\Diagnosis. Kernel objects: Creating or opening named pipes, events, mutexes for synchronization with other components may be blocked by the kernel object manager due to protection level mismatches. Dependency Chain Disruption: Windows telemetry isn't just one process - it's an entire ecosystem of services (DiagTrack, dmwappushsvc), scheduled tasks (CompatTelRunner, Consolidator), and ETW providers that must work together. By isolating a key element (the service host), you break these connections. The CompatTelRunner task might launch, but won't be able to establish communication with the already-running, protected svchost process hosting DiagTrack to pass data to it. Target Processes Worth Considering (Target Map) Here's a list of processes/services that are the pillars of telemetry in the latest Windows 11 builds. Isolating these processes can provide maximum effect with minimal risk of system destabilization. When expanding the program, always check tasklist /svc for PID to ensure that a given svchost process hosts only the target telemetry service, not critical system services. Service Name (Process Name) Description Suggested Protection Level Notes DiagTrack (svchost.exe) Main telemetry engine PPL-WinTcb Your primary target. Isolating this practically paralyzes the entire pipeline. dmwappushservice (svchost.exe) WAP push notification service, used for remote control and device telemetry (MDM) PP-WinSystem Important target, often overlooked. CDPUserSvc / CDPUserSvc_{ID} (svchost.exe) Connected Devices Platform Service. Collects data about devices around you (Bluetooth, WiFi) PP-WinSystem Isolation can improve privacy. TokenBroker (svchost.exe) Though authentication-related, may collect Microsoft account usage data PP-Windows Use caution, may affect MS service logins. PimIndexMaintenanceSvc (svchost.exe) Indexes and sends data about your contacts, calendar, etc. PP-Windows Key for "experience features", isolation highly recommended. MessagingService / MessagingService_{ID} (svchost.exe) Messaging service, part of notification and telemetry ecosystem PP-Windows Low priority, but worth silencing. Processes you should NOT isolate: Lsass.exe (already PPL-Lsa) - absolutely critical for system security Services.exe - service manager. Isolating it may prevent all services from starting Wininit.exe - responsible for system initialization Sihost.exe, RuntimeBroker.exe - processes related to shell and UWP apps. Isolating them may make the system unusable 100% Effectiveness Verification - Advanced Monitoring To have absolute certainty that no data is leaking, use these tools: Microsoft Network Monitor 3.4 or Wireshark: Start network traffic capture Apply filter: ip.dst == 52.184.215.195 || ip.dst == 52.178.192.105 (example addresses for vortex-win.data.microsoft.com - worth updating the list via nslookup vortex-win.data.microsoft.com) If after isolation you see no HTTP/HTTPS packets sent to these addresses, it means complete success Event Viewer: Check logs: Applications and Services Logs > Microsoft > Windows > Diagnostics-Performance > Operational Look for errors (Level: Error) related to DiagTrack or EventTrace - these may indicate the service cannot write or send data Process Monitor (ProcMon) from Sysinternals: Set filters: Process Name - is - svchost.exe then Operation - is - RegSetValue Look for attempts to write to telemetry-related registry keys (containing DataCollection, Telemetry, DiagTrack). If you see many ACCESS DENIED errors, it's a sign your isolation is working Summary This method is effective, elegant, and hard to detect by protection systems (EDR/AV) because you're not modifying any files on disk, only kernel structures in operational memory. This is exactly how advanced rootkits work - you're using the same power for a righteous cause, for privacy. You're on a very good path. Continue isolating additional processes from the above list, but do it methodically, one at a time, and always monitor system stability and network traffic after each change. I'm planning to implement these automation features directly into the KVC framework: Automatic discovery of PIDs for all key telemetry services Service isolation validation to ensure we're only targeting single-purpose hosts Dynamic command generation for safe protection level assignment The beauty of this approach is that we're not fighting the system - we're making it fight itself. The telemetry processes become their own prison wardens.
Abuse the system against itself Interesting thing ( remind me John week 4 strategy ) If you protect them it will survive reboot ? Or you have to repeat it every start up ? Can we have somehow DLL library for powershell To load it external ?
Protection doesn't survive reboot by default - you'd need to reapply it on each startup. However, KVC already has service installation capabilities (kvc install) that deploys itself as a persistent system service, so implementing automatic telemetry isolation on boot is definitely feasible. Rather than bloating the codebase, I'm considering a configuration-driven approach using an .ini file that defines target services and their desired protection levels. Something like: Code: [TelemetryTargets] DiagTrack=PPL-WinTcb dmwappushservice=PP-WinSystem CDPUserSvc=PP-WinSystem This would let the service auto-apply protection without hardcoding process lists. Alternatively, exposing the protection manipulation as a standalone DLL would allow PowerShell integration or other external tools to leverage the functionality. I'm currently researching process persistence behavior after user logout - it's quite interesting. The kvc shift backdoor (sticky keys replacement) persists beautifully - you can hit 5 shifts after user switching/logout and get your elevated shell. But here's the weird part: the actual telemetry processes themselves get terminated after some time, even when under PPL protection. This seems to be some Microsoft idiosyncrasy - their process lifecycle management wasn't designed to handle "working on a logged-out system" scenarios. I suspect I'll need to implement assembly trampolines to "confuse the process killer" and maintain persistence. The protection mechanism works perfectly while processes are running, but something in the session management stack is still hunting them down. It's an unusual edge case that probably wasn't anticipated in the original PPL design – most legitimate PPL processes (like antimalware) need to persist across user logouts.
Using "C:\ProgramData\Microsoft\Windows\Start Menu\Programs\Startup\svchost.cmd" for now. svchost.cmd Code: @echo off PowerShell -C (Get-Process svchost).Id > C:\log.txt For /F "usebackq delims=" %%0 in ("C:\log.txt") do ( echo %%0 call C:\kvc\kvc.exe protect %%0 PPL WinTcb ) net stop AudioSrv net start AudioSrv
Test code to disable telemetry: Code: <# .SYNOPSIS Smart isolation of Windows telemetry services through Process Protection Level (PPL) manipulation. .DESCRIPTION This script identifies and generates commands to isolate Windows telemetry services by elevating their Process Protection Level (PPL) using the kvc tool. It carefully analyzes service hosting to avoid isolating critical system processes. .NOTES Author: wesmar Requires: Administrative privileges, kvc tool in PATH Version: 1.0 #> #Requires -RunAsAdministrator function Get-TelemetryServices { <# .SYNOPSIS Retrieves Windows services known to be involved in telemetry data collection. #> $servicePatterns = @( 'DiagTrack', 'diagnosticshub', 'dmwappushservice', 'CDPUserSvc', 'CDPUserSvc_*', 'PimIndexMaintenanceSvc', 'TokenBroker', 'MessagingService', 'MessagingService_*' ) $allServices = Get-CimInstance -ClassName Win32_Service $targetServices = $allServices | Where-Object { $svc = $_ $servicePatterns | Where-Object { $svc.Name -like $_ } } return $targetServices } function Get-ServicesByProcess { param($ProcessId) <# .SYNOPSIS Retrieves all services hosted by a specific process ID. #> Get-CimInstance -ClassName Win32_Service | Where-Object { $_.ProcessId -eq $ProcessId } } function Test-CriticalService { param($ServiceName) <# .SYNOPSIS Checks if a service is considered critical for system operation. #> $criticalServices = @( 'EventLog', 'LSM', 'WinDefend', 'SecurityHealthService', 'RpcSs', 'DcomLaunch', 'PlugPlay', 'Power' ) return $criticalServices -contains $ServiceName } function Get-RecommendedProtectionLevel { param($ServiceName) <# .SYNOPSIS Returns the recommended protection level for a telemetry service. #> $protectionMap = @{ 'DiagTrack' = 'PPL WinTcb' 'dmwappushservice' = 'PP WinSystem' 'CDPUserSvc*' = 'PP WinSystem' 'PimIndexMaintenanceSvc' = 'PP Windows' 'TokenBroker' = 'PP Windows' 'MessagingService*' = 'PP Windows' } foreach ($pattern in $protectionMap.Keys) { if ($ServiceName -like $pattern) { return $protectionMap[$pattern] } } return 'PP Windows' # Default fallback } function Invoke-TelemetryIsolationAnalysis { <# .SYNOPSIS Main function that analyzes telemetry services and generates isolation commands. #> Write-Host "Identifying telemetry services..." -ForegroundColor Cyan $telemetryServices = Get-TelemetryServices if (-not $telemetryServices) { Write-Host "No telemetry services found or they are already disabled." -ForegroundColor Green return } $results = @() foreach ($service in $telemetryServices) { # Skip non-running services if ($service.State -ne 'Running') { Write-Host "Skipping $($service.Name) - not running" -ForegroundColor Gray continue } # Get process details $processId = $service.ProcessId $processName = (Get-Process -Id $processId -ErrorAction SilentlyContinue).Name if (-not $processName) { Write-Host "Skipping $($service.Name) - process not found (PID: $processId)" -ForegroundColor Yellow continue } # Get all services in this process $hostedServices = Get-ServicesByProcess -ProcessId $processId $hasCriticalService = $false foreach ($hostedService in $hostedServices) { if (Test-CriticalService -ServiceName $hostedService.Name) { $hasCriticalService = $true Write-Host "WARNING: Process $processId ($processName) hosts critical service: $($hostedService.Name)" -ForegroundColor Red break } } if ($hasCriticalService) { Write-Host "Skipping $($service.Name) - shares process with critical service" -ForegroundColor Red continue } # Recommend protection level $protectionLevel = Get-RecommendedProtectionLevel -ServiceName $service.Name # Add to results $results += [PSCustomObject]@{ ServiceName = $service.Name DisplayName = $service.DisplayName ProcessId = $processId ProcessName = $processName ProtectionLevel = $protectionLevel Command = "kvc protect $processId $protectionLevel" } Write-Host "Found: $($service.Name) (PID: $processId) - Recommended: $protectionLevel" -ForegroundColor Green } # Display results and generate commands if ($results) { Write-Host "`nRecommended isolation commands:" -ForegroundColor Cyan Write-Host "=================================" -ForegroundColor Cyan foreach ($result in $results) { Write-Host $result.Command -ForegroundColor White } # Option to save to batch file $saveToFile = Read-Host "`nSave commands to batch file? (y/n)" if ($saveToFile -eq 'y') { $commands = $results | ForEach-Object { $_.Command } $commands | Out-File -FilePath "TelemetryIsolationCommands.bat" -Encoding ASCII Write-Host "Commands saved to TelemetryIsolationCommands.bat" -ForegroundColor Green } } else { Write-Host "No safe isolation targets found." -ForegroundColor Yellow } } # Execute the analysis Invoke-TelemetryIsolationAnalysis Usage Instructions Prerequisites: Run PowerShell as Administrator Ensure the kvc tool is in your system PATH Execution: .\TelemetryIsolationAnalyzer.ps1Set-ExecutionPolicy -ExecutionPolicy RemoteSigned -Scope Process Save as bat and run... results: Code: PowerShell 7.5.3 PS C:\Windows\System32> Set-ExecutionPolicy -ExecutionPolicy RemoteSigned -Scope Process PS C:\Windows\System32> .\TelemetryIsolationAnalyzer.ps1 Identifying telemetry services... Found: DiagTrack (PID: 5440) - Recommended: PPL WinTcb Skipping dmwappushservice - not running Found: TokenBroker (PID: 10424) - Recommended: PP Windows Found: CDPUserSvc_1a491c7d (PID: 11524) - Recommended: PP WinSystem Skipping MessagingService_1a491c7d - not running Recommended isolation commands: ================================= kvc protect 5440 PPL WinTcb kvc protect 10424 PP Windows kvc protect 11524 PP WinSystem Save commands to batch file? (y/n): y Commands saved to TelemetryIsolationCommands.bat PS C:\Windows\System32> .\TelemetryIsolationCommands.bat C:\Windows\System32>kvc protect 5440 PPL WinTcb [+] Found PsInitialSystemProcess offset: 0xfc5aa8 [+] Found UniqueProcessId offset: 0x1d0 [+] Found ProcessProtection offset: 0x5fa [*] Initializing kernel driver component... [+] TrustedInstaller token cached successfully [+] Kernel driver component initialized successfully [-] PID 5440 is already protected [*] Starting atomic cleanup procedure... [+] Atomic cleanup completed successfully C:\Windows\System32>kvc protect 10424 PP Windows [+] Found PsInitialSystemProcess offset: 0xfc5aa8 [+] Found UniqueProcessId offset: 0x1d0 [+] Found ProcessProtection offset: 0x5fa [*] Initializing kernel driver component... [+] TrustedInstaller token cached successfully [+] Kernel driver component initialized successfully [+] Protected PID 10424 with PP-Windows [*] Starting atomic cleanup procedure... [+] Atomic cleanup completed successfully C:\Windows\System32>kvc protect 11524 PP WinSystem [+] Found PsInitialSystemProcess offset: 0xfc5aa8 [+] Found UniqueProcessId offset: 0x1d0 [+] Found ProcessProtection offset: 0x5fa [*] Initializing kernel driver component... [+] TrustedInstaller token cached successfully [+] Kernel driver component initialized successfully [+] Protected PID 11524 with PP-WinSystem [*] Starting atomic cleanup procedure... [+] Atomic cleanup completed successfully PS C:\Windows\System32> kvc list [+] Found PsInitialSystemProcess offset: 0xfc5aa8 [+] Found UniqueProcessId offset: 0x1d0 [+] Found ProcessProtection offset: 0x5fa [*] Initializing kernel driver component... [+] TrustedInstaller token cached successfully [+] Kernel driver component initialized successfully -------+------------------------------+---------+-----------------+-----------------------+-----------------------+-------------------- PID | Process Name | Level | Signer | EXE sig. level | DLL sig. level | Kernel addr. -------+------------------------------+---------+-----------------+-----------------------+-----------------------+-------------------- 4 | System [NT Kernel Core] | PP (2) | WinSystem (7) | Kernel (0x1e) | System (0x1c) | 0xffffac8b084ee040 188 | Secure System | PP (2) | WinSystem (7) | None (0x00) | None (0x00) | 0xffffac8b086f3040 232 | Registry | PP (2) | WinSystem (7) | None (0x00) | None (0x00) | 0xffffac8b08ae9040 704 | smss.exe | PPL (1) | WinTcb (6) | Critical (0x3e) | Standard (0x0c) | 0xffffac8b15f1a040 1040 | csrss.exe | PPL (1) | WinTcb (6) | Critical (0x3e) | Standard (0x0c) | 0xffffac8b1fd66240 1144 | wininit.exe | PPL (1) | WinTcb (6) | Critical (0x3e) | Standard (0x0c) | 0xffffac8b228c7080 1164 | csrss.exe | PPL (1) | WinTcb (6) | Critical (0x3e) | Standard (0x0c) | 0xffffac8b22908240 1272 | services.exe | PPL (1) | WinTcb (6) | Critical (0x3e) | Standard (0x0c) | 0xffffac8b229e6080 1312 | lsass.exe | PPL (1) | Lsa (4) | Service (0x3c) | App (0x08) | 0xffffac8b22a35080 3936 | Memory Compression | PP (2) | WinSystem (7) | None (0x00) | None (0x00) | 0xffffac8b2389e040 5440 | svchost.exe | PPL (1) | WinTcb (6) | App (0x08) | App (0x08) | 0xffffac8b24487080 6316 | MpDefenderCoreService.exe | PPL (1) | Antimalware (3) | WinSystem (0x37) | WinSystem (0x07) | 0xffffac8b24736080 6940 | MsMpEng.exe | PPL (1) | Antimalware (3) | WinSystem (0x37) | WinSystem (0x07) | 0xffffac8b2517d0c0 10424 | svchost.exe | PP (2) | Windows (5) | None (0x00) | None (0x00) | 0xffffac8b26504080 17136 | SecurityHealthService.exe | PPL (1) | Windows (5) | Service (0x3c) | Standard (0x0c) | 0xffffac8b265cc080 18928 | svchost.exe | PPL (1) | Windows (5) | Service (0x3c) | Standard (0x0c) | 0xffffac8b26ea2080 22656 | NisSrv.exe | PPL (1) | Antimalware (3) | WinSystem (0x37) | WinSystem (0x07) | 0xffffac8b47fe4080 7952 | csrss.exe | PPL (1) | WinTcb (6) | Critical (0x3e) | Standard (0x0c) | 0xffffac8b415f6080 11524 | svchost.exe | PP (2) | WinSystem (7) | None (0x00) | None (0x00) | 0xffffac8b518b9080 -------+------------------------------+---------+-----------------+-----------------------+-----------------------+-------------------- [+] Enumerated 19 protected processes [*] Starting atomic cleanup procedure... [+] Atomic cleanup completed successfully PS C:\Windows\System32> netstat -ano | findstr 5440 PS C:\Windows\System32> Code: PowerShell 7.5.3 PS C:\Windows\System32> sc query DiagTrack SERVICE_NAME: DiagTrack TYPE : 10 WIN32_OWN_PROCESS STATE : 4 RUNNING (STOPPABLE, NOT_PAUSABLE, ACCEPTS_PRESHUTDOWN) WIN32_EXIT_CODE : 0 (0x0) SERVICE_EXIT_CODE : 0 (0x0) CHECKPOINT : 0x0 WAIT_HINT : 0x0 PS C:\Windows\System32> reg query "HKLM\SYSTEM\CurrentControlSet\Services\DiagTrack" /v ImagePath HKEY_LOCAL_MACHINE\SYSTEM\CurrentControlSet\Services\DiagTrack ImagePath REG_EXPAND_SZ %SystemRoot%\System32\svchost.exe -k utcsvc -p PS C:\Windows\System32> tasklist /svc /fi "pid eq 5440" Image Name PID Services ========================= ======== ============================================ svchost.exe 5440 DiagTrack PS C:\Windows\System32> Get-WmiObject -Class Win32_Service | Where-Object {$_.ProcessId -eq 5440} | Select-Object Name, DisplayName Name DisplayName ---- ----------- DiagTrack Connected User Experiences and Telemetry PS C:\Windows\System32> netstat -ano | findstr 5440 PS C:\Windows\System32> tasklist /fi "imagename eq DiagTrack.exe" INFO: No tasks are running which match the specified criteria. reg query ...: Shows that the DiagTrack service is configured to run within the shared process svchost.exe (with the group utcsvc). tasklist /svc /fi "pid eq 5440": Confirms that currently the process with PID 5440 is svchost.exe hosting only the DiagTrack service. Get-WmiObject ...: Again confirms that PID 5440 is the DiagTrack service. netstat -ano | findstr 5440: (No results) - This is excellent news! It means that even though the service is running (RUNNING), there are no active network connections. This is strong evidence that the previous isolation is working and effective. The process is "trapped" and cannot send data. tasklist /fi "imagename eq DiagTrack.exe": (No results) - This confirms that DiagTrack is not currently running as a separate .exe process, but is hosted by svchost.exe. But this requires testing, preferably with Wireshark.
@IXMas Why are you posting AI generated slops? For instance, Linux kernel parameter access and its driver model are entirely different from Windows, so citing a LWN.net article doesn't make any sense.
Do you think I have time to search for articles we've written thousands of times for this audience that doesn't understand anything? That's why AI finds them, and he writes better En than me , the prerequisite is that you know what you're looking for. IOCTL, in Linux and Windows both serve as methods for user-mode applications to send device-specific commands to kernel-mode drivers. Linux discussions are perhaps more extensive, that's why. PS: If you don't like my writing, you can always block me like you did before.
@IXMas Dumping context-less contents backed by LLMs is far from actual research. Next time, either come up with something solid, or kindly stop polluting this thread. At this point, you clearly don't know what you're doing. Moreover, I can't personally block you on the basis of how I "like your writing." To put it simply, that's not how a public forum work, period.
if you trust every thing AI generate, as valid, or you read something in wikipedia, and say, valid source. that a big problem And AI, actually make assumption, if they don't have valid knowledge, and give you wrong results, and it won't tell it wrong results so, provide answer based AI, not on real valid source, wrong.!
A temporary small tool to stop Windows Defender/Tamper Protect Tomorrow I'll be adding a command-line option to disable Defender and Tamper Protection. For now, a reboot is still required despite it being just a single byte change in the registry. I might not have chosen the most elegant approach, but it's quickly reversible and effectively stops Defender's service despite multiple guard processes, Tamper Protection, and even the Cerberus watchdog protecting the chain. How it works: The tool manipulates the DependOnService registry value for WinDefend service, switching between RpcSs (active) and RpcSt (inactive). By using registry hive save/load operations with elevated privileges (SE_BACKUP_NAME, SE_RESTORE_NAME, SE_LOAD_DRIVER_NAME), it bypasses real-time protection mechanisms that would normally block direct registry modifications. Technical highlights: Bypasses Tamper Protection and PatchGuard mechanisms No alerts triggered from Windows Security subsystems Clean, reversible operation with automatic cleanup None of the protection mechanisms raise any alerts - they simply fail to detect the change until after reboot. It's a testament to how sometimes the simplest approaches work best against sophisticated protection systems. Download and test: MSE.zip Feel free to test it in your lab environments. The code is straightforward C++ using standard Windows APIs - no obfuscation or exotic techniques needed. Sometimes the old-school registry manipulation still beats modern endpoint protection. Test it on whatever Windows you have and shout if you see any problems.
Darki decide play with MIMI, but mimi fail, as your tool too i was hope to dump lsass and load iit to mimi, well, play time over tried with Administrator Acc, and System Account. etc, its windows 11 LTSC.