## Clustering and Batch Analysis of APT1 sampleset

March 4, 2013 in Batch Analysis, Compromise Detection, Malware Analysis

As I mentioned in my previous post, I was toying around with various samplesets (e.g. zero access, APT1, etc.) and since the APT1 sampleset is all over the news, I took a stab at it and sandboxed the samples + attempted to cluster the results to see if I any patterns emerge…

### The sampleset – batch analysis

#### Encryption

Some of the samples use DES and the following passwords:

• Hello@)!0
• !b=z&7?cc,MQ
• 1b=z7/lx+WK!
• !b=z&7?cc,MQ>

#### File names / locations:

• %USERPROFILE%\Application Data\Help\svchost.exe
• %USERPROFILE%\Local Settings\Application Data\Microsoft\svchost.exe
• %USERPROFILE%\Local Settings\Application Data\Microsoft\wuauclt.exe
• %USERPROFILE%\Local Settings\spoolsvr.exe
• %USERPROFILE%\Local Settings\Temp\AcroRD32.exe
• %USERPROFILE%\LOCALS~1\Temp\17DC75.dmp
• %USERPROFILE%\LOCALS~1\Temp\17DC85.dmp
• %USERPROFILE%\LOCALS~1\Temp\17DD6F.dmp
• %USERPROFILE%\LOCALS~1\Temp\17DD9E.dmp
• %USERPROFILE%\LOCALS~1\Temp\17DDEC.dmp
• %USERPROFILE%\LOCALS~1\Temp\17E7CF.dmp
• %USERPROFILE%\LOCALS~1\Temp\17EE48.dmp
• %USERPROFILE%\LOCALS~1\Temp\BP Makes Two Gas Discoveries in Egypt’s Nile Delta.doc
• %USERPROFILE%\LOCALS~1\Temp\ctfmon.exe
• %USERPROFILE%\LOCALS~1\Temp\ctfmon.exe\svchost.exe
• %USERPROFILE%\LOCALS~1\Temp\em.exe
• %USERPROFILE%\LOCALS~1\Temp\Halliburton to Present at Dahlman Rose & Co. Ultimate Oil Services And E&P Conference.pdf
• %USERPROFILE%\LOCALS~1\Temp\iTunesHelper.exe
• %USERPROFILE%\LOCALS~1\Temp\Material Type Ore 20160605.pdf
• %USERPROFILE%\LOCALS~1\Temp\Open letter of Dow Corning Corp.pdf
• %USERPROFILE%\LOCALS~1\Temp\POWER_GEN_2012.pdf
• %USERPROFILE%\LOCALS~1\Temp\runinfo.exe
• %USERPROFILE%\LOCALS~1\Temp\svchost.exe
• %USERPROFILE%\LOCALS~1\Temp\Top Stock Alerts for Day Traders – Facebook, Freeport-McMoRan Copper & Gold, Fastenal, Research In Motion, EnCana, and Dollar General.doc
• %USERPROFILE%\LOCALS~1\Temp\US hesitant in condemning North Korean launch.pdf
• %USERPROFILE%\LOCALS~1\Temp\WINWORD.EXE
• c:\WINDOWS\ntshrui.dll
• C:\WINDOWS\ntshrui.dll1
• C:\WINDOWS\svchost.exe
• C:\WINDOWS\System32\Nwsapagent.dll
• C:\WINDOWS\system\ersvc.dll
• c:\WINDOWS\system\ersvc.dll

