search

its-a-feature / Mythic

A collaborative, multi-platform, red teaming framework
Other
3.22k stars 430 forks source link

Execute_Assembly Timeout | Inject_Assembly Error #67

Closed HanseSecure closed 2 years ago

HanseSecure commented 3 years ago

Hey Ho,

iam trying to load different assemblies, for example Rubeus.exe but i cant execute these.

grafik

And injecting does also throwing an error, which makes no sense to me :-)

grafik

Any Ideas ?

Regards Flo

its-a-feature commented 3 years ago

This is for the Apollo agent right? @djhohnstein

HanseSecure commented 3 years ago

oh yes, sorry :-)

HanseSecure commented 3 years ago

We can close this issue here and i can move it to https://github.com/MythicAgents/Apollo/issues ?

its-a-feature commented 3 years ago

I'm not sure about that first Error, but for the second one with assembly_inject, it appears as though Apollo currently only supports that command to be freeform text (https://github.com/MythicAgents/Apollo/blob/master/Payload_Type/Apollo/mythic/agent_functions/assembly_inject.py#L20) so, "assembly_inject [pid] [x64|x86] [assembly] [args]"

HanseSecure commented 3 years ago

Okay the textform ends also in my timeout issue :-( But thanks for the freeform info!

grafik

djhohnstein commented 3 years ago

I don't speak German, but I'm almost positive that's an error on trying to connect to the named pipe. Usually means something bad happened when trying to launch the shellcode in the remote process (e.g., it allocated, it wrote shellcode, it tried to start the shellcode, and waited to connect to the named pipe, but it never started). It might be a permissions issue, a target process issue, or an EDR issue preventing you from injecting the payload.

HanseSecure commented 3 years ago

@djhohnstein the error message is just a standard timeout.

Can you check this function in a current test enviroment? i tried a lot of different setups xD

djhohnstein commented 3 years ago

Now that I think about it, I'm pretty sure there's an outstanding bug we're looking to track down where execute-assembly doesn't play nice with certain spawn-to processes, and that might be at play. Just to confirm, you experience it for both execute_assembly and the assembly_inject correct?

HanseSecure commented 3 years ago

thats correct

djhohnstein commented 3 years ago

I tested this in my lab setup using:

I was able to register, execute, and inject the assembly as expected (I injected into msedge specifically). Running getprivs, I didn't have anything special enabled either:

Enabled 5 privileges for DESKTOP-DJLLEVA\windev:

SeChangeNotifyPrivilege
SeIncreaseWorkingSetPrivilege
SeShutdownPrivilege
SeTimeZonePrivilege
SeUndockPrivilege
HanseSecure commented 3 years ago

At first very thank you for your time!

Do I need elevated privileges to execute (not injexct) an assembly?

I will test it in my lab and will let you know.

djhohnstein commented 3 years ago

I wouldn't think you'd need specific privileges since you're spawning the child process successfully. Is .NET 4.0 installed on the machine you're attempting to run these commands on? Looking through the code, it looks like I made it run on .NET 4 instead of 2, which might be the root cause.

HanseSecure commented 3 years ago

Okay, even with an privileged account i cant execute assemblies on several systems (including systems with .NET 4.0)

grafik

grafik

:-(

djhohnstein commented 3 years ago

:-(

I'll brainstorm a system collection tool to brainstorm why it might be failing. Sorry this has been so troublesome!

HanseSecure commented 3 years ago

Hey no worries, iam super happy with your tool. Can i help with any further information?

djhohnstein commented 3 years ago

Not at the moment, but I'll keep you in the loop.

HanseSecure commented 3 years ago

Any Updates regarding my issue? Can i help you with additional logs ? Maybe its something regarding the language/ german keyboard layout? Yesterday i got serious issues with sharpRDP because of the german keyboard (but there is already a ticket: https://github.com/0xthirteen/SharpRDP/issues/5).

just an idea ;-)

PS: With covenant's assembly function are no issue atm

djhohnstein commented 2 years ago

Hey there, sorry it took so long to reply. I lost track of it in the ensuing months. During that time though I've rewritten every aspect of Apollo from the ground up. There is very little shared code between the old project and the new. I'll detail the changes further but the TLDR is that I'd ask you to try again using Mythic v2.3 and the "refactor" branch of Apollo. Attached is screenshots of Rubeus executing both in-process and in the sacrificial process.

image image

Longer Explanation as to the Changes

In Apollo 1.X, execute-assembly is its own separate .NET project. That .NET project is wrapped in a custom CLR loader, and that CLR loader is then converted via sRDI. So at each point in this chain there is an opportunity for something to go wrong (namely, either sRDI failed to load, or the CLR loader failed to initialize the CLR, or the assembly crashed for an unknown reason).

In Apollo 2.X, the execute-assembly project is still separate, but is delivered via Donut's shellcode generation techniques. Moreover, it's now purely architecture agnostic, which could solve some issues.

I do ask that if you install Mythic 2.3, and use the refactor branch of Apollo, but are still having issues, to reopen this ticket on https://github.com/MythicAgents/Apollo and I'll take another pass at it.

its-a-feature commented 2 years ago

I believe this is fixed in Apollo 2.0 for Mythic 2.3

HanseSecure commented 2 years ago

will try this as soon as possible. unfortunately was the Version 2.3 last week not running (http c2 profile didnt start and i wasnt able to start it). Will try it again in this week and will let you know cody.

Anyway very thank you for your contribution to our small infosec family!

HanseSecure commented 2 years ago

It still doenst work :(

grafik

even with your command (and the shell is also gone :-(

grafik

its-a-feature commented 2 years ago

@djhohnstein

its-a-feature commented 2 years ago

hm... ok, to help track this down can you provide/try a few things:

Just trying to come up with various things that might be contributing to it so we can reproduce it on our end and get a fix

HanseSecure commented 2 years ago

Hey Cody,

i will provide you further information in the evening.

djhohnstein commented 2 years ago

Yeah, for us to reproduce can you:

  1. Give the exact build of Window's you're using by clicking the Windows icon in the callback pane
  2. Tell us what language pack(s) are installed on the machine

Then, in terms of other troubleshooting things, can I ask you to try and use https://github.com/TheWover/donut on the Rubeus assembly you've compiled to see if it'll execute? There might be a problem with the shellcode generation routine.

djhohnstein commented 2 years ago

@HanseSecure I think we have a fix. Can you install the language_localization branch of Apollo on your Mythic server via:

./mythic-cli install github https://github.com/MythicAgents/Apollo language_localization -f

Then rebuild your payload and try again? TLDR; I was setting pipe security descriptors based on English group names instead of their SIDs, causing the application to crash.

HanseSecure commented 2 years ago

now its working !

grafik

Very thank you guys :-)

djhohnstein commented 2 years ago

Woo! I'm really sorry this took so long to get fixed. I don't know what the issue is with inline_assembly that you posted, but hopefully this gets you where you need to go 😄

HanseSecure commented 2 years ago

Dont know why iam the only german who is reporting this xD

Anyway very thank you Dwight & Cody!