Skip to content

Latest commit

 

History

History
70 lines (39 loc) · 7.4 KB

Pentester_Interview_Process.md

File metadata and controls

70 lines (39 loc) · 7.4 KB

Pentester Interview Process

Previously I've interviewed for many Penetration Testing positions and gained tremendous insight into the process. I'm still determining if my process experience reflects how all companies assess a candidate, but the information I got was valuable. I will share information about the process but not reveal the companies or any in-depth details.

I think describing my level of experience will aid this article greatly:

I worked in Information Technology for roughly 7+ years before my first penetration testing interview. My experience in systems administration helped me grow my knowledge of business technologies, networking, and security. I became interested in penetration testing as a career in 2012 as I continued my Information Technology career. Before working in Information Technology, I had previous experience with C, secure coding, and a tiny bit of exploit development. I did a significant amount of independent coursework, including setting up labs, doing CTFs, and working on vulnerable VM's.

Starting the process

I will describe one company where they did an excellent job interviewing. The process began with a hands-on skills challenge created to evaluate how you think and assess your capabilities.

Section #1 Hands-on challenge

Web application assessment:

  • Analyzing the functionality of a web form
  • Javascript source code review

This section involved reviewing a web form's functionality and discovering what information would allow you to proceed past this form. You can piece this together by following the instructions and reviewing all linked files and their functions. The takeaway is that you should study everything available to you.

Working with shellcode:

  • Decoding a string
  • Working with shellcode
  • Using a debugger

This section involved decoding an encoded string, then working with the remaining shellcode. Knowledge of assembly may be necessary to have completed this challenge, including the ability to work with a debugger. You can accomplish this with research, but I recommend prior practice in this area.

Section #2 The write-up

This section involved a write-up of the steps in completing the challenge. Since this had a 2-page max, I decided only to detail my progress. I saved space by referencing photos in an appendix section. I write technical documentation with the reader in mind by walking someone through my thought process, so they understand how to duplicate my steps easily. This exercise was critical because articulating your steps and progress is crucial in penetration testing.

Section #3 Scripting challenges

This section involved three scripting challenges that varied in difficulty, and you can complete them in your scripting language of choice. I chose to use Python because this is the language I currently use for most penetration testing tasks. This challenge was a way to filter out candidates without fundamental scripting skills but also a way of seeing how you think and piece code together. Knowing at least one scripting language to build small tools and automate tasks is essential to being a penetration tester. This skill can also help you stand out amongst other candidates.

Section #4 Penetration testing report challenge

This section involved reading a vulnerability description and writing a report to present to a customer. This exercise tested how you deliver technical information to a customer and your ability to give security recommendations. To address the weakness, you must accurately describe the vulnerability, attack vectors, business impact and provide guidance. Many examples of penetration testing reports are available, and I recommend reviewing a few before starting any hiring process. I remember one other case where I was at a meetup asking people about hiring, and one of the first things they brought up was the writing of penetration testing reports. The takeaway is that the product the customer buys is the penetration testing report, so you should be good at writing them.

Technical interview

I then moved on to an over-the-phone technical interview. The required knowledge here will vary depending on the level of penetration tester the company plans to hire. In my particular instance, they asked about one part of a penetration test, and what tools I would use to perform the actions they specified. Understanding all stages of a penetration test is helpful here; prior experience can help you immensely.

Interview questions

I was asked many questions during the process, but I wanted to highlight a few of them that occur frequently:

If you had the scope and IP addresses for an external/internal penetration test/assessment, how would you start?

Regardless of the level you're currently at, they are interested in knowing how you would begin a penetration test. This question was asked of me multiple times during the process. Have a good understanding of scanning and enumerating targets before interviewing.

What tools would you run to scan/recon a network? What ports would you check? What commands would you execute?

If you have ever run nmap or any scanning tool, this question should be easy to answer. The interviewer also asked about which ports I would scan for quicker recon. I said 21(ftp), 22(ssh), 23(telnet), 80(http), 139(netbios), 445(smb), 3389(RDP), 1433(mssql), 3306(mysql), 5432(PostgreSQL). I also mentioned starting a vulnerability scan and then moving on to manual recon.

How would you perform privilege escalation on a Windows desktop?

The interviewer asked about the privilege escalation stage of a penetration test. However, I would expect that you may be asked questions about any stage of a penetration test during an interview.

How does a buffer overflow attack work?

Buffer overflow attacks seem to be an entry-level concept among the community, and learning them is a "right of passage." Although vulnerable code allowing you to perform this attack is rarely found in code nowadays, it is a great starting point for learning exploit development.

Do you have a blog? A GitHub? or projects?

Having a public presence holds weight with potential employers. I recommend that anybody working professionally or hoping to get into security has somewhere to post content, code, or projects. Public content will enable you to display technical writing skills and a passion for security. I would also recommend getting involved in coding projects and building small useful penetration testing scripts. Additionally, the interviewer asked about projects in general and how I chose to spend my free time.

Conclusion

After completing the interview process, I felt very fulfilled that I better understood the overall steps involved in getting a penetration testing job. Completing all the challenges gave me direction on what topics to study and solidified some of my ideas about my skill set and knowledge. I'm sure different companies have different processes, but you can expect to do some hands-on lab/challenge and conduct several technical interviews. Also, the interviewers mentioned the OSCP throughout the entire process. If you can obtain this certification on your own time, this would give you a significant advantage.

I hope this article can give you some insight into what it takes to get through the hiring process to become a penetration tester. One big takeaway is don't bullshit; passion can go a long way. My love for security was well regarded, and I was very proud of my time trying to chisel myself into a worthy hire.