• !@ADS@#$• 1234 • 1qaz@WSX • COPYRIGHTMM2011V2 • fire • Geman.do • Global\AdobeReaderX • GLOBAL\ADR32 • GLOBAL\ADR64 • GLOBAL\MSFT64 • Globxxxxxxxxssssseeeeeeal\ADReeeerrttyyyy64 • hackersuck • ijnrfv • letusgohtppmmv1.0 • letusgohtppmmv2.0.0.1 #### Services: • .Net CLR (Microsoft .Net Framework COM+ Support) • DevFS (Device File System) • DevFS (Device File System) • DevSec (Rpc Device Management) • InfMon (Infrared Monitor) • Nwsapagent (Gateway Service for Netware) • RasAuto (Remote Access Auto Connection Manager) • tcpguard (tcpguard) #### Connections (note, may contain clean IPs/URLs): • 10.166.1.182 • 127.0.0.1 • 140.116.70.8 • 143.89.35.19 • 202.105.39.39 • 202.39.61.136 • 202.6.235.83 • 203.200.205.245 • 204.111.73.150 • 205.159.83.91 • 208.239.156.123 • 209.124.51.194 • 209.124.51.219 • 209.151.145.185 • 209.161.249.125 • 209.208.114.83 • 209.233.16.84 • 209.253.17.229 • 211.232.57.235 • 212.130.19.154 • 216.15.210.68 • 218.232.105.200 • 218.232.66.12 • 218.233.206.2 • 218.234.17.30 • 24.73.192.154 • 60.248.52.95 • 61.219.67.1 • 64.80.153.108 • 65.105.157.228 • 65.110.1.32 • 65.114.195.226 • 65.89.173.68 • 66.151.16.30 • 66.155.114.145 • 66.170.3.43 • 66.228.132.53 • 68.17.104.162 • 68.96.31.136 • 69.20.5.219 • 69.25.50.10 • 69.28.168.10 • 69.74.43.87 • 69.90.123.6 • 69.90.18.22 • 69.90.18.23 • 69.90.65.240 • 70.62.232.98 • 74.86.197.56 • 75.145.139.18 • admin.datastorage01.org • AdobeFlash.info.tm • cas.ibooks.tk • cas.m-e.org.ru • code.mcafeepaying.com • Colville.com • conference.ddns.us • ctcs.bigdepression.net • ctx.comrepair.net • dev.teamattire.com • documents.downloadsite.me • eclipsecti.infobusinessus.org • exactearth.info.tm • fasa.arrowservice.net • fasa.bigish.net • fasa.newsonet.net • flash.aoldaily.com • flash.aunewsonline.com • flash.cnndaily.com • flash.mcafeepaying.com • flash.usnewssite.com • fni.bigish.net • help.purpledaily.com • hint.happyforever.com • hojutsu.com • japan.yahoodaily.com • jimnaugle.com • johnford985.appspot.com • ks.aoldaily.com • ks.cnndaily.com • ks.jaimeastorga.mx • ks.manguvaljak.ee • ks.petrotdl.com.ar • ks.utworld.ch • media.finanstalk.ru • meeting.toh.info • moto.purpledaily.com • moto1.newsonet.net • moto2.earthsolution.org • news.canadatvsite.com • news.micyuisyahooapis.com • news.msnhome.org • olmusic100.com • portal.itsaol.com • public.ddns.us • qhun-mons.businessformars.com • report.crabdance.com • safety.canadatvsite.com • share.canoedaily.com • software.myftp.info • sports.canoedaily.com • stratos.aoldaily.com • stratos.mcafeepaying.com • tcw.homier.com • thecrownsgolf.org • time.mediaxsds.net • ttl.tfxdccssl.net • un.linuxd.org • update.dnepr.com • update.sektori.org • update.slowblog.com • us.gnpes.org • vop.earthsolution.org • wikileaks.ddns.us • www.bigish.net • www.bluecoate.com • www.businessformars.com • www.competrip.com • www.cvba.com • www.deebeedesigns.ca • www.doversolutions.co.in • www.drgeorges.com • www.dsds.co.kr • www.fbrshop.com • www.freelanceindy.com • www.gobroadreach.com • www.heliospartners.com • www.jiangmin.com.tw • www.kayauto.net • www.keenathomas.com • www.microsoft.com • www.mountainvalley.americanunfinished.com • www.mwa.net • www.newsesport.com • www.olmusic100.com • www.omegalogos.org • www.pastorsrest.com • www.pcs157.com • www.rbaparts.com • www.smilecare.com • www.spmiller.org • www.uszzcs.com • www.vwrm.com • www.woodagency.com • zh.lksoftvc.net #### URLs and URL-like patterns (from static analysis; may contain errors) • 2.earthsolution.org • AdobeFlash.info.tm • www.mevatec.com • Colville.com • americanunfinished.com • aoldaily.com • appspot.com • aunewsonline.com • bigdepression.net • bluecoate.com • businessformars.com • canadatvsite.com • canoedaily.com • cnndaily.com • colville.com • com.tw • competrip.com • crabdance.com • cvba.com • datastorage01.org • ddns.us • deebeedesigns.ca • dnepr.com • doversolutions.co.in • drgeorges.com • dsds.co.kr • earthsolution.org • fbrshop.com • finanstalk.ru • freelanceindy.com • gnpes.org • gobroadreach.com • happyforever.com • hojutsu.com • homier.com • ibooks.tk • info.tm • itsaol.com • jimnaugle.com • kayauto.net • keenathomas.com • lksoftvc.net • mcafeepaying.com • mediaxsds.net • microsoft.com • micyuisyahooapis.com • msnhome.org • mwa.net • newsesport.com • newsonet.net • omegalogos.org • org.ru • pastorsrest.com • pcs157.com • purpledaily.com • rbaparts.com • sektori.org • slowblog.com • smilecare.com • spmiller.org • teamattire.com • tfxdccssl.net • thecrownsgolf.org • toh.info • usnewssite.com • uszzcs.com • vwrm.com • woodagency.com • yahoodaily.com • Hojutsu.com • Colville.com • Hojutsu.com • admin.datastorage01.org • cas.ibooks.tk • conference.ddns.us • ctcs.bigdepression.net • dev.teamattire.com • fasa.arrowservice.net • fasa.newsonet.net • fni.bigish.net • japan.yahoodaily.com • jimnaugle.com • media.finanstalk.ru • meeting.toh.info • moto.purpledaily.com • moto2.earthsolution.org • news.canadatvsite.com • news.micyuisyahooapis.com • news.msnhome.org • public.ddns.us • safety.canadatvsite.com • share.canoedaily.com • thecrownsgolf.org • time.mediaxsds.net • ttl.tfxdccssl.net • un.linuxd.org • update.dnepr.com • update.sektori.org • update.slowblog.com • us.gnpes.org • wikileaks.ddns.us • www.BusinessForMars.com • www.bigish.net • www.bluecoate.com • www.competrip.com • www.cvba.com • www.deebeedesigns.ca • www.doversolutions.co.in • www.drgeorges.com • www.dsds.co.kr • www.fbrshop.com • www.freelanceindy.com • www.gobroadreach.com • www.kayauto.net • www.keenathomas.com • www.microsoft.com • www.mountainvalley.americanunfinished.com • www.mwa.net • www.omegalogos.org • www.pastorsrest.com • www.rbaparts.com • www.smilecare.com • www.spmiller.org • www.vwrm.com • www.woodagency.com • zh.lksoftvc.net • K4Pu.ht • Olmusic100.com • Sdv.gf • Sh.sd • americanunfinished.com • aoldaily.com • appspot.com • aunewsonline.com • bigdepression.net • bluecoate.com • businessformars.com • canadatvsite.com • canoedaily.com • cnndaily.com • colville.com • com.tw • competrip.com • crabdance.com • cvba.com • datastorage01.org • ddns.us • deebeedesigns.ca • dnepr.com • doversolutions.co.in • drgeorges.com • dsds.co.kr • earthsolution.org • fbrshop.com • finanstalk.ru • freelanceindy.com • gnpes.org • gobroadreach.com • happyforever.com • hojutsu.com • homier.com • ibooks.tk • info.tm • itsaol.com • jimnaugle.com • kayauto.net • keenathomas.com • lksoftvc.net • mcafeepaying.com • mediaxsds.net • microsoft.com • micyuisyahooapis.com • msnhome.org • mwa.net • newsesport.com • newsonet.net • omegalogos.org • org.ru • pastorsrest.com • pcs157.com • purpledaily.com • rbaparts.com • sektori.org • slowblog.com • smilecare.com • spmiller.org • teamattire.com • tfxdccssl.net • thecrownsgolf.org • toh.info • usnewssite.com • uszzcs.com • vwrm.com • woodagency.com • yahoodaily.com • X:\command.com • admin.datastorage01.org • adobeflash.info.tm • asa.bigish.net • aspjk07@hotmail.com • att.infosupports.com • augle.com • bigdepression.net • bluecoate.com • businessus.org • canadatvsite.com • cas.ibooks.tk • cas.m-e.org.ru • code.mcafeepaying.com • colville.com • command.com • competrip.com • conference.ddns.us • content.ie • crz.dnsweb.org • ctcs.bigdepression.net • ctcs.earthsolution.org • ctx.comrepair.net • deebeedesigns.ca • dev.teamattire.com • dns.progammerli.com • dove.blackcake.net • drgeorges.com • e.canoedaily.com • eclipsecti.infobusinessus.org • eds1.infosupports.com • erence.ddns.us • essformars.com • exactearth.info.tm • fasa.arrowservice.net • fasa.bigish.net • fasa.newsonet.net • fbrshop.com • fetch.py • flash.aoldaily.com • flash.aunewsonline.com • flash.cnndaily.com • flash.mcafeepaying.com • flash.usnewssite.com • fni.bigish.net • freelanceindy.com • gateway.messenger.hotmail.com • gobroadreach.com • gro.sepng.su • h.lk • h:mm:ss.tt • help.purpledaily.com • hint.happyforever.com • hojutsu.co • hojutsu.com • hotmail.com • safety.canadatvsite.com • www.microsoft.com • admin.datastorage01.org • adobeflash.info.tm • cas.ibooks.tk • cas.m-e.org.ru • colville.com • conference.ddns.us • dev.teamattire.com • hint.happyforever.com • hojutsu.com • japan.yahoodaily.com • jimnaugle.com • media.finanstalk.ru • meeting.toh.info • news.canadatvsite.com • news.micyuisyahooapis.com • news.msnhome.org • portal.itsaol.com • public.ddns.us • report.crabdance.com • safety.canadatvsite.com • share.canoedaily.com • sports.canoedaily.com • tcw.homier.com • thecrownsgolf.org • time.mediaxsds.net • ttl.tfxdccssl.net • update.dnepr.com • update.sektori.org • update.slowblog.com • us.gnpes.org • wikileaks.ddns.us • www.bluecoate.com • www.businessformars.com • www.competrip.com • www.cvba.com • www.deebeedesigns.ca • www.doversolutions.co.in • www.drgeorges.com • www.dsds.co.kr • www.fbrshop.com • www.freelanceindy.com • www.gobroadreach.com • www.jiangmin.com.tw • www.kayauto.net • www.keenathomas.com • www.microsoft.com • www.mountainvalley.americanunfinished.com • www.mwa.net • www.newsesport.com • www.omegalogos.org • www.pastorsrest.com • www.pcs157.com • www.rbaparts.com • www.smilecare.com • www.spmiller.org • www.uszzcs.com • www.vwrm.com • www.woodagency.com • zh.lksoftvc.net • johnford985.appspot.com/fetch.py • code.mcafeepaying.com • ctcs.bigdepression.net • flash.aoldaily.com • flash.aunewsonline.com • flash.cnndaily.com • flash.mcafeepaying.com • flash.usnewssite.com • johnford985.appspot.com • ks.cnndaily.com • moto.purpledaily.com • moto1.newsonet.net • moto2.earthsolution.org • stratos.aoldaily.com • stratos.mcafeepaying.com • ic.ddns.us • ice.net • ille.com • ily.com • ing.toh.info • japan.yahoodaily.com • jimnaugle.com • johnford985.appspot.com • k.ca • kayauto.net • keenathomas.com • ks.aoldaily.com • ks.cnndaily.com • ks.jaimeastorga.mx • ks.manguvaljak.ee • ks.petrotdl.com.ar • ks.utworld.ch • m.ms • media.finanstalk.ru • meeting.toh.info • messenger.hotmail.com • microsoft.com • micyuisyahooapis.com • moc.yliadnnc.sk • moto.purpledaily.com • moto1.newsonet.net • moto2.earthsolution.org • mountainvalley.americanunfinished.com • msn.com • msnhome.org • mwa.net • n.datastorage01.org • n.linuxd.org • n.yahoodaily.com • news.canadatvsite.com • news.micyuisyahooapis.com • news.msnhome.org • nexus.passport.com • ni.bigish.net • nic.safalife.com • ntdetect.com • olmusic100.com • omegalogos.org • owservice.ne • pastorsrest.com • portal.itsaol.com • public.ddns.us • purpledaily.com • qhun-mons.businessformars.com • qusc12.infosupports.com • rbaparts.com • report.crabdance.com • rownsgolf.org • s.org • safety.canadatvsite.com • share.canoedaily.com • smilecare.com • sonet.net • sports.canoedaily.com • sra.blackcake.net • sra.infosupports.com • ssus.org • stratos.aoldaily.com • stratos.mcafeepaying.com • tcw.homier.com • te.dnepr.com • teamattire.com • thecrownsgolf.org • time.mediaxsds.net • tsu.com • ttl.tfxdccssl.net • ty.canadatvsite.com • un.linuxd.org • update.dnepr.com • update.mcafeepaying.com • update.sektori.org • update.slowblog.com • us.gnpes.org • usc12.blackcake.net • vop.earthsolution.org • vwrm.com • w.com • us.gn • wikileaks.ddns.us • woodagency.com • ww.bigish.net • www.BusinessForMars.com • www.bigish.net • www.bluecoate.com • www.businessformars.com • www.competrip.com • www.cvba.com • www.deebeedesigns.ca • www.doversolutions.co.in • www.drgeorges.com • www.dsds.co.kr • www.fbrshop.com • www.freelanceindy.com • www.gobroadreach.com • www.heliospartners.com • www.holdent.com.au • www.inkscape.org • www.jiangmin.com.tw • www.kayauto.net • www.keenathomas.com • www.microsoft.com • www.mountainvalley.americanunfinished.com • www.mwa.ne • www.mwa.net • www.newsesport.com • www.olmusic100.com • www.omegalogos.org • www.pastorsrest.com • www.pcs157.com • www.rbaparts.com • www.smilecare.com • www.spmiller.org • www.uszzcs.com • www.vwrm.com • www.woodagency.com • zh.lksoftvc.net #### HTTP Requests: • CONNECT HTTP/1.0 • CONNECT /index.asp HTTP/1.1 • GET HTTP/1.1 • GET /1.asp?rands=FXMJVXGOJJ&acc=&str=select id from tab_online where regcode = ‘FXMJVXGOJJ’ HTTP/1.0 • GET /197.1.16.3_7.html HTTP/1.1 • GET /2011/n325423.shtml?pvid=fAAAACIkAOyJMGjxiYadwRyN9buY2MAeOtQPGgD7e0CsZAFTwA8txDliAAA= HTTP/1.0 • GET /2651.asp HTTP/1.1 • GET /3491.asp HTTP/1.1 • GET /4823.asp HTTP/1.1 • GET /4981.asp HTTP/1.1 • GET /5310.asp HTTP/1.1 • GET /5712.html HTTP/1.1 • GET /6212.html HTTP/1.1 • GET /6958.html HTTP/1.1 • GET /_borders/top.htm HTTP/1.1 • GET /A2/front/lm/mini/noborder/?AQB=1&ndh=1&t=480&lv=VDipXNKF&pageName=About&ss=ipWHkqSl&g=Council&cid=225&v1=c25&hp=N&tal=&AQE=1 HTTP/1.0 • GET /aboutus_ohs.html HTTP/1.1 • GET /adobe.html HTTP/1.1 • GET /api/get_attention_num/adfshow?slot=7cLLvm4e&p=F&may=128&g=4363&n=0&i=Home HTTP/1.0 • GET /aspnet_client/system_web/1_0_3705_0/SmartNav.jpg HTTP/1.1 • GET /attachments/C262-240.jpg HTTP/1.1 • GET /bbs/db/1.asp?rands=KKIJLONGAP&acc=&str=select id from tab_online where regcode = ‘KKIJLONGAP’ order by id asc HTTP/1.0 • GET /bbs/db/1.asp?rands=SEXGJLSSXM&acc=&str=select id from tab_online where regcode = ‘SEXGJLSSXM’ order by id asc HTTP/1.0 • GET /BerwickFire/rental.html HTTP/1.1 • GET /css/about.htm HTTP/1.1 • GET /css/style.html HTTP/1.1 • GET /Default.aspx?INDEX=CGPEHQURTR HTTP/1.1 • GET /Default.aspx?INDEX=EIGHIZHOMM HTTP/1.1 • GET /Default.aspx?INDEX=EYZALCJEKE HTTP/1.1 • GET /Default.aspx?INDEX=GIOJJREGBY HTTP/1.1 • GET /Default.aspx?INDEX=IHPSYRANKA HTTP/1.1 • GET /Default.aspx?INDEX=IPESEDUTED HTTP/1.1 • GET /Default.aspx?INDEX=JBVUQETDVA HTTP/1.1 • GET /Default.aspx?INDEX=MAJVUXJDAQ HTTP/1.1 • GET /Default.aspx?INDEX=QFBMPJCWAL HTTP/1.1 • GET /Default.aspx?INDEX=XMDOFYNHDY HTTP/1.1 • GET /default.htm HTTP/1.1 • GET /default.html HTTP/1.1 • GET /download.htm HTTP/1.1 • GET /download/confere.html HTTP/1.1 • GET /download/device_ad.asp?device_t=2928269924&key=dxrqdgct&device_id=ad&cv=dxrqdgctnynmgjjfn HTTP/1.0 • GET /downloadsoft.htm HTTP/1.1 • GET /fax.html HTTP/1.1 • GET /file/yahootemp.html HTTP/1.1 • GET /Gallery/Winterfest/2.jpg HTTP/1.1 • GET /html/proe_tcp.html HTTP/1.1 • GET /images/1.asp?rands=HOWBTFQLOZ&acc=&str=select id from tab_online where regcode = ‘HOWBTFQLOZ’ order by id asc HTTP/1.0 • GET /images/_vti_img/index.asp HTTP/1.1 • GET /images/bs.gif HTTP/1.1 • GET /images/btn_info.jpg HTTP/1.1 • GET /images/button.jpg HTTP/1.1 • GET /images/colt_defense.jpg HTTP/1.1 • GET /images/db/1.asp?rands=BWFIMNAJEE&acc=&str=select id from tab_online where regcode = ‘BWFIMNAJEE’ order by id asc HTTP/1.0 • GET /images/device_index.asp?device_t=5962704463&key=odnnmvgr&device_id=index&cv=odnnmvgrmftvujsyg HTTP/1.0 • GET /images/error.jpg HTTP/1.1 • GET /images/head_left.jpg HTTP/1.1 • GET /images/icons/3224?meth=gc&tid=2005614&cqe=3884550&inif=tLu3v8eD3Lu+vqjHy8PI1MvMwtTCytTLycnct7uosceUkZzXgNy1qarHz9TL3LK+qbTHy8+fnw==&syun=250 HTTP/1.1 • GET /images/index_0_02.jpg HTTP/1.1 • GET /images/leftnav_prog_bg.jpg HTTP/1.1 • GET /images/li.gif HTTP/1.1 • GET /images/logo.png HTTP/1.1 • GET /images/reach1.jpg HTTP/1.1 • GET /images/record.asp?device_t=3134688572&key=ywbyftdd&device_id=index&cv=ywbyftddoirafvbak&result=no%20command%0D%0A%0D%0ANext%3ASun%20Feb%2024%2009%3A50%3A15%202013%0Adelay%3A3600%20sec%0D%0A HTTP/1.0 • GET /images/title.png HTTP/1.1 • GET /index.htm HTTP/1.1 • GET /index.html HTTP/1.1 • GET /index.html HTTP/1.1 • GET /index/default.htm HTTP/1.1 • GET /index01.htm HTTP/1.1 • GET /info/2013.html?1361695580 HTTP/1.0 • GET /info/2013.html?1361695600 HTTP/1.0 • GET /info/sh1/search.asp HTTP/1.1 • GET /info/sh3/search.asp HTTP/1.1 • GET /java/careers.html HTTP/1.1 • GET /loa/database3/sun.html?a=1317&b=10043&typ=ntWVDtQM&user=home_page|homepage_2nd_banner_820x90&pagei=/8LfwOjw&border=0&local=yes&psi=170&f=1&form=&h=&i=100 HTTP/1.0 • GET /logo.html HTTP/1.1 • GET /logs/login.asp HTTP/1.1 • GET /M&A_alliances.htm HTTP/1.1 • GET /main/1.asp?rands=TGPJQNYBQY&acc=&str=select id from tab_online where regcode = ‘TGPJQNYBQY’ order by id asc HTTP/1.0 • GET /marq.htm HTTP/1.1 • GET /NET/kappa.jpg HTTP/1.1 • GET /order.htm HTTP/1.1 • GET /Ouo4f045.asp HTTP/1.1 • GET /pop.htm HTTP/1.1 • GET /postinfo.html?1361694906 HTTP/1.0 • GET /postinfo.html HTTP/1.1 • GET /pp/core/cgi/wor.asp?category=qiu&ace=i9t2&newText=&amer=160&eur=&mm=love HTTP/1.0 • GET /public.html HTTP/1.1 • GET /report/news.html HTTP/1.1 • GET /Resource/device_Tr.asp?device_t=1626586307&key=wuagysqk&device_id=Tr&cv=wuagysqkptijnsayv HTTP/1.0 • GET /Resource/record.asp?device_t=2620185844&key=majccsyr&device_id=Tr&cv=majccsyrufwyqrdkg&result=no%20command%0D%0A%0D%0ANext%3ASun%20Feb%2024%2009%3A57%3A53%202013%0Adelay%3A3600%20sec%0D%0A HTTP/1.0 • GET /Rossini.jpg HTTP/1.1 • GET /s/asp?XAAAANoRA_U9K_o8YmGncEcjfW7mNjAHjrUDxoA8sgB_SAA=p=1 HTTP/1.0 • GET /safe/1.asp?rands=LYWWLWYPSW&acc=&str=select id from tab_online where regcode = ‘LYWWLWYPSW’ order by id asc HTTP/1.0 • GET /saler.gif HTTP/1.1 • GET /staff.htm HTTP/1.1 • GET /study.htm HTTP/1.1 • GET /sun/moto.htm HTTP/1.1 • GET /top.htm HTTP/1.1 • GET /uc/myshow/blog/misc/gif/show.asp?a=mmRCP0L&p=2Fregion2F&u=n5vh8rmrnlopo1ec&b=vY6HjJ2C&n=0&c=233&x=400&y=4153&e=&wt=30q00dn00ei76hc9 HTTP/1.0 • GET /update.jpg HTTP/1.1 • GET /update.jpg HTTP/1.1 • GET /update.png HTTP/1.1 • GET /uwire/index.html HTTP/1.1 • GET /windows.html HTTP/1.1 • GET /word/display.asp HTTP/1.1 • GET /worlda.html HTTP/1.1 • GET /worldb.html HTTP/1.1 • GET /Y/ HTTP/1.1 • GET Default.asp HTTP/1.1 • GET Default.asp?uid=86893&do=friend&view=41&_lgmode=pri&from=bkT7i2 HTTP/1.1 • GET Default.asp?uid=86893&do=friend&view=toms HTTP/1.1 • GET index.html HTTP/1.1 • GET HTTP/1.1 • POST /fetch.py HTTP/1.1 • POST 404error.asp HTTP/1.1 • POST aspnet_client/report.asp HTTP/1.1 • POST aspnet_client/system_web/1_0_3705_0/addCats.asp HTTP/1.1 • POST index.asp HTTP/1.1 #### User Agents: • 08:52:09+[HOSTNAME] • 08:52:27+[HOSTNAME] • 10:03:44+[HOSTNAME] • 10:04:02+[HOSTNAME] • 5.1 04:15 [HOSTNAME]\[USERNAME] • 5.1 04:19 [HOSTNAME]\[USERNAME] • 5.1 04:45 [HOSTNAME]\[USERNAME] • 5.1 04:46 [HOSTNAME]\[USERNAME] • 5.1 04:47 [HOSTNAME]\[USERNAME] • 5.1 07:43 [HOSTNAME]\[USERNAME] • 5.1 09:35 [HOSTNAME]\[USERNAME] • 5.1 09:36 [HOSTNAME]\[USERNAME] • 5.1 09:38 [HOSTNAME]\[USERNAME] • 5.1 09:39 [HOSTNAME]\[USERNAME] • Google+page • HTTP 1.1 • HTTP Mozilla/5.0(compatible+MSIE • IPHONE8.5(host:[HOSTNAME],ip:[IP] • IPHONE8.5(host:[HOSTNAME],ip:[IP]ct:Sun Feb 24 08:46:20 2013 • IPHONE8.5(host:[HOSTNAME],ip:[IP]ct:Sun Feb 24 08:46:40 2013 • Internet SurfBear • Microsoft Internet Explorer 6.0 • Microsoft Internet Explorer Exelon [HOSTNAME] • Mozilla/4.0 (compatible; • Mozilla/4.0 (compatible; MSIE 6.0; Win32 • Mozilla/4.0 (compatible; MSIE 6.0; Win32–[HOSTNAME] • Mozilla/4.0 (compatible; MSIE 6.0; Win32; • Mozilla/4.0 (compatible; MSIE 6.0; Win32;Ali; • Mozilla/4.0 (compatible; MSIE 6.0; Win32;Fly; • Mozilla/4.0 (compatible; MSIE 6.0; Win32;Google; • Mozilla/4.0 (compatible; MSIE 6.0; Windows NT 5.1 • Mozilla/4.0 (compatible; MSIE 6.0; Windows NT 5.1; SV1 • Mozilla/4.0 (compatible; MSIE 6.0; Windows NT 5.1; SV1; .NET CLR 2.0.50727; .NET CLR 3.0.04506.648; .NET CLR 3.5.21022; .NET CLR 3.0.4506.2152; .NET CLR 3.5.30729 • Mozilla/4.0 (compatible; MSIE 6.0; Windows NT 5.1; SV1; .NET4.0C; .NET4.0E; .NET CLR 2.0.50727; .NET CLR 3.0.04506.648; .NET CLR 3.5.21022; .NET CLR 3.0.4506.2152; .NET CLR 3.5.30729 • Mozilla/4.0 (compatible; MSIE 6.0; Windows NT 5.1; SV1; EmbeddedWB 14.52 from • Mozilla/4.0 (compatible; MSIE 6.0; Windows NT 5.2; SV1; .NET CLR 1.1.4322; .NET CLR 2.0.50727 • Mozilla/4.0 (compatible; MSIE 6.1; Windows NT 5.1; SV1 • Mozilla/4.0 (compatible; MSIE 8.0; Win32 • Mozilla/4.0 (compatible; MSIE 8.0; Windows NT 5.1; Trident/4.0 • Mozilla/4.0 (compatible; MSIE 8.0; Windows NT 5.1; Trident/4.0; .NET CLR 2.0.50727; .NET CLR 3.0.4506.2152; .NET CLR 3.5.30729 • Mozilla/4.0 (compatible; MSIE 8.0; Windows NT 5.1; Trident/4.0; Cxdp.BMWCN • Mozilla/4.0 (compatible; MSIE 8.0; Windows NT 5.1; Trident/4.0; Cxdp.BMWUS • Mozilla/4.0 (compatible; MSIE 8.0; Windows NT 5.1; Trident/4.0; Cxdp.NSF • Mozilla/4.0 (compatible; MSIE 8.0; Windows NT 5.1; [HOSTNAME];Trident/4.004:48 • Mozilla/4.0 (compatible; MSIE 8.0; Windows NT 5.1; [HOSTNAME];Trident/4.008:36 • Mozilla/4.0 (compatible; MSIE 8.0; Windows NT 5.1; [HOSTNAME];Trident/4.008:37 • Mozilla/4.0 (compatible; MSIE 8.0; Windows NT 5.1; [HOSTNAME];Trident/4.008:47 • Mozilla/4.0 (compatible; MSIE 8.0; Windows NT 5.1; [HOSTNAME];Trident/4.008:48 • Mozilla/4.0 (compatible; MSIE 8.0; Windows NT 5.1; [HOSTNAME];Trident/4.009:07 • Mozilla/4.0 (compatible; MSIE 8.0; Windows NT 5.1; [HOSTNAME];Trident/4.009:13 • Mozilla/4.0 (compatible; MSIE 8.0; Windows NT 5.1; [HOSTNAME];Trident/4.009:27 • Mozilla/4.0 (compatible; MSIE 8.0; Windows NT 5.1; [HOSTNAME];Trident/4.009:50 • Mozilla/4.0 (compatible; MSIE 8.0; Windows NT 5.1; [HOSTNAME];Trident/4.010:19 • Mozilla/4.0 (compatible; MSIE 8.0; Windows NT 6.1; Trident/4.0; SLCC2; .NET CLR 2.0.50727; .NET CLR 3.5.30729; .NET CLR 3.0.30729; Media Center PC 6.0 • Mozilla/4.0 (compatible; MSIE7.0; Windows NT 5.1 • Mozilla/4.0 (compatible; Windows NT 5.1; MSIE 7.0 • Mozilla/4.0 • Mozilla/5.0 (compatible; MSIE 7.1; Windows NT 5.1; SV1 • Mozilla/5.0 (compatible; MSIE 8.0; Win32 • Mozilla/5.0 • Win32 • [HOSTNAME]+Mozilla/4.0 (compatible; MSIE 8.0; Win32 • [HOSTNAME] • yahoo html #### Delays in ms • 100 • 1000 • 2000 • 3000 • 4000 • 5000 • 6000 • 10000 • 30000 • 60000 • 100000 • 120000 • 127000 • 300000 • 600000 • 900000 • 1500000 • 1620000 • 174000 • 1740000 • 1800000 • 2100000 #### Compilation timestamps: • 2001-07-17 00:22:56 Tuesday 995329376 • 2003-08-06 18:34:23 Wednesday 1060194863 • 2003-10-16 03:41:02 Thursday 1066275662 • 2004-01-23 23:39:42 Friday 1074901182 • 2004-05-15 01:06:23 Saturday 1084583183 • 2004-07-07 02:17:12 Wednesday 1089166632 • 2004-08-04 06:02:53 Wednesday 1091599373 • 2004-08-04 06:10:04 Wednesday 1091599804 • 2004-08-04 06:14:22 Wednesday 1091600062 • 2004-08-04 06:14:38 Wednesday 1091600078 • 2004-08-04 07:56:01 Wednesday 1091606161 • 2004-08-04 07:56:07 Wednesday 1091606167 • 2004-08-04 07:56:21 Wednesday 1091606181 • 2004-08-04 07:56:23 Wednesday 1091606183 • 2004-08-04 07:56:26 Wednesday 1091606186 • 2004-08-04 07:56:30 Wednesday 1091606190 • 2004-08-04 07:56:36 Wednesday 1091606196 • 2004-08-04 07:56:37 Wednesday 1091606197 • 2004-08-04 07:56:39 Wednesday 1091606199 • 2004-08-04 07:56:40 Wednesday 1091606200 • 2004-08-04 07:56:42 Wednesday 1091606202 • 2004-08-04 07:56:44 Wednesday 1091606204 • 2004-08-04 07:56:58 Wednesday 1091606218 • 2004-08-04 07:57:08 Wednesday 1091606228 • 2004-08-04 07:57:38 Wednesday 1091606258 • 2004-08-04 07:59:14 Wednesday 1091606354 • 2006-08-03 12:45:02 Thursday 1154609102 • 2006-09-13 18:20:18 Wednesday 1158171618 • 2006-09-14 02:28:46 Thursday 1158200926 • 2007-06-29 15:18:22 Friday 1183130302 • 2007-07-25 17:44:33 Wednesday 1185385473 • 2007-08-08 03:16:50 Wednesday 1186543010 • 2007-09-17 09:21:03 Monday 1190020863 • 2007-11-18 23:50:13 Sunday 1195429813 • 2008-03-12 12:39:30 Wednesday 1205325570 • 2008-04-13 19:14:55 Sunday 1208114095 • 2008-06-17 01:20:04 Tuesday 1213665604 • 2008-07-30 03:25:13 Wednesday 1217388313 • 2008-08-22 00:43:16 Friday 1219365796 • 2008-08-27 08:41:19 Wednesday 1219826479 • 2008-09-16 08:40:03 Tuesday 1221554403 • 2008-09-16 08:42:05 Tuesday 1221554525 • 2008-09-16 09:20:31 Tuesday 1221556831 • 2008-10-22 00:12:21 Wednesday 1224634341 • 2008-10-27 02:18:16 Monday 1225073896 • 2008-10-27 08:31:43 Monday 1225096303 • 2008-10-27 13:48:37 Monday 1225115317 • 2008-11-10 08:29:48 Monday 1226305788 • 2008-11-10 08:30:00 Monday 1226305800 • 2008-11-21 07:46:32 Friday 1227253592 • 2009-01-07 08:09:33 Wednesday 1231315773 • 2009-01-15 03:30:11 Thursday 1231990211 • 2009-02-05 07:14:01 Thursday 1233818041 • 2009-02-05 07:16:28 Thursday 1233818188 • 2009-02-05 07:20:22 Thursday 1233818422 • 2009-02-17 09:40:38 Tuesday 1234863638 • 2009-03-02 09:52:20 Monday 1235987540 • 2009-03-06 14:10:18 Friday 1236348618 • 2009-03-16 13:30:51 Monday 1237210251 • 2009-03-17 03:34:24 Tuesday 1237260864 • 2009-03-17 13:21:25 Tuesday 1237296085 • 2009-03-25 13:11:56 Wednesday 1237986716 • 2009-04-12 09:14:38 Sunday 1239527678 • 2009-05-14 17:12:40 Thursday 1242321160 • 2009-05-26 07:37:57 Tuesday 1243323477 • 2009-06-08 10:17:38 Monday 1244456258 • 2009-07-08 13:30:46 Wednesday 1247059846 • 2009-07-16 15:04:29 Thursday 1247756669 • 2009-07-20 08:33:01 Monday 1248078781 • 2009-07-20 09:02:46 Monday 1248080566 • 2009-07-25 03:44:04 Saturday 1248493444 • 2009-07-29 14:34:24 Wednesday 1248878064 • 2009-07-30 09:20:04 Thursday 1248945604 • 2009-08-03 08:29:29 Monday 1249288169 • 2009-08-11 08:38:40 Tuesday 1249979920 • 2009-08-16 11:05:43 Sunday 1250420743 • 2009-08-24 13:16:23 Monday 1251119783 • 2009-08-28 02:17:30 Friday 1251425850 • 2009-11-11 06:33:02 Wednesday 1257921182 • 2009-11-17 22:13:19 Tuesday 1258495999 • 2009-12-01 00:40:09 Tuesday 1259628009 • 2009-12-21 01:39:02 Monday 1261359542 • 2010-01-15 17:20:56 Friday 1263576056 • 2010-02-03 08:22:33 Wednesday 1265185353 • 2010-02-03 08:22:50 Wednesday 1265185370 • 2010-02-09 08:29:43 Tuesday 1265704183 • 2010-02-11 03:27:04 Thursday 1265858824 • 2010-02-11 06:44:46 Thursday 1265870686 • 2010-02-25 00:49:53 Thursday 1267058993 • 2010-03-15 06:27:58 Monday 1268634478 • 2010-04-12 09:09:29 Monday 1271063369 • 2010-04-14 17:18:20 Wednesday 1271265500 • 2010-04-20 03:39:27 Tuesday 1271734767 • 2010-04-23 07:51:28 Friday 1272009088 • 2010-05-20 07:01:21 Thursday 1274338881 • 2010-06-23 01:24:31 Wednesday 1277256271 • 2010-06-25 09:26:47 Friday 1277458007 • 2010-06-29 00:31:41 Tuesday 1277771501 • 2010-08-23 02:17:20 Monday 1282529840 • 2010-09-19 08:34:11 Sunday 1284885251 • 2010-09-27 02:06:31 Monday 1285553191 • 2010-09-28 01:00:25 Tuesday 1285635625 • 2010-09-28 08:09:41 Tuesday 1285661381 • 2010-10-19 08:15:54 Tuesday 1287476154 • 2010-10-21 06:51:09 Thursday 1287643869 • 2010-10-29 06:50:40 Friday 1288335040 • 2010-10-29 06:51:08 Friday 1288335068 • 2010-11-02 08:35:56 Tuesday 1288686956 • 2010-11-04 06:07:11 Thursday 1288850831 • 2010-11-06 08:08:37 Saturday 1289030917 • 2010-11-17 13:37:00 Wednesday 1290001020 • 2010-11-18 01:54:57 Thursday 1290045297 • 2010-12-02 08:05:26 Thursday 1291277126 • 2010-12-16 03:14:07 Thursday 1292469247 • 2010-12-16 03:16:48 Thursday 1292469408 • 2010-12-18 08:10:11 Saturday 1292659811 • 2010-12-22 08:02:25 Wednesday 1293004945 • 2011-01-11 02:12:48 Tuesday 1294711968 • 2011-01-11 02:24:30 Tuesday 1294712670 • 2011-01-11 03:22:02 Tuesday 1294716122 • 2011-03-02 07:40:24 Wednesday 1299051624 • 2011-03-03 13:41:14 Thursday 1299159674 • 2011-03-07 09:42:59 Monday 1299490979 • 2011-03-08 02:36:50 Tuesday 1299551810 • 2011-03-16 19:26:23 Wednesday 1300303583 • 2011-03-22 12:59:55 Tuesday 1300798795 • 2011-03-23 14:34:10 Wednesday 1300890850 • 2011-03-23 14:36:19 Wednesday 1300890979 • 2011-03-28 13:35:35 Monday 1301319335 • 2011-03-29 08:40:16 Tuesday 1301388016 • 2011-04-02 09:07:51 Saturday 1301735271 • 2011-04-08 08:04:50 Friday 1302249890 • 2011-04-20 13:13:08 Wednesday 1303305188 • 2011-04-21 07:16:51 Thursday 1303370211 • 2011-04-21 07:51:21 Thursday 1303372281 • 2011-04-26 01:53:58 Tuesday 1303782838 • 2011-04-28 01:22:03 Thursday 1303953723 • 2011-05-17 07:45:35 Tuesday 1305618335 • 2011-05-17 12:37:22 Tuesday 1305635842 • 2011-05-20 01:14:53 Friday 1305854093 • 2011-05-30 08:29:29 Monday 1306744169 • 2011-06-28 22:39:19 Tuesday 1309300759 • 2011-07-11 03:38:22 Monday 1310355502 • 2011-07-18 03:10:56 Monday 1310958656 • 2011-07-19 01:55:13 Tuesday 1311040513 • 2011-07-28 04:50:57 Thursday 1311828657 • 2011-07-28 14:49:46 Thursday 1311864586 • 2011-07-29 07:10:31 Friday 1311923431 • 2011-08-09 08:15:29 Tuesday 1312877729 • 2011-08-11 13:15:49 Thursday 1313068549 • 2011-08-19 02:34:16 Friday 1313721256 • 2011-08-19 03:07:37 Friday 1313723257 • 2011-09-20 03:40:51 Tuesday 1316490051 • 2011-09-20 03:50:48 Tuesday 1316490648 • 2011-09-25 13:42:51 Sunday 1316958171 • 2011-09-25 13:43:28 Sunday 1316958208 • 2011-09-27 13:07:55 Tuesday 1317128875 • 2011-09-27 13:09:16 Tuesday 1317128956 • 2011-10-10 14:16:57 Monday 1318256217 • 2011-10-11 13:02:38 Tuesday 1318338158 • 2011-10-12 01:58:10 Wednesday 1318384690 • 2011-10-13 08:47:13 Thursday 1318495633 • 2011-10-14 08:42:16 Friday 1318581736 • 2011-10-14 11:58:04 Friday 1318593484 • 2011-10-18 00:58:17 Tuesday 1318899497 • 2011-10-19 09:16:10 Wednesday 1319015770 • 2011-10-19 09:17:10 Wednesday 1319015830 • 2011-10-19 09:19:09 Wednesday 1319015949 • 2011-10-24 08:19:05 Monday 1319444345 • 2011-11-01 02:43:26 Tuesday 1320115406 • 2011-11-05 09:27:34 Saturday 1320485254 • 2011-11-07 14:59:20 Monday 1320677960 • 2011-11-17 07:22:44 Thursday 1321514564 • 2011-11-21 12:36:14 Monday 1321878974 • 2011-11-21 12:36:51 Monday 1321879011 • 2011-11-22 01:15:22 Tuesday 1321924522 • 2011-11-28 12:32:07 Monday 1322483527 • 2011-12-12 03:28:15 Monday 1323660495 • 2011-12-20 02:23:38 Tuesday 1324347818 • 2012-01-19 00:50:11 Thursday 1326934211 • 2012-01-20 03:14:28 Friday 1327029268 • 2012-02-09 00:47:28 Thursday 1328748448 • 2012-02-09 00:47:52 Thursday 1328748472 • 2012-02-16 08:22:06 Thursday 1329380526 • 2012-02-17 14:55:21 Friday 1329490521 • 2012-02-23 07:20:31 Thursday 1329981631 • 2012-02-28 11:48:43 Tuesday 1330429723 • 2012-02-28 15:35:51 Tuesday 1330443351 • 2012-03-02 06:27:21 Friday 1330669641 • 2012-03-02 07:20:27 Friday 1330672827 • 2012-03-02 08:45:11 Friday 1330677911 • 2012-03-07 08:41:30 Wednesday 1331109690 • 2012-03-12 01:34:56 Monday 1331516096 • 2012-03-13 02:21:54 Tuesday 1331605314 • 2012-03-13 03:47:57 Tuesday 1331610477 • 2012-03-16 07:10:50 Friday 1331881850 • 2012-03-20 09:24:33 Tuesday 1332235473 • 2012-03-22 08:45:38 Thursday 1332405938 • 2012-03-28 15:39:00 Wednesday 1332949140 • 2012-04-12 15:02:26 Thursday 1334242946 • 2012-04-17 08:29:00 Tuesday 1334651340 • 2012-04-17 08:30:01 Tuesday 1334651401 • 2012-04-17 09:32:54 Tuesday 1334655174 • 2012-04-24 08:24:45 Tuesday 1335255885 • 2012-05-07 03:19:17 Monday 1336360757 • 2012-05-14 14:16:53 Monday 1337005013 • 2012-05-28 08:12:40 Monday 1338192760 • 2012-05-29 14:39:47 Tuesday 1338302387 • 2012-06-04 12:57:35 Monday 1338814655 • 2012-06-09 13:19:49 Saturday 1339247989 • 2012-06-09 13:19:53 Saturday 1339247993 • 2012-06-11 12:37:20 Monday 1339418240 • 2012-06-26 03:30:05 Tuesday 1340681405 • 2012-08-08 23:27:53 Wednesday 1344468473 • 2012-08-10 02:10:53 Friday 1344564653 • 2012-08-16 07:53:11 Thursday 1345103591 • 2012-08-20 12:56:12 Monday 1345467372 • 2012-08-20 12:59:08 Monday 1345467548 • 2012-08-20 14:06:56 Monday 1345471616 • 2012-08-20 15:16:12 Monday 1345475772 • 2012-08-21 13:46:15 Tuesday 1345556775 • 2012-08-22 15:50:16 Wednesday 1345650616 • 2012-08-28 07:34:32 Tuesday 1346139272 • 2012-08-28 13:40:13 Tuesday 1346161213 • 2012-08-30 13:06:09 Thursday 1346331969 • 2012-09-06 15:34:30 Thursday 1346945670 • 2012-09-10 14:25:34 Monday 1347287134 • 2012-11-07 14:12:48 Wednesday 1352297568 • 2012-11-13 14:55:39 Tuesday 1352818539 • 2012-11-14 07:58:27 Wednesday 1352879907 • 2012-11-16 07:35:22 Friday 1353051322 • 2012-12-06 13:09:40 Thursday 1354799380 • 2012-12-25 13:07:50 Tuesday 1356440870 ### The sampleset – clustering Quite frankly, there is not so much to write about it here. I do not find obvious distribution or significant spikes of specific patterns and the results are not very presentable – to provide a few specific examples – out of 285 samples: The following samples use DES: • 0CF9E999C574EC89595263446978DC9F • 24259AE8B0018B0CE9992FB1D9B69E2A • 468FF2C12CFFC7E5B2FE0EE6BB3B239E • 476FEA8761A03BEF16E322996C2F6666 • 7AECB34616245EB6B2906358151BE55B • 7F1A4BC267ACE340A5AA7A0B79CBF349 • 8E8622C393D7E832D39E620EAD5D3B49 • 929802A27737CEBC59D19DA724FDF30A • C04C796EF126AD7429BE7D55720FE392 • CF9C2D5A8FBDD1C5ADC20CFC5E663C21 • D0D5A20C5A6C4FDDAB4D43B85632B6A9 • D34E357461C55D90C52309C1FF952B4C • DD21D1EA2146861A4219B1CBDAEFE59B The following files run runinfo.exe: • 09531F851EF74A7238685FD287A395BD • 0CA6E2AD69826C8E3287FC8576112814 • C3E5603A38E700274D1AB30CE93D08B9 The following samples use mutex !@ADS@#$

