-
Notifications
You must be signed in to change notification settings - Fork 0
Investigating Alerts
The following subpages provide information on how to investigate alerts.
Note: IIS logs in UTC so the Logparser queries will also use UTC.
After reviewing the sub-sections above, the following may be of help.
Some automated scanners will use a unique and descriptive User-Agent string that appears in the IIS Log Field cs(User-Agent). While easily spoofed it can be a quick indicator of unnecessary traffic since legitimate requests will rarely make any changes to this setting.
Identify if a single user is being targeted or if multiple users are being targeted. This will indicate password spraying (single password to many users) vs. brute forcing (many passwords to a single account). IIS log field cs-username is used for logging the client provided username.
Legit vulnerability scanners may trigger these settings. A reverse DNS lookup will often provide this identification by returning something like vulnscan.security.domain.com.
If using either of these authentication methods, take a closer look at the IIS log fields sc-substatus and sc-win32-status as they'll provide more context as to why an HTTP 401 was returned. Note that initial requests will not contain credentials resulting in NULL being logged by IIS in the cs-username field and is a function of how Basic/Windows authentication is initiated.
sc-status & sc-substatus: The HTTP status code in IIS 7.0 and later versions
sc-win32-status: Microsoft System Error Codes
Depending on how the website authenticates users and if logging at a sufficient verbosity, failed logins will be logged to the Windows Event Log on the target web server (IIS log field s-computername) for that request.
Review the timing of requests to determine if they appear to be automated. An actual person shouldn't exceed one failed login every 2-5 seconds.
Check whois to get more information about the IP address. Is it part of a security research group? Perhaps a temporary virtual machine on a cloud hosting provider? etc.
Check IP reputation services to identify whether other attacks have been reported from this IP address. SANS offers a great service. Just place the IP address in the search box at: https://isc.sans.edu/ipinfo.html
While not 100% accurate, getting reliable geolocation data can help build context around the client IP address. MAXMIND has been incredibly accurate.
Consider performing a cross-check of other internal logs for indications of abuse from the IP address. A good place to start would be perimeter flow data and/or firewall logs.