SecuritySynapse: November 2019

Wednesday, November 27, 2019

Making Splunk Dashboards Available Outside of Splunk

By Tony Lee

Have you ever built a beautiful Splunk dashboard that was not only aesthetically pleasing, but also incredibly insightful? If so, maybe others learned of its value and now want that data shared--even to users who may not have Splunk accounts. We had such a case in which the Chief Information Officer (CIO) wanted to add a particular Splunk panel to his intranet site for all employees to see. In this article we will recreate the scenario and show you how this can be accomplished. The two screenshots below show two possibilities of embedding Splunk panels into external sites.

Figure 1: Example of a single panel embedded into a page outside of Splunk

Figure 2: Example of two panels embedded into a page outside of Splunk

Problem

There are quite a few issues that we need to solve, such as:

Splunk does not make it easy to share panels and especially entire dashboards outside of their platform
Some data may be sensitive in nature, so just remember the potential audience

Fortunately, this sharing can be disabled if needed

This solution needs to be long-term low maintenance which means no manual updates
The new website must be able to reach the Splunk search head via HTTPS

Potential Solution

The potential solution we are going to show uses scheduled saved reports to share out a panel. Here are the steps below:

1) Generate your insightful panel using the proper search. Click Save As > Report

Figure 3: Creating a report

2) Select the content and time range selector

Figure 4: Saving the report

3) After saving the report, let's schedule it

Figure 5: Schedule the report

4) Specify the schedule - this example updates the report every hour with the last hour of data

Figure 6: Schedule parameters

5) Generate the embedded link by clicking Edit > Embed

Figure 7: Generating the embedded link

6) Copy the embedded iframe link into the external site in question (Example site shown in Demo Page Code section below)

Figure 8: Embedded iframe link

Conclusion

This is one possible solution that creates a low maintenance panel shared outside of Splunk. If you want to share an entire dashboard, this can be repeated for every panel in the dashboard. Just be cautious of the sensitivity of the data. If it is later determined that this data is no longer needed or should not be shared, it can be disabled. If you have a different method of sharing panels and especially entire dashboards, we would love to hear it. Feel free to post it in the comment section below and as always happy Splunking.

Demo Page Code

This is just a demo page that contains two embedded saved reports. The panel on the left is a single value number and the one on the right is a timechart. Just remember to replace the two locations of: "YOUR_EMBEDDED_LINK_HERE"

<HTML>

<HEAD>

<TITLE>This is an embedded demo</TITLE>

<!--

td {

height: 300px;

vertical-align: center;

text-align: center;

}

iframe {

vertical-align: center;

text-align: center;

}

-->

</style>

</HEAD>

<BODY>

<center><h2>CIO's Corner</h2></center>

<tr>

<th>Total Count</th>

<th>Count over Time</th>

</tr>

<tr>

</tr>

</table>

</BODY>

</HTML>

Tuesday, November 12, 2019

Building a DirtyNet - The Ultimate Malware Playground

By Tony Lee

Do you have a safe place to handle and investigate potential malware? Maybe you are you doing this on your home PC or in a VM to try to protect the rest of your network? Whether you have a DirtyNet or not, let’s start an open discussion that covers some safe malware handling possibilities along with the pros and cons of each. Maybe this will help provide justification or a framework for even a minimal amount of funding to build something official and supported.

Figure 1: DirtyNet Information Flow

The Benefits

There are many benefits to building a DirtyNet to take a closer look at potential malware, here are a few:

Determine maliciousness of malware

Never seen before binaries – Threat intel and malware repositories know nothing about it
Low conviction rate – Threat intel and repositories have seen it, but are not convinced of the maliciousness

Extract Indicators of Compromise (IOCs)

Useful in hunting for presence in the rest of the environment

Protect the rest of the network

Prevent users from mishandling malware on their corporate PCs by providing a dedicate environment

Possible Solutions

There are probably a large number of potential solutions – many of them bad ideas and some good ideas. We will cover the two most common setups here:

1) Stand-alone Malware Analysis Laptops

This is very common because it is easy to implement and somewhat reduces the risk of accidental malware spread. There are some pros and cons that should be noted though:

Pros

Lower risk of mishandled malware than using a VM on your corp machine

Cons

Requires sneaker net – USB drives with write-blockers
Not real-time feeding from sensors
Difficult to connect/automate sensors and analysis stack
Difficult to scale to a large amount of malware
Difficult to extract and harvest IOC for reuse

2) Building a DirtyNet

This is not always the route chosen, but when built correctly, it is a beautiful and graceful solution. Here are the pros and cons:

Pros

Can be automated
Flexible sensor integration
Flexible automated malware analysis stack
Scales to higher volume of malware

Cons

Higher risk of mishandled malware when not following proper procedures

DirtyNet Rules

Notice the single con of the DirtyNet… But just like fight club, it is important that EVERYONE follow the rules:

Write-only file share exposed to larger environment to accept malware and move inside DirtyNet
Malware stays within DirtyNet. No outbound traffic except whiteline for FireEye AX / Malware analysis stack
Malware can be taken from the Malware repo and moved to an analysis workstation within DirtyNet
Malware is ideally password protected zipped with “infected” before transfer and during storage
Analyst connection to dirty net does not compromise the rest of the network. Virtualized desktops through a browser plugin with no file sharing is a decent option.

Requirements

So you want to build a DirtyNet now... and you are curious as to what you might need. The info below contains the high-level requirements:

Hardware or Virtual (AWS/Azure/GCP) capacity
Whiteline randomized POP for malware to make callouts (ideal but not necessary)
Viper or similar framework for the Malware repository
Time from a network engineer to set up network and hosts

Conclusion

Now that you have the blueprint, will you be building a DirtyNet of your own? Also, if you already have a DirtyNet, we would be interested in hearing your tips, tricks, or opinions posted in the comment section below. As a bonus, do you have any cool integrations setup? For example, we have CyBot’s (https://github.com/cylance/CyBot) Cuckoo plugin safely feeding out instance with malware. Thanks for reading!

Figure 2: CyBot Cuckoo plugin safe submission to DirtyNet