Skip to content

08.4.Privilege Escalation and Information gathering detection

Our goal was to configure a system that captures these processes in Windows Event Logs, sends them to Elasticsearch, and then create a Detection rule using KQL in Kibana to trigger alerts when these tools are executed.

🔹 Tools Used

  • whoami.exe: Displays information about the current user, including username, groups, and privileges.

  • net.exe: Manages the local network, including adding/removing users, managing devices and groups, and performing network queries.

🔹 Step 1: Enable Process Creation Auditing

  1. Open Local Security Policy:\ Start > type secpol.msc > Enter

  1. Navigate to:\ Security Settings > Advanced Audit Policy Configuration > System Audit Policies > Detailed Tracking > Audit Process Creation

3) Enable Audit Process Creation → Success

This ensures that every new process is logged in the Event Logs.

🔹 Step 2: Include Command Line in Logs

To capture the full command line along with the program names:

  1. Open Group Policy Editor:\ Start > type gpedit.msc > Enter

  1. Navigate to:\ Computer Configuration > Administrative Templates > System > Audit Process Creation

  2. Enable Include command line in process creation events → Enabled

After this setting, any created process will be logged along with all its arguments.

🔹 Step 3: Verify Log Location

  1. Open Event Viewer:\ Event Viewer > Windows Logs > Security

  2. Look for Event ID 4688, which records every process creation. It contains:

  3. Process name (whoami.exe or net.exe)

  4. Command line used

  5. Filter the logs to find the required processes:

  6. Right click → Filter Current Log

  7. Event ID: 4688

  8. Keywords: whoami.exe or net.exe

🔹 Step 4: Create Detection Rule Using KQL

Open Kibana in your browser:\ https://<kibana-server>:5601

After confirming that the event.code: "4688" logs are successfully received in Kibana, proceed with creating a new Detection Rule to generate alerts when suspicious executions of whoami.exe or net.exe are detected.

🧩 Create a Custom Query Rule

  1. Navigate to:\ Security → Rules → Create new rule → Custom query

  2. Index pattern:

bash winlogbeat-*

  1. Custom KQL Query:

bash (event.code:"4688") and ( ( winlog.event_data.NewProcessName:"*net.exe" and winlog.event_data.CommandLine:( "*user*" or "*group*" ) ) or ( (winlog.event_data.NewProcessName:"*whoami.exe" or winlog.event_data.NewProcessName:"*net.exe") and not winlog.event_data.SubjectUserName:("*\\Administrator" or "Administrator") ) )

⚠️ This refined query helps reduce false positives by excluding executions made by the Administrator account or common parent processes like Explorer, CMD, or PowerShell.

🧠 Rule Description

Triggers an alert when whoami.exe or net.exe are executed in unusual contexts — for example, when used for user or group enumeration, or when run by non-administrative users outside normal interactive sessions.

⚙️ Configuration

  • Severity: Medium

  • Risk Score: 70

  • Schedule:

  • Runs every 5 minutes

  • Additional look-back time: 1 minute

  • Suppression: Optional (can limit alerts per host or user)

  • Timeline Template: None or Default

  • Actions:\ Configure a connector to send alerts via Email, Slack, or Webhook, including device name and command-line details.

Here are some commands for Windows, but be careful that the user is not an admin:

whoami
whoami /priv
net user
net group
net user Administrator

🧩 MITRE ATT\&CK Mapping

  • T1082 – System Information Discovery

  • T1016 – System Network Configuration Discovery

  • T1087 – Account Discovery

📘 Example False Positives

  • System administrators running whoami or net user during routine tasks.

  • Automated scripts or monitoring tools performing legitimate enumeration.

✅ Result

Once this rule is enabled, any suspicious or unauthorized execution of whoami.exe or net.exe on monitored systems will generate an alert, allowing analysts to quickly investigate potential privilege escalation or discovery activity attempts.