Penetration test: complete compromise of the transaction processing API, which allowed to initiate unsolicited payments on behalf of other registered customers.
Case study: Social engineering
Social engineering: it was possible to achieve persistent internal access, exfiltrate confidential and personal information, and compromise infrastructure.
Introduction
The team was tasked to perform an external black box engagement of an undisclosed banking institution without any restrictions on techniques used to obtain access, aside from establishing basic Rules of Engagement (RoE). No prior information except the Customer name and RoE was provided to the penetration testing team. However, a previous agreement stated that lateral movement and post-exploitation should be limited to avoid disruption of normal workflow.
The project had severe time constraints, but it was possible to achieve persistent internal access, exfiltrate confidential and personal information, and create internal attack scenarios that could further the infrastructure compromise.
Initial reconnaissance
During initial reconnaissance, Open source intelligence (OSINT), and active enumeration of the created attack surface, no easily exploitable external assets were identified, which led to the decision to pursue social engineering attacks. The priorities in information gathering shifted to discovering assets, services, and information that could help in payload or scenario creation. An externally-hosted outdated application was discovered, with a vulnerability that allowed unrestricted file upload and was later used for malware delivery. Other externally-facing applications were used to collect information about the company and its infrastructure or as targets for phishing.
Red team infrastructure setup, scenario creation, and campaign execution
The red team infrastructure used for the engagement included Command and Control (C&C) servers, HTTPS MitM proxies for phishing, a CDN domain front, and a malware testing environment. The payloads used during the attack were weaponized .doc, .xls, and .lnk files with embedded C&C implants. Both droppers and shellcode injection stagers were manually developed and obfuscated to minimize chances of static detection (achieving static detection by 0 out of 26 tested AntiVirus solutions), in-memory detection, and sandbox behavioral analysis.
Scenarios used for pretexting were specifically crafted for the organization and were delivered in several steps. Some of the scenarios used at later stages also implied increased security awareness to increase the chances of a successful breach. Performing a multi-stage campaign also allowed the penetration testing team to modify payloads and scenarios to evade sandboxes and mail filters present in the organization.
It was possible to obtain an initial foothold in the internal network, access to Active Directory with user-level access credentials, and achieve persistence.
Post-exploitation
Post-exploitation and lateral movement techniques were limited by the RoE, however, several internal flaws were discovered by the penetration testing team that allowed to confidently identify post-exploitation attack paths. Without breaking the RoE, the team was still able to verify that it is possible to use sensitive information discovered on publicly accessible shares, crack service tickets that allow access to high-privileged accounts, abuse folder redirection misconfiguration, or vulnerable Group Policy Objects, and conduct other, less critical attacks.
Conclusion
This case study highlights the importance of dedicated internal testing. The Customer in this case does not conduct internal testing and only insisted on assessing the possibility of an external breach. This led to the majority of project focus being dedicated to external attacks, and proper internal testing was still out of the project scope. The team was able to conduct a successful campaign and helped defend against similar attacks in the future, but it is strongly advised to always mind a possibility of an internal adversary and perform internal “assumed breach” testing. If you are interested in adversary simulation in general, please refer to the appropriate page.
WHY WORK WITH TENENDO?
Reducing high-severity vulnerabilities’ exposure by up to
97%
Reducing the cost of security testing, audit, and consulting by up to
30%
About security testing:
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…
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…
