> For the complete documentation index, see [llms.txt](https://txc.gitbook.io/documentation/llms.txt). Markdown versions of documentation pages are available by appending `.md` to page URLs; this page is available as [Markdown](https://txc.gitbook.io/documentation/writeups/malops.io/operation-silent-veil.md). # Operation Silent Veil Hi all, this writeup documents my analysis of the multistage malware sample being part of [Malops](https://malops.io/chain-challenges) Labs. These exercises enable participants to analyze complex challenges that involve a sequential chain of events leading up to a realistic attack. Starting with an Excel document and obfuscated VBA, we need to decrypt the final payload from a dropped image to reveal a .NET stager that communicates through Filen cloud storage.

https://x.com/MalGamy12/status/2103823019269406805

{% hint style="info" %} To be more efficient during malware analysis and to train focusing on the most relevant aspects (e.g. delivery of a decrypted C2 configuration to build a detection on instead of reversing the encryption algorithm in depth), I tried to myself into some kind of 'incident' mode were possible. Here and there I used AI as a copilot, for educational purposes (especially in fields I had no experience previously) or for automation. The corresponding sections are highlighted. {% endhint %} *** ## Stage 1 - The Hidden Document - sample.xls The whole infection chain starts with an Excel file, provided by the author of this lab. Triage returns the following, most interesting information: {% tabs %} {% tab title="SHA256" %} c99d00dede7a704ce86ef5fa5f8ec7e2388750327ec04f9691e11a32267ba031 {% endtab %} {% tab title="File size" %} 748032 bytes (730.5 KiB) {% endtab %} {% tab title="Embedded files" %}

{% endtab %} {% tab title="Strings" %}

ingest\[.]filen\[.]io Various API names like: \ GetCommandLineA\ RegCreateKeyExW\ RegSetValueExW\ LoadLibraryExW\ GetProcAddress\ CreateProcessA\ gethostbyname\ FindNextFileW\ IsUserAnAdmin {% endtab %} {% tab title="Document metadata" %}

{% endtab %} {% endtabs %} The file header shows the bytes D0CF11E0A1B11AE1, the magic bytes for the OLE2 file format (Question 1).

When the Excel file is opened, the Workbook\_Open (Question 2) VBA procedure runs the macros embedded inside.

{% hint style="warning" icon="comment-question" %} AI usage - GPT-6 Astra & Malcat MCP server - Summary of VB code\ Prompt:\ *I found all the VBA macros, but it is obfuscated and contains more than 1500 lines. Please analyze all the modules for me and give me a brief summary of what the VBA is doing in a clean table. Entry point is the smf function within the Workbook\_Open procedure* {% endhint %} {% hint style="success" icon="message-check" %} | Module | Main routines | What it does | | ------------------- | --------------------------------------- | --------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------- | | **ThisWorkbook** | `Workbook_Open`, `Workbook_BeforeClose` | Starts the installation sequence, hides the first sheet, and controls execution and saving when the workbook closes. | | **Module1** | `ini`, `gin`, `chkin`, `clr` | Loads embedded configuration, resolves environment paths, performs a DNS lookup of `ingest[.]filen[.]io`, and coordinates closing actions. | | **Module2** | `CrFld`, `ini2`, `t1`, `uu` | Creates folders, assigns configuration values, launches a hidden process, and masks visible worksheet cells with `#` characters. | | **Module3** | `sge`, `ttt`, `asd` | Checks for an existing installation, copies the extracted DLL into place, and coordinates killing/restarting Explorer. | | **Module4** | `COmkn`, `reflux`, `SearchEB` | Writes an HKCU `CLSID\…\InProcServer32` entry pointing to the DLL—an attempted [COM hijack](https://learn.microsoft.com/en-us/windows/win32/com/inprocserver32). Includes extraction and command helpers. | | **Module5** | `u`, `SearchBytes`, `WF`, `tfs` | Extracts embedded configuration, DLL, and PNG bytes. Restores visible worksheet content from the hidden sheet and records status. | | **Module6** | `SPe`, `hc`, `ges`, `u1` | Copies the XLS to `%TEMP%`, locates embedded data, masks cells, and launches the Explorer termination command. | | **Module7** | **`smf`**, `chkos`, `ost` | Main controller. Inventories OS/Excel versions and program folders; stores XOR-obfuscated results in hidden cell `Z101`. Provides fallback DLL execution. | | **Module8** | `t0`, `hpnol`, `getGrs`, `wtof` | Reads/writes binary files and builds the `taskkill` and [regsvr32](https://learn.microsoft.com/en-us/windows-server/administration/windows-commands/regsvr32) commands. | | **Module9** | `ini0` | Initializes `Scripting.FileSystemObject`, `%TEMP%`, and `system32` settings. | | **Module10** | Constants only | Defines the embedded-data marker `A056FA73` and a shared variable. | | **Module11** | API declarations | Provides Windows registry, process, file, and DNS APIs for VBA7. | | **Module12** | Legacy API declarations | Older-VBA equivalents, with apparent compatibility defects. | | **Sheet1 / Sheet2** | No procedures | Hold worksheet data and diagnostics; contain no executable VBA routines. | | {% endhint %} | | | Module10 contains the data marker `A056FA73` (Question 3) of the config blob. In the screenshot below we see each element of the configuration (Question 11 - Question 15, Question 17 - Question 18 - A more detailed analysis regarding Persistence via COM Hijacking, file dropping and a fallback mechanism is visible below).

The routine hpnol() in Module8 contains the logic to read bytes, starting from a given offset of a file and loading them into the buffer altunb.

The object created via the CreateObject() (Question 4) function is an ADODB.Stream object, defined in the beginning of Module4 via the variable fsagh. hpnol() is only called once, namely within Module1.

The filepath used in this function is constructed before and will be %TEMP%\\\~FILENAME.tmp. Modul1 is responsible for finding and loading the embedded configuration. After the code reads the desired bytes into a buffer, the malware searches for them via a self-defined SearchBytes() function.

The third parameter defines the size, in case of Question 5 hardcoded in the variable fsz0. A simple search for this variable reveals its definition within Module7. Within SearchBytes() the byte 0xEB is searched via a dedicated routine and its position adjusted by 8228 = 0x2024 bytes (Question 6). Afterwards, the malware search for its configuration and splits the fields, saving them in the array v. In total, this array contains 14 elements (Question 7) and is used gradually as code execution proceeds.

From triage it is already clear, that the Excel file contains an embedded PE resp. DLL file. The magic bytes header is either visible in the Excel file or in the Office.Workbook8 file (Question 8).

Similar to the 0xEB marker from the previous question, the 0xC600 marker within the file is accessed from within the SearchBytes() routine. In the screenshots below we can see the size of the block, but also its location within the Excel file (Question 9).

The SearchBytes() routine is able to search for bytes regarding different file types. The second parameter obj determines for which file header to search for.

For example, if obj = 1, the routine searches for the magic bytes of a PE file header. In case of obj = 2 the routine searches for the magic bytes of a PNG file header.

Transforming the decimal values to hex values will return the bytes 89 50 4E 47 0D, the [magic bytes for a PNG file](https://en.wikipedia.org/wiki/List_of_file_signatures). Tracing back the calls to SearchBytes() show only one occurrence with obj = 2 namely in the routine WF() that is also called only one time, with the size of the image as 3rd parameter (Question 10).

### Dropping next stage payloads From the configuration information embedded in the Excel file we get a hint, which file names and paths the malware uses to drop the payloads for the next stage. Additionally, before extracting bytes, the malware used the function SearchBytes() multiple times to locate them within the Excel document. Routine WF() is not only responsible for locating and extracting the bytes from the Excel file, but also responsible for writing the extracted bytes to disk. To achieve this goal, it calls the routine wtof() two times. In combination with tracing back calls tokernel32!CreateFileW we get an idea what is happening here (relevant for Question 16). This Windows API is defined in Module11 and called within the routine wtof().

Tracing back calls to wtof() leads again to the routine WF() with the relevant call visible in the first yellow rectangle.

The variable tmpd used in the concatenation as first parameter is filled before with the sixth element (via v(5)) of the configuration found earlier (see picture before). tf is the resolved environment variable of the TEMP directory. This results into the file creation of %TEMP%\DEFAULT-20241101-1112.log, containing the bytes of the DLL file loaded later during COM Hijacking. The second call to wtof() writes the bytes of the PNG file into Microsoft\Network\Cache\icon.png. However, at this point the file %appdata%\Microsoft\Internet Explorer\UserData\Low\DB\uimanager.dll does not exist yet, but only the LOG file in the Temp directory. Additionally, the parts of the full file path of this LOG file are still stored in the variables tf and tmpd.

Within Module3, various strings are concatenated and then, via CopyFile, the content dropped previously is copied into %appdata%\Microsoft\Internet Explorer\UserData\Low\DB\uimanager.dll. ### Persistence - COM Hijacking During routing COmkn the malware accesses and modifies the user hive of the Registry of the infected machine via a combination of API calls like advapi32!RegOpenCurrentUser, advapi32!RegCreateKeyExW and advapi32!RegSetValueExW. {% hint style="info" %} To establish Persistence via COM Hijacking, attackers target the user hive (HKEY\_CURRENT\_USER resp. HKEY\_USER) and modify the targeted COM interface within this hive. By default, the OS searches for the needed COM interface in this hive first, before falling back to the SYSTEM hive (HKEY\_LOCAL\_MACHINE). {% endhint %} In the screenshot below we can see the mentioned API calls in action and relevant content of the configuration filled into variables before.

After the COM Hijack has been established, the malware forces explorer.exe to exit and to restart. This ensures, that this process performs a lookup for the required COM interface, effectively loading the malicious DLL into its own process, namely explorer.exe.

original COM interface targeted by the malware. IDStore.dll loaded within explorer.exe

Question 19 and Question 20 can be answered together, exploiting the COM Hijack established previously. The malware kills the process explorer.exe first via taskkill.exe. It then starts explorer.exe again, effectively forcing it to load the malicious DLL dropped earlier via COM Hijacking. {% hint style="warning" icon="comment-question" %} AI usage - GPT-6 Astra & extracted .vbs script - Review of my API call tracking\ Prompt:\ *The VBS establishes COM Hijacking before. I think it kills explorer.exe first via taskkill.exe, then restarts it to abuse the COM Hijack. Is this correct?* {% endhint %} {% hint style="success" icon="message-check" %} **Yes—that is the intended execution chain.** 1. During `Workbook_Open`, `smf → COmkn` creates the per-user COM registration pointing to the dropped `uimanager.dll`. A successful registry write sets `flr = 1`. 2. When the workbook **closes**, `clr → asd → reflux → u1` launches: ``` taskkill.exe /f /IM explorer.exe ``` 3. After waiting up to 17 seconds, `asd → t1` launches: ``` %WINDIR%\explorer.exe ``` {% endhint %} During execution, the malware concatenates multiple parts of strings, being used for two calls to kernel32!CreateProcessA. Chattie did a good job to tackle the obfuscation, rebuild the strings and summarizing the execution flow, making the whole purpose of the routines way clearer. ### Fallback mechanism The malware uses a fallback mechanism to execute the dropped DLL via regsvr32.exe, if establishing persistence via COM Hijack wasn't successful. The routines are visible in the pictures below\...

... and execute only if the variable flr equals 0. This will be the case, when the malware fails to establish COM Hijacking (within routine COmkn). ### Check Name resolution (DNS) Question 21 and Question 22 can be answered in combination: Within the first routine executed, the routine chkin() is called.

This routine is responsible for resolving the hostname ingest\[.]filen\[.]io via gethostbyname. If the check fails, the variable chk will be modified and later written into a specific cell of the Excel file. ### Visibility The visibility (Question 23) of the sheet is changed during the Workbook\_Open() procedure. There the visibility is set to 2 ensuring the object is set to VeryHidden, [preventing users from making it visible again via the UI](https://learn.microsoft.com/en-us/office/vba/api/excel.xlsheetvisibility).

When the workbook is closed, the Workbook\_BeforeClose() routine executes, calling clr, uu and then hc for predefined cells of sheet 2 (Question 24).

Within hc the value for the predefined cells is set to preset constants (multiple hash symbols). ### OS architecture The script performs checks regarding the OS architecture multiple times. For the 64bit architecture, the script uses the constant Win64 (Question 25). ### Payload extraction {% hint style="warning" icon="comment-question" %} AI usage - GPT-6 Astra & sample.xls - Extraction of DLL and PNG file\ Prompt:\ *Started the Malcat MCP server with the sample.xls file. We already know, that it contains a PE32+ DLL with the size of 183296 bytes. Extract it for me and save it into my workspace. Follow the procedure from the the vbs script and give me a short summary, of what the malware author did to thwart simple extraction via Malcat. Do the same for the embedded PNG file with the size of 215393 bytes.* {% endhint %} {% hint style="success" icon="message-check" %} Saved **uimanager.dll** in your workspace. * **Size:** 183,296 bytes * **Format:** PE32+ x64 DLL * **SHA-256:** `125abe1a497067a61011eb6072b1b3d91d3f0b658ed20a99734f0341d9cbdd6a` I reproduced `SearchEB → SPe → SearchBytes` statically. The DLL occupies **184,920 physical bytes** in the XLS, interrupted by **22 four-byte Excel record headers** and **three 512-byte OLE allocation-table sectors**. Removing those 1,624 bytes reconstructs the DLL. This storage layout defeats simple contiguous carving: exporting directly from the `MZ` signature includes intervening container metadata and corrupts the recovered file. The VBA rebuilds the payload by skipping those structures. **Neither the VBS nor the DLL was executed.** The original XLS is unchanged. {% endhint %} {% hint style="success" icon="message-check" %} Saved **icon.png** in your workspace. * **Size:** 215,393 bytes * **Dimensions:** 516 × 354 pixels * **Validation:** PNG signature, all chunk CRCs, and final `IEND` verified * **SHA-256:** `6c7ddb53dd300d39f2e5b3d4d599be56991e807c633b5a5564b8b7d3fc7d491b` Following the VBA’s reconstruction logic, I removed **26 four-byte Excel record headers** and **three 512-byte OLE allocation-table sectors**. These 1,640 intervening bytes prevent straightforward contiguous extraction. **No VBA or payload was executed; the original XLS is unchanged.** {% endhint %} *** ## Stage 2 - Beneath the Surface - uimanager.dll ### Triage When analyzing this stage, we need to keep in mind, that the DLL is loaded into either explorer.exe or into regsvr32.exe, depending on whether COM hijacking has been established.\ Question 1 and Question 2 can be answered without looking too deeply into disassembled code. {% tabs %} {% tab title="SHA256" %} 125abe1a497067a61011eb6072b1b3d91d3f0b658ed20a99734f0341d9cbdd6a {% endtab %} {% tab title="Capa" %}

{% endtab %} {% tab title="Sections" %}

{% endtab %} {% tab title="Anomalies" %}

{% endtab %} {% tab title="Interesting strings" %} ─────────────────────────\ FLOSS TIGHT STRINGS (7)\ ───────────────────────── %appdata%\Microsoft\Network\Cache\icon.png\ 838645f4bab7458fb130c7120a500982\ resolvefree\ idstore.dll\ explorer.exe {% endtab %} {% endtabs %} {% hint style="warning" icon="comment-question" %} AI usage - GPT-5.6 Luna - Research (answer for Question 13)\ Prompt:\ *838645f4bab7458fb130c7120a500982*\ *What do you find about this?* {% endhint %} {% hint style="success" icon="message-check" %} That string is **not just a random identifier**. I found an exact match in a July 2026 malware-analysis report from 360 Security / Threat Intelligence. #### What it is `838645f4bab7458fb130c7120a500982` is described as a **hard-coded key seed** used by malware attributed by 360 to **APT-C-20 / APT28 (Fancy Bear)**. According to the analysis: * The malware uses this seed with **PBKDF2** to derive an **AES-256 key**. * It then reads a seemingly normal PNG file, `EdgeLogo.png`. * Data hidden in the image using **LSB steganography** contains encrypted malware. * The derived key is used to decrypt that hidden payload. * The resulting shellcode is executed **in memory**, avoiding a conventional executable being written to disk. * The later-stage malware communicates through the legitimate **Filen.io** cloud-storage infrastructure as a C2 mechanism. The same report gives related hashes, including: * `77014b3e77529079f041b5b9e73a013b` — `readme.docm` * `b077401fe3d9642345d4c3deafa60aa5` — `dnxstore.dll` * `d416eca59188474efa3408827578588b` — `Publish.exe` {% endhint %} ### String decryption API Hashing (described in the next chapter) occurs at different places within this DLL and is performed as a preparation for subsequent calls to resolved APIs. Before this procedure, the malware decrypts content, embedded as a cipher in the .rdata section (Question 8, Question 9 and Question 11). {% hint style="warning" icon="comment-question" %} AI usage - Sidekick (Binary Ninja) - Decryption (similar prompts for other decryption)\ Prompt:\ *Perform the decryption for me in the for-loop, starting at 0x180002374 to 0x180002399.*\ *Perform the decryption for me in the for-loop, starting at 0x180001462 to 0x180001485.* {% endhint %} {% hint style="success" icon="message-check" %} Decode 12 two-byte characters 0x180002374–0x180002399 Each iteration: 1. mov cl, r8b; and cl, 3; shl cl, 4 computes (index % 4) × 16. 2. mov rdx, r14; shr rdx, cl selects a 16-bit portion of the key. 3. xor dx, word \[r15+r8\*2+0x28c50] XORs that key word with an encrypted word at 0x180028c50 + index\*2. 4. mov word \[rsp+r8\*2+0x20], dx writes the decoded word into a stack buffer. 5. The loop increments r8 and repeats until all 12 words are decoded. The repeating XOR words are: ``` ED03 D192 4A32 D1B5 ``` For example, the first encrypted word is 0xed6a: ``` 0xed6a XOR 0xed03 = 0x0069 = 'i' ``` Result: idstore.dll, encoded as UTF-16LE, including its terminating NUL. Later, at 0x18000253d, the function passes this decoded buffer to LoadLibraryExW. I named the encrypted source and decoded stack buffer and annotated the loop in the database. {% endhint %} {% hint style="success" icon="message-check" %} The loop at 0x180001462–0x180001485 decrypts this ASCII string: ``` 838645f4bab7458fb130c7120a500982 ``` That is 32 characters plus a terminating NUL, totaling 0x21 bytes. | Property | Value | | ------------------- | -------------------------- | | Encrypted source | 0x180028bb8 | | XOR key | 0x9e3779b97f4a7c15 | | Repeating key bytes | 15 7C 4A 7F B9 79 37 9E | | Destination | Stack buffer at rsp + 0x30 | Unlike the earlier UTF-16 loop, this one processes one byte per iteration: * 0x180001468–0x18000146e selects a key byte by shifting the key by (index & 7) × 8. * 0x180001471 XORs that byte with the encrypted source byte. * 0x180001479 stores the plaintext byte. * 0x18000147e increments the index by 1, since the setup sets rsi = 1. For example, the first byte is 0x2d XOR 0x15 = 0x38, the ASCII character 8. I named the source encrypted\_hex\_string\_838645f4 at 0x180028bb8 and annotated the decoding loop. The plaintext looks like a hexadecimal value; its format alone does not establish whether it is a hash, key, or identifier. {% endhint %} The first string decrypted is idstore.dll. This is the DLL of the hijacked COM interface to force explorer.exe to load the malicious uimanager.dll (see [above](#persistence-com-hijacking)). This DLL will be loaded into the process, to ensure correct functionality of explorer.exe (Question 10).

Question 12 asks for the decrypted string that will be later used to create a mutex (resolvefree). Additional strings being decrypted during execution are: %appdata%\Microsoft\Network\Cache\icon.png\ \ 838645f4bab7458fb130c7120a500982 ### API Hashing From triaging we understand, that the DLL uses API hashing to resolve various APIs dynamically without exposing their plaintext imports. With the output of capa and using the HashDB plugin we are able to identify [FNV-1a](https://mojoauth.com/security-guides/fnv-1a-in-c#how-to-implement-fnv-1a-in-c) as hash algorithm used (and Question 4 - Question 7).

API Hashing occurs at different places within this DLL and is performed as a preparation for subsequent calls to resolved APIs (see below). ### Time check The function located 0x180001c94 resolves the following APIs: kernel32!Sleep, kernel32!QueryPerformanceCounter and kernel32!QueryPerformanceFrequency. This function is executed before additional actions happen. If it returns false, the malware skips additional activities.

Basically, the code in the picture above, retrieves a timestamp before executing a Sleep for 5000ms resp. 5s. If Sleep has been executed for longer than 4.9s, the malicious code continues. ### Thread Creation At address 0x1800022bd the malware calls kernel32!CreateThread after the pointer to this API has been resolved dynamically. This thread runs immediately after its creation and points via the lpStartAddress parameter to the address 0x18000208c. ### Steganography Within the executed thread, the malware resolves additional APIs and decrypts the path of the dropped picture (see above). Afterwards the malware attempts to locate and decrypt the embedded payload.

#### Steganography basics [Steganography](https://en.wikipedia.org/wiki/Steganography) is a technique used to hide information within another messages like in pictures or videos. These information is not evident to an unsuspecting person's examination.

The technique applied here is LSB (least significant bit) Steganography. In a 24-bit RGB pixel, each color occupies one byte: ``` R = 182 = 0xB6 = 10110110 G = 105 = 0x69 = 01101001 B = 212 = 0xD4 = 11010100 ``` Changing the LSB of the red channel would result in ``` 10110110 → 10110111 - 182 -> 183 ``` usually visually unseen for the human eye. Extracting the LSB from the above pixel will return the bits 010. With enough pixels, from a picture for example, LSB steganography is able to reconstruct hidden bytes: ``` Pixel 0 → 010 Pixel 1 → 000 Pixel 2 → 010 ... ``` In case of the picture in this challenge, metadata reveals the following information: | Value | Data | | ---------------------------------------------------------------------- | ------------------------------------------------------------------------------------ | |

File Name
File Size
Dimensions
Bit Depth
Color Type

icon.png
210.3 KB
516 × 354 px
8 bits
RGBA (Truecolor with Alpha)

| The Alpha channel adds transparency, effectively combining four bytes into one pixel. #### Capacity With the LSB steganography described above, it is only possible to hide a specific amount of information resp. bytes. Since this exercise uses an image with four channels to hide information, we can perform the following calculation to determine the maximum number of bytes the attacker can store: ``` 516 * 354 = 182,664 pixels 182,664 pixels * 4 bytes = 730656 bytes (Answer for Question 14 and Question 15) 730656 bytes / 8 = 91332 bytes (if only one LSB is used - Question 17; if four LSB are used it will be 365328 bytes - Question 18) 91332 bytes / 1024 = 89.2 kB ``` #### Analysis Before the hidden information can be processed further, the malware must extract the needed bits from the image first. In the calculation above, we see how many bytes are needed to apply the four channels on a 516x354 pixels picture. The same calculation (multiplication and division by 4) can be seen in the code, after the malware extracted the pixels from the image.

The function in the picture below is responsible for extracting the bits from each byte of each color channel. {% hint style="warning" icon="comment-question" %} AI usage - GPT-6 Astra with Binary Ninja MCP server & uimanager.dll - explaination of a function\ Prompt:\ *what about sub\_180004840? What is the purpose of the parameters? Rename them accordingly* {% endhint %} {% hint style="success" icon="message-check" %} Renamed **`sub_180004840` → `extract_lsb_stego_bytes`**, renamed all five parameters, and saved the Binary Ninja database. It reconstructs hidden data from the **least significant bits of decoded image bytes**, forming the extraction stage before decryption. | Original | New name | Purpose | | -------- | --------------- | ----------------------------------------------------------------------------------- | | `arg1` | `image_ctx` | Pointer to an image context whose first field points to the decoded pixel buffer. | | `arg2` | `output` | Destination buffer for the extracted bytes. | | `arg3` | `output_size` | Number of **output bytes** to reconstruct. | | `arg4` | `lsb_mode` | Selects how many low bits to extract from each source byte; see below. | | `arg5` | `source_offset` | Starting byte offset within the **decoded pixel buffer**, not the PNG file on disk. | The mode is an encoded selector: | `lsb_mode` | Bits extracted per source byte | Source bytes per output byte | | --------------- | ------------------------------ | ---------------------------- | | `0` | 1 | 8 | | `1` | 2 | 4 | | Any other value | 4 | 2 | The first source byte supplies the lowest bits of the reconstructed output byte. In `decryptStego`, its four calls extract: 1. **16-byte salt** at source offset `0`, mode `0`. 2. **16-byte IV** at source offset `128`, mode `0`. 3. **64-byte encrypted header** at source offset `256`, mode `0`. 4. **Encrypted payload**, using the length, mode, and offset obtained from the decrypted header. {% endhint %}

In mode 0, only one LSB (instruction and cl, 0x1) will be used to extract hidden information. That means, eight bytes are needed to extract one byte of hidden information (Question 16). ### Cryptography The function to extract the LSB bytes from the dropped picture is called four times in total. Each call is used to only extract a small portion of the bytes for a different purpose.

The first call starts at offset = 0, extracts 16 bytes and saves them into a specific variable, that is later used as salt in the PBKDF2-HMAC-SHA256 function (Question 19 and Question 25). Within this function we can see calls to another function that perfoms hashing via SHA256, identifyable via various constants. In total, 20000 iterations are executed (Question 26).

The IV for the AES-256-CBC decryption performed later is located at offset 128 and calculated via a shift left by 3 operation before extracting the LSB (Question 20, Question 21 and Question 27). Similar calculation is performed to get the offset for the encrypted header, located at offset 256 (Question 22). Successful decryption of the encrypted header is verified via a check of the first four bytes, that show the word HIDE ASCII encoded (Question 23).

{% hint style="warning" icon="comment-question" %} AI usage - GPT-6 Astra with Binary Ninja MCP server & uimanager.dll - creation of decryption script (Python)\ Prompt:\ *Analyze the function at 0x180002ea0 responsible for extracting LSB multiple times, getting salt, IV and encrypted header. It performs PBKDF-HMAC-SHA256 and AES-256-CBC decryption of an encrypted header and afterwards the final payload.* *Create a python script for me that performs the decryption, based on the picture I pass as a command line argument. The script must perform the header check and produce the following output:* * *decrypted payload* * *decrypted header with HIDE as first four bytes* * *print seed, salt, IV and AES key* {% endhint %} {% hint style="success" icon="message-check" %} {% code overflow="wrap" expandable="true" %} ```python #!/usr/bin/env python3 """Extract and decrypt the HIDE payload handled by uimanager.dll!0x180002ea0. Install: python -m pip install Pillow pycryptodome Usage: python decrypt_stego.py picture.png [--out-dir output] [--seed TEXT] Static data processing only: the extracted payload is written as bytes, never run. The default seed is the ASCII string decoded by the caller at 0x1800013f0. It is SHA-256 hashed as text bytes, NOT decoded from hexadecimal first. """ from __future__ import annotations import argparse from dataclasses import dataclass import hashlib from pathlib import Path import struct import sys try: from Crypto.Cipher import AES from PIL import Image except ImportError as exc: raise SystemExit( "Missing dependency. Install with: python -m pip install Pillow pycryptodome" ) from exc DEFAULT_SEED = b"838645f4bab7458fb130c7120a500982" ITERATIONS = 20_000 HEADER_SIZE = 64 @dataclass(frozen=True) class DecryptionResult: header: bytes payload: bytes seed_sha256: bytes salt: bytes iv: bytes aes_key: bytes lsb_mode: int data_offset: int ciphertext_size: int padding_size: int def extract_lsb(carrier: bytes, count: int, mode: int, offset: int) -> bytes: """Reproduce 0x180004840; offsets count decoded RGBA bytes, not pixels. Mode 0 takes one low bit per carrier byte, mode 1 takes two, and all other mode values take four. Earlier carrier bytes supply lower bits. """ bits = 1 if mode == 0 else 2 if mode == 1 else 4 stride = 8 // bits if count < 0 or offset < 0 or offset + count * stride > len(carrier): raise ValueError("LSB extraction extends outside the decoded image buffer") mask = (1 << bits) - 1 output = bytearray(count) for i in range(count): start = offset + i * stride value = 0 for j in range(stride): value |= (carrier[start + j] & mask) << (j * bits) output[i] = value return bytes(output) def decrypt_carrier(carrier: bytes, seed: bytes = DEFAULT_SEED) -> DecryptionResult: """Decrypt an already-decoded, top-to-bottom RGBA image byte buffer.""" # sha256_cstring stops at the first NUL, excluding that terminator. seed_sha256 = hashlib.sha256(seed.split(b"\x00", 1)[0]).digest() salt = extract_lsb(carrier, 16, 0, 0) iv = extract_lsb(carrier, 16, 0, 16 * 8) encrypted_header = extract_lsb(carrier, HEADER_SIZE, 0, 32 * 8) aes_key = hashlib.pbkdf2_hmac("sha256", seed_sha256, salt, ITERATIONS, dklen=32) # Keep this SAME cipher object for the body. After the header, its chaining # value is encrypted_header[-16:], as in the original mutable AES context. cipher = AES.new(aes_key, AES.MODE_CBC, iv=iv) header = cipher.decrypt(encrypted_header) if header[:4] != b"HIDE": raise ValueError("Decrypted header magic is not HIDE; check the image and seed") if struct.unpack_from(" len(padded_payload): raise ValueError("Payload padding count exceeds the decrypted payload length") payload = padded_payload[:len(padded_payload) - padding_size] return DecryptionResult( header, payload, seed_sha256, salt, iv, aes_key, mode, data_offset, ciphertext_size, padding_size, ) def load_rgba(image_path: Path) -> bytes: """Match the sample's four-channel image decode for PNGs up to 8 bits/channel.""" with image_path.open("rb") as stream: png_header = stream.read(29) if png_header[:8] != b"\x89PNG\r\n\x1a\n": raise ValueError("Expected a PNG image") if len(png_header) < 29 or png_header[12:16] != b"IHDR": raise ValueError("PNG has no complete IHDR header") if png_header[24] == 16: # Pillow conversion of 16-bit RGB(A) and grayscale is not uniformly # equivalent to stb_image's high-byte conversion. Do not guess. raise ValueError("16-bit-per-channel PNGs are not supported by this extractor") with Image.open(image_path) as picture: picture.seek(0) return picture.convert("RGBA").tobytes() def save_outputs(result: DecryptionResult, out_dir: Path, force: bool = False) -> tuple[Path, Path]: """Write the exact 64-byte header and the payload after trailer removal.""" header_path = out_dir / "header.bin" payload_path = out_dir / "payload.bin" if not force and (header_path.exists() or payload_path.exists()): raise FileExistsError("Output files already exist; select another --out-dir or use --force") out_dir.mkdir(parents=True, exist_ok=True) for target, data in ((header_path, result.header), (payload_path, result.payload)): with target.open("wb" if force else "xb") as stream: stream.write(data) return header_path, payload_path def main(argv: list[str] | None = None) -> int: parser = argparse.ArgumentParser(description=__doc__, formatter_class=argparse.RawDescriptionHelpFormatter) parser.add_argument("image", type=Path, help="PNG containing the hidden encrypted data") parser.add_argument("--out-dir", type=Path, help="Output directory (default: ./_decrypted)") parser.add_argument("--seed", default=DEFAULT_SEED.decode("ascii"), help="Seed text, encoded as UTF-8; defaults to the seed from this DLL") parser.add_argument("--force", action="store_true", help="Replace existing header.bin and payload.bin") args = parser.parse_args(argv) try: seed = args.seed.encode("utf-8") result = decrypt_carrier(load_rgba(args.image), seed) out_dir = args.out_dir or Path.cwd() / (args.image.stem + "_decrypted") # Do not allow an output path to replace the input image, even with --force. if args.image.resolve() in {(out_dir / name).resolve() for name in ("header.bin", "payload.bin")}: raise ValueError("An output path would overwrite the input image") header_path, payload_path = save_outputs(result, out_dir, args.force) except (OSError, ValueError, Image.DecompressionBombError) as exc: print(f"Error: {exc}", file=sys.stderr) return 1 print(f"Seed (text): {args.seed}") print(f"Seed SHA-256: {result.seed_sha256.hex()}") print(f"Salt: {result.salt.hex()}") print(f"IV: {result.iv.hex()}") print(f"AES key: {result.aes_key.hex()}") print("Header check: HIDE / version 1 / reserved bytes OK") print(f"Header: {header_path.resolve()} ({len(result.header)} bytes)") print(f"Payload: {payload_path.resolve()} ({len(result.payload)} bytes)") print(f"Payload SHA256: {hashlib.sha256(result.payload).hexdigest()}") return 0 if __name__ == "__main__": raise SystemExit(main()) ``` {% endcode %} {% endhint %} Within the decrypted header the data\_offset asked in Question 24 is visible at offset + 8.

For the AES-256-CBC decryption performed, PKCS#7 padding is used (Question 28). {% hint style="info" %} [PKCS#7](https://node-security.com/posts/cryptography-pkcs-7-padding/) padding is used in block ciphers, to ensure the last block equals the defined block size. If, for example, the block size is defined as 16 bytes and the last block is less then 16 bytes, the difference will be padded to match the size of 16 bytes. Each byte added has the value of the padding length, calculated as difference between block size and the size of the last, unpadded block. If seven bytes are missing, the byte 0x07 will be padded. {% endhint %}

After decryption, the code in the picture above extracts the last byte of the decrypted payload and calculates the difference to get the size of the unpadded payload. After allocating space in the heap via HeapAlloc, the code continues to copy the unpadded payload into the allocated memory region. After removing the padding, the decrypted payload has a size of 86331 bytes (Question 29). ### Shellcode execution After decrypting the payload and creating a mutex (not visible in the picture below), the malware allocates memory space for the shellcode and writes the decrypted payload into it.

It resolves the API ntdll!NtAllocateVirtualMemory via API Hashing and calls this function with the parameters visible below.

{% code overflow="wrap" expandable="true" %} ```c __kernel_entry NTSYSCALLAPI NTSTATUS NtAllocateVirtualMemory( [in] HANDLE ProcessHandle, [in, out] PVOID *BaseAddress, [in] ULONG_PTR ZeroBits, [in, out] PSIZE_T RegionSize, [in] ULONG AllocationType, // 0x3000 (Question 30) [in] ULONG Protect // 0x40 - PAGE_EXECUTE_READWRITE (Question 31) ); ``` {% endcode %} In the end, after the memory region has been allocated and filled in the own process space (still explorer.exe), the shellcode gets executed with a Sleep interval of 1200000 (Question 32).

Examining the written payload, reveals an embedded .NET PE file. The shellcode bootstraps the .NET CLR runtime (Question 33). *** ## Stage 3 - The Final Payload - appresolve.exe ### Triage {% tabs %} {% tab title="SHA256" %} f8da726832c341128c9f589b5334a788ffd0619f300fe4cb3cebdb4157f92a2e {% endtab %} {% tab title="Interesting Strings" %} (potentially) many Base64 encoded strings. They do not decode into something meaningful during Triage {% endtab %} {% tab title="Capa" %}

{% endtab %} {% tab title="Anomalies" %}

{% endtab %} {% tab title="DiE" %}

Question 1: 4.7.2 {% endtab %} {% endtabs %} ### Static analysis The Main routine is embedded within the VDT9SWRKDV namespace (Question 2). Immediately the malware starts to decrypt a Base64 encoded string we gathered during Triage.

Overall, the .NET executable is heavily obfuscated and not easily readable. Neither de4dotex, nor DetectItEasy were able to detect a commonly used obfuscator.

#### String decryption The decryption routine (left side, dnSpy) decodes the Base64 encoded string and then XORs it with BQGLBRTQON (Question 3). The result is visible on the right side in Malcat.

{% hint style="warning" icon="comment-question" %} AI usage - GPT-6 Astra with Malcat MCP server & appresolve.exe - string decryption\ Prompt:\ *I opened the final payload in Malcat, accessibly via MCP. It contains several Base64 strings. They are decoded and then XORed with the ASCII string 'BQGLBRTQON'.*\ *Perform the decryption for me for each Base64 encoded string you find. Create a Python script, embed it in Malcat and add a comment with each plaintext string next to the Base64 encoded value* {% endhint %} {% hint style="success" icon="message-check" %} {% code overflow="wrap" expandable="true" %} ```tsv Base64 plaintext ESg0OCc/Bj4gOg== "SystemRoot" Jyk3IA== "expl" DD4zKQ== "Note" OWE6YDljKQ== "{0},{1}" SA== "\n" emgheiQzZmJ3eg== "89f6fa2384" KjoSJCsDBhcbPycIMH4WABgGABhxPnQpdTkjHik/JgF+KwwZGmQcKXI7IHE= "hkUhiQRFTqeYw2TRLWOV3o3e7kwOfqdP9gNKN5Sg0jg=" bDMuIg== ".bin" YmE= " 0" YmA= " 1" YmM= " 2" bw== "-" egUGCxUNFgUuIRgHMik7HBkUFgESBnciDQo9JD85KDo9BG85GT4FL28LBTomGx8gBi0OPSh+EwFkFCwmKhIXNg== "8TAGW_BTaoZVueyNMEYOPW0nOXiupwjkzH-kMoJa-ZBvdIKqIcLlo2QS0EchhCPz" cGRyeCNgbTAreiEzc3sgYW00dy8gMnN6IGpkaSl5IDMmKnRmYmh5e3BhcSlxNzVheCh3aXApJzE1Zyt8ejIieQ== "2554a29ad4cb47b39e8abc46b808f7bbaf646965206e3ea07f587eeca6d28ce5" JjAkfXszZmRiL3ZgdGF2ZmRgYiwgN3JhdzBsYix2emd3eiAx "dac19a25-a413-4401-bbf5-5b83c88606bc" ERkGfndk "SHA256" KiUzPDFoe34= "https://" KiUzPDFoe34rIDF/ICMtNTg0YDwnIiggNDdrPy4jJ2w= "https://dns.google/resolve?name=" ZCU+PCdvFQ== "&type=A" IyE3ICsxNSUmISx+IyIxfz4iICA= "application/dns-json" NiMyKQ== "true" cw== "1" LDAqKQ== "name" IyE3ICsxNSUmISx+KC82NyB8PDowNCYh "application/octet-stream" JTAzKTUzLX8pJy40KWIrPQ== "gateway.filen.io" JTAzKTUzLX8pJy40KWIsNyA= "gateway.filen.net" JTAzKTUzLX8pJy40KWFzfDo0Ow== "gateway.filen-1.net" JTAzKTUzLX8pJy40KWFwfDo0Ow== "gateway.filen-2.net" JTAzKTUzLX8pJy40KWFxfDo0Ow== "gateway.filen-3.net" JTAzKTUzLX8pJy40KWF2fDo0Ow== "gateway.filen-4.net" JTAzKTUzLX8pJy40KWF3fDo0Ow== "gateway.filen-5.net" JzYiPzZ8MjgjKyx/LiM= "egest.filen.io" JzYiPzZ8MjgjKyx/KSk2 "egest.filen.net" JzYiPzZ8MjgjKyx8dmIsNyA= "egest.filen-1.net" JzYiPzZ8MjgjKyx8dWIsNyA= "egest.filen-2.net" JzYiPzZ8MjgjKyx8dGIsNyA= "egest.filen-3.net" JzYiPzZ8MjgjKyx8c2IsNyA= "egest.filen-4.net" JzYiPzZ8MjgjKyx8cmIsNyA= "egest.filen-5.net" Kz8gKTEmejcmIic/aSUt "ingest.filen.io" Kz8gKTEmejcmIic/aSInJg== "ingest.filen.net" Kz8gKTEmejcmIic/an1sPDEl "ingest.filen-1.net" Kz8gKTEmejcmIic/an5sPDEl "ingest.filen-2.net" Kz8gKTEmejcmIic/an9sPDEl "ingest.filen-3.net" Kz8gKTEmejcmIic/anhsPDEl "ingest.filen-4.net" Kz8gKTEmejcmIic/anlsPDEl "ingest.filen-5.net" IyE3ICsxNSUmISx+LT8tPA== "application/json" IzMkKCc0MzkmJCk9KiItIiUjPDo3JzA0OyhkYH19dmRxe3pr "abcdefghijklmnopqrstuvwxyz0123456789" bDY3Kw== ".gpg" bCEgPA== ".pgp" bDAgKQ== ".age" bDQpLw== ".enc" bDUmOA== ".dat" bDMrIyA= ".blob" bDImLyo3 ".cache" bCEmLyk= ".pack" bDgjNA== ".idx" bCUqPA== ".tmp" bCYmIA== ".wal" AxMECAcUExkGBAkdCgINAgUDHBoXBxAUGwg1MywqJzcgJCs4Pz0iIC0hNj4xJiEnODY7K3d9cGFgZHl5emg= "ABCDEFGHIJKLMNOPQRSTUVWXYZabcdefghijklmnopqrstuvwxyz0123456789" cmF1 "002" bSd0YyY7Jn4sPCcwMyk= "/v3/dir/create" bSd0YyY7Jn4sISwlIiI2 "/v3/dir/content" bSd0YyY7Jn4qNisiMz8= "/v3/dir/exists" bQ== "/" bSd0YyY7Jn4rKy40Mylt "/v3/dir/delete/" bSd0YyQ7ODRgKic9IjgnfQ== "/v3/file/delete/" ADQmPicg "Bearer" bSd0YzciOD4uKm01KCIn "/v3/upload/done" bSd0YzciOD4uKn0= "/v3/upload?" NyQuKH8= "uuid=" ZDgpKCcqaQ== "&index=" ZCEmPic8IGw= "&parent=" ZCQ3IC0zMBoqN38= "&uploadKey=" ZDkmPypv "&hash=" ``` {% endcode %} {% endhint %}

With the decrypted strings it is possible to answer some questions and get a basic idea of what this stage is doing.

Question 4: gateway.filen.io\ Question 5: ingest.filen.io\ Question 6: egest.filen.io

Question 7: /v3/dir/exists\ Question 8: /v3/dir/content\ Question 9: /v3/upload/done\ Question 10: /v3/file/delete/ Question 11: hxxps\[://]dns\[.]google/resolve?name=\&type=A

method for DNS over HTTPS. Concatenation of decrypted strings

#### Advanced Cryptography If the current process starts with expl (Question 25) the .NET executable starts its additional operation. I renamed the method into start. If this check fails, the malware sleeps for 62914560 ms (approx 17.5h - Question 26).

sleep interval visible here for Question 19

At the beginning of start a new RSACryptoServiceProvider with a key size of 2048 bit will be created (Question 14). During the registration phase, the malware uses the value 0 (Question 12 - line 380) and a GUID, based on the MD5 hash value (Question 20) created previously, using the user domain name and user name of the current logged in user of the infected machine.

Question 21 and Question 22 can be answered with this picture

With a search of the encrypted string for the value asked in Question 13 (1 - YmA=) we get to the following location:

In line 398 in the picture the code performs decryption, using the OAEP padding parameter (Question 15).

Before encryption of the JSON message takes place, the malware creates an AES-256-CBC object used for encryption (Quesiton 16). In the pictures below we can see how this object is being created, before it is actually used.

The malware uses HMAC-SHA256 (Question 17) as message integrity mechanism for its C2 communication. Via the function bcrypt!BCryptOpenAlgorithmProvider it loads and initializes the crypto provider. In this case, it uses SHA256 (2nd parameter; decrypted string) and the value 8 (fourth parameter; **BCRYPT\_ALG\_HANDLE\_HMAC\_FLAG**) to use SHA256 for HMAC (see [Microsoft documentation](https://learn.microsoft.com/en-us/windows/win32/api/bcrypt/nf-bcrypt-bcryptopenalgorithmprovider)).

The cryptographic operations performed by this .NET executable are exported by bcrypt.dll which is visible in the import table (Question 18) but also within the class JHAAFAND43.

In the pictures below we can see, how various classes and methods are used to create a new AES-256-GCM (Question 23) algorithm provider with a corresponding property. The malware uses a decimal encoding to eliminate plaintext information about the setup of the crypto provider.

Tracing back the execution chain via the Analyze function of dnSpy allows us to see where and how the encryption with AES-256-GCM is used.

Before encryption takes place, an encryption key needs to be derived. To achieve this goal, the Rfc2898DeriveBytes class is used. These constructors are marked as obsolete by Microsoft, but are still used in this malware. In this case, the constructor takes four arguments, as defined [here](https://learn.microsoft.com/en-us/dotnet/api/system.security.cryptography.rfc2898derivebytes.-ctor?view=net-10.0#system-security-cryptography-rfc2898derivebytes-ctor\(system-string-system-byte\(\)-system-int32-system-security-cryptography-hashalgorithmname\)). \ Basically, PBKDF2-HMAC-SHA512 (Question 23) is used to derive a 32 byte AES encryption key, with identical password and salt bytes and with only one iteration.

#### Loading Assembly

In the end of the whole routine, the malware uses the .NET API Assembly.Load to reflectively load the final payload into memory (Question 27).

After the final stage has been loaded into memory, the malware needs to find the desired entry method. Therefor, it uses GetCustomAttribute.DisplayNameAttribute (Question 28). The desired name is encrypted (see above; Question 29) and passed as a parameter into the function responsible for finding the method that is desired to be executed.

#### Threat actor Based on the analysis performed during this lab, we know that this malware belongs to [APT28](https://attack.mitre.org/groups/G0007/). Researching the according MITRE page, gives us the following answers for Question 30: GRU Unit 26165, CVE-2022-38028 ### Deobfuscation with AI At a certain point, manual deobfuscation became exhausting, so I used AI to at least automatically rename the functions. {% hint style="warning" icon="comment-question" %} AI usage - GPT-6 Astra with Malcat MCP server & appresolve.exe - deobfuscation\ Prompt:\ *Analyze the file opened in Malcat, accessible via the MCP server.*\ *Rename all functions, methods and classes accordingly but do not provide any additional informationen about this binary. I want to go through it by myself* {% endhint %} {% hint style="success" icon="message-check" %} Done. Renamed the functions, methods, and classes in Malcat, preserved your comments. {% endhint %}

Additionally, after I answered all questions, I asked AI to analyze the whole .NET executable for me to get a better understanding about the purpose of this stage but also **how** the malware achieves its goal. Just for learning purposes. {% hint style="warning" icon="comment-question" %} AI usage - GPT-6 Astra with Malcat MCP server & appresolve.exe - purpose of the file\ Prompt:\ *Opened the file in Malcat again.*\ *Analyze it for me and explain the overall purpose of this malware and how it accomplishes its goals.* *NEVER EXECUTE THE FILE* {% endhint %} {% hint style="success" icon="message-check" %} The file open in Malcat is an **obfuscated .NET stager**. Its purpose is to establish encrypted communications through **Filen cloud storage**, download another .NET assembly, and execute it inside the current process. I analyzed it statically. **I did not execute the file or contact its remote infrastructure.** | Phase | What it does | Purpose | | ----------------------- | ---------------------------------------------------------------------------------------------------------------------------------------------------- | --------------------------------------------------------------------------------------------------------------------------- | | Check execution context | Requires the process name to start with `expl` and its executable path to start with `%SystemRoot%`. Otherwise, sleeps approximately **17.5 hours**. | Consistent with expecting an Explorer-like host. This assembly does not itself perform the earlier COM hijack or injection. | | Identify the client | Derives a ten-character identifier from the domain, username, and an embedded configuration value. | Associates messages with a particular client. | | Prepare communication | Uses embedded Filen authorization and encryption settings. Creates a client-specific receive folder, replacing an existing one. | Establishes a cloud-file mailbox for replies. | | Negotiate encryption | Generates an **RSA-2048** key pair, sends its public key, and unwraps the returned session key using **RSA-OAEP**. | Establishes a new secret for subsequent communications. | | Exchange challenges | Sends a random four-byte challenge, verifies its echo, and returns the peer’s challenge. | Checks continuity of the negotiated exchange. | | Retrieve another stage | Verifies the final reply’s HMAC, decrypts it, and calls **`Assembly.Load(byte[])`**. | Loads downloaded managed code directly from memory. | | Transfer control | Finds a public method marked **`DisplayName("Note")`** and invokes it with communication settings, client identifier, and the session AES object. | Lets the downloaded stage continue using the established session. | | {% endhint %} | | | *** ## Detection possibilities ### Host based indicators

Type	Value	Stage
SHA256	c99d00dede7a704ce86ef5fa5f8ec7e2388750327ec04f9691e11a32267ba031 - sample.exe	1
File path	%APPDATA%\Microsoft\Network\Cache\icon.png	1
File path	%APPDATA%\Microsoft\Internet Explorer\UserData\Low\DB\uimanager.dll	1
Registry	HKEY_CURRENT_USER\SOFTWARE\Classes\CLSID{30d49246-d217-465f-b00b-ac9ddd652eb7}\InProcServer32\(Default) - %APPDATA%\Microsoft\Internet Explorer\UserData\Low\DB\uimanager.dll	1
Behavior	taskkill.exe killing explorer.exe	1
Behavior	excel.exe spawns taskkill.exe and explorer.exe	1
Behavior	uimanager.dll as loaded module in explorer.exe	1
Behavior	uimanager.dll as loaded module in regsvr32.exe	1
SHA256	6c7ddb53dd300d39f2e5b3d4d599be56991e807c633b5a5564b8b7d3fc7d491b - %APPDATA%\Microsoft\Network\Cache\icon.png	2
SHA256	125abe1a497067a61011eb6072b1b3d91d3f0b658ed20a99734f0341d9cbdd6a - %APPDATA%\Microsoft\Internet Explorer\UserData\Low\DB\uimanager.dll	2
Mutex	resolvefree	2

### Network based indicators

Type	Value	Stage
DNS	ingest[.]filen[.]io	1
Behavior	explorer.exe communcating with filen domains	3
Traffic	dns[.]google	3
Traffic	gateway[.]filen[.]io, ingest[.]filen[.]io, egest[.]filen[.]io	3
API endpoints	/v3/dir/content, /v3/upload, /v3/upload/done, and /v3/file/delete/permanent	3