Important Pentest Tools You must Check

• SysInternals
• Donut
• Chisel
• Powermad
• Burpsuite
• Metasploit
• Powershell-Suite
• Rubeus
• Fuzzdb
• gobuster
• Acunetix
• Nessus
• Cobalt Strike
• PowerSploit
• Impacket
• PingCastle
• Process Hacker
• Hashcat
• John the Ripper
• Hydra
• Aircrack-ng
• Burpsuite
• Metasploit
•Lair – Reactive attack collaboration framework and web application built with meteor.
•Pentest Collaboration Framework (PCF) – Open source, cross-platform, and portable toolkit for automating routine pentest processes with a team.
•peda – Python Exploit Development Assistance for GDB.
•Industrial Exploitation Framework (ISF) – Metasploit-like exploit framework based on routersploit designed to target Industrial Control Systems (ICS), SCADA devices, PLC firmware, and more.
•Decker – Penetration testing orchestration and automation framework, which allows writing declarative, reusable configurations capable of ingesting variables and using outputs of tools it has run as inputs to others.
•Faraday – Multiuser integrated pentesting environment for red teams performing cooperative penetration tests, security audits, and risk assessments.
• CrackMapExec – Swiss army knife for pentesting networks.
•SigPloit – Signaling security testing framework dedicated to telecom security for researching vulnerabilites in the signaling protocols used in mobile (cellular phone) operators.•
•ACLight – Script for advanced discovery of sensitive Privileged •Accounts – includes Shadow Admins.
• AQUATONE – Subdomain discovery tool utilizing various open sources producing a report that can be used as input to other tools.•
•CloudFail – Unmask server IP addresses hidden behind Cloudflare by searching old database records and detecting misconfigured DNS.
•DNSDumpster – Online DNS recon and search service.
•Mass Scan – TCP port scanner, spews SYN packets asynchronously, scanning entire Internet in under 5 minutes.
•OWASP Amass – Subdomain enumeration via scraping, web archives, brute forcing, permutations, reverse DNS sweeping, TLS certificates, passive DNS data sources, etc.
•celerystalk – Asynchronous enumeration and vulnerability scanner that “runs all the tools on all the hosts” in a configurable manner.
•kube-hunter – Open-source tool that runs a set of tests (“hunters”) for security issues in Kubernetes clusters from either outside (“attacker’s view”) or inside a cluster.
•Active Directory and Privilege Escalation (ADAPE) – Umbrella script that automates numerous useful PowerShell modules to discover security misconfigurations and attempt privilege escalation against Active Directory.
•GTFOBins – Curated list of Unix binaries that can be used to bypass local security restrictions in misconfigured systems.
• LOLBAS (Living Off The Land Binaries and Scripts) – Documents binaries, scripts, and libraries that can be used for “Living Off The

Web Application Penetration Testing – Training

Web Application Penetration Testing

Phase 1 – History

  1. History of Internet –

Phase 2 – Web and Server Technology


  1. Basic concepts of web applications, how they work and the HTTP protocol –
  2. HTML basics part 1 –
  3. HTML basics part 2 –
  4. Difference between static and dynamic website –
  5. HTTP protocol Understanding –
  6. Parts of HTTP Request –
  7. Parts of HTTP Response –
  8. Various HTTP Methods –
  9. Understanding URLS –
  10. Intro to REST –
  11. HTTP Request & Response Headers –
  12. What is a cookie –
  13. HTTP Status codes –
  14. HTTP Proxy –
  15. Authentication with HTTP –
  16. HTTP basic and digest authentication –
  17. What is “Server-Side” –
  18. Server and client side with example –
  19. What is a session –
  20. Introduction to UTF-8 and Unicode –
  21. URL encoding –
  22. HTML encoding –
  23. Base64 encoding –
  24. Hex encoding & ASCII –

Phase 3 – Setting up the lab with BurpSuite and bWAPP




  1. Setup lab with bWAPP –
  2. Set up Burp Suite –
  3. Configure Firefox and add certificate –
  4. Mapping and scoping website –
  5. Spidering –
  6. Active and passive scanning –
  7. Scanner options and demo –
  8. Introduction to password security –
  9. Intruder –
  10. Intruder attack types –
  11. Payload settings –
  12. Intruder settings –



  1. 1 Penetration testing tool –
  2. Environment Setup –
  3. General concept –
  4. Proxy module –
  5. Repeater module –
  6. Target and spider module –
  7. Sequencer and scanner module –