• 6B3D19CC86D82B06F5DB3AE9D5BA8A5F
• 831A67DC75E2D4505180888747BC8EA9

The following samples connect to 69.28.168.10:443

• 1F2EB7B090018D975E6D9B40868C94CA
• D9FBF759F527AF373E34673DC3ACA462

The conclusion?

Diplomatically speaking – my clustering efforts are far from being actionable at this stage .

Sandboxing samples provides a good data for toying around, but w/o some normalization of this data and w/o ability to establish links between smaller clusters, it’s hard to draw any significant conclusion.

## HMFT 0.3 + Extended Attributes, short update

February 17, 2013 in Anti-Forensics, Compromise Detection, Forensic Analysis, HMFT, Malware Analysis

update

fixed the title of the post  – it’s obviously a version 0.3 and not 3.0

old post

In my last post I talked about detecting Extended Attributes (used by ZeroAccess malware) using HMFT.  Today I got a chance to update it a bit with some more information.

First of all, I clustered some of the ZeroAccess samples I had and I came up with a list of comprehensive (of course it’s limited by a sampleset I have) file locations and their Extended Attributes that are used by the malware:

• %SYSTEMROOT%\system32\services.exe::731
• %USERPROFILE%\appdata\local\a4ca9b9c\u::@@@
• %SYSTEMROOT%\$NtUninstallKB16214$\2764741532\U::CFG

