re: aretzj.exe -- reappearing unknown system file

From: Harlan Carvey (keydet89_at_yahoo.com)
Date: 06/01/05

  • Next message: Roberto Alcantara: "RE: Passive FTP"
    Date: Wed, 1 Jun 2005 04:09:41 -0700 (PDT)
    To: systemcracker@gmail.com, kevinsnively@comcast.net, davec@digistruction.com, tvhawaii@shaka.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
    ------------------------------------------


  • Next message: Roberto Alcantara: "RE: Passive FTP"