question-mark
Stuck on an issue?

Lightrun Answers was designed to reduce the constant googling that comes with debugging 3rd party libraries. It collects links to all the places you might be looking at while hunting down a tough bug.

And, if you’re still stuck at the end, we’re happy to hop on a call to see how we can help out.

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:closed
  • Created 3 years ago
  • Comments:11 (6 by maintainers)

github_iconTop GitHub Comments

1reaction
CodeXTF2commented, Sep 2, 2020

oh nice il have a look thanks!

1reaction
calebstewartcommented, Jul 6, 2020

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).

Read more comments on GitHub >

github_iconTop Results From Across the Web

Creating modules - Puppet
From the command line, run the new module command, specifying the name of the module: pdk new module <MODULE_NAME> · Respond to the...
Read more >
Add new module sub-command — Modules documentation
This document is a guide for Modules developers that wish to introduce a new sub-command for the module command. Core code¶. Introducing new...
Read more >
Command Authoring - Drush docs
Creating a new Drush command or porting a legacy command is easy. Follow the steps below. Run drush generate drush-command-file . Drush will...
Read more >
Need to be able to search module based on command alias · Issue ...
Find-Command from PowerShellGet depends on PowerShellGallery search capability to find modules based on commands, but PowerShellGallery doesn't support ...
Read more >
How to dynamically load module based on command line ...
I'm still fairly new to python and I know I'm probably not setting up my modules correctly, but I'm not sure why.
Read more >

github_iconTop Related Medium Post

No results found

github_iconTop Related StackOverflow Question

No results found

github_iconTroubleshoot Live Code

Lightrun enables developers to add logs, metrics and snapshots to live code - no restarts or redeploys required.
Start Free

github_iconTop Related Reddit Thread

No results found

github_iconTop Related Hackernoon Post

No results found

github_iconTop Related Tweet

No results found

github_iconTop Related Dev.to Post

No results found

github_iconTop Related Hashnode Post

No results found