PDA

View Full Version : What does this command?

Shub-nigurrath
February 23rd, 2016, 08:14
Hi,
looking into some quite old malware I found commands such as

"dw20.exe -x -s 576"

given that what dw20.exe does, I cannot find anything about its command line parameters. Apparently the only programs using such switches are malware ..

"The Windows Error Reporting tool, Dw20.exe, collects information automatically whenever an Office program stops responding"

thanks
Kayaker
February 23rd, 2016, 18:41
Hmmm, I noticed in a few googled Virustotal scans that the same process creation + arguments were used with dwwin.exe, the XP version of the Dr. Watson debugger. Soo, I loaded up the file in IDA with MS symbols on one hand, and Ollydbg with those command line arguments on the other.

It was easy enough to find a named ParseFlags function:

Code:


.text:30005848 push eax  ; "-x -s 576"

.text:30005849 mov ?vdwExp@@3KA, edi ; 0

.text:3000584F call ?ParseFlags


It's simple enough to trace the function and see it specifically parse for "x", "s" and the number, but it's not really clear exactly what they do. Even with helpful symbols such as _MsoFSpaceWch@4 and _WGetCType1Wch.

If you run "dwwin.exe -x -s 576" from a command prompt it just exits, if you run it in a debugger it leads to an access violation in ntdll (Press f7/f8/f9 to pass exception to program). Interestingly, the exception occurs at standard PE parsing code:

Code:


7C9102D6 CMP WORD PTR DS:[ECX],5A4D

7C9102DB JNZ SHORT ntdll.7C9102FA

7C9102DD MOV EDX,DWORD PTR DS:[ECX+3C]


So, is it simply a debugger detection? The one thing I haven't tried yet is to set a JIT debugger (AeDebug) and see if the behaviour is any different. Seemed like something to try. Don't suppose you've got any malware code in how it's used?

K
blabberer
February 24th, 2016, 05:27
win7 dwwin also takes the parameters

3030

dwwin works with a manifest based crap some magic incantations about its sorcery can be gleaned from here
https://msdn.microsoft.com/en-us/library/bb219076%28v=office.12%29.aspx
google dw20 / dwwin command line options if ms link breaks
quoted from link
Quote:

Generic Reporting

Generic reporting is for errors other than crashes. Think about using generic reporting when something happens that you want to know about. It can be triggered by a line of code or by a user action.

With generic reporting, you are not constrained to use the eight parameters that define a crash bucket. You may specify up to ten parameters. Each parameter may contain up to 255 characters.

Generic reporting is supported in Manifest mode and Shared Memory mode. Use Shared Memory mode if you want Microsoft Error Reporting to snap a mini dump at the time of the event. In most cases, you are uploading data files other than a mini dump, and you use Manifest mode.

on the specific case of -x -s 576 it get the SharedmemHandle and tries to map it and fails with an INVALID_HANDLE c0000008 exception
0n576 = 0x240

Code:


Call stack of main thread

Stack     Data      Procedure                                                       Called from                      Frame

0006F97C  00EF4855  /dwwin.CExceptionReport::Report                                 dwwin.CWatsonClient::Run+125     0006F978

0006F980  00000240  |  Arg1 = 240

0006F984  0006FE64  \  Arg2 = 6FE64

0006FE34  00EF4951  /dwwin.CWatsonClient::Run                                       dwwin.wmain+70                   0006FE30

0006FE38  00161D9E  |  Arg1 = UNICODE ""C:\Windows\system32\dwwin.exe" -x -s 576"

0006FE3C  0006FE64  \  Arg2 = 6FE64

0006FE78  00EF3E18   dwwin.wmain                                                    dwwin.00EF3E13                   0006FE74

0006FEBC  75C93C45   ???                                                            kernel32.75C93C43                0006FEB8

0006FEC8  771C37F5   ???                                                            ntdll.771C37F3                   0006FEC4

0006FF08  771C37C8   ntdll.__RtlUserThreadStart                                     ntdll.771C37C3                   0006FF04


Log data, item 0
Address = 771A708F
Message = Exception C0000008 (INVALID_HANDLE) - Shift+Run/Step to pass exception to the program

it actualy tries to use MapViewofFile with the handle(576 _wtoI64() == 0x240) gets InvalidHandle there and fails when trying to CloseHandle the nonexistant handle

i think i need to Create A section and try to pass the handle to this dwwin and see what happens
Kayaker
February 24th, 2016, 21:57
You're right that the '-s number' indicates a mapped section. I found a useful reference by the guru of dump analysis that shows that "dwwin.exe -x -s " is the second parameter (lpCommandLine) of CreateProcess that is used during standard Windows fault reporting by faultrep!StartDWException:

https://books.google.ca/books?id=9w2x6NHljg4C&pg=PA114&lpg=PA114&dq="dwwin.exe+-x+-s"

Disassembling the XP version of faultrep!StartDWException we can track back how the command line is created:

