Cisco Umbrella and
Investigate Lab Guide
Lab Version​:
v6.0, 2016 Oct 10
Lab Developers: Matt Prytuluk, Robbie Grue, Justin Hang, Francis Lau, Chris Frost, Rob
Gregg, Ondrej Panek, Jason Phelps
Lab Overview
Cisco and Partner SEs will learn how to deploy and demonstrate the value of Umbrella’s
enforcement and intelligence ​products — Umbrella and Umbrella Investigate. T
​ his lab covers
the initial deployment of Umbrella, followed by sections on Umbrella reporting and threat
intelligence in Umbrella Investigate. A​fter completing this lab, SEs will be able to help sales
teams successfully demo Umbrella products for prospects.
Lab Exercises​ ​(click to view expanded table of contents)
1. Deploy Umbrella components, create policies, and generate activity
2. View activity in Umbrella reports
3. Use the Investigate Console
OpenDNS SEVT Guide
1
Lab Environment
Topology
Product Overview
Umbrella​ delivers a new predictive network security layer for DNS and IP activity for breach
protection and Internet-wide visibility. The cloud-delivered service protects any device, both on
and off the corporate network. Umbrella prevents command & control callbacks, malware, and
phishing from compromising systems or exfiltrating data over any port or protocol.
Umbrella Investigate​ provides access to our intelligence on domains and IPs across the
Internet. Investigate leverages a live graph of DNS requests that gives the most complete view
of the relationships and evolution of Internet domains, IPs, and ASNs.
OpenDNS SEVT Guide
2
Umbrella technology leverages a diverse dataset of 80+ billion daily DNS requests and a live
view of the connections between different networks on the Internet from 500 BGP peering
partners. We apply statistical models and human intelligence to this massive dataset to uncover
current and future malicious places on the Internet.
Components
●
SE’s Laptop: ​This is your own device. SEs must have the Microsoft Remote Desktop
application installed to RDP into virtual machines.
●
Windows Client VM​: This functions as an end-user device that makes DNS requests
from on the network. Umbrella will apply a blanket security policy while the device is on
network. The Umbrella’s roaming client will be installed on this VM to provide device
level granularity in the reports. The added granularity lets an admin link DNS requests to
a specific hostname.
●
Windows Client AC VM​: This functions as an end-user device that makes DNS
requests from off network to simulate coverage of roaming users. Umbrella roaming
client will be installed as AnyConnect security module to demonstrate this new
deployment option for AnyConnect customers.
●
VMware ESXi Host: ​Umbrella’s virtual appliances are installed on VMware ESXi hosts
(note: Microsoft Hyper-V also supported). Virtual appliances are an on-premises
deployment that provides visibility of internal IP addresses for any device sending DNS
requests.
●
Domain Controller (DC) VM: ​The Umbrella’s connector service is installed on at least
one (or optionally more) DCs to allow customers to initially import and continuously sync
their existing AD structure into Umbrella. Customers can identify which AD user, group,
or computer is making specific DNS requests with this integration. SEs will RDP to this
VM to forward DNS traffic to Umbrella and later on forward DNS traffic to the Umbrella’s
virtual appliances.
Component Access
1. SEs will RDP from their laptops into the Windows Client VM.
2. From the Windows Client VM students will use Microsoft Remote Connection to RDP
into the Domain Controller (DC) VM.
3. The Windows Client VM will have a VMware vSphere Client installed. The vSphere
Client will be used to access the ESXi host environment for deploying the Umbrella’s
virtual appliances.
OpenDNS SEVT Guide
3
Accounts & IP Configuration Info
1. SEs will be assigned a specific POD number. Look up your POD number in the table
below to find your Umbrella user login / password and network external IP (you will add
this external IP as an Umbrella network identity).
IMPORTANT: ​Write down all the information in this section (items 1 and 2) for the
POD you were assigned in a notepad. You will reference this multiple times during the
Lab. This will make it easier than scrolling back to this section to find the information.
NOTE: ​The password letters in bold D
​ n$​I​s@wS​0​m3 are “capital I” and “zero”.
If your​ pod number is between 1 and 20, t​ he IP you will register in Umbrella is y
​ our pod
number + 10​ in the final octet.
If your​ pod number is between 21 and 40, t​ he IP you will register in Umbrella is y
​ our
pod number + 60​ in the final octet.
POD
OPDNS-POD-1
OPDNS-POD-2
OPDNS-POD-3
OPDNS-POD-4
OPDNS-POD-5
OPDNS-POD-6
OPDNS-POD-7
OPDNS-POD-8
OPDNS-POD-9
OPDNS-POD-10
OPDNS-POD-11
OPDNS-POD-12
OPDNS-POD-13
OPDNS-POD-14
OPDNS-POD-15
OPDNS-POD-16
OPDNS-POD-17
OPDNS-POD-18
OPDNS-POD-19
OPDNS-POD-20
Umbrella User Login
sevt1@opendns.com
sevt2@opendns.com
sevt3@opendns.com
sevt4@opendns.com
sevt5@opendns.com
sevt6@opendns.com
sevt7@opendns.com
sevt8@opendns.com
sevt9@opendns.com
sevt10@opendns.com
sevt11@opendns.com
sevt12@opendns.com
sevt13@opendns.com
sevt14@opendns.com
sevt15@opendns.com
sevt16@opendns.com
sevt17@opendns.com
sevt18@opendns.com
sevt19@opendns.com
sevt20@opendns.com
OpenDNS SEVT Guide
Umbrella
Password
Dn$Is@wS0m3
Dn$Is@wS0m3
Dn$Is@wS0m3
Dn$Is@wS0m3
Dn$Is@wS0m3
Dn$Is@wS0m3
Dn$Is@wS0m3
Dn$Is@wS0m3
Dn$Is@wS0m3
Dn$Is@wS0m3
Dn$Is@wS0m3
Dn$Is@wS0m3
Dn$Is@wS0m3
Dn$Is@wS0m3
Dn$Is@wS0m3
Dn$Is@wS0m3
Dn$Is@wS0m3
Dn$Is@wS0m3
Dn$Is@wS0m3
Dn$Is@wS0m3
External IPv4
128.107.215.11
128.107.215.12
128.107.215.13
128.107.215.14
128.107.215.15
128.107.215.16
128.107.215.17
128.107.215.18
128.107.215.19
128.107.215.20
128.107.215.21
128.107.215.22
128.107.215.23
128.107.215.24
128.107.215.25
128.107.215.26
128.107.215.27
128.107.215.28
128.107.215.29
128.107.215.30
4
OPDNS-POD-21
OPDNS-POD-22
OPDNS-POD-23
OPDNS-POD-24
OPDNS-POD-25
OPDNS-POD-26
OPDNS-POD-27
OPDNS-POD-28
OPDNS-POD-29
OPDNS-POD-30
OPDNS-POD-31
OPDNS-POD-32
OPDNS-POD-33
OPDNS-POD-34
OPDNS-POD-35
OPDNS-POD-36
OPDNS-POD-37
OPDNS-POD-38
OPDNS-POD-39
OPDNS-POD-40
sevt21@opendns.com
Dn$Is@wS0m3
sevt22@opendns.com
Dn$Is@wS0m3
sevt23@opendns.com
sevt24@opendns.com
sevt25@opendns.com
sevt26@opendns.com
sevt27@opendns.com
Dn$Is@wS0m3
Dn$Is@wS0m3
Dn$Is@wS0m3
Dn$Is@wS0m3
Dn$Is@wS0m3
sevt28@opendns.com
sevt29@opendns.com
sevt30@opendns.com
sevt31@opendns.com
sevt32@opendns.com
sevt33@opendns.com
sevt34@opendns.com
sevt35@opendns.com
sevt36@opendns.com
sevt37@opendns.com
sevt38@opendns.com
sevt39@opendns.com
Sevt40@opendns.com
Dn$Is@wS0m3
Dn$Is@wS0m3
Dn$Is@wS0m3
Dn$Is@wS0m3
Dn$Is@wS0m3
Dn$Is@wS0m3
Dn$Is@wS0m3
Dn$Is@wS0m3
Dn$Is@wS0m3
Dn$Is@wS0m3
Dn$Is@wS0m3
Dn$Is@wS0m3
Dn$Is@wS0m3
128.107.215.81
128.107.215.82
128.107.215.83
128.107.215.84
128.107.215.85
128.107.215.86
128.107.215.87
128.107.215.88
128.107.215.89
128.107.215.90
128.107.215.91
128.107.215.92
128.107.215.93
128.107.215.94
128.107.215.95
128.107.215.96
128.107.215.97
128.107.215.98
128.107.215.99
128.107.215.100
2. All PODs have an internal subnet of 192.168.10.0/24 and 192.168.20.0/24 for
off-network VM . The table below describes what each internal IP is mapped to / used
for.
Component
Windows Client
VM
Internal IP
192.168.10.10
Windows Client AC
VM
192.168.20.2
Domain Controller
VM
192.168.10.2
VMware ESXi Host
192.168.10.100
OpenDNS SEVT Guide
Where it’s used?
There will be a preconfigured RDP
session to connect to the Windows
Client in the lab topology diagram.
Login to this VM with d
​ emouser /
dnsl@b123!
There will be a preconfigured RDP
session to connect to the Windows
Client in the lab topology diagram.
Login to this VM with d
​ emouser /
dnsl@b123!
There will be a preconfigured RDP
session to connect to the DC in the lab
topology diagram. Login to this VM with
demouser /dnsl@b123!
There will be a VMware vSphere client
on the Windows Client VM to access
the ESXi Host
5
Gateway
Local DNS Server
Netmask
VA 1
VA 2
OpenDNS SEVT Guide
192.168.10.1
192.168.10.2
255.255.255.0
192.168.10.3
192.168.10.4
Umbrella VA configuration (1.3.2)
Umbrella VA configuration (1.3.2)
Umbrella VA configuration (1.3.2)
Umbrella VA configuration (1.3.2)
Umbrella VA configuration (1.3.2)
6
Table of Contents
Lab Exercise 1 - Deploy and Configure Umbrella
Step 1 - Create Identities
1.1 - Add network identity in Umbrella dashboard
1.2 - Download and install Roaming Client
1.3 - Deploy two Umbrella Virtual Appliances in ESXi
1.4 - Create internal network identities
1.5 - Download and install the OpenDNS Connector service
1.6 - A​dd your internal domains to the Umbrella dashboard
Step 2 - Create and Customize Policies
2.1 - Create policy for network identity
2.2 - Create policy for roaming computer identity
2.3 - Create policy for internal network identity
2.4 - Create policy for AD users/groups
2.5 - Policy precedence introduction
Step 3 - Generate Activity from ​Roaming Computer Identities
3.1 - Re-enable Roaming Client
3.2 - Test with debug query
3.3 - Generate DNS queries
OpenDNS SEVT Guide
7
Step 4 - Generate ​activity from network identities
4.1 - ​Change forwarders to point to OpenDNS
4.2 - Test with debug query
4.2 - Generate DNS queries
Step 5 - Generate Activity from Internal Network Identities
5.1 - Update DHCP options to point DNS to the VAs
5.2 - Test with debug query
5.3 - G​enerate DNS queries
OpenDNS SEVT Guide
8
Step 6 - Generate Activity from Active Directory Identities
6.1 - Move connect​or to same site as VA
6.2 - Logoff the user and logon the user
6.3 - Test with debug query
6.4 - Generate DNS queries
Lab Exercise 2 - Reporting
Step 1 - View Basic Reports
1.1 - View Security Overview Report
1.2 - View Activity Volume
1.3 - View Security Activity
1.4 - View Activity Search
1.4 - Report filters
1.5 - Share, bookmark, and download reports
1.6 - Schedule Reports
Step 2 - View Advanced Reports
2.1 - Cloud Services and IoT
2.2 - ​Security Insights
OpenDNS SEVT Guide
9
Lab Exercise 3 - Use the Investigate Console
Use Case 1: Get ​Additional Information About a Domain
1.1 - Find out why this domain was flagged as malicious
1.2 - Examine various data fields and determine significance
Use Case 2: Incident Investigation
2.1- Use information to determine if the domain is malicious
2.2- Pivot on co-occurrence and IP address
Use Case 3: Pattern Search and Proactive Research
Use Case: Pattern Search
Use Case: Proactive Research
3.1- Show that this is a known-bad domain
3.2- Pivot on co-occurring domain(s) and related domains
3.3- Pivot on ASN
3.5- Go back to original domain and pivot on WHOIS
Lab Exercise 1 - Deploy and Configure Umbrella
Exercise Description and Objectives
This exercise covers deployment for devices on and off the corporate network. Your goal is to
deploy the service on your current network and device, then generate DNS traffic to populate
the reports for the second lab exercise.
Step 1 - Create Identities in Umbrella
In Umbrella, an identity is a network, internal network, site, roaming computer or Active
Directory object, to which you can apply an Umbrella policy or to which Umbrella service can
attribute DNS traffic to. In this Step, you will first add a network identity, then add a roaming
OpenDNS SEVT Guide
10
computer identity. After that, you will deploy two Virtual Appliances within an Active Directory
(AD) environment. Then you will create an Active Directory user and deploy a Windows
configuration script and the Umbrella’s connector software to sync the Active Directory
components with Umbrella.
Step 1.1 - Add A Network to the Umbrella Dashboard
Add your network
Informational: ​Networks are identities in Umbrella that contain all of the devices within a
typical work network. Add a network to Umbrella to extend protection to any device that
connects to the Internet from that network space. We recommend starting with the network
that the computer you're currently using is connected to.
Login to your Windows VM. ​Go to the Topology tab of the GOLDLabs portal
Download the preconfigured RDP session by clicking on the C
​ LICK HERE TO RDP! > click on
the RDP Client button
OpenDNS SEVT Guide
11
In the folder where Downloads are saved on your laptop, you should find a file similar to
218.8.12.1_6218_SEC-OPENDNS-[##].rdp​ that you can click on to access the Windows VM for
your specific pod. The login is ​demouser / dnsl@b123!
Login to your Umbrella account.​ Within your Windows VM, open up a Chrome web browser
and go to ​https://login.opendns.com​. Login with email address s
​ evt[pod #]@opendns.com a
​ nd
password​ Dn$Is@wS0m3 ​(e.g. pod 3 would login with s​ evt3@opendns.com​ as the email
address). If there’s any confusion, you can find your pod specific email address in the Accounts
& IP Configuration Info section on page 3.
To add a network identity, on the left hand side expand ​ Identities, l​ ocal N
​ etworks​ and click the
+​ button at the top of the page.
OpenDNS SEVT Guide
12
Give the network a descriptive name and enter the external IPv4 address of the network along
with the subnet mask; usually a /32 subnet for a single IPv4 address.
If your ​pod number is between 1 and 20​, the IP address you will enter for your network is
128.107.215.[ your pod number + 10 ]​. For example, if your pod is O
​ PDNS-POD-1 your IP is
128.107.215.11.​ The IP address for your pod is also listed in the table on page 3 under the
Accounts & IP Configuration Info section
If your ​pod number is between 21 and 40​, the IP address you will enter for your network is
128.107.215.[ your pod number + 60 ]​. For example, if your pod is O
​ PDNS-POD-21 your IP is
128.107.215.81.​ The IP address for your pod is also listed in the table on page 3 under the
Accounts & IP Configuration Info section
IMPORTANT!
If your​ pod number is between 1 and 20, t​ he IP you will register in Umbrella is y
​ our pod
number + 10​ in the final octet.
If your​ pod number is between 21 and 40, t​ he IP you will register in Umbrella is y
​ our
pod number + 60​ in the final octet.
The dynamic option allows the network identity to be updated via an API using DDNS for
customers whose IP address may change over time. In this lab, the network IP is statically
assigned, so ​uncheck the Dynamic check mark and​ click Save.
An option can be enabled to send a stats email daily. If enabled, information on network activity,
including daily total requests, unique domains, domains, blocked domains, and request types
will be delivered for this network in 24-48 hours.
OpenDNS SEVT Guide
13
The service will validate your IP address and the network’s status will initially appear [
] for
the ​next 90-120 minutes​ as this new identity is registered in our stats collection system. After
this time elapses, if the network has sent at least one DNS request the status will turn to [ ]
indicating that it is “active”. For any 24 hour period, if there is at least one DNS request the
status will remain “active”.
Step 1.2 - Installing Umbrella Roaming Client
The roaming client is a lightweight software DNS forwarder which provides per-computer
granularity for both reporting and policy enforcement, extending protection to computers both on
and off network. While called the “Umbrella roaming client,” it is common to deploy the client on
both laptops and desktops. The client sends encrypted DNS requests with embedded identity
information directly to Umbrella on any network and gracefully handles local DNS requests.
There are two different options how to install Umbrella Roaming Client and both are covered in
this lab:
Standalone program:​ roaming client will be installed as stand alone program
AnyConnect module​: customers who already have AnyConnect installed can easily deploy
roaming client as an additional security module. AnyConnect for Windows or OS X, version 4.3
MR1 or later is required.
1.2.1 Installing roaming client as standalone program
Now, let’s install the roaming client as standalone program.
RDP to CLIENT VM if you are not already connected. Open Chrome and click on the
bookmark labelled Umbrella. Login using credentials relevant for your pod. Expand I​ dentities
and select ​Roaming Computers​, and click on the blue plus to the top of this window.
OpenDNS SEVT Guide
14
Download links as well as documentation for both Mac and Windows versions are available. Pick the
Windows version and download the archive.
IMPORTANT! ​Installers are unique to the organization from which they’re downloaded.
Please do not use an installer from one organization with a second organization.
Next, we’ll do a manual installation. For small to medium size business, this is often the best
way to install the roaming client. In advance of any mass deployment, be sure to test a
representative computer.
NOTE:
●
●
Before installation, we highly recommend the customer review the prerequisites:
https://docs.opendns.com/product/umbrella/prerequisites/
You can hide the tray icon and/or to hide the program from available applications for removing
software (Add/Remove Programs on Windows). For more information on how to do this,
read command line and customizations: ​support.opendns.com/entries/67344494
OpenDNS SEVT Guide
15
●
It’s possible to deploy the roaming client via automated mass deployment using tools such as
Group Policy Objects and Apple Remote Desktop. This functionality is what most software
deployment tools will use. We have specific guides for the most common software
deployment tools, such as GPO, Orca, or inclusion in a disk image. For more info, read here:
support.opendns.com/entries/67344494
Extract the zip file you downloaded and run through the wizard to install the software locally.
IMPORTANT! ​You must extract the executables to disk before running the executable, do not
run the executable within the zip preview. Do not move the Setup.exe installer to another
directory. It must be executed in the same folder as the OrgInfo.json file.
OpenDNS SEVT Guide
16
Click on the Setup installation file and follow the quick and easy wizard with virtually no options.
Ensure the installation was successful by checking for the Umbrella’s roaming client icon in the
system tray. It should be green and say Protected and Encrypted.
OpenDNS SEVT Guide
17
If you refresh the Umbrella portal page, you will see the hostname of the Windows Client VM
show up in the Umbrella dashboard.
1.2.2 Installing roaming client as AnyConnect module (Umbrella’s roaming
security module)
As of August 2016 the Umbrella’s roaming client can be also installed as an AnyConnect
module. This new method allows us to reach AnyConnect customers base (185 million
installations) and seamlessly deliver DNS layer security. Limiting number of clients customers
need to run on their endpoints is highly appreciated. In this scenario, we will install the security
module on another Windows machine (CLIENT AC VM) which has pre-installed AnyConnect
(AC) 4.2. This is our starting point and through the process we will upgrade to AC 4.3 MR1
which is required to run Umbrella’s roaming client as a security module within AC.
OpenDNS SEVT Guide
18
From laptop RPD to Client VM if you are not already logged in. Locate pre-set RDP session
shortcut on the desktop that connects to Client AC VM (the machine with pre-installed AC 4.2)
Double click the icon and if asked for username or password use ​demouser​/​dnsl@b123!​ .
When you get connected to the Client AC VM notice in system tray that AnyConnect is already
running, this is the 4.2 version.
Now, in order to get the roaming client AnyConnect module we need to upgrade to AnyConnect
4.3 MR1 and select Umbrella Roaming Security module during the installation process.​ ​Go to
Downloads folder, right click on a
​ nyconnect-win-4.3.02039-pre-deploy-k9.iso and and select
MagicISO-​>​Mount​ a​nyconnect-win-4.3.02039-pre-deploy-k9.iso . This will mount the
installation disk.
OpenDNS SEVT Guide
19
Go to Computer and you should see AnyConnect icon as a mounted disk. Double click the icon.
It might happen that the AC ISO is already mounted and when you double click you get inside
the folder. If this happens double select …
When the installation screen pops-up select AnyConnect VPN and AnyConnect Umbrella
Roaming Security. Click “Install Selected”
OpenDNS SEVT Guide
20
After successful installation reboot the machine.
In order to reboot, click Press Alt+F4 (if your laptop is running Windows 10, click Alt + Fn + F4)
to bring up the Shut Down Windows popup menu and select Restart. The RDP session will be
shut down so you need to reconnect to the CLIENT AC via RDP again.
Note: “Help the key combination for reboot doesn’t work”
Windows 10: click ​Alt + Fn + F4
Mac: You don’t have those buttons silly, open a windows command prompt and type in
shutdown -r ​and press enter.
You should be now running AnyConnect 4.3 with Umbrella Roaming Security module. Open the AC icon in
system tray (right hand bottom corner). ​Notice, that you are not yet protected because the correct
profile is missing and module is not yet connected to Umbrella service​. We will fix this in the next
step.
OpenDNS SEVT Guide
21
We need to download the missing profile from Umbrella Dashboard. Open Chrome browser and
click on the bookmark labeled U
​ mbrella​. Login with your username and password .​ ​ In the
dashboard, expand ​Identities a
​ nd select​ Roaming Computers​, and ​click the + section at the top of
the page to get going. ​Scroll down at the bottom of the page and click on “MODULE PROFILE” to
download the profile ​for AnyConnect (OrgInfo.json). The OrgInfo.json file is specific information
about your Umbrella dashboard instance that lets the Umbrella’s roaming security module know
where to report and which policies to enforce.
The OrgInfo.json needs to be copied into “​C:\ProgramData\Cisco\Cisco AnyConnect Secure
Mobility Client\Umbrella”.
Action: The ProgramData folder is hidden. You must manually type
“C:\ProgramData\Cisco\Cisco AnyConnect Secure Mobility Client\Umbrella”
into Windows Explorer to navigate to the right folder.
Within couple of of seconds the Umbrella’s roaming security module scans the folder and
detects the profile and change its status.
OpenDNS SEVT Guide
22
If all goes well you are now protected by Umbrella service.
Login back to Umbrella dashboard or refresh the page if you are already logged on. You should
now see 2 roaming users connected. One via Umbrella’s roaming client as a standalone
program and one as AnyConnect module (Umbrella roaming security).
You can now logout from the this RDP session.
Note​: ​if a customer already has AnyConnect 4.3 MR1 installed he needs to run the
installation file (iso) again. The rest of the steps are the same.
Step 1.3 - Deploy 2 Virtual Appliances in VMware ESXi
The purpose of Umbrella’s virtual appliances is to embed local IP addresses within
Internet-bound DNS queries and then forward that query to Umbrella.
Virtual appliances run in ​both Hyper-V and VMware ESXi, but for this lab we are using
VMware ESXi.
The ​Virtual Appliance​ does the following:
OpenDNS SEVT Guide
23
●
●
●
Runs in a virtualized server environment and forwards local DNS queries for internal
domains to your existing DNS servers and all other DNS queries for Internet domains
to Umbrella.
Captures the local IP of the computer making the external DNS request and includes it
in the query sent to Umbrella.
If Active Directory integration is enabled, the virtual appliance forwards external DNS
queries with non-sensitive metadata to Umbrella to identify the AD user or computer.
IMPORTANT!
● In order for new versions to be automatically updated on the Umbrella’s virtual appliances
we require a minimum of two virtual appliances installed, otherwise the only way to
upgrade a virtual appliance is by pressing the upgrade button in the Dashboard.
Performing an in-place upgrade of a single virtual appliance will result in up to 15 minutes
of downtime during which time you will not be able to perform DNS queries on the network,
and effectively will not have Internet service. We strongly advise against such single VA
deployments and they may not be supported in the future.
● In order for the Virtual Appliance to properly route local DNS queries and external DNS
queries, all devices managed by Umbrella must have their DNS servers set to the
addresses of your virtual appliances.s.
Informational: ​Your ESXi and network have been preconfigured for you. Make sure your
customers review the prerequisites before they start installing the VAs. Not having the
necessary ports open in the network is a very common issue. For more information on
specific prerequisites, go to: ​https://docs.opendns.com/product/umbrella/prerequisites-2/
Step 1.3.1 - Create your Virtual Appliances in ESXi
To deploy your first VA, ​log into your ESXi server using the VMware vSphere client from the
Windows Client VM (not the Domain Controller VM or CLIENT AC). For your convenience, the
.ova files required for VA installation have already been downloaded and are located on the
Windows Client VM’s desktop.
OpenDNS SEVT Guide
24
In a typical customer environment, however, the customer would login to the Umbrella
Dashboard. Expand ​Settings ​and select S
​ ites and Active Directory​, then click ​Download
Components​ to download the VAs from within the Dashboard. There are no external links to
download VA .ova files.
OpenDNS SEVT Guide
25
Note: ​Downloading the VAs is the longest part of the process. When providing support to
customers, make sure they’ve already downloaded the .ova file. It’s most efficient for the
customer to try the installation and report the exact error they encountered to support.
Double click on the
​icon on the desktop to start up the VMware vSphere Client.
Once the vSphere Client connects you to the ESXi host select the​ [File]​ tab, and click ​[Deploy
the OVF Template...]​ and find the .OVA template on the Windows Client VM’s desktop.
Next up, follow the deployment wizard prompts, but be sure to follow these key steps:
1.
2.
For the source, ​browse ​to the​ .ova file you on your desktop > c​ lick​ Open > ​click​ Next
Override the default name with a unique name (e.g. “VA-1 San Jose”).
OpenDNS SEVT Guide
26
Note: ​It may be helpful to include the VA’s location or IP in the name for quick reference.
For this lab environment, the VAs will have the following static IPs,
VA-1 192.168.10.3
VA-2 192.168.10.4
Next, select the disks appropriate to your environment (in this demo lab environment it is
local-ds-vms​ as shown in the screenshot below).
During the disk format, make sure you select the ​[Thin Provision]​ radio button.
OpenDNS SEVT Guide
27
Typically, the next step for customers is to select or map a network. However, our lab
environment only has a single network, so the screen below does not appear.
Check the ​Power on after deployment b
​ ox,
Click [​Finish​] after completing the deployment configuration. System prompts will update you on
the status.
OpenDNS SEVT Guide
28
Note:
●
●
●
Most customers will have their VAs in the same network that they want to see
Umbrella reports for. When working with customers, make sure to select the correct
VLAN or LAN that includes the VAs.
Customers using AD integration (covered later in the lab) must choose the VLAN or
LAN that includes the VAs and Domain Controllers (DCs).
While the first VA is deploying you can begin to configure a second VA for high
availability. Do not clone the first virtual appliance when creating a second Virtual
Appliance. Instead, please repeat the above steps when deploying your second
virtual appliance.
Repeat this step to deploy a second VA and give it a unique name (e.g. “VA-2 San Jose”).
Step 1.3.2 - Configure your Virtual Appliances in their terminal
Select the virtual appliances just created by expanding the left-side menu for 192.168.10.100.
The VAs should be powered on already. If not, right-click on each VA and select P
​ ower >
Power on​. Right-click the VAs again and select [​ Open Console]​, which will bring you to the
command screen to configure your VAs.
OpenDNS SEVT Guide
29
After a brief boot up process you will be prompted to configure the DNS forwarder. You can
move between fields by using the ​[Tab]​ key. To release the cursor from the VA Console press
[​Ctrl] + [Alt]​.
In the Forwarder Configuration screen for each VA, please enter the following information:
VA-1
VA-2
Name: VA-1 San Jose
Name: VA-2 San Jose
IP: 192.168.10.3
IP: 192.168.10.4
Netmask: 255.255.255.0
Netmask: 255.255.255.0
Gateway: 192.168.10.1
Gateway: 192.168.10.1
Local DNS 1: 192.168.10.2
Local DNS 1: 192.168.10.2
Local DNS 2: Blank
Local DNS 2: Blank
OpenDNS SEVT Guide
30
Note:
●
●
The name field appears in your Umbrella dashboard next to the managed VA. It
helps to name this the same as in vSphere (e.g. “VA-1 San Jose”).
The local DNS fields should be populated with your local DNS servers. These are
typically the IP addresses of your Windows Servers where both the Active
Directory Domain Services and DNS Server roles are installed. In this lab, the
DNS is the Domain Controller, which is 192.168.10.2.
Finally, press ​[Return]​, then tab to ​[Save]​ and press ​[Return]​ again.
IMPORTANT!​ All VA time zones are GMT +0.C.
(you do not need to set the time zone for the VAs, this is just FYI).
Once you’ve hit ​[Return]​, you should see a sync message indicating that the VA and the
Umbrella service are communicating. It takes a couple of minutes for all tests to pass
successfully as the VA needs to register with our API (e.g., the Updates test specifically may fail
until the VA has fully synced with the API).
If you receive any error messages, or would like to to know more about what each of these tests
are, you can tab to the test and hit ​[Return]​:
OpenDNS SEVT Guide
31
The information here can help you understand what network issue might exist between the VA
and the Umbrella APIs. In this example, the SSL test to the host 'disthost.opendns.com' on port
443 timed out. If you were unable to complete the tests, please check the ESXi network
configuration to ensure you've matched it properly.
Once you've identified and resolved the issue, the tests continue to run in the background and
the test will subsequently succeed without intervention. If you'd like to ensure the tests are run
successfully, you can reboot the VA by going to the System Menu ​[CTRL+S].
OpenDNS SEVT Guide
32
Assuming the tests were completed without error, the next step is to verify the virtual appliance
syncs within your Dashboard.
When you return to the Dashboard, under S
​ ettings > Sites & Active Directory​, you should see
your VAs listed with the name you gave it earlier in the VA Console configuration.
Note: ​If you see a ​warning about DNSCrypt not being enabled​, stay calm and
proceed. You can read about DNSCrypt ​here​, but this warning will not cause you any
problems during this lab.
Your first VAs has been provisioned successfully.
In a simple configuration like this a customer would deploy their VAs to the “Default Site” only,
and by default, the VAs are assigned to the “Default Site”. However, in this configuration, and
larger multi-site deployments, VAs should be added to their own site.
Note: ​A site represents a set of devices that are connected by a high-speed network,
such as a local area network (LAN). Typically, all devices in the same physical site
reside in the same building or perhaps the same campus network. In Umbrella, a site
refers to a set of components (VAs, Connectors, and DCs) which communicate only with
each other.
OpenDNS SEVT Guide
33
Step 1.4 - Create Internal Network Identities
Now that we’ve deployed and configured our VAs, an internal network identity can be
configured.
The purpose of the internal network identity is to define a subnet that's non-externally routable
(or RFC1918 compliant) as an identity you can apply policies to. To create an internal network
identity, in the Umbrella Dashboard, expand​ Identities a
​ nd select​ Internal Networks, t​ hen
click the blue + ​at the top of the page.
You'll be asked to name your network and provide a valid subnet. In this lab, you are given a /24
subnet, so the final octet of the IP will be .0. Enter in 192.168.10.0/24 to cover the entire VLAN.
The configuration should look like this:
Later, we’ll configure a policy for these identities but for now let’s move on to integrating the VAs
with your Active Directory environment.
Step 1.5 - Prepare your Domain Controller VM to integrate with Umbrella
In this step, we’ll configure the Umbrella’s connector to communicate with the Domain Controller
(DC) and the VAs we configured earlier.
Let’s connect to your Domain Controller (DC) VM through your Windows Client VM.
OpenDNS SEVT Guide
34
From your ​Windows Client VM ​click on the pre-set RDP session labeled DC.rdp on your
Desktop. Use demouser/dnsl@b123! if you get ask for username/password.
Just click Yes if you run into this certificate warning.
First time logging in you may also encounter Windows Activation prompts, just click through
them to proceed.
Note: ​The AD environment provided for you has been preconfigured. To view the
customer prerequisites and other caveats, go to: s​ upport.opendns.com/entries/22231083
Step 1.5.1 - ​Create the​ ​OpenDNS_Connector user
First, we need to create a user for the Umbrella’s connector service to use. Start off by creating
a user called​ ​OpenDNS_Connector. In the Server Manager’s left-side pane, expand the options
as follows: [​Server Manager > Roles > Active Directory Domain Services > Active Directory
Users and Computers > odnslab.local​]. Then, right-click on [​Users​] and select [​New > User​].
OpenDNS SEVT Guide
35
We recommend using the same password as the demo user (​dnsl@b123!​)​ so that it meets the
password requirements. If you do not use the same password, enter one without backslash or
quotation characters.
Create this new user account with the following settings:
● The first name set to “OpenDNS_Connector”
● The logon name set to “OpenDNS_Connector”.
● The box ‘Password never expires’ checked.
Click Next and Finish.
OpenDNS SEVT Guide
36
Right-click the OpenDNS_Connector user and select [​Add to a group…​]. Add membership in
the following groups:
●
●
●
Event Log Readers
Distributed COM Users
Enterprise Read-only Domain Controllers
Start typing the first couple of characters for the group names and you can press the C
​ heck
Names button​ to populate. This is a good way to confirm you spelled the names correctly.
OpenDNS SEVT Guide
37
Step 1.5.2 - Download and run the Windows Configuration script on your Domain
Controller
Open up a Chrome browser (shortcut is on the desktop) in the ​DC VM​ (this is the RDP session
you have open to 192.168.10.2) and click the bookmark labeled U
​ mbrella ​and login with your
pod related credentials.
Reminder: ​Login with email address s
​ evt[pod #]@opendns.com a
​ nd​ ​password
Dn$Is@wS0m3 ​(e.g. pod 3 would login with s​ evt3@opendns.com​ as the email address).
If there’s any confusion, you can find your pod specific email address in the Accounts & IP
Configuration Info section on page 3.
In​ the Umbrella Dashboard expand S
​ ettings > Sites & Active Directory.​ Click on [​ ​Download
Components]​ at the bottom of the page, then download the W
​ indows Configuration​ Script​.
Note: ​The Windows Configuration Script is written in Visual Basic. For reference, it
automates these human-readable instructions s​ upport.opendns.com/entries/22263028
To run the script as an admin, open an elevated command prompt by going to S
​ tart > type in
“cmd” > right click on the cmd program > Run as administrator
OpenDNS SEVT Guide
38
Then from the command prompt, enter: ​cscript <filename> … where <filename> is the name of
the configuration script you just extracted.
For this lab, enter:
cscript C:\Users\demouser\Downloads\OpenDNS-WindowsConfigurationScript-20130627.wsf
The script will display your current configuration, then offer to auto-configure the Domain
Controller for operation. When prompted, enter “y”. If the auto-configure steps are successful,
the script will register the Domain Controller with the Umbrella Dashboard.
OpenDNS SEVT Guide
39
After the script has run, go back to the Umbrella Dashboard and verify the that DC appears
there.
When you return to the Dashboard, you will see the hostname of the Domain Controller
ODMS-DC on which you just ran the script in the ​[Inactive]​ state on the ​[​Sites & Active
Directory] ​page.
OpenDNS SEVT Guide
40
IMPORTANT!
In an environment with more than one DC, this script needs to be run on all r​ ead write
domain controllers in order to help them prepare to integrate with the Umbrella’s connector
service. The script does not need to be run on read only DCs. The configuration script only
runs once; it is not an application or service. If you change the IP address or hostname of the
Domain Controller, remove the previous instance of the Domain Controller by clicking the
round X icon to delete it from the Umbrella Dashboard.
Step 1.5.3 - Download and install the Umbrella’s connector service on your
Domain Controller
The purpose of the Umbrella’s connector service is to monitor one or more Domain Controllers.
It listens to user and computer logins via the security event logs, and subsequently enables
IP-to-user and IP-to-computer mappings on the Virtual Appliances. It also synchronizes
user-to-group, computer-to-group and group-to-group memberships with Umbrella, enabling you
to create and enforce group-based settings and view user, computer, and group-based reports.
The Connector helps import your Active Directory users, groups, and computers to provide
these mappings. Other Active Directory objects, including Organization Units (OUs) are not
imported.
Note: ​You only need to install one Umbrella’s connector per Umbrella site, but you may
install more than one. If your security policy does not allow you to install software directly on
your DC, you can install the Umbrella’s connector on a separate Windows member of the
same domain (see https://support.opendns.com/entries/22240922) The Windows
Configuration Script from the previous step must still be run on all DCs.
To install the Connector:
1.
From the Dashboard expand ​Settings ​and select S
​ ites and Active Directory​, then click
Download Components​, scroll down the page and download the W
​ indows Service
archive.
OpenDNS SEVT Guide
41
2.
Extract the contents of the ZIP file you downloaded to a folder. DO NOT RUN INSIDE
THE ZIPPED FOLDER. Make sure you’ve downloaded and extracted only to a local
drive.
Navigate to that folder.
4. As an admin, run ​setup.msi​.
5. Enter the password (dnsl@b123!) you configured for the O
​ penDNS_Connector​ user
you created in Step 1.5
3.
6.
7.
Follow the setup wizard prompts.
When finished, click ​[Close]​.
Next, we’ll want to check in the Umbrella Dashboard to ensure the AD components, such as AD
users have sync’d.
You will see the hostname of the Domain Controller on which you installed the Umbrella’s
connector on the [​Sites and Active Directory]​ page.
OpenDNS SEVT Guide
42
Note: ​Normally, you would assign the Umbrella’s connector(s) to the same site as the VAs
and Domain Controller(s) immediately to allow Umbrella to automatically configure and
connect the VAs to the Domain Controllers. For the purposes of this lab, we are delaying this
step. So the status will remain in “alert”​ for the Connector and “inactive” for the Domain
Controller (aka. “AD Server”) that we just ran the Windows Configuration Script on until we
perform this later in step 6.1.
Next, expand ​Policies ​in the right hand side menu and click on Policy List​.
The Umbrella’s connector should automatically sync user and computer group memberships,
and any subsequent changes, with Umbrella. You can verify that this has occurred
successfully by clicking the ​[+] icon ​and confirming that you see our three VMs’ hostnames as
“AD Computers” and Administrator, Demo User, and OpenDNS_Connector as “AD Users”.
Note: ​It can take ​up to 15 minutes​ for large numbers of AD users, computer, and group
objects to synchronize for the first time. In our lab the delay should be short, so talk to your
proctor if it has been 15 or more minutes. You can continue on to section 1.6 and just check
back on the AD users later.
After AD is done synchronizing, you should see 3 AD computers and 3 AD users.
OpenDNS SEVT Guide
43
1.6 - Add your internal domains to the Dashboard
IMPORTANT! ​This step has been delayed for the purposes of this lab. In a typical
deployment, customers should set up internal domains in their dashboard before installing
the roaming client or deploying VAs. Failing to do so will result in inaccessibility of local
resources and serious business continuity disruption.
Adding internal domains is a critical step in ensuring that Umbrella works as expected. This step
is often missed by customers during initial setup and results in an inability to resolve internal
network resources — printers, file servers and so on — and can derail any deal you’re working
on.
The internal domains feature allows DNS queries for certain domains to query the local
network's DNS servers instead of Umbrella when using the Umbrella’s roaming client or Virtual
Appliances. Without specifying internal domains, all DNS queries will be sent to Umbrella
directly. As a result, these queries will not be able to reach your network's local resources
(computers, servers, printers, etc) on internally-hosted (e.g. Intranet) domains that rely on local
DNS servers. Internal domain information will automatically propagate to the Umbrella’s roaming
clients and the virtual appliances within 10 minutes.
Expand ​Settings ​and select​ Internal Domains​.
Enter any internal DNS zone or domains. In this case, we’ll add the Active Directory domain
“odnslab.local”.
Note:​ For all customers, the internal domains section is pre-populated with .local and the
reverse lookup zones of private internal networks (i.e. ​RFC-1918​). This is to prevent
customers from forgetting to add domains associated with the most common internal
network configurations. In this lab example, we’re going to add the odnslab.local name
anyway (but it’s actually already there.)
OpenDNS SEVT Guide
44
You can choose whether to apply this internal domain to “All Appliances and Devices”,
or only the Virtual Appliances.
Step 2 - Create and Customize Policies
Policies are the rules for network security, content filtering, block pages, and logging level that
Umbrella applies to Internet activity from the identities when they reach its Global Network.
These steps apply when creating your first policy and when returning to edit an existing policy.
By default, there's always a single policy — the U
​ mbrella’s default policy​. This policy applies to
all identities when no other policy takes precedence for that identity. In other words, the
Umbrella’s default policy is a​ catch-all to ensure all identities within your organization receive a
baseline level of protection.
A policy can be applied to any combination of identities available in the Dashboard, and some
categories (such as AD Computers) can be expanded to more selectively choose which
identities will be affected by a policy.
OpenDNS SEVT Guide
45
Step 2.1 - Create policy for network identity
The process of creating policies is largely the same for any given identity. It is done through a
wizard, which can be found under P
​ olicies​ in the Umbrella Dashboard.
Expand​ Policy​ ​List ​and click ​+ ​at the top of the page​ ​to launch the policy wizard. In the wizard,
you’ll see several items to select:
In this first stage of the wizard, select only the network identity created in Step 1.1. Click [​ Next]​.
Step 2.1.1 - Apply Security Settings to the Policy
In the second step of the wizard, you’ll have an opportunity to select a category setting for
content filtering, a security setting, and add specific domain lists.
OpenDNS SEVT Guide
46
To start, click on​ [add new setting] .​
The “Create New Security Setting” modal will appear (see figure on the next page). These
settings allow the configuration of which types of security threats are blocked. Malware, drive-by
downloads, and mobile threats cannot be disabled. This is also where you could enforce
information about malicious domains coming from integrated solutions such as FireEye or Cisco
AMP Threat Grid.
The Intelligent Proxy feature is available in the Insights and Platform Umbrella packages when
roaming client is deployed. This allows for URL-based malware filtering for domains which
contain legitimate content but may also include pages that contain malicious files. Make sure to
check the “Enable Intelligent Proxy” radio button to enable this feature.
The “Enable SSL Decryption” option enhances security by performing HTTPS inspection.
“Enable IP Layer Enforcement”​ blocks malicious activity that tunnels connections directly by IP
instead of using DNS lookups by using the Umbrella’s roaming client’s technology to route those
connections to Umbrella. Be sure to check the ​“Enable IP Layer Enforcement”​ radio button to
enable this feature.
For more information on Umbrella packages visit our p
​ ackages page​.
OpenDNS SEVT Guide
47
Select whichever security protection options you’d like and click [​ Add]​.
Step 2.1.2 - Apply Category Settings to a policy
Next up, we’ll add a category setting to this policy. These settings allow the selection of content
filtering categories to be blocked for the identities selected in Step 1 of the policy wizard.
To create a new set of content filtering rules, click [​add new settings​] next to “Category setting
to enforce” or select an existing saved setting from the drop down menu. By default, no content
categories are blocked.
OpenDNS SEVT Guide
48
Adding a new setting or clicking on the name of the setting will bring up the C
​ ategory Settings
editor shown below.
A detailed list of all
categories is located
OpenDNS SEVT Guide
49
here: ​https://support.opendns.com/entries/27489550
Select one of the other predefined settings or check some of the individual categories. Enter a
name for this non-default setting, and click [​Save​].
Informational: ​If “Whitelist-Only mode” is checked, only domains explicitly allowed on a
domain list will be allowed. Since many websites require many content domains, this option
may take time to build a domain list and is NOT recommended for most people.
Whitelist-Only mode is an option next to category setting in the policy wizard:
Step 2.1.3 - Add a Domain List to your policy
Domain lists allow the customization of filtering by creating a list of domains that are explicitly
blocked or allowed. Note that each domain list can be set to be a block list (default) or an allow
list. We recommend adding domains in the format "domain.com" rather than www.domain.com
to ensure *.domain.com is included.
Allow list entries will always take precedence over block list entries. For example:
●
●
Blocking domain.com and adding mail.domain.com to the whitelist will still allow
mail.domain.com.
Adding domain.com to the allow list and blocking sub.domain.com will still allow
sub.domain.com.
To add a domain list, click on [​ add new destination list]​ > Add Block List and enter domains to
you want blocked. Enter juniper.com into, click add to list and then click add.
OpenDNS SEVT Guide
50
Notes:
● Domain lists are not saved until the [​Add​] button (note: [​Save​] for existing lists) is clicked,
despite appearing in the list view after entering it.
Step 2.1.4 - Block Page - create new or use default
After you’ve added your security, category and domain list, click ​[Next]​ in the policy wizard and
you’ll be brought to “Select Block Page Settings.”
In this section of the policy wizard you can configure a customized​ block page by clicking [​add
new setting​]. You can choose a generic message across all block pages, or customize the
message per type of block page.
OpenDNS SEVT Guide
51
The block can also redirect to a custom URL or IP. If not redirecting to a custom URL or IP, a
contact form can be added to allow blocked users to contact the administrator at the email
provided.
Finally, a custom logo can be uploaded to be displayed on the block page in place of the
Umbrella logo.
Notes:
● For this lab, feel free to use the defaults for block page settings.
● IMPORTANT: If a DNS query for an HTTPS site is blocked by Umbrella, by default, the
customer will see a browser warning. In order to resolve this for a customer, you advise
that they install the Cisco Root Certificate. For instructions, visit B
​ lock Page Settings >
Root Certificate​ in the dashboard. In future releases, the ability to install the root
certificate will be required for full feature functionality (the ability to decrypt SSL for use of
the Intelligent Proxy feature).
OpenDNS SEVT Guide
52
In the last step in the policy wizard, make sure to leave logging enabled for this policy so we can
make the most of out of the reports. Logging is enabled by default.
OpenDNS SEVT Guide
53
Label this policy “On-Network Policy” to easily identify it, as we’ll want to re-order these policies
in a later step. Click [​Save​] to save the policy.
Step 2.2 - Create policy for Roaming Computer identity
Following the same steps as above create a policy called “Off-Network Policy”. Select your
roaming client in the identities section of the policy wizard.
OpenDNS SEVT Guide
54
In the last step of the wizard change the request logging level to “Content logging disabled”.
This will maintain the user’s privacy while working remotely without sacrificing any threat
protection.
Step 2.3 - Create policy for internal network identity
Following the same steps as above, create and label a unique “Internal Network Policy” for the
internal network identity and only that identity. To access the internal network you created in
step earlier, go to [​add a new policy​] > 1. Select Identities, ​click on Sites​ > ​click on San
Jose​ > ​check the San Jose Internal Network
Note: ​You can also add a site here instead, depending on your preference in your
configuration and whether you added a site earlier.
OpenDNS SEVT Guide
55
Finish out the policy creation as you did in the previous steps. Make sure logging is enabled by
default.
Step 2.4 - Create policy for AD users/groups
Again, following the steps above to create a unique “User Policy” for an AD Users. We do have
3 users.
Once you complete this step you should end up with the list of policies as the figure below
shows.
OpenDNS SEVT Guide
56
Step 2.5 - Policy precedence introduction
Looking at your policies, you’ll see all four of the newly created policies along with the “Default’
Policy”. The policies are ordered and the order indicates that the first policy that’s been created
will take precedence over the other policies in the list.
In general, the top-most policy in the list that is added to an end user will apply. However, this
gets more complex when a device has multiple identities such as roaming computer and Active
Directory (user, computer, and group) identities. If an identity has no matches in any custom
policy, the identity will be applied to the “Default Policy”. Each policy has the option to select any
combination of identities.
For example, "Joe", a user in Active Directory can be added to several different policies as an
individual user, and be included as part of any policy with "All AD Users." Since "Joe" can be in
any of several policies, it's critical to understand the order in which those policies are applied to
"Joe." A common misconception is that policies are additive, and by creating a "YouTube Policy"
and "Facebook Policy", then adding identities, would allow all checked identities to access these
sites. This is not the case!
Policies are applied based on a "first match" methodology which follows a top-to-bottom
execution order. Therefore, only the top-most policy that matches a user's identity will be
applied, and all subsequent lower matches will be ignored. Policy order is modified via drag and
drop operation using the "handles" along the left hand side of each policy bar.
OpenDNS SEVT Guide
57
In cases where a user belongs to multiple identities, for example a roaming computer and
network, there is an identity precedence order that would take place. This would affect statistics
and reports only, since the same policy would result in identical filtering and security settings.
Informational:
● To learn more about identities, go to ​support.opendns.com/entries/50739684
● For best practices on organizing policies, go to s​ upport.opendns.com/entries/22645408
Step 2.6 - Policy Tester
In order to help understand how your policies work and whether they’re doing what you expect,
you should use the Policy Tester. ​The tool can be found at the top of your Policies page in the
Umbrella Dashboard, just click "Policy Tester" to expand:
Two fields are required-- an identity or identities to test against and a destination. The idea is
that the tester will determine, based on the way you've configured your policies, whether the
identity you've selected can reach the destination you've defined. Depending on whether you
expect that the identity should or should not reach that destination, it will offer assistance to
understand why the results are what they are.
The two fields are both required.
When you enter your identities, the field will allow you to 'type ahead' and search, so just
entering the letter 'A' will give a list of all identities with that letter in it.
IMPORTANT!:​ The destination can only be a fully qualified domain name. IP Addresses
and URLs are not supported.
The reason you might want to enter more than one identity is when you'd want to see which one
of the identities would take priority. For instance if there were a policy for a computer that had a
roaming client installed and was also protected with one or more network identities, it may not
OpenDNS SEVT Guide
58
be clear which of these policies would take effect. The policy tester will let you know which
identity would be triggered first and by which policy.
Once you've selected the identity or identities you'd want, click 'Run Test' to get your results:
The 'Reset' button can be used to clear the fields for both identities and destination.
Give the policy tester a try-- it’s a helpful troubleshooting tool and emphasizes how easy it is to
use Umbrella.
Step 3 - Generate Activity from Roaming Computer Identities
Next, we’ll generate some DNS queries from the roaming computer identity.
3.1 - Test with debug query
Let’s verify that the roaming client is routing DNS traffic to Umbrella for resolution. Open an
elevated admin command prompt and run:
nslookup -type=txt debug.opendns.com
Here’s is output that indicates Umbrella is properly configured,
nslookup -type=txt debug.opendns.com
Server:
127.0.0.1
​# The roaming client (RC) forces DNS to 127.0.01
Address:
127.0.0.1#53
​# The RC binds to port 53 and sends the DNS request
​# through our encrypted protocol ​DNSCrypt
Non-authoritative answer:
debug.opendns.com text = "server 1.pao"
debug.opendns.com text = "device 0101EB02077D144B" ​# unique device ID assigned to this device.
debug.opendns.com text = "flags 422 0 4040 1BFF000000000000000"
debug.opendns.com text = "originid 39164643"
debug.opendns.com text = "orgid 95886"
debug.opendns.com text = "actype 0"
debug.opendns.com text = "bundle 14918"
debug.opendns.com text = "source 70.211.73.186:3504"
debug.opendns.com text = "dnscrypt enabled (717744506545635A)"
OpenDNS SEVT Guide
59
Authoritative answers can be found from:
The unique device ID enables Umbrella to tie DNS requests to this specific machine no matter
what network it’s connected to.
If OpenDNS is ​not​ working properly you will get this output,
$nslookup –type=txt debugopendns.com
Server:
8.8.8.8
Address:
8.8.8.8#53
** server can’t find debug.opendns.com: NXDOMAIN
The text record debug.opendns.com can only be found if Umbrellla is used for DNS resolution.
Since the example above is using Google DNS (8.8.8.8), it is unable to find the
debug.opendns.com.
3.2 - Generate DNS queries
Using the browser on the Windows Client VM, browse the Internet. Go to a few standard
websites that have a lot of CDN-generated content (cnn.com is a good example). Try a test
malicious website (​internetbadguys.com​). Feel free to visit a few more of your own choosing
both good and malicious sites.
Optional: ​To test whether you're
blocking malicious IP (IP Layer
Enforcement), Umbrella has set up a
test page: ​ipblock.opendnstest.com​.
The page seen below displays
correctly when the feature is enabled
and working for the roaming client
installed on the computer. However,
once we get to step 5 and point DNS
traffic through the Umbrella Virtual
Appliances, the roaming client will be
automatically disabled. This is
normal behavior.
OpenDNS SEVT Guide
60
Remember: ​During step 2.1.1, you should have checked the Enable IP Layer Enforcement
check box in order for the IP blocking test page to work.
Step 4 - Generate Activity from Network Identities
It’s time to start sending DNS traffic generated by your network identity to Umbrella. This will
enable us to see how the policies we created apply to the data reaching the Umbrella’s global
network. It will also allow us to view reports on that data.
Note: ​Smaller branch offices may not have their own internal DNS server. In these cases you
can use the DHCP server role or router to instruct all on-network devices to point DNS traffic
to Umbrella. For this lab, we will assume we are working with a larger network and point
traffic using the internal DNS server.
Step 4.1 - Change forwarders in the DC VM’s DNS Server Role to point to
Umbrella
Log back into the Domain Controller and change the DNS forwarders on the server to point to
Umbrella. The steps to do this are:
1.
2.
3.
4.
5.
From the Start menu, select “Administrative Tools”, then select “DNS”.
Choose the server you’re logged currently into, right click select properties.
Then select “Forwarders” tab in the newly opened window.
Click the [​edit​] button.
Add Umbrella’s addresses in the IP address list. The addresses for Umbrella service are
208.67.222.222 and 208.67.220.220.
Note: ​You should only have 208.67.222.222 and 208.67.220.220 in your forwarders list. Most
operating systems will route DNS traffic in a round robin fashion to the IPs in the list. If you
had Google DNS in the list (8.8.8.8), some DNS requests may go to Google and others to
Umbrella resulting in an inconsistent experience. It is also a good idea when working with
customers to write down the existing IPs in case they need to switch back if needed.
OpenDNS SEVT Guide
61
Click [​OK​].
Click [​OK​]​.
8. In case the old IP is cached, you may need to ​Clear Cache a
​ nd go to A
​ ll Tasks >
Restart
6.
7.
4.2 - Test with debug query
Let’s verify the DC is routing external DNS traffic to Umbrella for resolution. Open an elevated
admin command prompt and run:
nslookup -type=txt debug.opendns.com
OpenDNS SEVT Guide
62
Here’s is output that indicates Umbrella is properly configured,
$ nslookup -type=txt debug.opendns.com
Server:
192.168.1.1
Address:
192.168.1.1#53
Non-authoritative answer:
debug.opendns.com
debug.opendns.com
debug.opendns.com
debug.opendns.com
debug.opendns.com
debug.opendns.com
debug.opendns.com
text = "server 3.pao"
​(Umbrella resolver this DNS request was routed to)
text = "flags 20 0 4040 1BFF000000000000000"
text = "originid 39163035"
text = "orgid 95886"
text = "actype 0"
text = "bundle 14918"
text = "source 67.169.6.116:5524"
​(source external IP of the DNS request)
Note: ​If you get a result saying debug.opendns.com can’t be found, Go back to section 4.1
step 7 and clear cache and do a restart of the DNS settings (see the screenshot in that
section).
This is a good troubleshooting test to run with customers to reveal if something is misconfigured
downstream, such as a proxy or firewall. It can verify the following,
1. Confirm external DNS is being routed to Umbrella.
2. Verify the source external IP of where DNS traffic is coming from. Customers sometimes
enter the wrong egress IP for their locations. Or they have more egress IPs that they weren’t
aware of.
4.2 - Generate DNS queries
Now comes the fun part! Using the ​browser on the Domain Controller​ ​VM​ (not the browser in
the Client VM) you’re logged into, browse the Internet. We want traffic to come from the network
you registered and not the ERC, so this is why you are browsing in the DC VM. Again, visit a
few standard websites that have a lot of CDN-generated content (cnn.com is a good example).
Next, please visit the sites below to generate data for the reports in lab exercise two:
internetbadguys.com​, ​salesforce.com​, and d
​ ropbox.com​. Feel free to visit a few more of your
own choosing both good and malicious sites.
Informational: ​Remember that it is not just web requests that Umbrella can block. Malware
sends command & control callbacks over any port or protocol; many times not using Web.
Next, to generate an event to use for the Security Insights report, enter an nslookup command
for the following domains: nslookup madarco.com.br and nslookup sso.anbtr.com
OpenDNS SEVT Guide
63
Both of these nslookups should return the IP of the Umbrella block page: 146.112.61.107
Note:​ The test websites will only block content if you’ve added that category setting or
security setting to the policy tied to this identity.
Note: ​Umbrella block page IPs may change from time to time. So if you get an IP back that
doesn’t match what is listed above you can copy and paste that IP into a browser to verify
you hit the Umbrella block page.
Once you’ve done that, jump to the Umbrella Dashboard and expand ​Reporting a
​ nd select
Activity Search.
NOTE: ​Since​ ​traffic from newly added Identities (e.g. networks, roaming clients, etc) may
take ​90-120 minutes​ to initially show up in reports, you will not have any traffic in the
Umbrella Dashboard yet.
ACTION:​ For the rest of this section, please click on the drop down menu (pictured below)
and switch to the ​Umbrella Reporting Demo​ which is already populated with reporting data.
All reporiting
The activity search will show most of the DNS requests from your identities (some results, such
as reverse DNS lookups (e.g. *.in-addr.arpa) and content delivery networks (e.g.
*.akamaiedge.net), are filtered out as they add a lot of ‘noise’ to the report). At this point there
should be some results from the network identity you configured earlier.
Step 5 - Generate Activity from Internal Network Identities
Let’s point DNS​ originating from the Windows Client VM through our VAs so that DNS queries
will be associated with the internal network identity you defined in the first step of this lab.
Informational:​ If a roaming client is installed on a computer which is forwarding its DNS queries
through a VA, the Roaming Computer identity is overridden by the identities embedded into the
EDNS queries by the VA. A similar behavior can be accomplished for networks without VAs by
setting the ​[disable roaming clients when behind protected networks] o
​ ption on the
[identities > roaming computers] ​page to​ [yes]​.
After this change, DNS requests are associated with multiple identities (AD User, external
network, and internal network).
OpenDNS SEVT Guide
64
Click on and drag the ​Internal Network Policy​ to the very top of the policy list to ensure that
the internal network identity will be matched first.
5.1 - Update DHCP options to point DNS to the VAs
In the vast majority of customer cases, DNS settings are given to the devices via DHCP. That’s
also the case in our lab, so we’ll want to update the DHCP settings given to the devices to point
their DNS to the Virtual Appliance.
To change the DHCP scope’s DNS addresses, l​ og on to the Domain Controller VM​, an​d​ ​open
the DHCP Microsoft Management Console (MMC) snap-in.go to S
​ tart > type in “DHCP” in the
search > click on the DHCP program
OpenDNS SEVT Guide
65
Go to ​odns-dc.odnslab.local > IPv4 > Server Options > double​-​ click on DNS Servers
Replace the 192.168.10.2 with the 2 IPs of the Virtual Appliances.​ ​On the ​Action​ menu, click
[​Properties]​, then modify scope properties as needed. The DNS servers should be the 2 IP
addresses of the Virtual Appliances you set earlier (​192.168.10.3 and 192.168.10.4). Should
look like this:
Click [​Apply​].
Once the change has been confirmed, you need to grab the new settings from the DHCP
server. In the ​Windows Client VM​, open a command prompt and run,
ipconfig /renew
Confirm the VA’s IP are the workstation's’ DNS server settings. Verify this by running,
ipconfig /all
and checking that the ​DNS servers​ are listing the 2 VA IPs (192.168.10.3 and 192.168.10.4).
OpenDNS SEVT Guide
66
NOTE:
● If the DNS servers are still set to 127.0.0.1, go into network settings to verify that the
DNS isn’t statically set to 127.0.0.1. If it is, set it to Obtain DNS server address
automatically,
●
Roaming clients will disable when a VA is detected on the same network. Once DNS
is directed to the VAs, traffic coming from the client with the RC installed will be
identified by the network or internal network identity and not the hostname of the
device.
5.2 - Test with debug query
As in the previous steps run the following in the elevated command prompt:
nslookup -type=txt debug.opendns.com
The line below should match the local non-routable IP of the workstation.
debug.opendns.com text = "remoteip 192.168.0.x"
OpenDNS SEVT Guide
67
Non-authoritative answer:
debug.opendns.com text = "server 100.sjc" (​Which Umbrella resolver answered the query​)
debug.opendns.com text = "organization id 2" (​*VA only - which organization the VA belongs to​)
debug.opendns.com text = "appliance id 8006701" (*​VA Only - VA ID Number)
debug.opendns.com text = "host id 662c7c872597a04b2576b6da0c831cb3" (​*VA Only - AD User hash​)
debug.opendns.com text = "user id 842f9753d0d5e60a842ca2baa063bafd" (​*VA Only - AD Computer hash​)
debug.opendns.com text = "remoteip 10.0.0.34" (​*VA Only - Internal IP address of the DNS request. This
should *not* be one of their local DNS servers​)
debug.opendns.com text = "flags 34 0 57E4 2091DFD000000000000000"
debug.opendns.com text = "originid 12102805" (​Origin ID of the non-AD identity applied, can be Roaming
Client or network. If 0, this network is not registered to any Umbrella accounts​)
debug.opendns.com text = "orgid 2" (​organization ID where the above origin id belongs, if any. The Org ID
should match the Dashboard URL’s Org ID for this identity​)
debug.opendns.com text = "actype 0" (​account type​. Umbrella Dashboard (dash2 Bundle): 0, Dashboard
Origin (dash1): 1, Dashboard Policy:2​)
debug.opendns.com text = "bundle 42366" (​Bundle ID belonging to the policy applied (Umbrella Dashboard
only​)
debug.opendns.com text = "source 12.34.56.78:56469" (​Public IP of the network's egress point seen by
Umbrella. This is the DNS egress IP of the DNS server used and may differ from the device’s IP. Use this
to confirm the IP address our resolvers are seeing the user request from.​)
debug.opendns.com text = "device 01011710DCDB09FE" (​*roaming client or Network Devices Only - Device
ID of the roaming client, NETGEAR, Cradlepoint, or other device-based integrations.)
debug.opendns.com text = "dnscrypt enabled (71447764594D3377)" (​roaming client or DNSCrypt only Indicates that DNSCrypt is active on this device.​)
debug.opendns.com text = "name opendnscache" (​This and the entries below are the opendnscache
versions on the server that responded.​)
debug.opendns.com text = "version 1.143-425"
debug.opendns.com text = "commit a916f244f613028d6671c65364c77965c2a5cc13"
debug.opendns.com text = "bits 64"
debug.opendns.com text = "release type release"
debug.opendns.com text = "deploy type production"
debug.opendns.com text = "compile time Jun 1 2015 20:17:38"
OpenDNS SEVT Guide
68
5.3 - Generate DNS queries
In this test, we’ll test going to a couple of popular cloud services so that the identities are
reflected in the logs in a later lab.
In your browser, or with an nslookup, go to a popular web-based SaaS sites, such as
www.facebook.com​, ​www.salesforce.com​, or ​www.webex.com​.
If you pick different SaaS/cloud services than these, that’s totally fine but make a note of them
for later.
Step 6 - Generate Activity from Active Directory Identities
6.1 -​ Adjust Policy Execution Order.
Click on and drag the AD Policy to the very top of the policy list to ensure that the AD
user/group/computer identity will be matched first.
6.2 - Logoff the user and logon the user
On your Windows Client VM, logoff the user from the Windows session, then log back in again.
This will generate a logon event in the event viewer on the Domain Controller, subsequently, the
Umbrella’s connector service will associate events from the Windows Client VM with that AD
user.
6.3 - Test with debug query
On the Windows Client VM, as in the previous steps, run
nslookup -type=txt debug.opendns.com
Check for the following lines in the output:
debug.opendns.com text = "host id [string]"
debug.opendns.com text = "user id [string]”
OpenDNS SEVT Guide
69
The string displayed is the AD GUID of the object in question. These lines indicate that your
user and machine is being mapped to your IP address.
6.4 - Generate DNS queries
At this point, go ahead and generate a few DNS queries from your Windows Client VM. In this
situation, try a couple of requests to test domains directly from the browser, they should be
blocked: ​http://internetbadguys.com
Make note of the domains tested in this step, as you should be able to see them associated with
your AD user in the next lab.
OpenDNS SEVT Guide
70
Lab Exercise 2: Reporting
Exercise Description and Objectives
Now we will go over the reporting functionality of the Umbrella Dashboard. Your goal in this
exercise is to prove the value of Umbrella by examining the malicious activity blocked and by
exploring the threat intelligence associated with that activity.
NOTE: ​Since​ ​traffic from newly added Identities (e.g. networks, roaming clients, etc) may
take ​90-120 minutes​ to initially show up in reports, you will not have any traffic in the
Umbrella Dashboard yet.
ACTION:​ For the rest of this section, please click on the drop down menu (pictured below)
and switch to the ​Umbrella Reporting Demo​ which is already populated with reporting data.
Step 1 - View Basic Reports
The screenshots below are from the Umbrella Demo environment, which contains more data
than the current lab environment. You can look through these reports in your lab instance of the
Umbrella Dashboard as well.
1.1 - Security Overview Report
The Security Overview is the first report you see when expanding ​Reporting ​in the Umbrella
Dashboard.
OpenDNS SEVT Guide
71
The Security Overview shows three main areas designed to give enterprise admins a quick view
of their environment:
Security Categories:​ ​The Security Categories portion of the report covers the majority security
category results grouped together: Prevent (malware & drive-by downloads), Contain (botnet
command and control requests) and Phishing.
Top Security Events:​ Top Security Events are divided into two areas, Top Events by Domain,
and Top Events by Identity. The number of identities requesting the Top Event Domains is also
noted.
Deployment Summary: ​This section of the report has two types of Identities-- Sites &
Networks and roaming clients are broken down to show how many of these Identities are
currently online and active. The "active" references those Identities with a green status in their
respective reports.
OpenDNS SEVT Guide
72
1.2 - View Activity Volume report
To view the Activity Volume report expand R
​ eporting i​ n the Umbrella dashboard under
Reports ​select ​Activity Volume ​in the left sidebar.
The Activity Volume summary table shows all DNS query activity, broken down by why each
query was blocked or allowed. You can drill down into the various categories of queries blocked
for security reasons by clicking the ​[+] ​icon next to each category.
Informational: ​A brief description of the various security groupings above.
OpenDNS SEVT Guide
73
● Prevent: ​Umbrella stopped users from accessing malicious websites and content. Includes
malware, drive-by downloads, and mobile threats.
● Contain: ​Umbrella intercepted requests from malware to command & control servers and
stopped users from accessing phishing sites they were tricked into visiting. Includes C2
callbacks to botnets and phishing attacks.
● Advanced Threats:​ Umbrella prevented users from visiting sites where our security
algorithms predicted malicious activity. Includes high-risk sites predicted to contain threats.
● Integrations: ​Umbrella blocked a DNS query based on intelligence from a security partner
that has been integrated with Umbrella in the customer’s environment (FireEye, Check
Point, etc.)
You can also view the Activity Volume report by categories over time by clicking ​[Trend Over
Time].
OpenDNS SEVT Guide
74
1.3 - View Security Activity
Next, expand ​Reporting ​and select S
​ ecurity Activity ​in the left sidebar menu. This report
shows recent DNS queries blocked for security reasons. You can view security activity filtered
by destination, security category, identity, internal IP, or external IP by clicking the related entry
in the table and selecting “see security activity for…”
You can also view Security Insights and Umbrella Investigate information (dependent on
package) for specific destinations or view total activity and activity volume for specific identities
by clicking on the related entries in this table.
OpenDNS SEVT Guide
75
1.4 - View Activity Search
You can also view all activity for your network using the activity search. Select A
​ ctivity Search
from the left sidebar under Reporting. To drill down and filter the results, click on the table
entries or use the report filters in the next step.
1.5 - Report filters
You can use any of the filters in the left side bar to refine the results of the activity search.
OpenDNS SEVT Guide
76
Typing a fragment of an identity into the identity filter will bring up a list of possible matches.
1.6 - Export, share & bookmark reports
Refer to these buttons at the top of the page:
●
The share symbol allows you to share the report and its current filters with
another admin in your organization.
●
The bookmark adds the report and its current filters as an entry under ​[My
Reports] ​in the left sidebar.
●
The download symbol exports the current report and its current filters as a CSV
file which you can access by clicking [​ Exported Reports] i​ n the left sidebar.
Note​: The identity shown in any dashboard report is the identity that first triggered the policy
displayed in that report. However, Umbrella logs all id info. Let’s look at the scenario where a
computer with the roaming client installed comes onto a network protected by Umbrella. Both
the network and roaming client identities would be recorded but which identity shows up in
reports would depend on 2 things,
1.If roaming clients are configured to disable when on an Umbrella Protected Network,
the network identity will always be displayed no matter the policy order.
2. If roaming clients are not configured to disable, then the policy order dictates which
identity shows up. If the roaming client policy is above the network policy you will see
the computer hostname show up as the identity. If the network policy is above the
roaming client policy, you’ll get the network identity.
OpenDNS SEVT Guide
77
1.7 - Schedule reports
Refer to the calendar icon in at the very top of the page to access the reports
[Scheduled Reports]​ (2nd from the bottom) on the left sidebar menu.
or click
If you clicked the icon, you’ll schedule the report you were in when you took that action.
Otherwise, if you selected ​[Scheduled Reports]​ from the sidebar, click the [+] icon to add a
new scheduled report and then there is a list of all reports that are available to be scheduled.
Following the wizard, add filters, recipients, a schedule and description to the scheduled report.
The email you use doesn’t have to be legitimate, as the email will not actually be sent.
Step 2 - View Advanced Reports
2.1 - Cloud Services report (including the Internet of Things)
The Cloud Services report allows you to gain visibility into the cloud services being used across
your organization, identify usage patterns, and uncover shadow IT. Identifying the cloud
services that users within your organization are using as shadow IT services is now becoming a
daily concern for administrators, especially those worried about data loss, information
containment and understanding the needs of the end user.
OpenDNS SEVT Guide
78
The Cloud Services report also includes a section to help observe Internet of Things (IoT) by
logging DNS traffic from Internet-connected devices within your network that are beaconing out
to IoT sites.
A list of classifications for the Cloud Services report can be found on the left hand side of the
user interface, under Filter by Classification:
In step 5.3, we asked you to visit sites for a few cloud services, such as salesforce.com or
webex.com and other.
Now, expand ​Reporting ​and select ​Cloud Services​ in the Umbrella Dashboard. Both
Salesforce and Webex (or whichever cloud service you picked) should appear here as cloud
services among other that have been visited:
OpenDNS SEVT Guide
79
Note:​ You may see other services as well -- the cloud services report covers any
SaaS-based cloud service, even services like Facebook or Gmail.
You can drill down into each cloud service to show a report of the use of individual services by
identities within your organization. Simply click on the name of the cloud service in the report, or
use the "Search for a cloud service" option on the left hand side.
Selecting the service and the clicking through brings you to the details for this service:
Some key points regarding the specifics for the details of each cloud service:
OpenDNS SEVT Guide
80
Cloud Service
Domains
This is the list of URLs that Umbrella has matched against to determine if the
cloud service is in use. Often a cloud service will only have one cloud
service domain. However, if a service has more than one, if a user visits any
one of the cloud service domains listed, it's considered a match. In the
example of Salesforce, they have more of these URLs than fits in the
interface. Clicking the [​ +]​ will expand to show them all
Classifications
The types, or classifications of the service is shown. In this example, there is
only one, but a cloud service can belong to multiple classifications.
2.2 - Security Insights Report
The Security Insights report is a pivot from within the Activity Search or Security Activity report
and applies to domains that have been blocked by Umbrella. You can find it in the Activity
Search by applying a specific filter to show only sites that have been blocked:
In this part of the lab, go to either the Security Activity report or Activity Search report, and from
there, find sso.anbtr[.]com in your Security Activity report, then click on the domain name in the
report, and select [​View Security Insight​].
If the domains aren’t in your report, do an nslookup on them from the Windows Client VM:
nslookup sso.anbtr[.]com
(This part of the report may not look the same for all customers, depending on which features
they’ve purchased.)
OpenDNS SEVT Guide
81
Clicking [​View Security Insight for sso.anbtr[.]com]​ will bring you to a report that looks similar
to the one below. The results vary depending on when the report is run and on which domain.
The Security Insight reports provides​ contextual details to help you answer:
● Is this a targeted attack against my organization, or a common problem?
● Which of my Umbrella identities might be compromised?
● What sort of threat is this and where does it come from?
OpenDNS SEVT Guide
82
The first detail to notice when looking at the Security Insight report is the overlay graph showing
a summary of the queries made by all identities on your network to the domain you've selected.
The timeline can be adjusted from daily to hourly or weekly. The option to select the time range
is in the upper right portion of the chart:
The graph will reflect the 24 hours for Hourly, the last 3 weeks for Daily, or the last 4 weeks for
Weekly.
Adjusting your traffic view shifts the graph to show only the traffic originating from your
organization and any identity associated with your organization or to show the global traffic to
this domain from all of the traffic to Umbrella DNS servers.
Hovering over your traffic shows an alert with interesting stats, including the number of alerts
from your network compared as a percentage to the Umbrella’s global network.
OpenDNS SEVT Guide
83
In the example above, the volume of traffic from your Organization is a tiny percentage of the
global traffic from all Umbrella’s customers.
In the image below, traffic from your Organization is a higher percentage global traffic: 2 of only
a total of 15 requests for that day. This could potentially indicate that this is a 0-day malware
threat, an unusual malicious site or a targeted attack.
Next, make a note of the Security Details section in the lower-left
The Security Details section of the report contains:
●
●
●
Security Category:​ The Umbrella’s security category under which the domain was
categorized. For a list of the security categories, ​click here​.
Hosting Location:​ The country that hosts the domain. We use the standard Internet
Country code abbreviations, eg: US, AU, UK, CA, etc.
IP Address or CNAME:​ The IP address of the domain, or the most recent IP that this
domain resolved to. There may be more than one IP that a domain resolves. The
CNAME is shown when the blocked domain is a CNAME for another domain. Hovering
over the CNAME will display more information where available, as in this example:
OpenDNS SEVT Guide
84
●
●
●
Potential DGA: Whether the domain is a potentially being registered as part of an
automated botnet. A DGA, or ​Domain Generation Algorithm​. This feature detects when a
domain name is being randomly generated by an algorithm as part of a botnet attack. A
randomly generated name is used by hackers in order to stay ahead of static block lists
and this feature prevents that.
Fast-Flux Candidate: Whether the domain is potentially in "​ fast flux".​ Fast flux is a DNS
trick used by criminals to hide phishing and malware delivery sites behind a high number
of IP addresses that are constantly changing. If the IP that the domain resolves to
changes often, this will let you know.
ASN: The ​Autonomous System Number o
​ f the IP routing prefix that hosts this domain.
The “Top Identities by Request” part of the the Security Insight report provides reporting on
which identity or identities have looked up the domain you're looking for insight about. The top 5
identities sorted by number of requests are listed.
The DNS request count can often be a little higher than expected if the identity is behind a VA, a
network or a site because they may all have the same computer or device behind it sending the
requests. If more than 5 identities within your Organization have requested this domain in the
past 30 days, there will be a "View More Identities" link. This goes to a report which will show
the rest of the identities that made a request to this specific domain.
For more information about this domain, we’ll dive into Investigate, where we can access all of
Umbrella’s threat intelligence.
OpenDNS SEVT Guide
85
Lab Exercise 3 - Investigate Console
Exercise Goals and Objectives
In this exercise you will navigate the Investigate web-based console to learn more about specific
malicious domains. By the end of this exercise you should be able to demonstrate the value of
Umbrella’s unique threat intelligence by pivoting through an attackers’ infrastructure.
Note​: In the following examples, we’ll highlight certain domains but because the information
in Investigate is dynamic and updated in real time, the examples may change. If you search
Investigate for one of the referenced domains in this section and don’t get the same result as
the screenshot, stay calm and proceed. The out of date screenshot and explanation should
still give you the main point of the section.
Use Case 1: Get Additional Information About a Domain
In the Security Insight report, we saw how the local traffic to this domain matched up against the
traffic globally from all Umbrella customers, and important Security Details about the domain
visited were also shown. Below the Security Details, there is a button to open Investigate and
research the domain further:
Clicking on this will take you to Investigate, which gives you access to the threat intelligence
powering Umbrella and provides more detailed information about the domain you are
researching.
The intelligence from Investigate provides the most complete view of the relationships and
evolution of Internet domains, IPs, and ASNs, and adds the security context needed to uncover
attackers’ infrastructures and predict future threats.
Investigate leverages a diverse dataset of 80+ billion daily DNS requests and live views ​of the
connections between different networks on the Internet​ from 500 BGP peering partners. We
OpenDNS SEVT Guide
86
apply statistical models and human intelligence to this massive dataset to uncover current and
future malicious places on the Internet.
With Investigate, security teams can speed up investigations, gain the global context needed to
prioritize incident response, and stay ahead of attacks.
Further documentation can be found along the top of the page:
In this section of the lab, we’ll review three typical use cases for Investigate and allow you to
explore the UI.
It’s worth noting that there is also an API for Investigate and this is a method many customers
use to automatically query Investigate and enrich other systems such as a SIEM, threat
intelligence platform, etc. The Documentation covers the API, and details about API Access can
be found under the Settings:
In this lab, we’ve found a domain that is already blocked by Umbrella and the goal here is to
learn more about why this domain was blocked, how long it’s been blocked, and any other
correlating data tying this domain to other threats or other domains.
1.1 - Find out why this domain was flagged as malicious
At the top of the page, Investigate bubbles up key information about the domain security details.
For example, we can see here that the domain is currently on the Umbrella block list. This
means our security labs team determined it is malicious (either based on their intelligence or it
was detected by one of our automated statistical models), and all current Umbrella customers
are being protected from going to the domain. Additionally, we see that IP addresses this
domain resolves to are also being blocked by Umbrella.
OpenDNS SEVT Guide
87
1.2 - Examine various data fields and determine significance
1.2.1 Security Graph Score and any other alerts (i.e. suspicious ASN/IP prefix)
The first thing a lot of people look for is the Security Graph score and the classifier prediction.
Here is data for the domain ​sso.anbtr[.]com​,
The Security Graph Score is a mathematical computation based on the security features and
scores that pertain to a domain (these scores are covered in the Security Features area of the
product).
The Security Graph Score is not considered to be authoritative over a site appearing in the
block list. In other words, it’s possible to have a site with a lower Security Graph Score that’s not
blocked, or a site with a higher Graph Score that is-- in fact, it can be reasonably common and
leads to confusion. An instance of when this could happen is if an otherwise previously
legitimate, good domain is hacked and begins serving malware. Not much about the DNS for
that domain has changed, but it is now being blocked.
OpenDNS SEVT Guide
88
It’s also worth noting that the Security Graph Score is not really the primary selling point of
Investigate-- we don’t intend this score to be anything more than a quick analysis representing
an algorithmic computation that looks at all the other scores and produces a likelihood score of
a site being benign or malicious (-100 suggesting highly likely malicious and +100 suggesting
highly likely benign).
OpenDNS Security Graph Score is a cumulative aggregate of the security details for a domain
and is an important alert to assist you in quickly determining whether a site could require
additional investigation.
Make a note of the security score for the domain you’re researching both now and in the future
when we look at additional domains.
Note: ​Descriptions of all other alerts can be found in the documentation.
1.2.2 DNS Queries graph (are there spikes or regular patterns?)
The DNS Queries graph below, shows the number of requests that we’ve seen globally for this
domain over the last 30 days, and it’s even broken down hourly when you hover over:
Most popular sites have a common traffic flow, peaking during certain times and not others, but
remaining normalized over a period of time:
Sometimes you’ll see something like this, where an emerging phishing campaign suddenly
begins generating traffic when there previously was none. Or you might see a small spike
before a larger spike, which could indicate when the attackers were testing their infrastructure
OpenDNS SEVT Guide
89
before launching the attack:
Note:​ ​When​ investigating a domain that shows a very low volume of traffic over the past few
days, keep in mind that the axis on the left (DNS queries per hour) is adjusted against total
Internet traffic and a very small amount of traffic may indicate that the domain you're
investigating could be part of a targeted attack, or an APT.
1.2.3 WHOIS record data
Next, have a look at the WHOIS record data for the domain. WHOIS record data provides
information about who registered the domain, where it was registered, the registrant contact
information (name, email address, street address, phone/fax number etc.), and more. A recent
registration could indicate the domain was spun up for the purposes of a spearphishing
campaign or a targeted attack.
WHOIS information can be forged or obfuscated fairly easily, especially with dodgy domain
registrars. For example, you might see celebrity names or clearly fake names like “Bad Guy”
used as the contact name. Next to the street address, you have a “View Map” option, which
opens up Google Maps and you can see if it’s a legitimate address. Investigate also provides
historical WHOIS record data to show changes that have been made over time. As a result,
having suspicious looking WHOIS information can be a key indicator that a domain is being
used for potentially malicious purposes.
OpenDNS SEVT Guide
90
Note:​ Often an emerging domain will not have information added to the WHOIS record, so
watch out for that. The Investigate interface may say “Sorry, couldn't load WHOIS
information for this domain.” Data may also not be available if the WHOIS information is
simply set to active with no details available.
You can pivot on multiple data points in the WHOIS record data, including the email address
used to register the domain and the associated nameservers. By clicking and pivoting on these
data points, you can uncover related infrastructure. For example, pivoting on the Associated
Domains for the email address, you can see all other domains registered with that same email
address and even see if any of the domains are malicious.
As an example, ​greystoneexpress[.]com,​ the WHOIS record data shows the same email
address was used to register two domains and both are considered to be malicious:
OpenDNS SEVT Guide
91
Clicking on the email address will ‘pivot’ to the email address view of Investigate to show other
domains registered with it. Investigate shows both domains have been associated with botnet
activity.
Similarly, you can pivot by clicking on the Associated Domains of the nameserver, which will
bring you to a view of any other domains hosted on the same nameserver. In this example,
there’s just one associated domain - the one we’re investigating.
Action: pivot on the email and nameserver values to find additional domains or IP
addresses that are related to the same attacker infrastructure.
Keep an eye on goloduha.info!
https://investigate.opendns.com/domain-view/name/goloduha.info/view
1.2.4 Domain Tagging
Domain tagging shows what category the domain is tagged as by Umbrella in our block list:
Malware, Phishing, Drive-by Download and so on. Additionally, when available, any specific
URLs that contain malicious code will appear, along with the duration of time it’s been listed.
You will also see historical information if it was previously categorized.
OpenDNS SEVT Guide
92
Action: Observe any categorization tags, both current and historical, associated with this
domain in the Domain Tagging section.
1.2.3 Features (Country codes, TTL, Locations count)
There are a number of Security Features to check out. We won’t cover them all today, but you
can review them on your own and refer to the Investigate Documentation for a description of
what information each provides.
First, you’ll see the Time-to-Live (TTL) for the domain. A standard TTL might look like this:
A domain with a low TTL is likely to have an IP change. TTL is normally lowered in advance of a
normal migration of a domain from one IP to another, but it is also lowered when a domain is
being used to mask multiple IP addresses hosting malicious content.
If TTLs are very low, you’ll see this alert:
If you see this alert, the TTLs for this domain will very small, or 0. In addition, the number of
Country codes, which are the country codes for the IP addresses that host this domain, will
often be very high — most domains are rarely more than 2 or 3. A domain like “cnn.com” is only
1 (the US).
Have a look at ​https://investigate.opendns.com/domain-view/name/goloduha.info/view
OpenDNS SEVT Guide
93
1.2.4 Anomaly Detection: DGA/fast flux detection
DGA detection uncovers whether the domain is a potentially being registered as part of an
automated botnet. A DGA, or ​Domain Generation Algorithm,​ is used to randomly generate
domain names as part of a botnet attack.. A randomly generated name is used by hackers in
order to stay ahead of static block lists and this feature prevents that. A yellow alert notes this:
The DGA alert appears when the DGA score i​ s -25 or lower. g
​ reystoneexpress[.]com​ is a
normally spelled domain name and not part of a DGA so it has a very low DGA score. Perplexity
and Entropy are other computations against the structure of the domain name itself that
contribute to the score.
For an example of a domain with a higher DGA score, check s
​ so.anbtr[.]com
https://investigate.opendns.com/domain-view/name/sso.anbtr.com/view
OpenDNS SEVT Guide
94
We also show whether it is potentially a "​ fast flux"​ d​o​m​a​i​n​. Fast flux is a DNS technique used by
attackers to hide phishing and malware delivery sites behind a large number of IP addresses
that are constantly changing. If the IP that the domain resolves to changes often, this is a very
good indication that the domain is fast fluxing.
goloduha[.]info ​is also an example of fast flux:
https://investigate.opendns.com/domain-view/name/goloduha.info/view
This is the alert that would show up at the top of the page if the domain is likely fast fluxing.
Next, we’ll look at the IP addresses section to show how we can tell it’s a fast flux.
Action: Have a look at the DGA Detection section, as well as the IP addresses section to
see why this domain is a possible candidate for either of these security alerts.
1.2.5 IP Addresses and Nameservers
The last feature we’ll look at in this lab is the list of IP addresses that the domain resolves to, as
well the IP of the nameservers for this domain. Note that the data for nameservers is from a
different source than the WHOIS information for that same domain; these are the nameservers
that Umbrella DNS resolvers see as being authoritative for the domain rather what’s listed in the
static WHOIS record.
Let’s go to​ goloduha[.]info ​again:
https://investigate.opendns.com/domain-view/name/goloduha.info/view
We see some very interesting patterns for both IP Addresses and Name Servers. First, under
the Features section, Investigate shows that this domain resolves to a total of 1567 IP
addresses (“RIPs” shows the number of server IP addresses).
OpenDNS SEVT Guide
95
Second, the IP addresses that this domain resolves to change every day. By definition, this is a
fast flux domain:
And the day before:
For the pattern of Autonomous Systems, we see 299 different ASNs associated with this
domain, which makes sense for a domain resolving to so many different IPs.
OpenDNS SEVT Guide
96
The name servers associated with this domain are also changing. Although the WHOIS record
data showed only a handful of name servers, the Umbrella data shows that the name server IP
changes every day as well:
Both the IP address and Name Servers are pivots you can click on to find out more about how
the infrastructure that hosts this domain is constructed and what other hosting infrastructure it’s
related to.
Conclusion:​ In this first use case, we started in the Umbrella Security Insight Report and
wanted to drill deeper into the details of a particular domain to understand why it was blocked.
We pivoted to Investigate where we found it was deemed malicious by the Umbrella’s security
labs team. Looking further, we found the domain a number of reasons why:
● Had irregular traffic to the domain based on the DNS Queries graph
● It was registered with the same email used to register another malicious domain
● It was categorized as a botnet in the Domain Tagging section
● It was fast fluxing
● And more...
Use Case 2: Incident Investigation
OpenDNS SEVT Guide
97
In this case, we’re going to look at a domain that you previously knew nothing about. This is
different than the previous scenario, where you’d seen a malicious site being blocked and
pivoted from Umbrella to Investigate.
Here’s the scenario: The security operations team received a SIEM alert showing several
endpoints across the environment were repeatedly connecting to a suspicious domain (or IP).
Previously, no traffic to that domain had been observed, and the goal is to learn more about this
domain or IP and determine whether it’s malicious or benign.
There are several different types of elements that you can query in Investigate:
● Domain or subdomain​ entries should be specified without the protocol or URL information,
but can include subdomains. For instance, both w
​ ww.example.com and ​example.com are
valid and may return different results depending on the zone record configuration of the
domain.
● IP address​ entries must be a full IPv4 IP address, eg: ​19.117.63.126
Only enter a single IP address. Currently we do not support searches for an IP range or a
partial IP address.
● Autonomous System Number (ASN)​ entries should simply be the AS Number, eg: 3​ 6692
● Email address​ should be the traditional name@domain.com format. Wildcards are not
currently permitted. Email is meant to search for the domain registrar.
2.1- Use key information to determine if the domain is malicious
Step 2.1.1 Review the alerts
Review the alerts at the top of the page and determine if this domain is benign (or “good”) and
can be ignored, or if you need to dig in a little further.
uoeeukyackaagagg[.]org ​shows a suspicious RIP score, or IP reputation score. This alerts
shows the IP address that this domain resolves to known to be suspicious.
Action: Review information bubbles associated with these domains, then check for the
relevant associated data in the Security Details section to find out more.
OpenDNS SEVT Guide
98
Step 2.1.2 DNS Queries Graph (are there spikes or regular patterns?)
Next, check out the domain tagging section and traffic patterns in the DNS Queries Graph. In
the case of ​j8le7s5q745e[.]org​, we identified it as being malicious and put on our block list on
Aug 29,
There was a sudden large increase in traffic on 9/15/16 after very little traffic for a long period of
time, which is unusual for legitimate domains:
OpenDNS SEVT Guide
99
This is a good example of how we can stop threats before they are launched. We see a huge
uptick in traffic right around 9/15 which is 1
​ 7 days after​ 8/29 when w
​ e first identified the
domain as being malicious.
2.1.3 WHOIS record data
Looking at the WHOIS record data for ​nailsartsdesfuture[.]com​, we see the email address
used to register this domain was also used to registered 481 other malicious domains. Clicking
on the email will show a list of all the domains registered with this email:
It’s worth noting that in some cases, such as the one below, not all the domains have been
tagged with a Security Category. This could happen for a few reasons:
● the domain may be registered with this email address, but it has no actual host or IP and
therefore no valid traffic that Umbrella would resolve.
● Alternately, it may not be categorized as malware or botnet because there’s not currently
any activity of that type associated with the domain, but it’s something to be wary of in
the future.
OpenDNS SEVT Guide
100
Action: pivot on the email address to see what other malicious activity is associated and
find additional domains that are related to the same attacker infrastructure. The fact that
this email address registered other malicious domains increases the likelihood that this
domain is malicious.
2.1.4 Pivot on IP and ASN
Let’s look at ​samyhookf[.]top​, scroll down to the IP section:
Action: pivot on the IP address to see what other malicious or suspicious domains
reside in this IP space.
Click on 192.3.150.196 to get to the IP Address view. Investigate shows this IP is currently
hosting 30 malicious domains, and even lists all known and malicious domains hosted by the IP.
You can also see the Prefix and autonomous system information (i.e. ASN and Network
owner). Since this IP is hosting a lot of malicious domains, that’s why we saw the alert earlier
about a suspicious RIP (IP reputation) score. Domains hosted by IPs with a lot of malicious
activity are more likely to be malicious.
OpenDNS SEVT Guide
101
Action: from the IP view, pivot again on the ASN:
Here we can see all of the IP prefixes connected to this autonomous system, as well as all of
the malicious domains currently being hosted. You can see the IP prefix of our original domain
(​samyhookf[.]top)​ is hosting a lot of malicious domains.
2.2- Pivot on co-occurrence
Now let’s go back to the original domain view of u
​ oeeukyackaagagg[.]org
Co-occurrences and Related Domains in Investigate are found at the bottom of the page:
OpenDNS SEVT Guide
102
Co-occurrences
Co-occurrences are a way to track other domain names that were looked up around the same
time as the domain that we’re researching. When two domain names are visited within rapid
succession with each other they are said to co-occur. Each domain has a co-occurrence score
indicating the frequency at which the two domains co-occur, with 100 being a 1-to-1
co-occurrence. A co-occurrence is a way of representing relationships and interconnections
between one or more domains looked up in rapid succession (i.e. seconds) by the same device.
But only if a statistically high number of devices worldwide demonstrate the same pattern.
The co-occurrence score is listed next to the domain that co-occurs with the one you’re looking
into with Investigate:
A visual representation of co-occurrences:
Often an infected host will look up a malicious site, and then shortly afterward visit a second or
third malicious site. Infected hosts searching for their command and control can behave in this
OpenDNS SEVT Guide
103
manner. Alternately, a website may redirect to infected content on another site and this would
show a co-occurrence between hosts visiting the first site and then the redirected site in quick
succession. Co-occurrence shows that relationship.
In the case of ​uoeeukyackaagagg[.]org, i​ t has a one-to-one relationship a domain that it
co-occurs with and it is likely tied to the same attack. Every time a request is make for one, it’s
make for the other. You can pivot on the​ aaaai[.]org ​domain for further research.
Being a co-occurrence isn't necessarily a bad thing. Legitimate sites co-occur with each other as
a part of normal web activity. Many popular sites co-occur with each other as designed. But
when you’re looking at malicious domains, co-occurrences will often surface other domains that
may be part of the command and control, another piece of the infection, or an updating
component of the malware.
Why would a malicious site co-occur with a known good site? L
​ et’s say you have a (normally
non-malicious) ad network, and this co-occurrence related to malvertising: Someone is buying
ad space from the AppNexus ad network which is serving malware that uses this site as a C&C
or dropper for a drive-by download of malware.
Action: At the bottom of the domain(s) you’re digging into further, use a highly-scored
co-occurrence to ‘pivot’ and find additional domains that may be related to the same
attack.
Related Domains
The Related Domains security feature is similar to co-occurrences. This part of the interface
returns a list of domain names that have been frequently requested around the same time (up to
60 seconds before or after) as the given domain name, but that are not frequently associated
with other domain names.
The score next to the domain name reflects the number of client IPs looking up related sites
within 60 seconds of the original request to the domain being searched.
Action: At the bottom of the domain(s) you’re digging into further, use a highly-scored
related domain to ‘pivot’ and find additional domains that may be of interest.
OpenDNS SEVT Guide
104
Conclusion:​ In this second use case, we started off querying a domain from a SIEM alert.
We wanted to figure out if it was malicious and what Investigate knew about it. We used
Investigate to determine it was malicious, and here’s what we found:
● It had a suspicious IP reputation score because the IP hosted a lot of other
malicious domains
● Had irregular traffic to the domain based on the DNS Queries graph
● Was registered with the same email used to register almost 500 other
malicious domains
● Pivoting from the domain to IP to ASN we confirmed it was hosted by a
network with a lot of other malicious activity
● Co-occurrences showed another domain that was likely tied to the same
attack. More research could be done looking into that domain to confirm how
it was related.
Use Case 3: Pattern Search & Proactive Research
Use Case: Pattern Search
A new feature in Investigate is the Pattern Search. ​Pattern Search gives you the ability to query
Investigate for domains matching different patterns and terms, including brand names. Instead
of only being able to search for exact matches to domain names, Pattern Search allows for
more flexible, extensive searches. One use case of Pattern Search is to uncover new domains
that are impersonating a company’s brand name—which could be used to mask malicious sites
intended for phishing campaigns against your prospect’s employees. The Pattern Search uses
traditional regular expressions (RegEx) to do the matching.
Let’s take Netflix as an example. Using regex, you can search for all newly queried domains that
contain the term “netflix” by typing the regular expression “​netflix.*” into the Pattern Search tab
across the top of the Search:
OpenDNS SEVT Guide
105
You can expand the time range of the search, but most relevant results are within a recent time
frame. You should a number of domains with “netflix” in them, most of which are not legitimate:
Action: try interesting RegEx patterns that might match to one of your prospects’
intellectual property, an existing customer, or even something in your personal life! For
help with regex, read here: http://regexr.com/
Use Case: Proactive Research
In this scenario, let’s say you’re trying to proactively uncover potential threats and you start with
a single domain that you found through your threat intel sharing group. Now you’ll use
Investigate to uncover the attacker’s infrastructure.
We’ll start with the domain “anbtr.com”, which hosts browser hijack malware and is often
something that a phishing attack or a compromised URL will forward to.
Enter the ​sso.anbtr[.]com ​domain into Investigate (without the square brackets around the
period.)
OpenDNS SEVT Guide
106
3.2 - Show that this is a known-bad domain
First, notice the red alerts indicating that this domain is in the block list, and the other security
features. Notice the DNS traffic-- a fair amount and a regular pattern:
Action: observe any unusual traffic patterns, zooming in to note the specifics around
dates.
Step 3.2 - Pivot on co-occurrences and related domains
Next, have a look at the co-occurrences. In the example of ​sso.anbtr[.]com ​the co-occurrence
is with other malicious hosts. Knowing about these additional domains helps you stay ahead of
the threat:
Some co-occurrences are legitimate domains that co-occur with suspicious or malicious
domains, other co-occurrences are part of an attacker’s server infrastructure and are related.
Action: Open each of the co-occurrences and related domains in a separate browser tab
or window and see what common features they share with the first domain, such as an IP
or an ASN. Note if they’re blocked already by Umbrella or have anything unusual about
the traffic patterns.
Step 3.2.1- Notice what infrastructure is shared by these domains
OpenDNS SEVT Guide
107
Next take a look at the IP address data for s
​ so.anbtr[.]com​ ,
Action: Click through on the first IP - 195.22.28.222
https://investigate.opendns.com/ip-view/195.22.28.222
In the IP view, you can not only uncover current malicious sites, but also find other domains
hosted on the same IP that may not be malicious now, but are associated with suspicious
activity and could be used in a future attack. These are domains you may want to proactively
block.
Action: Try clicking through on one of the *.anbtr.com domains to see how this IP/AS
infrastructure is being used to launch other browser hijack attacks.
https://investigate.opendns.com/domain-view/name/ss0.anbtr.com/view
3.3- Pivot on ASN
Action: Using what you’ve learned in the previous steps, pivot on the IP’s ASN for
sso.anbtr[.]com and continue to find additional threats that share the same
infrastructure:
OpenDNS SEVT Guide
108
3.4 - Go back to original domain and pivot on WHOIS
Action: Lastly, return to gsso.anbtr[.]com and using the email address in the WHOIS
record data, pivot against this to find additional malicious domains. Dig into the IP, ASN
and domains to learn more about their infrastructure:
https://investigate.opendns.com/associated-domains-view/emails/jgou.veia@gmail.com
Conclusion:​ In this third use case, we started off w
​ ith a single domain that you found
through your threat intel sharing group. Using Investigate, you were able to proactively
uncover other potentially malicious threats​ by:
● Identifying co-occurrences and related domains
OpenDNS SEVT Guide
109
●
●
Finding other domains hosted on the same IP and ASN that should be
monitored/proactively blocked
Uncovering other domains registered with the same email address and are
likely tied to the same attacker
If there’s time remaining in your lab session, feel free to continue to dig to find more resources
by pivoting through the database, or use online tools such as
http://www.malwaredomainlist.com/​ to find new domains to enter and investigate on your own.
Here’s a list of more ​recent domains to investigate​.
3.4 - Complete your view of an attack with AMP ThreatGrid
Umbrella’s technology brings unmatched view of attacker’s infrastructure as we discussed in the
last several exercises. The next logical step is complete this view with deep analysis focused on
the payload itself to understand the mission of the attack better. Umbrella Investigate integrates
with AMP ThreatGrid to provide world class static and dynamic file analysis. The partnership
between this two powerful technologies provide the most complete view of an attack in a single
pane of glass. Before you explore the integration watch the f​ ollowing video​.
Again, we will analyze the domain sso.anbtr[.]com for which you have already collected some
intel but this time we focus on information provided by AMP ThreatGrid around samples
connecting to this domain. Type the sso.anbtr[.]com into the search field and scroll down to the
AMP ThreatGrid section.
OpenDNS SEVT Guide
110
The AMP Threat Grid (AMP TG) provides a list of files that during a sandboxing process
connected to sso.anbtr[.]com. To keep track of the files the systems calculates a unique
identifier SHA256 for each file it runs. Notice, that for some of the files there is an AV result
provided, AMP TG has several AV engines build in, clearly pointing out that the files are known
to be malicious and signatures exist. The sandboxing system executes the file on one or
multiple OS systems and collects everything that happens from registry modification to network
communication. The collected data are then run through behavior indicators models that assign
a score to the behavior (you will see few examples later on) from 0 to 100. AMP TG currently
runs more than 700+ behavior models. The score from the different models is combined and
assigned to the file (artifact). Later, we will look more closely on few individual samples. Right
now, notice that all the related samples to sso.anbtr[.]com have the highest threat score.
Select a sample classified by AV as Win.Trojan.Agent, Win.Virus.Sality and click on the SHA256
hash. This takes you into a detail view of this particular malware sample. The header lists the
basic information about the sample: SHA256 (and 2 other hash markers), size of the file, AV
results, and when the file has been seen for the first time.
Note​: What Umbrella
Investigate provides is detail view for each sample. However, this is a small portion of what AMP
Threat Grid solution can offer. In order to get full access to AMP ThreatGrid including API
access customers need to purchase a separate AMP TG licenses.
OpenDNS SEVT Guide
111
Scroll down to the BEHAVIORAL INDICATORS section. Each behavior indicator is assigned a
severity - this reflects Cisco security expertise and assess to what extent the OS behavior
presents a security risk. The severity score is accompanied with Confidence to indicate the
likelihood of the given sample exhibiting the behavior. Click on a behavior indicator to read full
description where you learn why the operation might present a security risk.
Scroll down to the NETWORK CONNECTIONS section. Remember, we get the list of the
samples from AMP TG based on DNS query resolving sso.anbtr[.]com so we should see some
connections in the network connection section to this domain. These are highlighted in the
figure below. Our domain is not the only one used by this malware sample as you see other
connections to a domain amsamex[.]com and several IP address associated with botnets. Given
the information related to ​sso.anbtr[.]com you have collected in previous section you now
have completed the view with list of malware samples classified as Trojans with several high
risk behavior indicators reaching out to this domain.
OpenDNS SEVT Guide
112
To complete the workflow you can explore the the other domain amsamex[.]com with
Investigate and AMP TG again in another iteration to expand your threat view.
OpenDNS SEVT Guide
113