Depending on which web application they are using on port 80, 443 and perhaps 8080, (and even alternative ports), try to replicate their setup as much as possible especially including addons. Then begin auditing / pentesting those addons locally and try to locate / find vulnerabilities in those, then if you're permitted, check if they work on the target site.
Furthermore, you can also try to replicate the software they use and fuzz that and hope you may find a 0day within that, simply by fuzzing the hell out of those services in a smart way of course.
Also, check how many vulnerabilities has been previously been found within the products / software and web applications they use, what kind of vulnerabilities are the most common to be found within these, and so forth. Your chances of finding a similar vulnerability is high in case the same type of vulnerability "respawns" within certain versions when new features are implemented.
For instance, Persistent and Non-Persistent Cross-Site Scripting vulnerabilities are quite common to be found within vBulletin, compared to SQL Injection, Local and Remote File Inclusion and especially Remote Code Execution. So if you had to pentest vBulletin, then your best bet would be Cross-Site Scripting.
There's a blog here, about a 0day found within vBulletin recently:
http://www.exploit-db.com/vbulletin-a-journey-into-0day-exploitation/It was found by mistake, while I was doing some voluntary administrative work for another site, and after confirming the vulnerability I used a few days to research and develop a working exploit.
If the target is using custom coded software on their server it is harder to develop an exploit for of course, but if they're using a Web Application, then the possibility of a vulnerability existing is increasing on a major scale. Especially due to insufficient time for the developers to either code secure applications or learn how to do that, and of course, implementation issues