Phase 4 – Mapping the application and attack surface


  1. Spidering –
  2. Mapping application using robots.txt –
  3. Discover hidden contents using dirbuster ––nu9Jq07gA
  4. Dirbuster in detail –
  5. Discover hidden directories and files with intruder –
  6. Directory bruteforcing 1 –
  7. Directory bruteforcing 2 –
  8. Identify application entry points –
  9. Identify application entry points –
  10. Identify client and server technology –
  1. Identify server technology using banner grabbing (telnet) –
  2. Identify server technology using httprecon –
  3. Pentesting with Google dorks Introduction –
  4. Fingerprinting web server –
  5. Use Nmap for fingerprinting web server –
  6. Review webs servers metafiles for information leakage –
  7. Enumerate applications on web server –
  8. Identify application entry points –
  9. Map execution path through application –
  10. Fingerprint web application frameworks –

Phase 5 – Understanding and exploiting OWASP top 10 vulnerabilities


  1. A closer look at all owasp top 10 vulnerabilities –



  1. Injection –
  2. Broken authentication and session management –
  3. Cross-site scripting –
  4. Insecure direct object reference –
  5. Security misconfiguration –
  6. Sensitive data exposure –
  7. Missing functional level access controls –
  8. Cross-site request forgery –
  9. Using components with known vulnerabilities –

  1. Unvalidated redirects and forwards –



  1. Injection –
  2. Broken authentication and session management –
  3. Insecure deserialisation –
  4. Sensitive data exposure –
  5. Broken access control –
  6. Insufficient logging and monitoring –
  1. XML external entities –
  2. Using components with known vulnerabilities –
  3. Cross-site scripting –
  4. Security misconfiguration –



  1. Injection explained –
  2. Broken authentication and session management –
  3. Cross-site scripting –
  4. Insecure direct object reference –
  5. Security misconfiguration –
  6. Sensitive data exposure –
  7. Missing functional level access control –
  8. Cross-site request forgery –
  9. Components with known vulnerabilities –
  10. Unvalidated redirects and forwards –

Phase 6 – Session management testing


  1. Bypass authentication using cookie manipulation –
  2. Cookie Security Via httponly and secure Flag – OWASP –
  3. Penetration testing Cookies basic –
  4. Session fixation 1 –
  5. Session fixation 2 –
  6. Session fixation 3 –
  7. Session fixation 4 –
  8. CSRF – Cross site request forgery 1 –
  9. CSRF – Cross site request forgery 2 –
  10. CSRF – Cross site request forgery 3 –
  11. CSRF – Cross site request forgery 4 –
  12. CSRF – Cross site request forgery 5 –
  13. Session puzzling 1 –
  14. Admin bypass using session hijacking –

Phase 7 – Bypassing client-side controls


  1. What is hidden forms in HTML –
  2. Bypassing hidden form fields using tamper data –
  3. Bypassing hidden form fields using Burp Suite (Purchase application) –
  4. Changing price on eCommerce website using parameter tampering –
  5. Understanding cookie in detail –
  6. Cookie tampering with tamper data-
  7. Cookie tamper part 2 –
  8. Understanding referer header in depth using Cisco product –
  9. Introduction to ASP.NET viewstate –
  10. NET viewstate in depth –
  11. Analyse sensitive data in ASP.NET viewstate –
  12. Cross-origin-resource-sharing explanation with example –
  13. CORS demo 1 –
  14. CORS demo 2 –
  15. Security headers –
  16. Security headers 2 –

Phase 8 – Attacking authentication/login


  1. Attacking login panel with bad password – Guess username password for the website and try different combinations
  2. Brute-force login panel –
  3. Username enumeration –
  4. Username enumeration with bruteforce password attack –
  5. Authentication over insecure HTTP protocol –
  6. Authentication over insecure HTTP protocol –
  7. Forgot password vulnerability – case 1 –
  8. Forgot password vulnerability – case 2 –
  9. Login page autocomplete feature enabled –
  10. Testing for weak password policy –
  11. Insecure distribution of credentials – When you register in any website or you request for a password reset using forgot password feature, if the website sends your username and password over the email in cleartext without sending the password reset link, then it is a
  12. Test for credentials transportation using SSL/TLS certificate –
  13. Basics of MySQL –
  14. Testing browser cache –
  15. Bypassing login panel -case 1 –
  16. Bypass login panel – case 2 –

Phase 9 – Attacking access controls (IDOR, Priv esc, hidden files and directories)


Completely unprotected functionalities


  1. Finding admin panel –
  2. Finding admin panel and hidden files and directories –
  3. Finding hidden webpages with dirbusater ––nu9Jq07gA&t=5s

