Weird DLL behavior

Posted on by

I was toying around with the static DLL loading and came across a very strange behavior.

So… I created a small .exe file that depends on dll1.dll and dll2.dll, linked statically, and calls function1 and function2 from each DLL respectively.

...
Start:
 invoke function1 ; from dll1.dll
 invoke function2 ; from dll2.dll
 invoke ExitProcess,0

When loaded (and when the respective function is called) the DLLs create one of the following files:

  • DLL1.DLL
    • c:\test\dll1_attached – DLL is loaded (attached)
    • c:\test\dll1_detached – DLL is unloaded (detached)
    • c:\test\dll1_function – ‘function’ is called
  • DLL2.DLL
    • c:\test\dll2_attached – DLL is loaded (attached)
    • c:\test\dll2_detached – DLL is unloaded (detached)
    • c:\test\dll2_function – ‘function’ is called

I then modified the section attributes for dll2.dll so that its .text section doesn’t have code execution rights.

 Name: .text
 VirtualSize: 0x00000070
 VirtualAddress: 0x00001000
 SizeOfRawData: 0x00000200
 PointerToRawData: 0x00000400
 PointerToRelocations: 0x00000000
 PointerToLinenumbers: 0x00000000
 NumberOfRelocations: 0x0000
 NumberOfLinenumbers: 0x0000
 Characteristics: 0x00000000 <---- no flags

The dll1.dll .text section looks like this:

 Name: .text
 VirtualSize: 0x00000070
 VirtualAddress: 0x00001000
 SizeOfRawData: 0x00000200
 PointerToRawData: 0x00000400
 PointerToRelocations: 0x00000000
 PointerToLinenumbers: 0x00000000
 NumberOfRelocations: 0x0000
 NumberOfLinenumbers: 0x0000
 Characteristics: 0x60000020 <---- (CODE, EXECUTE, READ)

I then tested this file set on on Win 10 x64. After dropping the files into VM I ran the test.exe.

The first run shows the expected behaviour – i.e. the application crashes:

There is an event logged in the Event Logs as well:

To my surprise, when I re-run the test.exe it… actually works:

Running it again and again I am getting inconsistent results. I drop the files into a win10 VM and sometimes it crashes with the first run, same as described above. And sometimes it runs smoothly.

For the same set of files tested on Win7 x64 – I get the ‘dll1_attached’ created, but then the test.exe crashes.

When dropped into XP VM, it works w/o any issues (files are created).

When I manipulate .text section attributes for dll1.dll the application always crashes. So, it would seem that the section of the first DLL cannot be modified, but the second one can.

I am now scratching my head… Looks like a potential DLL mapping bug?

The memory layout looks like this:

Ideas?

You can grab the files here.

PsExec going places…

Posted on by

Update 2018-07-19

Today I came across an old post from @mbromileyDFIR who wrote about it in 2016 so adding link as it’s a good article explaining forensic artifacts associated with running psexec

Old Post

As a threat hunter you surely know that PSEXESVC.EXE is one of these nice signature-friendly artifacts that you will want to catch with your process/service creation rules. It’s one of the easiest way to spot the lateral movement.

Unfortunately, there is a catch.

You see, for a number of years now the psexec has that nice command line argument ‘-r’ that allows you to create a service name as per your liking; this affects the artifacts it creates on the remote system.

You can test it by running the following command:

PsExec.exe -r foobar \\localhost cmd.exe

The tool will drop c:\WINDOWS\foobar.exe and will start the service called ‘foobar’:

The flag will cause the named pipes used by Psexec (-stdin, -stdout and -stderr) to be renamed as well (I forgot to mention it in the original post, thx to @spinning_monkey for reminding me).

I guess the original idea behind the introduction of this flag was to allow multiple psexec versions (or instances) to co-exist on the remote system, but the side-effect is that you can’t detect psexec being present by relying on just a service / file name only.