Code:


stdcall StartDWException(struct _EXCEPTION_POINTERS *, unsigned __int32, unsigned __int32, const char *, unsigned __int32)

{

        hObject = CreateFileMappingA((HANDLE)0xFFFFFFFF, &EventAttributes, 4u, 0, 0x1C50u, 0);

        MapViewOfFile(hObject, 6u, 0, 0, 0);

        swprintf(lpCommandLine, (size_t)L"%ls\\dwwin.exe -x -s %lu", &CurrentDirectory, hObject);

        CreateProcessW(0, lpCommandLine,...)

}
Shub-nigurrath
February 25th, 2016, 04:20
Hi all,
I was stopped at the same level of the first post of Kayaker (due to time constraints only) and didn't further investigate.

So as far as I understand it is a trap mechanism for specific exceptions ? However, the malware is the attached one (password "infected", then rename to .exe .. it's a .net sample).

Beside opening dw20 with that parameters it also hooks it in the following way:

writes 32 bytes into "dw20.exe" (PID: 00002400)
writes 52 bytes into "dw20.exe" (PID: 00002400)
writes 4 bytes into "dw20.exe" (PID: 00002400)

interestingly also, but it's quite common, it suppresses some error messages via SetErrorMode(), using SEM_NOOPENFILEERRORBOX.


3031
blabberer
February 25th, 2016, 23:52
@kayaker
yeah the quoted approach from the dmitry's book sounds ok if the parent process is creating the child process
in that case the child can probably inherit the mapping handle as well
but how would it work for a non duplicated handle ? i mean passing 576 as a commandline and directly mapping 576 i think cannot be feasible at all
not sure how to emulate / simulate / the behavior

as to the sample it seems to be a standard bullshit creating a child process unmapping / get and set thread contexting and resuming thread that breaks free from the debugger


Code:


CPU Stack

Address   Value      ASCII Comments

0012EBAC  /00000000        ; |ApplicationName = NULL

0012EBB0  |00020660  `   ; |CommandLine = ""C:\Documents and Settings\admin\Desktop\_sample_net\_sample_net.exe""

0012EBB4  |00000000        ; |pProcessSecurity = NULL

0012EBB8  |00000000        ; |pThreadSecurity = NULL

0012EBBC  |00000000        ; |InheritHandles = FALSE

0012EBC0  |00000004       ; |CreationFlags = CREATE_SUSPENDED

0012EBC4  |00000000        ; |pEnvironment = NULL

0012EBC8  |00000000        ; |CurrentDirectory = NULL

0012EBCC  |0012F040  @ð   ; |pStartupInfo = 0012F040 -> STARTUPINFOW {Size=68., Reserved1=NULL, Desktop=NULL, Title=NULL, X=0, Y=0, Width=0, Height=0, XCountChars=0, YCountChars=0, FillAttribute=0, Flags=0, ShowWindow=SW_HIDE, Reserved2=0, Reserved3=NULL, hStdInput=NULL, hStdOutput=

0012EBD0  |0012F088  ˆð   ; \pProcessInformation = 0012F088 -> PROCESS_INFORMATION {hProcess=NULL, hThread=NULL, ProcessID=0 (0.), ThreadID=0}





CPU Stack

Address   Value      ASCII Comments

0012EBC0  /00000140  @    ; |hProcess = 00000140

0012EBC4  |00400000    @   ; |BaseAddress = _sample_net.<STRUCT IMAGE_DOS_HEADER>

0012EBC8  |00D30000    Ó   ; |Buffer = 00D30000

0012EBCC  |00000400       ; |Size = 1024.

0012EBD0  |00000000        ; \pBytesWritten = NULL





CPU Stack

Address   Value      ASCII Comments

0012EBBC  /00000140  @    ; |hProcess = 00000140

0012EBC0  |00401000   @   ; |BaseAddress = 401000

0012EBC4  |00D30400   Ó   ; |Buffer = 00D30400

0012EBC8  |00000A00   

    ; |Size = 2560.

0012EBCC  |00000000        ; \pBytesWritten = NULL





CPU Stack

Address   Value      ASCII Comments

0012EBCC  /00000144  D    ; |hThread = 00000144

0012EBD0  |0012F0A0  *ð   ; \pContext = 0012F0A0 -> CONTEXT {ContextFlags=CONTEXT_FULL, Dr0=7C927764, Dr1=7C927553, Dr2=150000, Dr3=40000060, Dr6=7C91003D, Dr7=12F2F8, Float_ControlWord=0, Float_StatusWord=0, Float_TagWord=79E74411, Float_ErrorOffset=87F3C019, Float_ErrorSelector=15


btw there is a payload security posting that probably analysed the same variant (i googled for a guid inside the sample.net.exe and google turns up three links outofwhich payload security appears to have some details exactly as shub posted


i dumped the decrypted ?? memory to a file and attached here didn't check what it is doing
password is infected