Threat Geek

Hiding in Plain Sight

“Engage people with what they expect; it is what they are able to discern and confirms their projections. It settles them into predictable patterns of response, occupying their minds while you wait for the extraordinary moment — that which they cannot anticipate.” ― Sun Tzu, The Art of War

If you find yourself having difficulty identifying with the quote above, try re-reading it with the understanding that you and your organization are the target.

Cyber warfare is an asymmetric challenge in which the advisory holds almost all of the cards. There are an endless variety of methods by which those wishing to compromise your systems can attempt to do so, however we are quickly gaining ground in the fight through hard earned knowledge and have begun to lay down best practices which when applied and enforced can significantly lower the avenues of approach to your sensitive data, intellectual property or financial assets.

BORED BETWEEN CASES?

Bored between cases? Check out this portal that shows real-time attacks hitting Deutsche Telekom honeypots (http://www.sicherheitstacho.eu/). According to Thomas Kremer (Board Member for Data Privacy, Legal Affairs and Compliance), Deutsche Telekom has taken a proactive approach to perform threat monitoring. The company has taken the lead in coordinating attack information from over 90 honeypots, 55 of which they own. The honeypots collect over 400,000 attacks per day (that’s 4-5 attacks per second). According to its news release, the company uses the data collected from the honey pots to create or enhance defensive capabilities. The website uses a view of the globe and when an attack occurs, a red dot on the source country is pinged. Around the map are statistics from last month for the top-15 source countries, top-5 attack types, types and distribution of attack targets and the total of both attacks and attackers per day.

I would expect nothing less from a telecommunication provider. What I did not expect was to find an online portal with real-time statistics of the attack vectors directly from their honeypots – at least not without some sort of login.

Another popular real-time and graphical honeypot reporting website is honeynet.org (http://map.honeynet.org/), which was also created by two Germans.

I can understand why academic researchers like Florian Weingarten and Mark Schloesser, both from HoneyMap, would create and publish such a webpage, but why would a company that sells to businesses, governments and consumers do the same? What would justify spending money and resources in publishing a graphical interface displaying attack sources as they happen? One could make an argument for corporate social responsibility (CSR) or business ethics, but I don’t want to waste brain power on the steganographic marketing scheme that is CSR. Instead, I would like to assume that a company like Deutsche Telekom would be motivated to create a gratuitous offering of information similar to why a company would place their corporate headquarters in sharp and professional-looking buildings with trimmed foliage exteriors and inviting interiors. The goal is to present to future customers and existing customers that the company is serious about business and will be around for a long time. Similarly, presenting a honeypot attack map demonstrates to existing and future customers that the company is committed to investing in what they see as being (potential) future costs in terms of breaches into its own network or customer networks. The bottom line is that, as with most everything in cybersecurity, the ROI on investing in threat analysis rarely ties directly to short-term and direct revenue lines. Instead, companies like Deutsche Telekom realize that investing in threat analysis affects long-term and indirect revenue lines.

The Deutsche Telekom website is a product of a partnership with the Allianz für Cyber-Sicherheit (Alliance for Cyber Security), a government-sponsored joint initiative between the German Federal Office for Information Security (BSI) and the German Association for Information Technology, Telecommunication and New Media (BITKOM).

T-Systems (an operational subsidiary of Deutsche Telekom) maintains the site and is Germany’s largest and one of the largest European IT services companies. Viewers will immediately recognize the letter “T” in the company’s logo because Deutsche Telekom also owns T-Mobile. T-Systems provides primarily B2B and B2G services with other operational arms of the company providing mobile, landline, broadband and TV services. According to its 2012 annual report, Deutsche Telekom reorganized its internal IT infrastructure by consolidating them into a new Telekom IT unit. Based on my experience in working with global organizations, consolidation not only saves cost but it can foster positive collaboration and information exchange, assuming leaders promote such collaboration and exchange within the newly consolidated environment. Without knowing the inner-workings of the new IT organization, the honeypot sensors and information output appear to be very encouraging effects of positive information sharing.

-Ryan Vela

UNDOING XOR AND PADDING AT LINE SPEED

Obfuscation is a tool employed by many malware writers and delivery agents. As always, the easier it is, the more attractive it is to those out to do harm; simple and easy are king in this world. XOR happens to meet both of these requirements - it is dead simple and since it exists as a fundamental operation at almost every level of computer and system architectures, it is extremely easy to use. Another of the popular tools used is padding or the addition of superfluous bytes to the beginning, middle or end of an artifact, to move the content starting point, making it difficult to detect, to hide start of content markers or to distort hash signatures.

XOR is a simple to understand and use function that is the basis for all cryptography. It is a way of encoding content so that it looks like gibberish and as such can’t be detected. It is done with a “key” that can be one byte in length up to a key the length of the content itself. The longer the key is, the higher the difficulty in decoding or cracking it (Fidelis XPS can discover XOR encryption keys of longer than length one, with or without padding - at line speed). Padding is the addition of extra bytes of filler content, usually to the beginning or end of the content but sometimes in the middle. So that is what XOR and padding are and how they are used for malicious purposes. Now we'll take a moment to dig in and understand this fundamental topic further.

XOR or 'exclusive OR' is a logical operation. Think of it like a box with two inputs and one output. Each input and the output can have only one of two states: true or false. True can be represented by a binary one and a false can be represented by a binary zero. If one and only one of the inputs is true then the output is true. If both inputs are false or both inputs are true, then the output is false. Said another way, XOR is true if an odd number of its arguments are true and false otherwise. In truth table format where A and B are the inputs and Y is the output, we see:

 A  B   |  Y

------------

0  0     |  0

0  1     |  1

1  0     |  1

1  1     |  0

In plain English, if the inputs are the same, the output is false and if the inputs are different, the output is true. So now we know what XOR is but we need to take a look at it in use to understand why and how people use it to implement basic encryption.

As previously mentioned, the reason why XOR is used is two-fold. First, the logical XOR operation has the property that the same key applied again with another XOR operation undoes the encryption. This makes it very easy to use. The second reason it is used is that XOR is one of the fastest operations a computer can do. It's implemented in electronics at the gate level and can be done extremely quickly and by using very few system resources. In fact, this is such a fundamental operation that most computers have an XOR instruction as part of their opcode or machine language set. This means that even for very long keys, it is extremely quick to perform the operations. The bad news is that it's not very good with encryption because the keys can be guessed by brute forcing all combinations - again being quick to implement it doesn't take long to iterate and since the input space is 8-bit characters, there are only 256 combinations to try for a single byte. The longer the key, the longer the guessing game takes (one byte = 256 combinations, two bytes = 256*256 = 65,536 combinations and in general, n bytes take 256ⁿ tries in the worst case) and at line speed.

Padding is just the insertion of extra bits or bytes in front of something to hide it. If you know you added four bytes at the beginning of an artifact, after that file is transferred it won't be recognizable anymore and by extracting those four bytes at the beginning of the file once the transfer is complete, you get the original file again. Anything looking for a particular file signature that doesn't know to begin looking four bytes in will only see your padding values and be unable to recognize the original file type. When you combine basic padding with the XOR encryption described above, you get a fast, easy and simple way to hide from many in-line and line-speed appliances and also from many software security solutions. 

As an example of how this looks in the real world, let's look at the letter A. It has ASCII code 65 in decimal which is 01000001 in binary. You can do these conversions quickly by either looking up an ASCII table (provided at the end of this document) which sometimes has the decimal (base 10), hexadecimal (base 16) and binary (base two) representations or by opening the Windows calculator, clicking on View and then select Programmer. Type in the number in calculator with the Dec selector on the left checked and then click on one of the other bases, like Bin for binary to show the number in that base.

Taking the ASCII code for A, we can take each binary digit and exclusive OR it with a "key." Let's choose a random value to use for our key, say the decimal number 15 or 00001111 in binary. So we'll do the exclusive OR and see what we get:

0 1 0 0   0 0 0 1    Letter A

0 0 0 0   1 1 1 1    Key = 15

-----------------------

0 1 0 0   1 1 1 0    Answer = 78 or ASCII character N

This operation is applied bit by bit. In the letter A, starting at the right-most bit which is a one, the key also has a one in this position. Using the truth table above, we see that a one and a one on the inputs results in a zero on the output so the Answer has a zero in the right-most bit position. We move left one bit at a time, repeat the process and get the Answer string. Something interesting happens if you apply the exact same key with another XOR operation:

0 1 0 0   1 1 1 0   Original answer of 78 or ASCII character N

0 0 0 0   1 1 1 1   Key = 15

-----------------------

0 1 0 0   0 0 01   Answer = 65 or Letter A

In fact, two XOR operations with the same key always return the original value! This is the basic premise of a shared-key (symmetric) encryption. 

What we have demonstrated here so far is a single byte XOR key. Let's take a look at a short message and a two byte key.

This time our message will be longer than a single character, let's use the word: SECRET. In ASCII this is 83 69 67 82 69 84. The key we'll choose is the two letter combination GD or in ASCII, 71 68. Since there are more than two letters in the message, we'll repeat the key over and over - we need one byte of key for each byte of message:

                                 
                                                  83            69             67            82            69            84

ASCII Message: SECRET   1010011  1000101   1000011 1010010   1000101   1010100 

Key (repeated): GDGDGD   1000111  1000100  1000111  1000100  1000111    1000100  

      
                                     --------------------------------------------------------------------------------

XOR result (cipher text)       0010100  0000001  0000100  0010110  0000010  0010000 

Decimal equivalent                   20             1              4             22              2             16

(none are printable characters)

If we apply key again, as expected we get the original message back:

XOR result (cipher text)       0010100  0000001  0000100  0010110  0000010  0010000 

Key (repeated): GDGDGD    1000111  1000100  1000111  1000100  1000111  1000100   

    
                                   ---------------------------------------------------------------------------------

ASCII Message: SECRET      1010011  1000101  1000011  1010010  1000101  1010100

Had we applied only one byte of the key, the G for example, every other character would have been decoded:

XOR result (cipher text)        0010100  0000001  0000100  0010110  0000010  0010000 

Key (repeated): GGGGGG     1000111  1000111  1000111  1000111  1000111  1000111 

                                   ---------------------------------------------------------------------------------

ASCII Message: SFCQEW      1010011  1000110  1000011  1010001  1000101  1010111 

As we see, only every other character is correctly decoded as the second byte of the key is wrong. Note there is no limit to the size of the key; you can use as many characters in the key as you have letters in the plaintext message. You can easily see how many guesses there are to getting an eight-byte key and why it can’t (as yet) be done at line speed, even with some very clever programmers.

Being able to see that a file has padding, that it is XOR encoded/encrypted and to undo that encryption at line speeds is a quality you should look for in any solution purporting to detect malware, malicious activity, data exfiltration and other security concerns. If you can't see the payloads then you can't make decisions on them and that traffic is hidden to you.

Additional Materials

ASCII Table in Decimal, Hexadecimal and Octal

ASCII Table Providing Direct Binary Output

Note: A is 65 decimal = 1000001 so you read the left-most three bits from the top row and the right-most four bits from the left columns, left to right for the seven-bit ASCII code. Put a zero in the left most bit if your key is a true 8-bit value.

-Darian Lewis

THREATTOONS: HOW LONG HAS IT BEEN SINCE YOUR NETWORK HAD A CHECKUP?

Want a THREATtoon on your blog or website? Great! Simply cite the cartoons original Threat Geek URL under the image and you’re good to go.

ZEUS' SHINY NEW LIMO: LINUX/CHAPRO.A

What became old is new again.  It's a mantra in the security community and you can bet if you run across a new threat that even after it dies down that it will be back for a visit at some time in the future.  ZeuS, a bot that made its fame in 2007 is following that philosophy quite well.  For those wanting a brief reminder, ZeuS is a banking trojan that steals information by key logging and scraping forms submitted by users.  It has already made one such resurgence in 2009 when it targeted organizations including Oracle, Bank of America, Amazon, NASA and others.  The FBI made arrests of over 90 persons in the US with additional arrests made by the UK and Ukraine as part of an international crime network found to be distributing this tool.  A third round came about in 2011 when a new version of the ZeuS source was leaked showing some new P2P communication capabilities.  The FBI released a nice graphic showing exactly how ZeuS is used to get money. This bot is so pernicious because it is stealthy and evasive.  A tracker was set up by abuse.ch just too monitor the use and spread of the infection that can be seen at https://zeustracker.abuse.ch.

The past two months in 2012 have shown it rearing its ugly head for another round.  This time a new delivery mechanism has been spotted for delivering the bot: Linux/Chapro.A.

The infection is done by way of an Apache plugin.  "The process described by Eset goes like this: a user requests a supposedly-innocent Web page from a compromised server, which contacts its command and control server. The C&C machine sends compromised content – like an iframe – back to the Web server, which sends the malicious content to the end user.  That leaves the user infected with Zeus, and under control of the exploit hosting server."

After infection, the host then sends information to a C2 server at approximately 10 minute intervals.  These are short (37-byte) messages via HTTP POST which look like:

C=1&version=2012.08. 07&uname=Linux

"The request is simple; it only includes the version of the malware  and the operating system it is running on.  The command and control server will respond to the query with the iframe to be  injected by the malicious apache module. The iframe is encoded using base64 and XOR. If a visitor does not fall into any of the blacklists detailed in the previous section, it is served the iframe downloaded from the command and control server." A cookie is then dropped to ensure that infected servers hide and don't get payload again.  

The IFRAME sent is encoded using Base64 and XOR.  The IFRAME points to a "Sweet Orange" exploit pack which tries to use one or more of the following exploits:

* CVE-2012-5076: Java JAX-WS Class Handling

* CVE-2012-4681: Java getField Method Class Invocation Privilege Escalation

* CVE-2006-0003: Internet Explorer MDAC

* CVE-2010-0188: Adobe Reader LibTiff Integer Overflow

The Sweet Orange exploit claims that around 10% to 25% of those who land on the malicious website will be infected, adding around 15,000 bots to the botnet daily. 

A German site was originally hosting the C2 server but has recently gone offline.  It is a good bet it will reappear in another country shortly.

Files which have been seen in the wild in conjunction with this attack include:

Linux/Chapro.A              MD5: e022de72cce8129bd5ac8a0675996318

Injected iframe                MD5: 111e3e0bf96b6ebda0aeffdb444bcf8d

Java exploit                       MD5: 2bd88b0f267e5aa5ec00d1452a63d9dc

Zeus binary                        MD5: 3840a6506d9d5c2443687d1cf07e25d0    

Detection of this new ZeuS delivery mechanism could be done in a number of ways including:

1. The MD5s of the binaries but these are likely to change and only be effective a very short period of time

2. The characteristics of the short POST (37 bytes) and the structure of that message: C=[0,4].&version=2012\..[6,8]&uname=.[0,20] to C2 servers

3. IFRAME with Base64 encoding and indications of XOR encryption in the HTML stream

Sources:

http://www.theregister.co.uk/2012/12/20/apache_dangerous_plugin/

http://blog.eset.com/2012/12/18/malicious-apache-module-used-for-content-injection-linuxchapro-a

http://news.softpedia.com/news/Sweet-Orange-Exploit-Kit-Developers-Boast-About-Their-Creation-s-Capabilities-316097.shtml

CVEs:

http://cve.mitre.org/cgi-bin/cvename.cgi?name=CVE-2012-5076

"Unspecified vulnerability in the Java Runtime Environment (JRE) component in Oracle Java SE 7 Update 7 and earlier allows remote attackers to affect confidentiality, integrity, and availability, related to JAX-WS. "

http://cve.mitre.org/cgi-bin/cvename.cgi?name=CVE-2012-4681

"Multiple vulnerabilities in the Java Runtime Environment (JRE) component in Oracle Java SE 7 Update 6 and earlier allow remote attackers to execute arbitrary code via a crafted applet that bypasses SecurityManager restrictions by (1) using com.sun.beans.finder.ClassFinder.findClass and leveraging an exception with the forName method to access restricted classes from arbitrary packages such as sun.awt.SunToolkit, then (2) using "reflection with a trusted immediate caller" to leverage the getField method to access and modify private fields, as exploited in the wild in August 2012 using Gondzz.class and Gondvv.class."

http://cve.mitre.org/cgi-bin/cvename.cgi?name=CVE-2006-0003

"Unspecified vulnerability in the RDS.Dataspace ActiveX control, which is contained in ActiveX Data Objects (ADO) and distributed in Microsoft Data Access Components (MDAC) 2.7 and 2.8, allows remote attackers to execute arbitrary codevia unknown attack vectors."

http://cve.mitre.org/cgi-bin/cvename.cgi?name=CVE-2010-0188            

"Unspecified vulnerability in Adobe Reader and Acrobat 8.x before 8.2.1 and 9.x before 9.3.1 allows attackers to cause a denial of service (application crash) or possibly execute arbitrary code via unknown vectors."

-Darian Lewis

THREATTOONS: IS YOUR CSO FORGETTING ABOUT WHAT CAN BE HIDING BELOW THE SURFACE?

Want a THREATtoon on your blog or website? Great! Simply cite the cartoons original Threat Geek URL under the image and you’re good to go.

FIGHTING FIRE WITH NETWORK DEFENSE AND FORENSICS

Back in August, I talked to you about the next chapter for Fidelis, as we joined the General Dynamics family. Today, I want to talk to you about another significant milestone – the advent of our Network Defense and Forensic Services.

It’s no secret that the threat landscape has changed dramatically – as I mentioned in my last post, U.S. enterprises are now battling an enemy that the Federal Government has been combating for many years: nation states capable of waging advanced, customized, well thought-out attacks. And as our adversaries evolve, it’s important that, we, the soldiers on the front lines, do as well.

This new era and its required artillery is what led to our union with General Dynamics  – and we are happy to now deliver Network Defense and Forensics Services through General Dynamics Fidelis Cybersecurity Solutions. The combined services help defend against attacks during every stage of the threat lifecycle and, if breached, quickly contain the threat, limit the damage and conduct remediation activities. 

By combining products with services and people – those who really understand threats and those who really understand networks – we feel like we have gotten to the heart of advanced threat defense. For example, last week we published a Fidelis Threat Advisory about the Shamoon threat that was based on primary research done by our new combined team. Together we disclosed previously undiscovered information about how to investigate, remediate, and recover from Shamoon, and how to identify it as it propagates laterally over the internal network.

Our people are the driving force behind the Network Defense and Forensics Services, and I’m happy to introduce a voice you’ll be hearing from: Jim Jaeger, VP of Cybersecurity Services at General Dynamics Fidelis Cybersecurity Solutions. Jim is joining our geekdom on the blog and having handled several of the world’s largest commercial intrusions to-date, he will certainly have some interesting perspective, so stay tuned.

Apologies for once again taking the blog away from our primary focus on industry analysis and threat advisories. But with all this excitement in the air, I couldn’t just leave you hanging after August’s post, could I?

-Peter George

FIDELIS THREAT ADVISORY #1007: RECOVERING FROM SHAMOON

 Fidelis Threat Advisory #1007

RECOVERING FROM SHAMOON

Executive Summary

The Shamoon malware has received considerable coverage in the past couple of months because of its destructive nature. Despite assertions that it is the work of amateurs, it has had a major impact on companies believed to have been affected. The basic functions of the malware are to infect, entrench, propagate, and wipe.

However because of the way the malware operates and how it is programmed to wipe, it can find itself being its own enemy. It will wipe data found in the Documents and Settings folder and the System32 folder, and then use a signed driver for disk access to start wiping at the disk level. Because the operating system needs certain files in the System32 folder to run, it was found that infected hosts will always restart before the malware can wipe completely at the disk level. Due to this it was possible to make a complete recovery of Shamoon-infected file systems to the state they were in before the wiping made the OS unbootable and unreadable. In fact the majority of files outside of the System32 and Document and Settings folder are recoverable as well; this provided the opportunity for a successful and fruitful analysis, investigation, and remediation effort.

Download FTA 1007 - Shamoon

ADOBE CERTIFICATE COMPROMISE: THE AFTERMATH

Adobe and its customers experienced a bit of a jolt recently when one of its certificates was compromised.  As you may know, certificates are what give some measure of “trust” to applications or other computer artifacts which are signed with those certificates.  (If you would like to learn more about the fundamentals of digital certificates, there are a number of online resources.) People assume that assets that are signed with valid certificates from legitimate companies are safe.  Once a certificate has been compromised, it can be used to sign some very unsafe items. That is exactly what has happened.  What makes the story far more interesting is the time interval involved. The certificate was compromised on, or around, July 10, 2012, and this compromise was reported publicly by many sources on September 27, 2012. Adobe didn’t revoke the certificate until October 4, 2012.  Two full months of having an invalid certificate in the hands of bad guys seems like an inordinately long time.

The compromised certificate was used for signing malicious code by way of a server compromise at Adobe.  One of Adobe’s servers that had access to code signing services was not properly secured.  This allowed malware authors to gain access to the Adobe server and use it to sign arbitrary files.  It appears that only two pieces of malware were signed this way: pwdump7v7.1, a password hash stealer for Microsoft Windows and myGeeksmail.dll, an ISAPI filter to examine and modify data traversing IIS servers.  According to Adobe’s disclosure, this malware comes in three pieces: an exe file and two DLL files.  Their names, MD5 hashes with and without being signed by this certificate are shown here for convenience and are also available from the Adobe disclosure.  There have been reports of other software signed by this certificate which has not been classified as malware but additional information on this code has not been released.

Malware component files signed by the compromised Adobe certificate

PwDump7.exe:

MD5 hash: 130F7543D2360C40F8703D3898AFAC22 (signed)

MD5 hash: D1337B9E8BAC0EE285492B89F895CADB  (unsigned)

libeay32.dll

MD5 hash: 095AB1CCC827BE2F38620256A620F7A4  (signed)

MD5 hash: A7EFD09E5B963AF88CE2FC5B8EB7127C  (unsigned)

myGeeksmail.dll

MD5 hash: 46DB73375F05F09AC78EC3D940F3E61A  (signed)

MD4 hash: 8EA2420013090077EA875B97D7D1FF07  (unsigned)

The certificate being revoked is a SHA1 RSA certificate issued to Adobe Systems Incorporated, issued by VeriSign as a Class 3 Code Signing 2010 CA.  The serial number of the certificate is 15 e5 ac 0a 48 70 63 71 8e 39 da 52 30 1a 04 88 and it was issued valid from December 14, 2010 until December 14, 2012 (now revoked as of October 4, 2012).

Beyond cancelling that certificate, my hope is that Adobe will also retract any software that was legitimately signed using that certificate or provide an update to it to be signed with a new and valid certificate.  This is no small list or task and includes Adobe Application Manager, Adobe Provisioning Toolkit, Report Builder, Site Catalyst Real-Time Dashboard, Adobe Update Server Setup tool, Flash Media Server 4.5.3, Cold Fusion 10, Flash Player, Adobe Reader, and three AIR applications: Adobe Muse, Adobe Story AIR and Acrobat.com desktop services.  These are used by both Mac and Windows.

We have a few recommendations for you. Be sure to check any signed executables traversing your network for signatures based on this revoked certificate.  Check to see if you have any of the affected software packages and make sure they are up to date.  Make sure your AV signatures are up to date as most have these component MD5s in them, but don’t rely simply on AV. Should other things have been signed by this certificate as well, they too should be treated as malicious and unknown.  In general, be aware that code signed with a certificate should be validated.  Is it signed by the author or their company, or is it a third-party signature?  Is the certificate valid for the period it was signed and is it still valid?  Does the certificate exist on a known revocation list?  Many of these are things that you need a deep session inspection engine like Fidelis XPS to examine for you at the network level to prevent having endpoint servers compromised.

-Darian Lewis

Sources:

1. http://www.spamfighter.com/News-17971-Hackers-Compromise-Adobes-Software-Endorsing-Certificate.htm, Retrieved Oct. 5, 2012.

2. http://www.networkworld.com/news/2012/092812-adobe-hack-262860.html, Retrieved Oct. 5, 2012.

3. http://www.adobe.com/support/security/advisories/apsa12-01.html, Retrieved Oct. 5, 2012.

4. http://computer.howstuffworks.com/digital-signature.htm, Retrieved Oct. 5, 2012.

5. https://www.symantec.com/products-solutions/families/?fid=code-signing, Retrieved Oct. 5, 2012.

LOOKING DEEP INTO YOUR NETWORK

If you're responsible for securing your enterprise network, you regularly detect attempts from attackers trying to penetrate your perimeter defense. And, every so often, an attack succeeds. Now you know a system is compromised and while you can fix that system, you're now stuck with a few open items to resolve:

• What sort of command and control communication occurred following the breach? In fact, what was all the communication from that host thereafter, since it may have involved exfiltration of key data assets?
• Were any other users in your environment targeted and successfully exploited in the same campaign, likely using the same techniques?
• What was the full scope of the attack - especially where external communications were involved?

Once you know these answers, you'd ideally like to go back to your security tools to write rules to help prevent future breaches using the same techniques.

You could try to do this with tools that rely on netflow, which typically means you have a listing of the IP information for all flows in your environment. But, when the attack techniques involve the same malware from different servers, potentially geographically distributed, what point does netflow serve?

You could try to do this with tools that capture all packets, index them, and then present you with the ability to do high-level queries. The issue with this is now you're establishing a SAN at every monitoring point and the queries take far too long to run, especially when they involve content level searches. Plus, when you do find what you were looking for, you then need to decide what action to take on the network. Block communication at the firewall? And, how will that help when the adversary is using assets around the world?

Starting now, you can use Fidelis XPS™ Collector, in conjunction with Fidelis XPS CommandPost and sensors to store and query rich session metadata on all traffic at your monitoring points. The sensors decode sessions in real time, extracting information about all aspects of the session – including netflow SSL signing certificates, To, From and Subject field info from enterprise e-mail and Webmail, executable signing info with build times – and much more. Further, this information is readily queried and correlated in an enterprise-class database. When you've identified enough characteristics about the attacks - perhaps a unique User-Agent string or Referrer – you can easily create rules in Fidelis XPS to block those sessions on the network the next time the attacker is back. And, in case you're wondering, all these systems are either 1U rackmount appliances or virtual appliances, giving you a pain-free operational and deployment cycle.

We'll be presenting a lot more information about this product in the weeks to come. In the meanwhile, take a look at the news release and new Power Tool published on our website.

-Hardik Modi