You can find a full list of samples using EAs together with hashes (md5_sha1) here.

Secondly, I added some code to HMFT and now it can dump Extended Attribute’s name (and some printable content of the EA value) as well:

   RESIDENT ATTRIBUTE
AttributeTypeIdentifierD = 224
LengthOfAttributeD       = 40
NonResidentFlagB         = 0
LengthOfNameB            = 0
OffsetToNameW            = 0
FlagsW                   = 0
AttributeIdentifierW     = 4
--
SizeOfContentD          = 16
OffsetToContentW        = 24
--
MFTA_EA
FlagsB          = 0
EaNameLenB      = 3
EaValueLenW     = 3
EaName = FOO
EaValue= bar

Using newer version of HMFT on one of the ZeroAccess samples gives the following result after postprocessing with eads.pl script:

use strict;
my $f=''; my$l='';
while (<>)
{
s/[\r\n]+//g;
$f =$1 if /FileName = (.+)$/; print "$f has $1 record\n" if ($l =~ /(MFTA_EA(_[A-Z]+)?)/);
print "$f:".":$1\n" if (/EaName = (.+)$/); print "$f:$1\n" if ($l =~ /MFTA_DATA/&&/AttributeName = (.+)$/);$l = $_; } Btw. if you look at the screenshot above you will notice :SummaryInformation ADS used by this sample (5D23ACF4C2221B687BC96A2701786C13/ AB7EEC68F9438E31523D0A67E7612CA666C8F56A) as well – it can be even better seen in the window of Process Monitor during the malware installation: In terms of APIs used by ZeroAccess to create EAs, I finally came across a few samples that use ZwSetEaFile to do so,. Interestingly. none of the samples used this API to create EA for services.exe – all the samples using this API create the following EA: • %USERPROFILE%\appdata\local\a4ca9b9c\u::@@@ (Please refer to the older post for more information about the context of this discussion.) You can download latest hmft here. ## Detecting Extended Attributes (ZeroAccess) and other Frankenstein’s Monsters with HMFT January 25, 2013 in Anti-Forensics, Compromise Detection, Forensic Analysis, HMFT, Malware Analysis The topic of Extended Attributes (EA) has been recently covered in an excellent post by Corey. Entitled Extracting ZeroAccess from NTFS Extended Attributes it goes into (amazing) depth explaining on what EA is and how to extract this artifact from the system. It’s a pure forensic gold and if you haven’t read this post yet, please go ahead and do so before reading mine. Similarly to Corey, I was very interested in researching EA, and I finally took some time tonight to have a deeper look at it myself. I actually wanted to dig in the code more than the$MFT artifacts alone not only to have something to write about (after all, Corey already covered everything! ), but also because I wanted to see how the EA is actually created and what system functions/APIs are used by malware. The reason behind this curiosity was improvement of my analysis tools and techniques, and a few other ideas that I will be quiet about for the moment.

