Red Team Penetration Testing – Anything Goes (Part 1 of 3)

Penetration testing is a valuable part of a security program. At Anitian, we offer a wide array of penetration tests: internal, external, social engineering, web application, API testing, and so forth. Typically, clients hire us for one or two of these tests. On their own, these tests can provide insight into the security of a particular system or application.

However, when you want to test an entire security program, nothing compares to a red team penetration test. This is the closest we get to being full black hats… And it’s really fun.

In this three-part series, I will chronicle a recent red team engagement Anitian completed. In just under 13 hours, we went from minimal information about the client to complete and total compromise of the entire environment. The client is a large corporation with a sizable security program. For purposes of this blog, we will call them Victim Corp.

The Game is On

In a red team penetration test, (almost) anything goes. While the client may determine some basic ground rules, like no denial of service attacks, the entire palette of attacks is available to us: systems, networks, applications, social engineering, etc. When we begin these tests, we typically know nothing about their security program. We must research the client and learn as much about their operations as possible, just like a real attacker does.

Once the client approves our basic technique and scope, the game is on. We might attack external servers, looking for outdated software and services we can exploit. Maybe we’ll find some applications with default or weak passwords. If we find custom web applications, we can attack those too, looking for any weakness that may gain us control over the web server. If all of that fails, we can turn to social engineering. We will attempt to trick your employees into handing over their passwords via email or telephone. We might email them malware in an attempt to gain access to their workstations. Then, once we get in, we can pivot and attack anything we can find in order to gain the keys to the kingdom. Often times this means we are after domain administrator credentials.

Now, Shall We Begin?

I spent hours poking at Victim’s external systems. They patched systems diligently. There were no obvious exploitable vulnerabilities on any of the perimeter systems. I tried dictionary attacks against some of these systems and services with no success. I found numerous web services and spent time investigating them. There was nothing in these tiny services.

I uncovered several remote access points including a Citrix VPN gateway, a Cisco VPN gateway, several webmail servers, and a VMWare Horizon View portal. Victim Corp was smart and had account lockout policies configured, so I couldn’t brute force employee passwords. Every six failed attempts, the account would lockout for at least 15 minutes.

They were not making this easy. So, like any good hacker, I pivoted to the consistently weakest link: people.

The First Try – Fakemail

One of the goals of any red team test is to fly below the radar. Most of the client’s employees have no idea that the test is happening. We do not want to raise any alarms within the organization. This is a real-time simulation. We need everybody to operate normally. As such, I wanted to limit my contact with employees.

I began with two small email phishing campaigns. I set up a fake webmail website that was a clone of Victim Corp’s Outlook Web Access portal. Then I designed two different email ruses in an attempt to trick employees into logging into my fake webmail site.

The first email was designed to trick help desk employees, who I assumed might have more privileges than the average user.

This second email was designed to be sent to non-IT employees. The intent was that they would log into the “webmail” system some time during the “maintenance window” and we could capture their credentials.

After waiting the better part of a day, I had nothing. No clicks, no credentials, nothing. Maybe the spam filter caught my emails or the employees were just too savvy. It was obvious that this company had a good security program. It was time for drastic measures.

Research the Victim

I spent the better part of a day doing extensive online research of Victim Corp. I identified over 325 potential employee names and email addresses. I also obtained external phone numbers for many of these employees using publicly available resources.

That night, I called a few of these phone numbers to validate my information. I got numerous voicemail recordings. With this information, I was able to determine the company’s main phone number area code and prefix. For Victim Corp, we can say it was 555-111-xxxx.

Along the way, I also discovered the internal help desk phone number. Like all large companies, Victim Corp had a line for employees to call when they had computer problems.

Yes, I began wringing my hands and cackling at this moment. The plan was coming together.

The Second Try – Hack the Human

Good plans are devious, great ones are simple. I went for something simple:

1. Call Victim Corp’s help desk line.
2. Pretend to be an employee.
3. Try to get a password reset over the phone.

If this worked, I was in. If it did not, I might set off the alarms and blow the whole test. I needed to do this carefully. Where to begin?

Who Can I Be Now?

First I needed to find an employee to impersonate. I had a list of over 325 possible employee names and email addresses. Which one should I choose?

I dug through my own personal emails, looking for some generic sales email that I completely ignored. Aha! This one looks good.

It was for some webinar. Would you have clicked on that? Would you even give it a second thought? I barely remember receiving it. The email was generic and boring with just enough tech buzz words to feel normal. Nobody would pay attention to this. Which means it was perfect for my ruse.

I signed up for a free email account with an address that sounded like the webinar organizer. Then I used the Social Engineering Toolkit to blast a copy of that webinar invitation to all 325+ emails I collected for Victim Corp.

Then I waited. Within a few hours, I had what I wanted.

I had received 22 emails with the subject line “Automatic reply.” Each of those employees had nicely told me they were out of the office. Thanks! They might as well have replied “I am on vacation and will never notice anything is wrong! Use me to hack the company.” Some employees even offered up the specific days they would be gone as well as alternate employee contacts, manager names, and alternate contact phone numbers. All useful information.

Now, which employee should I choose to impersonate? Being a guy, it made sense to impersonate a male employee.

I began with the first man on the list, we can call him “John Doe.” I looked him up on LinkedIn and sure enough, he had an up to date profile: “Risk Manager for Victim Corp.” I checked my data and I also had his phone number.

Zing! This was perfect. I relished the irony of using the corporate risk manager to hack the very company he is protecting.

I dialed the number. The phone rang several times before going to voicemail. Looks like he really is out of the office. I hoped he would have a customized message rather than just a generic robotic voice.

“Hi, this is John. I’m away from my desk at the moment. Please leave me a message and I’ll return your call as soon as I can. Thanks.”

Perfect! I hung up and re-dialed John’s number. The voice mail picked up again. I listened to his voice carefully. I called back a third time. This time I started repeating his message out loud to myself. I called several more times, each time attempting to match John’s voice as closely as possible. I did not know if the service desk would be familiar with John, but I could not take the chance that they would be able to identify that my voice was not his. Once I felt confident that I could impersonate John, it was time to execute the hack.

I browsed to Victim Corp’s remote Citrix access portal and typed in John’s username, “john doe”. I made up some random password and hit enter: “invalid username or password.” Of course. I repeated my fake login five more times until I received the message, “Your account is locked out.”

The stage is set.

Action! Hack the Help Desk

I reconfigured my phone to appear as a four-digit number on caller ID. We use a well known cloud-based VOIP service at Anitian and it is easy to reconfigure the Caller ID.

I didn’t know if Victim Corp’s help desk would even see this, but I figured if I appeared to be calling from an internal extension, I would have a higher chance for success. With my heart racing, I picked up the phone and dialed the help desk phone number.

A male voice answered.

Victim Corp: “Victim Corp help desk. How can I help you?”

Me: “Hi, this is John Doe. I think my account is locked, can you unlock it for me?”

Victim Corp: “Let me check on that for you.”

Me: “Thanks. My user name is johndoe.”

I offered up the username to make it sound more legitimate. I knew my account was really locked, which would also help sell the ruse. After a minute or so of waiting, he replied.

Victim Corp: “OK I unlocked it for you. Go ahead and try it now.”

Me: “Thanks, let me give it a shot.”

I knew it wasn’t going to work. I didn’t know the password! I typed in some random letters loudly, so the employee could hear it over the phone. Of course it didn’t work. I tried again and again. With each attempt I typed slower and more deliberately, as if I was really trying hard to get it right. After six failed attempts, the account locked out again.

Me: “I’m sorry, I think it locked me out again.”

Victim Corp: “OK hold on.”

Me: “I just reset that password too…”

I said this to make it seem to him that I must have just reset my password and then forgotten it and the only option would be to reset it. This way I wouldn’t have to specifically ask him to reset it.

Victim Corp: “Well, I can reset it for you if you want.”

Oh, be still my heart. Was this really going to work? On the first try!

Me: “*Sigh* Yeah, OK I think we’re going to have to do that.”

Victim Corp: “One moment.”

I waited with anticipation.

Victim Corp: “Try Password1 with a capital P.”

I went back to my Citrix login and tried the new password. It worked!

Me: “Ah there we go. I’m in now. Thanks so much for your help!”

Victim Corp: “No problem. Have a nice day.”

<Click>

I stared at the phone.

Me: “Oh, I will. MUAHAHAHAHAA!”

Not So Fast There, John

Now that I was logged into the Citrix portal, what applications can a Risk Manager access? I waited for the Citrix portal to load and… Nothing!

Noooooooo. Not after all this work. There were no published applications for my user! I searched around the portal and there was nothing there for me to use.

Okay, I cannot give up now.  Time for plan B, or maybe it was plan Z at this point. I had compiled a list of all the Victim Corp URLs I found that offered up some form of remote access. The next one on my list was a VMWare Horizon View portal. I visited the URL and typed in my password. Maybe John Doe has access to something here?

Hmm, this looks promising. A single Windows PC was listed. I believe I will click on that.

WOOT! I now had access to a Windows 7 virtual machine on the internal network and I was logged in as the Risk Manager for Victim Corp. So many doors were now opened. I spent the next 13 hours of hacking away nonstop. Ultimately, I would gain root to this entire company.

Stay tuned for Part Two of this series. I will outline how I went from a single user account to having complete Domain Administrator access of Victim Corp’s network in a mere 13 hours. In Part Three, I will discuss the benefits of red team testing and also describe when red team testing is most appropriate for an organization.