LogMeIn.com SSL certificate has been suspended – Malware analysis

23 01 2013

I couldnt help myself, I had to take this new baby out for a run.

I ran it in Sandboxie, using BSA – and got the following from the report:

 Report generated with Buster Sandbox Analyzer 1.84 at 13:23:54 on 23/01/2013

[ General information ]
* File name: e:\analysis\logmein\ssl_cert_logmein.scr

[ Changes to filesystem ]
* Modifies file (empty) E:\Analysis\logmein\ssl_cert_logmein.scr
* Creates file (empty) C:\Documents and Settings\Administrator\Application Data\Bydy\ziik.ila
* Creates file (empty) C:\Documents and Settings\Administrator\Application Data\Degi\ymnoo.epa
* Creates file C:\Documents and Settings\Administrator\Application Data\Feto\ypaf.exe

[ Network services ]
* Queries DNS “www.google.com.au”.
* Queries DNS “ssl.gstatic.com”.
* Queries DNS “www.google.com”.

[ Process/window/string information ]
* Enables process privileges.
* Gets system default language ID.
* Gets computer name.
* Checks for debuggers.
* Installs a hook procedure that monitors mouse messages.
* Installs a hook procedure that monitors keystroke messages.

Ok – so it drops a file, deletes itself & does a couple of google queries, installs a key & mouse logger …. but the important one is that it checks for debuggers ….. damn – ive been caught time to rollback the VM snapshot & try another way.

Before I run it outside the sandbox, I grab a registry snapshot with regshot & fire up wireshark.

HKU\S-1-5-21-682003330-1972579041-2146942695-500\Software\Microsoft\Windows\CurrentVersion\Run\Uvxexuk: “”C:\Documents and Settings\Administrator\Application Data\Udre\anuma.exe””
10.6.6.1 -> 8.8.8.8      DNS 80 Standard query 0x88da  A a5ccb72387a28161.com
8.8.8.8 -> 10.6.6.1     DNS 153 Standard query response 0x88da No such name

This time it drops a file (different random name this time) – but the important thing is that it sets it up run on boot. We also see a DNS query for a5ccb72387a28161.com that doesnt return a value … hmmmmm

root@bt:~/BADFILES/LogMeIn-SSL/logmein_2# whois a5ccb72387a28161.com

No match for “A5CCB72387A28161.COM”.
>>> Last update of whois database: Wed, 23 Jan 2013 04:19:45 UTC <<<

ok …. so its not registered …. although I wonder what it would do it it could reach that domain / url….

Time to fire up inetsim and see what happens

