Red Team: How We Compromised A Banks’ Network

A Red Team activity helps an organization assess it's security posture, and it's ability to safeguard assets against a persistent and motivated attack.

Red Team Security Brigade.
Posted by on September 22, 2018 0 Comment

A Red Team activity helps an organization assess it’s security posture, and it’s ability to safeguard assets against a persistent and motivated attack. The purpose of conducting a Red Team activity is to demonstrate how real-world hackers can combine seemingly unrelated exploits to achieve their goal.

“If you want to stop an attacker, you have to think like an attacker.”

Their goal is to act like the adversary and figure out different ways to break into a company so it can strengthen its defences. A red team considers the full ecosystem. Unlike penetration tests where we solely try to breach a component, red teamers use a plethora of multiple attack vectors. Ranging from social engineering, weak points in physical locations, external attacks.
This blog post addresses our recent Red Team where we comprised a bank’s network. Our Client (the bank) wanted a scenario as realistic as possible, where a dedicated adversary would be trying to break-in.

Methodology & Approach:

1. Defining the Target
2. Information Gathering
3. Vulnerability Analysis
4. Exploitation
5. Social Engineering
6. Physical Security Analysis
7. Post‐Exploitation or Maintaining Access

The Red Team Assessment commences with defining the target where we considered IP addresses, Applications, Organization’s physical security implementation, wireless network and employees for social engineering.

During the information gathering phase, the red team analyzed the banks’ ecosystem trying to leverage the maximum information. Typically, we gather information from various resources. OSINT plays a crucial role. We found IP addresses, applications, employee’s data, weak points in physical security implementation to name a few.

Information Gathering Phase Red Team

External Phase – Technical Analysis:

Once we had enough data on our target environment, the team began scanning their external network and public facing applications. Simultaneously we performed manual penetration testing on the applications. We correlated the information to find vulnerabilities that would allow us to execute commands on their remote server and help us to reach the primary target with pivoting.

Critical Vulnerabilities Discovered:
SQLi, Local File Download, LFI, Amazon S3 Buckets, Admin Panel, Hardcoded credentials, SQL server access, Command execution, Apache Tomcat running with default credentials.

Red Team Critical Vulnerabilities


The Red Team compiled sensitive data and internal files from the banks’ server and tried executing the command on their server. The banks’ security was resilient. The team tried accessing the Apache Tomcat with default credentials and got access to their tomcat admin panel. Having gained access we saw war deployment option and tried to upload our shell (It works!), we deployed our shell and executed the command on their server. Red teamers don’t stop here. The team tried pivoting to get access to further systems.

Up until now, we’d only tested the bank externally. The team gathered substantial sensitive data and access to sensitive resource of the organisation.

Social Engineering:

We conducted several successful interviews, promotional calls, and phishing attempts. With the help of social engineering attacks, we gathered sensitive details. Such as  AD credentials, personal information, internal proxy, physical security implementation, various security checkpoints, centralized server etc they were using.

Physical Security Analysis:


After the social engineering phase, we decided to have an anonymous visit to the bank. We had planned multiple scenarios to get inside: scheduling a job interview, RFID bypass, third-party meetings in the bank, promotional visits. However, we were successful in our first attempt but we also tried different methods to check the physical security postures. We used tailgating on various checkpoints where we also were able to take Red Team toolkit where they were unable to detect us. We also scheduled a meeting to get inside the organisation as a guest and were successfully able to enter in their premises.

Once the Red Team was on-site: We created a wireless network within the organisation using a LAN cable and our router which is usually the best way to be a part of their network. It was enough for us to be in their network. We also connected to their guest WiFi for network access but due to multi-step authentication, we only got the partial network access. A successful attack plan requires a backup option. To ensure that we didn’t lose connection via the wireless network we connected a Rasberry Pi in their network. This provided the reverse connection to our company for maintaining access.

Internal Phase – Technical Analysis :

We started testing their internal network. After a primary analysis, we got access to their FTP server, Printers, IoT devices, Configuration panels but that was not sufficient for us. We tried digging further inside, and after a thorough analysis, we got access to their RDP’s. Unfortunately, the monitoring team shut down the RDP. (Kudos to the banks’ Blue Team)

We tried LLMNR and NBT-NS Poisoning and received some of the NTLM hashes of users, but finding plaintext credentials from NTLM was taking long and considering the Blue Team was actively monitoring us we did not waste the active time on these hashes.

The team observed that one of the FTP server is accessible with anonymous login and has a URL and Credentials of their Citrix server. We considered the possibility of it being a honeypot because the credentials we got didn’t have a system associated with it. However, we got a rough idea where the Citrix server runs. We also confirmed that the Blue team is actively monitoring the network.


We observed that their Citrix server’s login is configured over SSL, but the SSL was not enforced. The team tried SSLStriping to downgrade the protocol along with MITM and successfully received several credentials of their Citrix systems. Our Red Team configured the Citrix receiver with received credentials and successfully got access to the system which has admin rights and contains all the internal data of the bank. The same credentials allowed us to join our created system in the AD and gained persistent access into their network.

Citrix server and any other centralised server should be the first target in any red team activity since most of the companies do not follow the security best practices for implementation and leave it vulnerable. Also, these systems can give us the huge scope to reach our target.

Concluding the Red Team Activity:

Alternatively, we got access to their monitoring system where we could disable the entire monitoring system and put the Blue team in trouble and allowed us access to assets of the bank assigned to Blue Team. We have done exactly the same and gained the access to domain admin by pivoting in the absence of blue team.

Leave a Reply

Your email address will not be published. Required fields are marked *