Visual Basic is quite popular amongst malware writers. It’s simple, it allows to hide the ‘juicy’ code under the layer of p-code, and is often used as a relatively cheap wrapper as many routines for loading PE files inline (RunPE) are easily available online for copy&paste. It is also not that well-documented despite many years of research on its internals. In today’s post I will describe one ‘feature’ of VB that makes it for a minor, yet still interesting (and potentially helpful in some cases) forensic artifact.
Let’s begin from the end. Have you ever seen any %TEMP%\~DF*.tmp files on the investigated system? The chances are – you did. These temporary files are created by OLEAUT32 library; this and other OLE2 components are essential to run many Windows applications and Visual Basic happens to rely on them a lot. When executed, the Visual Basic app loads the form that has an icon associated with it. It turns out, at some stage Visual basic calls an OleLoadPictureEx API function function that is responsible for manipulating the application’s icon… and, indirectly, is also creating these temporary OLE2 files in a form of:
- %TEMP%\~DF4BA7.tmp
- %TEMP%\~DFBBA3.tmp
- %TEMP%\~DFCBD8.tmp
- etc.
If you want to confirm it on your own, you can try the following:
- Clean the %TEMP% directory
- Load a sample Visual Basic Application into OllyDBg
- Make a breaakpoint on OleLoadPictureEx (Ctrl+G, then paste ‘OleLoadPictureEx’ there and hit Enter)
- Run until the breakpoint hits (F9)
- Check the %TEMP% directory – still nothing there
- Now Execute till return (CTRL+F9)
- Check %TEMP% directory again
- There you have it… see below, before (breakpoint on OleLoadPictureEx hits) and after (after the function completes the execution).
The temporary files are deleted after the program terminates, but sometimes they can be forensically recovered, or simply still present in the folder if e.g. malware or system crashed.
The structure of the file is OLE2 compound and storage file and can be previewed with OffVis – The Microsoft Office Visualisation Tool (Link is a direct download):
The actual content usually starts at offset 0x600 if it is a non-icon (i.e. a file in an .ico format), and 0x800 if it is an icon; I don’t know the reason why the difference – I assume that for .ico files the area between 0x600-0x7FF contains some internal data used for handling .ico files (if you know what’s there, please let me know).
The screenshot above highlights the beginning of the icon (00 00 01 00); One can easily extract it and view it using any image viewer, even Windows Explorer itself. In our case, it’s:
Not surprisingly, the very same icon can be found inside the resources of the executable:
The conclusion?
If you come across %TEMP%\~DF*.tmp file(s), you can attempt to:
- View their content
- If it contains an .ico resource, it could be a trace of Visual Basic application running on the system
- In such case you can extract the icon and recognize if it’s sth dodgy e.g. one of the infamous fake Acrobat Reader, Microsoft Word, etc. icons used by malware all over the place and if you are lucky and it stands out, use the file timestamps in your analysis, especially if main executable is no longer on the system; in a way, it’s a weak way of confirming some VB app was possibly executed on the system
Word of caution:
- It’s OleLoadPictureEx that creates the file, not Visual Basic alone – the function is used widely by non Visual Basic applications as well and it’s common to find the content of the ~DF*.tmp files to contain e.g. PNG files; ~DT files should be seen as containers storing the stream of data related to some graphics. If these are .ico files, then high chances of it begin associated with some Visual Basic application, if not, it may still be useful as it may contain traces of pictures processed on a computer using an application that happens to rely on OleLoadPictureEx to manipulate the graphics.