Privileged Account Discovery Script: Reduce Privilege Escalation Attacks

Overview

Privileged accounts are accounts on computer systems with more access than standard user accounts. These accounts, for example, can execute processes in the system context, run system-wide services, or modify system configuration files.

Privileged accounts are often targets for privilege escalation attacks, where attackers are able to gain access to network-wide resources after making a beachhead on a system using a standard user account.

The Story of the Discovery Script

There are several great tools out there for discovering and managing privileged accounts. I was determined to find a free tool that would provide the level of detail I was looking for.

After conducting research, I could not find what I was looking for so I decided to write a custom script.

Download Script: Privileged Account Scanner V1

This script focuses on six main types of Windows privileged accounts:

  1. Windows Local Administrator Accounts
  2. Windows Service Accounts
  3. Windows Scheduled Task Accounts
  4. Windows COM+ Application Service Accounts
  5. Windows DCOM Application Service Accounts
  6. Microsoft SQL Accounts

The Script requires Windows PowerShell Remoting to be enabled.

Furthermore, the account you execute the script with must have Local Administrator privileges on the target system, and GRANT CONTROL SERVER on SQL servers.

“I could not find what I was looking for so I decided to write a custom script”

Provide an array of computer names to the parameter ListOfTargets and the script will gather privileged account information on each of the target computers.

The result will be a CSV file generated in the TEMP folder. That path can be modified with the ReportExportPath parameter, as seen in the below command.

.\PrivilegedAccountScanner.ps1 -ListOfTargets “DB01”,”ERPM01” -ReportExportPath “C:\users\SuperAman\desktop\”

Running this command produces a report that looks like this:

In this example report you see examples of most of the types of accounts the script scans for. Below are the columns found in the report and a brief description of each:

  • ComputerName – The computer targeted for scanning.
  • Account – The name of the discovered privileged account.
  • Type – Shows which of the six types of account this account falls under.

The data in the name and note columns will change depending on the type of account.

Additionally, below is an outline of how different account types affect other columns:

  • Local Admins
    Shows “N/A” for name, and the type of account discovered. Above you see that the account is actually a group.
  • Service Accounts
    The Name column shows the service name and the note column shows the service description.
  • Scheduled Tasks
    The name column is the name of the Scheduled task and the note column will display “N/A”.
  • COM+ and DCOM
    Application accounts, the Name column shows the application name and the note column is the application key.
  • SQL Accounts
    The name column shows the associated SQL Instance and the Note column shows a summation of what roles and explicit permissions are assigned to the account./

Customizing Data

You can do further customization of the data your collecting by modifying array variables defined near the top of the script, as shown below.

Broaden or Focus Discovery Scan

The following are arrays that can be modified depending on your reporting needs.

  • The $FilterArray is a list of accounts that are ignored during the discovery scan
  • The $FilterSQLBuiltinAccounts is the list of built in SQL Account to ignore
  • The $SQLPermissions is a list of SQL permissions to look for when scanning SQL
  • The $SQLRoles is a list of SQL roles to look for when scanning. Any SQL users that are members of these roles will be captured

“By adding or removing elements of these arrays, you can broaden or focus your discovery scan.”

Let’s Continue the Conversation

I set out to develop a flexible scanning script that can provide actionable data on privileged accounts in your environment. However, I am sure there are scenarios, configurations, and use cases that I missed.

I look forward to feedback and any requests for additional functionality. Do you have a suggestion? Please leave it in the comments below and we will continue the conversation.

Sincerely,

Aman Motazedian
Senior Consultant
Critical Design Associates

LinkedIn Profile

0 replies

Leave a Reply

Want to join the discussion?
Feel free to contribute!

Leave a Reply

Your email address will not be published. Required fields are marked *