Adversary simulation exercise: when real-life meet business

What’s an adversary simulation?

Unlike standard penetration test usually targeting one specific solution, application, or network; an adversary simulation exercise is more oriented on realistic approach where only objectives (flags) and out-of-scope scenarios are defined. It means that we are allowed, as attacker, to employ any attack vector that seems promising to reach our goal, as for example phishing attack, physical attack or/and internet exposed asset attack, if the customers agreed with such scenarios.

Goals of such mission are also to challenge detection capabilities, incident response processes and to identify technics, tactics and procedures (TTPs) that could be used by an external threat actor to conduct a successful targeted attack against our customer infrastructure without having any prior knowledge.

Adversary simulation exercise are really appreciated by customers, as this really reveals if they can be fully compromise tomorrow by an attacker, by pointing the weaknesses inside their procedures and infrastructure current configuration and flaws. It should be noted that until now, we performed a lot of adversary simulation exercises, and we always achieved our defined objectives.

Introduction

An international company in financial sector mandated us to perform a targeted attack against their company.
Only the physical intrusion vector was considered as out of scope for this mission, meaning we were not authorized to physically get into target office in order to plug raspberry on their network, target corporate computer, or try to gain Wi-Fi access or such kind of scenarios.

The following objectives were defined:

• Get unauthorized access to the customer internal network.
• Elevate privileges on the on-premise Active Directory.
• Gain access to sensitive data.
• Modify specific ERP data (eg: RIB) to prove the ability of conducting financial fraud.

Attack preparation

Infrastructure

A complete dedicated offensive infrastructure was setup for the mission before the start.

This infrastructure is composed of:

• Redirectors: Internet-facing assets in charge of transmitting victim connection to attacker servers.
• SMTP server: Mail server used to send phishing e-mails.
• HTTP server: Web server used to deliver malwares and offensive tooling + web phishing template.
• C&C / C2 (Command & Control) server: Malware panel to control compromised hosts.

Only the redirectors were accessible from internet, meaning that it should not be possible to directly identify the backend IPs of the adversary infrastructure.
Each server received specific configuration such as DKIM, SPF and DMARC for SMTP which permit to reduce the risk of spam categorization of our phishing emails, valid SSL certificate for HTTP and C2, without forgetting the domain categorization for the web proxy.

OSINT & External (internet facing services) surface recognition

Once the offensive infrastructure was setup, the first step was to identify company’s services accessible from a remote position, establish a list and check for potential vulnerabilities.
Also, employee’s data were also collected using social media platforms such as LinkedIn, to later compile a list of corporate email addresses to target and launch the phishing campaign:

Searches on the shodan.io and subdomains brute force were also performed in order to find the list of exposed servers on the internet:

Scenario definition

Accessing Citrix protected by 2FA

As no critical vulnerability allowing to gain remote code or command execution (RCE) on an internal asset of the targeted infrastructure was found during the external phase, it was decided to go with a phishing scenario for the initial access.

This scenario usage was selected because the company was using a remote access solution, in our case, it was CITRIX NetScaler.
Such remote access solution (Citrix, VPN) are target of choice for attacker, because if the attack is greatly performed, and depending on the remote solution configuration, it can be an ideal entry point for attackers.

This is also due because in most cases, it is easier to make targeted users filling a login form with their credentials, than executing a malware which on top of that, have to be successfully executed and in some cases may be detected by antivirus or EDR solutions.

Two options were discussed:

• Deliver a dropper within the email (in attachment or through an external link) to employees.
• Steal corporate credentials and replay them on the legitimate Citrix platform to generate valid session and interact with it manually.

A mix a both scenarios was chosen in order to increase campaign’s success rate.
First, during our R&D time, a script that automatically submit stolen Citrix credentials, including 2FA token, and generate valid session was developed to fit our needs.
Then, depending on the user web browser, a malware could be delivered.
JavaScript was used to fingerprint the user’s web browser and redirect to the dropper only if “Internet Explorer” is detected.
However, once the access will be gained, a persistence must be installed in order to keep our access in case of password change or Citrix session timeout.

Dropper

An HTA dropper file was created and work as following:

• The .HTA file embed a VB script that will drop a malicious DLL and execute it with rundll32.exe.
• This .DLL file is a customized binary allowing to connect to the command and control server and give remote access to the infected client (with the current user privileges).

Persistence

