PR: #255

Enable tunnel data through agents, which would allow SOCKS proxying & reverse shell

There are a lot of spacing issues all over with our man page docs. I will try and go through and find them all but im noting this down to keep track of.

I have been working through training in the community edition and it looks like you cannot progress through the 'basic' module as the docs have been moved as part of the 1.7 release to doc.prelude.org

When deploying chains against schism-ftp that is connected to a redirector
[-] Instruction failed: 'utf-8' codec can't decode byte 0x8b in position 1: invalid start byte

Minor issue but in the interest of making this program even better, I wanted to highlight this:

I notice if you Update the name of the Agent inside Operator (Emulate-->Agent Settings (gear icon), the random generated name string persists in the console. (screenshot below)

Sliver plugin only support Session-based agents. Add beaconing agent support.

EDIT: I should note that restarting Operator did not fix it but rebooting the OS did.

I am walking through the training modules and successfully got the flag for Intro>Emulation>Import a New Procedure. I cloned the community git locally and added the 58282d96-4b91-49e8-adaf-eaa3db921b7a.yml file to the execution folder. Then I went to the editor to upload it and instead of uploading the individual file I opted to upload the folder. I got a pop up stating it was done but now when I click on the editor I get the following Unhandled Exception which I've attached a screenshot of

I am running Operator 0.9.13 on Ubuntu 20.04.1 LTS 64bit.

What do you think about adding a section for sigma rules? I always find myself cross referencing against other open source tools like sigma and Mitre.

Hello,

Do the file names need to be guids or can the filenames be human readable? I was thinking it might be easier for folks to find specific ttp's or w/e the individual files are called if they had distinct names.

https://github.com/preludeorg/community/blob/master/training/introduction/basic/326c369e-4672-48c1-9120-2fdd3a13d80d.yml

Currently, to my understanding, only a single payload is supported by TTP, even with multiple variants.

In many cases, just like why the variant feature is useful, there are many ways to achieve a goal with payloads that work differently.

Another example would be that a TTP would have 2 stages, like a dropper and the actual payload so when testing an EDR, we could test detection on one or the other depending on the WinAPI calls used.

It would be nice if TTPs could have support for multiple payloads.