Re: HTML.ObjectDataHTA

On Wed, 04 Jan 2006 07:10:11 -0800, Malke wrote:
>Mediamon wrote:

>It is always recommended to run virus/malware scans in Safe Mode because
>most malware is actively in use during Regular Mode. You cannot delete
>a file in use. Sometimes it is even necessary to remove malware from
>Safe Mode Command Prompt only because it has hooked into the gui. There
>is no reason to limit yourself to scanning in Normal Mode and in fact
>doing this may hamper malware removal.

Agreed. Not only will the practicalities of the OS prevent removal of
a file that is "in use", but active (running) malware is in a position
to actively defend itself and/or react punitively it attacked.

For these reasons, and bearing in mind we are talking about malicious
software here, it is best to attack malqware when it is NOT active.

Unfortunately, Safe Mode (even Command Prompt Only) cannot be relied
upon to prevent malware from being active, although the mechanisms for
malware to become active are reduced. These mechanisms are:

1) Direct primary entrance

A PC that is connected to (or connectionable by) networks can be
primarily (re-)infected through networking. Such connections include
the Internet, cabled LAN connections to other systems that are
infected, wireless LAN, bluetooth, infra-red and so on.

Primary entrance to occur from removable media.

Opportunities for primary entrance may be by design (e.g. allowing
code files to be dropped into StartUp groups via hidden admin shares,
or allowing Remote Procedure Calls to be initiated, or the
auto-running of an inserted CD) or by defect.

2) Explicit integration

Malware that does not use (1) to re-infect the system from outside,
will usually seek to persist across Windows sessions in some way.

The easiest of these is to exploit by-design opportunities to
integrate the malware code into the system, via the startup axis, file
associations, shell integration and so forth - opportunities that
exist both at OS and application levels.

The relative success of Safe Mode is that most startup integrations
are disabled in this mode. Safe Mode Command Prompt Only goes
further; by not running the shell, shell integrations are avoided.

3) Intrafile integration

This is the oldest method of persistance across runtimes, necessitated
by the few opportunities for (2) that DOS offered - basically, there
were only two points of entry (Config.sys and Autoexec.bat), both of
which were a familiar part of the user skill set of the time.

Windows and antivirus software make it more difficult to infect the
inside of existing code files, via System/Windows File Protection and
heuristic monitoring of such behavior, respectively. It is also
technically difficult to do, especially from the high-level languages
that make stability and broad functionality easier to attain.

For these reasons, we see less (3) than (2) in the 21st century,
though method (3) has not been abandoned. One reason why, is that it
can attain malware activity within Safe Mode and Safe Mode Command
Prompt Only; where relevant, DOS mode is usually spared, but only
because most intrafile code infection techniques are specific to the
Win32PE code file format that does not run in DOS mode.

4) Self-integration

We are, AFAIK, not seeing this as yet, but it can be predicted easily
enough - it is the main significance of defects that allow code to run
when icons are extracted, files are indexed in the background, etc.

This approach allows zero-integration persistance of malware activity
across OS sessions. There's no intrafile changes for code integrity
checkers to detect, no invasion on existing code files for av to
heuristically detect, and no explicit integrations that can be spotted
via registry scans or suppressed by Safe Mode.

Not only that, but method (4) allows the infection of off-HD
environments (if the OS contains the same exploitable defects) as well
as the infection of these environments, if they are not read-only.

Method (4) is the very large shoe that we are still waiting to drop.

>> The two PMM files are containers for much important unread email. The
>> point of this exercise is to repair the files. Deleting is the very
>> last resort option.

Mail storage is one of two locations where malware can be hidden from
scanners, the other being System Restore data (particularly when
compressed or "cabbed", as occurs in WinME).

Risks from email content can operate in various ways:

a) Use of HTML "features"

These threats reside within the "message" itself, and include all the
unsafe garbage that makes HTML such a poor choice for generic "rich"
information exchange between arbitrary parties, e.g. scripting, etc.

It's important to choose an email app that is smart enough not to run
any of this stuff at all, ever. Most email is unsolicited, and I can
think of no context where I would want to confer programming rights to
arbitrary unsolicited content from outside the system.

b) Normal attachments

Properly-encoded files allow any sort of content to be delivered, and
pose the biggest malware risk as a result. Generally, even the most
useless email apps are not designed to "open" such files
automatically, but this may be possible in combination with (a),
either via by-design (scripting etc.) or defect exploitation methods.

Some email apps break file attachments out of the message "text" and
store these outside the mailbox storage in another location as files
that can be scanned, deleted etc. I prefer this; Eudora does this,
whereas Outbreak, OE, Thunderbird, Netscape Mail, Pegasus etc. do not.

c) Abnormal attachments

Attachments can be abnormal in two ways. They can be improperly
embedded in the message "text" so that they are inconsistently handled
(e.g. an av scanner may fail to extract and scan them while the email
app may extract and "open"them just fine). Or they can be described
at the MIME level as files to be "opened" as part of the "message
text", such may be done with JPEG images, sound files, etc.

By design, such "inline" files are supposed to be safe. But this
assumption of safety can be broken in two ways; either by exploiting
by-design or via-defect escalation opportunities within the file type
itself (e.g. the current WMF debacle) or by mis-representing the
file's type at the file name extension and/or internal content level.

