Many research teams have reported on their observations of exploits involving the use of the Apache Struts vulnerability CVE-2017-5638 since Cisco Talos published their post on Wednesday March 8. Fidelis Cybersecurity Threat Research is also seeing widespread activity and contrary to some reporting, we're not seeing any reduction in scanning over the course of the day. 

Apache Struts 2 is an open-source development framework for Java web applications. It uses and extends the Java Servlet API to encourage developers to adopt a model–view–controller (MVC) architecture. Apache Struts2 is used to build websites by a wide variety of organizations. Even as the patch was made available earlier in the week, it's a fair assumption that a large number of systems are yet to be updated.

This post captures some of the exploit code we're seeing. Our expectation is that we'll build on the post as more implementations are discovered.

Impact

The activity is very reminiscent of Shellshock, in that Apache Struts is open source, mature, widely deployed and often embedded in other packages, both commercial and open-source. Many environments only discover the presence of these packages when they discover exploited systems.

We have two general observations around the activity we've seen:

1. Mass scanners are typically trying to install downloaders that lead to Windows and Linux versions of DDoS software, typically the BillGates Botnet.
2. There is more targeted activity clearly going on, often involving reconnaissance of some nature.

Observed Exploits

Building off the original proof-of-concept code

Numerous botnets are adapting code from the proof-of-concept code that was published earlier this week. In each of these instances, there is an attempt to immediately disable firewall functionality followed by the download and immediate execution of a binary.

Update 3/17:

Original Implementations

1. In this one, it looks like the code is printing the root path directory from the exploited server

2. We don't have a good theory for this one other than it represents test code that could eventually be adapted

Conclusion

The wave of threat activity involving CVE-2017-5638 is only just beginning and we're seeing variants that diverge from the original proof-of-concept code starting to emerge. As we see more activity, we intend to share these observations with the community by updating this post.

Every day, attackers tunnel under, sneak through, go around, go over and squeeze past your security technologies.

While you’re armed with more security tools than you can count, most of them are hiding a dirty little secret: They actually create more work for people, not less. Security teams are inundated by alerts indicating potential incidents. These products don't come with job requisitions. They do come with alert overload.

Defenders are often unable to quickly validate whether an alert is real or not, mostly because they receive little context – aka useful insight – from each alert. Without context, it’s a challenge to determine the potential impact of an alert. And given the limits of PCAP data, it can often take days or even weeks to retrieve and analyze data about a threat.

But what if you had a secret weapon that provided the visibility and context you need to make a quick decision about the severity of an alert and, more important, understand the context of what was going on before and after that alert?

With metadata, you do. Rich metadata can answer many questions about what’s happening on your network and shift the advantage from the attacker to you.

Impossible?

Possible. And we’ll prove it. In this three-part blog series, we'll use metadata to solve three of your most vexing challenges.

1. How can I find everyone who received a phishing email?
2. How do I verify that we haven’t already been compromised by a particular tactic?
3. How do I detect credentials in the clear?

Phishing emails – A prolific threat …

Attackers have upped the game when it comes to phishing. Classic phishing campaigns used to come with predictable executable attachments disguised as screensavers or an exploit or macro in a Word document. Now, attachments are non-traditional file types, such as Java JAR, Windows Script Files (.wsf) and JavaScript, among others.

Experience tells you that where there's one phishing email, there are many more. To take action, you need to know the full extent of the event – but how do you find all the other emails that you know are out there?

You could call the mail administrator. If you have a good relationship and can reach him, it may be possible to convince him to search for similar subject lines and “from” addresses on the mail server. The problem is that mail administrators lack the tools to easily perform such tasks. Plus, their day job leaves little time to take calls from security analysts. You’re left knowing there’s a problem, but unable to identify which users received the email, clicked on it and may be compromised.

Relax. Rich metadata solves the problem.

Metadata fills in the missing pieces of the puzzle. With metadata, you can easily conduct an incident response exercise to scope the event and gain the context necessary to act on the alert. A glance at the Fidelis Network dashboard indicates a number of malware alerts. Let’s take a look at one of them to see how easy it is to dig through data to find the other emails.

