New Module-based Commands
See original GitHub issue@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.
Issue Analytics
- State:
- Created 3 years ago
- Comments:11 (6 by maintainers)
Top GitHub Comments
oh nice il have a look thanks!
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
andprivesc
which line up nicely. I thinkenum
is basically “Collection” and could be theoretically renamed tocollect
to line up. We could have separate commands like:evade
- Defense Evasioncreds
- Credential Accessdiscover
- Discoverylateral
- Lateral Movementexfil
- Exfiltrationimpact
- ImpactI 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).