A common tactic used by pen testers, “red teams”, and threat actors is searching for Group Policy Preference (GPP) files with usernames and passwords.  These XML files, stored in the domain SYSVOL, are used to create local administrator accounts, map drives, create scheduled tasks, and more. This excellent blog by Sean Metcalf discuses what they’re used for, what’s in them, and how to find them.  It’s a must read for new pen testers.

This blog isn’t for pen testers.  I spent a lot of years as a sysadmin.  After that I moved into the defense side of security.  As a result, my heart’s always been with the blue team and I like to give a helping hand when I can.  I’m not aware that I’ve ever been detected on a job when searching for GPP files.  When I’ve found GPP fies with credentials, I haven’t been detected using those creds.  And those creds are most often associated with administrator-level access.

I’ve written a tool to help defenders detect pen testers and bad actors accessing and using these files.  Introducing GPPDeception.  GPPDeception is a PowerShell script that will generate a file designed to look like a GPP file.  The file mimics a legitimate file that would create a local user on machines linked to a specific OU.  Even upon close inspection, the file appears to be legitimate.  The only sign that this file isn’t legitimate is that there isn’t a corresponding Group Policy anywhere in AD.  I’ve never talked to another pen tester who said they checked to see if the GPP file was legitimate.  As an added bonus, the cpassword embedded in the file will decrypt to a real password of your choosing.

Of course, creating a file doesn’t do you any good by itself.  You’ll need to monitor to see if it’s been accessed or if the creds have been used.  File access monitoring requires setting up object access auditing as well as file auditing.  I’ve provided some links on auditing at the end of this article that can help you get started. 

You can also monitor for the use of the creds in the GPP file.  For maximum effectiveness, you’ll want to monitor for the creds both at the DC as well as at endpoints.  Monitoring all endpoints might get pretty noisy, so it might be worth thinking about using a smaller set of hosts in each network segments for detection.

You can download GPPDeception from GitHub: https://github.com/hardwaterhacker/GPPDeception

 

Usage

GPPDeception takes two parameters.  Plaintext is the plaintext password that you want to set for your fake account.  UserName is the name you want to give the fake account.   GPPDeception will create a file, groups.xml, in your current directory.  It will also suggest a GUID to be used for the folder name.  Take the file, create the suggested directories, and place the file there.  In the example output below, the path would be \\example.com\sysvol\example.com\{6C49AACD-C5E8-41E4-BF07-8A06871BD6BB}\Machine\Preferences\Groups\groups.xml

Invoke-GPPDeception -Plaintext ThisIstheFakePassword! -UserName BackupAdmin

Considerations

File Timestamps – One giveway about your deception will be the file timestamps.  When you create this file, the file creation timestamp is obviously going to be whatever day you created the file.  If you’ve installed the MS14-025 patch, a file creation date after the patch was intalled is going to look suspicious.  I doubt many, if any pen testers are looking at the file creation date for GPP files, but it’s still a tell.  The output of GPPDeception includes a timestamp in the changed attribute of the User element.  It might be worth looking into MACB timestamp stomping.  This post from SpecterOps will probably help you in that regard.

File/Folder Auditing – When you’re auditing for access to the file, don’t forget to audit the folder as well as the file.  If you’re auditing for folder access you’ll detect somebody looking for GPP files with findstr /I /S cpassword on the SYSVOL, even if they don’t actually open the file.