Penetration test: complete compromise of the transaction processing API, which allowed to initiate unsolicited payments on behalf of other registered customers.
The penetration testing team was hired to perform an internal adversary simulation assessment for an undisclosed financial institution. The end goal of the test was to obtain network access and valid application authentication credentials to the internal protected processing segment. It should be noted that generic quarterly infrastructure penetration tests were performed by a third-party team and the Client has mitigated vulnerabilities detailed in previous penetration test reports.
The simulation was staged onsite at the Client’s premises, which allowed for physical attacks to take place.
The penetration testing team obtained complete access to the Customer’s office domain, network access to processing segments, SSH credentials to critical servers, database passwords, and access to critical Web applications.
The scenario assumed the attacker has office employee-level access, and a preconfigured laptop with a standard OS distribution and endpoint protection configuration was provided to the security team. However, it was still deemed necessary to outline initial attack vectors for an outside attacker.
Wireless Evil Twin
A wireless Evil Twin PoC was set up at the Customer’s premises. As the wireless networks used RADIUS authentication with AD credentials, a successful hash capture was enough to gain initial access to the network and an account in the office domain. The Customer did not employ any wireless scanning tools, so the Evil Twin AP would remain undetected for a long period of time.
USB Keystroke Injection
Exploiting the lack of unauthorized wireless AP detection, a USB keystroke injection payload was crafted to tunnel the connection through an attacker-owned wireless network. Default endpoint protection policies allowed third-party USB keyboards to connect, allowing a crafted device to emulate a keyboard, executing the payload in PowerShell on the computer it is plugged in, and providing the attacker with initial access to the network. Such a device could be used on a temporarily unlocked PC or left plugged in on a locked one and provide the attacker with a shell in five seconds of activity.
RDP RCE and unauthorized Ethernet connections
The attacker could also set up shop in one of the unused meeting rooms to gain network access. However, a domain account would still be required to conduct further attacks, so the security team scanned the network and discovered several hosts vulnerable to different RCE exploits in the RDP service, allowing the attacker to obtain administrator-level access to them and valid domain authentication credentials.
Local privilege escalation and proxy bypass
In order to begin attacking the office network, it was necessary to obtain local administrator access and invent a way to bypass proxy whitelisting restrictions. The simplest method was to boot a live USB OS and use a third-party wireless AP, but, for the testing purposes, a local privilege escalation vulnerability was found in the default distribution’s service configurations, which allowed an attacker to run any command as the SYSTEM user. Also, all necessary tools could be downloaded directly from Github (which was whitelisted in the environment) and run in memory via PowerShell, bypassing AV restrictions.
Obtaining domain administrator access and lateral movement
The office environment relied heavily on Active Directory, so AD attacks were deemed a priority. A successful Kerberoast attack allowed the security team to obtain several Kerberos tickets while staying undetected by the Customer’s security infrastructure. Six of the tickets were cracked offline, presenting several different passwords. These passwords were used in password-spraying attacks and, while surprisingly remaining undetected by the security software, allowed access to over 150 domain accounts, two of which were service accounts with Domain Admin rights. Due to AD misconfigurations, these allowed interactive RDP access to any host in the domain, containing thousands of accounts of legitimate users, accounts of email servers, file transfer services, etc.
It was discovered, however, that the target network segment was inaccessible from the office network. A list of people with such access was created, and keylogging software was installed on their machines, bypassing endpoint protection measures by in-memory execution of the payloads. Thus, the security team obtained RDP authentication credentials to the terminal used to connect to the protected segment and tested pivoting the connection through the employee’s laptop to the terminal.
Obtaining application and database credentials
Once the network access to the processing segment was obtained, the penetration testing team performed a password-hunting activity on the terminal virtual hosts. An open share was discovered, containing employee manuals for processing operators. These manuals contained in unencrypted, unprotected form text files left over by previous and current employees with their authentication credentials, which allowed the security team’s complete access to both testing and production environments and databases. At this point, on an agreement with the Customer, the adversary simulation activity was considered complete not to accidentally disrupt the normal workflow of the infrastructure.
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 the human factor, weak password policies and password reuse, service and Active Directory misconfiguration, 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.
Despite mitigating all vulnerabilities discovered by a third-party company, the Client remained vulnerable to attacks and methods which a penetration test does not cover. Adversary simulation, in this case, has offered a completely different viewpoint on the security infrastructure of the Client, which allowed for preventing a threat of a similar real-world attack in the future.
With valid developer credentials for the infrastructure, we obtain access to existing CI/CD, logging, monitoring, and remote access solutions to build a complete threat model, find access control misconfigurations, and help companies ensure no single…
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…