> Date: Wed, 29 Feb 2012 08:29:39 -0500
> Subject: Re: [Vol-users] A little direction help please
> From: michael.hale@gmail.com
> To: dragonforen@hotmail.com
> CC: vol-users@volatilityfoundation.org
>
> Mike,
>
> On Sun, Feb 26, 2012 at 7:28 PM, Mike Lambert <dragonforen@hotmail.com> wrote:
> > I am conducting an examination of a test system infected with a sample from
> > the internet. See attached virustotal scan if you are interested what it is.
> > fawi.exe is the dropped infection result of sample ssl.exe
> >
> > I am having trouble answering the question, "Where is the malware?". This is
> > not the usual rundll or infected program in memory, it is injected. I think
> > it is in the kernel, but this is a new area for me. Any direction on how I
> > answer that question is appreciated.  (One thought I had is: that the
> > malware is hooked into the SSDT that zone alarm's vsdatant.sys hooks and
> > since vsmon.exe probably uses vsdatant.sys, that is why the malware looks
> > like it is in vsmon.exe - but it is just hooked into the kernel.)
>
> Don't overlook your biggest clues. The virustotal scan indicates PWS,
> Zbot, Injector, etc. Its probably a zeus variant. The IP that
> Explorer.exe is connected to is a known zeus CC:
> https://zeustracker.abuse.ch/monitor.php?host=analyticdns.org.
>
> Zeus doesn't use any kernel hooks, but there are at least 3 or 4
> analysis by different folks showing how they detected zeus (google for
> "zeus volatility malware" or just run through the malware commands
> http://code.google.com/p/volatility/wiki/CommandReference#Malware_and_Rootkits
> with a Volatility 2.0 build).
>
> > Here is where I am at and how I got there:
> >
> > The infection started executing ssl.exe, here is some prefetch info:
> > SSL.EXE-028F0541.pf Saturday, February 25, 2012 23:08:41 Z (UTC)
> > Nothing in PSSCAN, no ssl.exe anywhere in fact.
> >
> > It dropped:
> > \DOCUMENTS AND SETTINGS\MIKE\APPLICATION DATA\YPYCUB\FAWI.EXE   and executed
> > it:
> > FAWI.EXE-398259A4.pf Saturday, February 25, 2012 23:08:41 Z (UTC)
> > PSSCAN shows it ran for 3 secs
> >  Offset     Name             PID    PPID   PDB        Time
> > created             Time exited
> > 0x0420ca70 fawi.exe           3812   2468 0x0cd44000 2012-02-25
> > 23:08:37      2012-02-25 23:08:40
> >
> > Seeing this:
> > fawi.exe pid:   3812
> > Unable to read PEB for task.
> > did not surprise me since it had exited.
> >
> > I could easily see how it is in NTUSER.DAT and starts with the run key:
> > HKCU\Software\Microsoft\Windows\CurrentVersion\Run
> >    {AED24BF3-7C21-B878-2172-0CFD5C3474CA}
> >      "C:\Documents and Settings\Mike\Application Data\Ypycub\fawi.exe"
> >      Glows Anger Hebrew
> >      Orb Networks
> >      8.3.0.0
> >      c:\documents and settings\mike\application data\ypycub\fawi.exe
> >      f4cc71ca8e5522519b9c6e8d350d876b (MD5)
> >
> > Since fawi.exe has terminated, my only clue is explorer.exe communications
> > seen by cports.exe
> > 2/25/2012 5:08:39 PM Added           Explorer.EXE         TCP
> > 192.168.1.44:1185      94.63.147.98:80
> >
> > (An interesting note: Win32dd and FDPRO were both unable to collect a memory
> > image. I hibernated the system and converted hiberfil.sys to a file I could
> > analyze with Volatility.)
> >
> > Explorer.exe seemed the first suspect as it was the only process sending
> > network i/o out
> > 0x043d7360 explorer.exe       1756   1732 0x107ff000 2012-02-25 11:30:26
> >
> > I pulled the dlls, files and reg keys for PID 1756, along with a memdmp.
> > Nothing interesting in the dlls files or keys. I examined the dmp and found
> > an unusual string in it along with ssl.exe and fawi.exe and this
> > "Glows Anger Hebrew"  A search of the internet shows one reference in a
> > similiar infection in February. I found it on the internet just 2 days after
> > the first sample was sent to virustotal.
> >
> > I searched the 458 MB memory image for "Glows Anger Hebrew" and got 5 hits.
> > Here is my text file for the strings function
> > 357229672:Glows
> > 280642408:Glows
> > 257105340:Glows
> > 113457472:Glows
> > 357230696:Glows
> >
> > Results from strings is:
> > 357230696  [kernel:df864868 ] Glows
> > 357229672  [kernel:df864468 ] Glows
> > 257105340  [kernel:e1ec1dbc ] Glows
> > 113457472  [1456:2ac0940 ] Glows
> > 280642408  [1456:45b8368 ] Glows
> >
> > PID 1456 is:
> > vsmon.exe pid: 1456
> > Command line : C:\WINDOWS\system32\ZoneLabs\vsmon.exe -service
> > PSSCAN is
> > 0x043e6020 vsmon.exe          1456    848 0x102da000 2012-02-25 11:30:25
> >
> > I dumped PID 1456 and searched the dmp. I also grabbed a couple of other
> > processes (because 3 were kernel references). See search results in the
> > attached JPG (cut and paste test did not work out well).
> >
> > So, strings said that the malware is injected in vsmon.exe. Is that correct?
> > Now I guess my next step is to identify the thread? Or is this malware
> > 'everywhere' in that it is in the kernel, and everyone mapps to it?
>
> I'd view page permissions on 2ac0xxx and 45b8xxx in pid 1456 (vadinfo
> command) and see if they're executable. If they're read-only they're
> probably in vsmon.exe because vsmon.exe, being part of ZoneAlarm,
> opened the malicious file to scan it.
>
> MHL
>
> > I need some help on next steps. Am I moving in the right direction?
> >
> > BTW, who else is doing this type of work? and are you interested in
> > colaborating? I am in Houston, TX.
> >
> > Thanks for your help!
> >
> > Mike Lambert
> > dragonforen@hotmail.com
> > michael-lambert.us/index.htm
> >
> >
> >
> >
> > _______________________________________________
> > Vol-users mailing list
> > Vol-users@volatilityfoundation.org
> > http://lists.volatilityfoundation.org/mailman/listinfo/vol-users
> >