Figure 1. Fidelis Network Threat Life Cycle Dashboard

Because Fidelis Network captures rich metadata about every event it sees on the network, pivoting from alert to root cause takes only a few clicks. The extensive forensic information provided in the alert detail facilitates and expedites the investigation process.

Figure 2. Alert Detail

Using the one phishing email as a starting point, we begin with the file attachment details. For this event, we find that a .wsf file was inside a zip file and attached to the email. We can also see that the file extension [.doc.wsf] was mangled just enough to possibly convince a user that it's actually a Word document.

Clearly malicious.

Figure 3. File Attachment Details

Moving across the screen, we see details about related alerts, strengthening our suspicions that the email is part of a larger campaign. This information allows us to begin putting context around the alert that will help answer questions such as:

• Where does the email seem to have come from?
• What are the dates?
• When did the user receive them?

Figure 4. Related Alerts Details

Continuing to the right of the screen, the decoding path and channel attributes reveal even more aspects about the event. Here, for example, we see that the sender is masquerading as FedEx.

Figure 5. Decoding Path & Channel Attributes Detail

While we have quickly uncovered a tremendous amount of information about the alert, this is only the beginning. The next step is to pivot from this alert to look for other events in the environment. This is where metadata really shines. Because Fidelis stores rich metadata about every event on the network, it’s a simple matter to perform a search on a component from inside the session.

Let’s revisit that file name. In this case, the attackers intended to fool the user by using a .wsf file with a .doc extension.

Figure 6. Use of .doc.wsf Extension as Attack Tactic

 Using the tactic as search criteria, we perform a search over a one-week period.

Figure 7. Filename as Search Criteria

And what do we find? Subject lines on multiple messages and attachments, all of which, while unique, conform to the same tactic. We can conclude that this is a campaign!

Figure 8. Search Results Reveal Full Scope of Campaign

Without Fidelis, and the rich metadata it captures, it’s a safe bet that you’re relying on the mail administrator to help find the nefarious emails. And it’s equally likely you won't find them. All you’d have is that one email. With Fidelis, it takes a couple of pivots and quick searches. In less than two minutes you're able to find all the phishing emails.

What could be easier?

Did you know Fidelis automates the collection, analysis and storage of your network data so it’s ready for you to investigate immediately? The rich metadata that Fidelis Network captures about every session on your network makes it possible to investigate suspected incidents in seconds – and put the adversary on the ropes.

Ready to cut your detection time down to minutes with metadata? Read our white paper, Talk Metadata To Me: How to Decode Your Network’s Deepest and Darkest Secrets and contact Fidelis today.

This is part one of a three-part blog series about ways to reduce detection time from months to minutes. Coming up: Part 2: Applying New Threat Intel to the Past.

 -- Fidelis Cybersecurity CMO Michael Evans 

Nviso Labs recently published a fascinating blog post illustrating the use of the Lua programming language over the Suricata DPI engine to detect obfuscations in PDF files. Deep analysis of content seen on networks is a topic close to our heart at Fidelis Cybersecurity. After reading that post, we decided to investigate how we could implement this detection by creating a rule in the Yara content scanning engine within one of our own products. This blog walks you through our logic and shows how trivial it is to apply it to PDF content in network traffic.

Analysis

First, a bit of background. Fidelis Network has the ability to rip through sessions and the content inside them. It provides a wide range of 'Analyzers' that can be applied to such sessions and content. One of the more popular analyzers integrates Yara. Yara is broadly favored by malware researchers for file analysis, particularly with a focus on determining maliciousness. The Fidelis Threat Research team finds Yara to be an immensely helpful tool in our daily work.

The core of our exercise is captured here in the Nviso Labs blog:

One of the elements that make up a PDF is a name. A name is a reserved word that starts with character / followed by alphanumerical characters. Example: /JavaScript. The presence of the name /JavaScript is an indication that the PDF contains scripts (written in JavaScript).

