# Pantera\_Analysis\_Pt-1

## Executive Summary

In this post, I analyze a multi-stage Pantera malware sample discovered randomly on MalwareBazaar. It uses a deceptive .lnk shortcut file to initiate infection, A sophisticated multi-stage malware infection chain initiated through a deceptive Windows shortcut (`.lnk`) file. The attack leverages several evasion techniques including script obfuscation, living-off-the-land binaries (LOLBins), fileless execution, and anti-analysis mechanisms. The primary goal of the campaign appears to be the stealthy deployment and execution of a final-stage payload without leaving significant traces on disk.

The infection chain progresses through a malicious `.lnk` file that launches an encoded PowerShell command, which in turn downloads and executes a weaponized `.mp4` file embedded with JavaScript. Subsequent stages involve VBScript, PowerShell-based loaders, environment-aware batch files, and .NET-based payloads with advanced anti-analysis features such as AMSI and ETW patching, sandbox detection, and in-memory execution. This layered approach enhances stealth, persistence, and resistance to detection.

## Key Findings:

* **Initial Access via LNK File:** The infection begins with a disguised `.lnk` file masquerading as a PDF. When executed, it launches a Base64-encoded PowerShell payload via `powershell.exe`.
* **Weaponized MP4 File:** A seemingly benign `.mp4` file is fetched using `mshta`, but it contains embedded, obfuscated JavaScript that triggers the next stage. The use of HTA content disguised as media is a notable evasion technique.
* **Fileless VBScript Execution:** The JavaScript decodes and executes a VBScript that silently invokes another obfuscated PowerShell payload via WMI, a common stealth method.
* **Layered Obfuscation & Anti-Analysis:** The PowerShell payloads employ string reversal, regex deobfuscation, and encoded commands. The scripts check for sandbox indicators, known forensic tools, and virtual environments before proceeding.
* **Dotnet.bat Loader:** A highly obfuscated batch script dynamically constructs a command using environment variables and delayed expansion to execute an AES-encrypted and GZip-compressed payload in memory—demonstrating classic fileless malware behavior.
* **Payload 1 – Anti-Analysis .NET Executable:**
  * Utilizes vectored exception handling and thread context manipulation.
  * Dynamically patches `AmsiScanBuffer` to bypass AMSI.
  * Engages hardware breakpoints for stealthy in-memory patching.
* **Payload 2 – Encrypted .NET Loader:**
  * Contains encrypted resources and implements AES + GZip decoding.
  * Performs ETW patching and anti-debugging/VM checks.
  * Establishes persistence via scheduled tasks or registry run keys depending on privileges.
* **Final Stage Loader (output\_payload.exe):**
  * Loads and executes decrypted assemblies using `Assembly.Load()`.
  * Displays behavior typical of evasive .NET-based loaders, including Base64 decoding, dynamic invocation, and compression.
* **Command and Control (C2) Infrastructure:**
  * Communication and payload retrieval are handled via the domain `driverupdate.ue3hdn4-cdnsecurefile[.]com`, which hosts all stage-1 and stage-2 payloads.
  * All scripts and payloads are dynamically assembled, encoded, or encrypted to delay detection and hinder analysis.

## Technical Analysis:

### Stage 0 - Malicious Lnk File.

