Social engineering
During this social engineering engagement, it was possible to achieve persistent internal access, exfiltrate confidential and personal information, and compromise the internal segmented infrastructure.
Targets
The application penetration testing activity has a strict predefined scope, that includes all endpoints and parts of the application environment available to an attacker. This ensures that vulnerabilities that may arise when interacting with different parts of the application (i.e. mobile and web APIs) are covered by the scope.
Penetration testing models
Penetration testing activities may be performed with different levels of environment information and access available to the tester. Testing methods and techniques differ based on that level, and it is sometimes recommended to conduct testing in several stages to have a better understanding of the application and potential security risks.
Blackbox testing
Blackbox testing implies no previous knowledge of the application, its components, architecture, and functionality is provided to the tester. Also, no test accounts except for initial access are created for the penetration test. Although this test allows emulation of an outside threat, it is recommended to combine BlackBox testing with other methods to improve testing coverage.
Greybox testing
Greybox testing expands upon BlackBox methods, providing the attacker with client accounts, API documentation and schematics, and a list of application components. This method is the most common, as it allows balancing the effectiveness of the testing with an adequate simulation of a persistent outside threat.
WhiteBox testing
WhiteBox testing implies complete administrative access to all hosts in the environment and all components of the application, including its source code. Although complete security code reviews are not usually performed, knowledge of underlying mechanisms, frameworks, and architecture makes WhiteBox testing the most efficient out of the three methods. Also, it becomes easier to verify the exploitability of discovered flaws, as potentially unseen from outside server-side effects can be identified by the tester.
WhiteBox testing makes it harder to assess identified risks and determine the exploitability of the application from the outside, as the attacker usually does not have similar knowledge about the application environment. However, it is still safer to assume that a persistent attacker has near-infinite time to discover vulnerabilities, and WhiteBox testing can help discover not only the most probable but all potential security flaws.
Methodology
In order to conduct application penetration tests, we rely on industry-wide accepted best practices and methodologies, mainly:
- OSSTMM (Open Source Security Testing Methodology Manual)
- OWASP (Open Web Application Security Project) manuals and guidelines
- NIST and ISACA penetration testing and auditing standards and guidelines
Relying on industry standards helps us not only to maintain a consistent testing process but to provide our customers with thorough and standard-compliant penetration tests.
Related services:
Client-Bank 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.
Internal Adversary Simulation Case
The adversary simulation activity helped the client identify and remediate multiple issues with the on-premise infrastructure and vulnerabilities, calculate potential risks, and improve the overall security posture. Each finding also included proposed solutions for applying industry-standard defences.