The PDF specification allows for the substitution of alphanumerical characters in a name by an hexadecimal representation: /J#61vaScript. #61 is the hexadecimal representation of letter a. We call the use of this hexadecimal representation in names “name obfuscation”, because it is a simple technique to evade detection by engines that just look for the normal, unobfuscated name (/JavaScript).

Doing it in Yara

Nviso takes the logic and creates an elegant Lua rule. Our rule below represents a slightly brute-force way of achieving the same detection, but this time in Yara.

rule GENERIC_PDF_ObfuscatedJavaScriptName {

meta:

copyright = "Fidelis Cybersecurity"

description = "Detects PDF files with an obfuscated JavaScript name."

source = "https://blog.nviso.be/2017/03/10/developing-complex-suricata-rules-with-lua-part-1/"

strings:

$name1 = { 2F 23 34 41 (23 36 31 | 61) (23 37 36 | 76) (23 36 31 | 61) (23 35 33 | 53) (23 36 33 | 63) (23 37 32 | 72) (23 36 39 | 69) (23 37 30 | 70) (23 37 34 | 74) }

$name2 = { 2F (23 34 41 | 4A) 23 36 31 (23 37 36 | 76) (23 36 31 | 61) (23 35 33 | 53) (23 36 33 | 63) (23 37 32 | 72) (23 36 39 | 69) (23 37 30 | 70) (23 37 34 | 74) }

$name3 = { 2F (23 34 41 | 4A) (23 36 31 | 61) 23 37 36 (23 36 31 | 61) (23 35 33 | 53) (23 36 33 | 63) (23 37 32 | 72) (23 36 39 | 69) (23 37 30 | 70) (23 37 34 | 74) }

$name4 = { 2F (23 34 41 | 4A) (23 36 31 | 61) (23 37 36 | 76) 23 36 31 (23 35 33 | 53) (23 36 33 | 63) (23 37 32 | 72) (23 36 39 | 69) (23 37 30 | 70) (23 37 34 | 74) }

$name5 = { 2F (23 34 41 | 4A) (23 36 31 | 61) (23 37 36 | 76) (23 36 31 | 61) 23 35 33 (23 36 33 | 63) (23 37 32 | 72) (23 36 39 | 69) (23 37 30 | 70) (23 37 34 | 74) }

$name6 = { 2F (23 34 41 | 4A) (23 36 31 | 61) (23 37 36 | 76) (23 36 31 | 61) (23 35 33 | 53) 23 36 33 (23 37 32 | 72) (23 36 39 | 69) (23 37 30 | 70) (23 37 34 | 74) }

$name7 = { 2F (23 34 41 | 4A) (23 36 31 | 61) (23 37 36 | 76) (23 36 31 | 61) (23 35 33 | 53) (23 36 33 | 63) 23 37 32 (23 36 39 | 69) (23 37 30 | 70) (23 37 34 | 74) }

$name8 = { 2F (23 34 41 | 4A) (23 36 31 | 61) (23 37 36 | 76) (23 36 31 | 61) (23 35 33 | 53) (23 36 33 | 63) (23 37 32 | 72) 23 36 39 (23 37 30 | 70) (23 37 34 | 74) }

$name9 = { 2F (23 34 41 | 4A) (23 36 31 | 61) (23 37 36 | 76) (23 36 31 | 61) (23 35 33 | 53) (23 36 33 | 63) (23 37 32 | 72) (23 36 39 | 69) 23 37 30 (23 37 34 | 74) }

$name10 = { 2F (23 34 41 | 4A) (23 36 31 | 61) (23 37 36 | 76) (23 36 31 | 61) (23 35 33 | 53) (23 36 33 | 63) (23 37 32 | 72) (23 36 39 | 69) (23 37 30 | 70) 23 37 34 }

condition:

//Check for "%PDF" magic header, not needed when applied in Fidelis Network

uint32(0) == 0x46445025 and

any of them

}

This rule takes advantage of the 'alternatives' feature in Yara, which is applied to hexadecimal strings. For example, (23 34 41 | 4A) represents the hexadecimal representation of both the obfuscated and unobfuscated versions of the letter 'J'. Ultimately this leads to detecting files with all combinations of this specific obfuscation.

