This blog will discuss using the HTTP header "Origin" combined with Zeek (Bro) NSM & Elastic ELK for a few different scenarios to detect malicious activity, general suspicious/anomalous activity, or as an added network "forensic" artifact.
You can see the RFC for the Origin header here:
https://tools.ietf.org/html/rfc6454
Browser plugins are a really interesting way to perform malicious actions -- these actions would include key logging of the browser session, web site data, each site visited, screenshot of pages visited, mine crypto-currencies, and plugin's are so powerful that can even fully remote control the device.
These actions regarding data, screenshots, and key loggers are especially useful now a days given that the majority of employees tasks are performed in the browser along with company email, banking, social, etc...
Also, lets say for example you have a user who connects to your VPN network and has a malicious browser plugin that is taking screenshots of every site the user visits. Although the communication of the plugin to its C2 may be blocked while on the VPN -- once the user disconnects from the VPN everything will be uploaded.
Therefore, think if they are performing admin tasks for firewalls/switches/etc in their browser or accessing a web database or some other internal site hosting intellectual property.
Finally, they are a lot less likely to be picked up by more traditional network monitoring techniques that do not involve data collection. Traditional detection measures that may yield no results in detecting plugins:
-Sandboxing == I am not sure of any sandboxes that even run Chrome Plugins (if you know of any then please comment and I will update the blog accordingly)
-IDS signatures / AntiVirus == Not only are static/signature based detection mechanisms a shortcoming as your only means of coverage but Chrome Plugins are a mix of JavaScript/HTML/CSS and these languages can be obfuscated to the moon and back. example:
text > hex > utf16 > base64
TEXT=i am a malicious plugin
HEX=6920616D2061206D616C6963696F757320706C7567696E
UTF-16=%u2069%u6D61%u6120%u6D20%u6C61%u6369%u6F69%u7375%u7020%u756C%u6967%u006E
BASE64=JXUyMDY5JXU2RDYxJXU2MTIwJXU2RDIwJXU2QzYxJXU2MzY5JXU2RjY5JXU3Mzc1JXU3MDIwJXU3NTZDJXU2OTY3JXUwMDZF
You can then perform a google search on the UID (which is "pgeolalilifpodheeocdmbhehgnkkbak") to see what the actual plugin is from the Chrome Web Store. You can also use:
https://chrome.google.com/webstore/detail/$PlaceUIDHere
In my example I had to use the search method because this plugin was something I found back from 2015 and the UID has changed.
The plugin from this PCAP is taking each URL that a user visits and double base64 encoding and then POSTing it.
The first step is to add to the HTTP Origin header to the Bro http.log. This can be accomplished by creating a simple bro script to add the field as seen here:
https://gist.github.com/neu5ron/cbfca0dfc42b1d6c96cd321d687e5495
In order to accomplish this as a whole (ie: restart bro and everything to add the log) you would perform the following:
BRODIR="/opt/bro";
CUSTOMDIR="/opt/bro/custom/additional_http_headers";
mkdir -p $CUSTOMDIR;
# Download the Bro script
wget https://gist.githubusercontent.com/neu5ron/cbfca0dfc42b1d6c96cd321d687e5495/raw/af6f2a36bef23ad77c34f1a4928fb5f36a30fc46/additional_http_headers-main.bro;
mv additional_http_headers-main.bro main.bro;
# Create the additional files needed to make the script a local Bro "package"
echo "@load ./main.bro" > __load__.bro
# Move all files to the $CUSTOMDIR
mv __load__.bro main.bro $CUSTOMDIR;
# Edit the bro directory to include our new script
echo "@load $CUSTOMDIR" >> $BRODIR/share/bro/site/local.bro;
Now assuming you have Bro HTTP logs already going to ELK we can perform some queries and stack counting analysis to find outliers/anomalies of chrome extensions.
Performing a query to find any request made from a plugin is as simple as
origin:chrome
We can then add the query/search from above (after saving it) and the visualization (after saving it) to a dashboard/single-view.
My example is showing a 2 day query and only returned 2 chrome extensions.
However, your environment may have many more. If your environment has many more plugins do not fear because stack counting is here.
However, this example is of a very large network and searching across 432,365,000+ http logs. Even if there were 25+ extensions making outbound connections it would take less than 5 minutes to whitelist any of the legitimate extensions and then you do not have to worry about making your hunt more strenuous then it needs to be...which would result in possibly missing positives/malicious-activity.
After excluding any false positives -- we can create our search into an X-Pack Watcher Alert and then email/notify us any time there is an extension.
Which would mean you don't have to worry about malicious chrome plugin's going unnoticed and can focus on other things :)
\o/
https://tools.ietf.org/html/rfc6454
The HTTP Origin header can be used to aide in detecting
- Google Chrome (Browser) plugins/add-on's.
The purpose of this blog -- which will be discussed in length after describing the other methods. - CSRF.
https://www.owasp.org/index.php/Cross-Site_Request_Forgery_(CSRF)_Prevention_Cheat_Sheet
multiple ways to use ELK and Bro to potentially find some issues as described at that OWASP link using your creativity and the referer, origin, and host HTTP header fields. - Historical artifact of where a connection came from.
This could be used along with the HTTP Referer header. This is described in the qoute ""In some sense, the origin granularity is a historical artifact of how the security model evolved." from https://tools.ietf.org/html/rfc6454#section-7
Also, scenarios where an origin could be a "file://" as described here:
https://tools.ietf.org/html/rfc6454#section-4
The Problem/Threat
Now going back to Chrome (Browser) plugins. For brevity and the fact that Google Chrome is the majority used browser today we will only be focusing on plugins for it.
Browser plugins are a really interesting way to perform malicious actions -- these actions would include key logging of the browser session, web site data, each site visited, screenshot of pages visited, mine crypto-currencies, and plugin's are so powerful that can even fully remote control the device.
These actions regarding data, screenshots, and key loggers are especially useful now a days given that the majority of employees tasks are performed in the browser along with company email, banking, social, etc...
Also, lets say for example you have a user who connects to your VPN network and has a malicious browser plugin that is taking screenshots of every site the user visits. Although the communication of the plugin to its C2 may be blocked while on the VPN -- once the user disconnects from the VPN everything will be uploaded.
Therefore, think if they are performing admin tasks for firewalls/switches/etc in their browser or accessing a web database or some other internal site hosting intellectual property.
Finally, they are a lot less likely to be picked up by more traditional network monitoring techniques that do not involve data collection. Traditional detection measures that may yield no results in detecting plugins:
-Sandboxing == I am not sure of any sandboxes that even run Chrome Plugins (if you know of any then please comment and I will update the blog accordingly)
-IDS signatures / AntiVirus == Not only are static/signature based detection mechanisms a shortcoming as your only means of coverage but Chrome Plugins are a mix of JavaScript/HTML/CSS and these languages can be obfuscated to the moon and back. example:
text > hex > utf16 > base64
TEXT=i am a malicious plugin
HEX=6920616D2061206D616C6963696F757320706C7567696E
UTF-16=%u2069%u6D61%u6120%u6D20%u6C61%u6369%u6F69%u7375%u7020%u756C%u6967%u006E
BASE64=JXUyMDY5JXU2RDYxJXU2MTIwJXU2RDIwJXU2QzYxJXU2MzY5JXU2RjY5JXU3Mzc1JXU3MDIwJXU3NTZDJXU2OTY3JXUwMDZF
How HTTP Origin Looks on the Wire/Network
Although plugins may be difficult to detect from a signature perspective they leave very specific fingerprint on the network when they make a connection. This is specifically in the "Origin" HTTP header. When Google Chrome plugin makes a request the actual chrome extension UID is in the Origin header/field! |
| Origin: chrome-extension://pgeolalilifpodheeocdmbhehgnkkbak |
You can then perform a google search on the UID (which is "pgeolalilifpodheeocdmbhehgnkkbak") to see what the actual plugin is from the Chrome Web Store. You can also use:
https://chrome.google.com/webstore/detail/$PlaceUIDHere
In my example I had to use the search method because this plugin was something I found back from 2015 and the UID has changed.
The plugin from this PCAP is taking each URL that a user visits and double base64 encoding and then POSTing it.
The Solution/Hunt
Bro Setup (Adding HTTP Origin)
If you leverage Bro logs then we can easily perform searching for malicious/suspicious Chrome plugin's.The first step is to add to the HTTP Origin header to the Bro http.log. This can be accomplished by creating a simple bro script to add the field as seen here:
https://gist.github.com/neu5ron/cbfca0dfc42b1d6c96cd321d687e5495
In order to accomplish this as a whole (ie: restart bro and everything to add the log) you would perform the following:
BRODIR="/opt/bro";
CUSTOMDIR="/opt/bro/custom/additional_http_headers";
mkdir -p $CUSTOMDIR;
# Download the Bro script
wget https://gist.githubusercontent.com/neu5ron/cbfca0dfc42b1d6c96cd321d687e5495/raw/af6f2a36bef23ad77c34f1a4928fb5f36a30fc46/additional_http_headers-main.bro;
mv additional_http_headers-main.bro main.bro;
# Create the additional files needed to make the script a local Bro "package"
echo "@load ./main.bro" > __load__.bro
# Move all files to the $CUSTOMDIR
mv __load__.bro main.bro $CUSTOMDIR;
# Edit the bro directory to include our new script
echo "@load $CUSTOMDIR" >> $BRODIR/share/bro/site/local.bro;
Now assuming you have Bro HTTP logs already going to ELK we can perform some queries and stack counting analysis to find outliers/anomalies of chrome extensions.
Exploring the Data in ELK
Performing a query to find any request made from a plugin is as simple as
origin:chrome
Visualizing the Data in ELK
Now performing stack counting to find outliers/anomalies is just as simple as creating a data table visualization on origin.keyword.We can then add the query/search from above (after saving it) and the visualization (after saving it) to a dashboard/single-view.
My example is showing a 2 day query and only returned 2 chrome extensions.
However, your environment may have many more. If your environment has many more plugins do not fear because stack counting is here.
Baselining (Stack Counting) or Whitelisting/Filtering
You can quickly whitelist a plugin's UID (using techniques described above by searching what the plugin actually is via google/chrome-store) so you never have to see the result again. Also, you may perform even more strenuous filtering by adding "method:(POST OR PUT)" to your query.However, this example is of a very large network and searching across 432,365,000+ http logs. Even if there were 25+ extensions making outbound connections it would take less than 5 minutes to whitelist any of the legitimate extensions and then you do not have to worry about making your hunt more strenuous then it needs to be...which would result in possibly missing positives/malicious-activity.
Alerting Instead of Hunting/Exploring
In regards to all of those who don't want to look at a dashboard or search/query..After excluding any false positives -- we can create our search into an X-Pack Watcher Alert and then email/notify us any time there is an extension.
Which would mean you don't have to worry about malicious chrome plugin's going unnoticed and can focus on other things :)
\o/