[2013-01-23 14:51:52] [825] [dns_53_tcp_udp 972] [10.6.6.1] connect
[2013-01-23 14:51:52] [825] [dns_53_tcp_udp 972] [10.6.6.1] recv: Query Type A, Class IN, Name a5ccb72387a28161.com
[2013-01-23 14:51:52] [825] [dns_53_tcp_udp 972] [10.6.6.1] send: a5ccb72387a28161.com 3600 IN A 10.6.6.11
[2013-01-23 14:51:52] [825] [dns_53_tcp_udp 972] [10.6.6.1] disconnect
[2013-01-23 14:51:52] [825] [dns_53_tcp_udp 972] [10.6.6.1] stat: 1 qtype=A qclass=IN qname=a5ccb72387a28161.com
[2013-01-23 14:51:52] [825] [http_80_tcp 1641] [10.6.6.1:1063] connect
[2013-01-23 14:51:52] [825] [http_80_tcp 1641] [10.6.6.1:1063] recv: POST /dcbe7001/a507590e.php HTTP/1.1
[2013-01-23 14:51:52] [825] [http_80_tcp 1641] [10.6.6.1:1063] recv: Accept: */*
[2013-01-23 14:51:52] [825] [http_80_tcp 1641] [10.6.6.1:1063] recv: User-Agent: 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; .NET4.0C; .NET4.0E)
[2013-01-23 14:51:52] [825] [http_80_tcp 1641] [10.6.6.1:1063] recv: Host: a5ccb72387a28161.com
[2013-01-23 14:51:52] [825] [http_80_tcp 1641] [10.6.6.1:1063] recv: Content-Length: 120
[2013-01-23 14:51:52] [825] [http_80_tcp 1641] [10.6.6.1:1063] recv: Connection: Keep-Alive
[2013-01-23 14:51:52] [825] [http_80_tcp 1641] [10.6.6.1:1063] recv: Cache-Control: no-cache
[2013-01-23 14:51:52] [825] [http_80_tcp 1641] [10.6.6.1:1063] recv: <(POSTDATA)>
[2013-01-23 14:51:52] [825] [http_80_tcp 1641] [10.6.6.1:1063] info: POST data stored to: /var/lib/inetsim/http/postdata/294f5db6a7407efb43a12242b0e0dbec996cc4d3
[2013-01-23 14:51:52] [825] [http_80_tcp 1641] [10.6.6.1:1063] info: Request URL: http:/ /a5ccb72387a28161.com/dcbe7001/a507590e[dot]php
[2013-01-23 14:51:52] [825] [http_80_tcp 1641] [10.6.6.1:1063] info: Sending fake file configured for extension ‘php’.
[2013-01-23 14:51:52] [825] [http_80_tcp 1641] [10.6.6.1:1063] send: HTTP/1.1 200 OK
[2013-01-23 14:51:52] [825] [http_80_tcp 1641] [10.6.6.1:1063] send: Server: Microsoft-IIS/4.0
[2013-01-23 14:51:52] [825] [http_80_tcp 1641] [10.6.6.1:1063] send: Connection: Close
[2013-01-23 14:51:52] [825] [http_80_tcp 1641] [10.6.6.1:1063] send: Content-Length: 258
[2013-01-23 14:51:52] [825] [http_80_tcp 1641] [10.6.6.1:1063] send: Content-Type: text/html
[2013-01-23 14:51:52] [825] [http_80_tcp 1641] [10.6.6.1:1063] send: Date: Wed, 23 Jan 2013 03:51:52 GMT
[2013-01-23 14:51:52] [825] [http_80_tcp 1641] [10.6.6.1:1063] info: Sending file: /var/lib/inetsim/http/fakefiles/sample.html
[2013-01-23 14:51:52] [825] [http_80_tcp 1641] [10.6.6.1:1063] stat: 1 method=POST url=http:/ /a5ccb72387a28161.com/dcbe7001/a507590e[dor]php sent=/var/lib/inetsim/http/fakefiles/sample.html postdata=/var/lib/inetsim/http/postdata/294f5db6a7407efb43a12242b0e0dbec996cc4d3
[2013-01-23 14:51:52] [825] [http_80_tcp 1641] [10.6.6.1:1063] disconnect
[2013-01-23 14:51:53] [825] [http_80_tcp 1642] [10.6.6.1:1064] connect
[2013-01-23 14:51:53] [825] [http_80_tcp 1642] [10.6.6.1:1064] recv: POST /dcbe7001/a507590e.php HTTP/1.1
[2013-01-23 14:51:53] [825] [http_80_tcp 1642] [10.6.6.1:1064] recv: Accept: */*
[2013-01-23 14:51:53] [825] [http_80_tcp 1642] [10.6.6.1:1064] recv: User-Agent: 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; .NET4.0C; .NET4.0E)
[2013-01-23 14:51:53] [825] [http_80_tcp 1642] [10.6.6.1:1064] recv: Host: a5ccb72387a28161.com
[2013-01-23 14:51:53] [825] [http_80_tcp 1642] [10.6.6.1:1064] recv: Content-Length: 120
[2013-01-23 14:51:53] [825] [http_80_tcp 1642] [10.6.6.1:1064] recv: Connection: Keep-Alive
[2013-01-23 14:51:53] [825] [http_80_tcp 1642] [10.6.6.1:1064] recv: Cache-Control: no-cache
[2013-01-23 14:51:53] [825] [http_80_tcp 1642] [10.6.6.1:1064] recv: <(POSTDATA)>
[2013-01-23 14:51:53] [825] [http_80_tcp 1642] [10.6.6.1:1064] info: POST data stored to: /var/lib/inetsim/http/postdata/b5fd16db60922e8b7d960748fc4e0af6c4a3dde5
[2013-01-23 14:51:53] [825] [http_80_tcp 1642] [10.6.6.1:1064] info: Request URL: http:/ /a5ccb72387a28161.com/dcbe7001/a507590e[dot]php
[2013-01-23 14:51:53] [825] [http_80_tcp 1642] [10.6.6.1:1064] info: Sending fake file configured for extension ‘php’.
[2013-01-23 14:51:53] [825] [http_80_tcp 1642] [10.6.6.1:1064] send: HTTP/1.1 200 OK
[2013-01-23 14:51:53] [825] [http_80_tcp 1642] [10.6.6.1:1064] send: Server: Microsoft-IIS/4.0
[2013-01-23 14:51:53] [825] [http_80_tcp 1642] [10.6.6.1:1064] send: Connection: Close
[2013-01-23 14:51:53] [825] [http_80_tcp 1642] [10.6.6.1:1064] send: Content-Length: 258
[2013-01-23 14:51:53] [825] [http_80_tcp 1642] [10.6.6.1:1064] send: Content-Type: text/html
[2013-01-23 14:51:53] [825] [http_80_tcp 1642] [10.6.6.1:1064] send: Date: Wed, 23 Jan 2013 03:51:53 GMT
[2013-01-23 14:51:53] [825] [http_80_tcp 1642] [10.6.6.1:1064] info: Sending file: /var/lib/inetsim/http/fakefiles/sample.html
[2013-01-23 14:51:53] [825] [http_80_tcp 1642] [10.6.6.1:1064] stat: 1 method=POST url=http://a5ccb72387a28161.com/dcbe7001/a507590e.php sent=/var/lib/inetsim/http/fakefiles/sample.html postdata=/var/lib/inetsim/http/postdata/b5fd16db60922e8b7d960748fc4e0af6c4a3dde5
[2013-01-23 14:51:53] [825] [http_80_tcp 1642] [10.6.6.1:1064] disconnect

