Internal pen test

Viewing 9 reply threads
  • Author
    • #8668

      *Microsoft IIS 7.5*
      *Microsoft Exchange 2007-2008*

      I have had some excellent advice thus far on this forum, so I thought I would seek some help on my next question! 🙂

      I have discovered a couple of services that stand out to me, but wanted some input from you guys. I have checked vulnerability databases and the obvious choice is IIS 7.5 out of the two. However, if you were doing a full penetration test for a client and came across these two applications, what would be your plan of exploitation and how would you fancy you chances of actually being successful?

      Literally any advice would be helpful

    • #53789


      Depends on the rules of engagement, and the type of assessment you are running. Assuming everything is good to go, my first instinct would be IIS. There are at least some vulnerabilities for IIS.

      Of course those could be patched. I don’t hear much about exchange vulnerabilities in general, But I assume they are out there.

    • #53790

      Thank you. I will be reading up on the ones you mentioned, and if I feel confident enough understanding exactly how it can be replicated I’ll have a go

    • #53791

      You’re going to have far more luck going after the applications and not the servers. See what email addresses you can scrape together and try some password guessing attacks on Exchange. See what content the web server is actually hosting and try attacking that. Do some recon and see if you can find valid credentials, run DirBuster to find web server additional content, etc.

    • #53792

      Thank you, I used dirbuster and analysed the results from the 5 different servers I am testing.

      I discovered Tomcat 5.0.28 and also PHP running (PHP appeared to be patched). Whilst running dirbuster it showed a few error 200’s to file locations, but when I try to access them I get ‘you do not have the required permissions etc’.

      In regards to discovering what other applications are running all I could find where default login pages. Web pen testing was never my strong point so struggling where to go next with this.

      Apart from going down the brute forcing route for the login pages I am not sure what else I can go at. There are no other pages on these servers visible. Any advice or pointers?

    • #53793

      Are you working alone or as part of a team?

    • #53794

      On my own with this project

    • #53795

      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). 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: (I’m assuming “archived” means it’s no longer maintained). That service itself might actually be exploitable: 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 ( – 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. 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 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.

    • #53796

      Just a quick update after the extremely helpful reply. I tried dirbuster and also cewl but to no avail. I also tested the web facing login pages for XSS and SQL vulnerabilities in case I missed something obvious. Literally hit a brick wall with this, I’m sure someone with more expertise could probably find a way in, but unfortunately for me I can’t see myself finding a hole.

      One positive however, was the next day post exploitation attempts going into the office and looking at all the firewall logs to see what was being blocked and what was not! So was a good learning curve even if it was not a successful final outcome

    • #53797

      Glad to hear it!

Viewing 9 reply threads
  • You must be logged in to reply to this topic.

Copyright ©2021 Caendra, Inc.

Contact Us

Thoughts, suggestions, issues? Send us an email, and we'll get back to you.


Sign in with Caendra

Forgot password?Sign up

Forgot your details?