I first assumed that the ZeroAccess’ EAs are created using ZwSetEaFile/NtSetEaFile function from ntdll.dll. I saw this API name popping up on some blogs and I saw it being referenced in my ZeroAccess memory/file dumps so it was a natural ‘breakpoint’ choice for OllyDbg analysis:

To my surprise, none of the samples I checked used this function at all!

Curious, I started digging into it a bit more and realized that for the samples I looked at, the EAs are actually created not by  ZwSetEaFile/NtSetEaFile function, but by ZwCreateFile/NtCreateFile.

Surprised?

I was!

Looking at a documentation, you can see the following function parameters described on MSDN:

NTSTATUS NtCreateFile(
_Out_     PHANDLE FileHandle,
_In_      POBJECT_ATTRIBUTES ObjectAttributes,
_Out_     PIO_STATUS_BLOCK IoStatusBlock,
_In_opt_  PLARGE_INTEGER AllocationSize,
_In_      ULONG FileAttributes,
_In_      ULONG ShareAccess,
_In_      ULONG CreateDisposition,
_In_      ULONG CreateOptions,
_In_      PVOID EaBuffer,
_In_      ULONG EaLength
);

Yes, it’s that simple.

One thing to note – the EA is added to files on both windows XP and Windows 7, but only under Windows 7 I observed the modification of services.exe. On Windows XP, it only appended EA to the  ‘U’ file and nothing else.

Okay, I mentioned I had a couple of ideas why I wanted to research this feature. Now it’s time to reveal them!

### Idea #1 – POC

Once I found out what APIs are being used by the malware, I was also able to produce a simple snippet of code that reproduces the functionality:

.586
.MODEL FLAT,STDCALL

o equ OFFSET
include    windows.inc
include    kernel32.inc
includelib kernel32.lib
include    ntdll.inc
includelib ntdll.lib
include    masm32.inc
includelib masm32.lib

IO_STATUS_BLOCK STRUCT
union
Status        dd ?
Pointer        dd ?
ends
Information    dd ?
IO_STATUS_BLOCK ENDS

.data?
file db 256 dup (?)
fa   db 256 dup (?)
_FILE_FULL_EA_INFORMATION struct
NextEntryOffset dd ?
Flags           db ?
EaNameLength    db ?
EaValueLength   dw ?
EaName          db ?
_FILE_FULL_EA_INFORMATION ends
FEA equ _FILE_FULL_EA_INFORMATION
io IO_STATUS_BLOCK <>
.code
Start:
invoke GetCL,1, o file
lea    edi,[fa+_FILE_FULL_EA_INFORMATION.EaName]
invoke GetCL,2, edi
invoke lstrlenA,edi
lea    esi,[fa+_FILE_FULL_EA_INFORMATION.EaNameLength]
mov    [esi],al
inc    edi
invoke GetCL,3, edi
invoke lstrlenA,edi
lea    esi,[fa+_FILE_FULL_EA_INFORMATION.EaValueLength]
mov    [esi],al
invoke CreateFileA, o file, \
GENERIC_WRITE, \
0, \
NULL, \
CREATE_NEW, \
FILE_ATTRIBUTE_NORMAL, \
NULL
xchg   eax,ebx
mov    eax,edi
sub    eax,o fa
invoke NtSetEaFile,ebx,o io,o fa, eax
invoke CloseHandle,ebx
invoke ExitProcess,0
END Start

This code can be used for testing purposes in a lab environment.

You can either compile the code yourself using masm32 or you can use a precompiled binary – download it here.

To run:

ea.exe <full path name to a file> <EA name> <EA value>

e.g.:

ea.exe g:\test.txt foo bar

Remember to specify a full path to a file. Also, choose a non-existing file name for a file (the program won’t work with files that are already present).

Last, but not least – there is no error checks, you can add it yourself if you wish

### Idea #2 – Reduce the FUD factor

While it is a novelty technique, it is not very advanced -  a single API call does all the dirty job to _create_ the EA.

To _detect_ EA is not very difficult either – as long as you have a right tool to do so

### Idea #3 – Show how to detect EA on a live system

Now that I got a POC, I can run it:

g:\test.txt foo bar

and then analyze changes introduced to the file system.

I can do it quickly  with hmft.

hmft -l g: mft_list

I tested the program on a small drive that I use for my tests. I formatted it first to ensure its MFT is clean:

I then opened the mft_list file in a Total Commander’s Lister and searched for MFTA_EA.

I am pasting the full record for your reference:

  [FILE]
SignatureD                    = 1162627398
OffsetToFixupArrayW           = 48
NumberOfEntriesInFixupArrayW  = 3
LogFileSequenceNumberQ        = 1062946
SequenceValueW                = 1
OffsetToFirstAttributeW       = 56
FlagsW                        = 1
UsedSizeOfMFTEntryD           = 368
AllocatedSizeOfMFTEntryD      = 1024
FileReferenceToBaseRecordQ    = 0
NextAttributeIdD              = 5
--

RESIDENT ATTRIBUTE
AttributeTypeIdentifierD = 16
LengthOfAttributeD       = 96
NonResidentFlagB         = 0
LengthOfNameB            = 0
OffsetToNameW            = 0
FlagsW                   = 0
AttributeIdentifierW     = 0
--
SizeOfContentD          = 72
OffsetToContentW        = 24
--
MFTA_STANDARD_INFORMATION
CreationTimeQ         = 130036100539989520
ModificationTimeQ     = 130036100539989520
MFTModificationTimeQ  = 130036100539989520
AccessTimeQ           = 130036100539989520
FlagsD                = 32
MaxNumOfVersionsD     = 0
VersionNumberD        = 0
ClassIdD              = 0
OwnerIdD              = 0
SecurityIdD           = 261
QuotaQ                = 0
USNQ                  = 0
CreationTime (epoch)    = 1359136453
ModificationTime (epoch)  = 1359136453
MFTModificationTime (epoch)  = 1359136453
AccessTime (epoch)           = 1359136453
--

RESIDENT ATTRIBUTE
AttributeTypeIdentifierD = 48
LengthOfAttributeD       = 112
NonResidentFlagB         = 0
LengthOfNameB            = 0
OffsetToNameW            = 0
FlagsW                   = 0
AttributeIdentifierW     = 2
--
SizeOfContentD          = 82
OffsetToContentW        = 24
--
MFTA_FILE_NAME
ParentID6             = 5
ParentUseIndexW       = 5
CreationTimeQ         = 130036100539989520
ModificationTimeQ     = 130036100539989520
MFTModificationTimeQ  = 130036100539989520
AccessTimeQ           = 130036100539989520
CreationTime (epoch)    = 1359136453
ModificationTime (epoch)  = 1359136453
MFTModificationTime (epoch)  = 1359136453
AccessTime (epoch)           = 1359136453
AllocatedSizeQ        = 0
RealSizeQ             = 0
FlagsD                = 32
ReparseValueD         = 0
LengthOfNameB         = 8
NameSpaceB            = 3
FileName = test.txt
--

RESIDENT ATTRIBUTE
AttributeTypeIdentifierD = 128
LengthOfAttributeD       = 24
NonResidentFlagB         = 0
LengthOfNameB            = 0
OffsetToNameW            = 24
FlagsW                   = 0
AttributeIdentifierW     = 1
--
SizeOfContentD          = 0
OffsetToContentW        = 24
--
MFTA_DATA
--

RESIDENT ATTRIBUTE
AttributeTypeIdentifierD = 208
LengthOfAttributeD       = 32
NonResidentFlagB         = 0
LengthOfNameB            = 0
OffsetToNameW            = 0
FlagsW                   = 0
AttributeIdentifierW     = 3
--
SizeOfContentD          = 8
OffsetToContentW        = 24
--
MFTA_EA_INFORMATION
--

RESIDENT ATTRIBUTE
AttributeTypeIdentifierD = 224
LengthOfAttributeD       = 40
NonResidentFlagB         = 0
LengthOfNameB            = 0
OffsetToNameW            = 0
FlagsW                   = 0
AttributeIdentifierW     = 4
--
SizeOfContentD          = 16
OffsetToContentW        = 24
--
MFTA_EA


There are two EA-related entries here:

• MFTA_EA_INFORMATION
• MFTA_EA record

Manual analysis like this are quite tiring, so we can write a short perl snippet that can help us with postprocessing:

use strict;
my $f=''; my$l='';
while (<>)
{
s/[\r\n]+//g;
$f =$1 if /FileName = (.+)$/; print "$f has $1 record\n" if ($l =~ /(MFTA_EA(_[A-Z]+)?)/);
$l =$_;
}

Saving it into ea.pl file, and running it as:

ea.pl mft_list

produces the following output:

### Idea #4 – Detect ZeroAccess with hmft

It’s simple

• I ran hmft before the ZeroAccess installation
• Then I infected my test box
• I then ran hmft after the ZeroAccess installation

At this stage, all I had to do was to run ea.pl on both outputs and I got the following results:

Or, for the sake of copy & paste (and web bots ):

r:\>ea.pl before_installation
V20~1.6 has MFTA_EA_INFORMATION record
V20~1.6 has MFTA_EA record

r:\>ea.pl after_installation
U has MFTA_EA_INFORMATION record
U has MFTA_EA record
V20~1.6 has MFTA_EA_INFORMATION record
V20~1.6 has MFTA_EA record
U has MFTA_EA_INFORMATION record
U has MFTA_EA record
services.exe has MFTA_EA_INFORMATION record
services.exe has MFTA_EA record/span>


As we can see, the malware activity is immediately visible.

