Passive Security Tools Fingerprinting Framework
Passive Security Tools Fingerprinting Framework
Have you ever wanted a simple, easy, and stealth bypass for multiple classes of security products? pstf^2 (pronounced pstf-square) is an implementation of an HTTP server capable of passive browser fingerprinting – and it might just be the thing you are looking for. When attackers try to deliver a payload over the internet they need to overcome multiple tools capable of scanning incoming links. Email filters, scanning engines, and even submission to sandbox over URL – all can be bypassed once pstf2 detects them in a passive fashion. Once detected, the tool allows to differentiate between security services and potential victims and deliver either a malicious or benign response.
This tool was released during BlackHat EU 2020.
Details about the research are available in this blog post.
How does it work?
The real question is – how link scanners work? Inspecting a malicious link is an action involving a web client sending an HTTP GET request. Each vendor uses a different in-house implementation – most trying to mimic a real user interaction to some extent. pstf^2 is a simple python-based HTTP server which applies well-known bot detection tactics to determine whether an incoming request is from an automated security tool. The server’s operator can customize responses, e.g. – if a scanner is detected redirect to Google otherwise send malicious content.
Below are the main tactics implemented as part of pstf^2:
Application Layer
Obsolete User Agents
Security tools try to hide as legitimate clients, impersonating real browsers, nevertheless – usually, this is not the case. It is common to see tools which are not maintained properly using fake user-agent headers for browser versions which are a decade old. pstf^2 allows you to set a minimum threshold for what you consider as a real non-obsolete version.
General HTTP Anomalies
There are many types of odd implementations the tool is capable of detecting. A couple of examples which were presented in the BlackHat talk were:
- Leaving a via: header which disclosed the nature of the virtual host used for sandboxing.
- the referer: header which suggested that the link was reached from Google, e.g. referer: google.com/search?q=specific.site.com. in the scenarios we tested, it made no sense since this product scans emails and when someone clicks an email (not from a web interface) this header is absent.
Link, Network and Transportation Layer
Correlation
Multiple TCP parameters can imply either a specific OS version or a specific flavour. Some clients spoof the user-agent header but are running on top of an OS different than the one they declare.
MTU Values
Clients hosted on specific cloud providers networks have MTU different than the standard value of 1500 bytes.
ASN
In some cases, the request is sent from an ASN associated explicitly with a specific security vendor. In others, the request’s origin is a cloud hosting provider, while not incriminating a specific vendor it is unlikely to be a typical user.
DNS PTR Records
In rare cases the client’s IP address has a PTR record, associating it with a URL related to a security vendor.