/ (#4A | J) (#61 | a) (#76 | v) (#61 | a) (#53 | S) (#63 | c) (#72 | r) (#69 | i) (#70 | p) (#74 | t)

You'd be right to see this particular Yara rule and think it's complex. But if you're used to doing analysis by brute forcing through common obfuscations or encodings, then it's really not that much of a stretch. We'd say that it took our analyst about 20 minutes to write this up after reading the Nvisio blog post.

Application in Fidelis Network

One of the upsides of doing this rule in Yara is that you can run it on multiple malware analysis platforms against stored file zoos. We ran it on one of the platforms that we have access to (we've posted discovered file hashes at the bottom of this post). In our analysis, just like Nviso reported, all the files we discovered had been determined to be malicious.

The Nviso blog concludes with a bit of a reality check – actually applying the Lua rule to network traffic with Suricata can affect performance of the IPS engine. There are some measures proposed to tamp down on this impact. But to the trained eye, it's clear these are sub-optimal from a detection standpoint, even as it lets you keep your IPS running.

This is where Fidelis Network really makes a difference. It lets you apply Yara rules to objects that have been extracted from network sessions. Even better, it performs file classification independently of the rule. You get to specify 'I want to apply this Yara rule against PDF files' and now the rule is applied to files that Fidelis Network identifies as PDFs, regardless of the network protocol or intermediate encoding or compression layers.

The approach provides these benefits:

• The rule is applied to all network traffic – HTTP, SMTP, POP3, FTP, SMB and many others. Email is a primary vector for the delivery of malicious PDFs, so it's essential to apply this rule to all traffic.
• The system consistently identifies PDF files using a variety of techniques, not easily bypassed by obfuscation (note the %PDF- identifier and accompanying comment in the Nviso blog)
• You're only incurring the compute cost of the rule when the system identifies a PDF file.

Don't get us wrong. This is not intended to be a knock on the Suricata+Lua combination, which after all is an open-source tool used by countless network defenders worldwide.

Instead, after reading the post, we saw what looked like a good opportunity to highlight our implementation and the benefits of using Yara in an intrusion prevention context.

The following screenshots show what the detection would look like in Fidelis Network when the file is transferred over HTTP:

Note: After we wrote this post, Nviso published a follow up blog discussing an iterative process towards improving the Lua rule. This is exactly what we like about the use of Yara since it has an extensive toolset and ecosystem in place, including the ability to run rules against datasets. See the hashes in Appendix B for an example of what we discovered with such a run.

Appendix A - Alternate Yara rule

The Yara rule below is one of our analyst's earlier iterations. It is much more elegant, compact and functionally equivalent to the verbose final version above. But this rule raises performance warnings from the native Yara engine. Due to the Yara engine's inner workings around the selection of "atoms," this rule's approach is more computation intensive and required de-optimization of the syntax logic to create the final version shown above.

rule GENERIC_PDF_ObfuscatedJavaScriptName{

     meta: 

        copyright = "Fidelis Cybersecurity" 

        description = "Detects PDF files with an obfuscated JavaScript name." 

        source = "https://blog.nviso.be/2017/03/10/developing-complex-suricata-rules-with-lua-part-1/" 

    strings:

        // "/(#4A|J) (#61|a) (#76|v) (#61|a) (#53|S) (#63|c) (#72|r) (#69|i) (#70|p) (#74|t)"

        $name = { 2F (23 34 41 | 4A) (23 36 31 | 61) (23 37 36 | 76) (23 36 31 | 61) (23 35 33 | 53) (23 36 33 | 63) (23 37 32 | 72) (23 36 39 | 69) (23 37 30 | 70) (23 37 34 | 74) } 

        $jsname = "/JavaScript"

    condition: 

        uint32(0) == 0x46445025 and //Check for "%PDF" magic header  

        #name > #jsname //Check if more obfuscated versions exist than the number of un-obfuscated versions

}

Appendix B - Detected File Hashes

 f5aac4bb54cc524f91ed78952ecc12d7ea5c07d9ceab72516fa7cbcf46f0506f
e56b90588bb9fcc0ee98db85bc20a47cfde87da079bb2a2ae4b14a32339942ea
a132a9a1aadbf70a124e1b2214e41e28b1be5075c1768ea733e5e2ab8bc85769
6febdf27633c88fb46ba07b3cc5fb256df88fe79af5232184ab50cef4831aca8
b39c15514664acba77a7ce63e7c6640e0f532aef6ceb18c931be0be601f10ff8
7aa45d7252507f8f15613162dbf363ab804d1b7b8dc330eda4f0d3d9ffcc32e3
4ae4dd8dfe601fad097f19f2242c0949093928ef18444564e5272d85acbf7831
6c94497b79dab4f88ce1d7af7b85420566434cebcb9fc51dd83327482bf1ec43
41870fd6cdc3fdfaf610c4b132134ae1eb21c1ac472317883f832707dc0cd037
8cecb8e4091b64683d0acd567d6c115ff10defe5be7dec0d13c06d39119bd08f
367547f151358c3ff872bda0017ed0871842b946c7b61da5e4d91f48176a617d
abd8af58913feaa1a372ba3b08ea9d1fbf61816e49e8ad6a6e89fc34d27e7dfd
6c83a329f66deea6773bc3c83bdae22e93a5c80c829528de7d49d70208f7813c
c4bf178d7a0791c8373c1d35d36e05c685bc0928337864f6947dbac9c3cef203
b93bbdd37216d44226173a972b415a6eea96a88ba1949f8c9e6308261994b388
9960414632c92785b3d865af11dd16efb3f2aca55f403cba23882d0174d556e3
1a464927cfc31e1bf09783b9b7470e95fe522b490f913a21660f4d782f1881f2
3b0c506e0f2c0ae7820d1be408ede6d08a9851eb2218ac957dff75166f0a103f
0495bebd383dee37b558293667432be9fb411379d76abac00eeb636d5e5e9a2a
0c0530da094fa8ee4ab8149ddb4d038dc0361877bb110981968b03bf05fca764
e0098144277792b1a9385af30ec70c19545cd232bc089ae8171edb52f887c549
f86471bd3e88462ddda96c38650d6b53277135389b44d992d7c4b293ad5609af
65ce23bcc7db4494cd21a103c4218d5216fe7213707fe1445cff5cd915abe5ab
2a803e67417e5b6f6b724220eb2861391a855f138a124e356895b96016b00b22
f148d687af45fc320574e2ebbe1ffb25ab7008c5aca43257516895861d38099e
a88e416b98b6a8ba28d0e6da96bb39295b2ccfda28d2246bebc59c77437685e4
c5f9cebf083f1fb38f1fc20518b512240ca37e3a1eed93badf983a0500705da5
7d336f0fef2bd1f7e98039ad2a69cc0a0bc543d9741dc8a81577cc3b57274b46
90b71d61f4a10dc3b34e6f9650fd212feec34c970a7c21802459a0e828680544
9519b0828733770b2ca1376962922a1df9e10f6218326a6af4b91c6c89bce157
0af2001aa3c97d32567d9990785dfefb4de54aae50fbf9af3f1c5953c6edd6d7
3a2c4b451291a80062c66a86d1ea77547140e5a7186cd6edaa323a0f3d87d239
c887c89347980dfc6b18d19d96786a2cfd065a98ad349d6fcf918ec9159a7ddf
516457828ad97206e58b8dffce02cce303afe01abf0cbaaadf96d829d842191f
64faef3e3df9e464a01a37c19d578b88ecb96c51312800b21f46e3e58e36eb7a
982f73491d8ffa1c27d7c4375d50e0212e02e02751e3186a92256abbff98c3ed
86dcc1251df159ce58628b2b9a852c66199448f545084de1821a719c88120d38
6f3c5d03b0c58b763fc23a14e7ad1a523b46ca7453c6c8e0c3959272928a0323
25d4eb72174ac2279a0aaaecb84648328895f7b5faaa413fd6b7db5061eb963c
876df82e3dfdca50b72f3fb28b71088101c42c86762696a7115973e0cac2d287
3ca77800a2caaeb8050c3e3a9f602ed44fe27371b582ddcd0f0bea4aab35797c
b85bca0c26dee077b066716faee735a8471951a7cba6379fdc7e7b38ac2a2701
e218d13461ebededc13b1c3fdc9edeaaf26a480249152ce3fee91cfcddd2d18c
492e1abae4d41fd508abc6043f8503006473b32d1e640055994024fa2c9f39e7
a7de24f17ffd26828baa68f2541533b333c15345ab9841abf97c7f720abea24f
0cf6492f1faa00794438ed5f587fd82c48b1a0d3b7233d9dbdb654ff4fd95654
788bdf912ff4bfe3998716ca5421e61619b317010d1a57cfad3064254fd9ae43
579d7b3a8b0222a75035e071daabcde10dc06b7494dc57b1603117e6f9ff59f5
bfe623fa10ee472964ad73df43ed8d4ae3a6df2e13bbbe29f5a9f0a99c87944e

-- Fidelis Threat Research Team

Interesting changes are happening in the world of cybersecurity legislation. Notably, these changes are impacting the role of the chief information security officer (CISO). No longer are CISOs just the sacrificial lamb (read: scapegoat) when a company suffers a data breach. 

The changes revolve around newly minted regulations in the New York State Department of Financial Services along with a proposed Senate bill, The Cybersecurity Disclosure Act of 2017 S.536. 

The Cybersecurity Requirements for Financial Services Companies, 23 NYCRR 500 took effect March 1, 2017. One of the significant things this regulation does is define a cybersecurity event as “any act or attempt, successful or unsuccessful, to gain unauthorized access to, disrupt or misuse an Information System or information stored on such Information System”. Note that it does not just talk about data exfiltration, but goes so far as to say any successful or unsuccessful attempt. 

I speak at many events where the audience is predominately CISOs. I’ve noticed that they’ve been very careful to delineate between an “event” and a “breach” because this gives them -- and the company’s general counsel -- the ability to put clear parameters around when they must enact their incident response (IR) plan and potentially provide notifications of data leaving their control.

Based on this definition included in the regulation and in Section 500.17 Notices to Superintendent, these regulations will likely require increased notifications in the wake of a possible breach.  Another unique aspect of this regulation is that it mandates the naming of a qualified CISO. This CISO will be required submit a written report at least annually to the Board of Directors, their equivalent governing body, or a Senior Officer. This report must include cybersecurity risks, overall effectiveness of the program, and any material cybersecurity events. There are many other requirements of this regulation regarding risk assessment and testing as well.

The Cybersecurity Disclosure Act of 2017, which has been proposed before the Senate, brings the mandate of cybersecurity acumen to a company’s board of directors. If passed, this law will require that publicly traded companies include in their annual filings and proxy statement a disclosure on whether any member of the board or appropriate governing body has cybersecurity expertise or experience. If the board doesn’t have a member with that expertise, the company must disclose what efforts have been taken to identify and evaluate new nominees who possess the expertise to join the board.

Even though this requirement won’t go in to effect until a year after it is passed, it is very surprising that the federal government is trying to make this a requirement. It speaks very strongly to how important they feel this expertise is to the operations of a public company.

While these laws/regulations are only applicable to somewhat narrowly defined groups in the grand scheme of things, they are steps in the right direction by ensuring that corporations are being good stewards when it comes to cybersecurity. Additionally, many organizations are being proactive and have already enacted many of the items contained in these regulations even though they don’t directly apply.

I believe these regulations are just a few examples of what’s to come over the next several months as cybersecurity remains a critical issue we must address. With that said…CISOs and potential CISOs, get used to wearing a suit because you are moving up in the world!

-- Fidelis Senior Vice President of Cybersecurity Services Mike Buratowski

Welcome back to reducing detection time from months to minutes. In the first post in this series, we showed how metadata holds the power to quickly disarm one of the most effective cyberattack methods in the attackers’ arsenal – phishing. 

But what about detecting threats in the past?

You’ve read the headlines: Ransomware Hits. Data Stolen. E-mails Hacked.

Perhaps a high-profile organization in your industry was compromised, had to report the breach, and a new zero-day exploit is uncovered. No sooner do you get the details about the event when you get a phone call from the CEO, asking, “Has this happened to us?” 

Can you say with certainty whether you’ve been affected by the exploit in the past, or not?

Faced with an urgent detection dilemma, it’s natural to turn to threat intel to get details. However, it's nearly impossible to operationalize your threat intel to investigate retroactively. Yet this is exactly what must happen. Because the dirty truth about threat intelligence is that by the time the details are published, attackers have already been using the tactic for a while.

When you get intel about a new tactic, how can you apply that intel quickly? And specifically, how can you apply it historically to understand if you've been compromised?

The answer (again) is metadata.

Rich metadata allows you to apply new threat intelligence and indicators of compromise to all traffic – including historical traffic – to determine if the organization is affected by the threat. 

Still have doubts?

Metadata in Action

Let’s look at some threat intel using Fidelis Network to see how easy it is to apply the hash and perform a backward search to identify any incidents occurring in the environment that we are unaware of. Fidelis Network creates and stores a hash of all objects crossing the wire, including attachments and compressed files, plus executable files and all file types, such as Word files, JavaScript, Flash, Swift files, Java JAR files.)

Figure 1. FBI Cyber Bulletin: Identification of Locky Ransomware

Using a hashtag from the threat intelligence report, we plug in the hash, select a timeframe and run a search against all metadata stored by Fidelis Collector. Within seconds, you will know with absolute confidence whether this malware has impacted your environment. Searches of 90 to 120 days of metadata deliver results in minutes.

Figure 2. Hash Search Against Stored Metadata

It’s that simple. 

Here, the results show us that multiple events have occurred. A quick examination reveals the attacks happened over email. And, if the attacks happened via the web, it would have been found in the same manner. Using a hashtag from the threat intelligence report, we plug in the hash, select a timeframe and run a search against all metadata stored by Fidelis Collector. Within seconds, you will know with absolute confidence whether this malware has impacted your environment. Searches of 90 to 120 days of metadata deliver results in minutes.

Now, with clear eyes on the events within the environment and context around those events, all that’s left is to start the incident investigation and response process.

Figure 4. Metadata Facilitates Incident Investigation and Response

With Fidelis Network, not only can threat intelligence be applied backwards, it can also be applied to future traffic. It’s a simple matter to create a custom rule for the hash fingerprint to operationalize the threat intel. When an event matching the intel occurs in the future, you’ll automatically get an alert.

Without metadata, it’s all but impossible to apply threat intelligence to the past. You can basically forget about identifying – let along resolving – the incident.

Sure, you can cut and paste snippets of intel from various threat intelligence feeds. But how time-consuming and error-prone is that?

With metadata, applying new threat intelligence to historical data takes only a few clicks. You can detect and resolve both new threats and past compromises in minutes. Not only will it enable you to confidently answer the question, “Are we safe?” the next time the CEO asks, it will equip you to detect attacks other solutions can't even see.

The choice is yours, but we’d go with the metadata.

Did you know Fidelis automates the collection, analysis and storage of your network data so it’s ready for you to investigate immediately? The rich metadata that Fidelis Network captures about every session on your network makes it possible to investigate suspected incidents in seconds – and gives you answers to questions that were previously impossible to know.

Ready to do impossible things with metadata? Read our white paper, Talk Metadata To Me: How to Decode Your Network’s Deepest and Darkest Secrets and contact Fidelis today.

This is part two of a three-part blog series about using metadata to reduce detection time.

-- Fidelis Cybersecurity Vice President of Threat Research Hardik Modi

Trade policy was at the center of the recent U.S. presidential election and is sure to feature prominently on the agenda when President Trump meets for the first time with China President Xi Jinping in Florida this week.

Read the full article >>

Welcome back to our blog series on reducing detection time from months to minutes. In our first and second posts, we showed how you can use metadata to quickly resolve phishing attacks and investigate threats retroactively. While those two scenarios are pretty common, here’s one that may be new to you: detecting credentials in the clear.

First, let’s take look at a typical day in a typical office. Employees (including top executives) are accessing external applications without HTTPS for authentication. Somewhere, the mail administrator is using an ftp application that doesn’t encrypt credentials.

Normal activities. What could possibly go wrong?

There is a high probability that their credentials are being passed in the clear. It doesn’t even matter if it’s the strongest possible password. By simply listening to the network traffic, it’s easy for attackers to grab the credentials.

Credentials in the Clear

Unlike the two scenarios in our previous posts – where you know you are on the hunt for an attacker – user credential theft can happen right before your eyes. You won’t even know it’s happening.

Why should attackers bother with complex and expensive zero day exploits or sophisticated malware when a username and password can grant access to almost any application? Attackers can grab passwords passed in the clear and get a toehold on your network. Once inside, they can move laterally. It’s a huge problem for network defenders.

To make matters worse, employees willingly engage in online activity that is tantamount to shouting out their passwords at Black Hat or posting their credentials in a Dark Web user forum?

Fortunately, we have an answer: Pre-empt the would-be attacker by detecting credentials in the clear as they cross the wire.

Impossible? It’s not only possible. It’s easy. 

Let’s look at the Wall of Sheep hacking event at DEFCON (full disclaimer, we’ve sponsored and participated in this event for several years). Participants are given network traffic data from the conference’s free Wi-Fi network to look for user credentials passed in the clear. These credentials, when vetted, are partially obfuscated and posted to a giant screen (dubbed “the Wall”) to expose users’ data. The goal of the exercise isn’t to embarrass. It’s aimed at drawing attention to the fact that this could happen to anyone, on any network.

Wall of Sheep

Year after year, we’ve seen common protocols that transfer credentials in the clear -- like POP3, IMAP, FTP, Telnet and even SMTP -- continue to be used in volume – even in enterprise environments. We’re also seeing applications using http are inadvertently sharing credentials. This is especially true for IoT devices, which often lack encryption. That fitness tracker you’re using to count your steps? That webcam on your monitor? All could be passing credentials in the clear.

Because Fidelis Network, our next generation network intrusion prevention system, is fine-tuned to detect credentials in the clear, it’s a simple matter to detect when a username is observed in a network session and find out whether a password was attached to it.

A simple search and filter of your network’s metadata shows the session, the protocol, the observed username, and the fact that there was a password. Here we see that the system identified a non-standard protocol.

With one click, you can further explore the unknown protocol session and extract usernames and passwords. Depending on the details, a security analyst may need to elevate the event to a real security incident – or simply educate the user. 

Drill Down on Protocol Activity

Historical access to metadata makes finding and resolving threats that go beyond typical malware -- like credentials in the clear -- easier to deal with. Unfortunately, this is where classic intrusion prevention systems typically fall short. Traditional IPSs are focused on real-time detection and prevention. They have no non-selective memory and no ability to go back in time. That’s a problem when it comes to stopping modern intrusions.

Today’s threats require you to extract, store, and analyze rich protocol, application and content level metadata from every session that traverses the network. And with that visibility comes peace of mind. Not only do you know what is happening on your network, but you can do something about it.

Did you know Fidelis automates the collection, analysis and storage of your network data so it’s ready for you to investigate immediately? Fidelis Network captures rich metadata about every session on your network – making it possible to investigate suspected incidents in seconds – and gives you answers to questions that were once impossible to know.

Ready to do impossible things with metadata? Read our white paper, Talk Metadata To Me: How to Decode Your Network’s Deepest and Darkest Secrets and contact Fidelis today.

Check out the first two installments of our “Three Ways to Reduce Detection Time from Months to Minutes” series:

Part 1: Phind the Phish

Part 2: Investigating Threats Retroactively

--- Fidelis Cybersecurity VP of Threat Research Hardik Modi