
Task 1. AMSI Bypass
Mitre ATT&CK ID T1562.001 — Impair Defenses: Disable or Modify Tools
A common technique used by attackers is to impair defenses in place by disabling or modifying tools. AMSI bypass will be used to demonstrate this technique. (https://attack.mitre.org/techniques/T1562/001/)
First, here is a brief overview about Windows Antimalware Scan Interface (AMSI). AMSI is a versatile interface standard that allows your applications and services to integrate with any antimalware product that’s present on a machine. This program provides enhanced malware protection for your end-users and their data, applications, and workloads.
Some windows components that integrate with AMSI:
- User Account Control, or UAC (elevation of EXE, COM, MSI, or ActiveX installation)
- PowerShell (scripts, interactive use, and dynamic code evaluation)
- Windows Script Host (wscript.exe and cscript.exe)
- JavaScript and VBScript
- Office VBA macros

Now for the first task of emulating and detecting AMSI bypass. Starting off cmd.exe is ran as administrator and directories are changed to the working folder of the tool. Once in the correct folder the AmsiPatchDetection.exe executable is ran. The output shows the AMSI patch detection running with no detections of AMSI in use.

Next is to execute powershell as administrator and re-run the AmsiPatchDetection.exe. On the second execution in cmd.exe the output shows AMSI in use by powershell.

Now time to emulate the AMSI bypass by executing the ASBBypass.ps1 script in our active powershell.

Re-running the AMSI bypass detection executable for a third time in cmd.exe after running the bypass script shows a potential AMSI bypass was detected and gives the PID for the Powershell used to emulate the AMSI bypass.

For further confirmation, starting Process Hacker 2 in the memory section of the powershell used to run the ASBBypass.ps1 script shows the amsi.dll having read, right, and execute privileges. This not normal, default behavior and another indication AMSI bypass occurred.


Checking the memory of amsi.dll in Process Hacker 2 shows read, write and execute permissions. This is not a normal behavior that was caused by the AMSI bypass code.

Task 2. Parent PID Spoofing
Mitre ATT&CK ID T1134.004 — Access Token Manipulation: Parent PID Spoofing
A common tactic for defense evasion and privilege escalation is PPID spoofing. Adversaries use this technique to spoof the parent process identifier (PPID) of a new process to evade process-monitoring defenses or to elevate privileges. (https://attack.mitre.org/techniques/T1134/004/)
What is a Parent Process ID (PPID)? What are indications of PPID Spoofing?
A process that creates a new process is called a parent process and the new process is called a child process. The parent process ID (PPID) becomes associated with the new child process when it is created. Therefore, monitoring parent and child processes is very common technique for threat hunting teams to detect malicious activity.
An example of this which would set off a red flag is PowerShell being the child process of Microsoft Word. This would be an indication of compromise. Another indicator to look for is the Windows API call “CreateProcess” which supports a parameter that allows the user to assign the Parent PID. This means that a malicious process can use a different parent when it is created from the one that is actually executed.

For detection of PPID spoofing the detect-ppid-spoofing.py python script will be ran. If the spoofing is successful this script will report the spoofed PPID and where the process actually originated from.

Next, process hacker is used to grab explorer’s PID to spawn notepad to using powershell. Once the command is run below notepad should be spoofed under explorer as if it was started normally instead of with powershell. Time to test it.
Below using powershell as administrator the execution policy bypass is ran, the module is imported, and PPID spoof command is run. The command’s arguments give the -ppid option followed by the target ppid of explorer to show notepad being created from, then the -spawnTo option with the path of our process to spawn from explorer, and the -dll option with the path of the msimplepayload.dll to use to inject notepad.exe as a child process of explorer.exe and spoof the PPID of explorer.

Jumping back to cmd.exe where the detection script was run shows detection of a spoofed parent process and gives information on where to look. The script shows successful detection of notepad being spoofed as the child process of explored, although the detection script shows it actually originated from powershell.

As shown below it is confirmed that notepad was successfully spoofed under the explorer process and does not show it under the powershell process from which it was truly executed. Cool stuff!!!! :D
