SEC504: Hacker Tools, Techniques, and Incident Handling

Experience SANS training through course previews.
Learn MoreLet us help.
Contact usConnect, learn, and share with other cybersecurity professionals
Engage, challenge, and network with fellow CISOs in this exclusive community of security leaders
Become a member for instant access to our free resources.
Sign UpMission-focused cybersecurity training for government, defense, and education
Explore industry-specific programming and customized training solutions
Sponsor a SANS event or research paper
We're here to help.
Contact UsWe have written a ten question exam which will hopefully help you with determining if you are better suited for SEC660 or SEC760.
As you may have heard, we've been adding new content to SANS SEC760: Advanced Exploit Development for Penetration Testers, including Windows 10 updates, heap exploit material, and all new kernal debugging and exploitation sections. The course was written as a follow-on to SEC660: Advanced Penetration Testing, Exploits, and Ethical Hacking, for those wanting more knowledge and experience in exploit development. There has been a lot of growth in this area and many organizations are looking for professionals with this skill set in order to perform threat modeling, bug hunting, determine bug exploitability, and possess the ability to write exploits against applications running on modern operating systems. Even if your current position does not have you spending your days writing exploits, the subject matter covered is very relevant for:
As the authors of the course, we get a lot of questions, including:
We have written a ten question exam which will hopefully help you with determining if you are better suited for SEC660 or SEC760. Remember that this is purely from an exploit development perspective. SEC660 includes two days of material on introduction to exploit development and bypassing exploit mitigation controls. Much of the other material in SEC660 is on a wide range of advanced penetration testing topics such as network device exploitation (routers, switches, NAC), pentesting cryptographic implementations, fuzzing, Python, network booting attacks, escaping Linux and Windows restricted environments, etc...
Please take the exam without any help. Do not use Google or other search engines to look up answers, ask a peer, or seek the answers by any means other than using your brain and experience. The answers along with explanations are also available in a separate link below. See how you measure up!
You can use the following as a rough guide based on the number of correct answers you achieve on your test.
Good luck with the quiz, and see you in SEC760!
Thanks!
--Jaime Geiger & Stephen Sims
a. Memory leak b. Stack smash c. Control Flow Guard d. JOP
a. Memory Standard Resource b. Model Specific Register c. Memory-Synchronized Range d. Mandatory System Routine
label: pop rax sub rax, 5
a. Making a system call b. Turning off DEP c. Subverting control flow guard d. Getting the current execution address
a. \xff\xc0\x48\x89\xd8\x48\x31\xf6\xcc\xcd\xc2\xcc b. \xb6\x2d\x1d\x00\x41\x89\xd8\xff\xc3\x31\xc0 c. \x48\x31\xf6\x48\x89\x43\x08\xb3\xc3\x0f\x05 d. \x0f\x85\xed\x00\xb6\x47\x18\xbb\xc2\x74\x36
a. unsigned char *mem = malloc(2); memcpy(mem, userbuffer, 4); b. RtlCopyMemory(buf, userbuf, userlen); c. char *str = malloc(stringsize); strncpy(str, userbuffer, stringsize); d. int len = sprintf(NULL, "fmt %s", userstr); char *str = malloc(len+1); sprintf(str, "fmt %s", userstr);
a. When the size of the data is not known at compile time b. When the data must outlive the current function c. When the data is larger than 1 page d. When the data is sensitive
a. Mutator b. Generator c. Executor d. These are all fuzzer components
a. Repair the canary b. Cause an exception before the canary is checked c. Use a ROP chain to avoid the canary all together d. Jump to or call an indirect function pointer you control
a. Hardware and software breakpoints can only be triggered on code execution b. Hardware breakpoints cannot be removed with code, while software breakpoints can c. Hardware breakpoints are set in registers, while software breakpoints are set by overwriting instructions d. An unlimited number of hardware breakpoints can be set, while only a limited number of software breakpoints can be set
Jaime Geiger is an experienced forward and reverse engineer with a passion for teaching. He currently works in the DC area, where he perfects software design and implementation, reverse engineering, exploit development, and network administration.
Read more about Jaime Geiger