# Vault 7: Projects

This publication series is about specific projects related to the Vault 7 main publication.

### Grasshopper

# GH-ServiceProxy-v1_1-UserGuide

- 1
- 2
- 3
- 4
- 5

SECRET//NOFORN
--stubname STUBNAME alternate stubname to use {A|B|C} [default A]
Example
(gh) add component serviceproxy
–p “c:\windows\system32\example.dll”
-n LanmanServer
--hijack
-k “%temp%\killme.txt”
--payloadpath "%SYSROOT%\payload.dll"
Note: The --hijack option temporarily utilizes a stopped service to immediately start
the ServiceProxy Stub. This hijack feature only works once and will not work
again until system is rebooted.
2.2 Supported Payload Types
ServiceProxy accepts input payloads in EXE or DLL formats for the x86 or x64
architectures. If a payload DLL supports the NOD Persistence Specification, the stub
will memory load it during execution if using Stub A otherwise it is written to disk
and loaded. ServiceProxy is a terminating component and does not output a
payload.
Input Type Output Type(s)
x86 DLL nod-persist None
x64 DLL nod-persist None
x86 DLL None
x64 DLL None
x86 EXE None
x64 EXE None
2.3 Supported Variant Stubnames
As part of the ServiceProxy component version 1.1, variant stubs were added.
Three stubs are available the default stub A, and stub B, and stub C.
1. The default stub A uses the CRT and uses resources data to store
configuration information as well as the obfuscated payload(using xor with
random key). Stub A uses a payload file name specified in command line
option or if none specified will use stubname dll filename except with a
stubname{cpl}.extension. Stub A also supports NOD-persist dlls and
performs memory loading of the payload when NOD persist dlls are specified.
2. Stub B stub uses alternate resource ids, and writes the payload to disk during
installation time. Stub B uses a payload file name specified in command line
option or if none specified will use stubname dll filename except with a
stubname{mgr}.extension.
3
SECRET//NOFORN

- 1
- 2
- 3
- 4
- 5