not working in Excel 2016 32bit

[slavadba]

Hi,

I tried to used - and get error about format of cells - I take screenshots:

https://ibb.co/TBR5bP5 https://ibb.co/HNScKb1

then GoTo and contents of cell with error are

=FORMULA($FE$512;$A$1)

Command for generate - very basic:

Macrome.exe build --decoy-document decoy_document.xls --payload popcalc.bin --output-file-name CharSubroutine-Macro_calc32.xls

OS version and Excel - Windows 10, Excel 2016 32bit.

I do not know what else to add, except for what I can do PoC from the article https://outflank.nl/blog/2018/10/06/old-school-evil-excel-4-0-macros-xlm/ for calc32 or for Metasploit - on the same machine and Excel .

[michaelweber]

Any chance you can attach the generated XLS file here for me to take a look at? Normally I'd guess this meant there was a null byte inside the shellcode, but it sounds like you're using the default popcalc.bin file which SHOULD work fine. Famous last words of course.

[slavadba]

Sure, If you give me mail - I'll send file. Or you can download it from https://drive.google.com/drive/folders/1LqJnvAgTNNKI3alRCVATU_BCf9kGi41d?usp=sharing And yes - its default popcalc.bin . I dont think what problem with payload.

[chvancooten]

Facing the same issue - macro errors pop up when opening the generated .xls file, no matter which encoding method or payload I use. Test machine is running Microsoft Office Professional Plus 2016 on Windows 10 Enterprise.

[michaelweber]

Tested the file in Office 2010 and it worked so I'm guessing there's some weird office shenanigans going on here (what else is new?). I'm grabbing a version of 2016 to test against and will fix whatever is going on here. Thanks for the heads up folks!

[chvancooten]

I've had some successes getting at least the built-in calc payload to work when changing the Macro sheet to an International Macro sheet, suggesting it may be a regional issue (Western EU here). Didn't find the time yet to debug further, let me know if you need any help :)

[michaelweber]

This is almost definitely part of the problem. I just ran it in 2016 (and it had converted to US formatting somehow) and it wasn't a problem. If I had to guess, the way that the content is stored in the cells as a string is being interpreted as unicode differently and it's now trying to convert something to a nonexistent Unicode format.

[slavadba]

chvancooten - you did it use Macrome or some manual test? I don't really understand how XLM macroses can work on International Macro sheet - I think these different things at all.

michaelweber - did my file work as it should? can I somehow change settings for US formatting to reproduce your test? By default I use language "English (United States)"

[michaelweber]

@slavadba The file did work when I ran it - I'm guessing @chvancooten is correct. Looking for documentation on how I can change the region so I can replicate this bug on my end.

[michaelweber]

Alright, I was able to replicate the bug by installing Office 2016 with a default language besides English - (using Russian here for the moment).

[chvancooten]

@michaelweber Interesting, so it does definitely seem related. Out of curiosity - wouldn't converting the macro sheet to international solve this issue? Or would that introduce new issues?

@slavadba I took the payload from Macrome and pasted it to an international macro sheet rather than a regular macro sheet. It worked for me after doing so!

[michaelweber]

@chvancooten - International Macro Sheets are probably the answer - interestingly enough these aren't available if your region is set to the US. I changed the regional settings on my OS and suddenly this appeared...

My guess is that when you make an international sheet, it's possible to explicitly say what language the cells should be interpreted as.

[chvancooten]

@michaelweber - Huh, that's odd, I was under the impression that it was some sort of standard that followed a common pattern of list separators etc. Apparently not!

In that case - perhaps the problem would just be solved if you can somehow specify the sheet to be international during generation? Provided that doing so doesn't mess with the macro in US regions, that is :)

[michaelweber]

This is EXACTLY what I'm trying to figure out how to do right now. There's probably some undocumented flag to mark the sheet as international.

[michaelweber]

https://docs.microsoft.com/en-us/openspecs/office_standards/ms-offmacro/450634cb-ca5a-4350-9edb-940a90707f49 - it's even more silly:

An instance of this part type specifies the same information as a macrosheet part type (section 2.2.2.1). When this part type is present, the associated macro sheet will display and operate with the US English locale, regardless of what the product locale, user locale, or system locale is. This will maximize compatibility when running under various locales.

[slavadba]

it's genius )) i.e. International Macro Sheet always operates in US English locale ??

Any chances its will be added in project in the near future ?

And another question about obfuscated example of file (CharSubroutine was used) - how find cell from which execution started? I tried two variants of manual start on International Macro Sheet:

1 ) start execution from FE1 cell (its worked with sample without obfuscate) 2 ) start execution from FE845 cell

Both - ended with errors. File here https://drive.google.com/file/d/1n5PZPNgQgv3pK4ttspYEPt5xUwcABhlM/view?usp=sharing

[michaelweber]

https://docs.microsoft.com/en-us/openspecs/office_file_formats/ms-xls/d5860aa2-0331-4af9-8e4b-1d78be7056f5 - I just need to add this entry to the macro sheet, I can probably do it by updating the macro sheet template even. Will push something in a bit.

[michaelweber]

Alright, I updated Macrome to generate documents using the Intl record to help avoid some of these regional Excel version issues. Give it a try at https://github.com/michaelweber/Macrome/releases/tag/0.2.4 or pull down the latest version. If this looks like it's fixed then please let me know and I'll close the issue out.

[chvancooten]

It works flawlessly with the default shellcode for me! I'll play around with some custom shellcodes later and let you know :)

[michaelweber]

Fantastic! Glad we've got this thing up and running again - this will be a nice trick to handle if your target is running on a very different region too =). @slavadba - does this work on your machine now?

[slavadba]

everything works just like magic! thanks, this was the fastest fix in my requests on github!

Maybe there any plans to attach the detection of the sandbox? Probably, in this article gathred most of technics about it https://www.lastline.com/labsblog/evolution-of-excel-4-0-macro-weaponization/

[michaelweber]

So glad this fixed it for you!

Adding some sandbox evasion options to the default templates is definitely going to be a thing. That being said, I might suggest a variation on this "fun" statement from the ZLoader malware family that has been popular for the past few months:

IF(AND(OR(AND(MIN(APP.MAXIMIZE()),MAX(GET.WORKSPACE(13))>770,GET.WORKSPACE(14)>390,AND(GET.WORKSPACE(42),TRUE),OR(FALSE,GET.WORKSPACE(31)=FALSE),AND(GET.WORKSPACE(19)))),TRUE),SUM(3,4),HALT())

You can add this by creating a preamble file and using the --premble flag to prepend it to the normal shellcode loading. I know pentesters have also been using the preamble for gating their payloads to make sure they're on the right domain / machine before detonating which is also handy for sandbox evasion.

It sounds like we've successfully fixed this direct issue though, so I'm going to close it out. Thanks for the assistance with hunting this stuff down, I wouldn't have even realized this was a problem without the issue being opened and without @chvancooten realizing International Macro Sheets fixed this I wouldn't have been able to triage this so quickly. Cheers to both of you!