Author: Wesley Renshaw – Lead Consultant
This two part blog series will take a look at a recent Red Team assessment performed by Dionach, and the process that was carried out to overcome barriers and achieve the objectives set out by the client.
Introduction
Dionach were approached to perform a Red Team assessment for a global organisation with offices all over the world. As such the scope for this assessment was particularly wide which is beneficial as this type of assessment involves helping the organisation’s monitoring and detection capabilities and doing so at a large scale is most helpful.
The assessment was split into the following phases:
- Reconnaissance
- Initial compromise
- Escalation of Privileges
- Persistence
- Data Gathering and Exfiltration
The blog post will be divided into these sections with discussions detailing ideas and approaches carried to achieve the objectives of the assessment.
Reconnaissance
The reconnaissance phase identified the following information some of which was used to push the assessment forward and accomplish the objectives outlined.
- External network ranges
- External login portals
- Website and Mobile applications
- Email addresses
- Information relating to employees, such as their job roles and what devices and software they use
The information gathered identified that the client used Google’s G-Suite heavily to perform daily business operations, such as email, documents processing, calendar management, and file sharing using Google Drive.
Accessing Google accounts without triggering alerts would be difficult and proved to be the case as alerts were triggered later in the assessment as discussed in section “Escalation of Privileges”.
A number of websites identified included common web application flaws such as SQL injection, however these vectors did not prove useful in gaining a foothold within the client networks. Further reconnaissance was performed against other client assets such as mobile applications in an attempt to identify API endpoints which may provide access to the client’s G-Suite environment. Mobile applications may be neglected when thinking in terms of Red Team assessments and could often be overlooked. During this assessment however it proved to be useful, providing the initial compromise of the assessment. Dionach gave a talk that explores this matter further that was delivered at DefCamp 2019. The conference video for this talk can be seen below:
https://www.youtube.com/watch?v=Hx9EBQT4BBc
The team reviewing the mobile application identified a trivial file upload vulnerability on a website hosted on an AWS server that was being supported by the mobile application. It was possible to exploit this to gain an initial foothold onto a client asset, which is explored further in the next section.
Initial Foothold
Reviewing the mobile applications developed by the client allowed for the discovery and exploitation of a trivial file upload vulnerability; with this it was then possible to perform more reconnaissance with access to the compromised AWS server. The goal at this point of the assessment was still the same, find a way to gain access to the client’s Google G-Suite environment. A common practice amongst developers is to hardcode credentials into web files such as PHP files to allow for notifications to be sent to mail accounts as an example. By pillaging the server for hardcoded credentials, a number of Gmail accounts were discovered that were in use for services across the globe. Identifying these accounts provided a great starting point for the assessment, however one problem arose which was known to the team: Google’s Security Operations Centre (SOC). By using these Gmail accounts and logging into them from outside the geographical norm in which the accounts log in, and from unknown devices would cause alerts to be raised.
Alerts were raised by Google when accessing one of these service accounts from outside of the originating country. However, one issue was evident relating to this Gmail account, the lack of multi-factor authentication (MFA). MFA had not been configured for the account this allowed the team to skip this configuration setup and access the Gmail account. With access to the Gmail account it was a great step forward for all of ten minutes, as an alert was triggered which the team deleted however the alert may have been forwarded to and seen by someone which prompted a password change.
At this point it was almost back to the start, however the team still had access to valid credentials for a number of Gmail accounts. The problem however was still accessing these accounts without raising any alerts. One approach was to leverage the compromised AWS server to tunnel traffic through and access these Gmail accounts from a host which may be trusted and was at least in the same geographic region as the targeted Gmail accounts. A slight problem arose however, as access to the AWS server only provided limited privileges which prevented the installation of packages, and an old version of OpenSSH server on the server did not support dynamic ports. In order to overcome this issue, a member of the Dionach team developed a tool to allow tunnelling of SSH traffic through a local SOCKS5 proxy, providing web browser access through the AWS server.
Using this approach, it was possible to log into one of the Gmail accounts without raising alerts, providing a safe way to start performing further reconnaissance against the compromised Gmail account. The following information was targeted in order to progress further throughout the assessment:
- Information relating to how employees access the client network remotely.
- Sensitive information relevant to the objectives of the assessment.
- Clear text passwords which could be used to gain a foothold into the client’s internal networks.
By performing more reconnaissance against the compromised Gmail Account, a number of useful details were obtained such as clear text passwords that provided a foothold into the client’s infrastructure.
Asia Internal Network Foothold
The information gathering performed with access to the Gmail account provided details of a XenApp server and related Administrator user credentials. A number of ways exist to break out of a Citrix environment, in this instance Notepad was a published application for this user account, allowing access to Windows Explorer. From here it was trivial to run cmd.exe as no software restrictions were seen to be in place.
To summarise briefly, the team now have achieved command line access on a server located within the Active Directory forest of the network infrastructure for Asia. The next part of the assessment was to escalate privileges further to start working towards the objectives.
Escalation of Privileges
Various techniques can be leveraged to escalate privileges within an Active Directory (AD) environment, and which go beyond the scope of this blog post, further information about one way to escalate privileges within a domain can be seen in the article below:
https://www.dionach.com/blog/printer-server-bug-to-domain-administrator
One quick and common method however, although noisy depending on how it is performed, is password spraying across domain accounts.
During the enumeration of information from the Gmail account a common password kept appearing and would likely be used across domain accounts within the client’s AD environment. By modifying lines 103-104 in the PowerShell script from Nettitude’s PoshC2 project, it was possible to perform password spraying across other forests and not just the current forest where the script was being ran from:
$ForestContext =
New-Object
System.DirectoryServices.ActiveDirectory.DirectoryContext("Forest", "
test", "test.uk\USER", "Password")
$forest = [System.DirectoryServices.ActiveDirectory.Forest]::GetForest($ForestContext
)A screenshot of the modified script running is provided below, where it is testing passwords across another forest and domain:
The original script can be found at the following URL:
https://github.com/nettitude/PoshC2/blob/master/Modules/Brute-AD.ps1
With this modification, password spraying revealed a large number of accounts that were configured with a common organisation specific password including privileged accounts, particular privileged service accounts. Large organisations typical suffer from technical debt which can include accounts that may have been insecurely configured by contractors and included into privileged groups at one moment in time and forgotten. It was relatively quick to obtain the AD database of the client Asia forest and exfiltrate this information out from the XenApp server, however another mistake was made by the team that resulted in a P1 being raised by the client’s SOC. As a privileged account in the UK domain was used to remotely access a server within the Asia domain, which the account has never accessed before, an alert was raised.
A way to avoid this is to check the date modified of the User profile folders, by connecting to the ADMIN$ or C$ share on the target server and determine when it was last modified to verify the frequency in which the account is used and whether the accounts access the systems or not.
At this point of the assessment as the phases started to progress, nerves were running a little high as a P1 alert was raised by the SOC and whether time would be limited with regards to access to the XenApp server, and that the account had a weak password. The team had access to the entire Asia AD database where offline password cracking or pass-the-hash techniques could be used to move laterally across to another domain, as discussed in part 2 Additionally, during access to the Asia forest a snapshot of the Active Directory structure was taken using Sysinternals Active Directory Explorer to assist in future offline AD querying. This approach was taken as the tool could be accessed via WebDAV and ran without touching disk, additionally the tool used LDAP queries that would blend in with the client environment.
Part two of the blog series continues with lateral movement into the UK network in order to achieve the objectives.