Vault 7: Projects

This publication series is about specific projects related to the Vault 7 main publication.
2. Application layer impl:
Pros
- Could be as simple as mission cmd exec support. e.g. exec netcat –args
-simple impl. leads to control of alternative tools that may be available on some FTs
Cons
- not as reliable and as good of performance as NAT translation (marginal considering use
cases)
• may be easier to provide an application layer impl on some devices
• even application layer impl. still requires firewall rule checking/override
• Note: we must override existing firewall config specified by a user on the FT-- which means
that we'd have to either modify IP tables periodically or place our hooks in before iptables can
filter out/drop the packets.
E) Support to forward to FT LAN IP or localhost
1. Required
2. If it works for a FT without effort, great.
3. No support to forward to FT LAN IP or FT localhost
Assumptions:
• no validation or security on pinhole
i.e. a packet from ANY IP would be forwarded through the firewall (option A-1)
or
the 'right' IP (option A-2)
• must be able to configure a FT's firewall to open up the hole without interfering with the FT's
normal firewall configuration.
Reverse Pinhole
Note: We already have a form of reverse pinhole, but is for all outbound traffic for a specific IP. I
don't think that it will be difficult to perform a NAT translation from a outbound destination IP, that
corresponds to one of the following options, to a translated outside IP and port. Where the destination
IP is:
1. the FT's LAN IP
or
2. an arbitrary IP/network mask
or
3. a domain, (requires looking into DNS requests).