Account Brute Force Possible Through IIS Printers Directory Authentication Interface | Support Tips

Account Brute Force Possible Through IIS Printers Directory Authentication Interface

Qualys scanning found a vulnerabilities-“Account Brute Force Possible Through IIS Printers Directory Authentication Interface” as below. I need to do black box testing to verify this vulnerability.

If anybody would be willing to help, it would be greatly appreciated!


A “printers/” directory has been found active on your Microsoft IIS Server and is open to authentication requests.

If the host has an account lockout policy in place, a remote user may use this authentication interface to lockout a local user, provided that the name of the local user is known.

If the host does not have an account lockout policy in place, a remote user may use this authentication interface to brute force user passwords.

Note that Windows user list may sometimes be obtained by exploiting other vulnerabilities. Windows also has a few easy-to-guess default names for built-in accounts: “Administrator” for administering the computer/domain, “Guest” for guest access, “IUSR_” for anonymous access to IIS, “IWAM_” for IIS to start out of process applications, etc. Here the machine name may be obtained via Windows UDP Netbios NS (port 137).

Among the above built-in accounts, the account lockout policy, even if it is in place, does not apply to the administrator account. So if the host uses a default name of “Administrator” for the administrator account, the password brute force of this account is possible through the “Printers” authentication interface.

Run the ‘Internet Services Manager’ under ‘Settings > Control Panel > Administrative Tools > Internet Services Manager’.
In the left pane labeled “Tree”, select “Default Web Site”.
In the right pane, right click on “Printers”, and select “Delete”, which will remove this file directory your IIS installation.

HTTP/1.1 401 Access Denied
Server: Microsoft-IIS/5.0
Date: Fri, 01 Oct 2010 16:07:34 GMT
WWW-Authenticate: Negotiate
WWW-Authenticate: NTLM
Connection: close
Content-Length: 4431
Content-Type: text/html
<html dir=ltr>
a:link {font:8pt/11pt verdana; color:FF0000}
a:visited {font:8pt/11pt verdana; color:#4e4e4e}
<title>You are not authorized to view this page</title>
<META HTTP-EQUIV=”Content-Type” Content=”text-html; charset=Windows-1252″>
function Homepage(){
// in real bits, urls get returned to our script like this:
// res://shdocvw.dll/http_404.htm#
//For testing use DocURL = “res://shdocvw.dll/http_404.htm#”
//this is where the http or https will be, as found by searching for :// but skipping the res://
//this finds the ending slash for the domain server
serverIndex=DocURL.indexOf(“/”,protocolIndex + 3);
//for the href, we need a valid URL to the domain. We search for the # symbol to find the begining
//of the true URL, and add 1 to skip it – this is the BeginURL value. We use serverIndex as the end marker.
//urlresult=DocURL.substring(protocolIndex – 4,serverIndex);
BeginURL=DocURL.indexOf(“#“,1) + 1;
//for display, we need to skip after http://, and go to the next slash
displayresult=DocURL.substring(protocolIndex + 3 ,serverIndex);
InsertElementAnchor(urlresult, displayresult);
function HtmlEncode(text)
return text.replace(/&/g, ‘&amp’).replace(/’/g, ‘”‘).replace(/</g, ‘<‘).replace(/>/g, ‘>’);
function TagAttrib(name, value)
return ‘ ‘+name+’=”‘+HtmlEncode(value)+'”‘;
function PrintTag(tagName, needCloseTag, attrib, inner){
document.write( ‘<‘ +
tagName + attrib + ‘>’ + HtmlEncode(inner) );
if (needCloseTag) document.write( ‘</’ + tagName +’>’ );
function URI(href)
IEVer = window.navigator.appVersion;
IEVer = IEVer.substr( IEVer.indexOf(‘MSIE’) + 5, 3 );
return (IEVer.charAt(1)==’.’ && IEVer >= ‘5.5’) ?
encodeURI(href) :
escape(href).replace(/%3A/g, ‘:’).replace(/%3B/g, ‘;’);
function InsertElementAnchor(href, text)
PrintTag(‘A’, true, TagAttrib(‘HREF’, URI(href)), text);
<body bgcolor=”FFFFFF”>
<table width=”410″ cellpadding=”3″ cellspacing=”5″>
<td align=”left” valign=”middle” width=”360″>
<h1 style=”COLOR:000000; FONT: 13pt/15pt verdana”><!–Problem–>You are not authorized to view this page</h1>
<td width=”400″ colspan=”2″>
<font style=”COLOR:000000; FONT: 8pt/11pt verdana”>You do not have permission to view this directory or page using the credentials you
<td width=”400″ colspan=”2″>
<font style=”COLOR:000000; FONT: 8pt/11pt verdana”>
<hr color=”#C0C0C0″ noshade>
<p>Please try the following:</p>
Vulnerabilities Report page 485
<li>Click the <a href=”javascript:location.reload()”>Refresh</a> button to try again with different credentials.</li>
<li>If you believe you should be able to view this directory or page, please contact the Web site administrator by using the e-mail address or phone
number listed on the
if (!((window.navigator.userAgent.indexOf(“MSIE”) > 0) && (window.navigator.appVersion.charAt(0) == “2”)))
home page.</li>
<h2 style=”font:8pt/11pt verdana; color:000000″>HTTP 401.2 – Unauthorized: Logon failed due to server configuration<br>
Internet Information Services</h2>
<hr color=”#C0C0C0″ noshade>
<p>Technical Information (for support personnel)</p>
This is usually caused by a server-side script not sending the proper WWW-Authenticate h
eader field. Using Active Server Pages scripting this is done by using the <strong>AddHeader</strong> method of the <strong>Response</strong>
object to request that the client use a certain authentication method to access the resource.
<li>More information:<br>
target=”_blank”>Microsoft Support</a>

Leave a Reply

Notice: Undefined index: sfsi_telegram_display in /home/www/ on line 320

Notice: Undefined index: sfsi_vk_display in /home/www/ on line 322

Notice: Undefined index: sfsi_ok_display in /home/www/ on line 324

Notice: Undefined index: sfsi_weibo_display in /home/www/ on line 326

Notice: Undefined index: sfsi_wechat_display in /home/www/ on line 328