Never Trust Your Victim: Weaponizing Vulnerabilities in Security Scanners
University of Genova
IMT School for Advanced Studies Lucca
University of Genova
The ﬁrst step of every attack is reconnaissance, i.e., to ac-
quire information about the target. A common belief is that
there is almost no risk in scanning a target from a remote
location. In this paper we falsify this belief by showing that
scanners are exposed to the same risks as their targets. Our
methodology is based on a novel attacker model where the
scan author becomes the victim of a counter-strike. We devel-
oped a working prototype, called RevOK, and we applied it to
78 scanning systems. Out of them, 36 were found vulnerable
to XSS. Remarkably, RevOK also found a severe vulnerability
in Metasploit Pro, a mainstream penetration testing tool.
Performing a network scan of a target system is a surpris-
ingly frequent operation. There can be several agents behind
a scan, e.g., attackers that gather technical information, pen-
etration testers searching for vulnerabilities, Internet users
checking a suspicious address. Often, when the motivations
of the scan author are unknown, it is perceived by the target
as a hostile operation. However, scanning is so frequent that it
is largely tolerated by the target. Even from the perspective of
the scanning agent, starting a scan seems not risky. Although
not completely stealthy, an attacker can be reasonably sure
to remain anonymous by adopting basic precautions, such as
proxies, virtual private networks and onion routing.
Yet, expecting an acquiescent scan target is a mere assump-
tion. The scanning system may receive poisoned responses
aiming to trigger vulnerabilities in the scanning host. Since
most scanning systems generate an HTML report, scan au-
thors can be exposed to attacks via their browser. This occurs
when the scanning system permits an unsanitized ﬂow of in-
formation from the response to the user browser. To illustrate,
consider the following, minimal HTTP response.
HT TP / 1. 1 20 0 OK
S er ve r : ng i nx /1 .1 7 .0
. . .
A naive scanning system might extract the value of the
ﬁeld (namely, the string
in the above
example) and include it in the HTML report. This implicitly
allows the scan target to access the scan author’s browser and
inject malicious payloads.
In this paper we investigate this attack scenario. We start
by deﬁning an attacker model that precisely characterizes
the threats informally introduced above. To the best of our
knowledge, this is the ﬁrst time that such an attacker model is
deﬁned in literature. Inspired by the attacker model, we de-
ﬁne an effective methodology to discover cross-site scripting
(XSS) vulnerabilities in the scanning systems and we imple-
ment a working prototype. We applied our prototype to 78
real-world scanning systems. The results conﬁrm our expec-
tation: several (36) scanning systems convey attacks. All of
these vulnerabilities have been notiﬁed through a responsible
The most remarkable outcome of our activity is possibly
an XSS vulnerability enabling remote code execution (RCE)
in Rapid7 Metasploit Pro. We show that the attack leads to
the complete takeover of the scanning host. Our notiﬁcation
prompted Rapid7 to undertake a wider assessment of their
products based on our attacker model.
The main contributions of this paper are:
1. a novel attacker model affecting scanning systems;
a testing methodology for ﬁnding vulnerabilities in scan-
RevOK, a prototype implementation of our testing
an analysis of the experimental results on 78 real-world
scanning systems, and;
three application scenarios highlighting the impact of
our attacker model.
This paper is structured as follows. Section 2recalls some
preliminary notions. Section 3presents our attacker model.
USENIX Association 23rd International Symposium on Research in Attacks, Intrusions and Defenses 17
Figure 1: Abstract architecture of a scanning system.
We introduce our methodology in Section 4. Our prototype
and experimental results are given in Section 5. Then, we
present the three use cases in Section 6, while we survey on
the related literature in Section 7. Finally, Section 8concludes
In this section we recall some preliminary notions necessary
to correctly understand our methodology.
2.1 Scanning systems
A scanning system is a piece of software that
a target through network requests,
collects the responses,
compiles a report. Security analysts often use scan-
ning systems for technical information gathering . Scan-
ning systems used for this purpose are called security scan-
ners. Our deﬁnition encompasses a wide range of systems,
from complex vulnerability scanners to simple ping utilities.
Figure 1shows the key actors involved in a scan process.
Human analysts use a user agent, e.g., a web browser, to select
a target, possibly setting some parameters, and start the scan
(1. start). Then, the scanning system crafts and sends request
messages to the target (2. request). The scanning system
parses the received response messages (3. response), extracts
the relevant information and provides the analyst with the
scan result (4. report). Finally, the analysts inspect the report
via their user agent.
Whenever a scanning system runs on a separate, remote
scanning host, we say that it is provided as-a-service. Instead,
when the scanner and scanning hosts coincide, we say that
the scanning system is on-premise.
A popular, command line scanning system is Nmap .
To start a scan, the analyst runs a command from the command
line, such as
nmap -sV 172.16.1.26 -oX report.xml
Then, Nmap scans the target (
) with requests
aimed at identifying its active services (
). By default,
Nmap sends requests to 1,000 frequently used TCP ports and
collects responses from the services running on the target.
The result of the scan is then saved (
Interestingly, some web applications, e.g., Nmap Online ,
provide the functionalities of Nmap as-a-service.
Scanning systems are often components of larger, more
complex systems, sometimes providing a browser-based GUI.
For instance, Rapid7 Metasploit Pro is a full-ﬂedged pen-
etration testing software. Among its many functionalities,
Metasploit Pro also performs automated information gath-
ering, even including vulnerability scanning. The reporting
system of Metasploit Pro is based on an interactive Web UI
used to browse the report.
2.2 Taint analysis
Taint analysis  refers to the techniques used to detect
how the information ﬂows within a program. Programs read
inputs from some sources, e.g., ﬁles, and write outputs to some
destinations, e.g., network connections. For instance, taint
analysis is used to understand whether an attacker can force a
program to generate undesired/illegal outputs by manipulating
some of its inputs. A tainted ﬂow occurs when (part of) the
input provided by the attacker is included in the (tainted)
output of the program. In this way, the attacker controls the
tainted output which can be used to inject malicious payloads
to the output recipient.
2.3 Cross-site scripting
Cross-site scripting (XSS) is a major attack vector for the
web, stably in the OWASP Top 10 vulnerabilities  since
its initial release in 2003. Brieﬂy, an XSS attack occurs when
the attacker injects a third-party web page with an executable
by the victim’s browser. The simplest payload for showing
that a web application suffers from an XSS vulnerability is
that causes the browser to display an alert window. This pay-
load is often used as a proof-of-concept (PoC) to safely prove
the existence of an XSS vulnerability.
There are several variants to XSS. Among them, stored
XSS has highly disruptive potential. An attacker can exploit a
stored XSS on a vulnerable web application to permanently
save the malicious payload on the server. In this way, the
attack is directly conveyed by the server that delivers the in-
jected web page to all of its clients. Another variant is blind
XSS, in which the attacker cannot observe the injected page.
For this reason, blind XSS relies on a few payloads, each
adapting to multiple HTML contexts. These payloads are
called polyglots. A remarkable example is the polyglot pre-
sented in  which adapts to at least 26 different contexts.
3 Attacker model
The idea behind our attacker model is sketched in Figure 2
(bottom), where we compare it with a traditional web secu-
rity attacker model (top). Typically, attackers use a security
scanner to gather technical information about a target appli-
cation. If the application suffers from some vulnerabilities,
18 23rd International Symposium on Research in Attacks, Intrusions and Defenses USENIX Association
Figure 2: Comparison between attacker models.
attackers can exploit them to deliver an attack towards their
victims, e.g., the application users. On the contrary, in our
attacker model attackers use malicious applications to attack
the author of a scan, e.g., a security analyst.
Here are the two novelties of our attacker model.
Attacks are delivered through HTTP responses instead
Attackers exploit the vulnerabilities of scanning systems
to strike their victims, i.e., the scan initiator.
Below, we detail the attacker’s goal and capabilities.
The objective of the attacker is to directly
strike the analyst. To do so, the attacker exploits the vulnera-
bilities of the target scanning system and its reporting system
to hit the analyst user agent. In this work, we assume that the
user agent is a web browser. This assumption covers every
as-a-service scanning system, as well as many on-premise
ones, which generate HTML reports. As a consequence, here
we focus on XSS which is a major attack vector for web
browsers. As usual in XSS, the attacker succeeds when the
victim’s browser executes a piece of attacker-provided code,
First, we state that the attacker has
adequate resources to detect vulnerabilities in scanning sys-
tems before deploying the malicious application. However,
the attacker capabilities do not include the possibility of ob-
serving the internal logic of the scanning system. That is, our
attacker operates in black-box mode.
Secondly, our attacker has complete control over the ma-
licious application, e.g., the attacker owns the scanned host.
However, we do not assume that the attacker can force the
victim to initiate the scanning process.
4 Testing methodology
In this section, we deﬁne a vulnerability detection methodol-
ogy based on our attacker model.
Figure 3: Phase 1 – ﬁnd tainted ﬂows.
4.1 Test execution environment
Our methodology relies on a test execution environment (TEE)
to automatically detect vulnerabilities in scanning systems. In
particular, a test driver simulates the user agent of the security
analyst, while a test stub simulates the scanned application.
Our TEE can
start a new scan,
receives the requests
of the scanning system,
craft the responses of the target
access the report of the scanning system.
Intuitively, the TEE replicates the conﬁguration of Figure 1.
In this conﬁguration, the test driver is executed by the scanner
host, and the test stub runs on the scanned host. In general, the
test driver is customized for each scanning system under test-
ing. For instance, it may consist of a Selenium-enabled 
browser stimulating the web UI of the scanning system.
Both the test driver and the test stub consist of some sub-
modules. These submodules are responsible for implementing
the two phases described below.
4.2 Phase 1: tainted ﬂows enumeration
The ﬁrst phase aims at detecting the existing tainted destina-
tions in the report generated by the scanning system. Having
a characterization of the tainted ﬂows is crucial to deal with
the input transformation logic of the target scanning system.
In general, since payloads may be arbitrarily modiﬁed before
being displayed in the report, detecting actual injections is
non-trivial. Instead, through this phase, injections can be de-
tected just by monitoring tainted destinations. The process is
depicted in Figure 3. Initially, the test driver asks the scanning
system to perform a scan of the test stub. The scan logic is
not exposed by the scanning system and, thus, it is opaque
from our perspective. Nevertheless, it generates some requests
toward the test stub. Each request is received by the scan fron-
tend and dispatched to the response generator, which crafts
The response generation process requires special attention.
One might think that a single, general-purpose response is
sufﬁcient. However, some scanning systems process the re-
sponses in non-trivial ways. For instance, they may abort
the scan if a malformed or suspicious response is received.
For this reason, we proceed as follows. First, we generate a
USENIX Association 23rd International Symposium on Research in Attacks, Intrusions and Defenses 19
response template, i.e., an HTTP response containing vari-
ables, denoted by
. Response templates are generated from a
fuzzer through a probabilistic context-free grammar (PCFG).
A PCFG is a tuple
context-free grammar such that
is the set of non-terminal
is the set of terminal symbols,
are the production
is the starting symbol. The additional component
of the PCFG, namely
, associates each rule in
with a probability, i.e., the probability to be selected by the
fuzzer generating a string of
. Additionally, we require that
is a probability distribution over each non-terminal
P(α7→β) = 1
In the following, we write
P(α7→ β) = p
α7→p1β1|p2. . . |pnβn
(where "" is the empty string).
The probability values appearing in our PCFG are assigned
according to the results presented in [20,21]. There, the au-
thors provide a statistical analysis of the frequency of real
response headers as well as a list of information-revealing
ones. Such headers are thus likely to be reported by a scanning
system. Finally, when the frequency of a ﬁeld is not given
(e.g., for variables), we apply the uniform distribution.
An excerpt of our PCFG is given in Figure 4. For the sake of
presentation, here we omit some of the rules and we refer the
interested reader to the project web site
. The grammar deﬁnes
the structure of a generic HTTP response (
) made of a
), a status (
), a list of headers (
a body (
are all fresh and they can appear in
several parts of the generated response template. In particular,
variables can be located in status messages (i.e.,
), header ﬁelds (i.e.,
body. For instance, a ﬁeld can be
nginx/ is a server type (SrvT, omitted for brevity).
The response template is then populated by replacing each
variable with a token. A token is a unique sequence of char-
acters that is both recognizable, i.e., it has a negligible prob-
ability of appearing by chance, and uninterpreted, i.e., the
browser treats it as plain text, when appearing in an HTML
document. All tokens are mapped to the responses containing
them. Responses are stored in a database. Finally, the test
driver matches the tokens appearing in the responses database
with those occurring in the scan report. Such tokens are evi-
dence that there are tainted ﬂows in the internal logic of the
scanning system. Tokens mark the source and the sink of a
ﬂow in the response and report, respectively. All these tokens
are stored in the tainted tokens database.
Resp 7→1Vers Stat Head Body
Vers 7→0.5" HT T P /1 . 0" |0.5" H TT P / 1. 1 "
Stat 7→0.554 Succ |0.427 Redr |0.013 ClEr |0.006 SvEr
Succ 7→0.5"2 0 0 OK " | 0.5"200" t
Redr 7→0.386 "3 01 M ov ed P er m an e nt l y " | 0.386 "301" t
|0.114 "3 0 2 Fou n d " | 0.114 "302" t
ClEr 7→0.26 "403 Forbidden" |0.26 "403" t
|0.24 "4 0 4 N o t Fou n d " | 0.24 "404" t
SvEr 7→0.5"5 00 I nt er na l Se rv er Er ro r " |0.5"500" t
Head 7→1Serv PwBy Locn SetC CntT AspV MvcV Varn
→StTS CnSP XSSP FrOp
Serv 7→0.475 " Se r ve r : " t|0.475 " Se rv e r :" Sr v T t
PwBy 7→0.24 "X - P o we r ed -B y : php "
|0.24 "X - P o we r ed -B y :" t
Locn 7→0.315 " Lo c at i on : " Lin k |0.315 " Location:" t
Link 7→0.516 " ht t ps : / /" t
|0.167 "http ://" t":8899"
|0.135 "http ://" t":8090"
|0.065 "http ://" t"/ l og i n . l p "
|0.059 "/ n o co o k ie s . h tm l "
|0.058 " c oo k ie c h ec k e r ? ur i = /"
SetC 7→0.175 " Se t - C o o k ie : " Cki e
Ckie 7→0.471 "__cfduid =" t|0.394 "PHPSESSID=" t
|0.087 " AS P . NE T Se s si o n = " t
|0.048 "JSESSIONID =" t
CntT 7→0.07 "X - C on te n t - Ty pe - O p ti on s : no sn i ff "
|0.07 "X - C o nt e nt -T yp e - O p ti o n s :" t
AspV 7→0.5"X - A s pN e t - V e r si o n : " t
MvcV 7→0.5"X - A s p Ne t Mv c - V e r si o n : " t
Varn 7→0.5"X - V a r ni s h : " t
StTS 7→0.5" St ri c t - T r an s po r t - S e cu r i ty : " STS A
STSA 7→0.111 " ma x - a g e = " N+
|0.111 " ma x - a g e = " t
|0.111 " ma x - a g e = " N+" ; p r el o ad "
|0.111 " ma x - a g e = " t"; p re lo a d "
Figure 4: Response template grammar (excerpt).
4.3 Phase 2: vulnerable ﬂows identiﬁcation
The second phase aims to conﬁrm which tainted ﬂows are
actually vulnerable. We use PoC exploits to conﬁrm the vul-
nerability. The workﬂow is depicted in Figure 5. As for the
ﬁrst phase, the test driver launches a scan of the test stub.
When the test stub receives the requests, the exploit builder
extracts a response from the responses database. Then, the
response is injected with a PoC exploit. More precisely, a
tainted token is selected among those generated during Phase
1. The tainted token in the response is replaced with a payload
taken from a predeﬁned injection payload database. In gen-
eral, a vulnerability is conﬁrmed by the test driver according
to predeﬁned, exploit-dependent heuristics. Although tainted
ﬂows can be subject to different types of vulnerabilities, as
discussed in Section 3, we focus on XSS. Thus, the heuristics
implemented by the exploit checker consists of recognizing
a vulnerable ﬂow when an alert window is spawned by the
corresponding, tainted ﬂow. Finally, the exploit checker stores
the vulnerable ﬂows in the conﬁrmed vulnerabilities database.
The deﬁnition of injection payload is non-trivial. Since our
20 23rd International Symposium on Research in Attacks, Intrusions and Defenses USENIX Association
Figure 5: Phase 2 – ﬁnd vulnerable ﬂows.
TEE applies to both on-premise and as-a-service scanning
systems, some issues must be considered. The ﬁrst issue is
testing performances. As a matter of fact, scanning systems
can take a considerable amount of time to perform a single
scan. Moreover, as-a-service scanning systems should not
be ﬂooded by requests to avoid degradation of the quality
of service. For these reasons, we aim to limit the number of
payloads to check.
As discussed in Section 2.3, polyglots allow us to test mul-
tiple contexts with a single payload. In this way, we increase
the success probability of each payload and, thus, we reduce
the overall number of tests.
In principle, we might resort to the polyglot of , which
escapes 26 contexts. However, its length (144 characters)
is not adequate since many scanning systems shorten long
strings when compiling their reports, so preventing the ex-
ploit from taking place. To avoid this issue, we opted for poly-
glots such as
"’/><img src=’x’ onerror=’alert(1)’/>
This is rendered by the browser when appearing inside both
an HTML tag and an HTML attribute. The reason is that
allow the payload to escape from quoted
has two advantages. First, it circumvents basic input ﬁltering
methods, e.g., blacklisting of the
our payload applies to both static and dynamic reports. More
precisely, a static report consists of HTML pages that are
created by the scanning system and subsequently loaded by
the analyst’s browser. Instead, a dynamic report is loaded
by the browser and updated by the scanning system during
the scan process. The HTML5 standard speciﬁcation [16,
§ 8.4.3] clearly states that browsers can skip the execution of
dynamically loaded scripts. For this reason, our payload binds
the script execution to an error event that we trigger using
a broken image link (i.e.,
). A concrete example of
this scenario is discussed in Section 6.2.
5 Implementation and results
In this section, we present our prototype RevOK. We used it
to carry out an experimental assessment that we discuss in
Our prototype consists of two modules: the test driver and the
test stub. We detail them below.
A dedicated test driver is used for each scanning
system. The test driver
triggers a scan against the test stub,
saves the report in HTML format and
report to detect tainted and vulnerable ﬂows (in Phase 1 and
2, respectively). While
is the same for all the scanning
systems, (i)and (ii)may vary.
In general, the implementation of
two categories depending on whether the scanning system
has a programmable interface or only a GUI. When a pro-
grammable interface is available, we implement a Python 3
client application. For instance, we use the native os Python
module to launch Nmap so that its report is saved in a spe-
ciﬁc location (as describe in Section 2). Similarly, we use the
requests Python library
to invoke the REST APIs provided
by a scanning system and save the returned HTML report.
Instead, when the scanning system only supports GUI-based
interactions, we resort to GUI automation. In particular, we
use the Selenium Python library
for browser-based GUIs and
for desktop GUIs. In the case of GUI automa-
tion, the test driver repeats a sequence of operations recorded
during a manual test.
Finally, for the report processing step
between two operations. The tainted ﬂow detection trivially
searches the report for the injected tokens provided by the
response generator (see below). Instead, vulnerable ﬂows are
conﬁrmed by checking the presence of alert windows through
the Selenium function switch_to_alert().
For the response generator, we implemented
the PCFG grammar fuzzer detailed in Section 4.2 in
Python. Tokens are represented by randomly-generated Uni-
versally Unique Identiﬁers  (UUID). A UUID con-
sists of 32 hexadecimal characters organized in 5 groups
that are separated by the
symbol. An example UUID is
. As required
in Section 4.2, UUIDs are both recognizable (as collisions
are extremely unlikely to happen) and uninterpreted (as they
contain no HTML special characters).
On the other hand, starting from a response, the exploit
builder replaces a given UUID with an injection payload.
Payloads are taken for a predeﬁned list of selected polyglots,
as discussed in Section 4.3.
USENIX Association 23rd International Symposium on Research in Attacks, Intrusions and Defenses 21
5.2 Selection criteria
We applied our prototype implementation to 78 scanning
systems. The full list of scanning systems, together with our
experimental results (see Section 5.3), is given in Table 1.
There, we use
to distinguish between as-a-service
and on-premise scanning systems, respectively.
For our experiments, we searched for scanning systems
included in several categories. In particular, we considered
security scanners, server ﬁngerprinting tools, search engine
optimization (SEO) tools, redirect checkers, and more. From
these, we removed scanning systems belonging to the follow-
Abandonware, i.e., on-premise scanning systems that
were not maintained in the last 5 years.
Paywalled, i.e., scanning systems that are not free and
have no trial version.
Scheduled, i.e., as-a-service scanning systems that only
perform periodic scans, not controlled by the analyst.
We applied RevOK to the scanning systems of Table 1. For
each scanning system, we used RevOK to execute 10 scan
rounds (see Section 4) and we listed all the detected tainted
and vulnerable ﬂows. As a result, we discovered that 67 scan-
ning systems have tainted ﬂows and, among them, 36 are
vulnerable to XSS.
In Table 1, for each scanning system we report the number
of tainted and vulnerable ﬂows (
, respectively) de-
tected by RevOK. After running RevOK, we also conducted
a manual vulnerability assessment of each scanning system.
The assessment consisted of a review of each tainted ﬂow,
followed by a manual payload generation (see below).
indicates that an XSS vulnerability
was found by a human analyst starting from the outcome
of RevOK. It is worth noticing that only in one case, i.e.,
DupliChecker, RevOK resulted in a false negative w.r.t. the
manual analysis. By investigating the causes, we discovered
that DupliChecker performs URL encoding on the tainted
locations. This encoding, among other operations, replaces
white spaces with
, thus invalidating our payloads. To
effectively bypass URL encoding, we replaced white spaces
(U+0020) with non-breaking spaces (U+00A0) that are not
modiﬁed. Thus, we deﬁned a new polyglot payload that uses
non-breaking spaces and we added it to the injection list
included in RevOK. Using this new payload, RevOK could
also detect the vulnerability in DupliChecker.
At the time of writing, all the vulnerabilities detected by
RevOK have been reported to the tool vendors and are under-
going a responsible disclosure process (see Appendix A).
In Figure 6we show the frequency of the tainted and vulner-
able ﬂows over the 14 ﬁelds considered by RevOK. Location
Figure 6: Frequency of tainted and vulnerable ﬂows.
Figure 7: Correlation between tainted ﬁelds.
has 59 tainted ﬂows, the highest number, and 21 vulnerable
ﬂows. Server only has 51 tainted ﬂows, but it has 26 vul-
nerable ﬂows, the highest number. On the other hand, Body
has only 14 tainted ﬂows and only 1 vulnerable ﬂow. This
highlights that most scanning systems sanitize the Body ﬁeld
in their reports. The reason is that HTTP responses most
likely contain HTML code in their Body. Thus, sanitization is
mandatory to preserve the report layout. Also, the Body ﬁeld
is often omitted by the considered scanning systems.
In Figure 7and Figure 8we show the correlation matrices
for tainted and vulnerable ﬁelds, respectively. From these
matrices we observe a few, relevant facts. We brieﬂy discuss
The ﬁrst observation is that the Body ﬁeld is almost unre-
lated to the other ﬁelds, both in terms of tainted and vulnerable
ﬂows. This is somehow expected since the Body ﬁeld is often
neglected as discussed above.
22 23rd International Symposium on Research in Attacks, Intrusions and Defenses USENIX Association
Table 1: Experimental results for the considered scanning systems. († requested to stay anonymous.)
T is the number of tainted ﬂows, V is the number of vulnerable ﬂows, M indicates if a human analyst found a vulnerability.
Name T V M Name T V M Name T V M
AddMe 11 11 XInternetOfﬁcer 2 1 XSecurity Headers 13 -
AdResults 14 - [Anonymous]†11 1 XSEO Review Tools - -
HArachni 14 - iplocation.net - - SeoBook 12 11 X
AUKSEO - - IPv6 Scanner - - SERP-Eye - -
BeautifyTools 13 - itEXPERsT - - Server Headers 13 12 X
BrowserSPY 9 - HIVRE 2 - Site 24x7 13 13 X
CheckHost 1 - JoydeepDeb 13 13 XSQLMap Scanner 1 1 X
1 - JSON Formatter 13 13 XSSL Certiﬁcate Tools 12 -
CheckSERP 11 - LucasZ ZeleznY 2 1 XStepForth 12 11 X
CheckShortURL 1 1 XHMetasploit Pro 11 3 XStraightNorth - -
Cloxy Tools 11 - Monitor Backlinks 12 - SubnetOnline 14 13 X
CookieLaw 1 - HNessus 11 - Sucuri Site Check 3 -
CookieMetrix 2 1 XNikto Online 2 2 XSureOak 9 8 X
DNS Checker 1 1 XHNmap 14 - TheSEOTools 1 1 X
DNSTools - - Nmap Online 12 1 XTutorialspots 13 13 X
Dupli Checker 1 - XOnline SEO Tools 12 12 XUrl X-Ray 1 -
evilacid.com 12 12 XHOpenVAS 3 - Urlcheckr 10 -
expandUrl 1 - HOWASP ZAP 4 - Urlex - -
13 13 XPentest-Tools 2 1 Xw-e-b.site 13 13 X
GDPR Cookie Scan - - Port Checker 10 - W3dt.Net 12 11 X
GeekFlare 12 - Redirect Check 11 10 XWeb Port Scanner - -
Hacker Target 13 - Redirect Detective 2 - XWeb Sniffer 14 -
HTTP Tools 12 12 XReqBin 13 - WebConfs 13 12 X
httpstatus.io 14 - Resplace 12 - HWebMap 14 1 X
HInsightVM 3 - RexSwain.com 13 1 XWhat Is My IP 12 -
Search Engine Reports
1 1 XHWMap 12 10 X
Figure 8: Correlation between vulnerable ﬁelds.
Also the Location ﬁeld is weakly correlated with the other
ﬁelds. This is due to the behavior of redirect checkers. As
a matter of fact, this category of scanning systems focus on
Location, and, in most cases, ignore the other ﬁelds. An in-
depth evaluation of the behavior of redirect checkers is given
in the application scenario of Section 6.3.
An argument similar to the previous one for Location also
applies to Status Message. The Status Message is typically
used by scanning systems that carry out availability checks,
e.g., to verify that a web site is up and running.
Finally, for what concerns all the other ﬁelds, we observe
an extremely strong correlation. The conﬁrms the proposition
of  about the security relevance of the headers that we are
considering. Indeed, most of the scanning systems included in
our experiments report them all. This also highlights that the
exposure of the scanning systems is not ﬁeld-dependent, e.g.,
when a scanning system is vulnerable via one these ﬁelds,
most likely it is also vulnerable via the others.
6 Application Scenarios
In this section, we present three application scenarios for
our methodology. For each scenario, we highlight the sub-
class of vulnerable scanning systems, the vulnerability and
USENIX Association 23rd International Symposium on Research in Attacks, Intrusions and Defenses 23
Figure 9: XSS PoC on Nmap Online.
its impact if an attacker were to use it in the wild. For each
subclass of scanning systems, we chose a representative that
we present as a concrete case study: Nmap Online for as-a-
service scanning systems, Metasploit Pro for on-premise ones,
and CheckShortURL  for redirect checkers.
6.1 Scan Attribution
Attack attribution is a hot topic since it is often difﬁcult or
even impossible to achieve. The main reasons are the struc-
ture of the network and some state-of-the-art technologies
that enable clients anonymity. For instance, analysts can use
proxies, virtual private networks, and onion routing to hide
the actual source of the requests from the recipient. How-
ever, an injected browser may be forced to send identifying
data directly inside the HTTP requests, so making network-
level anonymization techniques ineffective. In this section, we
show how to attribute scans using our attacker model through
an application scenario based on Nmap Online .
Nmap Online vulnerability
Nmap Online is a web appli-
cation providing some of the functionalities of Nmap. Users
can scan a target with Nmap without having to install it on
their machine. Furthermore, since requests originate from the
Nmap Online server, users can stay anonymous w.r.t. the scan
target. When users start a scan, they select the target IP and
the scan type. The Nmap Online website scans its target and
displays the retrieved information to the user, e.g., server type
Nmap Online reports suffered from an XSS vulnerability.
Figure 9shows an injected report. The injection occurs on the
Server response header. In this case, the Server ﬁeld was set
Since there is no guarantee that more
than one scan will occur, we recur to browser hooking, which
5The vulnerability was ﬁxed on March 24, 2020.
can be obtained with a single XSS payload. A hooked browser
becomes the client in a command and control (C2) infrastruc-
ture, thus actively querying the C2 server for instructions. This
allows the attacker to submit arbitrary commands afterward
even when no other scans occur.
An effective way to achieve browser hooking is
through BeEF . In particular, the BeEF C2 client
is injected via the script hook.js. For instance, we
can deploy hook.js by setting the Server header to
where [C2] is the IP address of the C2 server.
The BeEF framework includes modules
for ﬁngerprinting the victim host. For instance, the browser
module allows us to get the browser name, version, visited do-
mains, and even starting a video streaming from the webcam.
Similarly, the host module allows us to retrieve data such
as physical location and operating system details. Some of
these operations, e.g., browser ﬁngerprinting, require no vic-
tim interaction. Instead, others need the victim to take some
actions, e.g., explicitly grant permission to use the webcam.
To overcome these hurdles, attackers usually employ auxil-
iary techniques, e.g., credential theft, implemented by some
BeEF modules, e.g., social engineering. Finally, the overall
ﬁngerprinting process can be automated through the BeEF
autorun rule engine .
6.2 Scanning host takeover
On-premise scanning systems, which run on the analyst’s host,
may have privileged, unrestricted access to the underlying
platform. In some cases, on-premise systems are provided
with a user interface that includes both the reporting system
and a control panel. When such a user interface is browser-
based, a malicious scan target can inject commands in the
reporting system and perform lateral movements by triggering
the scanning system controls.
The attack strategy abstractly described above must be
implemented through concrete steps that are speciﬁc to the
scanning system. In this section, we show an implementa-
tion of this attack strategy for the popular scanning system
Metasploit Pro. In particular, we show how to perform lat-
eral movements leading to a complete scanning host takeover
through remote code execution (RCE). Finally, we carry out
an impact evaluation.
CVE-2020-7354 and CVE-2020-7355
Metasploit Pro is a
full-ﬂedged penetration testing framework. It has a browser-
based UI that integrates both a scan reporting system and
many controls for running the most common tasks, including
host scanning. Each command is executed by the Metasploit
back-end, which is stimulated through a REST API.
24 23rd International Symposium on Research in Attacks, Intrusions and Defenses USENIX Association
Figure 10: Stored XSS PoC on Metasploit Pro.
The vulnerability we found affects versions 4.17.0 and
below. It was remediated on May 14, 2020, with patch 4.17.1.
A malicious scan target can inject a Stored XSS payload in
the UI. Multiple pages are vulnerable, e.g.,
Metasploit Pro fetches the Server header and displays
it inside the INFO column with no sanitization. Fig-
ure 10 shows the effect of setting the Server header to
<img src=’x’ onerror=’alert(1)’/>
(as described in
Remote code execution
We use the XSS vulnerability de-
scribed above to gain a foothold in the browser on the scan-
ning host. For instance, we can inject a BeEF hook to remotely
interact with the browser (as in Section 6.1). The hooked
browser is the steppingstone to interact with the Metasploit
Pro UI and trigger its controls. Interestingly, Metasploit Pro
includes a diagnostic console, i.e., an embedded terminal that
allows the analyst to run arbitrary commands on the under-
lying operating system.
Although the diagnostic console
is disabled by default, the attacker can activate it through
BeEF. In particular, the hooked browser is forced to perform a
POST HTTP request to
. Since the diag-
nostic console is a browser-embedded Metasploit terminal
emulator, the attacker can submit commands from the BeEF
The Metasploit Pro documentation
clearly states that “Metasploit Pro Users Run as Root. If
you log in to the Metasploit Pro Web UI, you can effectively
run any command on the host machine as root”. This opens
a wide range of opportunities for the attacker. Among them,
the most impactful is to establish a reverse shell. The reasons
are twofold. First, opening a shell on the scanning host allows
the attacker to execute commands directly on the operating
system of the victim. Thus, attacks are no longer tunneled
through the initial vulnerability, which might become unavail-
able, e.g., if Metasploit Pro is terminated. Second, a reverse
shell works well even when certain network facilities, such as
ﬁrewalls and NATs, are in place. Indeed, although these facil-
ities may prevent incoming connections, usually they allow
outgoing ones. Once a reverse shell is established, the attacker
can access a permanent, privileged shell on the victim host.
6.3 Enhanced phishing
The goal of a phishing attack is to induce the victim to commit
a dangerous action, e.g., clicking an untrusted URL or opening
an attachment. In this section, we show how our attacker
model changes phishing attacks, using CheckShortURL as an
A common phishing scenario is that
of an unsolicited email with a link pointing to a malicious
web page, e.g.,
. The phishing site mimics a
reputable, trusted web page. For instance, the attacker may
clone a bank’s web site so that unaware users submit their
access credentials. Another technique is to provoke a reaction
to an emotion, such as fear. This happens, for instance, with
menacing alerts about imminent account locking and malware
infections. Again, if victims believe that urgent action must
be taken, they could overlook common precautions and, e.g.,
download dangerous ﬁles.
Most of the examples given above
require the victim to open a phishing URL. Common, un-
skilled users typically evaluate the trustworthiness of a URL
by applying their common sense.
such as URL shortening and open redirects  masquerade
the phishing URL to resemble a trusted domain.
Some online services may help the user to detect phishing
attacks. For instance, reputation systems and black/white lists,
e.g., Web of Trust
, can be queried for a suspect URL. How-
ever, phishing URLs often point to temporary websites that
are unknown to these systems.
Since browsers automatically redirect without asking for
conﬁrmation, in  the authors highlight that victims can
defend themselves by checking where the URL redirects with-
out browsing it. To this aim, several online services, e.g.,
CheckShortURL, do redirect checking to establish the ﬁnal
destination of a redirect chain. Typically, the chain is printed
in a report that the user inspects before deciding whether to
proceed or not.
10E.g., see https://phishingquiz.withgoogle.com/
USENIX Association 23rd International Symposium on Research in Attacks, Intrusions and Defenses 25
Figure 11: Phising through CheckShortURL.
Exploiting redirect checkers
Redirect locations are con-
tained in the Location header of the HTTP response asking
for a redirection. According to our attacker model, this value
is controller by the attacker. Thus, if the victim uses a vulner-
able redirect checker, the report may convey an attack to the
user browser. Since the goal is phishing, the attacker has two
possibilities, i.e., forcing the URL redirection and exploit the
scanning system reputation.
In the ﬁrst case, the attacker delivers an XSS payload such
window.location = "http://ev.il/"
. When it is ex-
ecuted, the browser is forced to open the given location and
to redirect the user to the phishing site.
The second case is even more subtle. Since the XSS attack
is delivered by the scanning system, the attacker can perform a
phishing operation and ascribe it to the reporting system. For
instance, the attacker can make the user browser download
a malicious ﬁle pretending to be the scanning system pdf
report. In this way, the attacker abuses the reputation of the
scanning system to lure the victim. This can be achieved with
the following payload.
The effect of injecting such a payload in CheckShortURL is
shown in Figure 11.
7 Related Work
In this section, we survey the related literature.
7.1 Attacking the attacker
Although not frequent in the literature, the idea of attacking
the attackers is not completely new. Its common interpretation
is that the victim of an attack carries out a counter-strike
against the host of the aggressor. However, even tracking an
attack to its actual source is almost impossible if the attacker
takes proper precautions (as discussed in Section 6.1). To
the best of our knowledge, we are the ﬁrst to consider the
response-based exploitation of the attackers scanning systems.
Djanali et al.  deﬁne a low-interaction honeypot that
simulates vulnerabilities to lure the attackers to open a ma-
licious website. When this happens, the malicious website
delivers a browser exploitation kit. The exploitation relies
on a LikeJacking  attack to obtain information about the
attacker’s social media proﬁle. Unlike our approach, their
proposal substantially relies on social engineering and does
not consider vulnerabilities in the attacker’s equipment.
Also, Sintov  relies on a honeypot to implement a re-
verse penetration process. In particular, his honeypot attempts
to collect data such as the IP address and the user agent of the
attacker. Again, this proposal amounts to retaliating against
the attackers after identifying them.
In terms of vulnerabilities, some researchers already re-
ported weaknesses in scanning systems. The closest to our
work is CVE-2019-5624 , a vulnerability in RubyZip that
also affects Metasploit Pro. This vulnerability allows attack-
ers to exploit path traversal to create a cron job that runs
arbitrary code, e.g., to create a reverse shell. To achieve this,
the attacker must import a malicious ﬁle in Metasploit Pro as
a new project. However, as for , this attack requires social
engineering as well as other conditions (e.g., about the OS
used by the attacker). As far as we know, this is the only other
RCE vulnerability reported for Metasploit Pro. Instead, apart
from ours, no XSS vulnerabilities have been reported.
7.2 Security scanners assessment
Several authors considered the assessment of security scan-
ners. However, they mainly focus on their effectiveness and
efﬁciency in detecting vulnerabilities.
Doupé et al.  present WackoPicko, an intentionally vul-
nerable web application designed to benchmark the effective-
ness of security scanners. The authors provide a comparison
of how open source and commercial scanners perform on the
different vulnerabilities contained in WackoPicko.
Holm et al.  perform a quantitative evaluation of the ac-
curacy of security scanners in detecting vulnerabilities. More-
over, Holm  evaluated the performance of network secu-
rity scanners, and the effectiveness of remediation guidelines.
Mburano et al.  compare the performance of OWASP
ZAP and Arachni. Their tests are performed against the
OWASP Benchmark Project  and the Web Application
Vulnerability Security Evaluation Project (WAVSEP) .
Both these projects aim to evaluate the accuracy, coverage,
and speed of vulnerability scanners.
To the best of our knowledge, there are no proposals about
the security assessment of scanning systems. Among the pa-
pers listed above, none consider our attacker model or, in
general, the existence of security vulnerabilities in security
26 23rd International Symposium on Research in Attacks, Intrusions and Defenses USENIX Association
7.3 Vulnerability detection
Many authors proposed techniques to detect software vulner-
abilities. In principle, some of these proposals can be applied
to scanning systems.
The general structure of vulnerability testing environments
was deﬁned by Kals et al. . Our TEE implements their
abstract framework by adapting it to inject responses instead
of requests. The main difference is our test stub, that receives
the requests from the scanning system under test. We substi-
tute the crawling phase with tainted ﬂow enumeration (see
Section 4.2). During the attack phase, we substitute the pay-
load list with a list of polyglots, which reduces testing time.
Our exploit checker implements their analysis module as we
also deal with XSS.
Many authors have proposed techniques to perform vulner-
ability detection through dynamic taint analysis. For instance,
Xu et al.  propose an approach that dynamically monitors
sensitive sinks in PHP code. It rewrites PHP source code, in-
jecting functions that monitor data ﬂows and detect injection
Avancini and Ceccato  also use dynamic taint analysis to
carry out vulnerability detection in PHP applications. Brieﬂy,
they implement a testing methodology aiming at maximizing
the code coverage. To check whether a certain piece of code
was executed, they rewrite part of the application under test
to deploy local checks.
These approaches rely on inspecting and manipulating the
source code of the application under test. Instead, we work
under a black-box assumption.
Besides vulnerability detection, some authors even use dy-
namic taint analysis to implement exploit detection and pre-
vention methodologies. Vogt et al.  prevent XSS attacks
by combining dynamic and static taint analysis in a hybrid ap-
proach. Similarly, Wang et al.  detect DOM-XSS attacks
using dynamic taint analysis. Both these approaches iden-
tify sensitive data sinks in the application code and monitor
whether untrusted, user-provided input reaches them.
Dynamic taint analysis techniques were also proposed for
detecting vulnerabilities in binary code.
Newsome and Song  propose TaintCheck, a method-
ology that leverages dynamic taint analysis to ﬁnd attacks
in commodity software. TaintCheck tracks tainted sinks and
detects when an attack reaches them. It requires a monitoring
infrastructure to achieve this.
Clause et al.  propose a generic dynamic taint analysis
framework. Similarly to , Clause et al. implement their
technique for x86 binary executables. However, the theoretical
framework could be adapted to ﬁt our methodology.
In principle, the exploit prevention techniques mentioned
above might be used to mitigate some of the vulnerabilities de-
tected by RevOK. However, they do not deal with vulnerabil-
ity detection. Moreover, they require access to the application
In this paper we introduced a new methodology, based on a
novel attacker model, to detect vulnerabilities in scanning sys-
tems. We implemented our methodology and we applied our
prototype RevOK to 78 real-world scanning systems. Our ex-
periments resulted in the discovery of 36 new vulnerabilities.
These results conﬁrm the effectiveness of our methodology
and the relevance of our attacker model.
This paper was partially funded by
EU H2020 research project SPARTA (grant agreement
Wade Alcorn. Beef autorun rule engine.
Autorun-Rule- Engine, Accessed March 19, 2020.
Wade Alcorn. The Browser Exploitation Framework,
Accessed March 3, 2020.
Andrea Avancini and Mariano Ceccato. Towards Secu-
rity Testing with Taint Analysis and Genetic Algorithms.
In Proceedings of the ICSE Workshop on Software En-
gineering for Secure Systems, 2010.
Luca Carettoni. On insecure zip handling, Rubyzip and
Metasploit RCE (CVE-2019-5624).
Accessed March 19, 2020.
CheckShortURL. CheckShortURL, Accessed March 23,
Shay Chen. The Web Application Vulnerability Scan-
ner Evaluation Project.
projects/wavsep/, Accessed March 19, 2020.
James Clause, Wanchun Li, and Alessandro Orso. Dy-
tan: a generic dynamic taint analysis framework. In
Proceedings of the International Symposium on Soft-
ware Testing and Analysis, 2007.
MITRE Corporation. ATT&CK - Technical Information
TA0015/, Accessed March 20, 2020.
Supeno Djanali, FX Arunanto, Baskoro Adi
Pratomo, Abdurrazak Baihaqi, Hudan Studiawan,
and Ary Mazharuddin Shiddiqi. Aggressive web
application honeypot for exposing attacker’s identity.
In Proceedings of the 1st International Conference
on Information Technology, Computer, and Electrical
USENIX Association 23rd International Symposium on Research in Attacks, Intrusions and Defenses 27
Adam Doupé, Marco Cova, and Giovanni Vigna. Why
Johnny can’t pentest: An analysis of black-box web vul-
nerability scanners. In Proceedings of the International
Conference on Detection of Intrusions and Malware,
and Vulnerability Assessment, 2010.
Ahmed Elsobky. Unleashing an Ultimate XSS Poly-
Accessed March 19, 2020.
OWASP Foundation. OWASP Top Ten.
owasp.org/www-project- top-ten/, 2017.
OWASP Foundation. OWASP Benchmark Project.
Accessed March 19, 2020.
Satish Gojare, Rahul Joshi, and Dhanashree Gaigaware.
Analysis and Design of Selenium WebDriver Automa-
tion Testing Framework. Procedia Computer Science,
MUNSIRADO Group. Nmap Online, Accessed March
Web Hypertext Application Technology Working Group.
HTML Living Standard, Last updated March 27, 2020.
Hannes Holm. Performance of automated network vul-
nerability scanning at remediating security issues. Com-
puters & Security, 2012.
Hannes Holm, Teodor Sommestad, Jonas Almroth, and
Mats Persson. A quantitative evaluation of vulnerabil-
ity scanning. Information Management & Computer
Stefan Kals, Engin Kirda, Christopher Kruegel, and Ne-
nad Jovanovic. SecuBat: A Web Vulnerability Scanner.
In Proceedings of the 15th International Conference on
World Wide Web, 2006.
Arturs Lavrenovs and F Jesús Rubio Melón. HTTP
Security Headers Analysis of Top One Million Websites.
In Proceedings of the 10th International Conference on
Cyber Conﬂict (CyCon), 2018.
Arturs Lavrenovs and Gabor Visky. Investigating HTTP
response headers for the classiﬁcation of devices on the
Internet. In Proceedings of the 7th IEEE Workshop
on Advances in Information, Electronic and Electrical
Engineering (AIEEE), 2019.
Paul Leach, Michael Mealling, and Rich Salz. A univer-
sally unique identiﬁer (UUID) urn namespace. 2005.
Balume Mburano and Weisheng Si. Evaluation of Web
Vulnerability Scanners Based on OWASP Benchmark.
In Proceedings of the 26th International Conference on
Systems Engineering (ICSEng), 2018.
James Newsome, Dawn Song, James Newsome, and
Dawn Song. Dynamic taint analysis: Automatic detec-
tion, analysis, and signature generation of exploit attacks
on commodity software. In Proceedings of the 12th
Network and Distributed Systems Security Symposium,
 Nmap project. Nmap, Accessed March 23, 2020.
E. J. Schwartz, T. Avgerinos, and D. Brumley. All You
Ever Wanted to Know about Dynamic Taint Analysis
and Forward Symbolic Execution (but Might Have Been
Afraid to Ask). In Proceedings of the IEEE Symposium
on Security and Privacy, 2010.
Craig A Shue, Andrew J Kalafut, and Minaxi Gupta.
Exploitable Redirects on the Web: Identiﬁcation, Preva-
lence, and Defense. In Proceedings of the 2nd USENIX
Workshop on Offensive Technologies, 2008.
Alexey Sintsov. Honeypot that can bite: Reverse pene-
tration. In Black Hat Europe Conference, 2013.
SOPHOSLABS. Facebook worm: Likejacking.
, Accessed on
March 19, 2020.
Philipp Vogt, Florian Nentwich, Nenad Jovanovic, Engin
Kirda, Christopher Kruegel, and Giovanni Vigna. Cross
Site Scripting Prevention with Dynamic Data Tainting
and Static Analysis. In Proceedings of the Network and
Distributed System Security Symposium (NDSS), 2007.
Ran Wang, Guangquan Xu, Xianjiao Zeng, Xiaohong
Li, and Zhiyong Feng. TT-XSS: A novel taint tracking
based dynamic detection framework for DOM Cross-
Site Scripting. Journal of Parallel and Distributed Com-
Wei Xu, Sandeep Bhatkar, and R Sekar. Practical dy-
namic taint analysis for countering input validation at-
tacks on web applications. Technical Report SECLAB-
05-04, Department of Computer Science, Stony Brook,
28 23rd International Symposium on Research in Attacks, Intrusions and Defenses USENIX Association
A Vulnerability Disclosure
All the vulnerabilities reported in this paper were promptly
notiﬁed to the scanning system vendors. We based our re-
sponsible disclosure process on the ISO 29147
Below, we describe each disclosure step in detail and the
A.1 First contact
The ﬁrst step of our responsible disclosure process consisted
of a non-technical email notiﬁcation to each vendor. We report
our email template below.
De a r < sc a n ni n g s ys t em ve n do r > ,
my n am e is < i den ti f ic ati on an d li nk s >
As p ar t of m y res ea rch a cti vi ty on a
no ve l t hr ea t m ode l , I fo un d t ha t y our
pla tf orm i s mo st l i ke ly vul ne r ab le
to X SS a t ta c ks .
In p arti cu lar , the v ul ne ra bi li ty I
d is c ov e re d m ig h t ex p os e y ou r en d - u se rs
to c o nc r et e r is k s .
Fo r t he se r eas on s , I am c on ta ct in g
yo u to s tar t a re spo ns i bl e d is c lo sur e
pro ce ss. I n t hi s respe ct , I am k in d ly
ask in g yo u to p oin t me to the ri gh t
cha nn el (e . g. , an of fic ia l b ug b oun ty
pro gr am or a se cu r it y o ff ic er to
Ki nd re ga rds
We sent the email through ofﬁcial channels, e.g., contact
mail or form, when available. For all the others, we tried with
a list of 13 frequent email addresses, including security@,
webmaster@, contact@, info@, admin@, support@.
In 5 cases the previous attempts failed. Thus, we submitted
the corresponding vulnerabilities to OpenBugBounty.13
A.2 Technical disclosure
After the vendor answered our initial notiﬁcation, providing
us with the technical point of contact, we sent a technical
report describing the vulnerability. The report was structured
according to the following template, which was accompanied
by a screenshot of the PoC exploit inside their system.
Th e i ss u e i s a C ro ss - Si t e Sc r i pt i ng
att ac k on y ou r o nl in e v uln er a bi lit y
s ca n ni n g t oo l < s ca n n in g s y st e m na me >.
Th is ex po ses y ou r us er s to a tt ac ks ,
pos si bly l ead in g to d ata l ea k ag e an d
a cc ou n t ta k eo v er .
A mal ic iou s s er ve r c an a ns w er w it h X SS
pay lo ads i ns tea d of it s st and ar d hea de rs.
Fo r e xample , it c ould a nswe r wi th t hi s
( m in im a l ) H T TP r es p on s e :
< mi nim al P oC f or t he sca nn ing s ys te m >
Si n ce y ou r w eb si t e di s pl ays t hi s dat a in
a re por t , t hi s c ode d is pl ays a p op up on
th e u se r p age , b ut an a tt ac ke r c an
i nc lu de a ny J av aS c ri pt c od e i n i t ,
t ak i ng c o nt r o l o f t he u se r b ro w s er ( s ee
ht t p s : // b e e fp r o je c t . c om / ) , an d h en c e
ma ke th em p e rf or m a ct ion s on y ou r
w eb si t e o r st e al p e rs on a l in f or m at i on .
I att ac hed a s cr e en sho t of t he P oC
r un n in g on y o ur p ag e . Th e P oC is
com plet el y ha rml es s , b oth f or yo ur
web si te an d fo r yo u to tes t.
I al so hos te d a ma l ic iou s ( bu t ha r ml es s )
ser ve r her e if you w an t to r epr od uce t he
is s u e : < te s t st u b n et w o r k ad d re s s >
Yo u ca n per fo rm an y sc an y ou w an t
aga in st it ( pl ea s e le t me k no w if i t is
In a few cases we extended the report with additional de-
tails, requested by some vendors. For example, some of them
asked for the CVSSv3
calculation link and an impact evalu-
ation speciﬁcally referring their scanning system.
A.3 Vendors feedback
Out of the 36 notiﬁcations, we received 12 responses to the
ﬁrst contact message. All the responses arrived within 2 days.
Among the notiﬁed vendors 5 ﬁxed the vulnerability within 10
days. Another vendor informed us that, although they patched
their scanning system, they started a more general investiga-
tion of the vulnerability and our attacker model. This will
result in a major update in the next future. Finally, after ﬁxing
the vulnerability, one of the vendors asked us not to appear in
USENIX Association 23rd International Symposium on Research in Attacks, Intrusions and Defenses 29