The malware masquerades as a **PDF document** but is actually a **Windows shortcut (`.lnk`) file**. When executed, the `.lnk` file uses **`powershell.exe`** from **`C:\Windows\System32\`** to run a **Base64-encoded PowerShell script**. This script initiates the first stage of the malware.

<figure><img src="/files/FRzBBCJQ9nGkcDlPopkK" alt="" width="293"><figcaption></figcaption></figure>

Looking Inside the malicious Lnk File using LECmd tool:&#x20;

<figure><img src="/files/umR3elsjSzPbvEYv2AMm" alt=""><figcaption></figcaption></figure>

It will execute powershell with -E parameter and the base64 encoded script \
Base64 Decoded Script:-

<figure><img src="/files/3Qs8xc8W59a3S8DWzr6h" alt=""><figcaption></figcaption></figure>

**`mshta`** is being used t&#x6F;**:** Load a **remote HTA or JavaScript/HTML file** — in this case, **disguised as an `.mp4`** file.

### Stage 1 - Malicious Mp4 File.

<figure><img src="/files/exOMtkhmEBuYI2G3yeys" alt="" width="563"><figcaption></figcaption></figure>

Upon closer inspection of the MP4 file i found small code snipets of javascript inside it. To get a clearer look i extracted all the strings from the MP4 file.

<figure><img src="/files/IxJ4YxoTFOMuvL93BJto" alt="" width="375"><figcaption></figcaption></figure>

It's actually a real MP4 file with embedded Javascript inside it after cleaning up the data we are exposed to the below obfuscated Script:-

<figure><img src="/files/ZcBZERRhpN5OV8MY9Wk1" alt=""><figcaption><p>Obfuscated JavaScript</p></figcaption></figure>

After Deobfuscating and removing the garbage data added to confuse the analyst and waste their time the we are left with the below Javascript Code :-

<figure><img src="/files/CPnZHxzR7YsLB927b60O" alt="" width="563"><figcaption></figcaption></figure>

<figure><img src="/files/ldBldclzLU2nv8SlwqlW" alt="" width="563"><figcaption></figcaption></figure>

<figure><img src="/files/PCKeDcA1Wz8VkHzLpiQ0" alt="" width="563"><figcaption></figcaption></figure>

<figure><img src="/files/qAdmDchcLh99FoVK8BCv" alt="" width="563"><figcaption></figcaption></figure>

The above script decodes the hex encoded reversed string payload and executes it using `eval`\
I made a simple python script to mimic the behaviour and decode the data and save it.

<figure><img src="/files/0zAz0hJb41pqLLkl7f2j" alt=""><figcaption></figcaption></figure>

### Stage 2- Decoded VBS Payload

After Decoding the data inside the javascript code, we are left with the below VBScript which it would've been executing , The VBScript uses WMI to silently launch PowerShell with execution policy disabled, running an obfuscated (Base64-encoded) payload in a hidden window — a classic malware technique for stealthy code execution.

<figure><img src="/files/5S5J6f0zxN2q9eQCq9Ka" alt=""><figcaption></figcaption></figure>

<figure><img src="/files/SwAksTFHN1AlwA5iLChv" alt=""><figcaption></figcaption></figure>

<figure><img src="/files/GDp432YkPaqoTU8S7ibX" alt=""><figcaption><p>Decoding the base64 Encoded Script</p></figcaption></figure>

We are left with another obfuscated powershell script which utilizes regex to deobfuscate the script and execute itself.

<figure><img src="/files/aAgWLoIEVXUaWU5kn1oL" alt=""><figcaption><p>Obfuscated Powershell Script</p></figcaption></figure>

I made a python script to replicate to replicate its deobfuscating mechanism and write it in a file.

<figure><img src="/files/CVlouaaBsMIxwAWB5OQ3" alt=""><figcaption></figcaption></figure>

<figure><img src="/files/OHc8VazIEM1hgYUFhYdZ" alt=""><figcaption><p>Deobfuscated powershell script</p></figcaption></figure>

After deobfuscating and prettifying the powershell script we are left with the below:-

* Checks for presence of analysis tools using process names stored inside `$malwareanalysis_tool_names`&#x20;
* Checks for sandbox environments via usernames/machine names stored inside `$common_sandbox_names`
* Exits if any known tool or sandbox is detected (`CheckProcess`, `CheckName`).
* Uses `curl` to download the files and save them to `%AppData%` folder.
* Executes the files using:
  * `ii` (Invoke-Item)
  * `start` command

<figure><img src="/files/PkEAiw7c5On46OhgnvHP" alt=""><figcaption></figcaption></figure>

<figure><img src="/files/MQgUVc0RBwEET0va4bX7" alt=""><figcaption><p>Deobfuscated &#x26; Prettified Script</p></figcaption></figure>

### Stage 3- PDF Decoy Summary & Dotnet.Bat Analysis

#### **PDF File Analysis – Decoy in Infection Chain**

* **Filename**: `Chrono24-receipt.pdf`
* **Purpose**: **Non-malicious decoy** used to make the attack appear legitimate dropped along side the `dotnet.bat` file.
* **Behavior**:
  * Contains no active exploit, script, or malicious payload.
  * Mimics a legitimate purchase receipt from Chrono24.
  * Designed to **distract or reassure the victim**, reinforcing the social engineering narrative.

<figure><img src="/files/siwC7hAjMPtHh7G6im3r" alt=""><figcaption></figcaption></figure>

#### Dotnet.bat File Analysis -

The file appears to be heavily obfuscated , Appears to use **environment variables** and **`set`** commands to dynamically reconstruct or decode commands at runtime \
Upon closer inspection we can see that it sets `hONswBYgmpEsaulXGfarAZZbvVoPuJWTRlClefejvYvNMtAWsi` to `set` dynamically and then the batch script uses **delayed variable expansion** to store and execute small code snippets. \
`!<variable_name>! "name=value"`&#x20;

<figure><img src="/files/mLln9MDAkHJCclIzXxz6" alt=""><figcaption><p>Obfuscated Batch Script</p></figcaption></figure>

After Replacing !variable\_name! with set we are left with the following where the variables are set to a value and then concatenated at once to form a script

<figure><img src="/files/imhVoliyENTgjKnC3Ku2" alt=""><figcaption></figcaption></figure>

I made a python script to reconstruct the command, the script works by resolving the variable values and reconstructing the original commands from the concatenation chain.

<figure><img src="/files/2JOqh9qteI4LPRyeUXeu" alt=""><figcaption></figcaption></figure>

<figure><img src="/files/XZgudOYx4ZohQHmIVSIX" alt=""><figcaption><p>Raw output After the concatenation</p></figcaption></figure>

Below is the Powershell script we received after concatenation of the variables,&#x20;

* The Powershell script reads the running batch script , searches and reads data starting from `qZrwcKwB1crSwCDpHoZQ*` till the end.
* If it does not find the payload then it exits.
* If it does then it &#x20;
  * First Base64Decodes the `$payload_var[0]` and `$payload_var[1]` &#x20;
  * Decrypts the base64 decoded payload using AES-CBC with a hardcoded key and IV
  * Decompresses the decrypted payload using Gzip and executes both of the payloads without touching the disk , a classic Fileless Malware Technique.

<figure><img src="/files/BfRg0aEQVOM0nsLRftgj" alt=""><figcaption><p>Cleaned Powershell Script after Concatanation</p></figcaption></figure>

<figure><img src="/files/iQLGhmxyayGMnLIDPrr3" alt="" width="563"><figcaption><p>The data to be decoded,decrypted and decompressed.</p></figcaption></figure>

I made a python script to decode, decrypt and decompress the payloads and save them to a file on disk.

<figure><img src="/files/CZF2ximkquERW1WxaQOU" alt="" width="555"><figcaption></figcaption></figure>

<figure><img src="/files/BUiWtUNhSyuJu9mXXNe4" alt="" width="555"><figcaption><p>Python Script to Decode, Decrypt and Decompress.</p></figcaption></figure>

### Stage 4 - Payload1.Bin

The first executable seems to be a .NET executable, no signs on packing or obfuscation. PeStudio flags three API's `SetThreadContext` , `GetThreadContext` and `AddVectoredExceptionHandler` .

<figure><img src="/files/LQ9KFVsk1kPxjKTH6o5k" alt=""><figcaption><p>PeStudio.exe</p></figcaption></figure>

Analyzing the executable in DnSpy we found the main method it does the following

* Retrieves a method called `"H"` from class `A` using reflection
* Registers a vectored exception handler pointing to that method
* Marshals the context structure (`ctx`) to memory at `A.p3`
* Gets the context of the current thread and stores it at `A.p3`
* Reads the thread context back from memory into `ctx`
* Calls a custom method `A.R()` passing the thread context and a memory address (`A.p2`)

<figure><img src="/files/pRo1EPgEo7U1HmzrCi9n" alt=""><figcaption></figcaption></figure>

We see that p1 is actually loading a string which is dynamically resolved which is the library amsi.dll (Antimalware Scan Interface) while p2 is also dynamically resolving the string `AmsiScanBuffer` used to get the address of AMSI scanning function

<figure><img src="/files/DsxmcVjxy6sgMfjIcNUC" alt=""><figcaption></figcaption></figure>

By Looking at all of the below functions we get to know that this code is performing **anti-AMSIScanBuffer patching** using a **context manipulation and vectored exception handler trick**.

What it does:

* Loads `amsi.dll`
* Locates the address of `AmsiScanBuffer` function
* Allocates memory for a thread context structure
* Sets up a custom vectored exception handler pointing to method `H`
* Captures the current thread context
* Modifies the thread context to:
  * Set debug registers (`Dr1`, `Dr2`, etc.)
  * Set `Dr7` to enable hardware breakpoints
  * Target `AmsiScanBuffer` in debug registers
* Resumes the thread with the modified context
* When the thread hits the breakpoint (e.g., at `AmsiScanBuffer`), the exception handler runs
* In the handler, it patches memory (likely to NOP or Ret `AmsiScanBuffer`) to **disable AMSI scanning**

<figure><img src="/files/6yukPMtn3xcUULOyDuYc" alt=""><figcaption></figcaption></figure>

<figure><img src="/files/vbPM2AVYRAXMFt5PkNgc" alt=""><figcaption></figcaption></figure>

### Stage 5- Payload2.bin

Detect-It-Easy suggest that the file is likely a **packed .NET loader** or **intermediate stage in a malware chain**, likely designed to decrypt and execute a secondary payload in memory while actively avoiding analysis environments.

<figure><img src="/files/PuJgDsK5y6g0n1VFF3wq" alt=""><figcaption><p>die.exe</p></figcaption></figure>

Below are the capabilities of the extracted **.NET-based loader** were analyzed using the **Capa tool**.

<figure><img src="/files/SquN5LUGzsu59E4ViKFG" alt="" width="563"><figcaption><p>capa.exe</p></figcaption></figure>

Upon analyzing the sample in **PEStudio**, I observed that it contains a large resource named **`payload.exe`**. Further inspection using **HxD** revealed that the resource appears to be **encrypted or obfuscated**, as the contents were not in a readable or standard executable format.

<figure><img src="/files/LiPh3y43Qp6B9HBCRTFU" alt=""><figcaption><p>PeStudio.exe - Resource Section</p></figcaption></figure>

`LuckyCrypter` is the **namespace** or **class name** used in the .NET assembly. This likely refers to a **custom or commodity .NET crypter**.

<figure><img src="/files/jy4IZsxOdg2ZTwp1q3AD" alt=""><figcaption><p>DnSpy.exe</p></figcaption></figure>

Viewing the Main function of the loader it seems to get the filename,

* Then call a function named [#isstartup-function](#isstartup-function "mention")&#x20;
* If its not then it proceeds with the [#installstartup-function](#installstartup-function "mention")
* Proceeds with the [#antivmchecks](#antivmchecks "mention") and the [#antidebuggingchecks](#antidebuggingchecks "mention")
* Then loads the ntdll library , gets the procedure address of EtwEventWrite then performs [#systeminfocheck-and-etweventwrite-patch](#systeminfocheck-and-etweventwrite-patch "mention")
* In the end it starts the [#asmload-decrypt-decompress-execute](#asmload-decrypt-decompress-execute "mention")

<figure><img src="/files/YrY2Ln0Z8XiGM7Nn8Xw5" alt=""><figcaption></figcaption></figure>

<figure><img src="/files/PB0irVmkZ4yylEdIZNvi" alt=""><figcaption><p>Main Function of the Loader.</p></figcaption></figure>

<h4 align="center">IsStartup Function</h4>

The IsStartup Function checks if a given file or folder path is located in the **Application Data** folder.

<figure><img src="/files/KHsT910mV6Tnkb82Kurj" alt=""><figcaption></figcaption></figure>

<h4 align="center">InstallStartup Function</h4>

* Defines two fixed file paths in the user profile directory:
  * `svchost.bat`
  * `svchost.vbs`
* Writes a `svchost.vbs` script that silently runs `svchost.bat` using `WScript.Shell`.
* Checks if the process has administrative privileges via `IsAdmin()`.
* If **admin**:
  * Uses PowerShell to create a scheduled task named `svchost__str`.
  * The task runs `svchost.bat` at user logon with highest privileges.
* If **not admin**:
  * Creates or modifies a registry key under:

    ```
    mathematicaCopyEditHKCU\Software\Microsoft\Windows\CurrentVersion\Run
    ```

    to point to `svchost.vbs`, causing it to run at login.
* Copies the original batch file to `svchost.bat` in the user profile directory, if it doesn't already exist.
* Terminates the current process using `Environment.Exit(-1)`.

<figure><img src="/files/HV6d1k1NVtA3zvMpb4nk" alt=""><figcaption></figcaption></figure>

<h4 align="center">AntiVmChecks</h4>

AntiVmCheck which gets the Manufacturer fro ManagmentBaseObject and compares the string with multiple VirtualMachine Providers.

<figure><img src="/files/2QGLmEc9IJX1wGXkVs7l" alt=""><figcaption></figcaption></figure>

<h4 align="center">AntiDebuggingChecks</h4>

Checks If the debugger is present by passing the current process's handle.\
If True then exits.

<figure><img src="/files/zq8ZgtkrBcozTouepsQW" alt=""><figcaption></figcaption></figure>

<h4 align="center">SystemInfoCheck &#x26; EtwEventWrite-Patch</h4>

Checks if the system is 64 bit or 32 bit using the size of IntPtr, and sets the value of array2 accordingly. The Value of array2 : `ret`  in both cases.

* **Changes memory protection** of the address where `EtwEventWrite` resides to allow writing.
* **Overwrites the beginning of `EtwEventWrite`** with the custom bytes (`ret`, or `ret 0x14`).
* **Restores original memory protection**.

<figure><img src="/files/Xx96Fb7neym9umNDsOV7" alt=""><figcaption></figcaption></figure>

<h4 align="center">AsmLoad-Decrypt-Decompress-Execute</h4>

The analyzed code functions as a loader that extracts, decrypts, decompresses, and executes embedded payloads dynamically in memory. It implements multiple techniques to evade detection and minimize forensic artifacts.

**Key Functionalities:**

* **Resource Extraction:**\
  Retrieves embedded resources from its own assembly, specifically targeting executable (`.exe`) and batch (`.bat`) files, excluding specific known resource names.
* **File Handling:**\
  Writes the extracted resources to disk temporarily with hidden and system file attributes, minimizing visibility to users and casual inspection. After execution, the files are deleted to reduce footprint.
* **Payload Decryption and Decompression:**\
  The embedded payload is stored as a Base64-encoded string. The code decrypts this payload using AES encryption (CBC mode with PKCS7 padding) and decompresses it with GZip. This layered protection obscures the payload from static analysis.
* **In-memory Execution:**\
  The decrypted and decompressed payload is loaded directly into memory as a .NET assembly and executed by invoking its entry point. Command-line arguments are passed if available.
* **Threaded Execution:**\
  Execution of external payloads occurs on separate threads with synchronous wait to ensure sequential processing.
* Below Are The Code Snippets.

<figure><img src="/files/byZT97OodDPSvgoqhqrx" alt=""><figcaption><p>Resource Extraction and Execution Logic</p></figcaption></figure>

<figure><img src="/files/fuUCdSH4gAkSRk3y1WpQ" alt=""><figcaption><p>Payload Decryption and Loading Logic</p></figcaption></figure>

<figure><img src="/files/Epg3Fbz02OZRMwRwmEMc" alt=""><figcaption><p>GZip Decompression Method</p></figcaption></figure>

<figure><img src="/files/HXuVnBopc7fP6K1Kk7vP" alt=""><figcaption><p>AES Decryption Method</p></figcaption></figure>

<figure><img src="/files/RY4ksit9e1RMQ7WW0z5y" alt=""><figcaption><p>Assembly Entry Point Invocation</p></figcaption></figure>

Built a Python Script to Load the resource file, aes decrypt it, decompress gzip stream and save it to on disk.

<figure><img src="/files/N53rgpH38NChEEXtzBFe" alt=""><figcaption><p>Python Script</p></figcaption></figure>

### Stage 6- Loader

When viewing the executable in PeStudio, we observe that the compiler timestamp is set to a date in the future.

<figure><img src="/files/liTJXhFIhXgIplISf8KB" alt=""><figcaption><p>PeStudio.exe</p></figcaption></figure>

Capa Analysis Summary of `output_payload.exe`

* The executable is a **.NET assembly** with a future compiler timestamp (2025-07-26).
* Detected behaviors include:
  * **GZip compression** and **Base64 decoding**, indicating data obfuscation techniques.
  * Dynamic **loading and invocation of .NET assemblies** at runtime.
* These features suggest the file unpacks and executes payloads dynamically, consistent with evasive malware behavior.

<figure><img src="/files/TzziEy9eAyVTazFDSBE6" alt=""><figcaption><p>capa.exe</p></figcaption></figure>

Analysis of the `Main` Function

* It executes the `ArrangeTransformableFormatter()`&#x20;
* The `ArrangeTransformableFormatter()`  which calls the `Agxethj` Function&#x20;
  * `Agxethj` is Ultimately the [#decompressdata-method](#decompressdata-method "mention") which takes `Giahghmp` Function as its parameter which is [#aes\_data\_decryptor-method](#aes_data_decryptor-method "mention")
  * After the data is Decompressed and Decrypted its loaded with `Assembly.Load` and executed using the `.Drhyvwhh` Funtion.

<figure><img src="/files/AdmtVDPWbbp8z1nF0stX" alt=""><figcaption></figcaption></figure>

<h4 align="center">DecompressData Method</h4>

* Takes a byte array (`task`) as input.
* Checks if input is non-null and has length > 4.
* Uses a `MemoryStream` to read the input bytes.
* Implements a switch-case to handle decompression logic.
* Uses `GZipStream` to decompress the data into another `MemoryStream`.
* Returns the decompressed byte array.

<figure><img src="/files/77eNTLiBRDT5b70qQ3iS" alt=""><figcaption></figcaption></figure>

<h4 align="center">AES_Data_Decryptor Method</h4>

* Takes a byte array (`reference`) as input.
* Converts base64-encoded strings into byte arrays used as AES key and IV.
* Creates an AES decryptor with CBC mode and PKCS7 padding.
* Uses the AES decryptor to decrypt the input byte array (`reference`).
* Returns the decrypted byte array

<figure><img src="/files/Y1l0tLI6QqpZDXiNuFVo" alt=""><figcaption></figcaption></figure>

I used breakpoints during execution to analyze the program’s behavior and dynamically dumped the file at runtime for further examination which will be revealed in Pt-2.

### IOC&#x20;

**File Hashes (SHA-256):**

* `16b18d7854e8de32cedfe3033f68b0ec0c22797db536789ff0156e8b9b852213` – `16b18d7854e8de32cedfe3033f68b0ec0c22797db536789ff0156e8b9b852213.lnk`
* `749be1e2595b48b32e9e5edf1c15b2e7caae473e4c67a0c8d8ff859de45220b4` – `customer-receipt.mp4`
* `b64bceb4a186aed291a6de46fa6d07ab6ac460e2a484ea9d50313976658698e5` – `decoded_payload.vbs`
* `d89bf390cb1d4ed4a12c4d7367813755fefbfa9a17b0b05efa92ea6f26356df3` – `Chrono24-receipt.pdf`
* `82fc7e4c0fbbb36f31199bda58a57dc975bd6fc2a1d80d3dcd4071d57cbd06f0` – `dotnet.bat`
* `9c72e2062b461fa11aa5a064f3361aefec1de0e94ea7381398de17ef9dd9d489` – `payload_1.bin`
* `1687e5ec93fcf561f286bdd9a93ab0f213f7292fb89adc2bbaacfffaa083520c` – `payload_2.bin`
* `2f3c58f6ba667651fc30331a7cf1def4de2d6767a3406e820b9111a66e791b4e` – `Zwqvmm.exe`

**URLs / Domains:**

* `http://driverupdate.ue3hdn4-cdnsecurefile.com/customer-receipt.mp4`
* `http://driverupdate.ue3hdn4-cdnsecurefile.com/Chrono24-receipt.pdf`
* `http://driverupdate.ue3hdn4-cdnsecurefile.com/dotnet.bat`&#x20;

