PCAP files play a critical role in network troubleshooting and security. When an issue arrises and Developers are pointing at the SysAdmin who are pointing at the Network Admins, a PCAP capture will give you the unbiased answer. Depending on the amount of traffic and length of the capture however, these files can be extremely daunting to look at when first opened. Where do you start in a capture with 200,000 entries?
We now have a working pipeline starting with an alert being triggered at our endpoint, through escalating that alert into TheHive. Once we have an alert we can begin the process of case creation, task assignment, IoC enrichment, and ultimately case closure. Let’s walk through this process in more detail.
Today I’ll show you how to use imap2thehive to pull emails from a mailbox, extract as many unique observables as possible, and generate a case in TheHive. It won’t be a long post as the author of imap2thehive has done an excellent job with his script and some small configuration changes are all that are required.
Below is the guide I use when troubleshooting a broken WSUS installation. This can manifest as a server console error, the ever popular “it’s just not reporting in”, or through the event log. I’ll walk you through the components of WSUS and how to check and make sure each one is functioning properly.
At some point, after probably dozens of test Elasticsearch instances, you’ll want to actually deploy a cluster into production. If you’re now responsible for a production cluster you’ll need to protect against credential harvesting and random
curl DELETE queries that can cause all your indexes to disappear. Thus the motivation for purchasing X-Pack.
Cuckoo Sandbox is an open source malware analysis system used to launch files in an isolated environment and observe their behavior. Pass it a URL, executable, office document, pdf, or any file, and it will get launched in an isolated virtual machine where cuckoo can observe it’s process execution, API calls, network access, and all filesystem activity. You’ll then get a report and a threat score based on the observed behavior. Once the analysis is complete the VM restores to a known good snapshot and waits for the next execution.
Today we’ll be completing the chain and bridging the gap between Elasticsearch where our alerts currently sit, and TheHive where the alerts will become cases for analysis.
In today’s episode we’ll be installing some of the final pieces of our pipeline with TheHive and Cortex. Along with TheHive we’ll need to install Elasticsearch from the 5.6 branch as a requirement of TheHive. Version 4.1 (expected in Q2 2019) will eliminate Elasticsearch as a dependency and instead use GraphDB.
Implementing a MISP server will allow Cortex, or any application capable of issuing a simple REST request, to query against feeds of threat indicators, most notably for IP addresses, URLs, and file hashes. The MISP server will allow you to control the subset of feeds you wish to subscribe to and query against, but it’s up to you to find the right balance in selecting the feeds. The information returned depends on the additional data provided by the feed and varies greatly among feed sources. Some feeds are simple block lists while others provide a wealth of additional data. Take a look at feed number 1 from CIRCL for an example of the data that can be provided.
Today we’ll be installing Wazuh Manager on a new server, registering an agent, and integrating Wazuh with Elasticsearch.