The Http_lua_options file has many functions that can be enabled and disabled to ensure proper parsing of your traffic. One of the functions that is not listed in the OOTB options file is the browserprint function. This is often deployed during RSA Incident Response engagements to give a bit more detail about the headers in HTTP sessions and their order/occurrence.
To enable browserprint, do the following:
Edit the http_lua_options file (on the decoder):
function browserprint()
--[=[
"Browserprint" : default FALSE
Whether to register a "fingerprint" of the browser based upon the specific headers
seen in the request. The format of this browserprint value is:
Position 1 is HTTP version: 0 = HTTP/1.0, 1 = HTTP/1.1
Remaining positions are in order that the header was seen. Only
the below listed headers are included in the fingerprint:
1 = accept / 2 = accept-encoding
3 = accept-language / 4 = connection
5 = host / 6 = user-agent
Example "15613":
HTTP/1.1
HOST:
USER-AGENT:
ACCEPT:
ACCEPT-LANGUAGE:
(other headers may have appeared between those headers)
The usefulness of this meta is not necessarily in determining "good" or "bad"
browser fingerprints. Rather, it is more useful to look for outliers. For
example if the majority of values are 15613 with just a few being 15361, then
the sessions with 15361 may be worth investigation.
--]=]
return true
end
Next, restart the decoder service.
On your index-concentrator-custom.xml file (on the concentrator), add the following key:
<key description="Browser Print" format="Text" level="IndexValues" name="browserprint" defaultAction="Closed" valueMax="500000" />
Next, restart the concentrator service.
Update the ESA Explore setting below to make sure ESA sets the values as string[] (array) and not string.
Admin > ESA > Explore >
/workflow/source/netGenAggregationSource/ArrayFieldNamesAdd browserprint to the end of the line
Now you have the ability to generate the browserprint numbers as new sessions arrive at the decoder.
Next question... what do those numbers actually mean in the browserprint key?
From the code above this is the explanation:
Registers a "fingerprint" of the browser based upon the specific headers seen in the request. The format of this browserprint value is:
Position 1 is HTTP version: 0 = HTTP/1.0, 1 = HTTP/1.1
Remaining positions are in order that the header was seen. Only the below listed headers are included in the fingerprint:
1 = accept
2 = accept-encoding
3 = accept-language
4 = connection
5 = host
6 = user-agent
Example "15613":
1 - HTTP/1.1
5 - HOST:
6 - USER-AGENT:
1 - ACCEPT:
3 - ACCEPT-LANGUAGE:
(other headers may have appeared between those headers)
The usefulness of this meta is not necessarily in determining "good" or "bad" browser fingerprints. Rather, it is more useful to look for outliers. For example if the majority of values are 15613 with just a few being 15361, then the sessions with 15361 may be worth investigation.
What does this look like with more traffic?
Simply by looking over a large set of data you can start to see that certain patterns are uncommon and unusual.. those could be investigated to see what they were and if they were interesting.
Lets Take this a step farther, can we use this Browserprint data point in combination with other metakeys to find more specific unusual communication patterns? Browserprint allows us to take a look at the 'crowd' of common HTTP headers and orders and determine outliers. What if that was combined with user agent information, destination hosts, outbound traffic direction and the number of source IP addresses?
This could give us a method to see the rare combinations of source IP to destination host, outbound, with the same rare Browserprint number (along with the destination org, and the de-duped list of unique UA that match the HTTP communications).
The Report and Rule syntax
name: "browserprintUA-Rare-Mozilla"
description: ""
path_for_export: "rsa-custom/browserprint/browserprintUA-Rare-Mozilla"
query {
data_source_type: NWDB
netwitness_query {
select: "browserprint,count(browserprint),count(ip.src),distinct(client),distinct(alias.host),distinct(org.dst)"
where: "browserprint exists && client exists && direction=\'outbound\' && client contains \'mozilla\'"
group_by_keys: "AGGREGATE"
order_by_keys {
column_name: "count(browserprint)"
sort_order: ASCENDING
}
order_by_keys {
column_name: "count(ip.src)"
sort_order: ASCENDING
}
limit_results_count: 100
then_clause: "max_threshold(50,count(ip.src))"
agg_session_threshold: 0
group_by: "browserprint"
alias_names: ""
}
data_source_name: ""
}
name: "browserprintUA-Rare-NonMozilla"
description: ""
path_for_export: "rsa-custom/browserprint/browserprintUA-Rare-NonMozilla"
query {
data_source_type: NWDB
netwitness_query {
select: "browserprint,count(browserprint),count(ip.src),distinct(client),distinct(alias.host),distinct(org.dst)"
where: "browserprint exists && client exists && direction=\'outbound\' && not(client contains \'mozilla\')"
group_by_keys: "AGGREGATE"
order_by_keys {
column_name: "count(browserprint)"
sort_order: ASCENDING
}
order_by_keys {
column_name: "count(ip.src)"
sort_order: ASCENDING
}
limit_results_count: 100
then_clause: "max_threshold(50,count(ip.src))"
agg_session_threshold: 0
group_by: "browserprint"
alias_names: ""
}
data_source_name: ""
}
When put in a report and run in a lab environment you get something like this when broken down between mozilla or non-mozilla useragents. Sorted by least occurrance and with a max threshhold of 50 to make sure we focus on the rare Browserprint combinations.
Report and rules are listed here to test and provide feedback.
GitHub - epartington/rsa_nw_re_browserprint-rare: Browserprint http_lua_options for rarity
Happy hunting
