MythicAgents / poseidon

Poseidon is a Golang agent targeting Linux and macOS
Other
118 stars 32 forks source link

Windows compatability #22

Closed scottctaylor12 closed 1 year ago

scottctaylor12 commented 2 years ago

There were lots of small changes that needed to happen to make poseidon work with Windows. Here's the summary:

Major Changes:

Minor changes:

For the most part, I had to go in various command packages and add a _windows.go file with the //+build windows header and include a return error of "Not Implemented/Compatible". These cases are found in:

Some commands build, but do not work for windows. For these situations, I went into the agent_function/.py file and disabled them for windows by adding:

attributes = CommandAttributes(
    supported_os=[SupportedOS.MacOS, SupportedOS.Linux]
)

This change can be found in:

Notable Testing Success:

scottctaylor12 commented 2 years ago

Also, socks proxying worked while testing from a windows agent :fire:

scottctaylor12 commented 2 years ago

@its-a-feature PR is up-to-date with latest MythicAgents:dev branch changes and ready for review!

I noticed one thing about your upstream change. The way you handle the compiler flags might cause a bug within the poseidon container. The compiler flags are set using export to environment variables which is fine. However, those environment variables will still be set when the next payload is being built.

Problem scenario: darwin payload exports CC=o64-clang; and CXX=o64-clang++ when being built. When the Linux payload gets built, those environment variables might still be set and mess up the build.

https://github.com/MythicAgents/poseidon/blob/f5e9c0a74d0bc528495a47c91f362ddf01cb48d1/Payload_Type/poseidon/mythic/agent_functions/builder.py#L97-L100

Solution: Instead of exporting the compiler flags, add them before the garble/go command like: CC=mingw go build ..... rather than export CC=mingw; go build ...

its-a-feature commented 2 years ago

How's this effort going? Is it to the point where you want me to review it or are you still looking to add major command functionality?

scottctaylor12 commented 1 year ago

Apologies for the long delay @its-a-feature! I fixed up my execute-assembly command to use direct syscalls and run in-process rather than fork & run. Whenever you have the time, could you review my PR please?

scottctaylor12 commented 1 year ago

With the v3.0.0 release, how would you like me to handle this PR? I see there's a v3.0.0 branch, off of master, but I'm trying to merge into the dev branch.

its-a-feature commented 1 year ago

Great question! If possible, it'd be nice to target the v3.0.0 release. If it's a big lift though, we can always keep going with the other branch for now (easier testing for you) and then once v3.0.0 goes live, we can port it over - the biggest change is that the v3.0.0 version is golang instead of python.

scottctaylor12 commented 1 year ago

Not a problem! I'll close this out and start a new PR with the v3.0.0😀 I like the idea of starting a fresh PR since this has been sitting a bit

its-a-feature commented 1 year ago

You closed this one, does that mean the new one updated for v3.0.0 is coming soon? :)

scottctaylor12 commented 1 year ago

Actually I was just about to message you in Slack about it! Should I contribute to dev, v3.0.0, or yolo to main haha

its-a-feature commented 1 year ago

Right now only v3.0.0 is actually updated for V3, so open PRs against that one for now so i can test with all the updates

scottctaylor12 commented 1 year ago

Sounds good to me 😁