Insecure direct object reference

  1. IDOR case 1 –
  2. IDOR case 2 –
  3. IDOR case 3 (zomato) –

Privilege escalation

  1. What is privilege escalation –
  2. Privilege escalation – Hackme bank – case 1 – 87cWM
  3. Privilege escalation – case 2 –

Phase 10 – Attacking Input validations (All injections, XSS and mics)


HTTP verb tampering


  1. Introduction HTTP verb tampering –
  2. HTTP verb tampering demo –

HTTP parameter pollution


  1. Introduction HTTP parameter pollution –
  2. HTTP parameter pollution demo 1 –
  3. HTTP parameter pollution demo 2 –
  4. HTTP parameter pollution demo 3 –

XSS – Cross site scripting


  1. Introduction to XSS –
  1. What is XSS –
  2. Reflected XSS demo –
  3. XSS attack method using burpsuite –
  4. XSS filter bypass with Xenotix –
  5. Reflected XSS filter bypass 1 –
  6. Reflected XSS filter bypass 2 –
  7. Reflected XSS filter bypass 3 –
  8. Reflected XSS filter bypass 4 –
  9. Reflected XSS filter bypass 5 –
  10. Reflected XSS filter bypass 6 –
  11. Reflected XSS filter bypass 7 –
  12. Reflected XSS filter bypass 8 –
  13. Reflected XSS filter bypass 9 –
  14. Introduction to Stored XSS –
  15. Stored XSS 1 –
  16. Stored XSS 2 –
  17. Stored XSS 3 –
  18. Stored XSS 4 –
  19. Stored XSS 5 –

SQL injection


  1. Part 1 – Install SQLi lab –
  2. Part 2 – SQL lab series –
  3. Part 3 – SQL lab series –
  4. Part 4 – SQL lab series –
  5. Part 5 – SQL lab series –
  6. Part 6 – Double query injection –
  7. Part 7 – Double query injection . –
  8. Part 8 – Blind injection boolean based –
  9. Part 9 – Blind injection time based –
  10. Part 10 – Dumping DB using outfile –
  11. Part 11 – Post parameter injection error based –
  12. Part 12 – POST parameter injection double query based –
  13. Part 13 – POST parameter injection blind boolean and time based –
  14. Part 14 – Post parameter injection in UPDATE query –
  1. Part 15 – Injection in insert query –
  2. Part 16 – Cookie based injection –
  3. Part 17 – Second order injection –
  4. Part 18 – Bypassing blacklist filters – 1 –
  5. Part 19 – Bypassing blacklist filters – 2 –
  6. Part 20 – Bypassing blacklist filters – 3 –
  7. Part 21 – Bypassing WAF –
  8. Part 22 – Bypassing WAF – Impedance mismatch –
  9. Part 23 – Bypassing addslashes – charset mismatch –

NoSQL injection

  1. Introduction to NoSQL injection –
  2. Introduction to SQL vs NoSQL – Difference between MySQL and MongoDB with tutorial –
  3. Abusing NoSQL databases –
  4. Making cry – attacking NoSQL for pentesters –

Xpath and XML injection

  1. Introduction to Xpath injection –
  2. Introduction to XML injection –
  3. Practical 1 – bWAPP –
  4. Practical 2 – Mutillidae –
  5. Practical 3 – webgoat –
  6. Hack admin panel using Xpath injection –
  7. XXE demo –
  8. XXE demo 2 –
  9. XXE demo 3 –

LDAP injection

  1. Introduction and practical 1 –
  2. Practical 2 –

OS command injection

  1. OS command injection in bWAPP –
  2. bWAAP- OS command injection with Commiux (All levels) –

Local file inclusion

  1. Detailed introduction –
  2. LFI demo 1 –
  1. LFI demo 2 –

Remote file inclusion

  1. Detailed introduction –
  2. RFI demo 1 –
  3. RFI introduction and demo 2 –

HTTP splitting/smuggling

  1. Detailed introduction –
  2. Demo 1 –

Phase 11 – Generating and testing error codes


  1. Generating normal error codes by visiting files that may not exist on the server – for example visit php or chintan.aspx file on any website and it may redirect you to 404.php or 404.aspx or their customer error page. Check if an error page is generated by default web server or application framework or a custom page is displayed which does not display any sensitive information.
  2. Use BurpSuite fuzzing techniques to generate stack trace error codes –

Phase 12 – Weak cryptography testing


  1. SSL/TLS weak configuration explained –
  2. Testing weak SSL/TLS ciphers –
  3. Test SSL/TLS security with Qualys guard –
  4. Sensitive information sent via unencrypted channels –

