Crap AV detection results

[Frazer Jolly Goodfellow]

Indeed. That file is a little like the old "autoexec.bat" file. Consider
an entry like "@hrur4ttn.exe" in that file. Sure, it would be good to
detect such an entry, but you wouldn't really know much about the
malware itself without analyzing the actual "hrur4ttn.exe" file.


The one the information file attempts to execute when autorun is
enabled - or the one it attempts to trick the user into executing by
making it look like a simple "open" action.


It is not a patch, it is a configuration option. Sort of like having the
option to not boot from a floppy to avoid boot sector infector
propagation.

A patch is needed to fix the configuration option.
http://www.itworld.com/windows/63219/after-cert-warning-microsoft-delivers-autorun-fix

The text file?

Yes.

 

[FromTheRafters]

Did the material you posted come from the actual autorun.inf file, or
is
it part of the file that is mentioned _in_ the autorun.inf file?

Please post the contents of the inf file here, then submit the file
that
is launched from the inf file to virus total and report back the
results.

I've pasted the complete contents of the autorun.inf file below. I
don't
know what is launched as a consequence of its execution because the
text is
so obfuscated.
[snippage]

* [AUTorUN/

 AcTION =Open folder to view files

* icon/_ =* *%syStEmrOot%\sySTEM32\sHELL32.Dll ,4

shelLExECUte__ =RuNdLl32.EXE
.\RECYCLER\S-5-3-42-2819952290-8240758988-879315005-3665\jwgkvsq.vmx,ahaezedrn

Location of file.

 

[FromTheRafters]

A patch is needed to fix the configuration option.
http://www.itworld.com/windows/63219/after-cert-warning-microsoft-delivers-autorun-fix

True, but it is still an abuse of function rather than a software flaw
that needed to be patched.

In the above analogy, it is like setting the option not to boot from
floppy and yet still being able to boot from the floppy. If the
suggested option was to change the boot device order to make the floppy
the last option chosen - you could still get infected if the other
devices were not bootable for some reason. Changing the CMOS Setup
program to allow "disabling" of boot devices would be the equivalent of
the patch.

Yes.

I think you place too much emphasis on detecting this fragment of the
worm.

 

[Virus Guy]

Please post the contents of the inf file here, then submit the
file that is launched from the inf file to virus total and
report back the results.

I've pasted the complete contents of the autorun.inf file
below. I don't know what is launched as a consequence of
its execution because the text is so obfuscated.
[snippage]

* icon/_ =* *%syStEmrOot%\sySTEM32\sHELL32.Dll

If that mess was the actual contents of the autorun.inf file, well then
either there's a flaw in how Windows processes the INF file and it
allows it to be constructed / formatted in such a non-documented way as
to resemble a binary file, or it's leveraging an exploit in how the
autorun.inf handler works.

Can anyone point to material that describes how or why autorun.inf would
be able to execute the contents of that file?

.\RECYCLER\S-5-3-42-2819952290-8240758988-879315005-3665\jwgkvsq.vmx,ahaezedrn

Location of file.

How did it get there? Did your AV program put it there? What does your
AV log file say?

It should still be on the USB stick, unless it was deleted from there.

Is it still in the recycler? If so, temporarily turn of your AV program
and submit the file to Virus Total. Then turn your AV back on.

 

[Virus Guy]

Can anyone point to material that describes how or why autorun.inf
would be able to execute the contents of that file?

Ok, I see why:

------------------
Typical Autorun.inf files are very small in size.

The Downadup worm inflates the size of its autorun.inf in an attempt to
avoid detection by antivirus signature scanners. Binary characters are
used to inflate the file size. These binary characters are ignored by
the Windows operating system.

Windows will find the following command:

• Open=RUNDLL32.EXE .\RECYCLER\jwgvsq.vmx

This command executes a DLL called jwgvsq.vmx from a hidden folder on
the removable drive containing the malicious autorun.inf.
-------------------

Now why would Microsoft have designed their autorun.inf handler such
that it strips non-printable characters?

Why not just barf and ignore the file if it contains such characters?

What were they anticipating such that they built that behavior into the
autorun handler?

So the file is located in a hidden folder on the usb memory stick.

Submit that file to virus total. Change the properties on the folder if
necessary to make it visible.

 

[Frazer Jolly Goodfellow]

Frazer Jolly Goodfellow wrote:

It should be referred to in the affected autorun.inf file.

Heavily obfuscated I fear - here's a sample from the start of the
file:

Did the material you posted come from the actual autorun.inf file, or
is
it part of the file that is mentioned _in_ the autorun.inf file?

Please post the contents of the inf file here, then submit the file
that
is launched from the inf file to virus total and report back the
results.

I've pasted the complete contents of the autorun.inf file below. I
don't
know what is launched as a consequence of its execution because the
text is
so obfuscated.
[snippage]

* [AUTorUN/

 AcTION =Open folder to view files

* icon/_ =* *%syStEmrOot%\sySTEM32\sHELL32.Dll ,4

shelLExECUte__ =RuNdLl32.EXE
.\RECYCLER\S-5-3-42-2819952290-8240758988-879315005-3665\jwgkvsq.vmx,ahaezedrn

Location of file.

Spot on. There is evidence of it having been on the memory stick: the
folders E:\RECYCLER\S-5-3-42-2819952290-8240758988-879315005-3665 are still
there. Unfortunately the payload file itself, jwgkvsq.vmx, wasn't there any
more. I ran an undelete program and it found remnants of that file, but I
suspect it was corrupted because of other file activity on the drive since
the deletion. VirusTotal reported 0/39 hits for the recovered jwgkvsq.vmx
file, which is inconclusive.

 

[FromTheRafters]

Ok, I see why:

------------------
Typical Autorun.inf files are very small in size.

The Downadup worm inflates the size of its autorun.inf in an attempt
to
avoid detection by antivirus signature scanners. Binary characters are
used to inflate the file size. These binary characters are ignored by
the Windows operating system.

Windows will find the following command:

. Open=RUNDLL32.EXE .\RECYCLER\jwgvsq.vmx

This command executes a DLL called jwgvsq.vmx from a hidden folder on
the removable drive containing the malicious autorun.inf.
-------------------

Now why would Microsoft have designed their autorun.inf handler such
that it strips non-printable characters?

Why not just barf and ignore the file if it contains such characters?

Fault tolerance?

You may be interested in the way comfiles and batfiles can exhibit this
behaviour. Check out the functioning of the batman186 virus or mimail.

What were they anticipating such that they built that behavior into
the
autorun handler?

I thought it was just a bad idea at the outset - but Microsoft has had a
history of giving the people what they want as opposed to what they need
securitywise.

So the file is located in a hidden folder on the usb memory stick.

Yes, as opposed to the 'exploit' and 'download from server' vector in
which it installs as you mentioned elsewhere.

Submit that file to virus total. Change the properties on the folder
if
necessary to make it visible.

That's the bugger where the danger lies (and the way to "identify"
rather than just detect a fragment).

 

[FromTheRafters]

Can anyone point to material that describes how or why autorun.inf
would
be able to execute the contents of that file?

I know that you know, but to be clear the autorun.inf file does not
execute the file's contents. The shell extension uses the information in
the autorun.inf file to determine what desired action to take (i.e.
which executable to execute or what to present to the user interface).

 

[kurt wismer]

I've just finished cleaning up a customer PC that was riddled with malware,
including the much-publicised Downadup/Conficker worm. To confirm the
latter, I 'harvested' the autorun.inf file it deposited on a test USB
memory stick and submitted it to virustotal.com. VirusTotal reported it had
first seen my suspect file on 4-Jan-2009 and that 26/40 identified it as
malicious. I requested re-analysis to see the current status.

you realize, of course, that the autorun.inf file *isn't* the actual
malware, it's just the tool the malware uses to get automatically
executed...

VirusTotal now reports 25/39 hits. Which means that after nearly three
months of it being known to the anti-malware community, more than 33% of
anti-malware packages *still* don't recognise it, including several
'household' names e.g. McAfee, AntiVir, Avast!, PCTools, PrevX. Even
Microsoft's product detected it!

most probably if you submitted what the autorun.inf file pointed to you
would have gotten better results...

[snip]

And where does that leave anti-malware benchmarking? Scoring close to 100%
in a benchmark but missing the bleedin' obvious in live use doesn't
re-assure me at all.

there are a number of reasons why virustotal can't be used as a measure
of an av product's effectiveness... they aren't always using the most
up-to-date version, they only run the command line scanner component and
thus miss out on the more advanced detection capabilities, etc...

 

[kurt wismer]

On Sat, 28 Mar 2009 19:21:54 -0400, Virus Guy wrote:
[snip]

If so, that's the file you should have sent to Virus Total.

... so the autorun.inf file planted on removable media to infect the next
PC it's plugged into isn't significant? Wouldn't it be useful if the AV
software on that PC could recognise it before it is executed?

autorun.inf files are too generic and they're used by too many
legitimate things... the only thing it will have in it is a filename of
the real malware and since malware can't be identified by filename the
autorun.inf file is insufficient...

 

[kurt wismer]

Please post the contents of the inf file here, then submit the
file that is launched from the inf file to virus total and
report back the results.
I've pasted the complete contents of the autorun.inf file
below. I don't know what is launched as a consequence of
its execution because the text is so obfuscated. [snippage]

* icon/_ =* *%syStEmrOot%\sySTEM32\sHELL32.Dll

If that mess was the actual contents of the autorun.inf file, well then
either there's a flaw in how Windows processes the INF file and it
allows it to be constructed / formatted in such a non-documented way as
to resemble a binary file, or it's leveraging an exploit in how the
autorun.inf handler works.

it's the former - autorun.inf files can be obfuscated by inserting junk...

i can't remember who it was i saw write about this before but i have
heard about it before...

 

[jen]

Yes, it will be randomly named (which should be some-what easy to pick
out, for a human anyways). It will be located in either the System32
directory, program files or the user's temporary files folder.
One characteristic is that it will have the same date-stamp as the
host's kernel32.dll file.
So find kernel32.dll, look at it's date (not sure if it's created or
modified date you want) then seach the entire system (including hidden
and system files) for all .dll files with the same date. Then
visually
scan the list and look for a "randomly-named" file. The bone-heads
that
wrote a write-up I was reading about it doesn't mention the typical
size
for this file, which would help to narrow it down.
http://mtc.sri.com/Conficker/addendumC/index.html
The file will have it's write and delete privileges set so that it
can't
be deleted. Besides some registry entries that it sets (some, most or
all of which it doesn't seem to use), the only file it relies on is
itself - no accessory files. It doesn't even modify any system files
(but it does alter the memory images of some specific system files).

An easier way to find the random name of the DLL...
1. In Registry Editor, locate and then click the following registry
subkey:
HKEY_LOCAL_MACHINE\SOFTWARE\Microsoft\Windows NT\CurrentVersion\SvcHost
2. In the details pane, right-click the netsvcs entry, and then click
Modify.
3. Scroll down to the bottom of the list. If the computer is infected
with Conficker.b, a random service name will be listed. For example, in
this procedure, we will assume the name of the malware service is
"gzqmiijz". Note the name of the malware service. You will need this
information later in this procedure.
4. Delete the line that contains the reference to the malware service.
Make sure that you leave a blank line feed under the last legitimate
entry that is listed, and then click OK.
http://support.microsoft.com/kb/962007

The autorun.inf file is a text file. Presumably it's only a few lines
in length and contains no personally-identifiable information. If so,
please post it here. It will contain the name of the executable that
installs the DLL onto the system, so look for that file as well (if
this
was a USB memory stick then it should also be on the stick). Submit
that file to Virus Total and report back the results.
I'm not sure how different AV programs are positioned in terms of
interception ability when it comes to files that are launched via
autorun.inf on removable media.

-jen

 

[Gaz]

This could have been either Conficker.A or Conficker.B, given the
stated date.


Going back *over* 4 weeks ago, it was /then/ my understanding that the
Conficker.A, Conficker.B and Conficker.B++ worms existed in their
_basic_ form. Also I had read, at *that* time, that >300 variations
of those basic three existed. ...and now, we have their mama,
Conficker.C and many weeks for the all of these to flourish with more
variants coming from the minds of the bad folks.

I believe this problem is like none we've seen before.

Would you please post a reply with the reported identity(s) of the
worm you found?

Do you believe that most of the big named antimalware producers have
received samples of /most/ all of the strains?

If you believe you've successfully purged your customer's system, what
tool(s) did you employ to eradicate the Conficker worm? If you still
have a copy of the virustotal URL report, that would even be better.

I'm sure that many of us share in your obvious frustration.

Pete

But the mechanism and the method of operation are the same. The writing of
an autorun file to a flash disk would be a rare to non existant legitimate
activity, and a prety likely behaviour of a a virus.

All antivirus software should now be scanning removable media for autorun
files on the root, as a matter of routine and flagging up suspicious
behaviour.

Gaz

 

[Virus Guy]

All antivirus software should now be scanning removable media for
autorun files on the root, as a matter of routine and flagging up
suspicious behaviour.

Even more.

If malicious autorun.inf files are randomly padded with binary
characters to evade AV detection, then why don't the AV programs do what
the windows autorun.inf handler does - which is to remove the binary
characters? That way, different autorun.inf files can be boiled down to
the same file to make for easier detection. The AV programs would know
to handle specific files that way - autorun.inf specifically, perhaps
others (like *.bat, *.vbs, etc).

I still want to know why microsoft anticipated the presence of binary
characters in an autorun.inf file, to the extent that they developed
this mechanism to handle them. Even if it was a form of
error-correction, what confidence would you have in a script file that
had to have characters stripped out of it? What confidence would you
have that the result would be a coherent and funcational script?

If I replaced some of the text in my config.sys or autoexec.bat with
binary characters, and then stripped them out, the result would be
useless.

 

[kurt wismer]

Gaz wrote:
[snip]

But the mechanism and the method of operation are the same. The writing of
an autorun file to a flash disk would be a rare to non existant legitimate
activity, and a prety likely behaviour of a a virus.

just because it doesn't happen a lot in your environment doesn't mean
it's rare in other environments... virtually every software developer
that distributes their product on optical media uses autorun.inf files...

All antivirus software should now be scanning removable media for autorun
files on the root, as a matter of routine and flagging up suspicious
behaviour.

i think folks are getting a little hysterical about autorun.inf files...
while i agree that autorun is a braindead feature that should absolutely
be killed, scanning autorun.inf files is retarded - you might as well
scan autoexec.bat files while you're at it... there's nothing bad in the
autorun.inf file...

 

[kurt wismer]

Even more.

If malicious autorun.inf files are randomly padded with binary
characters to evade AV detection,

what makes you think that's why they're padded? an autorun.inf file with
absolutely no crud in it would also have nothing in it to indicate
malicious intent and thus be necessarily invisible to a scanner...
frankly, the more crud you put in an autorun.inf file the more sense it
makes to create a heuristic to look for crud in autorun.inf files...

it's far more likely that the padding is to stymie casual visual
inspection by unskilled users...

 

[1PW]

Gaz wrote:
[snip]

But the mechanism and the method of operation are the same. The
writing of an autorun file to a flash disk would be a rare to non
existent legitimate activity, and a pretty likely behavior of a a virus.

just because it doesn't happen a lot in your environment doesn't mean
it's rare in other environments... virtually every software developer
that distributes their product on optical media uses autorun.inf files...

All antivirus software should now be scanning removable media for
autorun files on the root, as a matter of routine and flagging up
suspicious behavior.

i think folks are getting a little hysterical about autorun.inf files...
while i agree that autorun is a braindead feature that should absolutely
be killed, scanning autorun.inf files is retarded - you might as well
scan autoexec.bat files while you're at it... there's nothing bad in the
autorun.inf file...

But Kurt, I wonder if that was _the_ possible attack vector that took
down a portion of the French Air Force for a few days and raised hob
with portions of bt.com as well?

I know this may be unanswerable.

USB thumb drives and laptops, brought from the outside world, were some
of the primary sources for our attacks at my previous place of employment.

Warm regards,

Pete

 

[FromTheRafters]

Gaz wrote:
[snip]

But the mechanism and the method of operation are the same. The
writing of an autorun file to a flash disk would be a rare to non
existent legitimate activity, and a pretty likely behavior of a a
virus.

just because it doesn't happen a lot in your environment doesn't mean
it's rare in other environments... virtually every software developer
that distributes their product on optical media uses autorun.inf
files...

All antivirus software should now be scanning removable media for
autorun files on the root, as a matter of routine and flagging up
suspicious behavior.

i think folks are getting a little hysterical about autorun.inf
files...
while i agree that autorun is a braindead feature that should
absolutely
be killed, scanning autorun.inf files is retarded - you might as well
scan autoexec.bat files while you're at it... there's nothing bad in
the
autorun.inf file...

But Kurt, I wonder if that was _the_ possible attack vector that took
down a portion of the French Air Force for a few days and raised hob
with portions of bt.com as well?

I know this may be unanswerable.

USB thumb drives and laptops, brought from the outside world, were
some
of the primary sources for our attacks at my previous place of
employment.

You would think that sneakernet was a new development after reading
about the USB autorun vector. What security professional doesn't already
know that attaching foreign devices to a system can lead to malware
problems?

 

[1PW]

Gaz wrote:
[snip]
But the mechanism and the method of operation are the same. The
writing of an autorun file to a flash disk would be a rare to non
existent legitimate activity, and a pretty likely behavior of a a
virus.
just because it doesn't happen a lot in your environment doesn't mean
it's rare in other environments... virtually every software developer
that distributes their product on optical media uses autorun.inf
files...

All antivirus software should now be scanning removable media for
autorun files on the root, as a matter of routine and flagging up
suspicious behavior.
i think folks are getting a little hysterical about autorun.inf
files...
while i agree that autorun is a braindead feature that should
absolutely
be killed, scanning autorun.inf files is retarded - you might as well
scan autoexec.bat files while you're at it... there's nothing bad in
the
autorun.inf file...

But Kurt, I wonder if that was _the_ possible attack vector that took
down a portion of the French Air Force for a few days and raised hob
with portions of bt.com as well?

I know this may be unanswerable.

USB thumb drives and laptops, brought from the outside world, were
some
of the primary sources for our attacks at my previous place of
employment.

You would think that sneakernet was a new development after reading
about the USB autorun vector. What security professional doesn't already
know that attaching foreign devices to a system can lead to malware
problems?

Hi All:

Mentioning sneakernet - I guess I'll load up some of my thumb drives
with all the legitimate Conficker removal tools to be found, gas up our
cars, and be prepared to make a few house calls late in the week...

Pete

 

[Frazer Jolly Goodfellow]

On 03/29/2009 08:25 PM, kurt wismer sent:
Gaz wrote:
[snip]
But the mechanism and the method of operation are the same. The
writing of an autorun file to a flash disk would be a rare to non
existent legitimate activity, and a pretty likely behavior of a a
virus.
just because it doesn't happen a lot in your environment doesn't mean
it's rare in other environments... virtually every software developer
that distributes their product on optical media uses autorun.inf
files...

All antivirus software should now be scanning removable media for
autorun files on the root, as a matter of routine and flagging up
suspicious behavior.
i think folks are getting a little hysterical about autorun.inf
files...
while i agree that autorun is a braindead feature that should
absolutely
be killed, scanning autorun.inf files is retarded - you might as well
scan autoexec.bat files while you're at it... there's nothing bad in
the
autorun.inf file...
But Kurt, I wonder if that was _the_ possible attack vector that took
down a portion of the French Air Force for a few days and raised hob
with portions of bt.com as well?

I know this may be unanswerable.

USB thumb drives and laptops, brought from the outside world, were
some
of the primary sources for our attacks at my previous place of
employment.

You would think that sneakernet was a new development after reading
about the USB autorun vector. What security professional doesn't already
know that attaching foreign devices to a system can lead to malware
problems?

Hi All:

Mentioning sneakernet - I guess I'll load up some of my thumb drives
with all the legitimate Conficker removal tools to be found, gas up our
cars, and be prepared to make a few house calls late in the week...

Hope they're write protectable, otherwise you risk becoming a carrier.