(following Part 1)
A big part of the project consisted in testing their new hotel management software. The hotel chain had an internal network connecting all their hotels across the world. The hotel had a custom made ERP/Management/Guest-info software installed that would make reservation handling, employee management, supplies management and other things easier. Given the amount of sensitive information in the system, they wanted to make sure it was secure.
Based on the next to nothing information we had, the whole system was connected to the internet via the hotel VPN. However, based on a little digital recon, some of the hotel's system were connected to the internet directly, such as the email server. MX servers and other basic information are easy to get by combining whois information, DNS requests and other simple networking tricks. Getting to know what is running in those severs takes a little more time, but it's not hard either.
One of the best things to do on the initial digital recon of your target is search for technical information about what software the target uses, what OS (vrsion, etc) is running and ther tidbits of information that will allow you to prepare your attack package. One way we found give us a lot of good intel is to search technical forums for information that the target's IT, network or security guys might have asked. Search for the target's email address - open your favorite search engine, type the @domain part of the email, like @redteams.net, and see what you find. Chances are you will run into technical forums, like Microsoft, Cisco, etc, where those emails appear as part of the post. See what they are asking about, what kind of question about bugs, problems, etc. This will give you an idea about what they are running. At least the initial idea.
Then you can actually reach out and touch their systems. In the case of the email server, try to send an email to an address that you know doesn't exist. Like sdajsdkajsldkajs@target-domain.com. When the cannot deliver email returns to your inbox, check the email's headers. Unless the email server admin or the firewall admin know what he/she are doing, chances are the headers will contain a lot of good information and sometimes, internal IP addresses and other good stuff.
Then check their website. Maybe they are running the web server on their network and it's a possible way in. Use NC (netcat) or other tools to get their HTTP headers. Have they been sanitized? If not, what do they disclose?
All this can be done without any scans. Scans of any type will set alarms. A port mapping done the wrong way will alert a good security team that someone is performing a recon on their turf. A vulnerability scan will send their team into even higher alert, so don't do it. Instead, take your time. Start playing with their different IPs and see what out there, slowly and deliverately.
Anyway, back to the hotel. We discovered that their email server was located on their DMZ, as it should, and that it was poorly configured and it lacked updates, some of them critical. So we decided to play with it. We identified two possible attack vectors: a direct, exploit-based attack on the actual server, and an inderect attack via a social engineering trick. The first one was going to take some research and coding, and the second one a little bit of ingenuity, luck and a good backdoor.
Standby for part 3....