Echo TRACK / HTP/1.0 |nc –vv <target> <port> followed by two CRLF pairs

That’s it:


The HTTP protocol consists of requests and responses. Requests are
sent from the clients (browsers) and they always start with a certain
keyword (verb). The most common request is a "GET" request, but there
are many more of these verbs, all of them are well documented within
the RFCs. But one of these verbs that Microsoft uses is not: it's the
"TRACK" request. The TRACK request returns the original request as an
entity (with a content-type of "message/http" and the returned body
contains your original request), just like a TRACE request. The TRACE
request is RFC compliant and well documented, the TRACK request is
not RFC compliant and not documented (only one page mentions this verb
in the MSDN library with no explanation).


Making an HTTP request with the verb TRACK is not being logged. This
makes it quite critical because it can be used to produce a lot of
traffic and to get the 'Server' header and other valuable information.
Furthermore because the TRACK request is the same as a TRACE request,
all known problems with TRACE requests also apply for this verb.
The most important issue with a TRACE request is cross-site
tracing (XST): a malicious web page or e-mail can send a TRACE/TRACK
request to another website (by using client side scripting) and by
analysing the response it can have access to your credentials and
your cookies on that site (think: session hijacking, passwords,...).
All unpatched and future exploits that work with a TRACE request,
should also work with the TRACK request but this time without being
logged, making it ideal for probing vulnerable IIS systems.

IIS 6 is not vulnerable. The IIS team probably found the bug and
removed it silently and didn't care about patching previous
versions of IIS because that's not part of their Trustworthy
Computing Initiative.