7.5.3. Analysing the Malicious Powershell Detect alerts

7.5.3.1. Introduction

For information, see the following paragraphs:

7.5.3.1.1. How does this particular engine detect threats?

The detection of malicious powershell scripts is carried out in several steps:

  • The first step is to analyze the form, looking for offuscation of the powershell script.
    Malicious scripts are usually obfuscated and legitimate scripts are not supposed to be, this step helps to avoid false positives.
  • The second step is to scan the content of the powershell script for potentially malicious commands.
    This step undoes the most common offuscation techniques to characterize the threat.

7.5.3.1.2. How does Malicious Powershell Detect engine work in the GCenter?

The engine:


7.5.3.1.2.1. Malicious Powershell Detect engine input data

The network flow is duplicated on the network by a TAP and the files are rebuilt by the GCap.
The file reconstruction is configured by the file reconstruction rules used by the GCap detection engine (refer to Configuring the file reconstruction rules via the GCap profile).
Any packet passing through the network will undergo a search for smart patterns to identify those likely to contain a malicious powershell script.
These packages are then extracted and sent to the GCenter for further analysis by the Malicious Powershell engine.
Files with extension .ps1 will also be extracted for analysis.

Once the scan is complete, if a malicious powershell script has been identified, an alert is raised with all the information collected.

Currently, the management of obfuscations in the second step will only be possible for a defined set of techniques, but this will not prevent the detection of malicious powershell scripts whose offuscation technique could not be identified.

In order for the engine to be operational, a first update of the "Threat-DB" will have to take place.

7.5.3.1.3. Management of the Malicious Powershell Detect engine

To view the engine Status, see the Viewing the engine status paragraph.
To update the engine, see the Engine update paragraph.
To configure the engine, see the Engine configuration paragraph.

7.5.3.1.4. Events generated by the engine

