How to detect and respond to a suspicious process alert using ADAudit Plus

How to detect and respond to a suspicious process alert using ADAudit Plus

In this article:  

  • Objective

  • Prerequisites

  • Steps to follow

  • Validation and confirmation

  • Tips

  • Related topics and articles

 

 Objective   

This article explains how to use ADAudit Plus to detect a potential threat based on the execution of a suspicious process, understand the immediate remediation steps, and implement long-term prevention strategies.

 Prerequisites   

  • You must have administrator access to the ADAudit Plus web console.

  • Sysmon (System Monitor) must be deployed and configured on the endpoints (servers and workstations) you wish to monitor.

  • ADAudit Plus must be configured to collect and process Sysmon event logs from these endpoints.

 Steps to follow   

The process for handling a Suspicious Process alert involves detection, immediate remediation, and prevention.

 Part 1: Detecting the threat   

  1. Navigate to the Active Directory tab > Attack Surface Analyzer > Threats > Suspicious Process.

  2. This report shows all detections of processes that have started without standard identifying metadata, which is a common characteristic of malware.

 Part 2: Understanding the detection criteria   

ADAudit Plus detects a potential threat based on the following pattern from Sysmon logs:

  • Description: An unverified process has started. The process lacks a company name, product name, and original file name in its file properties.

  • Detection logic (Sysmon):

    • Event code equals 1 (Process Creation).

    • Company equals null.

    • Product equals null.

    • OriginalFileName equals null.

    • User does not contain NT AUTHORITY\SYSTEM.

    • ParentImage (the process that launched this one) does not contain Windows\System32.

 Part 3: Immediate remediation   

A suspicious process alert can indicate the execution of malware. Act immediately.

  1. Isolate the affected machine: The report will identify the machine where the process was executed. Isolate this machine from the network immediately to prevent potential damage or lateral movement.

  2. Investigate the process:

    • Identify the full path and name of the suspicious executable (the Image field in the Sysmon event).

    • Submit the file hash (e.g., SHA256) to a threat intelligence platform to check whether it is known malware.

  1. Terminate the process: If the process is confirmed to be malicious or is unauthorized, terminate it on the isolated machine.

  2. Remove the malicious file and investigate persistence: Delete the executable file. Investigate how the file was introduced to the system (e.g., via a phishing email or malicious download). Check for persistence mechanisms such as new scheduled tasks, services, or registry run keys created by the process.

  3. Investigate the user account: The user account under which the process was run may be compromised. Force a password reset and review its recent activity for other suspicious actions.

 Validation and confirmation   

  • After remediation, monitor the Suspicious Process report in ADAudit Plus to ensure the process does not reappear.

  • A full forensic scan of the affected machine should confirm the removal of the threat.

  • The affected machine should be considered compromised and may need to be rebuilt from a known-good image to ensure complete eradication of the threat.

 

 Tips   

The following best practices can help prevent the execution of suspicious and malicious processes.

 Application controls and allowlisting   

  • Implement application control policies (such as AppLocker or Windows Defender Application Control) to allow only known and trusted applications to run. This is a highly effective defense against unknown malware.

 User training   

  • Conduct regular security awareness training. Teach users to be cautious of phishing emails, suspicious downloads, and unknown attachments, as these are common methods for introducing malicious executables into an environment.

 Principle of least privilege 

  • Ensure the principle of least privilege (PoLP) is maintained so that users do not have local administrator rights on their workstations. This prevents many types of malware from being installed and executed successfully.

 

 Related topics and articles   

  • How to detect and respond to a Remote Thread Creation attack using ADAudit Plus 

                  New to ADSelfService Plus?