Just like the CPSA, the CCT-ACE is under both the Code of Ethics , and has an NDA which covers the specific content, questions present, and the overall structure of the exam. As such, this post is NOT about the actual content or structure. It is merely my experience with the examination process, and the Technical syllabus. A copy of the notes for candidates covering the exam type, question examples and such is available from here and the technical syllabus is available here. These two documents should be the starting point for any study towards the certification.
Please check the CCT-ACE Page on the crest website for the most up to date version of the notes for candidates and the Technical Syllabus. If anything on this page is deemed against the Code of Ethics or the Non Disclosure agreement or section 1.2 of the notes for candidates then please contact me and so we can discuss what needs removing.
- TL;DR: An intense exam covering all the technical syllabus, extremely tight on time (even after the changes to how the exam is done!), but with a good selection of questions in both difficulty and tech know-how.
So what is the CCT and who should take it? The CREST Certified Tester exams sits third in line in the exam path, aiming to confirm a mid to high level of technical ability when assessing client web applications, and client infrastructure. It sits above the CRT exam and takes a more specialist approach to your chosen exam path. The Infrastructure path is aimed at common client configurations, whereas the ACE exam looks at a whole host of web application flaws. CREST recommend that you should have 5 years testing experience before attempting the exams, and although you do not need the CPSA/CRT to take these exams, given the cost of the CCT, I would recommend starting out with them to act as a form of orientation to the examination method so you do not get hit by any nasty surprises. The exams also grant CHECK Team Leader status, a requirement for the CHECK testing scheme for HMG and Public Sector networks.
The exam is now split into two sections. First, a multiple choice exam which takes place at a Pearson Vue Centre, and second, the practical examination. The new format means that there is more time in the second half of the exam, and if you are able to pass the multi-choice section of the exam, you are able to have three attempts at the practical, saving a bit of money (Although you should be looking to pass the first time around!). The first section is only 150 questions and is closed book. Not much to say about this as you will either know the topics as highlighted in the syllabus, or you won't. The second section consists of a number of questions, as well as one "Scenario Question", previously known as the dreaded long-form answer. The notes for candidates and the technical syllabi highlight the areas that will be examined.
I have a personal preference for testing Web Applications and find that there is a much wider availability of training, write-ups, and logic around them. Starting off, I grabbed a copy of the syllabus, stated working notes on the areas to which I believe the questions and the machines would focus on. Done on a ReMarkable E-Ink Tablet, I have no problem plugging it as it was a huge help during my studies! Its an A4 sized e-reader with a 'pen', allowing you to annotate documents. Easy and simple to use, great battery life, and, handles large PDFs and tech books with ease. Even better, the remarkable exposes the ability to gain root access over SSH, making it super customisable.
CREST sticks with the syllabus style for the CCT exams, and it works pretty well. The exams work as proficiency and skills tests, and as such, no training is provided through CREST. Accredited training courses are available, but I have not attended any so can not comment on the quality of them. The syllabus has 10 sections, and just as other exams, there is a cross-over between this, CISSP and OSCE, so if you have done any of those before then you may have an upper hand in this exam.
|Soft Skills and Assessment Management||This first section tests you on all the 'aside' things that you may not deal with every day. Looking at laws and compliance, risk, project structure and also reporting. As this does not really differ from normal report writing, and sections of the CPSA and CRT, there should not be much to revise in this section.||Looking at your record keeping, make sure you can make coherent notes and can follow the instructions on the exam paper.|
|Core Technical Skills||This again should come simply to any tester, can you use your scanner of choice effectively, interpret and understand the output, and use this information to make informed decisions about the security of a system.||This section has two areas flagged for assessment, target mapping was assumed to mean banner grabbing, and OS fingerprinting. For cryptography, looking at common encryption methods, password hashing, crypt weaknesses, and padding oracle attacks were revised.|
|Background Information Gathering & Open Source||Effectively looking at some basic OSINT, most of the items in this section simply cannot be tested on the exam as there is no network connection.||One area flagged for testing in this section, Customer Site Analysis. This was taken to mean, searching for comments within the page source, generating word lists based on the site, and, inferring information and logic based on what is displayed. As such, not much to revise for this section either if you are familiar with burp suite!|
|Networking Equipment||Looking at common client LAN networks, mostly common networking knowledge, with a few things you may not come across as often such as 802.1X, routing, and switching protocols.||This is all paper revision for the ACE exam.|
|Microsoft Windows||Looking to the Windows ecosystem, common exploits, weakness, and knowledge of how domains work. Technet is your friend for this section if you have not acted as a Sysadmin on a Domain before. Most points on this section are aimed at the Infra exam.||One row is highlighted, passwords. I guessed this would be either post exploitation hashdump and crack, or methods of eliciting a NetNTLM hash such as; use of XP_DIRTREE and alike. forcing the mount of a remote share, and embed UNC path in a web page.|
|Unix Security||Another Section aimed at the CCT Infra, do you know headline vulnerabilities, password storage ($1$2$5$6), common Unix server software, user enumeration and remote management? If you have done OSCP, you should be OK here.||Not a single P in this section suggests that Unix boxes will not even appear in the exam. A bit odd given how prevalent they are.|
|Web Technologies||A look at the underlying infrastructure of web applications and the platforms that they are hosted on.||A number of tools will be needed for this section but nothing your normal testing laptop should not have, an up-to-date ExploitDB, MSF, SOAPUI, 32+64 bit Wine, lots of random git projects, and write up of high severity named vulnerabilities.|
|Web Testing Methodologies||Looking at the theory and cause of vulnerabilities. Auditing and pulling information from pages, logical issues and the write-ups associated with issues found.||Mainly looking at the audit of applications, some pre-prepared write-ups may help here. Better however, would be to have a good understanding of all the OWASP top findings.|
|Web Testing Techniques||The main section of the exam, can you test web applications, do you know OWASP like the back of your hand, have you absorbed every bit of information from the Hackers Handbook Series, and have you played at a few CTF's? If so that is a good start.||Tools to help you work effectively are important here, working quickly and accurately is very important for the exam, and you do not want to be trying to remember what flags do what. Also, remember you do not have to use tools to do everything, sometimes doing things by hand is quicker and easier.|
|Databases||The backbone of any good application, knowing how to exploit and shell them is a vital skill. Knowlege of exploiting SQL injections, database security testing, and the methods by which you will be able to execute code on the remote server.||SqlMap is a basic requirement, much better to have an understanding of SQL, the variances between the languages (sleep, wait, pg_sleep), and what functions can be used on the server.|
The first dedicated web section assesses the technologies and frameworks which support web applications. Sections 2 and 8 are looking at off the shelf servers such as IIS and Apache, and as such it was assumed that off the shelf vulnerabilities would be tested under these questions. Things such as overflows present in the software stack itself and weaknesses in their configuration. For these, I assumed the requirement for a vulnerability scanner, and up to date copies of Metasploit and the local Exploit DataBase by Offensive Security.
Section 4 covers web protocols, methods and headers. For SOAP, one option is using SoapUI to generate valid test cases, and highlight data input, and then use BurpSuite to fuzz and attack the service. SoapUI requires the service description which can usually be discovered by checking out the WSDL (example.com/soap.svc?wsdl or sometimes example.com/soap.svc?singlewsdl) or by using the discovery URL which usually points to the WSDL (example.com/soap.svc?disco). It is interesting how REST is not mentioned for testing. Web methods could be the enumeration and use of the PUT method. First, issue a OPTIONS request and see what you can do.
Section 4 covers web protocols, methods and headers. For SOAP, one option is using SoapUI to generate valid test cases and highlight data input, and then use BurpSuite to fuzz and attack the service. SoapUI requires the service description which can usually be discovered by checking out the WSDL (example.com/soap.svc?wsdl or sometimes example.com/soap.svc?singlewsdl) or by using the discovery URL which usually points to the WSDL (example.com/soap.svc?disco). It is interesting how REST is not mentioned for testing. Web methods could be the enumeration and use of the PUT method. First, issue a OPTIONS request and see what you can do.
Web Testing Methodology
Next up, we have web testing methodologies. Sections 3 and 12 gathering information from mark up and source code is relatively straightforward. Word lists can be created using CEWL, and the page can be examined for anything which is not displayed to the user such as comments, hidden fields, or static values which are passed with forms. Included CSS and JS pages should also be checked for includes from other servers or 'private' directories or API endpoints, and anything which looks like a 'standard' web library such as jquery should be checked for any added functions. It also looks at source code analysis which could mean gaining access to the source of an application through an LFI to gain access to the source and then find another vulnerability within it.
Sections 4 and 5 looks at Authentication and Authorisation. Both reference 'common pitfalls', so it is assumed that it will be nothing more than IDOR, weak passwords, or exposed authentication tokens. It could be either through SQL injection, or weaknesses in session handling such as guessable session tokens, weak use of random number generation, weaknesses in password resets, or padding oracle attacks on session tokens. Session Fixation attacks could also be required which would chain with the XSS questions present on the Syllabus, helping cover of I4 and I11, using an injected page through a proxy to serve up a known session.
H6 and H7 cover just basic fuzzing and validation, such as bypassing a client-side control, expected to be most likely in support of either XSS, SQLi or RCE, which would then cover off 9 and 10. Here I do not see anything more than just standard BurpSuite usage, while also covering I5 and I6. A local instance of Burp Collaborator was also configured to use the advanced blind and host interaction tests.
Web Testing Techniques
The main chunk of the exam, looking at finding and exploiting web application flaws. Skipping over I1 which was covered above, I2 Cross Site Scripting. Having pre-made templates to steal the user's session token, auto-submit a form on behalf of the user, and read the page were prepared. The SET and BEEF frameworks were also installed to act as a 'cheaty' way to carry out enumeration and exploitation on a hooked client. Copies of the OWASP XSS Cheatsheet and a libray of payloads were grabbed before the exam.
For I3, SQLMap with its collection of automated analysis and tamper is the obvious choice, and pentestmonkey's collection of cheatsheets was downloaded. If you are unfamiliar with doing SQL injection manually you should also go away and practise this, in some instances SQLMap will not be able to exploit your injection point, and you will have to do this manually. Revision of shelling a database through SQLi is also required, and the usage of xp_cmdshell, xp_dirtree, library uploads, uploads to the webroot, or just database exploits was revised. One last thing for this section - always starts with VALID DATA! If its a SELECT it should SELECT a subset of data, not everything, and if its an INSERT, check to make sure there are no UNIQ constraints on what you are injecting into.
I7 covers SSL configuration, SSL Labs has write-ups of common misconfigurations and good practice guides. Write-ups of commonly seen flaws and all the 'named' bugs were created. SSLScan is a good tool for this, just confirm it is working as expected first. There are also some summary write ups available.
I8 and I9 cover directory traversal, dotdotpwn is an option for an automated tool, but doing these manually is usually easier. Keep in mind ways of jumping from LFI to Shell, and have some quick simple web-shells ready for use. Don't forget to check for any blacklisted functions when trying to shell the server. If you have done the OSCP, these two should be a breeze!
Code injection is easy enough, also covered in the OSCP. To make this easier and roll in shellshock, Commix is a tool which can be used.
Downloading commonly used documentation and cheat sheets, and the pre-write up of common flaws acts as a 'good known', as the last thing you want to do is be tripped by a typo in your exam, and when testing for things such as SQLi and RCE, do the simple tests first as they may just save you a bucket full of time. I also worked on a python RTFM, adding a new flag and new content getting ready for the exam.
|The Hacker Playbook 2: Practical Guide To Penetration Testing||A must for the exam, covering your standard web application flaws. Read it, then re-read it, then make sure you have absorbed all the information within it. If ou dont have it, check it out online at : https://archive.org/details/TheWebApplicationHackersHandbook2ndEdition|
|The Browser Hacker's Handbook||The companion book to the WAHH, also a must read covering more client-side attacks.|
|Open Source Intelligence Techniques: Resources for Searching and Analyzing Online Information||Covering off the OSINT, if you have never done anything formal in the area this is a great place to start.|
|SQL Injection Attacks and Defense||Taking a more in-depth look at SQLi, a good read for more than just the usual OR 3=3.|
If you are not planning on taking the exam anytime soon, and you are working from online resources, check out https://www.humblebundle.com/, they occasionally have infosec book sales where you can pick up great books at low prices while donating to charity!
There are some free training sites available, and most testers at this point have heard of https://www.vulnhub.com/, and https://www.hackthebox.eu/, but there are a few others which you may find useful. penTesterLabs looks at a large collection of off the shelf web application flaws, and more 'complicated' platform issues and CVE's. This one will set you back $20 a month, so it is quite cheap to have a look and see what you can learn.
If you are a UK based University Student, you may have access to Immersive Labs. A pretty good resource which utilises a series of virtual machines to teach a wide variety of concepts. Sadly, the second two are a bit expensive if you are studying on your own money. Priced at over $1000, Unless your organisation is signed up, it is quite expensive. Before launch, there was talk of a totally free access through "The Digital Cyber Academy® (DCA)", where all you needed was an .ac.uk adress, however this is no longer advertised so it may have been silenty dropped.
A few other people have done write-ups on the CCT exam, and their write-ups can also help, http://pentestdiary.blogspot.co.uk/2017/08/crest-cct-application-exam.html covers a large dump of tools which you may wish to use, http://pwndizzle.blogspot.co.uk/2014/12/crest-crt-exam-preparation.html covers a few common commands, HighOnCoffee has some high-quality cheatsheets, and RTFM contains quick snippets and links to more information.
The second section of the exam is open book, don't be afraid to take in your condensed revision notes or relevant reading material (An indexed up Web Application Hackers Handbook!). Although its open book time is very tight so you won't want to be having to look through pages and pages of notes and a few books so only take in things that you will really need. Have snippets of information available at your fingertips. Going into the exam make sure that your laptop is set up how you use it every day. The laptop gets wiped at the end of the exam (make sure you can take the drive out!) so it may be tempting to just stick something like Kali on there and be done with it, but, consider that you will not have external network access, so make sure all programs, plugins and compatibility fixes are in place.
Sanity check your build before going into the exam, with the rise of HTML 5 and the fall of NAPI, some things you may take for granted as working may not out the box. Flash, Java, ActiveX, and, SilverLight are all highlighted in the exam syllabus, but none are available when inserting a Kali Sana ISO. To deal with this, I have rolled up my testing laptop with all tools I need into a liveboot ISO. If you do testing as a day job a highly recommend following the walkthrough so that should the worse happen and your drive does not work in the exam, you have something to fall back on!
Keep an eye on your time in the exam, Your timings work out at around one mark per minute if you go for 100%, so read the paper at the start of the exam, and go for the section for which you believe will be the easiest. You don't need to tackle the exam in order, and you do not need to answer all sections of the questions.
And finally, in the words of Douglas Adams'DONT PANIC!
If you have studied, absorbed the reading list, had a stab at vulnhub, done some web app testing (Go check out BugCrowd if you want more!), and have memorised the syllabus you will be fine. At the end of the day, its just web application testing!