Just That Easy: Real World Pen Testing Attack Vectors [Part 1]

By Brad Antoniewicz
Original Report by Tony Lee and Robert Portvliet

Although conferences, news articles, and everyday conversations make attacks on large organizations seem so simple, it may be hard to believe that these things work. The goal of this series of blog posts is to demonstrate the closest thing to getting "real world" without committing a crime.

This is an attack vector of an actual penetration test…

..and although every step was calculated and creativity was used in some areas, the fundamental concepts are all straight out of any hacking book you'd find on the shelf

Information Gathering

Goal: Employee Information

The information gathering phase on this assessment was primarily conducted to gain information about the employees of the organization. The two most valuable resources for us were:

1. Google/LinkedIn - "site:linkedin.com CompanyName"
2. Company's Website

Utilizing these two resources, it took us about a day to learn the organization's business, locations, and build a list of employee names and email addresses that could be used in other attacks later on. Taking time to learn about the organization makes it easier to craft more targeted and believable attacks. Here's just some of what we found:

• Employee Names - LinkedIn returned a good number of employee’s names, job titles, interests, and some email addresses while the company website had just a handful of press related contacts. One particularly useful piece of information was the name of an ex-employee. It was a good ice breaker when we called another employee and helped us build good rapport and trust with the victim employee.
• Email Addresses - Although we initially only identified a small number of valid email addresses, this proved to be enough. From the few we found, it was trivial to deduce the naming convention and apply it to the names found on LinkedIn (e.g. FirstinitialLastname@CompanyName.com.)
• Company Addresses and Phone Numbers - The company had a convenient "location finder" on the website which gave us the phone numbers and addresses for all of their locations.
• Valid Username Combinations - The company's website also had an employee login section which permitted account harvesting via the password reset page. It helped us confirm some employee names and gave us insight into username naming conventions.
  

Social Engineering

Goal: Gain Employee Credentials by directly asking for them (say what?)

To gain more information about the networks, systems, and employees, we picked a handful of users to target. We asked for items of interest such as:

1. Job function
2. Location (City, state)
3. IP Address
4. Host name
5. Windows Domain
6. Domain Controller
7. Username
8. Password

Normally we will not ask a user for their username or password, however the client requested it for year over year tracking purposes. If we must ask for this, we generally try to solicit information with little variation from the order above (as it goes from least intrusive to most intrusive) but, most importantly, we almost never ask for the username/password until the end, unless we have the victim really comfortable. Couple hints:

• Building Trust - The more the victim speaks, the more comfortable they are. Let them talk.
• Script - Build a script. Come up with answers to everything you can think of. Take your time between asking questions, be courteous when asking for it.
• Caller ID Spoofing - Always helps to spoof your Caller ID to be an internal number

Here's an abbreviated version of our script:

1. "Hello, this is (made up name) from the (headofficelocationname) compliance team.” Wait for a response. Often, the user will have an outstanding issue and begin asking about it. This can be very useful for building trust.
• Note: If challenged - "I am completing this task for Heidi Montag in the Information Security Department"
  
2. If the user does not ask for any immediate assistance, say "We're calling to ensure that your PC and user account are in compliance with our guidelines. Do you have a few minutes to help us out?"
• Wait for the victim to respond. If they don't have a few minutes, thank them and move on to the next call.
3. Ask them "Are you in front of your computer?"
• Wait for the person to respond. If they are not, thank them and end the call.
4. Say "Great. Now, have you noticed any problems with your computer lately? For instance, have you had problems logging on? Or has it been especially slow?"
• Wait for the client to respond. Very often there will be something wrong. Ask them to explain any problems. Say that what you are calling about may be related. If there is no issue, simply continue.
5. Say "OK, I'm going to ask you to run a few simple commands and read back the results to me. You are running windows, right?"
• Wait for them to respond to the question. Obviously change the question (and the rest of the test) if they are using a different OS.
6. Say "Fantastic. I'd like to ask you to click on the start button, and then click Run". Wait for confirmation.
7. Say "Ok, now type in the letters C-M-D and press enter." Pause. Say "You should see a console with a blinking cursor." Wait for confirmation.
8. Say "Type in the letters I-P-C-O-N-F-I-G. Ipconfig. Press enter".