Events generated by the Malicious Powershell Detect engine are alerts.
These are displayed:
  • In the main interface named WEB UI of the GCenter in the `Alerts` screen:
    The main interface named WEB UI is described in Overview of the WEB UI.
    • To display only these alerts, select the `Malicious Powershell` engine filter then validate.
      See the presentation of the Web UI `Alerts`.
      ../../_images/GCE103_POWERSHELL_ALERT_06.PNG
  • If the `Group by name` mode is activated, the name of the aggregated alerts and their number are displayed.
    Click on a grouping of alerts to display the list.
  • When the `Group by name mode is disabled, different Source and Destination information is displayed for each alert.
    `Tags` and `Notes` are also visible and editable.
    The various Quick Access `Actions` are available for each alert.
  • In the interface named Kibana UI:
    • In the main interface WEB UI, to view the alerts, select the `Malicious Powershell` engine filter then validate.
      See the presentation of the Web UI `Alerts`.
      ../../_images/GCE103_POWERSHELL_ALERT_06.PNG
    • After selected the alert, click on the `Open powershell engine analytics` command of the `Actions` menu.
      Kibana is opened on the `Malicious Powershell` category of the `Alerts ` section: in the `Overview` tab, the database displays all alerts
      The interface displayed is the interface named Kibana UI (described in Overview of the Kibana GUI).
      ../../_images/GCE103_POWERSHELL_ALERT_02.PNG
    • Click on the `Messages` tab.

      ../../_images/GCE103_POWERSHELL_ALERT_04.PNG
  • To consult information about a specific alert:

    • Click on the toggle icon on the left of the Alert
      The expanded document is displayed.
      ../../_images/GCE103_POWERSHELL_ALERT_05.PNG
      The detailed information of this alert can be viewed in table or json format.

    Note

    The Kibana UI can also be accessed without any filters via the `Hunting` icon on the left side menu bar in the WebUI.


7.5.3.1.5. Essential information to understand the context of the alert

7.5.3.1.5.1. What are the key fields of an alert and their meaning?

Before undertaking any investigation or qualification of the alert, it is essential to start by observing several elements that will provide essential information to understand the context.
These elements can be found either in the WEB UI interface or in the Kibana UI interface.
../../_images/GCE103_POWERSHELL_ALERT_06.PNG
Here are the main fields that will be found in the `Alerts` view of the `Web UI`, when Aggregated is disabled:
  • `Risk`
    The risk score of the alert, it depends on the success of the analysis of the Shellcode.
  • `Date` (event.created)
    The date and time the alert was raised by the engine.
  • `Name:`
    This is the threat description based on the analysis. It consists of:
    • Malicious powershell detected, probably obfuscated (60b656e17bec0a97f5638790c78a3124)

    • The alert severity:

      If the risk is 70% then the alert is indicated as `Malicious`
      If the risk is 40% then the alert is indicated as `Suspicious`
    • engine name: `powershell_detected` (event.module)

    • the probability of obfuscation: if the score is superior to 0.75 then the `probably obfuscated` information is displayed

    • an identifier based on the details of the analysis (malicious_powershell.id)

  • Source IP and Dest. IP (source.ip and destination.ip)
    The source and destination IP address associated with the alert.
  • Src. Host. and Dest. Host.
    When the information is available, it is the name of the machines linked to the IP associated with the alert.

More information is available in the Alert Details panel by clicking on an alert:

../../_images/GCE103_POWERSHELL_ALERT_08.PNG
  • In the `Malicious Powershell Detect summary` section of the `Summary` tab:

    • Scores - Proba obfuscated (obfuscation probability:)
      This is the probability of obfuscation, a score of 1 indicates a high probability of obfuscation that can prevent the detection of suspicious commands.
      The more obfuscated the Powershell script, the more likely it is to be malicious.
    • Scores - Analysis (score)
      This is the synthetic score of malice, a score greater than `100` indicates the presence of several techniques considered malicious.
  • Click on the `Details` tab (3).

    • Scores - Others (malicious_powershell.score_details)
      The score of the different techniques sought during the analysis, used to calculate the analysis score.
    • event.severity
      The threat score of the alert, it depends on the values malicious_powershell.proba_obfuscated and malicious_powershell.score.
      If these values are high enough, this score will have the value 1, meaning a high probability of malice.
      If these values do not allow to decide on the threat, this score will have the value of 2.
    • network.timestamp
      The date and time the file was extracted by the GCap.
    • malicious_powershell.id
      An identifier based on the analysis details, to group similar alerts.
    • malicious_powershell.sample_id
      The unique identifier of the analyzed sample, composed of the extraction date, a random number, and the GCap name.

7.5.3.2. Alert handling procedure

7.5.3.2.1. How do you verify the accuracy of an alert and determine if it represents a real threat?

In some cases, a Malicious Powershell alert may not be a real threat.
To evaluate it, several actions can be taken.
  • Check sample content: legitimate tool
    Sometimes legitimate Powershell code is confused with malicious code.
    A number of tools are installed using Powershell commands as malware might do.

    For example, chocolatey, a package manager for windows, installs with the following command.
    iex ((New-Object System.Net.WebClient).DownloadString('https://community.chocolatey.org/install.ps1')
    This kind of command is often used in a malicious framework to download in memory and run malware on a Windows machine.
    The only clue to conclude a legitimate order is the url, by performing a search on the Internet.

    This is usually easy to identify:
    1. On the WebUI interface, open a Malicious Powershell alert.

    2. Click on the `Show Hexdump` command of the `Action` menu.

    3. Search the right column for keywords known as legitimate tools.

    4. Search the right column for any suspicious content.

    5. If in doubt, contact administrators for confirmation.

  • Check sample content: Antiviral DB
    The malicious_powershell engine often categorizes anti-viral database update streams, or similar, as malicious over the network.
    These feeds contain signatures that can trigger an alert, but they also contain the names of these signatures.
    It is therefore generally easy to identify them:
    1. On the WebUI interface, open a Malicious Powershell alert.

    2. Click on the `Show Hexdump` command of the `Action` menu.

    3. Search the right column for keywords similar to signature names.

    4. If enough (3-4) different keywords are identified, it is certainly an antiviral database

    Names can be truncated depending on the type of stream being extracted.
    Generally, just search for keywords on Microsoft’s website: https://www.microsoft.com/en-us/wdsi/threats
    Examples:
    • Pshdlexec ("TrojanDownloader:X97M/Pshdlexec")

    • !##..32/Hikiti.GIC ("Backdoor:Win32/Hikiti")

    • ...64/Meterpreter.R ("Trojan:Win64/Meterpreter")

    • Y2V:Costin_Raiu_Kaspersky_Lab/loki2crypto

  • Check flow type: Backup
    It is possible for a malicious Powershell script to be detected in a virtual machine backup stream.
    This means that there is a malicious Powershell on the machine disk.
    This is an alert that is less urgent to investigate and will depend on the use of this machine.
    For example, a cybersecurity expert could keep such files on his machine.

    To know if it is a backup flow, we can:
    • Compare ports (source.port, destination.port) with your virtualization tool documentation

    • Check if the IP matches a storage server

    • Check if many similar flows occur at the same time

    • Contact the infrastructure staff


7.5.3.2.2. How to categorize the threat based on the information collected?

  • Check the target machine.
    Powershell scripts require the Powershell interpreter to be installed on the machine, which is still the case on Windows, but very rare for Linux or MacOS.
    In addition, the capabilities of the Powershell framework are limited for them, reducing its interest in a malicious framework.
    Thus, when a Malicious Powershell alert is raised, it is interesting to check that the target machine is indeed under Windows.
    If so, it is likely that the machine has been infected.
    If not, it may be a intermediate machine or a false positive.
  • Check detailed scores in alert.
    In the alert, consult the list of detailed analysis scores to determine the actions taken by the `powershell` code.
    The `malicious_powershell.score_details` subfields indicate the score related to the types of commands detected.

    Obfuscation techniques detected:
    • `FmtStr`
      Reassembly of multiple values into a formatted string
    • `StrCat`
      Concatenation of multiple strings
    • `StrJoin`
      Concatenating multiple strings with `-join`
    • `CharInt`
      Creating characters from integers with ``[Char]`
    • `Base64`
      Presence of Base64 encoded strings
    • `StrReplace`
      Changing strings by replacing patterns
    Detected commands related to the download:
    • `WebClientInvokation`

    • `InvokeWebRequest`

    • `InvokeRestMethod`

    • `StartBitsTransfer`

    Detected commands related to file interaction:
    • `GetContent`

    • `SetContent`

    • `AddContent`

    • `StreamReader`

    • `StreamWriter`

    • `SystemIOFile`

    Detected commands related to order execution:
    • `InvokeExpression`
    Thus, we can deduce behaviors from this information.
    For example an alert with the following results:
    • `malicious_powershell.score_details.InvokeExpression: 50`

    • `malicious_powershell.score_details.InvokeWebRequest: 20`

    Indicates a download and execution of `powershell` code as a `string`.
    This is probably a dropper that downloads code to run.
  • Manually analyze the Powershell script
    It is often useful and effective to access the sample content to view the detected powershell code and categorize the threat.
    1. On the WebUI interface, open a Malicious Powershell alert.

    2. Click on the `Show Hexdump` command of the `Action` menu.

    3. Identify the Powershell code detected by a `powershell` text search.

    4. Extract script manually for better reading.
      Typically, the powershell code is intercepted as one or more orders placed directly to the powershell.
      In this case, isolate the code after the `-Command` or `-c` argument.
      It is not uncommon for the script to be partial, "perforated", or strewn with non-printable characters due to various network-related factors.

      The powershell code may also have been intercepted in base64.
      In this case, the base64 character string containing the code located after the `-EncodedCommand` or `-e` and extract it..
      This tool can be used: CyberChef - getEncodedCommand

      If the `powershell` code was intercepted as a `. ps1' file, the code should be readable and isolated without further action.
    5. Read code to understand purpose
      The Powershell language is relatively intuitive to read with basic programming, if it is not too obfuscated.
      The purpose of this first reading is to identify interesting commands like those indicated in the previous section.
      We can also be interested in external commands or windows executables, for example:
      • `regedit.exe`: import/export registry keys

      • `reg add`: add a registry key

      • `schtasks /Create`: create a scheduled task

      • `net start/stop`: starts/stops a service

      • `wmic`: obtaining or changing the configuration of a remote machine

      • `netsh advfirewall`: obtaining or changing firewall configuration

      • `wusa /kb:{numero}`: uninstall package by KB number

      Help can usually be found to understand these commands on the Internet.

      Overall, these commands can identify whether the script looks malicious or legitimate.
      If the code is too difficult to understand, it is possible to use an AI (eg chatGPT, Mistral, Phind, etc.) provided that the extraction is of good enough quality.
    6. Look for information that may contain indicators of compromise or threat details such as:

      • URLs (e.g. search `http://`)

      • IP addresses

      • File paths (e.g., search for `c:\`, `%AppData%` or `%windir%`)

      • Registry key paths (e.g. search `HKLM`, `HKCU`, `CurrentVersion`)

      • Messages to the victim (e.g. “Your sensitive data has been stolen”)

    It is common for this information to be obfuscated in order to avoid pattern detection.
    Here are the main techniques encountered along with tools to solve them:
    Most `string` obfuscation techniques are easy to undo with the right recipe `CyberChef`
    When CyberChef or similar tools are not enough, it is possible to use an AI (eg chatGPT, Mistral, Phind, etc.) in order to obtain the obfuscated code.
    As a last resort, be careful to copy only the offuscation code, execute the offuscation code snippet in a `powershell` interpreter.
    This `powershell` interpreter must have as few rights as possible to limit the risks in case of false manipulation.
    PS C: Users Guest> "aXzYZf" -replace "XzYZ", "bcde" -> abcdef
  • Correlate with other engines
    It is interesting to check the presence of alerts from other engines from information identified by Malicious Powershell Detect.
  1. Note some information that may be present in other alerts.
    For example:
    • IP Source: `x.y.z.1`

    • IP Destination: `x.y.z.2`

    • URL or IP contacted by the script

    • File downloaded by script

  2. In the "Alerts" menu of the WebUI, select all engines except Malicious Powershell Detect and filter on the collected information.
    Some examples of filters:
    • Filter 1: `ip:x.y.z.1`

    • Filter 2: `ip:x.y.z.2`

    Note

    It is important to note that the source IP identified by Malicious Powershell Detect may have been identified by another engine as an IP Destination.

    The most suspicious alerts will be related to the compromise of the source IP: executable files, privilege elevation, connection to bad reputation IPs among others.

  3. It is also possible to perform this investigation in Kibana UI.
    The previous filters then become:
    • `source.ip:x.y.z.1 or destination.ip:x.y.z.2) and event.module:"sigflow_alert"`

    • `source.ip:x.y.z.1 or destination.ip:x.y.z.2) and event.module:"sigflow_alert"`

  • Correlate with windows logs

    • If a malicious Powershell script was run on a Windows machine, there is a good chance of finding a trace of it in the event logs.

    • If the feature is enabled, Windows records all executed powershell commands.
      To do this, open "Event Viewer", then go to "Application and Service Logs", "Microsoft", "Windows", "Powershell".

7.5.3.2.3. What answers are needed if the threat is confirmed?

  • Isolate the system: immediately isolate the contaminated system and ensure it cannot cause further damage

  • Notify: inform relevant parties of threat detection

  • Collect information: gather critical information such as IP addresses, or information in the Hexdump.

  • Neutralize the threat by blocking the IP address

  • Analyze logs: review system and network logs to trace the spread of the threat.


7.5.3.2.4. What if an alert from this engine is identified as a false positive?

If an alert from this engine is identified as a recurring false positive, it is recommended to `mute` the alert signed.
There is no whitelist for the Malicious Powershell Detect engine.