Eudora breaks all encoded files out of the message, but stores
"in-line" files in a different location, does not "open" them if the
file type is mis-represented, and provides no explicit link to such
files either. In effect, MIME-spoofed files are auto-quarantined;
they exist as loose files that can be scanned and killed, but there is
no manual not automatic mechanism whereby they can be "opened" from
within the email program.

This is how Eudora has always treated such files, even before IE's
HTML rendering engine was fixed for MIME-spoofing in the IE 5.xx era.

d) External links

The malware not be within the email "message" or attachments at all,
but may be linked via the wonders of HTML. The linkage may
automatically retrieve the file when the "message text" is displayed,
thus confirming it is being "seen", or the user may have to click the
link to retrieve the content or visit the web site.

e) Human vector

The malware may not operate at the machine level at all; it may aim to
persuade the user to undertake the malicious action. Examples range
from the joke "this is a human virus payload; please delete the
following files..." through virus hoaxes and pyramid schemes that seek
to spread via users (gathering email address as it goes), to various
phishing schemes and so on.

SE and ME (Social and Machine Engineering, respectively) are how
malware work, but sometimes only one of these is required.

A sufficiently unsafe OS can forego the need for SE, e.g.
Lovesan/Blaster and other clickless attacks. Pure SE with no ME
component deprives heuristic defences of traction, unless such
heuristics successfully understand the SE.

In this case - malware content within Pegasus a mail box - the
significance of that content depends on how safely Pegasus handles it.

I'd want to be rid of such content, and here's how I'd do it:
- move messages to multiple mailboxes, per sender
- compact all mailboxes to remove "deleted" content
- re-scan mailboxes
- repeat process on the mailbox found to be infected

In this way, you'd eventually distil down to a mailbox containing the
one message that contains the malware (if there's only one such
malware, of course). Derive whatever forensic satisfaction possible,
then delete that message, delete again from trash, compact all 'boxes.

>Then I would suggest you contact Pegasus tech support to see if they can
>recommend a way to extract messages from their database files.

If the av can detect the signature in one mailbox, it will probably do
so in any mailbox. The problem is that mass of malware that is not
detected when hidden in a mailbox, due to mailbox encryption, or the
scanner's assumptions based on file types, offsets, etc.

>You need to extract the messages from the database so you can
>delete the infected ones and then read/backup the ones your
>girlfriend needs. Pegasus will know how to do this.

In Eudora, most of that work is already done. Messages are handled
safely in Eudora, and all file attachments are already ripped out and
stored as loose files that can be scanned and deleted. You no longer
have to delete the whole message and all attachments, as you do in
Pegasus; you can just delete a single attachment.

Eudora still has potential risk surfaces, especially if left to "use
Microsoft's viewer", thus inheriting all that may be wrong with IE's
HTML rendering engine. Correctly-MIME'd inline files included with
the message may exploit defects within the file handlers, e.g. WMF,
and broken file embedding may cause such files to remain within the
message store and be detected as such - though as they can't be
accessed, there's no risk unless the mail is imported into a different
email app that is exploitable.

>As is well known, an unprotected Windows machine on the Internet can
>become infected in less than 12 minutes.

Think (1) and pure ME clicless attacks. Implies a dangerously
defective OS, either at the design or coding level; usually both.

>...what matters is that she learn how to practice Safe Hex

That takes care of the SE. You also need to "teach" the OS and
applications to be less stupid to reduce scope for ME, and while
patching will fix code defects, it won't fix bad design decisions.

>Multi-AV is a tool written by Dave Lipman - just do a Google Groups
>search for his name and you'll see who he is. Sysclean is a first-line
>antivirus tool written and hosted by TrendMicro. It takes quite a while
>to run its various scans, but is effective as a first step in removing
>viruses/trojans. One of its great advantages is that it does not need
>to be installed on the target machine.

SysClean can be run formally - in order to avoid (1-3) - from Bart CDR
(as off-HD booted OS). It can be run without "plugging it in"; just
have it on a USB stick that is present when Bart boots, copy it to HD
for less write-fatigue on the stick, and run it there.

Note that as some scans don't run from Bart boot, the scan should be
repeated from Safe Mode Command Only.

Other scanners and tools that work from Bart CDR include:
McAfee Stinger
McAfee ScanPM (superdat) via ScanGUI plugin
F-Prot CLI scanner

Some of these need plugins; some will just run, as SysClean does. In
some cases, Bart includes the plugin required. Some tools need to run
from writable storage rather than from CD (SysClean, AntiVir). Some
tools need the RunScanner plugin to be present and used so they can
access the HD's registry (AdAware, HiJackThis).

Google and ye shall find.

>I'd be far less worried about installing and then uninstalling
>Ad-aware and Spybot and Ewido

AdAware and Spybot will in fact work without being installed, if you
simply run a scrape-over - but as is often the case, they will spawn
registry entries when used. So it's better to install them, so that
they can clean up when they are uninstalled.

Unlike known-to-be-aa-pig Norton AV, the registry impact of these
tools (even if deleted rather than uninstalled) is trivial.

>Many tools like HijackThis and Sysclean are not installed
>on the local computer.

SysClean doesn't pollute the registry when run. HiJackThis does, in
that the path to HiJackThis is recorded in the registry for some
reason, so you get the "this will impact registered programs" message
when you try to delete it after use. This can be safely ignored, and
the registry impact is minuscule, but I have no idea why this problem
was coded into HiJackThis in the first place.

>---------- ----- ---- --- -- - - - -
Don't pay malware vendors - boycott Sony
>---------- ----- ---- --- -- - - - -