Phase 12 – Business logic vulnerability


  1. What is a business logic flaw –
  2. The Difficulties Finding Business Logic Vulnerabilities with Traditional Security Tools –
  3. How To Identify Business Logic Flaws –
  4. Business Logic Flaws: Attacker Mindset –
  5. Business Logic Flaws: Dos Attack On Resource –
  6. Business Logic Flaws: Abuse Cases: Information Disclosure –
  1. Business Logic Flaws: Abuse Cases: iPod Repairman Dupes Apple –
  2. Business Logic Flaws: Abuse Cases: Online Auction –
  3. Business Logic Flaws: How To Navigate Code Using ShiftLeft Ocular –
  4. Business Logic Security Checks: Data Privacy Compliance –
  5. Business Logic Security Checks: Encryption Compliance –
  6. Business Logic Security: Enforcement Checks –
  7. Business Logic Exploits: SQL Injection –
  8. Business Logic Exploits: Security Misconfiguration –
  9. Business Logic Exploits: Data Leakage –
  10. Demo 1 –
  11. Demo 2 –
  12. Demo 3 –
  13. Demo 4 –
  14. Demo 5 –
  15. Demo 6 –

Phase 13 – WAF Bypass

OSINT and Ephemeral exposures

OSINT and Ephemeral Cloud Native exposures



Penetration Testing

Penetration Testing

Advice on how to get the most from penetration testing

Penetration testing is a core tool for analysing the security of IT systems, but it’s not a magic bullet.

This guidance will help you understand the proper commissioning and use of penetration tests. It will also help you to plan your routine security measures so that you gain maximum benefit from this powerful but expensive operation.

For details of the processes used by CHECK-approved penetration testers, go here.

What is penetration testing?

For the purposes of this article, we will define penetration testing as: “A method for gaining assurance in the security of an IT system by attempting to breach some or all of that system’s security, using the same tools and techniques as an adversary might.”

Penetration testing should be viewed as a method for gaining assurance in your organisation’s vulnerability assessment and management processes, not as a primary method for identifying vulnerabilities.

A penetration test should be thought of as similar to a financial audit. Your finance team tracks expenditure and income day to day. An audit by an external group ensures that your internal team’s processes are sufficient.

Pen Testing: The ideal

In an ideal world, you should know what the penetration testers are going to find, before they find it. Armed with a good understanding of the vulnerabilities present in your system, you can use third-party tests to verify your own expectations.

Highly experienced penetration testers may find subtle issues which your internal processes have not picked up, but this should be the exception, not the rule. The aim should always be to use the findings of a penetration test report to improve your organisation’s internal vulnerability assessment and management processes.

What should a penetration test tell you?

Typically, penetration tests are used to identify the level of technical risk emanating from software and hardware vulnerabilities. Exactly what techniques are used, what targets are allowed, how much knowledge of the system is given to the testers beforehand and how much knowledge of the test is given to system administrators can vary within the same test regime.

well-scoped penetration test can give confidence that the products and security controls tested have been configured in accordance with good practice and that there are no common or publicly known vulnerabilities in the tested components, at the time of the test.

What sort of system should be tested?

Penetration Testing is an appropriate method for identifying the risks present on a specific, operational system consisting of products and services from multiple vendors. It could also be usefully applied to systems and applications developed ‘in-house’.

For product-specific testing, it is not an appropriate technique.

Using penetration testing effectively

A penetration test can only validate that your organisation’s IT systems are not vulnerable to known issues on the day of the test.

It’s not uncommon for a year or more to elapse between penetration tests. So, vulnerabilities could exist for long periods of time without you knowing about them if this is your only means of validating security.

Third party penetration tests should be performed by qualified and experienced staff only. By their nature, penetration tests cannot be entirely procedural, an exhaustive set of test cases cannot be drawn up. Therefore, the quality of a penetration test is closely linked to the abilities of the penetration testers involved.

The NCSC recommends that HMG organisations use testers and companies which are part of the CHECK scheme. Non-governmental organisations should use teams qualified under one of these certification schemes: CRESTTiger schemeCyber Scheme.

Types of testing

Penetration testers can be used to perform a wide-range of testing. The following list is illustrative, not comprehensive.

1. Test basis

