Latest Alerts

Syndicate content SANS Internet Storm Center, InfoCON: green
Updated: 49 min 55 sec ago

Assessing the risk of POODLE, (Thu, Jan 8th)

Wed, 01/07/2015 - 23:14

One of the biggest security announcements in the last year was definitely the POODLE (Padding Oracle On Downgraded Legacy Encryption) vulnerability, which marked the real end of SSLv3. In a contrast with many other previously identified vulnerabilities in encryption algorithms used by SSLv3, this vulnerability is viable, and can be exploited by an attacker without jumping over too many obstacles or requiring large resources the POODLE vulnerability is real.

While this raised quite a bit of panic (in some cases the panic was justified) it also raised quite a bit of dust where it should not have had. The goal of this diary is therefore to clear things up a bit, to allow you to make proper risk assessment on moving away from SSLv3 please do add comments and your experiences (and any corrections, if you find errors).

A little refresher

First, though, a little refresher on how the POODLE vulnerability works. The original paper is available at, however I will explain couple of details which are, in my opinion, crucial for this attack and that maybe have not been stressed out as they should have in this paper (my personal opinion is that the steps related to the attack should have been better explained since that would allow people to easily assess the risk).

The vulnerability exists in the fact that, when a CBC encryption algorithms is used, SSLv3 does not cover padding with MAC (Message Authentication Code). Additionally (and this is the key), when there is an entire block of padding, SSLv3 checks only the last byte in the padding block. All other, previous bytes in that block are ignore and the value of the last byte must be equal to the block size (i.e. 15, when the block size is 16 bytes).

If an attacker wants to exploit this vulnerability, he first must perform the following actions:

  • Successfully run a Man-in-the-Middle attack against the victim,
  • Downgrade connection to SSLv3, if TLS is used as well, for example,

If the requirements above have been fulfilled, the attack is relatively simple, and the attacker must do the following:

  • Position the byte he wants to recover as the last byte of a block. This is a critical requirement as we will see later.
  • Copy that block as the last (padding) block.

Now the attacker uses the server as the oracle depending on messages received back. The server will try to decrypt the message and when decrypting the last block, due to the CBC encryption algorithm, after the decryption, the last byte will be XOR-ed with the last byte of the previous block. As we used an entire block of padding, the attacker knows that result of this process must be 15. In other words, if the decryption was successful, the attacker can obtain the plain text value of that byte since he can easily calculate it: the decrypted byte = 15 XOR (the last byte of the previous block).

How does the attacker know if the decryption was successful? Its simple: by observing network traffic from the server:

  • If the decryption failed (and this means that the result was not 15), the attacker will see Alert Code 21, which means Decryption failed (the description says: Decryption of a TLSCiphertext record is decrypted in an invalid way: either it was not an even multiple of the block length or its padding values, when checked, were not correct. This message is always fatal.)
  • If the decryption was successful, the attacker can decrypt the byte. The action that the request will cause does not really matter.

All the attacker needs to do now is cause the victim to issue multiple requests. In average he will need 256 request to decrypt a single byte (but notice that it might take him much more or less requests to do this). By causing the victim to issue arbitrary requests, the attacker decrypts his wanted data (usually a session cookie in web applications) byte by byte.

Practicality of POODLE attacks

As you can see in the previous section, there is a number of requirements that the attacker needs to fulfill to execute POODLE attacks. One of the most important is to make the victim issue arbitrary requests to the server. The attacker must somehow be able to influence these requests the byte he wants to decrypt must be the last byte in a block.
With web applications this is relatively easy since the attacker must be in a MitM position anyway, he can make the victims browser issue such special requests (for more details see the original paper).

However, and this is the crucial point of assessing the risk of POODLE what happens if the attacker cannot influence such requests? Well, according to current information, he will be able to decrypt only single pre-positioned bytes.

While this is still bad, the risk might be lower than with a standard web application. And this is the main point of assessing the risk: in last couple of months Ive seen simply too many cases when an auditor (or a penetration tester) ran a tool which reported that SSLv3 is enabled and blindly marked this as a critical vulnerability that has to be mitigated as soon as possible.

One of the typical cases of such detections are client-server applications that use SSLv3 to protect data, but that do not allow the attacker to modify the requests (for example: monitoring systems). Such systems always issue same requests, and they do this automatically so the attacker cannot modify the request (the plain text version of it), as he can with web applications.

So, to wrap up this already long diary always assess risk properly and do not accept results of automated scanners blindly. While the POODLE vulnerability is indeed a severe and critical vulnerability, and we should move to TLS (v1.2 if possible), the migration should be staged and carefully planned.


(c) SANS Internet Storm Center. Creative Commons Attribution-Noncommercial 3.0 United States License.
Categories: Alerts

Why patch management is ALSO REQUIRED in ICS infrastructure, (Wed, Jan 7th)

Wed, 01/07/2015 - 21:32

Security patch management is a delicate issue in critical infrastructure. This is caused for the specific configuration, operating system version and related software required by the ICS platform. Most support contracts states that any modification outside the parameters stated by the manufacturer will void the relation and release manufacturer and seller from any responsibility about malfunction and any consequence on the industrial process.

Unfortunately, when we talk about ICS software running on windows the restriction is often applied to domain controllers as well. The case I will cover on the present diary is about an incident on a Water ICS system controlled by Emerson Open Enterprise installation and how all the servers located in the domain got modified their attributes on the domain controller without being able to tell what changes were executed.

Before this incident happened, all domain controllers and servers were configured to log the required security events to Arcsight. Now we need to find out which of the billions of logs we need to search. For this installation, we are talking about 3000 events per second. The incident began when the Open Enterprise HMI System began to loose readings from all the RTUs and after a couple of minutes it was unable to send commands to any RTU.

Since we are talking here about Windows Server 2012R2, There is an interesting repository were all event IDs for Windows 8 and Windows 2012 can be located. After looking inside the repository, the following events are interesting for searching inside the arcsight database:

Category Subcategory Event ID Message Summary DS Access Directory Service Changes 5136 A directory service object was modified. DS Access Directory Service Changes 5137 A directory service object was created. DS Access Directory Service Changes 5138 A directory service object was undeleted. DS Access Directory Service Changes 5139 A directory service object was moved. DS Access Directory Service Changes 5141 A directory service object was deleted.

Event ID 5136 states that the attribute field must be filled with the information changed for the specific object. Check the following evidence collected:

Log Name: SecuritySource: Microsoft-Windows-Security-AuditingDate: 23/11/2014 1:30:42 PMEvent ID: 5136Task Category: Directory Service ChangesLevel: InformationKeywords: Audit SuccessUser: N/AComputer: DC.Domain.comDescription:A directory service object was modified. Subject: Security ID: Domain\Administrator Account Name: Administrator Account Domain: Domain Logon ID: 0x5f8a3Directory Service: Name: Domain.local Type: Active Directory Domain Services Object: DN: CN=XXXXXXX,OU=XXXXX,DC=Domain,DC=Com GUID: CN=XXXXX,OU=XXXXX,DC=Domain,DC=Com Class: XXXXX Attribute: XXXXXXXXXXX: YYYYYYYY Syntax (OID): X.X.X.X Value: ZZZZZZZZZZZZZZ Operation: Type: Value Deleted Correlation ID: {ba5fa2fe-9a61-12fa-1b95-3bf03643b4e2}">For some reason, the attribute field was missing and we could not know what attributes were deleted. After researching on this issue, we found it">Want to implement patch management in your organization? Check the specific NIST guide for more information.

Manuel Humberto Santander Pelez
SANS Internet Storm Center - Handler
e-mail: msantand at isc dot sans dot org

(c) SANS Internet Storm Center. Creative Commons Attribution-Noncommercial 3.0 United States License.
Categories: Alerts

ISC StormCast for Thursday, January 8th 2015, (Thu, Jan 8th)

Wed, 01/07/2015 - 16:58
(c) SANS Internet Storm Center. Creative Commons Attribution-Noncommercial 3.0 United States License.
Categories: Alerts

A Packet a Day: ICMPv6 Type 1 Code 5, (Wed, Jan 7th)

Wed, 01/07/2015 - 16:21

One of the exercises I keep recommending is to take 5 minutes of traffic form your own network (any network...), and try to explain each packet. Being an eat your own dogfood kind of guy, I try to do this myself every so often, and yesterday, after setting up a new IPv6 connection, I came across this neat packet:

IP6 2601:aaaa:bbbb:cccc:1122:33ff:fe44:5566 2601:aaaa:bbbb:xxxx:1122:3344:5566:7788: ICMP6, destination unreachable, unknown unreach code (5)

If tcpdump calls an ICMP type Unknown, things certainly get interesting. If it is IPv6, then that becomes outright exciting and makes you dive for the RFCs. So whats is happening here?

In the end, it is a simple invalidconfiguration, but something you may find in IPv6 quite commonly. My ISP assigns me an IPv6 prefix via DHCPv6. DHCPv6 has a special feature to do so:Prefix Delegation (often abbreviatedPD). In my case, my DHCP client died. Turns out, that as soon as I no longer request the particular prefix, my modemdecided that the prefix is no longer mine, and itno longer routed it. Now in IPv4, there is no well defined ICMP message that is sent back if you essentially try to spoof a source IP that doesnt belong to you. Maybe an admin prohibited? In IPv6, we got a specific ICMPv6 code, 5, to indicate what is happening.

Type 1 is used for unreachable, similar to 3 in ICMPv4. Code 5 is defined in RFC 4443 as Source address failed ingress/egress policy. This certainly helped me figure out what is going on here.

Here is a quick list of the codes defined for type 1 in RFC 4443:

Code Message 0 No route 1 Admin Prohibited 2 Beyond scope of source address (e.g. a link local address used to reach a global address) 3 Address unreachable 4 Port unreachable 5 ingress/egree policy fail 6

reject route to destination (trying to use a router that doesnt route to that destination)

Again, this is all for type 1. Code 5 and 6 are described as subtypes of 1 (Admin Prohibited)

As a quick tcpdump filter, you have to use icmp6 and ip[40:2]=0x0105. tcpdump does not support icmp6 offsets at this point.


Johannes B. Ullrich, Ph.D.

(c) SANS Internet Storm Center. Creative Commons Attribution-Noncommercial 3.0 United States License.
Categories: Alerts

ISC StormCast for Wednesday, January 7th 2015, (Wed, Jan 7th)

Tue, 01/06/2015 - 18:45
(c) SANS Internet Storm Center. Creative Commons Attribution-Noncommercial 3.0 United States License.
Categories: Alerts

Please Take Part In Our Annual Stormcast Survey, (Wed, Jan 7th)

Tue, 01/06/2015 - 18:38

Johannes B. Ullrich, Ph.D.

(c) SANS Internet Storm Center. Creative Commons Attribution-Noncommercial 3.0 United States License.
Categories: Alerts

ISC StormCast for Tuesday, January 6th 2015, (Tue, Jan 6th)

Mon, 01/05/2015 - 19:16
(c) SANS Internet Storm Center. Creative Commons Attribution-Noncommercial 3.0 United States License.
Categories: Alerts

ISC StormCast for Tuesday, January 6th 2015, (Tue, Jan 6th)

Mon, 01/05/2015 - 19:16
(c) SANS Internet Storm Center. Creative Commons Attribution-Noncommercial 3.0 United States License.
Categories: Alerts

The argument for moving SSH off port 22, (Mon, Jan 5th)

Mon, 01/05/2015 - 16:08

An interesting discussion is occurring on reddit on whether Secure Shell (SSH) should be deployed on a port other than 22 to reduce the likelihood of being compromised. One interesting comment is that security by obscurity is not a security measure, but a way to delay the attacker, so it provides little value. While it is true that it is difficult to stop a determined attacker who is targettingyou, any measure that stops the random script kiddies and scanners from poking at your SSH is not completely useless.

The truth is that I have been deploying SSH on non-standard ports (typically 52222) for more than 15 years on the Internet facing servers I manage. Of course this is not the only security measure I employ. use hosts.allow where practical, keys and passphrases instead of passwords, and deploy DenyHosts. Do I deploy on a non-standard port because of the security advantages to be had by security by obscurity? Not at all! I deploy SSH on a non-standard port because it eliminates all the noise that is every present on port 22. The continual scanning and attempted brute forcing of SSH that has been on the Internet since the beginning of time, and seems to get worse every year, generates a lot of noise in the logs and is at best a nuisance and at worst service affecting for the server. Why put up with it if you dont have to?

It decreases the volume so much that I often have to test my defenses to be sure they are working.


-- Rick WannerMSISE- rwanner at isc dot sans dot edu- - Twitter:namedeplume (Protected)

(c) SANS Internet Storm Center. Creative Commons Attribution-Noncommercial 3.0 United States License.
Categories: Alerts

Defensible network architecture, (Mon, Jan 5th)

Sun, 01/04/2015 - 18:52

For the nearly 20 years since Zwicky, Cooper and Chapman first wrote about Firewallsthe firewall has been the primary defense mechanism of nearly every entity attached to the Internet. While perimeter protection is still important in the modern enterprise, the fact is that the nature of Internet business has vastly changed and the crunchy perimeter and squishy inside approach has long since become outdated. You can two aspects of your business model that you cannot do without and which can give the bad guys a foothold inside your perimeter protections.

As the Sony, Target, Home Depot, and many other breaches have shown, once the bad guys are into the network they are content to dig in, explore, and exfiltrate large amounts of data and will often go undetected for months. What is needed is a security architecture that focuses on protecting data and detecting anomalies. A security architecture that results in a network that is capable of defending itself from the bad guys.

Richard Bejtlich introduced the concept of a defensible network architecture over 10 years ago in his books, but the concepts are even more important today, and are gaining traction,buthave not reached widespread adoption in the security industry.

What does a defensible network architecture look like today? In my opinion these are the minimum fundamentals to aim for in a modern defensible security design:


The fact is that most enterprise networks are very flat and provide little resistance once the network perimeter is breached. Desktops are the most likely ingress vector for malware, yet most organizations desktop LANs are very flat and desktops often have virtually unimpeded access to the entire network. Creating segregation between the desktop LAN and the critical data, stored on servers, is a huge step in impeding a breach of the network. The fact is that desktops do not normally need to communicate with other desktops. So the first step would be to segregate desktops from each other to limit desktop reconnaissance and worm type propagation between desktops. Second, the desktop LAN should be treated as a hostile network and should only be permitted access to the minimum data required to do business.

Servers should be segregated from each other, and from the desktop LAN, with firewalls. Access to the servers must be limited only to communication on ports required to deliver the business functions of the server. This applies to desktops as well. Only a chosen few who require administrative access to perform their responsibilities should have administrative access. Why a firewall for segregation, not VLANs or some other method? The firewall gives you detailed logging which can be used as an audit trail for incident response purposes.


Dr. Eric Cole has always evangelized that Prevention is ideal, detection is a must. Prevention is a laudable goal, but the fact is that prevention, in most cases, is hard. Aim for prevention where you can, but assume that whatever preventive controls you deploy are going to be defeated or fail. When the controls do fail would you notice? Sony failed to detect a number of Terabytes of data leaving their network. Would you notice it leaving yours? It is essential is to instrument your network so that detection is possible. There are two essential elements to minimal detection. The first is properly installed and managed intrusion detection, preferably at the network and host level. But even importantly is network instrumentation that will permit you to detect network anomalies. The goal is to notice deviations from the norm, in order to notice those deviations it is important to understand what the network baseline is. NetFlow data is sufficient here, but there are many network products that will provide network instrumentation that can be used for alerting, and monitoring of the network and will be critical in the investigation of a breach.

Application whitelisting

Lets get it out of the waysignature based anti-virus may not be dead, but it is on life support. The model of protecting hosts based on known malware threats is badly broken in this era of ever-changing malware. restricting access to the minimum required to do business, to the host. Deny all behaviours on the host except for those required by the applications to do business. This is a huge shift in host architecture that is probably going to be met with a lot of resistance from SysAdmins and application owners, but it is one of the few practical approaches to host defense that provides any practical likelihood of successful host defense. Application whitelisting has been available since early last decade, but it is only in the last few years that these products have matured to the point of being manageable.

This is my approach. What suggestions do you have for creating a defensible network architecture?

-- Rick Wanner MSISE- rwanner at isc dot sans dot edu- - Twitter:namedeplume (Protected)

(c) SANS Internet Storm Center. Creative Commons Attribution-Noncommercial 3.0 United States License.
Categories: Alerts

ISC StormCast for Monday, January 5th 2015, (Mon, Jan 5th)

Sun, 01/04/2015 - 18:27
(c) SANS Internet Storm Center. Creative Commons Attribution-Noncommercial 3.0 United States License.
Categories: Alerts

Get Wisdom as Cheaply as You Can, (Sun, Jan 4th)

Sat, 01/03/2015 - 16:44

A long time ago I was given advice from a non-security professional that is among the best and most influential I have received in my security career - Get wisdom as cheaply as you can. I was encouraged to learn from the mistakes of others as a means to avoid the full pain of what they were forced to experience.

