_     _ _    _ _   _             
                      | |   (_) |  (_) | | |            
  __ _ _ __ __ _ _ __ | |__  _| | ___| |_| |_ ___ _ __  
 / _` | '__/ _` | '_ \| '_ \| | |/ / | __| __/ _ \ '_ \ 
| (_| | | | (_| | |_) | | | | |   <| | |_| ||  __/ | | |
 \__, |_|  \__,_| .__/|_| |_|_|_|\_\_|\__|\__\___|_| |_|
  __/ |         | |                                     
 |___/          |_|                                     
                                                             
               __..--''``---....___   _..._    __
     /// //_.-'    .-/";  `        ``<._  ``.''_ `. / // /
    ///_.-' _..--.'_    \                    `( ) ) // //
    / (_..-' // (< _     ;_..__               ; `' / ///
     / // // //  `-._,_)' // / ``--...____..-' /// / //

a (possibly) EDR-evasive ransomware utilizing GPU shaders for encryption

DISCLAIMER

The initial inspiration came from this post from smelly at vx_underground, which mentions that security tools are rather blind to what's happening in VRAM.

Further research showed that it appeared that endpoint controls are typically pretty bad at monitoring computation on GPUs in general, which led me to wonder if we could build GPU-based ransomware, and whether that would evade detection.

This work should never be utilized outside of this educational scope and should never be utilized on any unauthorized computer system.

ANOTHER DISCLAIMER

I don't have major access to super good EDR, like CrowdStrike or SentinelOne, due to poor.

This was instead tested against various other consumer and enterprise-grade solutions, and proved to be mostly successful in these tests.

Your mileage may vary, but I'm quite keen to see how it performs on more advanced EDR solutions anyway.

Building from Source

Requirements

• Rust (latest stable version recommended)
• A GPU with compute shader support
• wgpu-compatible drivers
• (perferably) a Windows machine with DirectStorage support.

Building

cargo build --release

The compiled binary will then be aavailable at target/release/graphikitten

Usage

Basic usage

# Encrypt files in a directory (recursive)

./graphikitten -key "key string" -dir /path/to/directory

# Decrypt files in a directory (that were previously encrypted by graphikitty)

./graphikitten -decrypt -key "key string" -dir /path/to/directory

DirectStorage (Windows-only)

The DirectStorage API will be used automatically for file IO if your machine is compatible with the API AND if the .dll and .lib files are stored in the same folder as the executable

They can be downloaded from Microsoft

Optional arguments

-verbose    |  Enables debug logging 

Notes

• The same key must be used for encryption and decryption
• During encryption, some metadata is added to files to allow for decryption to work without failing miserably and permanently nuking files.
• Files over 100MB are skipped by default, this is mostly arbitrary but decryption definitely will fail on anything larger than 18 exabytes due to the length metadata storage breaking. (joke)
• Explicit rules are added to prevent encryption of critical system files, though these are likely not exhaustive, so don't get too comfortable.