After 6 months of continuous development, I have written less than one hundred lines of code that is building the foundation of the latest version of the chrome-based browser extension ‘Pink Thumb’. There are multiple reasons why only such a small amount of code came out of this extended period of development.

First, like all of us, I am living in quite busy times which allowed me to only proceed from time to time. This by itself was making things even more difficult, since the problems I was facing were quite demanding and that leads us to the second reason: I had a lot to research, test, discard and start from nothing for certain elements over and over. In fact, there were several points in time, where I nearly gave up and thought I would never be able to create the functionality I had in mind. To be honest, this was somehow the toughest private project I encountered so far.

I was also able to shorten the logic over the time of development and we now have a pretty compact source code.

However, when I now read this blog post und look at the functionality the extension is providing, I cannot believe the vast amount of effort it took to create it. All seems so simple now.

The initial idea from 2021 of showing a pink thumb next to the browser’s address bar whenever the user browsed to a website that was considered ‘trusted’, was discussed on Twitter among Jan Bakker and others. Troy Hunt rightly pointed out that with that approach a user must watch out for an indicator (pink thumb) that is either present (yes, you can type your creds now) or absent. Especially, the latter is difficult for some users, I guess – and even more advanced users, like myself, would not always recognize that this indicator is missing.

I thought about this for a while and finally produced the idea of bringing in a ‘positive’ indicator in addition.

What do most phishing pages have in common?

At least a lot of phishing pages contain a password field, because the attacker wants the victim to provide their secrets:

In most cases, such fields are generated through a line of HTML like this:

 <input type="password" id="password" name="password">

What the extension does

So, why not parse websites for lines like this, check if the hostname that belongs to this web page is listed as a trusted site in the Pink Thumb extension’s config file and if not, display a warning? That’s exactly what the latest version of Pink Thumb does:

Again, you see this warning icon next to the address bar only if the website is not listed in the config of the extension:

and if the page contains a password field. If the page does not include any password fields, a grey thumb is displayed:

In the last use case, when you browse to a trusted website with a password field on it, a pink thumb, is shown:

With that, you can still tell your users to trust only the pink thumb:

[Experimental]: Secret MDE Integration

Then I thought, it would be nice to see this information that a user was on a webpage that contains a password field and is not listed in the trusted sites in Microsoft Defender for Endpoint, right?

Since you cannot simply ingest custom content into Microsoft Defender for Endpoint (MDE), this is accomplished by a trick:

Pink Thumb is trying to make a get-request to a URL that you can configure in the config file. The website behind it needs to be accessible on port 80. Pink Thumb then sends a get-request to this URL with a fake URL parameter “?s2MDE=” and is providing the current URL of the browser tab as the value. Confusing?

Let’s take the example of our very first screenshot:

The user browsed to dropbox.com which contains a HTML password field. Dropbox.com is not listed in the trusted sites section of the config file, therefore the red alert icon is shown.

In the config file, if you have turned ON the MDE-functionality and you configure an MDE-signal URL of e.g.: “http://geisbauer.de” like this:

then Pink Thumb would send a get request to geisbauer.de in the following format:

This get-request will then be ‘recorded’ by Defender for Endpoint enrolled systems by default. That is why you could then hunt for occurrences like this in MDE:

You could then take the next step and see what happens afterwards and which URLs are then listed in the DeviceNetworkEvents table to find out if the user typed in the password and was then redirected to another site.

This is an experimental feature of the extension and only available in the Pink Thumb version available to side-load from GitHub and not in the official Google Web Store version (they didn’t like the fact that I am sending “user-data” over http, I told them that the URL can be configured, well, … they still didn’t like it, which is ok and at the end they are right. Please read my general take on this feature below to understand how and if you should use it).

Remarks, Code & Download

Enterprise-Ready?

You might think about using all of this in production. I think as a private user and to test certain scenarios, you could use all the Pink Thumb functionality. I would even go as far as saying, you could use the basic Pink Thumb functionality (without the MDE integration) in some companies to make users more aware.

However, I still think (as mentioned when I released the first version), that all of Pink Thumb’s functionality should be better integrated by a browser vendor in a much prettier way.

The MDE Integration is ‘experimental’ and turned off by default and only available to side-load from GitHub. This is to play around, test and to bring in some inspiration of what could come next 😉

Find the source code of the extension on GitHub: https://github.com/jangeisbauer/PinkThumb2023

To use Pink Thumb in Microsoft Edge, enable other stores in the extension settings, find more info here.

My Intention

I had this idea of warning the user whenever a malicious website is requesting their credential and I wanted step away from a reputation-based approach in which you need to know bad websites to warn the users. The Pink Thumb approach is closer to what we call “behavioral analysis”.

My second idea was to integrate more information from within the “TLS channel” / web content in Defender for Endpoint for further analysis there.

And then I hacked my way through in some dirty ways to bring this functionality to code.

Insights / Future

Most of Pink Thumb’s functionality is triggered through the declarativeContent API of chrome-based browsers:

Pink Thumb is parsing the website source in a quite effective way for password fields (see screenshot above). There are many other possibilities for parsers that can be used. You could even combine filters, search for certain key words or anything else. On the other hand, you don’t need to rely on the config file for the trusted websites, you could also identify them by certificate thumbprints.

If you think the warning icon is too small to get recognized and you would like to display a skull all over a page that is not trusted and is containing a password field or something similar, look at the content-warning.js:

There is an out commented setting to set the background for such pages red. And you can of course do whatever you like here. But please be gentle ;).

Regarding Defender for Endpoint: of course, it would be nice to get increased insights into what is happening within the TLS channel / on the page. To really know if a user typed in the password or not would be an immense improvement. But also, other areas could benefit from such insights: having the deep URLs of file downloads from https sites available in MDE would be super cool.