### MITRE ATT\&CK Mapping

| **Tactic**               | **Technique**                                       | **Description**                                                           |
| ------------------------ | --------------------------------------------------- | ------------------------------------------------------------------------- |
| **Initial Access**       | T1204.002 - User Execution: Malicious File          | Delivered `.lnk` masquerading as a PDF to entice user interaction.        |
| **Execution**            | T1059.001 - PowerShell                              | PowerShell used in multiple stages for payload execution.                 |
|                          | T1218.005 - Mshta                                   | Used to load remote HTA (disguised as `.mp4`) from a URL.                 |
|                          | T1059.005 - Visual Basic                            | VBScript executed to launch further obfuscated payloads.                  |
|                          | T1047 - WMI                                         | Used to execute PowerShell silently via `Win32_Process`.                  |
| **Persistence**          | T1053.005 - Scheduled Task/Job: Scheduled Task      | Scheduled task created for persistence if admin privileges are present.   |
|                          | T1547.001 - Registry Run Key                        | Registry modification for persistence if non-admin.                       |
| **Defense Evasion**      | T1027 - Obfuscated Files or Information             | Base64, hex, string reversal, and regex-based script obfuscation used.    |
|                          | T1140 - Deobfuscate/Decode Files or Information     | Deobfuscation techniques implemented via scripts.                         |
|                          | T1562.001 - Disable or Modify Tools                 | AMSI patching via thread context & exception handler to bypass detection. |
|                          | T1562.002 - Disable Windows Event Logging           | ETW patching to suppress telemetry.                                       |
| **Discovery**            | T1082 - System Information Discovery                | Determines architecture (x64/x86), OS, username, machine name, etc.       |
|                          | T1497.001 - Virtualization/Sandbox Evasion          | Detects VMs based on known strings (e.g., VirtualBox, VMWare).            |
|                          | T1057 - Process Discovery                           | Checks for analysis tools and sandbox processes.                          |
| **Command and Control**  | T1105 - Ingress Tool Transfer                       | Payloads downloaded from remote server using PowerShell and `curl`.       |
| **Execution (Fileless)** | T1055.012 - Process Injection: Thread Local Storage | Payload decrypted and executed directly in memory.                        |

[Linkedin](https://www.linkedin.com/in/nitin-mithbavkar)


---

# Agent Instructions: Querying This Documentation

If you need additional information that is not directly available in this page, you can query the documentation dynamically by asking a question.

Perform an HTTP GET request on the current page URL with the `ask` query parameter:

```
GET https://xto9ot.gitbook.io/malware-analysis/pantera_analysis_pt-1.md?ask=<question>
```

The question should be specific, self-contained, and written in natural language.
The response will contain a direct answer to the question and relevant excerpts and sources from the documentation.

Use this mechanism when the answer is not explicitly present in the current page, you need clarification or additional context, or you want to retrieve related documentation sections.
