Case study: Social engineering

Social engineering: it was possible to achieve persistent internal access, exfiltrate confidential and personal information, and compromise infrastructure.


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 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.


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.  


Reducing high-severity vulnerabilities’ exposure by up to


Reducing the cost of security testing, audit, and consulting by up to


About security testing:

Case study: Payment processing API penetration testing

Case study: Payment processing API penetration testing

Penetration test: complete compromise of the transaction processing API, which allowed to initiate unsolicited payments on behalf of other registered customers.

Read More
Case study: Web application compromise

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…

Read More
Case study: Internal adversary simulation

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…

Read More

Need more information?

Post navigation