Client Fingerprinting
In this section we will discuss Client Fingerprinting,
also known as Device Fingerprinting,
to obtain operating system and browser information
from a target in a non-routable internal network.
For example, we may be tasked with establishing an initial foothold
on a target’s network for a penetration test.
Let’s assume we previously extracted an email address of a promising target.
As a client-side attack,
we could use an HTML Application attached to an email
to execute code in the context of Internet
and to some extent, Microsoft Edge.
Before we do this, we need to confirm that our target is running Windows
and that either Internet Explorer or Microsoft Edge are enabled.
We’ll use Canarytokens, a free web service that generates a link
with an embedded token that we’ll send to the target.
When the target opens the link in a browser,
we will get information about their browser,
IP address, and operating system.
With this information, we can confirm that the target is running Windows
and verify that we should attempt an HTA client-side attack.
Let’s create our link in Canarytokens
by loading the token generation page in our browser.
The web form provides us with a dropdown menu
to select the kind of tracking token we want to create.
We must enter an email address to get alerts
about the tracking token or provide a webhook URL.
After we enter this information,
we’ll click on Create my Canarytoken.
A new page appears stating that our web token is now active:
This page contains the tracking link we can use to fingerprint targets.
It also provides ideas on how to get a target to click the link.
Next, let’s click on Manage this token.
This will bring us to the token settings.
The token has not been triggered yet,
but this is to be expected since we just created it.
For this example, we’ll keep the default settings,
since we are simply fingerprinting the target
and not embedding the token in a web application or web page.
Next, let’s click on History in the upper right corner.
The History page shows us all visitors that clicked our Canarytoken link
and the information about the victim’s system.
As of now the list is empty.
Let’s assume we have convinced our victim,
in the context of our pretext, to visit the Canarytoken link via email.
As soon as the victim clicks our link, they get a blank page in their browser.
At the same time, a new entry appears in our history list:
A map on the left side shows us the geographical location of the victim.
We can click on the entry to get more information.
The upper-half of the detailed view provides us information
about the victim’s location and attempts to determine the organization name.
The user agent sent by the victim’s browser is also displayed.
From the user agent itself we can infer the target’s operating system and browser.
However, the user agent can be modified
and is not always a reliable source of information.
In this example, the victim’s user agent implies
that they use the Chrome browser on a 64-bit Windows 10 system.
Let’s review the Browser section.
This section shows us additional information about the victim’s browser.
This information does not come from the user agent,
but from JavaScript fingerprinting code embedded in the Canarytoken web page.
This information is more precise
and reliable than the information from the user agent.
This again suggests that the target is running Chrome on Windows.
In this section, we demonstrated an effective fingerprinting technique
that revealed critical information about our target’s system.
This is a crucial first step for a client-side attack.
While our goal was to determine if the target runs Windows
and has Internet Explorer or Microsoft Edge enabled,
we could only identify that the victim runs Chrome on Windows.
In a situation like this,
we should either use a different client-side attack vector
or change our pretext to suggest that the screenshot is only viewable
in Internet Explorer or Microsoft Edge.