The desktop.ini is a standard text file that can be placed in any Windows folder to customize certain aspects of the folders behaviour, i.e. what the folder icon should be, what folder name to display, etc. The desktop.ini file is normally a hidden file so to display existing ones in folders you’ll need to make it visible by opening the folder and clicking on the Tools menu . . . Folder Options and selecting View. Then select “Show hidden files and folders” radio button and also uncheck “Hide protected operating system files (Recommended)”. Below I have touched upon three customised folders and the ini files it contains.
For Favourites folder the folder has to have attributes of either readonly or system or both for the folder to change to “favourites” from the actual folder displayed in Explorer. The desktop.ini file can have any attribute and below is an example of the ini file.
The LocalizedResourceName parameter can be used to change the folder name to something else when viewed in Windows Explorer.
Certain system folders use class ids to define the folder properties. Here again the folders attributes define the folder properties and the desktop.ini file can have any attribute set.
To create a recycle bin folder changing the folder attributes to system or readonly makes it change to the bin icon. The ini file settings should contain this class id below
For the Scheduled tasks again changing the folder attributes to system or read only makes it change to the tasks icon.
So what does this mean from a malware point of view? Well these kind of system folder properties malware files can be easily hidden from view. i.e. having a job in Windows tasks (C:\WINDOWS\Tasks) with a hidden attribute set on the job file will be invisible even with all files and folders set to show. The same goes for the recycle bin where malware writers create a bogus recycle bin folder containing malware files which when browsed through Explorer remains invisible and only genuine deleted files are shown to the user.
After a week of this 0-day vulnerability being reported a number of posts have been published over the last few days detailing the disassembled malicious flash (swf) file exposing the invalid byte triggering the vulnerability. The vulnerability is caused when handling a “newfunction” instruction by Adobe’s ActionScript Virtual Machine 2 (AVM2). The vulnerability lies in both Adobe Reader and Adobe Flash so either product is vulnerable to attack. This post Im focusing on the actual malware that gets dropped when a malicious pdf file is opened.
After the pdf file is opened the first thing it does is process the malformed flash file in the pdf file which triggers the vulnerability dropping an executable in the root.
This file has been embedded in the pdf file making it portable without depending on any external sites to download and execute the malware. Once the dropped executable gets executed and a further 3 more files gets dropped onto the system.
The original qmgr.dll file located in C:\WINDOWS\system32\ gets renamed to kernel64.dll and a malicious qmgr.dll takes it place. Also the original qmgr.dll file located in C:\WINDOWS\ServicePackFiles\i386\ gets replaced with the malicious qmgr.dll. The file Eventsystem.dll is a copy of the malicious dll file qmgr.dll and the file es.ini is just ascii file contains the text below used by qmgr.dll
The final change to the system making sure the malware starts up everytime is changing the settings in a legitimate Windows service called “Background Intelligent Transfer Service” (BITS). By default the status is not started and startup type set to manual. This now becomes a started status with the startup type set to automatic. Thereafter when the system starts the service dll qmgr.dll gets loaded in memory when the BITS service is started.
Note that the time stamp has also been modified making it harder to trace if searching by date.
Adobe has now released an update for Adobe Flash 10.1.53.64 fixing the vulnerability. This resolves the issue if a swf file is opened via the web. For pdf files Adobe Reader update has not yet been released. One way to mitigate for now is to rename the following files:
C:\Program Files\Adobe\Reader 9.0\Reader\authplay.dll
C:\Program Files\Adobe\Reader 9.0\Reader\rt3d.dll
This analysis had been done using Adobe Reader version 9.3.2 with a pdf file having a md5 hash value of 721601bdbec57cb103a9717eeef0bfca