With a slew of new contestants scouring the Internet collecting data for this years Social-Engineer.Org SECTF at Defcon 19 we thought we would give them a little help. Last years winner, known as phat32, wrote an article about the skills he needed to overcome all the obstacles and become the first ever winner of the Social-Engineer.Org SECTF and the winner of the game changing black badge…..

As the winner of the Social Engineering CTF that was held at Defcon 18, I was asked to write up a little summary of the event from my point of view. Let me start off by telling you about myself. I’m not a professional penetration tester nor do I have any formal social engineering training or experience. I’ve worked in IT for the past 13 years with the last 10 in Infosec. My previous roles have ranged from vendor technical support to security analyst and engineering for MSSP’s. It’s perhaps more important that nearly every job I’ve held since I was 15 has included some customer facing aspect. During that time I’ve learned a lot about how to successfully interact with people (an unintentional yet valuable side effect).

The contest was structured to be a true Capture the Flag challenge. The rules were explicitly spelled out, targets were provided by the judges, and points were based on pre-defined flags of information that you had to obtain during your call. The CTF was also, in many ways, similar to an SE engagement. We had a defined scope with specific objectives to achieve.

The Flags
We received the contest rules, our targets, and the list of flags a few weeks before the contest date. The targets were all high profile, prominent companies and the flags were a mixture of physical, HR, and IT related information with varying point values. As I read through the flags I noted the odd mixture of questions based on the type of information being requested. My first step was to rearrange the flags and group them by type. Consider the following two lists. They contain the same flags but when the flags are rearranged by type, it becomes more obvious how they might lend themselves to a particular attack vector or pretext.

 

Where as before I had a large list of Unsorted flags, after my reorganization I had a list broken into categories like:

  • Facilities/Physical IT Flags
  • HR Flags
  • URL Flag
  • IT Flags
  • Physical Security Flags

This changed the landscape and allowed me to focus my attention on how the flags lent themselves to developing a pretext.

I opted to focus on the IT related flags for a few reasons. They were, as a group, worth the most points but it was also an area I was more comfortable with due to working in IT. Additionally, concentrating on a single type of flag allowed for a more smoothly flowing conversation rather than trying to jump back and forth from physical to HR to IT questions. Part of what makes a pretext convincing to other people is how much you believe it yourself. In becoming this person you’re portraying, you add the emotional filler that’s often missing when someone is just faking it. By focusing on the IT flags, I was able to leverage my own IT experience (good and bad) and present a convincing pretext during my call.

The Research

Now that I had the target and the objectives it was time to get busy with research and information gathering. The rules prohibited us from contacting the target company or it’s employees until the day of the contest so any information I gathered could only come from passive means (Google, social media, job postings, etc.). I started with basic Google searches that combined the target name with keywords from the flags. I give credit to my target company in that they did a good job of keeping much of this information off the basic search level. Ironically, I found a great deal of information about their cafeteria that also provided ancillary details about the option to use their badges to pay for food or have it deducted directly from their paycheck.

Social media was helpful when I found postings from former employees describing their experiences working for the target (good and bad). This type of information is valuable for understanding the corporate culture and how current employees may feel about the company and their work environment. For example, if you see a common theme about harsh working conditions, you can leverage this in your pretext by expressing a similar dissatisfaction with your own employer. Sharing this with an employee of the target presents a common point of emotional experience and commiseration. If you’d like to test this for yourself, start a conversation about your own negative working conditions the next time your with a group of friends and see how many people chime in with their own experiences. After all, it’s a rare thing to find someone that has a perfect job.

Searching the target company’s job postings was another valuable source of information. By reviewing the job postings, I gained a sense of what skill sets they were looking for and subsequently, what type of technology was in use (OS, hardware platforms, etc). For example, a posting for System Administrator with strong skills in Red Hat tells you something about the platform of Linux they work with. This works for learning about applications and even the physical and logical structure of their networks (data center technicians, global sites, stringent uptime requirements, Senior skills needed due to complex routing or specialized equipment, etc.). Here again I have to give credit to my target company. They worded their job descriptions as generically as possible while still communicating the general nature of the job opening. Fortunately I only needed a few pieces of information to sound credible for a 25 minute call. A more in-depth engagement could have been hampered by the lack of details. In this case, the job postings did indicate a need for expertise with specific operating systems. This was one of the flags we were given and while finding it via passive means wouldn’t count for the call, knowing what OS they used would give me credibility when I discussed and verified it during my call.

One aspect that I wanted to focus on was how many of the flags I could find via passive information gathering before my contest call. If you can uncover a high percentage of information without ever directly contacting the target, it not only speaks volumes about how much information the company is leaking, but also makes it that much easier to develop a credible pretext. The more inside information you can provide, the more plausible that you are who you say you are. I documented all the flags I found to demonstrate the point about data leakage.

The preparation work done in this phase outlines some key points for Social Engineering.

First, know your target. Do your research and gain an understanding of who they are and how they operate. Without this knowledge you’re more likely to fail at presenting a pretext that will successfully engage the target without putting them on the defensive.

Second, know yourself. If the only vector you can discern relies on knowledge or experience you’ve never obtained it will be much more challenging to present a convincing pretext that implies credibility. The same is true if you’re too uncomfortable with the pretext. Remember that no matter what pretext you choose, YOU are always a core part of that pretext. If you can’t believe it there’s a good chance the target won’t either.

Last, know your data. You’ve spent the time to research and collect it all, now invest the time needed to understand what you have and how it supports your pretext as well as your objectives.

If you haven’t noticed, there’s an underlying theme to this phase. The research and the objectives are foundational aspects to your pretext development. Building and executing a solid pretext is akin to coding an exploit and it’s imperative that the preparation work supports the pretext. I’ll talk about how this applied to my CTF call in the next article.