Btw. V20~1.6 is a $MFT FILE record that refers to C:\Windows\CSC\v2.0.6 and is related to Offline files (client-side caching). I don’t have any information about the content of this EA. Perhaps someone will be more curious than me to poke around there ### Idea #5 – Create a Frankenstein’s monster Using EA and ADS (Alternate Data Streams) with a single file is also possible. You can use ea.exe to create such Frankenstein’s monster in 2 simple steps: • by running it first with a filename only – this will create EA record • and then re-runing it with a stream name, this will create the ADS, but EA for ADS will fail (sometimes it’s OK to fail ) The result is shown on the following screenshot: Using hmft and a combination of ea.pl and ads.pl (posted in older post related to HMFT) in a single eads.pl script: use strict; my$f='';
my $l=''; while (<>) { s/[\r\n]+//g;$f = $1 if /FileName = (.+)$/;
print "$f has$1 record\n" if ($l =~ /(MFTA_EA(_[A-Z]+)?)/); print "$f:$1\n" if ($l =~ /MFTA_DATA/&&/AttributeName = (.+)$/);$l = $_; } we can easily detect such beast as well. That’s all, thanks for reading! ## Malware attacking POS systems December 19, 2012 in Compromise Detection, Forensic Analysis, Malware Analysis Recently there has been quite a lot of technical posts about RAM scrappers targeting Point Of Sale (POS) systems i.e. malware stealing track data directly from memory of the systems involved in processing of credit cards within the Payment Card Industry (PCI). I am speaking – of course – about Dexter malware. You can find selected (good, technical and informative) articles covering this particular malware here: Verizon, Seculert, Volatility Labs, Trustwave. It’s good to see that the actual samples are now being either shared publicly or at least discussions about their internals are becoming available for a public eye. Xylitol is definitely leading here as he has been talking about this topic and specific samples a few times this year (example here and here), and sporadically, some of the PFI companies write a blog or two, or present their findings on security conferences. One thing worth to mention here is that some ‘juicy’ knowledge about specific RAM scraping samples has been shared many times in the past, but it has never gained as much exposure as it probably should e.g. many hashes of RAM scrapers have been mentioned in public advisories from card schemes e.g. here, here, and here. Still, access to the actual samples is very limited plus the hashes of samples keep changing (they are often recompiled for each new compromise). ## RAM Scraping and theft of data in transit What is ‘RAM Scraping’? RAM scraping is a different way of saying that malware reads and parses data directly from a memory (or a file containing memory dump) of a legitimate application responsible for credit card processing. Such ‘sniffing’ is usually scheduled to run at regular intervals. The malware can also directly ‘plug’ or hook into the payment application’s internals and analyze content of its buffers used to temporarily store credit card data in transit. RAM scraping is not a new idea, many carding attacks within at least last 5 years are relying on this technique and are described in detail by Trustwave and Verizon Business – well-known security companies that specialize in PFI investigations. The RAM scraping technique is extremely simple, effective and… quiet – except for the time when hackers come to the system to install the malware and occasionally come back to extort accumulated data, there is not much of suspicious or easily identifiable activity going on on the compromised system. It’s the ‘in transit’ aspect of RAM scraping that makes the attack so successful; even if the credit card data never touches the disk (e.g. on a properly hardened and configured system), the malware can still intercept it as it is injected into a transaction process and actively participates in it as an ‘observer’. It acts in a way similar to a man-in-the-middle attack with no modification of data involved (in other words, whatever application is processing – it will be first ‘seen’ by malware before it is passed to the legitimate payment processing application; and this is when data gets sniffed/stolen/dumped). In the first method of RAM scraping mentioned above the malware acts as an active ‘observer’ of other processes memory constantly analyzing it and looking for card data. It uses a ReadProcessMemory API to access the memory of a targeted process. The second one is more complex as it interacts directly with a targeted application – it can be a patched / modified binary or code patching of the running application – writing such patch requires either a good familiarity (on a programmatic level) with the payment application or the attacker needs to spend some time reverse engineering the application internals to know where to hook into its card processing functions. In a way, it is like a plugin code attached to the legitimate software. A very good example of the complex malware using this technique was the infamous ATM malware described first by Threatexpert back in 2009. The malware targeting POS systems comes in all flavors. It is written in perl, python, .NET, Delphi, C, and sometimes these are just legitimate applications modified to serve malicious purpose e.g. winpcap, ngrep, etc.. There is currently no good protection for this kind of attack on a software level (although system hardening, blocking access to process’ memory or immediately cleaning buffers used for credit cards and even introducing dummy yet incorrect track data inside the application buffers /randomly/ could possibly help; if you are merchant, ask POS vendors about it; if you are POS vendor, feel free to ask me more about it). ## Other types of POS malware & hacking techniques For the sake of completeness it is worth mentioning that some malware variants include code to cover other areas of the system as well and apart from memory scraping they can sniff unencrypted track data from network (again ‘data in transit’), or use traditional keyloggers to intercept track data directly as it enters the system used for swiping the cards e.g. in hotels or restaurants (card readers present themselves to the system as a keyboard, hence track data can be intercepted via keystroke interception). One can find PAN/Track harvesters working as sniffers putting network card interface in a promiscuous mode, or as specific modules injected into specific processes (more targeted approach), keyloggers, screen grabbers, and so on and so forth. Some techniques are even simpler – enabling legitimate flags/settings responsible for debugging purposes or to enable logs, or sometimes even simply increasing log verbosity allows to change the behavior of the POS application so that it will start storing PANs/Track data (and the hacker just needs to re-visit system a bit later to harvest the data). In some cases attackers also downgrade the applications to restore older, vulnerable versions of POS software on the compromised system. Such modifications are usually very subtle and since they don’t even require malware to be active on the system – very hard to detect. On the server side, the attacker may change the script responsible for card processing to transfer data to the attacker’s destination immediately after site users enter them – sometimes such data is stored in a local file as well. Other attacks rely on SQL injection and card data is dumped directly from the database to attacker’s client/tool. Older malware would also use SMTP or FTP to transfer data out in a real-time, but it’s really old school and doesn’t work in more and more environments. While ‘smash and grab’ approach still works, the mission to ‘stay quiet and steal as long as possible’ is a trend growing over last few years. Using a cliche metaphor, hackers now build oasis-like wells that act as card reservoirs to which they come back to fetch new harvested data once in a while. ## Example malware attacking POS I will describe here a a few specific examples of malware targeting POS systems. There are not too many publicly available samples available, but since now they are out there in the wild for quite some time (thanks to Xylitol for sharing the samples via his blog), let’s get to business and describe what we got there… #### lanst.exe MD5 D770ADBEE04D14D6AA2F188247AF16D0 SHA1 2474EC06E46605D60AC2B04B20998EB052AF275F It’ s a perl2exe compiled executable. Perl2exe executables contain an encrypted perl code that is decrypted during run-time and interpreted by the embedded perl processor/interpreter; because of this, we can extract the perl code during run-time. Lanst.exe’s perl code looks like this (we can save it as lanst.pl and even run): It is obvious from looking at the screenshot that there seem to be some funny unrecognized characters in the source code. It’s a good occasion to use hstrings: hstrings -ps0 lanst.pl > lanst.pl.probe It will probe all the encodings it knows and save the output data into lanst.pl.probe file. Browsing through lanst.pl.probe file using Total Commander’s Lister we can see Okay, so encoding is cp866,OEM Russian; Cyrillic (DOS). We can now go back to lanst.pl and use Lister’s Encodings menu to change the default encoding to 866. Et voilà! We get a nice Perl code with Russian comments: The code itself is not that interesting – it is a boring card scanner that tries to check if the attacked system stores any track data; it is multithreaded, can scan local system, its shares and computers in a domain. It also allows for file and file extensions exclusion/inclusion to speed up system analysis. Admittedly, it is a a nicely written triage script. And yes, I lied – it is actually quite interesting after all – a very efficient code that does exactly what is supposed to do in only a few dozen of lines in perl. Notably, the source code includes a version number 1.4a $version="Version 1.4a MultiThread from 22.04.2008";

and a code that prevents it from running if it is executed after a certain date.

$dietime = 1207392905+(86400*30*2); if ( time >$dietime ) { die("Can't open Handle/Tie.PM!"); };

This variant ‘dies’ if the date is 60 days past Sat, 05 Apr 2008 10:55:05 GMT – as you can see from the code above, it produces a misleading error message if executed at a wrong time.

Let’s take two important notes here:

• It is a very old sample! And since its version is 1.4, the earlier versions must exist.
• If you read my older post, you may recall that built-in ‘expiration date’ is one of the reasons why dynamic analysis is often not enough

A simple test on a dirty box (with a dummy Track data inside the track_samples.txt file) produces the following output:

Quite a nicely behaving hacking tool, isn’t? The guys who run it must feel really happy when they see it hitting the jackpot. Not so funny though if the track data comes from your own card that you have used at the compromised restaurant a few months ago.

Another aspect worth mentioning, the code creates various output files: ccfind.log is the most important amongst them as it contains the track data found on the scanned system together with the file names. If you came across this file on your case, congratulations – you have found a smoking gun…

The lanst.exe is both a triage/reconnaissance tool and a harvesting machine that is looking for easy targets on compromised systems i.e. files storing unencrypted track data that are ready for an immediate extortion.

It is not a RAM scraper per se, but I describe it here because it can be often found inside the ‘toolchests’. Traces of such tools being used are also a good indicator of a compromise.

#### dnsmgr.exe

MD5         3004CE6CB7C44605CDF971B74DB3A079

Another perl2exe compiled script. Decompiled code presents itself as yet another card parser that searches for Track1 and Track 2 patterns in a specific set of files. This is a scraper using similar technique to the one used in lanst.exe (regular expressions matching two types of track data) – yet again it is actually not a RAM scraper, but a file scraper.

If it sounds a bit confusing, it is because the files it parses are actually memory dumps obtained using a dedicated memory dumping tool. That is, the actual memory dumping part is implemented in a separate program.

One note here: memory dumping programs are typically part of hacker’s toolchest and since the functionality is trivial and easy to implement they are not described in this post; notably, memory dumping/parsing techniques are not carding/hacking-specific – many reverse engineers, penetration testers, and other security pros often use such tools during malware analysis, debugging sessions, pentesting or auditing gigs. Gaming cheat engines also use the same functionality.

Going back to dnsmgr.exe – as mentioned, there are two components involved here:

• one is a memory dumper that enumerates memory blocks from the process(es) that is/are of carders’ interest e.g. application processing card data
• second one is a parser (dnsmgr.exe) – it analyzes the dumped data looking for track 1 and 2 patterns – fragment of the parser are shown below.

It is a first generation of RAM scraping malware and as you can see it is not very advanced on a programmatic level, but worked well for quite some time (at least 3 years AFAIK; some may still be present on some POS systems even today!)

Second generation of RAM scrapers combined memory dump&parsing functionality into a small executable as shown in a next example.

#### rdasrv.exe

MD5         D9A3FB2BFAC89FEA2772C7A73A8422F2
SHA1        06A0F4ED13F31A4D291040AE09D0D136D6BB46C3

This is a second generation of RAM scrapers; it has been already described by various AV companies – so here just for the completeness: it is a code written in Delphi that runs as a service; it enumerates memory blocks of processes and reads them one by one, on the way utilizing regex patterns that match Tracks 1 and 2 – whatever matches theses patterns is intercepted and preserved in a locally created file.

As mentioned earlier, it is a service, so it has to be installed, then started:

While running, it creates a c:\windows\system32\data.txt file that contains intercepted information – Track data:

Last, but not least, it can be also uninstalled:

#### compenum.exe

MD5         BCC61BDF1A2F4CE0F17407A72BA65413
SHA1        B026397615ED9B63396EB5A4DF102DB706992E0E

MD5         C5C3341FBDD38C041E550D5DFF187A8F
SHA1        6686CE1C9B9809034333EEBD546523AE91491DB6

Two samples that are simple LAN recon/enumeration tools – they utilize WNet* functions to enumerate resources. They accept 3 command line arguments: -nocomment, -domains, -fullinfo and BCC61BDF1A2F4CE0F17407A72BA65413 accepts extra argument -createbat. The meaning of the command line arguments is as follows: extra info on WNET output (NETRESOURCE.lpComment), disable information about domains, output full information, output everything to a batch file (‘play.bat’ or ‘p’).

## Conclusion

These are old samples and there is nothing new here; RAM scraping malware is not very complex when compared to far more advanced families like Zeus or ZeroAccess, but this is a enough to harvest credit card numbers and later extort them from compromised systems. There are a lot more variants written by other carding groups yet the samples are not available publicly; most of them work the same way though – user mode components targeting memory of specific processes or all processes using ReadProcessMemory API or direct hooks in the payment applications’ code/libraries; kernel drivers are rare. Dexter’s arrival suggests that POS systems are gaining some attention and may be targeted even more than in previous years.

If you admin a POS system don’t be frightened, but consider making a step forward towards getting your systems PCI DSS compliant. While it’s not perfect, it will definitely improve the security posture of your organization.

## HSD – Quick bug fix

October 18, 2012 in Compromise Detection, HSD, Software Releases

I have updated my Sniffer Detector fixing a bug related to output redirection – it basically didn’t work when you tried to run

hsd > output