In order to persist on the Citrix hosts even after session timeout, a specific malware was developped.
The malware was connecting on our C2 server using HTTPS and his execution was triggered by the opening of any Word document.
This was due to the fact that Microsoft Word application automatically load any external library (DLL) ending with “.wll” extension present under the %APPDATA%\Microsoft\Word\Startup folder of the user opening Word.
The DLL was tasked to perform Process Hollowing and execute a Cobalt Strike shellcode in-memory of the iexplore.exe (Internet Explorer) process.
Of course, for all our payload, we used several AV/EDR evasion technics developed and tested during our dedicated R&D time in order to not being catched by any solution.
Payload injection has been performed inside another process than WORD in order to not lose the remote session in case the user close Microsoft Word application.

Toolset

To resume the created resources, we prepared before running the phishing:

• A HTA dropper;
• A .DLL payload;
• A .WLL word payload for persistence;
• E-mail phishing template;
• Web phishing page;
• JavaScript browser fingerprinting;
• Python script to relay phished credentials to the real targeted Citrix.

Therefore, as you can imagine, there’s a lot of preparation in order to successfully achieved our goals on such mission. We could enter in the very specific details for the payload, dropper and credentials replay script preparation but it is as long as it would need its own article, and is not the subject of this blog. Maybe in the next article? =) #teasing

Phishing preparation

As mentioned before, based on the identified hosts and the collected emails, we decided to run a phishing campaign using Citrix scenario. To do so, a phishing email and a phishing web page (landing-page) similar to original client Citrix page have been created.

Attack execution

Initial access

After having collected a maximum of email addresses, prepare the phishing web page and email, it was time to launch the attack.
The phishing was launched and permitted to gain initial access using the in-house script that automatically replay stolen credentials, including OTP, on the legitimate target CITRIX platform to gather valid Citrix sessions.

A library like Selenium can also be used in order to automate the replay of credentials and cookie saving/loading.
The python script combining both Citrix cookie grabbing and selenium cookie refresher can be found on our GitHub here : Offensive_tools/citrix_selenium.py at main · post-cyberlabs/Offensive_tools · GitHub

Figure 1 – Automatically replaying Citrix credentials (2FA) to generate session

Figure 2 – Web Citrix access (using session)

Connecting to the user Citrix session may disconnect him, which increase the risk of being detected, especially if the user is disconnected just after having submitted his credentials on our phishing page. That’s why we usually wait for the end of the day, and keep the session cookie valid until the end of working hours to connect.

Persistence

Once the Citrix access was gained, a persistence was setup on the compromised hosts to ensure the access will not be lost in case of session timeout, credentials reset or some other actions.

It should be noted that a restage of the infected hosts would not remove the malware as the targeted infrastructure had user’s home folders mapped on a network share, including installed application data and so, the malware located in Microsoft Word folder.
This imply that the malware was located on a file server, and started only when the user open Word from any Citrix even a freshly staged host.

Infrastructure takeover

The Active Directory Domain takeover was simple.
As the DFL (Domain Functional Level) was quite old, it was supposed that Domain Controllers were allowed to downgrade their authentication mechanisms to permit older systems to work correctly.
However, this type of attack scenario requires to have a listener performing the relay on TCP port 445 and in our case, only a malware running on a Windows Citrix was gained on the targeted infrastructure.
As Windows uses port 445 for SMB and stopping this service or binding on such port require local administrator privileges, it was not possible to use the compromised host from this perspective.
To bypass this limitation and perform the attack, a test was done to reach one of our internet exposed server on port 445 from the compromised Citrix host and if the TCP connection succeed, it will mean that no network filtering was performed to filter outgoing TCP connection on specific ports.
Thus, a downgrade of the Net-NTLM protocol was tried along with authentication coercion using both PrinterBug and PetitPotam on DCs over internet, permitting to gather Net-NTLMv1 hashes with specific challenge-response.
Net-NTLMv1 is known to be weak, rainbow tables for a pre-defined challenge-response exists and could permit to get NTLM hash from Net-NTLMv1 in few seconds.
Then, using the cracked NTLM hash of DC and Pass-The-Hash, it was possible to directly perform DCSync attack and take over the entire AD domain.

Figure 4 – Net-NTLMv1 over internet

Once the infrastructure is done, it was easy to move laterally on the internal network using adequate user NTLM hash, especially to target the payment Oracle database, and modify the RIB of an employee in order to validate the 4th flag.

Schema of the simulation and attack

We faced a lot of different infrastructure misconfiguration which usually permit us to gain Domain Administrator privileges over the network.
From Active Directory to machines configuration issues, we almost never use the same technics in order to elevate our privileges during such exercise.
That’s also why such exercise is interesting for customers bringing a more realistic approach and much more…