Today WikiLeaks released CIA documents on a set of Windows hacking tools bundled as the Grasshopper framework. Grasshopper specifically targets Windows systems and infects them with persistent implants which will allow remote access without alarming anti-virus software or the target themselves. Many of these implants are quite sophisticated and can even be made to execute immediately without the target even having to reboot their machine.

In an effort to digest this large sum of information, the WikiLeaks Research Community issued another challenge to "Catch the Grasshopper". Here is my research on the subject according to the stipulations of the Challenge:

For this research challenge, we are going through the manuals for the Grasshopper components. We're hoping to map out how the components work by answering the following questions about each:

1. What does the component do? (brief, non-technical summary)
2. How does the component work? (technically, how does it persist malware on a computer?)
3. What traces would the component leave on the computer system?
4. If there are multiple versions of the component, how has it changed from version to version?
5. Any other interesting notes about the component?

More information on the WLResearchCommunity challenge itself can be found at its WikiLeaks Reddit post.

I also created a table comparing persistence modules in a more recent Steemit post.

Basic utilities

Here are some of the basic components in Grasshopper which are not necessarily persistence modules themselves, but assist in using and exploiting them.

Drop

• Drop is a Grasshopper component that provides a simple way to drop a file to a target's file system
• The Drop component writes its input file content to the target file system at a user-specified location. If the directory specified for the output file does not exist, it is created. If no input file is specified then an empty file is created.

NULL

• NULL is a module that lays down and executes a payload without deleting it.
• As of version 2.0, NULL can optionally also lay down (but not execute) an arbitrary number of other user provided files.
• This module is meant to be used with either one-shot tools or with payloads that provide their own persistence separate from Grasshopper, allowing existing tools to make use of the Grasshopper payload obfuscation.
• NULL supports 32- and 64-bit EXE payloads only.
• The executed payloads are visible in the Windows Task Manager.

Run

• Run saves a .exe file (the malware payload) at a pre-specified location on the file system.
• It seems that the .exe file is saved with no obfuscation or any other attempts to hide it. Additionally, if directory specified for saving the .exe does not already exist, Run creates it.

Persistence modules

"Persistence modules" are tools designed to assist the "persistence" (or continued access in spite of reboots, reinstalls, etc.) of payloads available in Grasshopper. Payloads, often (but not always) DLL and EXE files, can then be used to obtain various data reports from a target system in XML format and more. You'll notice that there is a tremendous variety of these available in Grasshopper, and this is part of the CIA IOC's continued effort to bypass any security measures a target might employ.

The following list is of the Grasshopper persistence modules WikiLeaks has made available, including their methods of deploying payloads, available payloads, notable facts and how these persistence methods may be detected or found on a Windows system.

All these modules will use various Windows exploits to install and deploy 32 and 64-bit payloads including EXE and DLL files as well as GH1 Grasshopper interfaces (executable assembly code that gets injected into the module's stub file). Most, but not all, are designed to delete any deployed components and system changes should the module fail to install and are able to run with SYSTEM-level privileges.

Bermuda

• Bermuda uses the Windows COM interface to create tasks in the Windows Task Scheduler. The tasks are used to schedule the execution of a user-provided payload.
• If the module fails to install the payload, it will delete any deployed components and remove the scheduled task.
• Bermuda can be detected by the following:
  • The process of the task executable, whether payload or stub, is visible in the Task Manager during execution
  • Bermuda will create scheduled task visible in the Task Scheduler. In addition a hidden file named '<TaskName>.job' will be created by Windows in '%SYSTEMROOT%\Tasks

Bamboo and Buffalo

• Buffalo and Bamboo use direct registry modification to register a stub as a service DLL in the netsvcs service host.
• If the module fails to install the payload, it will delete any deployed components and remove the registry modifications.
• Buffalo modules require a reboot for installation and execution, but Bamboo can use "service hijacking" to run immediately on installation.
• Buffalo/Bamboo can be detected by the following:
  • Buffalo/Bamboo will create a service visible in the Services view of the Microsoft Management Console with the user-specified display name and description.
  • A registry key will be placed in HKLM\SYSTEM\CurrentControlSet\services<ServiceName>
  • The Service Name will be placed in a registry REG_MUTLI_SZ value at HKLM\SOFTWARE\Microsoft\Windows\NT\CurrentVersion\Svchost\netsvcs

Crab

• Crab uses direct registry modification to register a payload as a Windows Service.
• If the module fails to install the payload, it will delete any deployed components and remove the registry modifications.
• Crab can be detected by the following:
  • Crab will create a service visible in the Services view of the Microsoft Management Console with the user-specified display name and description.
  • A registry key will be placed in HKLM\SYSTEM\CurrentControlSet\services<ServiceName>
  • The Service Name will be placed in a registry REG_MUTLI_SZ value at HKLM\SOFTWARE\Microsoft\Windows

NetMan

• NetMan maintains persistent payloads through the Windows Network Connections Manager Service
• NetMan can be detected by the following:
  • If the payload is an EXE, the process of the payload executable is visible in the Task Manager during execution.
  • NetMan will create a registry key in HKLM\ SYSTEM\CurrentControlSet\Control\Network\LightweightCallHandlers\NETMAN\Startup storing the path to the Netman Stub DLL.

Scrub

• Scrub uses direct registry modifications to create a run key in the Windows registry. The run key is used to run an executable payload or stub at user login.
• Whenever a user logs in, the Windows OS will run all executables listed in the Scrub registry under the run key with that user's privileges. This is unique because most other tools run their payloads with SYSTEM privileges.
• Scrub can be detected by the following:
  • The process of the run key executable, whether payload or stub, is visible in the Task Manager during execution.
  • A registry key will be placed at HKLM\SOFTWARE\Microsoft\Windows\CurrentVersion\Run<Name>. The name of the run key matches the user-specified name of the run key executable, whether the stub or payload.

ScheduledTask

• ScheduledTask maintains persistent payloads through the Windows Task Scheduler.
• ScheduledTask uses the Windows Task Scheduler 1.0 COM interface to create a new scheduled task.
• The scheduled task may be configured to trigger on either system startup or user logon.
• ScheduledTask can be detected by the following:
  • Payload Executable, located at a user specified location
  • Payload Directory, may have been created
  • Task Stub Executable, located at a user specified location
  • Task Stub Directory, may have been created
  • Scheduled Task XML, located at %SYSTEMROOT%\System32\Tasks<TASK_NAME>

ServiceDLL

• ServiceDLL maintains persistent payloads through existing Windows Services.
• ServiceDLL will has 6 different stub configurations depending on user input or an automatic detection script.
• ServiceDLL can hijack an existing, stopped service DLL’s entry to gain immediate execution.
• ServiceDLL can be detected by the following:
  • File System
    • Service Stub Executable, located at a user specified location <STUB_PATH>
    • Service Stub Directory, may have been created
    • Nodpersist interface payloads are not on disk but are an obfuscated resource
      in the stub
    • Payload Directory, may have been created
    • Unhijack Executable, located at a user specified location <UNHIJACK_PATH>
    • Unhijack Directory, may have been created
  • Registry Keys
    • Created
      • HKLM\SYSTEM\CurrentControlSet\Services<SERVICE_NAME>
      • HKLM\SYSTEM\CurrentControlSet\Services<SERVICE_NAME>\ImagePath
      • HKLM\SYSTEM\CurrentControlSet\Services<SERVICE_NAME>\ObjectName
      • HKLM\SYSTEM\CurrentControlSet\Services<SERVICE_NAME>\DelayedAutoStart
      • HKLM\SYSTEM\CurrentControlSet\Services<SERVICE_NAME>\ErrorControl
      • HKLM\SYSTEM\CurrentControlSet\Services<SERVICE_NAME>\Start
      • HKLM\SYSTEM\CurrentControlSet\Services<SERVICE_NAME>\Type
      • HKLM\SYSTEM\CurrentControlSet\Services<SERVICE_NAME>\Parameters
      • HKLM\SYSTEM\CurrentControlSet\Services<SERVICE_NAME>\Parameters\ServiceDll
      • HKLM\SYSTEM\CurrentControlSet\Services<SERVICE_NAME>\Description
      • HKLM\SYSTEM\CurrentControlSet\Services<SERVICE_NAME>\DisplayName
    • Modified
      • HKLM\SOFTWARE\Microsoft\Windows NT\CurrentVersion\SvcHost\netsvcs
    • Modified (during hijack)
      • HKLM\SYSTEM\CurrentControlSet\Services<HIJACKED_SERVICE>\Parameters\ServiceDll
      • HKLM\SYSTEM\CurrentControlSet\Services<HIJACKED_SERVICE>\Parameters\ServiceDllUnloadOnStop

ServiceProxy

• ServiceProxy maintains persistent payloads through existing Windows Service DLL files.
• ServiceProxy can be used to imitate/impersonate a number of Windows Services including Schedule, LanmanServer, NlaSvc, iphlpsvc, CryptSvc, AudioSvc, or LanmanWorkstation.
• ServiceProxy can be detected by the following:
  • File System
    • Service Stub Executable, located at a user specified location <STUB_PATH>
    • Service Stub Directory, may have been created
    • Payload Executable, located at <STUB_PATH>{cpl|mgr|cfg}.{exe|dll} or specified
      path
    • Payload Directory, may have been created
  • Registry Keys
    • • HKLM\SYSTEM\CurrentControlSet\Services<PROXIED_SERVICE_NAME>\Parameters
    • Modified during hijack
      • HKLM\SYSTEM\CurrentControlSet\Services<HIJACKED_SERVICE>\Parameters\ServiceDll
      • HKLM\SYSTEM\CurrentControlSet\Services<HIJACKED_SERVICE>\Parameters\ServiceDllUnloadOnStop

Stolen Goods 2.1

• Stolen Goods 2.1 is an advanced persistence module with unique persistence methods.
• Stolen Goods 1.0 was originally taken by the CIA from Russian organized crime and was completely redesigned in v2.0.
• Stolen Goods maintains a persistent payload through custom code injected into the Windows boot sequence.
• Stolen Goods payloads can be either in a DLL file or a Windows Driver.
• This module is unique for its ability to use both persistence methods simultaneously.
• Stolen Goods 2.1 also introduced stealth functionality that can hide sections of the target's disk containing the payload by hiding it in unpartitioned space.
• At most Stolen Goods 2.1 will leave only one, encrypted file on the target disk as well as registry keys if it is using a JediMindTricks driver payload.
• Stolen Goods 2.1 was able to bypass just about all personal security products (PSP) including:
  • Kaspersky
  • 360safe
  • Symantec
  • ESET NOD 32

Wheat

• Wheat maintains persistent payloads as Windows Drivers.
• Wheat can be detected by the following:
  • Wheat writes the payload binary to the target filesystem at %SYSTEMROOT%\System32\drivers<DriverName>.sys
  • A registry key will be placed in HKLM\System\CurrentControlSet\services<DriverName>

WUPS

• WUPS maintains persistent payloads through the Windows Update Service.
• WUPS can be configured to start the payload immediately without rebooting the system.
• When the WUPS stub is loaded and executed by Windows Update, it will start the payload executable with SYSTEM privileges and spawn a process to maintain its place in the list of Windows Update DLLs.
• Windows Update continues this same behavior whether or not updates have been disabled by the user.
• WUPS can be detected by the following:
  • The process of the payload executable is visible in the Task Manager during execution. A process running the WUPS Stub within RunDll32 is briefly visible in the Task Manager while it re-submits itself to the list of Windows Update DLLs.
  • WUPS will create a registry key in HKLM\SOFTWARE\Microsoft\Windows\CurrentVersion\WindowsUpdate\Setup\ServiceStartup<WUPSKeyName> storing the path to the WUPS Stub DLL.
  • The WUPS startup will create a non-critical error log entry in the Windows Update log in the Windows directory.

If you like my work and wish to support my future projects and research, consider subscribing to my Patreon and receive additional perks for helping the cause!