It is common to be faced with a web application where you have no credentials to log in. Very often, the application contains a wealth of functionality that can be accessed without authentication and which you can start working on to find a way in. Typically, the most promising initial targets are the more peripheral functions supporting the authentication logic, like user registration, password change and account recovery.
But occasionally you will face a narrower challenge. Suppose the web root of the server returns a simple login form, with no other functions and no links anywhere else. You can try to guess a username and password, but is that all?
Here are just a few of the things to think about in this restricted situation:
Looking for names, email addresses and other information in the HTML source.
Fingerprinting the web server software, application platform and any other identifiable technologies in use, and researching these for vulnerabilities.
Enumerating the content that is currently hidden, by brute forcing file and directory names, running Nikto, etc., and checking whether the content discovered is properly access controlled.
Checking search engines and Internet archives for references to the target.
Tampering with any hidden parameters and cookies in the login request that may affect server-side logic.
Checking for any disabled form elements that may still be processed if you re-enable them.
Adding common debug parameters (like test=true) to your request.
Inspecting the ASP.NET ViewState (if present).
Testing for username enumeration via informative failed login messages or other differences.
Testing susceptibility to brute force attacks.
If the application issues session tokens prior to login, testing these for predictability.
Testing all request parameters and headers for common code-level flaws like SQL injection, XSS, script inclusion, etc.
Probing for logic flaws within the login function, by omitting parameters, interfering with the request sequence if multi-stage, etc.
If the application is hosted in a shared environment, looking for co-hosted applications that you may be able to leverage to attack your target.
Any one of these attacks might give you a sufficient foot in the door to get past the login and into the protected functionality behind it. If they do not, then the login mechanism is a lot more robust than most are, and it is probably time to try to get hold of credentials, or move on to another target.