Infrastructure penetration testing

Infrastructure penetration testing focuses on the security of both the application environment and the supporting infrastructure, including third-party services and applications. The testing is performed with a combination of manual and automated techniques, tailored for the specific environment.
To maintain a consistent testing process, we rely on industry-standard best practices and methodologies, like OSSTMM (Open Source Security Testing Methodology Manual), NIST and ISACA penetration testing and auditing standards and guidelines, PCI SSC penetration testing guidelines, while also using our own methodologies, developed over years of experience. Usually, infrastructure penetration testing is required to pass security certifications like PCI DSS, so we make sure our testing processes and methodologies are compliant to the standards required by the Customer.

Application penetration testing

Web penetration testing is focused on finding security vulnerabilities in a target application environment that could let an attacker obtain unauthorized access to the application or exploit its functionality to gain access to sensitive information, underlying OS, or conduct unauthorized actions (i.e. transactions in a banking application). Unlike vulnerability assessment activities, goals of penetration testing include ensuring all vulnerabilities identified are exploitable and can be combined to create an attack chain. However, penetration testing does not focus on achieving specific goals like adversary simulation or Red Team activities, including in scope all potential compromise scenarios.

Case study: Web application compromise

This case is a very good example why manual penetration tests are valuable – the team achieved compromise without administrator access to the application, not using any known exploits or discovering injection/deserialization/other RCE flaws. The vulnerabilities used could not be discovered by any Web application scanner, as the requests used presented well-documented behavior. We understand the importance of manual testing, and that is why most of our web penetration test project time is dedicated to it.

Case study: Internal adversary simulation

The adversary simulation activity allowed the security team to demonstrate a complete compromise path while not using any usual, “exploitable” vulnerabilities. Instead, the attackers relied on human factor, weak password policies and password reuse, service and Active Directory misconfigurations and weak segmentation measures to achieve the goal. Also, flaws in threat detection and response, endpoint protection, wireless protection and security policies were discovered, something that is usually out-of-scope for an infrastructure penetration test.

Social engineering assessments

Social engineering is an attack that requires human interaction, persuading employees of the target company to act, such as opening a malicious document or providing authentication credentials.
While the social engineering delivery method is usually assumed to be email, many other channels such as SMS messages, calls, or social media may be used in the assessment. During the test, spear-phishing attacks are preferred, where a user’s personal information and position in the company are used to enhance a pretexting scenario, improving the success rate.
Usually, social engineering attacks are carried as a part of an adversary simulation assessment.

Adversary simulation

Adversary simulation can provide a different insight into a security infrastructure. While penetration tests are used to test potential vulnerabilities with no regard to stealth, evasion, lateral movement and the Blue Team’s ability to detect and respond to attacks, adversary simulation assessments allow to completely emulate the actions of a malicious individual and trigger proper security team response. While not a replacement for a complete penetration test, such an assessment can provide valuable insight into protection capabilities of a company against a real-world attack.