LetsDefend — Chrome Extension Challenge Walkthrough
Investigating a Malicious Chrome Extension with DB Browser for SQLite
Introduction:
Welcome to my weekly walkthrough!
Have you ever wondered how a malicious Google Chrome extension could be abused, creating a privacy risk for a user? Well we’re about to investigate exactly how this can happen by working through the Malicious Chrome Extension challenge over on LetsDefend!
This is an incident response challenge which has us defenders investigating a Windows image to determine how the victim’s data was exposed. We’ll need to review artifacts on the system like the Google Chrome cache to determine what happened. Sounds like another fun investigation to me!
So, whether you’re here to learn more about Chrome cache analysis, check out some new tools, or are just looking for a reference walkthrough for the LetsDefend Malicious Chrome Extension, you’ve stumbled on the right blog.
Put on your detective hat and let’s have some fun with forensics! Thanks for reading along!
Challenge Link: https://app.letsdefend.io/challenge/malicious-chrome-extension
Challenge Scenario:
The victim found out their private info was out there for everyone to see, and things got worse — the bad guys got into their money stuff, social media, and personal emails. We got an image of his machine so you can tell us what happened.
Question 1: What is the ID of the malicious extension?
Let’s start out by getting familiar with our analysis environment and looking in our Tools folder. We’ll find that there is only one tool: DB Browser for SQLite.
Since we are looking for a malicious extension, we’re going to leverage DB Browser to analyze the victim’s local web browser cache and focus on Google Chrome. If you aren’t aware, Chrome stores some website and browsing data in a cache folder on the local device it’s installed on.
I’ll point to an excellent cheat sheet from Foxtron Forensics about the locations and data that are located within the Chrome cache:
With that background, let’s open DB Browser. We’ll want to select Open Database and navigate to the victim’s Google Chrome Cache folder within the challenge file.
/root/Desktop/ChallengeFile/Extension/Users/Administrator/AppData/Local/Google/Chrome/User Data
Once we navigate to the above file path, we need to select “All Files” to see the contents of the folder.
We’ll start with the History database which, according to the Foxtron Forensics article contains:
Website Visits
Chrome Website Visits are stored in the ‘History’ SQLite database, within the ‘visits’ table. Associated URL information is stored within the ‘urls’ table.
Now, if we browse through the URLS table, we will find references to several extensions from the Chrome Web Store.
Most of these extensions appear to be simple utilities, but the two extensions referencing Netflix stick out to me, so let’s focus on the Netflix Party app and the Teleparty Premium extensions.
Let’s do some Google research and see if we can find any information about the possibility of malicious activity from these extensions, shall we? It doesn’t take long to stumble upon the following article from Popular Science about malicious, fake Netflix extensions with a link to the original research by McAfee.
Very interesting! According to the McAfee blog, one of the malicious extension’s ID is:
I think we found a match on the victim’s device!
Question 2: What is the name of the malicious extension?
This one is a bit trickier to find. Remember in Question 1 that we saw the Chrome Web Store name, Netflix Party, in the History database and in the McAfee research? This isn’t the name of the extension that we are looking for in Question 2, though.
So, let’s navigate to the extension’s local directory and see what else we can find.
/root/Desktop/ChallengeFile/Extension/Users/Administrator/AppData/Local/Google/Chrome/User Data/Default/Extensions/mmnbenehknklpbendgmgngeaignppnbe/3.0.0_0/manifest.json
Inside of the extension directory, go ahead and open the manifest.json file in any plain text editor.
But what is the manifest file, anyway? According to Google:
Every extension must have a
manifest.json
file in its root directory that lists important information about the structure and behavior of that extension. This page explains the structure of extension manifests and the features they can include.
Unfortunately, the name in the manifest.json is also not what we are looking for this time. Hmmm, let’s think creatively and see what else we have available.
There is also a _locales folder in the extension’s directory with an “en” directory for English.
/root/Desktop/ChallengeFile/Extension/Users/Administrator/AppData/Local/Google/Chrome/User Data/Default/Extensions/mmnbenehknklpbendgmgngeaignppnbe/3.0.0_0/_locales/en/messages.json
We’ll get some background on what the messages.json is from Google first:
Each internationalized extension has at least one file named
messages.json
that provides locale-specific strings.
In other words, this file is used for translation and localization for different languages including locale-specific strings. Maybe there is a helpful string here for us? Let’s open up the messages.json.
Third time’s the charm! Let’s input extension name (extName) message from this file and see if we found the correct answer…
Question 3: How many people were affected by this extension?
Okay, let’s refer to the McAfee article that we used for Question 1. Fortunately, for us the research has the number of affected users listed in the table.
Question 4: What is the attacker’s domain name?
Now that we have reviewed the manifest and messages, let’s see what else is available in the malicious extension’s directory. We can see some JavaScript files, let’s have a look at some of these and try to understand what they are doing and see if we can locate the attacker’s domain.
Based on the McAfee research we have some idea of where to look. The blog states:
The manifest.json sets the background page as bg.html. This HTML file loads b0.js and this is responsible for sending the URL being visited and injecting code into the eCommerce sites.
B0.js
The b0.js script contains many functions. This blog will focus on the functions which are responsible for sending the visited URLs to the server and processing the response.
Let’s turn our attention to b0.js and look more closely for ourselves.
/root/Desktop/ChallengeFile/Extension/Users/Administrator/AppData/Local/Google/Chrome/User Data/Default/Extensions/mmnbenehknklpbendgmgngeaignppnbe/3.0.0_0/b0.js
Since we are looking for a domain name, we’ll try something simple and just use the find function to search for https:// to see if we can find it that way…
Okay, we’ve found something — a variable, e, defined as: hxxps://a1l4m[.]000webhostapp[.]com (defanged for safety, of course!)
This variable is consistent with the details in the McAfee article. While our victim’s version of the extension has a different URL than the McAfee sample, it is located in the same function within the extension. Good find!
Question 5: What is the full URL the attacker uses to exfiltrate the data?
Now that we found the e variable with the domain name value, let’s see if we can find the full URL. The McAfee blog mentions that a victim’s data is exfiltrated with an HTTP POST method to the domain so let’s search b0.js for POST this time:
Right above the POST value, we can see that the URL that data is sent to is the e variable we found in Question 4 + “/chrome/TrackingData”
Putting this all together, we get:
hxxps://a1l4m[.]000webhostapp[.]com/chrome/TrackingData
Question 6: What is the function name responsible for getting the victim’s location?
To locate the location function, we’ll take the path of least resistance and search for “location” within the code. The first thing we’ll find is the get_location function which can be used to access Geolocation data.
Question 7: What is the variable name that is responsible for storing the zip code of the victim?
Okay we made it to the last question! Just as we did in the previous question, let’s do a simple search within the code; this time we will look for “zip.”
We found some evidence of the variable in the code — that’s a great start but let’s refer to the McAfee write-up one more time:
The country, city, and zip are gathered using ip-api.com.
Now that we have validated the JavaScript code on our victim’s machine and confirmed it with the McAfee research, let’s submit the answer and wrap up this investigation!
Conclusion:
Nice job! We successfully navigated the Malicious Chrome Extension by analyzing the victim’s Chrome cache.
We learned through our research that this malicious extension sends the victim’s browsing data to an external, attacker controlled domain — this creates a huge privacy risk! Having identified the source of the attack, it’s time to bring this investigation to a close.
Thank you to LetsDefend for the opportunity to practice our Chrome cache analysis skills! This challenge was a fantastic opportunity to see a practical example of how a malicious extension can compromise a user’s data and privacy. We also got valuable exposure to some tools like DB Browser to strengthen our knowledge of the Google Chrome local cache!
Thank you so much for reading along and working through this investigation with me. I hope that you had as much fun as I did and learned something new, too!
Until next week — stay curious!
Tools & References:
SQLite Browser: https://sqlitebrowser.org/
Foxtron Forensics Google Chrome History Location: https://www.foxtonforensics.com/browser-history-examiner/chrome-history-location
Popular Science — These 5 popular Chrome extensions are compromising your computer: https://www.popsci.com/technology/chrome-extension-installation-malware-netflix-party/
McAfee — Malicious Cookie Stuffing Chrome Extensions with 1.4 Million Users: https://www.mcafee.com/blogs/other-blogs/mcafee-labs/malicious-cookie-stuffing-chrome-extensions-with-1-4-million-users/
Chrome Developers Manifest File Format: https://developer.chrome.com/docs/extensions/reference/manifest
Chrome Developers Messages.Json: https://developer.chrome.com/docs/extensions/how-to/ui/localization-message-formats