Tests can be carried out by testers armed with varying amounts of information about your system:

  • Whitebox testing – Full information about the target is shared with the testers. This type of testing confirms the efficacy of internal vulnerability assessment and management controls by identifying the existence of known software vulnerabilities and common misconfigurations in an organisation’s systems.
  • Blackbox testing – No information is shared with the testers about the internals of the target. This type of testing is performed from an external perspective and is aimed at identifying ways to access an organisation’s internal IT assets. This more accurately models the risk faced from attackers that are unknown or unaffiliated to the target organisation. However, the lack of information can also result in vulnerabilities remaining undiscovered in the time allocated for testing.

2. Test type

Each of the tests described below can be run as either a blackbox or whitebox operation:

  • Vulnerability identification in bespoke or niche software – Most commonly used in web applications. This type of testing must give feedback to developers on coding practices which avoid introducing the categories of vulnerability identified.
  • Scenario driven testing aimed at identifying vulnerabilities – The penetration testers explore a particular scenario to discover whether it leads to a vulnerability in your defences. Scenario’s include: Lost laptop, unauthorised device connected to internal network, and compromised DMZ host, but there are many others possible. You should consider, based on previous incidents, which scenarios are most relevant to your organisation.
  • Scenario driven testing of detection and response capability – In this version of scenario driven testing, the aim is to also gauge the detection and response capabilities your organisation has in place. This will help you understand their efficacy and coverage in the particular scenario. This is an area of current work by the NCSC, further information will be available shortly, please contact us if you have a particular need in this area.


If you have a particular scenario that requires additional assurance, a specifically targeted penetration test may be a good way to obtain that assurance. A suitably qualified penetration testing team will be able to guide you through the selection and scoping process required in this case.

Your testing regime

It’s critically important to note that a planned penetration test doesn’t mean your normal testing regime should cease to include security tests on the target system. Functional testing of security controls should still occur.

Assessing whether defined security controls are functioning is not a valuable use of penetration testing resources.

A functional testing plan should always include positive tests (such as “The logon box comes up every time you try to log in and you aren’t just allowed in”).

Negative testing may be included in your functional testing plan where the skills to perform it are available within your organisation (for example, verifying that ‘You can’t log in without the correct password’).

A model penetration test engagement

A typical penetration test will follow this pattern: Initial engagement, scoping, testing, reporting and follow up. There should be a severity rating for any issues found.

For this model we assume that:

  • You wish to know what the impact of an attacker exploiting a vulnerability would be, and how likely it is to occur
  • You have an internal vulnerability assessment and management process

Initial engagement of the external team

You should ensure that the external team has the relevant qualifications and skills to perform testing on your IT estate. If you have any unusual systems (mainframes, uncommon networking protocols, bespoke hardware etc.) these should be highlighted in the bid process so that the external teams know what skill sets will be required.


Scoping a penetration test should involve:

  1. All relevant risk owners
  2. Technical staff knowledgeable about the target system
  3. A representative of the penetration test team

Where the goal of the test is to ensure good vulnerability management:

  1. Risk owners should outline any areas of special concern
  2. Technical staff should outline the technical boundaries of the organisation’s IT estate
  3. The penetration test team should identify what testing they believe will give a full picture of the vulnerability status of the estate

Assuming you have one, a current vulnerability assessment should be shared with the testers at this stage. Testing can then be designed to support a reasonable opinion on the accuracy and completeness of the internal vulnerability assessment.

Special requirements

During scoping, you should outline any issues which might impact on testing. This might include the need for out-of-hours testing, any critical systems where special handling restrictions are required, or other issues specific to your organisation.

Plan of action

The output of the scoping exercise should be a document stating:

  1. The technical boundaries of the test
  2. The types of test expected
  3. The timeframe and the amount of effort necessary to deliver the testing – usually given in terms of resource days
  4. Depending on the type of approach agreed, this document may also contain a number of scenarios or specific ‘use cases’ to test
  5. The penetration testing team’s requirements.This will allow you to do any necessary preparation before the date of the test. For example, by creating test accounts or simply allocating desk space
  6. Any compliance or legislative requirements that the testing plan must meet
  7. Any specific reporting requirements, for example the inclusion of CVSS scores or use of CHECK severity levels
  8. Any specific time constraints on testing or reporting, that a penetration testing company will need to consider when allocating resources


Staying in contact

During the test phase, you should ensure that a technical point of contact is available at all times. The point of contact does not need to spend all their time working with the test team but should be available at short notice. This allows the test team to raise any critical issues found during testing, and resolve problems which are blocking their testing (such as network misconfiguration).

Taking care

The testers should make every effort to avoid causing undue impact to the system being tested. However, due to the nature of penetration testing, it’s impossible to guarantee that no unexpected reactions to testing will occur.

Changing scope

