not working in Excel 2016 32bit about macrome HOT 21 CLOSED

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.

from macrome.

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.

from macrome.

@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.

from macrome.

@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 :)

from macrome.

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.

from macrome.

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

from macrome.

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.

from macrome.

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

from macrome.

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/

from macrome.

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!

from macrome.

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.

from macrome.

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!

from macrome.

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 :)

from macrome.

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.

from macrome.

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)"

from macrome.

@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.

from macrome.

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

from macrome.

@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!

from macrome.

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.

from macrome.

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.

from macrome.

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?

from macrome.