The new version fixes the problem.

Thx to Sebastien for spotting it and letting me know.

## Finding Alternate Data Streams (ADS) with HMFT

October 4, 2012 in Compromise Detection, Forensic Analysis, HMFT, Malware Analysis, Tips & Tricks

Finding Alternate Data Streams  (ADS) on the whole drive may be quite time consuming so in this quick post I will show you how to do it faster with HMFT.

As you probably know, the latest version of HMFT supports listing of basic attributes directly from $MFT – from both images and live systems. Amongst the features it currently supports is showing type of attribute and its name. Turns out, that this is enough information to find out what named DATA streams are hidden inside the FILE records – and this is essentially what ADSs are. So… First, let’s test how HMFT shows ADS-related data: • First let’s create a few sample ADSs echo > f:\test echo > f:\test:ads echo > f:\test:ads2 echo > f:\test:ads3 • Next, we run hmft over the drive and saving it to a file hmft -l f: f_mft.txt • Finally, let’s see the content of the file – scroll down to see file name, first unnamed DATA attribute that is then followed by 3 named DATA attributes – ADS names:  [FILE] SignatureD = 1162627398 OffsetToFixupArrayW = 48 NumberOfEntriesInFixupArrayW = 3 LogFileSequenceNumberQ = 4204637 SequenceValueW = 1 LinkCountW = 1 OffsetToFirstAttributeW = 56 FlagsW = 1 UsedSizeOfMFTEntryD = 448 AllocatedSizeOfMFTEntryD = 1024 FileReferenceToBaseRecordQ = 0 NextAttributeIdD = 6 -- RESIDENT ATTRIBUTE AttributeTypeIdentifierD = 16 LengthOfAttributeD = 96 NonResidentFlagB = 0 LengthOfNameB = 0 OffsetToNameW = 0 FlagsW = 0 AttributeIdentifierW = 0 -- SizeOfContentD = 72 OffsetToContentW = 24 -- MFTA_STANDARD_INFORMATION CreationTimeQ = 129938289425003390 ModificationTimeQ = 129938289502223390 MFTModificationTimeQ = 129938289502223390 AccessTimeQ = 129938289425003390 FlagsD = 32 MaxNumOfVersionsD = 0 VersionNumberD = 0 ClassIdD = 0 OwnerIdD = 0 SecurityIdD = 261 QuotaQ = 0 USNQ = 0 CreationTime (epoch) = 1349355342 ModificationTime (epoch) = 1349355350 MFTModificationTime (epoch) = 1349355350 AccessTime (epoch) = 1349355342 -- RESIDENT ATTRIBUTE AttributeTypeIdentifierD = 48 LengthOfAttributeD = 104 NonResidentFlagB = 0 LengthOfNameB = 0 OffsetToNameW = 0 FlagsW = 0 AttributeIdentifierW = 2 -- SizeOfContentD = 74 OffsetToContentW = 24 -- MFTA_FILE_NAME ParentID6 = 5 ParentUseIndexW = 5 CreationTimeQ = 129938289425003390 ModificationTimeQ = 129938289425003390 MFTModificationTimeQ = 129938289425003390 AccessTimeQ = 129938289425003390 CreationTime (epoch) = 1349355342 ModificationTime (epoch) = 1349355342 MFTModificationTime (epoch) = 1349355342 AccessTime (epoch) = 1349355342 AllocatedSizeQ = 0 RealSizeQ = 0 FlagsD = 32 ReparseValueD = 0 LengthOfNameB = 4 NameSpaceB = 3 FileName = test -- RESIDENT ATTRIBUTE AttributeTypeIdentifierD = 128 LengthOfAttributeD = 40 NonResidentFlagB = 0 LengthOfNameB = 0 OffsetToNameW = 24 FlagsW = 0 AttributeIdentifierW = 1 -- SizeOfContentD = 13 OffsetToContentW = 24 -- MFTA_DATA -- RESIDENT ATTRIBUTE AttributeTypeIdentifierD = 128 LengthOfAttributeD = 48 NonResidentFlagB = 0 LengthOfNameB = 3 OffsetToNameW = 24 FlagsW = 0 AttributeIdentifierW = 3 -- SizeOfContentD = 13 OffsetToContentW = 32 -- MFTA_DATA AttributeName = ads -- RESIDENT ATTRIBUTE AttributeTypeIdentifierD = 128 LengthOfAttributeD = 48 NonResidentFlagB = 0 LengthOfNameB = 4 OffsetToNameW = 24 FlagsW = 0 AttributeIdentifierW = 4 -- SizeOfContentD = 13 OffsetToContentW = 32 -- MFTA_DATA AttributeName = ads2 -- RESIDENT ATTRIBUTE AttributeTypeIdentifierD = 128 LengthOfAttributeD = 48 NonResidentFlagB = 0 LengthOfNameB = 4 OffsetToNameW = 24 FlagsW = 0 AttributeIdentifierW = 5 -- SizeOfContentD = 13 OffsetToContentW = 32 -- MFTA_DATA AttributeName = ads3 • Knowing all this, we can quickly put together a perl script that can walk through the data and pick up all ADS from the output file: use strict; my$f='';
my $l=''; while (<>) { s/[\r\n]+//g;$f = $1 if /FileName = (.+)$/;
print "$f:$1\n" if ($l =~ /MFTA_DATA/&&/AttributeName = (.+)$/);
$l =$_;
}
• Run it using the following syntax
perl ads.pl <hmft output>

e.g.:

perl ads.pl f_mft.txt

The output for the example file system is:

$Repair:$Config
test:ads3

I suggest you running a test on your local drives  – you are probably going to be quite surprised

Not only you may find plenty of files with ADS, but you may also get to know less-known good ADSs – many of them I have listed previously and a few more e.g. internal ADSs used by OS:

• $Info in$UpCase:$Info •$Config in $Repair:$Config
• $Max in$UsnJrnl:$Max and also MAC-related streams (resource forks) added by Safari (kinda equivalents of IE’s Zone.Identifier) • com.apple.quarantine • com.apple.metadata:kMDItemWhereFroms Note on a small bug here: with a larger number of ADSs the ads.pl script will show incorrect entries as ADS attributes that don’t fit within one FILE record will be stored elsewhere and w/o FILENAME attribute, hence the associated file name will be incorrect. Some may be also stored under ATTRIBUTE_LIST that is not supported by HMFT yet. ## HMFT update: listing$MFT attributes

September 29, 2012 in Compromise Detection, Forensic Analysis, HMFT, Malware Analysis, Software Releases

A few months back I released the first version of HMFT – a small utility written in x86 assembly that reads $MFT directly from a physical disk (or raw image file/DD format) and saves it to a file. Today I am releasing a new version of this tool that now can also extract$MFT metadata and print it out to the output file. It is very similar to AnalyzeMFT from David Kovar, mft.pl (wfa3e.zip) from Harlan Carvey, and fls from Sleuthkit as well as other similar utilities.

The main difference is that it is very small, fast, works on both live systems and images, and tries to parse the attributes and print out raw data in a way that includes all gore details from $MFT FILE records to help in analysis and learning the NTFS internals. Apart from a new functionality, I also fixed one bug – the actual$MFT FILE record was not saved to the output file in a previous version; this is now fixed.

As usual:

• it’s a work in progress and at the moment it only supports FILE_NAME and STANDARD_INFORMATION attributes as well as data LCNs. Hopefully I will be able to add other information later on.
• it may contain bugs so if you spot any, please do let me know and I will try to fix them.
• any feedback is much appreciated, thanks!

Enjoy!

The new version now takes 3 arguments from a command line:

Usage:
hmft [drive:] [-/options] [output filename]
where options are:
- l - enumerate $MFT and list FILE record attributes (partially implemented) - d - dump$MFT to a file

Examples:
hmft -d c: c_mft.dat
hmft -l c: c_mft_listing.dat

Example session on a 1.2GiB $MFT: Example output: [NTFS BOOT RECORD] BytesPerSector = 512 SectorsPerCluster = 8 MFTStartCluster = 786432 ---------------------------------------------- [FILE] SignatureD = 1162627398 OffsetToFixupArrayW = 48 NumberOfEntriesInFixupArrayW = 3 LogFileSequenceNumberQ = 99422051935 SequenceValueW = 1 LinkCountW = 1 OffsetToFirstAttributeW = 56 FlagsW = 1 UsedSizeOfMFTEntryD = 616 AllocatedSizeOfMFTEntryD = 1024 FileReferenceToBaseRecordQ = 0 NextAttributeIdD = 7 -- RESIDENT ATTRIBUTE AttributeTypeIdentifierD = 16 LengthOfAttributeD = 96 NonResidentFlagB = 0 LengthOfNameB = 0 OffsetToNameW = 24 FlagsW = 0 AttributeIdentifierW = 0 -- SizeOfContentD = 72 OffsetToContentW = 24 -- MFTA_STANDARD_INFORMATION CreationTimeQ = 128880037529117193 ModificationTimeQ = 128880037529117193 MFTModificationTimeQ = 128880037529117193 AccessTimeQ = 128880037529117193 FlagsD = 6 MaxNumOfVersionsD = 0 VersionNumberD = 0 ClassIdD = 0 OwnerIdD = 0 SecurityIdD = 256 QuotaQ = 0 USNQ = 0 CreationTime (epoch) = 1243530152 ModificationTime (epoch) = 1243530152 MFTModificationTime (epoch) = 1243530152 AccessTime (epoch) = 1243530152 -- RESIDENT ATTRIBUTE AttributeTypeIdentifierD = 48 LengthOfAttributeD = 104 NonResidentFlagB = 0 LengthOfNameB = 0 OffsetToNameW = 24 FlagsW = 0 AttributeIdentifierW = 3 -- SizeOfContentD = 74 OffsetToContentW = 24 -- MFTA_FILE_NAME ParentID6 = 5 ParentUseIndexW = 5 CreationTimeQ = 128880037529117193 ModificationTimeQ = 128880037529117193 MFTModificationTimeQ = 128880037529117193 AccessTimeQ = 128880037529117193 CreationTime (epoch) = 1243530152 ModificationTime (epoch) = 1243530152 MFTModificationTime (epoch) = 1243530152 AccessTime (epoch) = 1243530152 AllocatedSizeQ = 1051983872 RealSizeQ = 1051983872 FlagsD = 6 ReparseValueD = 0 LengthOfNameB = 4 NameSpaceB = 3 FileName =$MFT
--

NON_RESIDENT ATTRIBUTE
AttributeTypeIdentifierD = 128
LengthOfAttributeD       = 80
NonResidentFlagB         = 1
LengthOfNameB            = 0
OffsetToNameW            = 64
FlagsW                   = 0
AttributeIdentifierW     = 1
--
StartingVCNQ          = 0
EndingVCNQ            = 293647
OfsToRunListW         = 64
CompressionUnitSizeW  = 0
UnusedD               = 0
AllocateSizeQ         = 1202782208
ActualSizeQ           = 1202782208
InitializedSizeQ      = 1202782208
--
MFTA_DATA
len = 2
ofs = 3
LCN_Ofs = 786432
LCN_Len = 17312
len = 3
ofs = 4
LCN_Ofs = 16909768
LCN_Len = 276336
len = 0
ofs = 0
--

NON_RESIDENT ATTRIBUTE
AttributeTypeIdentifierD = 176
LengthOfAttributeD       = 272
NonResidentFlagB         = 1
LengthOfNameB            = 0
OffsetToNameW            = 64
FlagsW                   = 0
AttributeIdentifierW     = 6
--
StartingVCNQ          = 0
EndingVCNQ            = 36
OfsToRunListW         = 64
CompressionUnitSizeW  = 0
UnusedD               = 0
AllocateSizeQ         = 151552
ActualSizeQ           = 148896
InitializedSizeQ      = 148896
--
MFTA_BITMAP
NumOfClustersBlocks = 2
----------------------------------------------

## Perfect Timestomping a.k.a. Finding suspicious PE files with clustering

September 1, 2012 in Anti-Forensics, Compromise Detection, Forensic Analysis, Malware Analysis, PECluester, Software Releases

In my previous post about clustering, I mentioned that it can be used as an efficient  data reduction technique. I also provided some examples of timestamps that could be useful for detecting suspicious files on the system. One of them was a compilation time  embedded inside Portable Executables (PE). Turns out that putting this idea into practice is easy and today I wrote a simple perl script that implements this functionality in a few dozen lines of code.

The script scans directory (recursively, if requested) and finds all Portable Executables. It then reads their compilation timestamps and groups them into clusters. Each cluster is a ‘bucket’ holding all binaries compiled within a window of 1 day (86400 seconds). You can play around with the script and change the value of CLUSTER_BOUNDARY to e.g. 30 days and see what happens.

On a screenshot below you can see the script at work – finding all PE files and grouping them into clusters:

And after processing the whole folder, the resulting clusters are printed out:

One needs to quickly scroll through these groups and look at isolated / oprhaned files or small groups and this should hopefully help in finding the bad apples. You can also toy around with the script over clean directories to see what intel you can gather from the compilation timestamps of all PE files inside some specific directory.

For example, after running it over the c:\window\system32 directory of various Windows flavors you may spot some interesting patterns:

• Portable Executables that are part of Windows OS are not build in an alphabetic order (I originally hoped they are – it could be an interesting pattern to use to spot ‘out-of-orderly’ named executables sandwiched between 2 clean OS files)
• Still, many OS binaries are compiled sequentially (with a few minutes difference) so many can be easily ignored in analysis
• On Windows XP and Vista DLLs and EXEs seem to be compiled separately (this is an interesting pattern as  seeing .exe in a sequence of  .dlls should be immediately treated as suspicious; note that system updates may affect this pattern)
•  On Windows 7 both EXEs and DLLs seem to be compiled w/o any specific pattern
• Clean installation has a very small number of clusters within system32 directory; updated/patched binaries make analysis harder (still, updates will be most likely seen as separate clusters)
• Files dropped by installers, malware, as well as packed executables, compiled scripts e.g. perl32exe, etc. should stand out, even if timestomped – see how psexec service executable stands out below

Compilation time is a very useful characteristic of Portable Executable. Malware authors occasionally zero it or change it to a random value, but this is still not a very common practice. This, of course is a very good news for investigators and forensic analysts. If timestamp is real (not tampered  with), compilation time of a malicious sample is so unique that it is most likely different from ‘typical’ timestamps that can be found e.g. within system32 directory. As mentioned earlier, PECluester should be able to group such randomly dropped files into separate cluster(s) even if the file system (e.g. $MFT) timestamps are timestomped. Speaking of the devil. I mentioned ‘perfect timestomping’ in the title of this post. Why? Perfect timestomping of a Portable Executable would require not only changing the metadata on the file system, but also changing PE file’s compilation time (and all timestamps inside PE file that could reveal its compilation time) to some carefully chosen value that blends with compilation times of system files (especially for malware dropped inside system folders; for malware within application/temp data folders this – of course – is not that useful). So, how would we go about finding such perfectly timestomped files? Good news for forensic investigators is that a compilation timestamp is only one of many possible timestamps that can be found inside a typical Portable Executable. Unless malware author takes a really good care of all these timestamps (either understands Portable Executable file format quite well or uses a specialized tool), there is a high chance one may find some inconsistencies. While not many PE timestamps are properly updated during compilation time (e.g. Resources, Import Table have placeholders for timestamps, but are often zeroed by the compiler), some may include timestamps e.g. Debug Directory as show on a screenshot below: Other clues about the compilation time can be related to • embedded files (author might have forgotten to clean up their timestamps) • copyright banners for statically linked libraries • standard ‘template’ program icon (e.g. icons for win32 applications created via templates in RAD environment utilize always the same standard icon unless authors changes that; icons change between RAD versions and may give some clues as for the ‘age’ of the malware) • libraries/compiler signatures – this is difficult as it requires libraries of known patterns, IDA Pro’s FLIRT signatures come to mind here and may give some hints, but associating these with a specific date is close to impossible • even harder – specific to the compiler version code of exception handlers, prologue/epilogue code, compilation flags etc. Back to PECluester – imho you can use it as an alternative to AV scans and a toy for further research. Go ahead and experiment. Enjoy! You can download script here. ## Finding Smoking Gun and going beyond that – Helpful Forensic Artifacts August 23, 2012 in Compromise Detection, Forensic Analysis, Malware Analysis, Preaching, Tips & Tricks While I am quite critical about the idea of collecting IOCs (Indicator of Compromise) describing various malware, traces of hacking, etc in a form of hashes, even fuzzy hashes, file names, sizes, etc., etc. I do believe that there is a certain number of IOCs (or as I call them: HFAHelpful Forensic Artifact – as they are not necessary relevant to compromise itself) that are universal and worth collecting. I am talking about artifacts that are common to malware functionality and offensive activities on the system in general as well as any other artifact that may help both attackers and… in investigation (thanks to ‘helpful’ users that leave unencrypted credentials in text files, watch movies on critical systems, etc.). In this post, I will provide some practical examples of what I mean by that. Before I kick it off, just a quick reminder – the reasons why I am critical about bloated IOC databases is that they have a very limited applicability in a general sense; and the limitations come as a result of various techniques used by malware authors, offensive teams, etc. including, but not limited to: • metamorphism • randomization • encryption • data (e.g. strings) build on the fly (instead of hardcoding) • shellcode-like payloads • fast-flux • P2P • covert channels • etc. Notably, antivirus detections of very advanced, metamorphic malware rely on state machines not strings and it’s naive to assume that collecting file names like sdra64.exe is going to save the day… Anyway… If we talk about good, interesting HFAs I think of things that: • are very often used in malware because of a simple fact they need to be there (dropping files, autostart, etc.) • traces of activities that must be carried on the compromised system (recon, downloading toolchests, etc.) • also (notably) traces of user activity that support attacker’s work (e.g. a file password.txt is not an IOC, but it’s HFA) • traces of system being affected in a negative way e.g. if system has been compromised previously by a generic malware, certain settings could have been changed (e.g. disabled tracing, blocked Task Manager, etc.); they are IOCs in a generic sense, but not really relevant to the actually investigated compromise; you can think of it of these aspects of system security that place the system on the opposite side to the properly secured and hardened box; it also included previously detected/removed malware – imho AV logs are not ‘clear’ IOCs as long as they relate to the event that is not related to investigated compromise If we talk about a typical random malware, it’s usually stupidly written, using snippets copied&pasted from many sources on the internet. The authors are lazy and don’t even bother to encrypt strings, so detection is really easy. You can grep the file or a memory dump of a suspected process for typical autorun strings with strings, BinText, HexDive and most of the time you will find the smoking gun. If the attacker is advanced, all you will deal with is a blob of binary data that has no visible trace of being malicious unless disassembled – that is, a relocation independent, shellcode-like piece of mixed code/data in a metamorphic form that doesn’t require all the fuss of inline DLL/EXE loading, but it’s just a pure piece of code. It’s actually simple to write with a basic knowledge of assembly language and knowledge of OS internals. I honestly don’t know how to detect such malware in a generic way. I do believe that’s where the future of advanced malware is though (apart from going mobile). And I chuckle when I see malware that is 20MB in size (no matter how advanced the functionality). When we talk about IOC/HFAs and offensive security practices, it is worth mentioning that we need to follow the mind process of an attacker. Let me give you an example. Assuming that the attacker gets on the system. What things s/he can do? If the malware is already there, it’s easy as the functionality is out there and can be leveraged, malicious payload updated and attacker can do anything that the actual payload is programmed to do and within the boundaries of what environment where it runs permits. On the other hand, if it is an attack that comes through a typical hacking attempt, the situation is different. In fact, the attacker is very limited when it comes to available tools/functionality and often has to leverage existing OS tools. This means exactly what it says – attacker operates in a minimalistic environment and is going to use any possible tool available on OS to his/her benefit. If we talk about Windows system, it can be • net.exe (and also net1.exe) • telnet.exe • ftp.exe but also • command.com • cmd.exe • debug.exe • makecab.exe • diantz.exe • netsh.exe • netstat.exe • route.exe • hostname.exe • sc.exe • arp.exe • shutdown.exe • findstr.exe • at.exe • attrib.exe • cacls.exe • xcacls.exe • ping.exe • tracert.exe • runas.exe • more.com and OS commands • echo • type • dir • md/mkdir • systeminfo and many other command line tools and commands. So, if you analyze memory dump from a Windows system, it’s good to search for presence of a file name associated with built-in windows utilities and look at the context i.e. surrounding memory region to see what can be possibly the reason of it being there (cmd.exe /c being the most common I guess). Back to the original reason of this post – since I wanted to provide some real/practical examples of HFAs that one can utilize to analyze hosts, let me start with a simple classification by functionality/purpose: • information gathering • net.exe • net1.exe • psexec.exe/psexesvc.exe • dsquery.exe • arp.exe • traces of shell being used (cmd.exe /c) • passwords.txt, password.txt, pass.txt, etc. • data collection • type of files storing collected data • possibly password protected archives • encrypted data (e..g credit cards/track data) • various 3rd party tools to archive data: • rar, 7z, pkzip, tar, arj, lha, kgb, xz, etc. • OS-based tools • compress.exe • makecab.exe • iexpress.exe • diantz.exe • type of collected data • screen captures often saved as .jpg (small size) • screen captures file names often include date • keystroke names and their variants • PgDn, [PgDn],{PgDn} • VK_NEXT • PageDown, [PageDown] {PageDown} • timestamps (note that there are regional settings) • predictable Windows titles • [ C:\WINDOWS\system32\notepad.exe ] • [ C:\WINDOWS\system32\calc.exe ] • [http://google.com/ - Windows Internet Explorer] • [Google - Windows Internet Explorer] • [InPrivate - Windows Internet Explorer - [InPrivate]] • possible excluded window class names • msctls_progress32 • SysTabControl32 • SysTreeView32 • content of the address bar • attractive data for attackers • regexes for PII (searching for names/dictionary/, states, countries, phone numbers, etc. may help) • anything that matches Luhn algorithm (credit cards) • input field names from web pages and related to intercepted/recognized credentials • user • username • password • pin • predictable user-generated content • internet searches • chats (acronymes, swearwords, smileys, etc.) • data exfiltration • who • username/passwords • how • ftp client (ftp.exe, far.exe, etc.) • browser (POSTs, more advanced: GETs) • DNS requests • USB stick • burnt CD • printer • how • just in time (frequent network connection) • ‘coming back’ to the system • configuration • file • registry • uses GUI (lots of good keywords!) • where to: • URLs • FTP server names • SMTP servers • mapped drives (\\foo\c$)
• mapped remote paths (e.g. \\tsclient)
• malicious code
• any .exe/.zip in TEMP/APPLICATION DATA subfolders
• processes that have a low editing distance between their names and known system processes (e.g. lsass.exe vs. lsas.exe)
• processes that use known system processes but start from a different path
• areas of memory containing “islands” with raw addresses of APIs typically used by malware e.g. CreateRemoteThread, WriteProcessMemory, wininet functions
• mistakes
• Event logs
• AV logs/quarantine files
• leftovers (files, etc.)

Many of these HFAs form a very managable set that when put together can be applied to different data sets (file names, file paths, file content, registry settings, memory content, process dumps, etc.).

In other words – instead of chasing after a sample/family/hacking group-specific stuff, we look for traces of all these things that make a malware – malware, a weak system – weak, a hack – hack and attack-supporting user – victim.

## Windows Disco

August 7, 2012 in Compromise Detection, HWD, Malware Analysis, Software Releases

Detecting malware on a live system is often very difficult and requires special tools and lots of experience.There are situations though when some simple techniques can be used as well. This post introduces one such technique and provides a simple demo tool (toy really) you can use to play around.

The technique itself relies on a simple fact that many keylogging malware apps utilize a hidden ‘worker’ window and often offer extensive GUI that is not typically visible, but can be accessed by a malicious user after pressing a combination of keys. Worker window receives all intercepted keystrokes that are being sent by a hook procedure and GUI is used to set up keylogger parameters/view logs, etc. So, since such ‘working’/hidden GUI windows are not visible to the user, but they are still windows one can still enumerate them and present them to the user (even if windows are invisible).

This is exactly what Windows Disco does. It walks through all processes and their windows and takes a screenshot of each window, then saves it to a temporary PNG file in a current subfolder (named disco); you may review all these files either in an application itself, or in an Explorer, IrfanView or other image viewer.

For naysayers: yes, of course this can be so easily bypassed and is of course not foolproof – everything can be hooked and both enumeration and screenshot-taking prevented as well as keylogging can be implemented in a different way, but this is a demo of a trivial technique, not a ‘solve it all’ software who knows… with more and more malware moving back from kernel to userland such simple techniques may turn to be actually useful.

Another similar technique that might be potentially useful is hotkey enumeration – provided that keylogger registers a hotkey in a documented way one could use a hotkey enumeration tool to find suspicious associations (again I know this is far fetched, many keyloggers use state machine to trigger their hidden GUI, but always… ). The tool + src to enumerate hotkeys and article in Russian can be found here and  here.

As usual, testing on VM first is advised. Occasionally the GUI may be less responsive, pls be patient and kill it if necessary.

The whole procedure ends when MessageBox pops up showing how many windows have been enumerated.

The following screenshots have been taken from various keylogging applications; as you can see some are more ‘ostentatious’, some less.

As mentioned earlier, all files are saved in a ‘disco’ directory and can be reviewed using various browsers: