Solutionary Minds - Your Information Security Blog Source

Trusted Information Sources: Discern Between Truth and Deception

Thu, 23 May 2013 03:00:00 GMT

One of the biggest challenges that security researchers face in the ever-changing world of emerging threats is how to assimilate information from only reliable and valid sources. Sources may include: newspapers, documents, videos, search engines, social media, and various other information stores. With the diverse amount of information available, there is always a significant challenge in identifying what should be used when faced with information that is conjecture, speculation, erroneous, as well as information that is deliberately designed to be deceptive.

How can one tell if information is valid or a method of deception?

First check what you have read against the results of an Internet search query. Best practice would be to only trust information that can be verified against three or more additional sources, of which provide the same detailed information.

Next be aware that social media is the primary method in which individuals, or groups, have spread disinformation in order to create panic or misdirect users. This is why high-profile, social media accounts become prime targets for criminals and hacktivists. Here are a couple examples of this happening:

http://thelede.blogs.nytimes.com/2012/08/05/hacked-reuters-twitter-feed-used-to-spread-disinformation-about-syrian-rebels/

http://www.networkworld.com/community/blog/hacktivists-take-olympus-has-fallen-scare-tactics-style/

So, place an extra cautious eye on information you get from the Internet, specifically social media, and verify it before you take any action.

www.solutionary.com

Cool Addition to the Metasploit Framework

Tue, 21 May 2013 03:00:00 GMT

In a recent update, the Metasploit framework added a very interesting tool called mimikatz to its massive tool repository. The tool enables you to steal Windows® credentials. Why is this important? There already are many ways to steal credentials from Windows with Metasploit. The key feature of this tool is that it steals the credentials in clear text instead of just the password hashes.

If you do any research on the Windows authentication process you will quickly find out that Windows does not store a clear text version of your password. Windows only stores a hashed version of your password. Mimikats collects the credentials from the WDigest dll. The HTTP digest authentication and Simple Authentication Security Layer (SASL) authentication modules use the WDigest dll. Both of these authentication modules require the user's plain text password. Mimikatz takes advantage of this and is able to extract the credentials in clear text.

As a stand-alone tool, mimikatz can be run locally and remotely but does need administrator privileges to run. If you gain access to a machine through one of the many exploits available in the Metasploit framework, you can run the tool from memory and collect the credentials in clear text. The benefits of getting the password in clear text are that there is no need to crack password hashes and reuse the password in the Windows environments.

www.solutionary.com

Announcing the New Solutionary.com

Wed, 15 May 2013 03:00:00 GMT

Followers of the Solutionary Minds blog and frequent visitors to Solutionary.com may have noticed some significant changes to the web site. First-time visitors will not realize that anything has changed at all (trust me, it has). After months of work, the Solutionary team is happy to unveil the latest iteration of the Solutionary web presence.

A few of the highlights include:

More video - See Solutionary team members discussing a variety of topics.
Resource Center - Find Solutionary content like datasheets, white papers and webinars here.
News and Events - See our recent media coverage, press releases and an interactive calendar that allows you to click on any specific date throughout the year and find out what Solutionary will doing that day.
Blog - The "Solutionary Minds" blog has been moved from its previous location, blog.solutionary.com to be part of the web site at www.solutionary.com/resource-center/blog/. If you follow our blog, make sure to bookmark the new page or subscribe to the RSS feed.
Enhanced Career Center - If you're looking for your next IT security job, check out Solutionary job openings to see if there's a fit for you.

Be sure to check back frequently to see what else is new on the site. We'll be updating the new site frequently with Solutionary news, threat intelligence and fresh content. If you have feedback for us, please contact us or leave a comment below.

www.solutionary.com

Memory: It's What's for Dinner

Thu, 09 May 2013 03:00:00 GMT

Memory is the new vogue and rightfully so. My Solutionary teammate, Susan Carter, recently posted a related blog. Ironically, we were both crafting our posts about the same time but I want to drive home the importance of capturing volatile data and performing memory analysis.

In the past, forensics examinations involving computer systems were always performed by immediately disconnecting any compromised or infected hosts from the network. This is done with a “hard shutdown” or what has become known as “pulling the plug” and immediately acquiring a forensics image acquisition of the hard drive. The rationale for doing this as the first step is to preserve the state of the hard disk.

Now, the first step in any incident response scenario should be capturing the volatile data at the onset. This has become critical to identifying the extent of the compromise or infection. In fact, in some cases, volatile memory analysis is the only way to identify the nature and extent of a compromise. This is because the contents in RAM are cleared when the computer is shutdown and all traces of the potential malicious code, any commands given, and data exfiltrated may no longer be available on disk.

I’m not going to go into detail about how volatile memory operates, but I do want to explain why it is important to acquire volatile memory as the first step, rather than following the “pulling the plug” technique of the past.

Performing memory analysis contributes significantly to any forensic examination and not just a malware infection. Memory analysis overcomes several limitations of traditional forensic analysis especially when encryption is involved. But most importantly, memory analysis overcomes the inability of the physical disk image to reveal information about processes that were running in memory at the time of compromise.

Some of the information that can be obtained from memory analysis are:

Processes
Loaded DLLs
Open files and registry handles
Network information
Passwords and cryptographic keys
Unencrypted content
Hidden data and files
Malicious code
Command line arguments

Volatile memory can store a great deal of information, but the problem is finding a tool that can properly parse the data that is contained in the memory image. There are a few tools out there but my favorite that I have used is a tool called Volatility.

Check out a previous post, Hunting Malware with Memory Analysis, for more information on the use of Volatility.

And, pull the network plug, not the power plug…

www.solutionary.com

Into the Rabbit Hole: Protocol Anomaly Detection

Tue, 07 May 2013 03:00:00 GMT

Today we are going to explore the fascinating world of (say it with me) protocol anomaly detection. That’s right kids; it’s the controversial, often imitated, but never duplicated topic that will cross an analyst’s desk at least once in their career.

Since my early days in information security protocol anomalies have been a long-standing interest of mine. I first read about them on the SecurityFocus, Incidents mailing list. I watched as post after post went back and forth about protocol anomalies, debating what was an anomaly and what was not. The debate was never settled, and probably never will be, so we can all probably agree to disagree. I was intrigued by the mere mention of its name. Like an unmarked shiny red button I wanted to push, “Ooohh what’s that?” Some will either share in my fascination or run in the other direction.

For the purposes of this article, we are going to approach protocol anomalies from two angles:
1. Anomalous findings in protocol structure
2. Anomalous findings in the payload

To keep things simple, think of protocol anomalies as things that do not belong in the given packet you happen to be analyzing. For instance, if you are expecting an “a”in a packet and get a “B”, this could be considered an anomaly. It does not necessarily indicate that something malicious has happened, only that something is not right or expected in the packet.

When Anomalies Attack

Outside of identifying the anomaly itself, determining if something is malicious is the most difficult part of anomaly detection. Some anomalies are easily identified, while others are slight changes that can just as easily be overlooked. You may be thinking you can just reference the Request For Comments (RFC) for the protocol, since surely everyone follows that standard. After all, it is practically Internet law. In a perfect world, you would be correct.

Unfortunately, many vendors have tweaked, added, modified and improved protocol standards for any number of reasons. Some of the changes are highly documented, while others were implemented once, and then forgotten long ago. Malware authors know this and use it to their advantage, while banking on the fact that not many people are going to be well-versed in every facet of a protocol, let alone pay that much attention to traffic on the network. When you have a large Internet connection with thousands of users and multiple peering connections, anomalies are important, but are often only acknowledged if all the bells and alarms are sounding to indicate something is wrong. Not everyone will be sitting around with a box of wine, some Yanni or Kenny G (depending on your mood), curled up with the Protocol Standards Anthology, to relax at the end of a long day. This is not an excuse or justification for not monitoring network traffic, only an acknowledgement and realization that, even in the most secure infrastructure, it is possible for things to be overlooked. How do we cover it all? For starters, we choose our battles, and eat the elephant one bite at a time.

For now, we will focus specifically on ICMP traffic. ICMP packets are often used as beaconing or signaling packets by malware authors. ICMP is effective because many networks will allow it to roam freely both inside and outside of the network, and many perimeter security devices are only concerned about the total number of packets, and maybe if the packet is too small or too large (referencing some legacy attacks). To follow the rest, we should first have basic understanding of these important characteristics of ICMP:

ICMP is a connectionless protocol (not really concerned about ports, reliability and receiving a response)
ICMP can be adapted to fit specific network situations
Some operating systems may use static ICMP data payloads

If you really want a deep understanding of the ICMP protocol, refer to RFC 792 for further details. Per the RFC, ICMP packets may have incrementing sequence numbers for each request and reply packet. This holds true for most, if not all, everyday ICMP usage. Normally, ICMP is associated with the Ping utility for determining if a host is available along with any network latency. Windows-based computers dating back to at least Windows 2000 have been using the alphabet as the standard payload for ICMP packets. Check out the ICMP payloads for other operating systems, to see if there are any differences or similarities. Figure 1 below shows a typical Windows based ICMP packet.

Identifying the Anomaly – Nmap Ping

Figure 1

As mentioned earlier, it is not uncommon for software developers to create custom network packets to be used in their applications. Naturally, this sentiment holds true for malware authors as well. The popular network-scanning tool Nmap or Network Mapper uses custom ICMP Ping packets for one of its scanning options. On its own, Nmap is not a malicious tool. There are many legitimate reasons for employing its vast functionality. But, when the tool is used and applied to support the dastardly deeds of a malevolent mind it can become quite troublesome.

Figure 2 displays a snippet of ICMP traffic from the packet capture covered in the previous article. You will notice the packet sizes and sequence numbers are different. In accordance with the RFC the reply packets should be the same size as the request, and the sequence numbers should also be in contiguous order. (It is worth noting that the specific ICMP Identifier fields (id=) may also be an anomalous trait associated with Nmap. The RFC does not specify if the field must adhere to a standard, however it can be used in identifying request/reply relationships or be set to zero. During this particular scan the identifier changed, while when ICMP is used for standard requests the number often remains constant.)

Figure 2

A deeper look into one of the request/reply pairs reveals that the ICMP echo request does not have a data payload. The RFC does not require any data be included in the packet, however, many operating systems including Windows and Linux implement their own data payload. Figure 3 displays the ICMP request packet and the padded return packet sent from the responding host since no payload was provided.

Figure 3

Conclusion

In this article, we briefly discussed a few protocol anomalies in ICMP packets. Truth be known, we could probably write a book on the subject in IPv4. It is quite possible for packets to change with each version of an operating system or application, as functionality is improved. To get you started with identifying anomalies in ICMP, here are a few items that should be checked:

Payload
Packet size
Sequence numbers
ICMP type
ICMP code

Remember, not every anomaly is malicious. An anomaly could be something related to a product or custom internal application. If you are not sure, start analyzing the protocol and the hosts involved. This is the only way to truly know if something anomalous is malicious. Have fun exploring the great unknown, in your own venture into the rabbit hole.