First of all let's remember a standart group policy precedence: Local — Site — Domain — Organisation Unit (LSDOU). From less specific level to more specific. It means that Local GPO settings will apply first, then Site-level, Domain-level etc. And the last applied (OU GPO) settings have the highest precedence on the resulting system. However, if a domain administrator didn't set some settings in the higher-level GPOs (e.g. Enable/Disable Windows Defender service) but the same settings have been configured on the Local-level GPO — the last ones will be apply. Yes, even the machine is a domain member.
The Local GPO files are located in %systemroot%System32GroupPolicy hidden folder and, of course, it has two scopes (located in subfolders): for User and for Computer. Any user (here I mean a «bad guy» of course), having access to this folder(s), can copy a Registry.pol file and check/change a Local GPO settings. An intruder can use a third-part apllication, such as a RegPol Viewer:
Or he can copy all %systemroot%System32GroupPolicy subfolders to the his machine and change these settings via standart Group Policy Editor (gpedit.msc) snap-in:
After a settings changing the intruder can copy these files back to the hacked machine and replace the current local policies. At the next time the GP updating process occures, all new GPO settings, including local ones, will be applied. In my example the Windows Defender service becomes turned off:
Well, how to detect these actions of intruder using digital forensics methods? Actually, it's not a big deal if we have a hard disk clone (image) for investigation.
Let's analyze the image of interest with plaso. Usually, if someone with administrative rights changes a Local policy legally, he does it with a standart Windows snap-in. So, we'll obviously detect sequential actions: open mmc.exe -> access Registry.pol & comment.cmtx files:
Also you can check the Microsoft-Windows-GroupPolicy Operational.evtx log file for Event ID 4016 (Windows 10) occured at the same time with Registry.pol changed. Note: as I discovered, only changes were made in Administrative Templates are registering in GPO logs.
If someone bad changes a Local policy files using copy and replace, you'll detect a similar events in plaso rezults:
In this example I've copied all Local policy files manually to the %systemroot%System32GroupPolicy folder (it was a VMware virtual machine, so you can see VMware-DnD folder) and after 10 minutes I've executed gpupdate /force command. You see that Windows Defender state was changed to OFF — because this option I made in Local policy before copying.
Ok, in conclusion — if some unexpected configuration changes were detected on the computer, try to check if it was an intruder-driven Local policy changing or not.
Thank you again for attention! I'll be back soon with a new good stuff!
Автор: volnodumcev