There are so many places where you can get your lessons learned without having to suffer through an outage or a security incident. You can learn from news articles or breach disclosure reports such as the Verizon Data Breach Investigations Report( and Mandiant M-Trends ( Create case studies based on these sources that your incident response team can use to conduct tabletop exercises. This preparation exercise will help you determine if your prevention and detection capabilities would be effective if faced with these scenarios

To get you started, here is an example when I failed. I thought it would be a good idea to scan a special internal network segment unannounced with unauthorized equipment. This caused a full and unplanned incident response. I discovered what happened and quickly notified the team of what I did and how sorry I was for causing thisincident. Most everyone was gracious and everyone was relieved this was not a real incident. I have not forgotten this lessonand have since put checks in place to make sure it does not happen that way ever again. In addition to learning to only use authorized scanning equipment, I learned the importance of notifying all impacted system and application owners before performing any scans.

Learn from the misfortunes of others. By getting wisdom as cheaply as you can, you are given the opportunity to not have to learn the hard way. What lessons have you learned and how have you applied them? Feel free to share using our comments section.

Russell Eubanks
securityeverafter at gmail dot com

(c) SANS Internet Storm Center. Creative Commons Attribution-Noncommercial 3.0 United States License.
Categories: Alerts

oledump analysis of Rocket Kitten - Guest Diary by Didier Stevens, (Fri, Jan 2nd)

Fri, 01/02/2015 - 11:42

In his Rocket Kitten diary entry, Johannes introduces research byGadiEvronandTillmannWerner. They analyzed a PE-file embedded in the VBA macro code of anXLSMspreadsheet.

I want to show you how you can quickly analyze MS Offices documents and extract files. Just using my Pythonoledumptool, nothing else. You dont need MS Office for this analysis.

First we runoledump" />

The first line (A: ) indicates that oledump found an OLE file named xl/vbaProject.bin inside the XLSM file. Remember that the new MS Office file format (.docx, .xlsm, ) is a set of XML files stored inside a ZIP file. But VBA macros are not stored in XML files, they still use the older MS Office file format: OLE files.

oledump reports the streams it finds inside the OLE file: from index A1 through A10. A letter M next to the index is an indicator for the presence of VBA code. A lowercase letter m indicates VBA code with only Attribute statements, an uppercase letter M indicates more sophisticated VBA code, i.e. code with other statement types than Attribute statements.

If oledump finds streams with VBA macros, I always look first at the streams marked with an uppercase letter M, as these contain the most promising code.

After the column with the macro indicator M, comes a column with the size (in bytes) of the stream and another column with the full name of the stream.

Lets take a look at the VBA code in stream A3 like this: s A3 v 266CFE755A0A66776DF9FD8CD2FEE1F1.xlsm

Option s A3 selects stream A3 for analysis, and option " />

Here is a part of the VBA source code. Remark function A0: it concatenates characters generated with function Chr into a long string. If you" />

By default, you get a hex-ascii dump of the embedded file. Now you can see that the embedded file is a PE file.

Last, we dump (option " />

The MD5 of the PE file is c222199c9a7eb0d162d5e96955739447. That is one of the IOCs Johannes included in his diary entry.

Oledump can be found on my blog.

-- Didier Stevens

(c) SANS Internet Storm Center. Creative Commons Attribution-Noncommercial 3.0 United States License.
Categories: Alerts

ISC StormCast for Wednesday, December 31st 2014, (Wed, Dec 31st)

Tue, 12/30/2014 - 17:39
(c) SANS Internet Storm Center. Creative Commons Attribution-Noncommercial 3.0 United States License.
Categories: Alerts

Will 2015 be the year we finally do something about DDoS?, (Mon, Dec 29th)

Mon, 12/29/2014 - 20:33

Among the events of the past few days during the holidays was a DDoS attack on Sonys Playstation network and on Xbox Lives network. The attack was reportedly carried out by a group called Lizard Squad and by all measures is not precisely the profile of a highly sophisticated attack. Such attacks have increased in both intensity and frequency in the past year but, to an extent, are not terribly new.

The question is, why are these low-skill attacks still happening and what can be done to stop them. This week I hope to put up a series of posts on some things every organization can do, this one is the first.

Many of these attacks rely on spoofing source IPs to an open UDP service (i.e. NTP, DNS, etc) that respond with traffic much larger to the spoofed target. Since some protocols can respond with hundreds of times larger of a response than the request, it makes it easy for someone with a gigabit connection to the internet to direct large DDoSs at a victim assume they know enough open services.

The first step to deal with this problem is for organizations to stop running open UDP services without a really really good reason (which you dont have). Usually, this involves very minor configuration changes. If you do need to run open services to the internet (you dont) than to use rate-limiting to prevent the service from being abused.
Does your network run any open UDP services? There are 4 websites that will help you find such services on your network.

These are the four biggest offenders in reflective DDoS attacks and eliminating them would go a long way to taking a bite out of the DDoS threat. In all cases, there are good reasons to disable the services even if you are not a victim. First, could be the potential of civil liability from a victim. Second, is the possibility of information leakage (i.e. SNMP).
Be sure to check your organizations IP space and for fun, check your home networks as well and/or your favorite WiFi hotspot.

If we all take some time to clean up our small corners of the net, we can start tamping down on DDoS and get back to our XBox.

John Bambenek
bambenek \at\ gmail /dot/ com
Bambenek Consulting

(c) SANS Internet Storm Center. Creative Commons Attribution-Noncommercial 3.0 United States License.
Categories: Alerts

ISC StormCast for Tuesday, December 30th 2014, (Tue, Dec 30th)

Mon, 12/29/2014 - 18:48
(c) SANS Internet Storm Center. Creative Commons Attribution-Noncommercial 3.0 United States License.
Categories: Alerts

ISC StormCast for Monday, December 29th 2014, (Mon, Dec 29th)

Sun, 12/28/2014 - 18:03
(c) SANS Internet Storm Center. Creative Commons Attribution-Noncommercial 3.0 United States License.
Categories: Alerts

"Rocket Kitten": Is it still APT if you can buy it off the shelf?, (Sun, Dec 28th)

Sun, 12/28/2014 - 06:36

Gadi Evron and Tillmann Wernerpresented an interesting case at 31C3 Conference in Hamburg yesterday, that shows how commercial software can be used to launch APT style attacks. In this case, several similar attacks where discovered against targets in Israel and Western Europe. In all cases, the attack started with a simple Excel spreadsheet which was sent as an attachment[1]. The email itself was brief and unremarkable, but used fake and plausible From headers.

Gadi was nice enough to share with us some screenshots of these attachments. They are all very plausible for the targeted recipients. Click on the thumbnail to see the full size image (these are images, not the original Excel files)

Screenshots of Excel E-Mail Attachments

Each Excel file included a macro.While the use of Excel Macros and the simple e-mail message initially looked like an old and simple exploit, thebackdoor caught the attention of Gadi and Tillmannwho assisted with the reverse analysis. It turned out more sophisticated and stealthy then what was found in standard crimeware.

The Excel macro consisted of two files. One was an encodedPE binary, the second a simple VBA script to decode the PE binary, write it to disk and run it. This binary is where things got more interested. It implemented a very capable backdoor, essentially proxyingsystem calls, allow for very flexible access to the system not limiting the attacker to aset of pre-defined commands.

In the end, it turned out that the entire attack was performed using Core Impact, a pricey, but highly sophisticated product allowing for point and click attacks of a level that are typically used for APT attacks [2]. In particular when attributing attacks like this to Nation States, or suggesting that the attacker has to be highly sophisticated and able to write custom exploits, one has to consider the possibility that the attacker just re-purposed commercial pentesting software like Core Impact, or even open source tools that offer similar features. The budget for such an attack typically is well below $100kto purchase the required software, a number that is well within reach of even minor nations or organized crime groups. In some cases, it may be possible to find pirated copies fo the required software. Another advantage of using commercial software is the ability to ask for support or professional services to help you with your APT attack.

Oddly, the backdoor was not recognized by anti-virus tools, even though Core Impactis a commonly used product. Core impact also fails to tag any of the software with a customer specific serial number, hindering attribution in cases like the one above. Such a serial number would not prevent an authorized pen test, but would help attribute unauthorized attacks.

For more details, I highly recommend that you watch Gadi and Tillmann[1].

[1] (The talk starts around 15 min into the recording)

Indicators of compromise:

IP Addresses

MD5 Hashes


Johannes B. Ullrich, Ph.D.

(c) SANS Internet Storm Center. Creative Commons Attribution-Noncommercial 3.0 United States License.
Categories: Alerts

Honey Pot Entertainment - SSH, (Sat, Dec 27th)

Sat, 12/27/2014 - 08:43

The Christmas period is a nice time to play with some honeypots and share some of the info they have been collecting. Currently I only have two functioning, both of them are located in the US. Each receives 20K or more login attempts per day. Im using a standard kippo installation, running as a non root user and using authbindto run the honeypoton port 22. Results are sent to a logging server for collection.

One of the honeypots has no valid password so it will always fail Im mainly interested in collecting the various userid and passwords used in the guessing attempts. The other one does have a valid password and I regularly expand its interaction by providing the correct responses utilising the kippo capabilities. The password can be changed by modifying the data/userdb.txt file in the kipposubdirectory. The interaction can be improved by issuing a command and capturing the output and placing the resulting file in txtcmds directory. For example sftp is often the first command issued.Locate where sftpis running from (usually /usr/bin). Create the structure under the honeyfsdirectory, e.g. honeyfs/usr/bin/sftp. Issue the command sftp and capture the output to a file called sftp and place it in the txtcmds directory,follow the same structure so txtcmds/usr/bin/sftp. Now when the command is entered it will get a response and hopefully you will get additional results.

So some stats for December:
  • Unique Passwords used: 136,029
  • Unique Userids used: 305"> Most common guessed password Most Common Userid " />

    Dirtiest subnets

    The following are the /24 subnets that are most active with a high number of hosts from the same subnet attacking.

    • - HK, CN - AS 63854
    • AS 4134 -
      • - Huzhou, CN
      •">-">-">, CN
      • - Nanjing, CN
      •">-">-">-">Based on the above Im quite comfortable in saying that blocking anything coming from AS4134would not be a bad idea.


        The passwords used in the attempts are quite varied and range from the simple as shown above to much more esoteric and complex passwords such as">!!QAZ@@WSX##EDC,!!Er.HAA22a098yIGH@_Z@,">%TGBVFR$#EDCXSW@,WORLDEDU20121123.">stop

      There has been some increase in scanning over the past month or so. My previous Honeypotrun in August 2014would max out at 1500 attempts per day. The main surprise to me was the wide range of passwords being used. A number of them seem to relate directly to specific types of hardware installed such as modem/routers. Others look like quite robust passwords and may have come from the various password compromises this year. The main message is that ifyou are running an SSH server it will get attackedand youd best have some decent passwords and ideally use certificate authentication to secure the server.

      If you want to run your own, Im a fan of kippo, it is simple to set up and there are plenty of guides on how to do it. Make sure you run it on a box that is not a production device and secure it. You do not want to become a staging point for attacks.

      If you want to submit your kippologs, Dr J in this diary provides the perl to do so.


      Mark H - Shearwater

      (c) SANS Internet Storm Center. Creative Commons Attribution-Noncommercial 3.0 United States License.
Categories: Alerts

Gate to Fiesta exploit kit on, (Fri, Dec 26th)

Fri, 12/26/2014 - 18:39

This is a guest diary submitted by Brad Duncan.

For the past year or so, Ive noticed a particular group using a gate that redirects to an exploit kit (EK), usually Fiesta. This gate has evolved over the past year, changing IP addresses, domain names, and URL patterns. Currently, this gate is using as its IP address.

I infected a VM on 2014-12-24 using the original referer from an example I found after searching for in my organizations web traffic logs. The image below shows the gate on and Fiesta EK on

Shown above: Wireshark display for the Fiesta EK infection using this gate.

Monitoring the infection traffic with Security Onion shows the appropriate Snort signatures for Fiesta EK:

Shown above: Snort events from Security Onion using the ET open signature set.

Lets examine how the gate points to Fiesta EK. Earlier this year, the gate used a fairly straightforward iframe. Heres an example from April 2014:

Shown above: Gate to Fiesta EK from April 2014.

The current gate has a much longer javascript, and the URL for Fiesta EK is slightly obfuscated. Heres the example from 2014-12-24:

Search your web traffic logs for, and youll likely find several different domain names using a specific pattern for the gate. Heres a sample of what I found for from 2014-12-10 through 2014-12-23:

  • - GET /?_SPMq=vahK1gfvq3z1_Aj=fW8sL8ldnkPgy=81S8Y0_0Us9=dr_fSq3Jaiw7Eaf=fu5dv5wDK9=Ydqk1z4o652YRK=eHl9jdJ8jI86__=He0S4m9GQPy3i=J4HP58S7hdRPS8=7bi7Y
  • - GET /?LDZhT=Kegl8uezbqbx6n_Nk98=Pa59bTd3_Jp3B=k9hKcTeG_eS30mwpoA=k3OmaPs700bKE03=6800L6Kf_S_Z2l=z1Hge2_s2R0M0M
  • - GET /?eg4yxQ=49eU6k7bIcPB5=ei8YapbIdQubUz3qMUy=w8H4iaz2Q1sePdZV4Zg=1hcfLh96u07x
  • - GET /?L_T=XfmqeN3LeQ97Wbwa7G6UOJgt=M1q6pbX2Xe_I8eK2n7aUsdm_v=MerQ5S5q6R9taM0IaIyfL3HSLF=5c
  • - GET /?tBbJ=286uU9rtikG=zaoY7Q_0KT8F0BREM=_4S3n0w9a2NE=9_d2Kz6ptmh=f87qmaaOc=2UQ5L1U1gWEfu6e=kcn_61M1srqR=R2s_9S9dGMvn=7b
  • - GET /?jtDO_=6pcoex6X_9I1TK9qJckr1Go9t3UL0sdQ_5LCsM=W3WO4NcvQ4M2tifG8ll9GXdxcgG0Q8Iz8Zn7M
  • - GET /?m9SO_=y2Nbh6pd_0j9Mw84xF=6h1WubuKajeV4KebW6dQc=w6UcT2aK1f2Tmj7=b_0u9j7Za_aV0vUhf=ma
  • - GET /?3W_wN=I40_W5_eht=t8vP8M8L2ad_uO=33KPa_s3oi=8P5_7QLfo=cHai8wZM7P_K=bSG7TH3pUKb38=1s4wx2sjSJyB=cM7c
  • - GET /?sk9=7ufJ8Ky7H8nS34n7f1h8t887R49eDf=1foPbZaw1VcxcHlfJdVw83P69hP1uSdYbR
  • - GET /?V7k2sF=sbLLbi2fp9p073kddzfGanaT5K1cGqdUQG=tc8Z8G0kav2v7QY5gf3I2Z8y5_V0v3dJ0P
  • - GET /?Cid=nak4G9zUkE3K=3i6iq9dUjM6_=Xe0seJ_X_g=R4taaJr4YHO=q9HQ34Px1_=3gaZ4HDVhN=v4v326t_=bu_1OX3OkFP=7y_5rv7
  • - GET /?m_FxE=eh0MkFq=H8GeSfz7=1l3d2T6r=aeLeH_9=k0Il2WZ7i6=3S17h_=SdlczmGAU=i0ufmMwf=ehp5pymV7T=y7lKeJpk_DF=_5_2
  • - GET /?_I4XS=idKbueq4kR1q80TsZ=Y0Wn7Lbr6K9hchthXvW=56WPaqG2OdJ0Ff_lty=x21dbrs8y5
  • - GET /?rQRqX=aj2us3_9Z4dBzt=h4uKf3l7eVSIDj=5rd_7zcN0g2Btxc=aief3k7oGC=X6g62bgw9hNUZHg=_5Q4scVc
  • - GET /?Zd_E=Zd_0Q9_5SZbUU32Z4m4bOchhflz2g5n1h7_b6XgctsIVh=M8gcrO2yw78886tz8Zf6Ycba_cRd0o1Vk1
  • - GET /?e2_Iq=652WNczup=V1Z7I2wR9m5_zQ=k3YT7O4H3_Dy2bH=t9nsbcbmGm2J_=1Kf_Ib0gq_BF=98m6

All the above domains are registered to same organization:

Registrant name/organization: Wuxi Yilian LLC

Registrant country: China

Registrar: - date registered: 2014-08-29 - date registered: 2014-10-27 - date registered: 2014-12-01 - date registered: 2014-11-12 - date registered: 2014-10-21 - date registered: 2014-11-12 - date registered: 2014-09-18 - date registered: 2014-12-01 - date registered: 2014-09-18 - date registered: 2014-12-01 - date registered: 2014-12-01 - date registered: 2014-10-21 - date registered: 2014-10-03 - date registered: 2014-10-27 - date registered: 2014-12-01 - date registered: 2014-11-12

Each of the domains on is tied to a particular compromised website. If you have access to the web traffic and the HTTP headers, its easy to find the compromised website. Just look for the referer in the HTTP GET request on

The group behind these domains has used at least 4 different IP addresses during the past year. It will likely change again. Wuxi Yilian LLC is the registrant for all the domains Ive found for this redirect in 2014.

I look forward to seeing what this group does in 2015.


Brad Duncan is a Security Analyst at Rackspace, and he runs a blog on malware traffic analysis at

(c) SANS Internet Storm Center. Creative Commons Attribution-Noncommercial 3.0 United States License.
Categories: Alerts