and there it is, that looks like a phone home to me – it resolves the url and instantly does two posts to the site http:/ /a5ccb72387a28161.com/dcbe7001/a507590e[dot]php

Interestingly, the two files dropped are different (MD5)

root@bt:~/BADFILES/LogMeIn-SSL/logmein_1# md5sum ypaf.exe
dc3f94ae190fd6db5f4a675097352768  ypaf.exe
root@bt:~/BADFILES/LogMeIn-SSL/logmein_1# md5sum anuma.exe
cad63849694322e025fbb0dcaf6d5a20  anuma.exe

but they are both appear to be zbot

https://www.virustotal.com/file/bdfde6c2b6e25759dd1ea25a7d23905b6c55bc16c4ade9ce0658c4b66c440bcc/analysis/

https://www.virustotal.com/file/cd480e6b94ce259275014a80d3f98e29ebaabd021e4ecf65f0b224ad462e59fc/analysis/

Advertisements




LogMeIn.com SSL certificate has been suspended – Malware

23 01 2013

I have been a little behind with updating this blog, mainly due to work & family commitments, but its also because I have been making my way through the book “Practical Malware Analysis” and had setup a sandpit in which to play around with some fun new toys to analyze executable files. Huge thanks to NoStartchPress – do yourself a favour & get hold of a copy of it: http://nostarch.com/malware

So there I was, happily reading email when I received one that said my LogMeIn.com SSL certificate had been suspended ….. my initial thought was WTF ? I dont have a LogMeIn.com SSL certificate, after opening the mail, seeing the alert that Google had kindly provided & then viewing the source of the email, seeing that it links to a zip file, my spidey sense was on full alert….

LogMeIn.com SSL Cert Email

So off to the google I went & sure enough, the first couple of hits are LogMeIn “Investigating” and a Threat alert from Cisco.

The first thing I notice, is that it appears to be distributed, in that its not just one email server sending these messages

My Email (62.149.131.234 & 62.149.158.121)

Return-Path: <me@localhost.com>
Received: from smtpsmart1.aruba.it (smtpweb121.aruba.it. [62.149.158.121])
by mx.google.com with SMTP id g49si29182110eep.242.2013.01.22.04.34.13;
Tue, 22 Jan 2013 04:34:13 -0800 (PST)
Received-SPF: neutral (google.com: 62.149.158.121 is neither permitted nor denied by best guess record for domain of me@localhost.com) client-ip=62.149.158.121;
Authentication-Results: mx.google.com;
spf=neutral (google.com: 62.149.158.121 is neither permitted nor denied by best guess record for domain of me@localhost.com) smtp.mail=me@localhost.com
Received: (qmail 9120 invoked by uid 89); 22 Jan 2013 12:34:12 -0000
Received: by simscan 1.2.0 ppid: 5136, pid: 8683, t: 1.6385s
scanners: clamav: 0.88.4/m:40/d:1945 spam: 3.1.4
X-Spam-Checker-Version: SpamAssassin 3.2.5 (2008-06-10) on
smtpsmart1.fe.aruba.it
X-Spam-Level: *****
X-Spam-Status: No, score=5.2 required=6.5 tests=BAYES_50,HTML_IMAGE_ONLY_20,
MIME_HTML_ONLY,RDNS_NONE,SPF_FAIL autolearn=disabled version=3.2.5
Received: from unknown (HELO webs1224.aruba.it) (62.149.131.234)
by smtpsmart1.fe.aruba.it with SMTP; 22 Jan 2013 12:34:10 -0000
Received: from webs1224 ([127.0.0.1]) by webs1224.aruba.it with Microsoft SMTPSVC(6.0.3790.4675);
Tue, 22 Jan 2013 13:33:35 +0100

