Vault7: CIA Hacking Tools Revealed
Navigation: » Latest version
Owner: User #71494
Caterpillar ICE Command-Line Parser Notes, Plans, Etc.
Task Description
The ICEIn-memory Code Execution spec outlines the ability to pass command line arguments into the tool being kicked off by ICE. Caterpillar uses a config file burned in at deployment time via Builderpillar.py. The Operators would like the ability to use the command line arguments specified in the Builderpillar documentation to override portions of the burned-in configuration.
Specific conditions and constraints
- Persistence of config edits is not necessary.
- I can expect there to be a command line arguments whenever edits need to be made.
- Operators should be able to modify everything, except the baked-in RC4 key.
Commands That Need to Be Implemented:
- chunksize
- collect
- id
- ip
- kill
- mtu
- max
- port
- rate
- redundancy
- state
New Commands To Be Created:
- uncollect - give the operators the opportunity to remove a GLOB specified in the config from collection
Questions:
- The RTPTrasmitterConfig object appears to support multiple destinations (destination being an object to itself consisting of an ip, port, amd max bytes to send there). Builderpillar does not appear to support multiple destinations. Which should my command line arguments support? Should we consider full support of multiple destinations in the future? I haven't gone digging to see if the rest of Caterpillar supports multiple destinations, its just that the transmitter config having a vector for destination objects seems to suggest the functionality exits, but it could just be future proofing.
Implementation Plans:
NOTE: These will turn green as I work them off.
-
Get the command line options in the ICEIn-memory Code Execution arguments struct from ICE_Entry() down into the thread running caterpillar_main()
- Probably done. Simple fix, but I don't know how to try things out in RICE yet, so I'll bug User #75380 or someone to walk me through it on Monday.
- Parse out the command line arguments from the args->cmdline stuct member
- Need to store the command strings obfuscated in some way to not bake a bunch of exfil-related literals into Caterpillar. User #75380 mentioned "obfustring" earlier.
- patch the burned in config after it is recovered from the resource by get_config_data()
- Allow Caterpillar to execute normally thereafter.