Azure x11 Compromises = Tycoon

Introduction

In Feburuary, 2024 ProofPoint posted an article regarding a Linux user agent string being involved in multiple Azure Account Compromises. Common compromise can be identified by observing the user agent string:

“Mozilla/5.0 (X11; Linux x86_64) AppleWebKit/537.36 (KHTML, like Gecko) Chrome/120.0.0.0 Safari/537.3”

with a successful login from the OfficeHome application ID:

“4765445b-32c6-49b0-83e6-1d93765276ca”.

Until recently this was quite prevalent with multiple online posts reporting this user-agent string.

The scenario of observing a linux agent logging into a user may be rare but it is not a main indicator of compromise. There may be scenarios where users may login from linux servers or devices which would provide a similar user agent. However, this specific user-agent seems quite prevalent, with an extremely high true positive rate. Another indicator would be a “failed login” from a mfa challenge followed by successful authentications shortly after, as most phishing portals will attempt an authentication after submitting your user_id and password, then prompting a mfa request if the challenge failed. This will be followed by a “keep me signed in prompt” to issue a persistent token.

Initial

I have observed a variety of different open-source websites that will either contain a link or a html document that will link you towards the phishing page. There’s been a mixture of phishing lures that have been targeted versus generic with almost all posing as a fake document. Most phishing appear to originate from emails, however there has been evidence of social media also being used as an initial communication vectors .

Defense Evasion

Once the user clicks on the link posted on the website they will first be sent to a cloudflare verification to check that it is a user proceeding to the website. During this time we observe obfuscated javascript being loaded into the browser session.

Masquerading

Following the verification they will then access the portal, which poses as a legitimate Microsoft logon page. Once visited this page it will attempt to “automatically sign you in” but this is to just appear more legitimate and will not automatically sign you in even with an active session in the same browser. Even when previously authenticated it will still prompt for your username and password.

Tycoon Confirmation

During this process a unique “session” will be assigned as it uses websockets to establish a connection with the threat actors infrastructure. Once this is established, in developer mode console you can also view a “Connected to server” show up. Looking further into the elements we observe that the first thing to be loaded is an obfuscated java script from the attacker’s server. This javascript is extremely similar to previous Tycoon PAAS analysis by TrustWave https://www.trustwave.com/en-us/resources/blogs/spiderlabs-blog/breakdown-of-tycoon-phishing-as-a-service-system/.

Trustwave has completed a very detailed breakdown of how Tycoon PAAS works so we will not include it here. But the basic steps are as follows:

User receives phishing email or link
User visits public website with phishing lure (fake shared document)
User passes cloudflare check
User visits website
Tycoon PAAS loaded into session.
Websocket connected
Data is transferred as user enters credentials
Credentials are tested and responses are loaded into the portal depending on results
If successful, the user is redirected to a “document” or a Microsoft Error.

Enumeration

When visiting the portal, location data is originally captured in a GET request to “ipapi”, which will query your ip_address. This information seems benign but becomes quite important for threat actors following the initial compromise. They may be able to use this data to bypass geo-based conditional access policies or to blend in with normal traffic during the post-compromise phase. Your user-agent string will also be captured.

Exfiltration

When the username and credentials are entered the Phishing portal will automatically send and test these inputs through the established websocket. Depending on the results from the server testing the input you will get a response accordingly through the web socket. If you input a legitimate email, you can see a “correct email” response received by the websocket. You can also view what is going out through the websocket which includes the following:

Email Address
Ip-location Data
User-Agent String
Password

Authentications

Have confirmed on multiple Tycoon portals that during the automated process you will observe sign-ins to OfficeHome with the aforementioned user-agent string.

“Mozilla/5.0 (X11; Linux x86_64) AppleWebKit/537.36 (KHTML, like Gecko) Chrome/120.0.0.0 Safari/537.3”

In some trails no MFA prompt was received and it authenticated straight into the account as "single-factor-authentication". Other times when trying it requested for MFA and as usual would prompt my authenticator. This will definitely need to be looked into further as there appears to be a massive disparity in when MFA works and does not.

Conclusion

Once the phishing process is completed you may be redirected to a “fake document” or receive a “Microsoft Sign-in error”. Thus, at this stage it appears the mentioned user-agent account takeover by proofpoint is related to Tycoon PAAS portals automated phishing.

Microsoft Error

References: