New Module-based Commands

@CodeXTF2 mentioned adding some new commands over at #21. I think continuing the discussion on top of that issue isn’t a good idea, so I figured I’d create a new one. If you just want to discuss for now for your own fiddling, that’s fine, but also I’d welcome some fresh ideas that may be able to be merged into master at some point 👍

The module-based commands are implemented in two different pieces. In general, there’s a back-end API, which does the real work. This is normally implemented as a package with a “main” class that is added to the Victim object. That way any part of pwncat can interact with it programmatically if needed (think privesc utilizing enumeration modules). Then, a command is created (usually with the same name) for interacting with it. So, there’s a privesc python module that has a Finder class. An instance of that class is available as pwncat.victim.privesc. And there’s a privesc command under the pwncat.commands package which simply provides a UI to the privesc module.

Practically speaking, you can implement it however you want. I like the back-end/front-end separation because it allows different parts of pwncat to seamlessly work together. For example, the privesc modules can request enumeration information from the pwncat.victim.enumerate, and utilize pwncat.victim.persist to fix some partial privesc situations automatically. All that happens seamlessly without having to hard-code specific methods or account for edge cases all over the place because of the abstractions.

You can take a look at the way the persistence and privesc packages are implemented to get an idea. They utilize pkgutils to dynamically load python modules/classes. The base classes are created and added to the Victim class in victim.py.

You mention a couple examples. Spawning another shell I would imagine would go under “persistence” anyway. I had planned to add some bind/reverse shell persistence methods eventually, but hadn’t gotten to it. The log stuff could go under it’s own module. I feel like it may be able to be integrated into tamper somehow because it feels logically connected there.

I had tried not to go down the road of a generic “run” command with all the modules underneath it (like Meterpreter used to use) because I think that gets unwieldy quickly with a bunch of modules underneath one interface. Grouping things into related base commands makes sense in my head, and allows them to be represented by objects in Python which makes automation easier. However, I’m open to discussion about a different structure. It’s not set in stone.

[CodeXTF2]

oh nice il have a look thanks!

[calebstewart]

So, tampers aren’t implemented in the same way. The only functionality for those from the prompt is to revert them. They are created programmatically as pwncat does different things (e.g. using pwncat.victim.tempfile will automatically register a tamper for a created file). I agree the name fits for what you are talking about, but practically it’s used for something else at the moment.

We had imagined some more categories of commands. In #2 we talked about it a little. Things like “meme” for something that would just mess with other users on the box (just useful for CTF-stuff). Also, things like “aggression” which would either destroy or change things on the machine. We had mentioned a “stealth” section which would be the stuff like you mentioned where you are clearing log files and things. I think for very specific stuff like KoTH or for a specific CTF, it would just be a custom command. I can probably look at making the “help” output organized better so that adding more commands doesn’t hinder runtime usage information.

As I’m typing this, I realize the logical thing would be to group the commands based on the MITRE ATT&CK framework, I think. Does that sound reasonable? We already have persist and privesc which line up nicely. I think enum is basically “Collection” and could be theoretically renamed to collect to line up. We could have separate commands like:

• evade - Defense Evasion
• creds - Credential Access
• discover - Discovery
• lateral - Lateral Movement
• exfil - Exfiltration
• impact - Impact

I think most of what you mentioned fits in there. Some of the one-off things might be grouped into custom commands (like koth-specific or ctf-specific actions).