re: aretzj.exe -- reappearing unknown system file

[Harlan Carvey <keydet89 () yahoo com>]

Kevin,

I didn't see any sort of resolution or follow-up on
this thread on SF's security-basics list, so I thought
I'd drop a line...

> I've come across, on a client's machine, a 
> reappearing / self propogating read only system
> file. The box is running a copy of XP pro fully 
> patched.
>
> c:\windows\system32\aretzj.exe

For clarification's sake, this is *not* a system file.
 I know it's in the system32 directory, and it may
have the system bit set (via 'attrib', just like with
the read-only bit) but it's *not* technically a system
file. 

Also, when you say "self propogating[sic]", are you
saying that this thing has propagated to other
machines?

> When Internet explorer is brought up this program 
> (aretzj.exe) asks for internet access via 
> ZoneAlarm. When deleted it reappears at bootup and
> even if the computer has not been restarted.

Actually, what's happening is that the program is
trying to access the 'net and is being blocked by ZA. 


If it reappears at bootup, then there's something
initializing it.  There are several ways in which this
could happen...and since this seems to be affected
primarily by IE, I'd suggest that you look into
Browser Helper Objects (BHOs).  What may be happening
is that IE is being told to load a DLL, which checks
for the suspect file.  If it doesn't find it, it
extracts that file and then launches the process.

> I can not find any reference in Technet or any of
> the search engines. 

I doubt that you would...especially TechNet.  In fact,
I don't really even understand why you'd check there,
but hey, you never know, right?

> It is read only and when deleted the XP claims it
> is a system file.

Again, take a look at the old DOS attrib command. 
It's still around with XP.

> I tried about 20+ search engines. One mentioned a 
> Name an author of a book published in 1935 - author 
> ha'aretz (without the "j").

If you ever make it over to the SF Virus list, you'll
probably see a guy named Nick Fitzgerald, and at some
point, you'll see him chiding someone about relying
solely on filenames when doing searches on the
Internet for a reference to a particular file,
especially when Windows systems are involved.  That's
b/c he's right.

> What I have done to try and identify the source:
>
> 1. looked for other "unknown" files inside of 
> system32, including checking dates of files such as 
> the KERNEL and KERNEL32 and looked for "suspicious"
> files. No results except aretzj.exe

I'm not clear on how helpful this would be...what do
you define as "unknown" or "suspicious"?  And which
dates were you checking?  Last access?  Last
modification?

> 2. cleaned out the [prefetch] folder (no positive 
> results)

I don't know why you would expect to see "positive
results" from this, really.  The purpose of the
Prefetch directory is to assist in application
loading, so the only effect this will have is that
your commonly-used applications will load a bit slower
the first time you run then after you clear the
directory out.  If you remove the layout.ini file, as
well, then your system defrag won't be optimized quite
as much as it could be.  But that's about
it...clearing this directory won't have any effect on
helping you find out what this file is.

> 3. [Downloaded prgram files] is and was empty

I'm sure it is.  Good idea to check, just in case,
though.

> 4. Checked c:\program files\internet explorer
> Looked for suspicous or unknown folders in common 
> files.

Again, what do you define as "suspicous[sic]" or
"unknown"?

> 5 Spent an almost inordinate amoutn of time poking
> around in general looking for clues, identifying 
> plugins, checking system and hidden folders to no
> avail.

Yeah, I'm sure...it can be frustrating.

Here's what I suggest...read through this and then
decide what you want to do.

1.  Go to SysInternals.com and get a current copy of
Autoruns.exe and Autorunsc.exe.  Run either on, with
all options set (even services) and save the results
to a file.  This program is the best out there for
checking autostart locations...none of the places you
checked allow a program to autostart.  

2.  Also at SysInternals.com, get a copy of
listdlls.exe, and when the system is running, run it
against the PID for IE.  Save the output to a file via
redirection (ie, "listdlls > myfile.txt").  Listdlls
will give you version information from each of the
DLLs that IE is using...version information that is
compiled directly into the DLL itself.  Finding DLLs
that don't have this information available may assist
you in tracking down how the .exe file is loading.

3.  If you're able to get a copy of the .exe file
itself (which it seems that you are), then go to
http://www.dependencywalker.com/ and get depends.exe. 
Open the .exe in this utility, and it will show you
which DLLs the file uses...this will help you track
down other files associated with this issue.

4.  Get a copy of Ethereal and install it on another
system on the same subnet as your "infected" system. 
Reboot the "infected" system, and have Ethereal
capturing the entire time.  Filter on all traffic
going to and from the "infected" system.  All the
traffic to go off of the box (disable ZA temporarily
if you have to).  Save the capture for analysis.

5.  Go to NTSecurity.nu and get a copy of pmdump.exe. 
The next time you see the .exe file running, run
pmdump.exe against the process, and dump the contents
of the program memory to a file.  This information can
be parsed to help track down the file.  Also, be sure
to open Task Manager and find out what user context
the process is running as...check the Username column.
 This may help you track down the file.

6.  Go to SysInternals.com and get a copy of
strings.exe, or go to Foundstone.com and get a copy of
BinText.  These tools will show you the ASCII and
Unicode strings embedded in a binary file.  Run either
one and save the output.  

> I am not sure what it is but as I renamed the file
> to a .txt extension and read through the "readable" 
> portion of the binary file hoping for some hook
> on identifying it.

Yeah, well the binary stuff is pretty much unreadable.
 Try running 'strings' against it to get ASCII and
Unicode strings out of it.

> At this point I am concerned as it 
> as "unidentifable" the terminology inside
> the binary file might be construed with "data 
> mining" and the client does run propriatary 
> databases - Oh Yes, and I have checked with the 
> vendor of the clients database software. They tell 
> me nothing is stored on the PC nor is anything 
> except a browser required to view the database.

This .exe isn't "unidentifiable" at all.  It's just
that the right methodology, tools, and techniques
haven't been used to identify it.

> We are now using firefox but the unknown file 
> continues to reappear.  The only solution I have 
> come up with is to wipe everything reinstall and
> restore actual data from a backup.

Well, this is a new piece of information...it
reappears with Firefox, so it's not specific to IE. 
Okay.  Well, the stuff I gave you above will still be
very helpful.  

> Any  help or suggestions will be greatly 
> appreciated.  Or has anyone run across this culprit?

For future assistance, this article was just published
in the Digital Investigation Journal:
http://www.compseconline.com/digitalinvestigation/DIINcarvey.pdf

You may find it helpful in the future.

Hope this helps,

Harlan


------------------------------------------
Harlan Carvey, CISSP
"Windows Forensics and Incident Recovery"
http://www.windows-ir.com
http://windowsir.blogspot.com
------------------------------------------