During a penetration test or security assessment, the testing team may identify additional systems or components which lie outside of the testing scope but have a potential impact on the security of the system(s) which have been defined as in scope.

In this event, the testing team may either suggest a change to the scope, which is likely to alter testing time frames and cost, or they may recommend that the exclusion of such components be recorded as a limitation on testing.

The decision on which would be the preferred option will generally be down to the risk owner, with the penetration team responsible for clearly articulating the factors to consider.


The test report should include:

  • Any security issues uncovered
  • An assessment by the test team as to the level of risk that each vulnerability exposes the organisation or system to
  • A method of resolving each issue found
  • An opinion on the accuracy of your organisation’s vulnerability assessment
  • Advice on how to improve your internal vulnerability assessment process

A debriefing can also be useful. At this meeting the test team run through their findings and you can request further information or clarification of any issues.

Severity rating

When rating vulnerabilities it is common for penetration testers (often at customer behest) to use the Common Vulnerability Scoring System which attempts to give a numerical score identifying the severity of a vulnerability.

To simplify this measurement, CHECK reports are required to state the level of risk as HIGH, MEDIUM, LOW or INFORMATIONAL in descending order of criticality. For CHECK reports, scoring systems such as CVSS may be used in addition to (but not in place of) this.

Whilst vulnerabilities are ordinarily categorised at one of these levels in a consistent manner, exceptions can sometimes occur. For example, other mitigating controls in place could minimise the effectiveness of a vulnerability, or the presence of additional vulnerabilities could have a synergistic effect.

Any deviation from associating a vulnerability with its standard rating should be documented and justified by the penetration testing team.

Follow up on the report

  1. Do your own assessment

The penetration test report should be assessed by your organisation’s vulnerability management group in a similar manner to the results of an internal vulnerability assessment.

The penetration test team will have rated each issue found and given a potential solution. However, it’s important to note that risk assessment and decisions on the application of fixes are your responsibility.

The test team may not have had access to all details about a specific system or the potential business impact of the exploitation of a vulnerability. Consequently, they may rate issues either lower or higher than you. This process of assessing vulnerability levels should not be used to downplay issues – it should be a process of looking at issues and identifying the risk to your organisation.

2. Previously unknown vulnerabilities

Any vulnerabilities identified by the penetration test which you did not previously know about should be given special attention, with the aim of identifying ways in which you might go about spotting such issues in future.

3. Choosing solutions

The solutions proposed by your penetration testers may not be the only ones possible. You should take advice from your own technical staff and suppliers on alternatives.

As an example, imagine your pen testers have suggested patching a piece of software. You should ask yourself, ‘Is this the only solution to the problem?’ It may be possible to simply uninstall the software if it’s not actually required, or other controls could be put in place to limit exposure to the vulnerability. It may even be that additional monitoring of the vulnerable component is sufficient to reduce the risk to an acceptable level.

Vulnerability risk assessment and mitigation is a business process and should not be wholly outsourced to the test team

OSCP Intro Letter


OSCP Intro Letter

Dear Applicant,
Thank you for your interest in Penetration Testing with Kali Linux. Please read this entire email carefully as it contains very important information.

Course Prerequisites

To be successful, you must have basic Linux skills – meaning you need to be able to navigate through the Linux filesystem, run simple commands, edit files, and be comfortable at the command line in general. We also recommend being familiar with Bash scripting with basic Perl, Python, or Ruby skills being considered a plus. A solid understanding of TCP/IP including addressing, routing, and subnetting basics are required as well.

Course Information

The Penetration Testing with Kali Linux (PWK) online course is comprised of downloadable videos totaling over eight hours in length and an approximately 350 page PDF lab guide. If you haven’t already done so, you can view the course syllabus and objectives at the following link:

Penetration Testing with Kali Linux Syllabus [1]

In addition to these study materials, you will receive access to our online labs where you can practice various attack techniques safely and legally. You can purchase VPN lab access for 30, 60, or 90 days in duration. The lab time begins when you receive your course materials as the content is intended to be practiced as you progress through the course. Based on previous student experiences, we recommend you begin with the 60 day option. Please note that once purchased, lab time is non-refundable.


The cost for this course with 30 days of labs is: 800$ USD
The cost for this course with 60 days of labs is: 1000$ USD
The cost for this course with 90 days of labs is: 1150$ USD

The certification exam is included in the fees above.

We only accept payment via major credit cards, debit cards, and e-wallets.

The time required to complete the course exercises depends on your technical background however, the average reported time by our students is a minimum of 100 hours. Note that this estimate only reflects the time to complete the course exercises and does not include the time needed to attack the various lab systems, which can vary from weeks to months depending on background, aptitude, and available time. Generally we find that 60 days of lab time is suitable for the average student.