--- snip --- You can see where this is leading. We made eight calls over two days. First day all six victims provided everything up to the username, and three actually gave us passwords. Day two we just made two calls, and both targets were somehow tipped off to what we were doing. If you think you have been tipped off, this could be to your advantage… Change the attack to a phone call warning users of a phishing attempt and have them navigate to a special website to ensure that they have not been compromised—afterall safety first! Also remember if someone refuses to give you their password – don’t push since that will cause them to alert someone.

Goal: Enticing Users to a Website

Asking a user to navigate to a website can be a nice and indirect way to have them give you access to their system. For instance, you can have the website present them with a username/password prompt and ask them to log into it, or you can be as aggressive as we were here. We simply put out a Metasploit Java Applet Browser Payload using SET on a domain we registered (test-companyname.com). When the user navigates to the site, they're prompted to accept the applet and it connects back to the handler on our attack system. The social engineering script is pretty similar to the above, however this time we'll introduce ourselves as someone from the web team:

1. Say to the user "Hello, this is (made up name) from the (companyname) web development team.”
• Wait for a response. Often, the user will have an outstanding issue and begin asking about it. This can be very useful for building trust.
2. If the user does not ask for any immediate assistance, say "We're calling to test the web accelerator and we're asking for user's to perform a quick test. Do you have a few minutes?"

After some schmoozing, we can ask them to go our website:

1. Say "OK, I'm going to need you to go to our test our new site. Are you running windows?"
• Wait for them for respond to the question. It should be ok if they are running Linux, Mac, or Windows as long as you have handlers set up for each operating system.
2. Say "Fantastic. I'd like you to open your web browser and surf to: www.test-companyname.com". Wait for confirmation.
3. Say "When you get the pop-up that says RUN or CANCEL, just click run. That is the web accelerator that we have worked so hard on to make your Internet faster”
   
4. Confirm that they have clicked run. “If you see the pop-up again, simply click RUN again. If you don’t get it again the accelerator is installed correctly."
• NOTE: If A/V flags: “Don’t worry about the antivirus, we have worked with Microsoft [the applet states its signed by microsoft] to develop this accelerator and we are currently troubleshooting that issue.”

This technique is highly successful because you are not asking a user for a username or password. You are only asking them for a little bit of their time and to click a few buttons. We only targeted one user with this method and they fell for it (100% success rate!).

Phishing

Goal: Internal Access via Employees

With a pretty decent sized email list pulled together, we created a phish to entice users to connect to our malicious site. The internal mail servers were filtering our spoof @companyname.com messages so we just sent the emails from the test-companyname.com domain which we created. Over the course of 3 days we sent emails out to a number of different users and each day we changed the phish:

1. New Employee Portal - We pretended to be from the web development team and told users about the new employee portal. The link in the email appeared to be one to the normal employee portal, however once clicked, it actually directed users to the test-companyname.com malicious website.
   
   • Target: Everyone Except HR
   • Result: 2 shells
   • Rate: First shell was obtained 4 minutes after the email was sent, Second was 3 hours after
2. Financial Results/Stock Tracker - This time the users were directed to a clone of a company-created stock tracking site where they can get information about the financial status of the company
   
   • Target: Management
   • Result 2 shells
   • Rate: First shell was obtained 13 minutes after the email was sent, Second was about 30 minutes after
3. Locator Clone - We simply cloned the locator page and sent the email out to a select few.
• Target: Everyone
• Result 2 shells
• Rate: First shell was obtained 28 minutes after the email was sent, Second was about 6 hours after

Part 2 of this series will show you how to turn those user level shells into domain admin and what juicy areas of the network to look for confidential information!