Closed 0xShkk closed 3 years ago
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?
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?
What version of golang are you using?
I've tested with office 365, can you provide an image of the error message?
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:
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?
Is the default person of office running as a 64-bit process or 32-bit process?
That is a good question..
Any idea how I can find that out in my VM I am testing this on?
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.
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.
Hi again,
as I played around with this great tool a little more, I found I could not get the Excel loader module to work. I tried to create shellcode in two ways:
Both worked flawlessly with other loaders (except the binary one).
When I create the payload via Excel loader module, I try to execute it via cscript as I saw a JavaScript file gets created. Excel spawns with a unsafe file extension message but does not execute the resulting xll.
I saw the xll got created in AppData\temp so I copied it before closing Excel and tried to execute the DLL manually by the methods described in this gist:
https://gist.github.com/ryhanson/227229866af52e2d963cf941af135a52
Unfortunately none of them worked.
Windows version here is
Excel version is:
No AVs are installed and Defender is turned off completely for testing here.