Sometimes engagements are scoped in a manner that result in a very small attack surface. This is frequently the case with small external engagements that do not allow authenticated testing or social engineering. You're not doing a poor job just because you don't have a Microsoft 0-day or can't get past a login page.
That said, there are still some other things you can do:
See if the manager functionality is accessible for Tomcat. That's sometime configured with weak credentials (i.e. admin/admin, tomcat/admin, tomcat/tomcat), etc. It's also another target for advanced password-guessing attacks. This can be significant because you can upload your own WAR file to get a web shell. This service is often running as SYSTEM on Windows, and I have also seen it as root on *nix systems (though I do not believe this is the default configuration).
There is a Metasploit module that will automate this if you have valid manager credentials, but I think AV will often snag the WAR they use nowadays. There are tons of other web shells floating around, and it's trivial to install these in Tomcat manually (just "deploy new" and select your WAR). http://laudanum.inguardians.com/
is a great collection, though I have had that fail occasionally as well. Again, possibly because of AV. You can find another one or just make your own. WARs are essentially just zipped JSP, and you can make a custom JSP shell and turn it into a WAR with just a few Google queries.
Additionally, that's a very old version of Tomcat: http://tomcat.apache.org/whichversion.html
(I'm assuming "archived" means it's no longer maintained). That service itself might actually be exploitable: http://www.exploit-db.com/search/?actio ... ion=tomcat
Even if you don't get anywhere with this, you should note that they're not properly keeping their perimeter services on supported platforms or patching them. Version 5 went into 5.5.x, so 5.0.28 is really old even for v5 itself.
It depends on how the engagement was scoped, but you could ask for a basic user account to poke around the web application(s) from an authenticated perspective. That will open the doors for you significantly.
If not, your options basically come down to circumventing the login/authentication mechanism or finding content you can directly access without authenticating. You could try using tailored wordlists with DirBuster. Use cewl (http://www.digininja.org/projects/cewl.php
- also in Kali) to scrape the company website and/or product/service page to make a custom wordlist, which may be more successful in identifying content than generic ones.
Try different extensions as well. Don't just go with php because it's running PHP. Try txt, html, bak, old, zip, etc. https://github.com/digination/dirbuster ... /wordlists
is a good resource for this. Check out all of them, but mutations_common.txt is the one that contains various extensions that might be worthwhile (also checkout vunls > tomcat for the server itself).
More often than not, this won't go anywhere, but you can also get really lucky with it. index.php.old might render as text and give you some insight into the login mechanism or other functionality, and backup.zip would likely be a huge win as well. We've found huge dumps of SSNs with just the txt check before. Remember that each extension is another pass through your wordlist, so you need to be a lot smarter with that. Even the medium wordlist will take forever, so you have to customize this, or you'll never get through all the extensions you specify.
Targeting specific directories will also help you make the most of your time. I’d hit something like /backup/ really hard while not wasting my time iterating through /docs/, /docs/en/, /docs/es/, /docs/jp/, etc. Don’t waste time doing something like fuzzing the web server’s documentation contents.
As I mentioned before, you don't have much of an attack web surface with just a login page, but that also makes it imperative that you don't miss anything obvious. You're never going to identify every issue when assessing a large application, but it would be extremely embarrassing if you miss SQLi auth bypass on a login form.
SQLi is the obvious attack vector here. Try some manual attempts and see if anything jumps out at you, and try using sqlmap to identify some less-obvious issues. Also load up Burp and take a look at the requests and responses that are going back-and-forth. Make sure you can't do something like bypass authentication simply by changing loggedin=0 to 1.
Does the login functionality disclose any information? Does it provide differential responses based on whether the username is valid? Try usernames based on what you've gather from recon as well as common ones like admin, administrator, test, etc. Are the responses the same or different compared to a username you made by just mashing on the keyboard?
If you can identify a difference anyway (maybe as little as "Invalid username or password" and "Invalid username or password."), you can enumerate valid users. Also check password reset functionality. Sometimes they properly provide a generic error message for failed logins, but you may find the password reset functionality will tell you whether or not the account is valid (as opposed to simply stating something like "An email has been sent to the address on file for that account" regardless of the account validity).
Also test for controls that throttle or limit automated password guessing attacks. Do you get a 5 minute delay or a CAPTCHA after a certain number of invalid logins, or can you pound on them all day? If there is some mitigating functionality in place, does it work by source IP or the username? Maybe they'll temporarily lock an account after a certain number of failures, but what happens if you iterate through users for each password instead of iterating through passwords for a single user. If there isn't any mitigating functionality, did anyone notice an enormous amount of failed logins in whatever logging/SIEM solution they have, or is no one really looking at that information?
Even if you don't get in, identifying areas where they could improve will help you add value to the report. These types of engagements can be extremely boring, but at the same time, I've never been unable to at least make a few recommendations.
The day you stop learning is the day you start becoming obsolete.