You will be able to watch the videos and read the lab guide offline, however the VPN labs require a solid Internet connection – high speed ADSL or cable connection (512/256 minimum). Our labs contain various configurations of Windows and Linux machines with specialized software packages and pentesting applications.

Online Lab Access

Our online VPN lab environment is a critical component of the course and you are provided access along with your course materials on your start date. You may not receive your course materials prior to your lab access as you are expected to work through the course exercises in the lab environment.

Lab access is provided as a consecutive block of time and is non-refundable. You may only pause your lab account under exceptional circumstances and only with valid, written justification. When lab time is paused, resources are still allocated in our lab which remain idle that prevent other students from being able to occupy your position in the labs.

Support Terms

Please note that Penetration Testing with Kali Linux is a self-paced and self-directed course that does not have any official support. In order to be successful, a great deal of independent study and research beyond the presented materials is required. You are expected to conduct extra research in order to compromise various hosts or complete the course exercises.

Our student administrators are available primarily to assist with technical issues related to the online labs but can also provide occasional hints or guidance after a student has demonstrated that they have already put in substantial effort before asking for assistance. We do however have active student forums where help might be found if needed. To get a better understanding of the effort and level of work required in the course, we recommend you refer to our Course Reviews [2] page where you will find numerous unsolicited reviews written by our alumni.

The typical administrative hours for the orders department are 1400 – 2200 GMT and our student administrators are typically online from 0800 – 0300 GMT.

Certification Information

The Offensive Security Certified Professional (OSCP) [3] certification challenge is an online exam. You will connect to our exam VPN lab remotely and have 23 hours and 45 minutes to complete the challenge and an additional 24 hours to submit your documentation by email. In addition to meeting the certification exam objectives, you must submit an exam penetration test report in order to be awarded your OSCP designation.

You must schedule the challenge within 90 days of the expiration of your lab time.

Penetration Testing with Kali Linux may qualify you for 40 ISC2 CPE Credits. This applies to students who submit their exercises and documentation at the end of the course or pass the certification challenge. CISSPs can register the Offensive Security training at the ISC2 website. Please note that we cannot register the CPEs on your behalf.

Continue Registration

We open a course every Sunday and recommend that students begin the registration process 15 – 30 days before their desired start date. If you would like to sign up for the Penetration Testing with Kali Linux course, please follow the link below in order to continue your registration. It is very important that you register with your legal name. You will have the opportunity to change this after passing your certification if you would like your certificate to read differently.

Our students usually provide us with a corporate email address or an address that can somehow help provide proof of identity. Email addresses from Internet Service Providers (ISP) or free email providers such as Hotmail or Gmail (including paid versions), are not accepted without a scanned ID.
If you are unable to provide an alternate non-free address that allows us to get basic verification, we will require a scanned copy of your valid government issued ID in color, such as a driver’s license or passport. For IDs in the form of a card, please include a scan of both the front and back of the card.

We need to be able to see your photo, full name, address (if applicable), year of birth and the expiration date of the ID. You may blur the ID number. Expired IDs are not accepted.

You may also send a photo of your ID if a scanner is not available as long as the image is clear and not blurry.

If you choose to send a scanned ID, you may blur the ID number and send it to [email protected] (please do so only after you use the link below and provide the required information).
Note that a registration request with a free email address will be ignored.

Register for Penetration Testing with Kali Linux [4]

The above registration link will be valid for the next 72 hours. You will be required to submit a new request in the future via our website if you do not use this link in the allotted time.

Do not hesitate to contact us with any questions.

The Offensive Security Team


Path to Hack



Bug Bounties

Bug Bounties

No alternative text description for this image


  • Web/API
  • Mobile App/API



PenTesting / Scanning Cached/Load Balanced Targets

PenTesting / Scanning Cached/Load Balanced Targets


As part of the PCI Certification process, external facing application that are in scope of the PCI environment require a PCI ASV scan. If these external facing applications are using load balancing and/or caching, please be aware of the following; (Examples of Load Balancers include; F5 LTM, AWS Elastic Load Balancer/ AWS CloudFront.)

Any load balancer using a full proxy architecture will establish a TCP connection to the virtual load balanced IP or VIP and the load balancer will proxy your scans and connection requests to a pool of backend applications servers. The rules on your load balancer determine which member of the pool gets that second connection. This means that you have no way of knowing which pool member you have scanned. The IP of the backend server will not be returned to the initial host, the one from which you established the initial TCP connection (to the VIP). To allow a PCI ASV scan, please add scanning origin to temporarily allow direct scans of your servers.

