OKIOK attended the annual NorthSec event, and participated in their CTF. One of the tracks was named “OuYaYa intranet”, and its objective was to compromise an intranet from an external perspective. It was created by David Lebrun (@davidlebr1), and proved to be realistic, challenging and fun. We were a few steps away from completing it during the CTF, but the whole track would have yielded a whopping 28 points. This post consists of its writeup.
First flag
Description
| Date: 20 May2022 |
| Ouyaya Intranet is a world class network architecture that |
| is built to resist to the most advanced attacks. Everything has been meticulously |
| designed to bring ease and security to our employees. You can still take a look |
| but you won’t find much, there is only our Exchange server exposed for our |
| employees to have access to their emails from the internet. |
| Our Web Development Lead, Ph a.k.a Pete Achety, can also testify the robustness |
| of the environment. He developped awesome tools and contributes to multiple open |
| source projects. I will let you find his Github, OSINT should be in your blood right? |
| Anyway, if you still want take a look, here is the link: |
| [Ouyaya Email Access](https://mail.yrr.ctf) |
| Rosie Meyer – A+, Server+, CCNA, CCNP, CCIE, MSDST, CSM |
| Network Admin |
| rosie.meyer@yrr.corp.ctf |
Resolution
The challenge introduction mentioned an external Exchange server that could have been the internal network entry point. While browsing the OWA of the Exchange server, nothing came up.
Popular vulnerabilities such as ProxyShell were attempted, but without success. It appeared that the first step was not a software exploitation, as it is less and less the case.
The challenge description also mentioned a Web developer, Pete Achety, his GitHub and OSINT, it was a clear indicator on which path should be followed.
Pete’s GitHub profile was quickly discovered as his username was its first and last name hyphenated.
He had only one repository, which was mostly empty, except for his initial commit and one issue. The issue was opened by Rosie Meyer, the author the challenge introduction and Ouyaya’s network administrator.
Her GitHub repository was empty, and her only activities were the issues raised on Pete’s repository.
OSINT for Pete and Rosie proved unfruitful. Fortunately, what we were looking for was not in the repository itself, but on a GitHub Gist.
By visiting the page of Rosie’s GitHub profile, a list of about 100 usernames, which could be the users of the internal network, were found in the file “yrr-users.txt”.
With a list of potential users, the typical attack path is to attempt to check for weak password. Using Ruler, a password spraying attack was performed on the Exchange Server with various popular passwords, such as “Password1”. When using a password policy that forces frequent password change, users are sometime changing their password based on the current time of the year. As the CTF was taking place in May 2022, we started with the password “May2022”, 4 users were using it. This password was also hinted in the challenge description.
Login into those accounts and reviewing their email led us to the first flag we found for that challenge. It was in “mikhail.volkov” mailbox.
Second flag
Description
| Really? But… how is that possible? Our password policy is very robust with at least 7 characters. |
| Anyway, it’s just an email account. You won’t go further. |
Resolution
The body of the email that contained the first flag also hinted at the next steps for the second flag.
The email, from Anatoli Boon, mentioned that he is expecting an email from Mikhail and that he had set up an automated script to respond when a URL pointing to the document was received, instead of an attachment, to bypass the security policy. This might be a little too realistic.
We created an executable payload in Cobalt Strike, hosted it on the machine for this purpose (shell.ctf) and sent the URL to Mr. Boon.
After a few minutes, the payload was fetched and executed, which gave us a remote shell with Mr. Boon permission on the system named “WKST01”.
Youpi as they say in French!
The second flag was on the desktop of the compromised machine.
Third flag
Description
| Ahhhhh, this is the kind of thing that I was afraid of. |
| I remember this request for Anatoli Boon. I should have not |
| allowed this script. |
| But… you know what? I think that you are out of scope. |
| I thought you were only looking from an external point |
| of view. |
| Screw it, at this point continue your work and let’s see |
| how far you can go. I hope that… nevermind. |
Resolution
From there, we had low privilege access on WKST01. We attempted local privilege escalation, as it is a typical path in CTFs.
The directory “C:\script” contained scripts for the previous challenge. The script “run.bat” revealed the password of anatoli.boon. Even if we had a session with this account, having its password allowed more persistence.
At this point, we preferred an RDP session on WKST01, so we spawned up a SOCKS proxy through our Cobalt Strike session, and started an RDP session through the proxy to obtain a graphical session.
The popular tool WinPEAS was executed to check for common misconfiguration that could be abused to local privilege escalation. It listed the service “yrrservice” on which our user had full access.
Since the service was run by the user SYSTEM, it was clear that this path could be taken to obtain high privilege access on the system.
The path executable of the service “yrrservice” was changed to an arbitrary value, which corresponded to our payload.
By starting the service, a connection was obtained as SYSTEM on WKST01, and the flag could be retrieved on Administrator desktop.
Fourth flag
Description
| At this point, I believe that you know what you are doing |
| and you must be a great hacker. I don’t even know how |
| you could get Administrator rights on an employee workstation |
| that is hardened. |
| We have a web application portal for our employees. Would you |
| have the time to take a look at it? |
Resolution
The description pointed to a Web application, and it consisted of two web challenges created by Marc Olivier Bergeron (@mo_bergeron).
During the internal recon, we obtained a list of the domain computers, one of them was called WEB01. It hosted the employee web portal that was in the challenge description.
Having the password of anatoli.boon, we used it to log in and quickly found a section of the application contained three files, one of which had a 0-point flag.
Fifth flag
Description
| Great you have found the web portal. I wonder what you could |
| find with your skills. The web application was developped by |
| Pete Hachety and it should be free of vulnerabilities. |
Resolution
The 0-point flag confirmed that the next challenge was to compromise the web application.
The web application had different sections, and only two of them were accessible with our current privilege. We also tried with other accounts that were compromised during the Exchange server password spraying, but without success.
Sections that were accessible were “Documents” and “Users”. The section “Documents” was mostly static and might have already served its purpose with the zero-point flag.
However, the section “Users” was a list of internal users with a search functionality based on their name. We though that it screamed SQL injection, and we were right.
By using sqlmap, we discovered an injection point with, among other techniques, stacked queries.
Two tables were found and were dumped successfully. The analysis revealed that specific users had high privileges. This was reflected in the value “role_id”. Since password values were in the form of a SHA512 hash, it was clear that the challenge was to change the “role_id” of an account that we controlled, rather than cracking hashes.
Since the SQL injection was performed with stack queries, it allowed more than only extraction. We were also able to execute UPDATE queries on the database to change the “role_id” of our user.
The command executed successfully, and we were able to obtain the fifth flag after logging in with the new privileges.
Sixth flag
Description
| Eh, this is…ehh… WHAT!? What is that? You said SQL Injection? |
| I will get in touch with Pete, he might be able to give me |
| more details on this. |
| I guess you can continue…I fear of where it will bring you. |
Resolution
At this point, our privileges gave access to three new sections. In “Upload”, we could upload document file to the server. However, our attempts all concluded with an application error.
In “Update”, we were presented with a button “Update” that was clickable.
In “Error Logs”, we could see the server error logs, starting with an interesting entry “C:\inetpub\OuYayaDocuments\wwwroot\update.bat” at the beginning of the logs. The rest of the logs were errors from our SQL injection previous attempts.
We connected the three sections together and created this scenario: the “Update” button calls “update.bat” at the location in the log, and we upload at this location with the Upload functionality.
This scenario was performed, by uploading a payload at the specified path and executed it with the “Update” button.
It gave us a low-privilege session on WEB01 with the web server role
The flag was waiting for us at “C:\Users\Public\flag.txt”.
Seventh flag
Description
| No one told me about this feature in the web application. |
| To be honest, I don’t even have administrative access |
| to the web portal. |
Resolution
From our low privilege access, we wanted to promote it to a high privilege access on the web server.
The privileges of our users were listed and the interesting one “SeImpersonatePrivilege” was set for our user.
The exploit Sweet Potato could be used to perform the local privilege escalation.
By exploiting it, we got a connection and were able to retrieve the seventh flag on the administrator‘s desktop.
Eighth Flag
Description
| So… if I understand, you were able to obtain Administrator privilege on WEB01. |
| If yes, I don’t know what to say. I think this is too much for me. |
Resolution
In a previous step, we tried to perform privilege escalation on the network instead of on the workstation. This gave us information on the domain hosts and their configuration. One of them was constrained delegation set up from WEB01 to EXCH01. Having compromised WEB01, we knew that it would be the attack path.
We requested a delegation TGT for our user WEB01$ and used it to request a TGS for EXCH01$ that had full access to EXCH01.
At this step, we had a ticket for WEB01 that was allowed to perform action as EXCH01 with high privileges. The flag was again on the administrator’s desktop.
Ninth flag
Description
| Did you bought a 0 day? I know that some APT are buying 0 day to reach their goal. |
| At this point I believe that you can stop here. Anyway, you won’t be able to access the domain controller |
| since the antivirus is up-to-date and running. |
| Well, you can waste your time on it. |
Resolution
The last flag was obtained by gaining access the domain controller. As it is often the case in internal network pentests, the domain privileges were lax and could be abused. Having control of EXCH01, we noticed that this machine account could add members to the important AD group “Entreprise Key Admins”.
The controlled user account, anatoli.boon, was added to that group. “Enterprise Key Admins” was a target of interest because its lax privileges gave it control over domain admins.
With the newly obtained domain administrator privileges, we performed a DCSync attack. Even if the antivirus was enabled on the domain controller, the DCSync is performed with DRSUAPI technique, which is usually not detected.
It allowed us to retrieve NTLM hashes of domain users, including the ones of a high privileges account. In the end, it was possible to retrieve the flag on the domain controller by using a domain administrator privileges which completed the track!