Latest Alerts

Volatility is a Python framework for performing memory forensics. If you haven't tried it yet I highly recommend it. The Volatility Month of Volatility Plugins II is on! As announced here: http://volatility-labs.blogspot.ca/2013/05/whats-happening-in-world-of-volatility.html Volatility 2.3 is entering beta and the second MoVP (Month of Volatility Plugins) has started and is actually in their second installment. Some very exciting new stuff:

1.1 - Mach-O Address Space
1.2 - VirtualBox ELF64 Core Dumps
1.3 - VMware Snapshot and Saved State Analysis
1.4 - New HPAK Address Space
1.5 - ARM Address Space (Volatility and Andriod / Mobile)
2.1 - RSA Private Keys and Certificates
2.2 - Unloaded Windows Kernel Modules

Cheers,
Adrien de Beaupré
Intru-shun.ca Inc.
My SANS Teaching Schedule

 

(c) SANS Internet Storm Center. http://isc.sans.edu Creative Commons Attribution-Noncommercial 3.0 United States License.

(c) SANS Internet Storm Center. http://isc.sans.edu Creative Commons Attribution-Noncommercial 3.0 United States License.

(c) SANS Internet Storm Center. http://isc.sans.edu Creative Commons Attribution-Noncommercial 3.0 United States License.

(c) SANS Internet Storm Center. http://isc.sans.edu Creative Commons Attribution-Noncommercial 3.0 United States License.

(c) SANS Internet Storm Center. http://isc.sans.edu Creative Commons Attribution-Noncommercial 3.0 United States License.

In my day job I spend about 90% of my time on the red team, performing vulnerability assessment and penetration testing. The rest is spent on threat research, incident response, and digital forensics. Interacting with clients as a consultant I often hear what I term 'interesting' responses. When a penetration tester calls something interesting you should probably pay attention :)

The IDS only listens external to the firewall? SharePoint is directly exposed to the Internet? The WAF protects against attacks therefore we don't have to fix the application? The VMs are all physically on the same host? The DMZ and the internal VLAN are physically on the same switch? You don't bother with privilege escalation patches? All quite interesting.

One of the responses I have heard multiple times is that privilege escalation vulnerabilities are a low priority because they require the attacker have local access. Meaning that that would be very difficult to pull off, therefore we don't have to worry about it. This also assumes that every single account holder is 100% gruntled all of the time, and that nobody ever makes a mistake. Meaning that we can trust everyone who accesses our networks and applications. Which I also find to be 'interesting' :)

There are multiple types of privilege attacks. The first is privilege escalation, where someone who has valid credentials or means to access a network or application can raise their level of access to a more privileged level. Like getting root on a Unix system for example, or becoming Domain admin before lunch on day 1, or assuming a higher role within an application. Impersonation attacks are similar however they entail becoming a different user, often with the same level of privilege, but with way more money in their account :) which soon finds its way to a non-extradition treaty country.

If the major difference between a remote exploit and a local one is that a network connection is required for the former, and not for the latter, does this mean that local priv escalation attacks cannot be performed across the network? Actually no. If an attacker can gain access to a system through a client side exploit, they may then effectively become the local user, and escalate to local system. Local system priv on a Windows computer is just a hop, skip, and jump away from being Domain administrator.

In a recent discussion about the priority to be assigned to patch one comment was "It's only a privilege escalation!". Yes, you are correct, and that is an interesting statement was my response.

Cheers,
Adrien de Beaupré
Intru-shun.ca Inc.
My SANS Teaching Schedule

(c) SANS Internet Storm Center. http://isc.sans.edu Creative Commons Attribution-Noncommercial 3.0 United States License.

(c) SANS Internet Storm Center. http://isc.sans.edu Creative Commons Attribution-Noncommercial 3.0 United States License.

I find it sad that in times when people are facing disaster, many have died, others missing, and the survivors facing having lost everything that there are scumbags who will try to take advantage. Be very wary of any charity that is raising funds for victims of any disaster, particularly one that has not been around for very long. There are many legit charities, I would recommend sticking to ones you are already familiar with. The American Red Cross for example has been around for a long time, does amazing work, and is always in need of funding. They are just one example of a well established charity that does good work and is already involved in helping out in Moore, Oklahoma.

Routine monitoring of newly registered domain names shows a number of brand new ones that have words like Oklahoma, Moore, tornado, recovery, help, assistance, and similar. I am certain that a number are registered by well meaning people, however I am equally sure that many are fake or scams. It does not take long for any recent newsworthy topic to be the subject line of phishing, malware, and scammers.

Another handler remarked that the new trend seems to be crowd funding, hopefully the money raised will make its way to the charity where it belongs.

Cheers,
Adrien de Beaupré
Intru-shun.ca Inc.
My SANS Teaching Schedule

(c) SANS Internet Storm Center. http://isc.sans.edu Creative Commons Attribution-Noncommercial 3.0 United States License.

(c) SANS Internet Storm Center. http://isc.sans.edu Creative Commons Attribution-Noncommercial 3.0 United States License.

(c) SANS Internet Storm Center. http://isc.sans.edu Creative Commons Attribution-Noncommercial 3.0 United States License.

I find it sad that in times when people are facing disaster, many have died, others missing, and the survivors facing having lost everything that there are scumbags who will try to take advantage. Be very wary of any charity that is raising funds for victims of any disaster, particularly one that has not been around for very long. There are many legit charities, I would recommend sticking to ones you are already familiar with. The American Red Cross for example has been around for a long time, does amazing work, and is always in need of funding. They are just one example of a well established charity that does good work and is already involved in helping out in Moore, Oklahoma.

Routine monitoring of newly registered domain names shows a number of brand new ones that have words like Oklahoma, Moore, tornado, recovery, help, assistance, and similar. I am certain that a number are registered by well meaning people, however I am equally sure that many are fake or scams. It does not take long for any recent newsworthy topic to be the subject line of phishing, malware, and scammers.

Another handler remarked that the new trend seems to be crowd funding, hopefully the money raised will make its way to the charity where it belongs.

Cheers,
Adrien de Beaupré
Intru-shun.ca Inc.
My SANS Teaching Schedule

(c) SANS Internet Storm Center. http://isc.sans.edu Creative Commons Attribution-Noncommercial 3.0 United States License.

(c) SANS Internet Storm Center. http://isc.sans.edu Creative Commons Attribution-Noncommercial 3.0 United States License.

Trend Micro published a report last week on a spear-phishing emails campaign that contain a malicious attachment exploiting a Microsoft Office vulnerability (CVE-2012-0158).

This paper identified specific targets:

• Government ministries
• Technology companies
• Media outlets
• Academic research institutions
• Nongovernmental organizations

According to the report, "While we have yet to determine the campaign’s total number of victims, it appears that nearly 12,000 unique IP addresses spread over more than 100 countries were connected to two sets of command-and-control (C&C) infrastructures related to Safe.[1]" Another fact of interest is the author of the malware is probably a professional software developer that reused legitimate source code from an Internet services company. Based on the information collected, they found "One key indicator that can be used to detect this network communication is the user-agent, Fantasia."[1] Additional information is available in the report.

If you have collected some malware matching this description, we would be interested to get some samples. You can submit them via our contact form.

[1] http://www.trendmicro.com/cloud-content/us/pdfs/security-intelligence/white-papers/wp-safe-a-targeted-threat.pdf
[2] http://www.cve.mitre.org/cgi-bin/cvename.cgi?name=CVE-2012-0158

-----------

Guy Bruneau IPSS Inc. gbruneau at isc dot sans dot edu

(c) SANS Internet Storm Center. http://isc.sans.edu Creative Commons Attribution-Noncommercial 3.0 United States License.

We're looking for any info or packets that target port 51616.   After witnessing a spike yesterday on his network and checking that our port data [1] corroborated his event, Andrew has written in asking what we know.    

The most useful snapshot of port activity can be seen in this graph image.  I ran the graphs as far back as 2006 and nothing more signifcant was illustrated.   The image below highlights yesterdays events as well as a more curious spike back in March.  These counts do not seem very significant at first look, but they could clearly be telling us something.   

So drop us a comment to share what you know.  We're interested to attribute this traffic to something useful.

[1] https://isc.sans.edu/port.html?port=51616

Update 1: ISC reader Jim suggested that port 51616 is Xsan is Apple Inc.'s storage area network (SAN) or clustered file system for Mac OS X. Xsan enables multiple Mac desktop and Xserve systems to access shared block storage over a Fibre Channel network. With the Xsan file system installed, these computers can read and write to the same storage volume at the same time.

(c) SANS Internet Storm Center. http://isc.sans.edu Creative Commons Attribution-Noncommercial 3.0 United States License.

I put together a simple .deb package to install our DShield iptables client on Ubuntu. The package is our standard perl client to submit iptables logs, but it is pre-configured for Ubuntu 12.04 LTS. It will submit IPv4 as well as IPv6 logs. Please give it a try and let me know if you run into any issues. For details, see

http://isc.sans.edu/clients/ubuntu.html

use our contact form for feedback or send it directly to me at jullrich - at - sans.edu 

The client will install the perl script in /opt/dshield, and all configuration files in /etc/dshield. It will also add an hourly cron job to check /var/log/ufw.log for new logs and mail them to DShield. All parameters can still be further configured via /etc/dshield/dshield.cnf.

To submit logs, we recommend you setup an account. But if you would like to submit anonymous reports, just use "0" as userid.

------
Johannes B. Ullrich, Ph.D.
SANS Technology Institute
Twitter

(c) SANS Internet Storm Center. http://isc.sans.edu Creative Commons Attribution-Noncommercial 3.0 United States License.

----------- Guy Bruneau IPSS Inc. gbruneau at isc dot sans dot edu

(c) SANS Internet Storm Center. http://isc.sans.edu Creative Commons Attribution-Noncommercial 3.0 United States License.

(c) SANS Internet Storm Center. http://isc.sans.edu Creative Commons Attribution-Noncommercial 3.0 United States License.

Currently, many public web sites that allow access via IPv6 do so via proxies. This is seen as the "quick fix", as it requires minimum changes to the site itself. As far as the web application is concerned, all incoming traffic is IPv4. 

The most obvious issue here is logging, in that the application only "sees" the proxies IP address, unless it inspects headers added by the proxy, which will no point to (unreadable?) IPv6 addresses.

But there is another issue: SSL Certificates. If only IPv6 connections are passed via the proxy, you will end up with two different certificate: One for the proxy, and one for the web application (or the IPv4 proxy). It may also happen that the IPv6 and IPv4 site are considered two different hosts on the web server, requiring distinct configurations.

For example, at this point, "www.socialsecurity.gov" uses two different certificates. One for IPv6 and one for IPv4. The IPv6 certifiate is expired, while the IPv4 certificate is valid. This is in particularly painful as some simple comand line tools, like "openssl s_client' are still not able to work over IPv6. For my test, I used gnutls-cli, which works similar to openssl s_client but supports IPv6.

Excerpt from the result:

 

gnutls-cli -p 443 --x509cafile /opt/local/share/ncat/ca-bundle.crt www.socialsecurity.gov Processed 291 CA certificate(s). Resolving 'www.socialsecurity.gov'... Connecting to '2001:1930:c01::aaaa:443'... [...] - subject `C=US,ST=maryland,L=baltimore,O=social security administration,OU=diias,OU=Terms of use at www.verisign.com/rpa (c)05,CN=www.socialsecurity.gov', issuer `C=US,O=VeriSign\, Inc.,OU=VeriSign Trust Network,OU=Terms of use at https://www.verisign.com/rpa (c)10,CN=VeriSign Class 3 Secure Server CA - G3', RSA key 1024 bits, signed using RSA-SHA1, activated `2012-04-05 00:00:00 UTC', expires `2013-04-29 23:59:59 UTC', SHA-1 fingerprint `3286afd908f256947b396dbae88d37b111c9aaaf' [...] - Status: The certificate is NOT trusted. The certificate chain uses expired certificate.  *** Verifying server certificate failed... *** Fatal error: Error in the certificate. *** Handshake has failed GnuTLS error: Error in the certificate.  

Next, lets try IPv4. A disadvantage of gnutls-cli is that you are not able to force an IPv4 connection, so I will just fall back to openssl here:

$ openssl s_client -connect www.socialsecurity.gov:443 -CAfile /opt/local/share/ncat/ca-bundle.crt [....] subject=/C=US/ST=maryland/L=baltimore/O=social security administration/OU=diias/OU=Terms of use at www.verisign.com/rpa (c)05/CN=www.socialsecurity.gov issuer=/C=US/O=VeriSign, Inc./OU=VeriSign Trust Network/OU=Terms of use at https://www.verisign.com/rpa (c)10/CN=VeriSign Class 3 Secure Server CA - G3 [...]   And after saving the certificate to a file:   $ openssl x509 -in /tmp/ssa.gov -text [...] Validity Not Before: Apr 22 00:00:00 2013 GMT Not After : Apr 30 23:59:59 2017 GMT Subject: C=US, ST=maryland, L=baltimore, O=social security administration, OU=diias, OU=Terms of use at www.verisign.com/rpa (c)05, CN=www.socialsecurity.gov So in short: two different certificates for the same host name. This isn't always bad, and not uncommon. But all certificates have to be valid!

------ Johannes B. Ullrich, Ph.D. SANS Technology Institute Twitter

(c) SANS Internet Storm Center. http://isc.sans.edu Creative Commons Attribution-Noncommercial 3.0 United States License.

(c) SANS Internet Storm Center. http://isc.sans.edu Creative Commons Attribution-Noncommercial 3.0 United States License.

 

Like with .biz, I sometimes have the impression that .su and .cc could be sinkholed in their entirety, because the bad domains seem to vastly outnumber whatever (if any) good is running under these TLDs as well.

Earlier today, ISC reader Michael contacted us with information that several PCs on his network had started to communicate with iestats.cc, emstats.su, ehistats.su, e-protections.su and a couple other domains. I was pretty sure that I had seen the latter domain on an earlier occasion in a malware outbreak, but I couldn't find it in our records .. until I only searched for "e-protections", and found e-protections.cc. This domain had been implicated back in October 2012 in a malware spree that was linked to the nasty W32.Caphaw, a backdoor/information stealer. The similarity of the names was too much of a coincidence, and it meant bad news for Michael.

Looking at what was captured by some of our network sensors allowed to reconstruct a (partial) picture of the IPs and ASN's involved in today's malware wave

Domain IP AS Provider Country ppetoc.iestats.cc 64.85.161.67 30517 Great Lakes Comnet USA ppetoc.iestats.cc 85.25.132.55 8972 PlusServer Intergenia AG Germany ppetoc.iestats.cc 173.224.210.244 40676 Psychz Networks USA ppetoc.iestats.cc 178.63.172.88 24940 Hetzner Online AG Germany ppetoc.iestats.cc 188.95.48.152 57172 Global Layer B.V. Netherlands

The host name portion for some of the domains looks like it is time dependent (incrementing ascii) whereas other domains use (apparently) random names like d3acofzi7hjft.e-protections.su. Name servers involved today include ns1.abercrombienfr.net (currently 199.68.199.178 - AS1426) and ns1.semi-spa.net (currently 91.227.220.104 - AS50300). I doubt the former has anything to do with the clothing store, the domain was created four months ago.

Closer inspection of Michael's PCs revealed that each infected box was apparently running a slightly different version of the EXE. Anti-Virus coverage is still thin (Virustotal) , but the Heuristics of some products seem to be catching on. This sample looks more like a ransomware trojan than Caphaw, but we'll know more once we analyze all the information gathered so far.

If you have information to add on this particular malware or the domains mentioned, please comment below, or use our contact form.

 

(c) SANS Internet Storm Center. http://isc.sans.edu Creative Commons Attribution-Noncommercial 3.0 United States License.