Understanding Suspicious PowerShell Engine ImageLoad Alerts in SIEM Solutions

Triage & Analysis on Suspicious PowerShell Engine ImageLoad Alerts


Are you seeing suspicious PowerShell Engine ImageLoad alerts in your SIEM solution? If so, it's important to investigate them further. These alerts can indicate the presence of malicious activity on your network, so it's crucial to take action and prevent potential damage.


What are Suspicious PowerShell Engine ImageLoad Alerts?

Suspicious PowerShell Engine ImageLoad alerts typically occur when an unexpected executable file, such as devenv.exe or ssms.exe, loads the System.Management.Automation.dll or System.Management.Automation.ni.dll library files. These files are part of the Microsoft PowerShell framework, which is used for task automation and configuration management on Windows systems.

While PowerShell is a legitimate and useful tool, it can also be used by attackers to carry out malicious activities, such as executing commands and scripts, stealing credentials, and exfiltrating data. Therefore, the loading of PowerShell engine libraries by an executable that is not typically associated with PowerShell can be a sign of malicious activity.


How to Investigate Suspicious PowerShell Engine ImageLoad Alerts

PowerShell is a popular tool for system administrators to automate tasks and routines. However, it can also be used by attackers to execute malicious code, bypassing application allowlisting and PowerShell security features. This is where the Suspicious PowerShell Engine ImageLoad alert comes in. In this blog, we will discuss how to investigate and respond to this alert.

If you see a Suspicious PowerShell Engine ImageLoad alert in your SIEM solution, you should investigate it promptly. Here are some steps to follow:

  1. Identify the executable file that triggered the alert, such as devenv.exe or ssms.exe.
  2. Determine whether the executable file is legitimate or malicious. You can use antivirus software, threat intelligence feeds, and other tools to help with this.
  3. Check the process tree to see if the executable spawned any child processes that may be suspicious.
  4. Look for any network connections made by the executable or its child processes, as these can be indicators of malicious activity.
  5. Review any command line arguments or environment variables passed to the executable, as these may contain clues about its purpose.

Triage and Analysis

  • When you receive a Suspicious PowerShell Engine ImageLoad alert, the first step is to investigate the process execution chain for unknown processes. 
  • Examine their executable files for prevalence, location, and digital signature. 
  • Next, investigate any abnormal behaviors observed, such as network connections, registry or file modifications, and spawned child processes. You should also check for other alerts associated with the user/host in the past 48 hours. 
  • Inspect the host for any suspicious or abnormal behavior during the alert timeframe.
  • If you determine that the implementation (DLL, executable, etc.) is malicious, you can use a private sandboxed malware analysis system to perform analysis. 
  • Observe and collect information about the following activities: 
    • attempts to contact external domains and addresses
    • file and registry access
    • modification
    • creation activities
    • service creation
    • launch activities
    • scheduled task creation. 
  • You can also use the PowerShell Get-FileHash cmdlet to get the files' SHA-256 hash values and search for their existence and reputation in resources like VirusTotal, Hybrid-Analysis, CISCO Talos, Any.run, etc.


False Positive Analysis

It's important to note that some vendors have their own PowerShell implementations that are shipped with some products, which can generate benign true positives (B-TPs). These B-TPs can be added as exceptions if necessary after analysis.


Response and Remediation

  • If you determine that the alert is indeed indicative of malware, initiate the incident response process based on the outcome of the triage. 
  • Isolate the involved hosts to prevent further post-compromise behavior. 
  • Search the environment for additional compromised hosts and implement temporary network rules, procedures, and segmentation to contain the malware. 
  • Stop suspicious processes and immediately block the identified indicators of compromise (IoCs). 
  • Inspect the affected systems for additional malware backdoors like reverse shells, reverse proxies, or droppers that attackers could use to reinfect the system.
  • Remove and block malicious artifacts identified during triage, and investigate credential exposure on systems compromised or used by the attacker to ensure all compromised accounts are identified. 
  • Reset passwords for these accounts and other potentially compromised credentials, such as email, business systems, and web services. 
  • Run a full antimalware scan to reveal any additional artifacts left in the system, persistence mechanisms, and malware components.
  • Determine the initial vector abused by the attacker and take action to prevent reinfection through the same vector. 
  • Using the incident response data, update logging and audit policies to improve the mean time to detect (MTTD) and the mean time to respond (MTTR).

Action Items for SOC Analysts

If you determine that the Suspicious PowerShell Engine ImageLoad alert is indicative of malicious activity, you should take the following actions:

  1. Terminate the malicious process and any child processes it spawned.
  2. Collect any relevant forensic data, such as memory dumps and network traffic logs.
  3. Quarantine any affected systems to prevent further damage.
  4. Determine the extent of the breach and identify any compromised data or systems.
  5. Notify appropriate stakeholders, such as management and law enforcement, if necessary.

Conclusion

Suspicious PowerShell Engine ImageLoad alerts can be a sign of malicious activity on your network, but they can also be triggered by legitimate use of PowerShell. Therefore, it's important to investigate these alerts thoroughly to determine whether they pose a threat. By following the steps outlined in this article, SOC analysts can take prompt action to mitigate any potential damage and prevent future attacks.

Comments