You are browsing the archive for Random ideas.

Playing with Delay-Loaded DLLs…

June 3, 2019 in Anti-Forensics, Random ideas

Delay-Loaded DLLs is PE file feature that is almost obsolete. Programmers who wanted to benefit from this mechanism in the past would write a program and use Windows API same as usual. During the linking process though they would enforce some DLLs and their imports to be resolved some time later after the actual program start. This was to speed up the loading of the program and use less memory. In practice, it’s just a convenient mechanism that resolves APIs dynamically ‘just-in-time’ so that programmers can use API calls transparently & don’t need to write their own wrappers (or use LoadLibrary/GetProcAddress directly).

We can take the advantage of this mechanism to implement a simple beacon by adding a DLL name to delayed import table, and then using hex editor (or a quick script) to replace the name of this DLL to a UNC path in a same way as the PDB example:

Once program is executed, and the function that is resolved dynamically is encountered, the program’s library function will attempt to load that particular DLL (i.e. in our case it will try to resolve the UNC path and as such will ping the destination address). The DLL could be of course present on that remote site, or the the dynamic loader could be executed within an exception handler wrapper so that the program can continue…

Interestingly, Dependency Walker shows the UNC path when the program is told to view the imports used by the test exe file. It doesn’t stop it though from trying to load the delayed DLL from that UNC path. And because of that, the ping can be made w/o execution of the main sample!

This is again should act as a warning against testing samples on systems that are online. Even static analysis could sometimes be harmful, especially if you use tools that blindly trust the input, or even worse, utilize LoadLibrary to load the DLLs that programs are linked to.

Playing with section names…

June 2, 2019 in PESectionExtractor, Random ideas

This post breaks my old tool PESectionExtractor.pl.

Any part of the .exe structure can be controlled by an attacker. This includes imported DLL names, imported function names, PDB paths, as well as section names.

My tool extracts PE sections by walking through them one by one and then dumps them to a file that is named according to the following scheme:

  • filename_sectionname_fileoffset_filesize_sectionflags

It works all and nice for your typical scenario, but fails miserably when a section name includes a colon e.g. .text:xy.

As you may guess the file name written by will be saved as an ADS e.g:

C:\test\test.exe_.text:xy_00000400_00001200_XR_CODE.dat

So, if you extract sections from PE files in an automatic way and use section name extracted from the file to build an output file name you may need to ensure colons are replaced with something else.

Fixed tool here.