Web Browsing to Unauthorized Sites

Description

Detect users who are persistently attempting to violate your proxy policy.


Use Case

Insider Threat

Category

Insider Threat

Security Impact

Users persistently violating acceptable use policies are risky in a number of different ways. In low grade situations, it may make sense to have HR follow up with that user. In high grade situations, it may indicate the need for an explicit intervention as the user may be a flight risk (or harbor malicious intent). In widespread scenarios, it may indicate a workplace problem that needs to be remediated. Regardless, things are blocked in your proxy for good reason -- you should track violations of those rules.

Alert Volume

Medium (?)

SPL Difficulty

Medium

Journey

Stage 1

MITRE ATT&CK Tactics

Exfiltration
Command and Control

MITRE ATT&CK Techniques

Exfiltration Over Alternative Protocol
Standard Application Layer Protocol
Web Service

MITRE Threat Groups

APT12
APT18
APT19
APT28
APT32
APT33
APT37
APT38
APT41
BRONZE BUTLER
Carbanak
Cobalt Group
Dark Caracal
Dragonfly 2.0
FIN4
FIN6
FIN7
FIN8
Gamaredon Group
Honeybee
Ke3chang
Lazarus Group
Leviathan
Machete
Magic Hound
Night Dragon
OilRig
Orangeworm
Patchwork
RTM
Rancor
SilverTerrier
Stealth Falcon
Threat Group-3390
Thrip
Turla
WIRTE

Kill Chain Phases

Actions on Objectives

Data Sources

Web Proxy

   How to Implement

There are two primary triggers for this search -- one is the categories being excluded, and the other is the number of denies that you want to trigger on. There is no standard best practice for either of these, so you can adjust these values to be whatever makes sense for your organization. The most common way we hear of this detection being described is to target suspicious internal users, so most organizations will adjust the filters to look for Acceptable Use Policy violations (e.g., browsing gambling sites) as opposed to denies that are tied to security hygiene (e.g., phishing). That said, you could absolutely implement it in both directions if you so desired. The threshold for triggering would likely be different between those categories though, as a human will likely quit relatively early when they see deny messages versus a script that gets timeouts instead of a big error message.

If this searches creates too many false positives in your environment, it may be because some of your users just generate a very large number of proxy denies on a regular basis. The first bet for dealing with this would be basic tuning of the categories you alert on. If that is not sufficient, you can instead implement this as a per-user time series detection. Look for the # of unauthorized detections per day per user, and then alert when any user exceeds their baseline. You can base this on any of the time series detections in Splunk Security Essentials -- a common and easy one would be to look at Increase in Interactive Logons (just swap out the field names and base dataset and implementation will be easy). There's one important adjustment you would need in order to make that work for you though -- because most users don't see proxy denies often, most of your users will end up with very low averages and low standard deviations. To guard against this, in addition to tracking that the most recent # of denies per day is more than 3 (or 6, or whatever) stdev above the average, you should also make sure that the most recent # is more than 5 (or 10, or whatever). That way you don't accidentally alert on a user that just had one deny (no matter how anomalous a deny is for that user).

   Known False Positives

   How To Respond

When this alert fires, look at the sites where it triggered, and importantly the # of different sites. The primary goal is to determine whether there is a persistent desire to violate policy (or any other malicious intent) or whether someone went to one site where there were 15 different requests in a short period.

   Help

Web Browsing to Unauthorized Sites Help

This example leverages the simple search assistant. Our dataset is an anonymized collection of Palo Alto Networks proxy logs. For this analysis, we are looking for any user who has a high number of denied proxy requests, excluding advertising and phishing categories.

SPL for Web Browsing to Unauthorized Sites

Demo Data

First we bring in our demo dataset of anonymized proxy events.
Next, we filter to look at just blocked connections.
Finally, we filter for users where we've seen printing on multiple days.

Live Data

First we bring in our dataset of proxy events, filtered for just blocked proxy activity where the user is not unknown, and the app is recognized.
Next, we count the number of connections and the categories and apps per user.
Finally, filter for where the count is >= 30, or where there are at least 30 events in the searched for time window.

Accelerated Data

First we bring in our dataset of proxy events, filtered for just blocked proxy activity where the user is not unknown, and the app is recognized, and count the number of connections and the categories and apps per user.
Finally, filter for where the count is >= 30, or where there are at least 30 blocked connections.

Screenshot of Demo Data