Report Offensive Message
Tattoos, fake Recycle Bins, etc.
ocie3 said: 'I am not sure what you mean by "If it integrates itself, you can check the integration points and spot it." -- "it" being the malware.'
To be active, malware code needs to be present, and be run. Getting the code to run requires integration, and usually (these days) that is via an explicit integration point, usually in the registry.
Other methods include infecting the inside of existing code files, swapping a malware file into the same name as an existing code file, dropping an \AutoRun.inf into the root of a hard drive volume to run the code when navigating into that drive, name-spoofing existing or expected files so the user launches the code by accident, exploiting an internally-exposed code surface, integrating into an application instead of the OS (e.g. Normal.dot) etc.
But as at June 2010, malware is most likely to integrate via the registry, while some do infect existing code files.
Earlier, I said: "USB storage devices that are seen as removable (as opposed to fixed, or spoofing as optical type via U3) will have no Recycle Bin..."
ocie3 said: 'In my experience so far, whether a removable USB HDD has a "Recyle Bin" depends upon the Properties chosen for the user's desktop Recycle Bin.'
By "removable", I meant that the OS sees it as such. USB storage (other than real and fake optical drives) are usually treated either as fixed (partition table, etc.) or removable.
External hard drives are very likely to be seen as "fixed", so they will often have System Restore activity and a Recycle Bin.
This can cause problems when they wander off, as removable drives do, though at least recent Windows uses an installation-specific GUID to prevent different PCs or installatiosn from looking at the wrong SVI and Recycle Bin contents.
A USB device that is more obviously "removable", such as a flash drive or camera card, would not be expected to have a Recycle Bin on it (or SVI for that matter).
Desktop.ini files are generally hidden and system etc. at the attribute level; nonetheless, safe (non-default) UI settings will let you see these and non-default options within search should find them also.
There's a well-known CLSID for Recycle Bin behavior, which would be considered fake if it turned up in a filespec other than that valid for a "real" part of the Recycle Bin system. So in my experience, it's been fairly obvious... but as I mentioned, a "real" bin can be used in that way, too.
If you browse the namespace, as Windows Explorer does, you will see Recycle Bin contents (spanning all drives) in such locations. If you browse the file system, as something like Dir or ye olde pre-95 File Managers do, you'd see the actual files in those locations, as the Desktop.ini is ignored. But a more obvious giveway is the Recycle Bin icon you'll see for the folder.
OTOH, if you mean the GUID which forms the directory within a real (or fake) 'bin, that would be trickier. If the PC has a history of re-installs or dual installations, you would see this effect in all SVI and 'bin directories visible to those installations. It's a fairly reliable indicator of that sort of history, i.e. that Windows was "just" re-installed, or that the HD was dropped into another PC, and was seen by that PC's installation as a "fixed" drive.
As to "just wipe and rebuild, to be sure"; follow the logic. Effective malware won't give itself away by any visible activity, therefore every PC has to be considered potentially infected. If you give up on the ability to detect malware, what PCs do you then not burn down to the ground "to be sure"?
Actually, when the stakes are high enough, the above logic should be followed all the way down the rabbit-hole. Doing some crucial online transactions? Eithernet into a trusted Internet access (with no LAN-side systems) from a freshly-made, fully-patched read-only OS disk with firewall, and do your thing from there.
To be active, malware code needs to be present, and be run. Getting the code to run requires integration, and usually (these days) that is via an explicit integration point, usually in the registry.
Other methods include infecting the inside of existing code files, swapping a malware file into the same name as an existing code file, dropping an \AutoRun.inf into the root of a hard drive volume to run the code when navigating into that drive, name-spoofing existing or expected files so the user launches the code by accident, exploiting an internally-exposed code surface, integrating into an application instead of the OS (e.g. Normal.dot) etc.
But as at June 2010, malware is most likely to integrate via the registry, while some do infect existing code files.
Earlier, I said: "USB storage devices that are seen as removable (as opposed to fixed, or spoofing as optical type via U3) will have no Recycle Bin..."
ocie3 said: 'In my experience so far, whether a removable USB HDD has a "Recyle Bin" depends upon the Properties chosen for the user's desktop Recycle Bin.'
By "removable", I meant that the OS sees it as such. USB storage (other than real and fake optical drives) are usually treated either as fixed (partition table, etc.) or removable.
External hard drives are very likely to be seen as "fixed", so they will often have System Restore activity and a Recycle Bin.
This can cause problems when they wander off, as removable drives do, though at least recent Windows uses an installation-specific GUID to prevent different PCs or installatiosn from looking at the wrong SVI and Recycle Bin contents.
A USB device that is more obviously "removable", such as a flash drive or camera card, would not be expected to have a Recycle Bin on it (or SVI for that matter).
Desktop.ini files are generally hidden and system etc. at the attribute level; nonetheless, safe (non-default) UI settings will let you see these and non-default options within search should find them also.
There's a well-known CLSID for Recycle Bin behavior, which would be considered fake if it turned up in a filespec other than that valid for a "real" part of the Recycle Bin system. So in my experience, it's been fairly obvious... but as I mentioned, a "real" bin can be used in that way, too.
If you browse the namespace, as Windows Explorer does, you will see Recycle Bin contents (spanning all drives) in such locations. If you browse the file system, as something like Dir or ye olde pre-95 File Managers do, you'd see the actual files in those locations, as the Desktop.ini is ignored. But a more obvious giveway is the Recycle Bin icon you'll see for the folder.
OTOH, if you mean the GUID which forms the directory within a real (or fake) 'bin, that would be trickier. If the PC has a history of re-installs or dual installations, you would see this effect in all SVI and 'bin directories visible to those installations. It's a fairly reliable indicator of that sort of history, i.e. that Windows was "just" re-installed, or that the HD was dropped into another PC, and was seen by that PC's installation as a "fixed" drive.
As to "just wipe and rebuild, to be sure"; follow the logic. Effective malware won't give itself away by any visible activity, therefore every PC has to be considered potentially infected. If you give up on the ability to detect malware, what PCs do you then not burn down to the ground "to be sure"?
Actually, when the stakes are high enough, the above logic should be followed all the way down the rabbit-hole. Doing some crucial online transactions? Eithernet into a trusted Internet access (with no LAN-side systems) from a freshly-made, fully-patched read-only OS disk with firewall, and do your thing from there.
Posted by cquirke
12th Jun 2010