Please consider the following when determining the number of IP address required for External Scan;

  1. There are no load balancers in front of any in-scope servers:
    • External IP address / URL counted as individual IPs.
  2. All servers behind load balancers are identical and synchronized:
    • The external facing VIP or load balanced URL/IP is counted as an individual IP  (Allow scanning origin to temporarily allow direct scans of your servers.)
  3. Servers behind load balancers not identical and not synchronized:
    • Need to scan each individual IP instead of the VIP. (Allow scanning origin to temporarily allow direct scans of all servers.)

Mailware analysis

Mailware analysis

PenTesting Methodology

PenTesting Methodology

Security Colony - Detail 2019-04-17 22-10-24.png


F3EAD Model

  1. Find: essentially ‘picking up the scent’ of the opponent, with the classic “Who, What, When, Where, Why” questions being used within this phase to identify a candidate target
  2. Fix: verification of the target(s) identified within the previous phase, which typically involves multiple triangulation points. This phase effectively transforms the intelligence gained within the “Find” phase into evidence that can be used as basis for action within the next stage
  3. Finish: based on the evidence generated from the previous two phases the commander of the operation imposed their will on the target
  4. Exploit: deconstruction of the evidence generated from the finish phase
  5. Analyze: fusing the exploited evidence with the wider intelligence picture
  6. Dissemination: finally publishing the results of the research to key stakeholder

Identify Target Environment

  1. Wireless
  2. Web Application
  3. MITRE ATT&C –
  4. External Network Infrastructure
  5. Internal Network Infrastructure
  6. Database Infrastructure
  7. Social Engineering
  8. Physical Security
  9.  SCADA
  10. IoT
  12. 0
  13. RedTeamOperations





Kali Cheatsheet

Kali Cheatsheet

The following is a list of improvements to the Kali distro to turbo charge your Pen Test tool kit..

Kali VM Username and Password: kali/kali

Fresh Install

  1. Setup Kali on AWS –
  2. Use Generation 1 in Hyper-V
  3. Install VM Guest Tools
  4. sudo su
  5. sudo apt-get install asciinema
  6. asciinema rec / exit
  7. lsb_release -a
  8. apt-get update && apt-cache search kali-linux-full
  9. apt-get update && apt-get upgrade -y && apt-get dist-upgrade -y
  10. sudo dpkg –configure -a
  11. apt-get autoremove
  12. reboot
  13. Install Vmware Tools and shared folders
    1. sudo apt update && sudo apt full-upgrade -y && sudo apt install kali-themes
    2. sudo apt install -y –reinstall open-vm-tools-desktop fuse
    3. usr/bin/vmware-hgfsclient
    4. cd /mnt/hgfs/
    5. ln -sf /usr/local/sbin/mount-shared-folders ~/Desktop/mount-shared-folders gsettings set org.gnome.nautilus.preferences executable-text-activation ‘ask’
    7. sudo mount -t vmhgfs .host:/Desktop /mnt/hgfs
    8. sudo mount -t fuse.vmhgfs-fuse .host:/Downloads /mnt/hgfs/Downloads -o allow_other
    9. nano /etc/fstab
    10. hosts:/Downloads /mnt/hgfs/Downloads fuse.vmhgfs-fuse allow_other
    11. mount -t vmhgfs .host:/Desktop /mnt/hgfs

    12. sudo mount -t fuse.vmhgfs-fuse .host:/Downloads /mnt/hgfs/Downloads -o allow_other

    13. nano /etc/fstab Hosts:/Downloads /mnt/hgfs/Downloads   fuse.vmhgfs-fuse allow_other

  14. Set Root password
    1. sudo su –
    2. passwd

Install Applications

Cloud Security Tools and Labs

  • Offensive Terraform –
  • CapitalOne – SRE exploits
  • FOR509: Cloud Forensics and Incident Response : US$7,020.00 USD
  • SEC588: Cloud Penetration Testing : US$7,020.00 USD
  • Find articats in Github
  • Eyewitness
  • Open Database
  • postman
  • privileged and escalations with PACU
  • Pacu is an open source AWS exploitation toolkit written by Rhino Security Labs. It was built to aid penetration testers in attacking AWS environments; so, now we will quickly install and set up Pacu to automate these attacks that we have been trying.

Staying anonymous

  • proxychain use socks5 only
  • update dns to opendns and in nertherlands
  • Disable webrtc
  • Use OpenVPN
  • use for searching
  • spoof mac address