# Vault 7: Projects

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

### Pandemic

# Pandemic 1.1 (S/NF)

16 January, 2015

- 1
- 2
…
- 6
- 7
- 8
- 9

SECRET//NOFORN
and Pandemic can't tell if it's a normal SMB operation or a weird VMWare
operation.
• (S//NF) If a target user is running the replaced PE on their system through SMB
(direct execution without copying it down to their machine), and Pandemic is
uninstalled, this can cause process instability for the replacement PE. The
instability may not appear if the entire replacement PE is cached on the target
user's machine. Instability may not happen immediately if it does occur.
• (S//NF) If the replacement PE file has a different icon than the target PE file, the
remote users may not see the correct icon all the time. The local Windows
machine tends to cache icons, and this icon caching can persist for some time (or
until reboot). The best work around is to ensure that if the target PE file has icon
information, the replacement PE file should then share that same icon
information.
• (S//NF) There will be some memory leakage as a result of making 'safe' choices
vs. potentially destabilizing choices. Typical memory leakage size will be around
1 KB per run of Pandemic (of NonPagedPool). According to various sources,
Vista+ 64-bit systems cap NonPagedPool to 75% of RAM. So on a server with
64 GB of RAM, NonPagedPool is limited to 48 GB.
◦ To limit leakage, run Pandemic with long death-timers. Avoid running
Pandemic many times using short death-timers. If this becomes an issue
(target server doesn't reboot often, operation requires many runs of Pandemic
on a short leash) then the developer can investigate ways of reducing the
memory impact
• (S//NF) Two different remote users that share the same machine (does not apply
to VMs on the same machine), but log into the Pandemic machine using different
user accounts (different SIDs) could cause targeting issues. If user account A on
the remote machine is targeted, but user account B on the same machine is not,
then the following issue can occur:
◦ User A is running WinHex.exe, the targeted application, directly from the
Pandemic File Server (PFS). User A really is running a Trojan'd copy of
WinHex.exe. User B logs into the PFS and also directly executes
WinHex.exe. User B, while not targeted, will still receive the Trojan'd
WinHex.exe. This is because the machine that User A and User B share is
caching the file.
◦ The following scenarios will not//not trigger the issue:
◦ User A is running WinHex.exe, the targeted application, directly from the
Pandemic File Server (PFS). User A really is running a Trojan'd copy of
WinHex.exe. User A is running off a VM on the remote machine. User B
then gets on the remote machine and logs into the PFS using a separate VM,
or the machine itself. User B will get the correct version of WinHex.exe
◦ User A and User B are on different remote systems
◦ User A is running the Trojan'd WinHex.exe. User B then gets on the same
machine, and downloads WinHex.exe from the PFS to the local machine
before executing the local copy. User B will get the correct copy of
WinHex.exe.
SECRET//NOFORN
8

- 1
- 2
…
- 6
- 7
- 8
- 9