From the LogMeIn.com post (80.67.28.160)

X-Msg-Ref: server-9.tower-85.messagelabs.com!1358859129!34525498!1
X-Originating-IP: [80.67.28.160]
X-SpamReason: No, hits=1.8 required=7.0 tests=HTML_60_70,
HTML_IMAGE_ONLY_20,HTML_MESSAGE,MIME_HTML_ONLY,ML_RADAR_SPEW_LINKS_18,
spamassassin:
X-StarScan-Received:
X-StarScan-Version: 6.7; banners=-,-,-
X-VirusChecked: Checked
Received: (qmail 10352 invoked from network); 22 Jan 2013 12:52:10 -0000
Received: from charybdis.ispgateway.de (HELO charybdis.ispgateway.de)
(80.67.28.160)  by server-9.tower-85.messagelabs.com with SMTP; 22 Jan 2013
12:52:10 -0000
Received: (qmail 17828 invoked from network); 22 Jan 2013 12:51:49 -0000
Received: from unknown (HELO charybdis.ispgateway.de) (127.0.0.1)  by
localhost with SMTP; 22 Jan 2013 12:51:49 -0000
Received: (from u195401@localhost)      by charybdis.ispgateway.de
(8.14.4/8.13.6/Submit) id r0MCpWg0016765;      Tue, 22 Jan 2013 13:51:32 +0100
Date: Tue, 22 Jan 2013 13:51:32 +0100

So anyway, back to the content, the link in the email to download a new SSL certificate is actually a link to a ZIP file. Note, the site is now requesting a login to get to the link.

http:/ / www [dot] austinpolishsociety [dot] org/bod/ssl_cert_logmein.zip

This ZIP file contains one file ssl_cert_logmein.scr

root@bt:~/BADFILES/LogMeIn-SSL# unzip -l ssl_cert_logmein.zip
Archive:  ssl_cert_logmein.zip
Length      Date    Time    Name
———  ———- —–   —-
324608  2013-01-22 03:38   ssl_cert_logmein.scr
———                     ——-
324608                     1 file
root@bt:~/BADFILES/LogMeIn-SSL# file ssl_cert_logmein.scr
ssl_cert_logmein.scr: PE32 executable for MS Windows (GUI) Intel 80386 32-bit
root@bt:~/BADFILES/LogMeIn-SSL# md5sum ssl_cert_logmein.scr
dc2b9b72189957c8d3ce9d15d0f35bf1  ssl_cert_logmein.scr

another quick google & we see that this file has hit the malware & virus check sites already malwr.com and virustotal.

So even without executing this guy, I can already tell its neither my “expired SSL cert” nor is it an screen saver (per the scr file extension).

I plan to run this in a sandbox & see what else I can find, several sites are reporting it phones home, and virustotal is flagging it as Zeus / zbot – so remote control and/or banking credential capture …. nasty little bugger.

Interestingly when I downloaded the zip & scanned it with MS Security Essentials – no virus reported ….. wonder how long it will take to get a sig down for it.





Malware Persistence without the Windows Registry

21 07 2010

Found an interesting post below, it seems that we can use dll files to deliver malware persistance without reg hacking (easily spotted) …. I wonder how this goes with meterpreter …. one way to find out I guess …. stay tuned.

Malware Persistence without the Windows Registry
Written by Nick Harbour
For an attacker to maintain a foothold inside your network they will typically install a piece of backdoor malware on at least one of your systems. The malware needs to be installed persistently, meaning that it will remain active in the event of a reboot. Most persistence techniques on a Microsoft Windows platform involve the use of the Registry. Notable exceptions include the Startup Folder and trojanizing system binaries. Examining malware persistence locations in the Windows Registry and startup locations is a common technique employed by forensic investigators to identify malware on a host. Each persistence technique commonly seen today leaves a forensic footprint which can be easily collected using most forensic software on the market.

The persistence technique I’ll describe here is special in that it doesn’t leave an easy forensic trail behind. A malware DLL can be made persistent on a Windows host by simply residing in a specific directory with a specific name, with no trace evidence in the registry or startup folder and no modified system binaries. There isn’t just one directory location and DLL filename that are candidate locations for this persistence mechanism but rather a whole class of candidate locations exist for any given system. On my laptop Windows 7 64-bit there are no less than 1032 such path and DLL name combinations where a DLL could be placed such that it would automatically be loaded at some point during my normal boot-up, and that’s just for a 32-bit DLL! If you had a 64-bit malware DLL the number would be much higher as I have many more 64-bit processes running at boot time. So how does this work?

via M-unition » Blog Archive » Malware Persistence without the Windows Registry.

Tool Here