Excel loader not working about scarecrow HOT 10 CLOSED

Sorry I am a bit confused. The Excel loader doesn’t create a binary. Are you referring to the xll loader is not working or that get a pop up message that prevents execution?

from scarecrow.

Sorry for the confusion.

I used ScareCrow like:

./ScareCrow -I msf.bin -Loader excel -domain google.com -O abc.js

On the target where Excel is installed, I executed the abc.js file like:

cscript abc.js

This opens Excel with a dialogue saying the extension is unsafe and if I want to continue. When I click yes, Excel tries to load an xll file from

C:\Users\%USERNAME%\AppData\Local\Temp

At this stage, the initial shellcode I wanted to execute did not execute.
So I tried to copy the xll file (created by abc.js in AppData\Local\Temp) and to execute this specific xll file somehow different via the described techniques in:

https://gist.github.com/ryhanson/227229866af52e2d963cf941af135a52

But none of the techniques were successful at executing the xll created by abc.js.

The payloads used to generate shellcode were all stageless.
So, I assume the xll file creation of ScareCrow is not working properly?
Or maybe I miss something here?

from scarecrow.

What version of golang are you using?

from scarecrow.

I've tested with office 365, can you provide an image of the error message?

from scarecrow.

Sure, sorry for the long response time.

The Linux I used ScareCrow on:

Linux kali 5.10.0-kali3-amd64 #1 SMP Debian 5.10.13-1kali1 (2021-02-08) x86_64 GNU/Linux

Used golang version:

go version go1.15.8 linux/amd64

I have tested on an Office ISO installation (licensed) but no O365:

Office Professional Plus 2019
Version 2102

Screenshot of the error message after executing abc.js via cscript:

After clicking "yes" on the above error, Excel opens like this:

It is notable that the xll got created under temp:

After copying the created xll from temp to Desktop and trying to execute it via Powershell, it won't work either:

from scarecrow.

I am unable to recreate this issue unless this is something to office 2019. I am in the process of getting a copy to test on to rule it out. However, If the above PowerShell leads me to believe that your DLL/XLL actually has the issue in it. Given the corrupt message from Excel, I wonder if it has to do with your bind shell? Have you tried a reverse shell?

from scarecrow.

Is the default person of office running as a 64-bit process or 32-bit process?

from scarecrow.

That is a good question..

Any idea how I can find that out in my VM I am testing this on?

from scarecrow.

You were perfectly right!!
Looked at my Excel install at the about section.
I run a 32-bit Excel in my VM and I have not noticed it/knew about it.

Thought Excel would be 64-bit by default.

Thank you very much for your great support on this topic and the tool and excuse this time taker.
Feel free to close this one.

from scarecrow.

No problem, I am glad I was able to figure this out. I know that Office 365 version comes default as 64-bit other versions such as Office Professional Plus 2019 I believe have the ability to install 64-bit but the default is 32-bit. Take care.

from scarecrow.