Stealing Session Tokens and Credentials with Modlishka

As a member of a small Red Team, many of the engagements I participate in operate under the “assumed breach” model. This model operates under the assumption that an endpoint in the target enterprise is already compromised or the target organization is already breached in some way. This model works well for two reasons.

1. It can take a long time to breach a network, especially for a smaller team.
2. Given enough time and resources, an advanced threat will be able to get into your network.

Given this, the assumed breach model allows Red Teams to focus on the later parts of the cyber kill-chain where more of an impact can be made upon the organization. However, it is still important to test your organization’s defenses against initial intrusions.

A very common technique to gain initial access to an organization is to phish the organization’s employees for credentials that give access to externally facing services. This can be done by simply cloning the login page of an externally facing service owned by the organization and using social engineering to convince employees that the cloned site is the “real” service. However, organizations are increasing their security posture by enforcing the use of multi-factor authentication. This makes credentials alone far less powerful in the hands of an attacker. But what if you could phish an employee for their session tokens as well as their credentials?

Enter Modlishka.

Modlishka is a powerful HTTP(s) reverse proxy, allowing attackers to bypass common forms of MFA. In short, a server running Modlishka will act as a middle man for all requests to the target service and all responses to the victim client.

There are several articles on the Internet describing how to download, install, and get started using Modlishka so I will skip over that and dig right into a practical example of using the tool. For this example, I will proxy Code42’s Okta Single Sign-on Page. I will use the domain code42.c42-sso.com to host the reverse proxy.

Unfortunately, pointing the tool at code42.okta.com and running it doesn’t work right off the bat. As you can see below, the login functionality on the page is not rendered at all.

We can use Burp Suite to inspect the response and see what went wrong.

In the HTTP response, the login script is loaded from a separate source then its integrity is verified by comparing the hash of the script to a sha384 hash value. Herein lies the problem. Modlishka automatically replaces the target domain with the malicious domain (code42.c42-sso.com) before returning responses therefore making the integrity check fail. Fortunately for an attacker, Modlishka is very flexible in that it allows the user to create rules that will match and replace text in the response before it is served to the victim. We can create a rule that replaces mainScript.integrity with mainScript.integrityKitten. Unless there is an “integrityKitten” attribute I am unaware of, the switch should stop the victim’s browser from verifying the integrity of the dynamic javascript resource it loads to render the login page.

Great! The login functionality is now rendered on the fake site.

Modlishka automatically rewrites URLs from the target URL to the malicious URL. However, sometimes the page needs to dynamically load resources from the real domain. In this case, you will need to create more replacement rules to replace the replacement URL with the original. It can be a bit tedious, but with the correct tweaking, you should be able to emulate the functionality of any site.

The reverse proxy is now working flawlessly in Firefox but when testing in Chrome there was some odd behavior. In Chrome, after authenticating to the proxied Okta site (code42.c42-sso.com) and providing 2FA, I am redirected back to the login page instead of my Okta home page. After inspecting the process in Burp, I noticed that Chrome was dropping my valid Okta session token after authenticating. After some research, I was able to find the cause of this odd behavior. Chrome introduced a feature in early 2020 that drops SameSite=none cookies if the cookies aren’t also set with the Secure flag. One of the features of Modlishka is that it automatically removes the Secure flag set on cookies. When the Secure flag is set on a cookie it means it can only be sent over a secure connection (HTTPs). This is cool if for some reason you want to downgrade your victim to an insecure connection and still send cookies. It’s not so cool if you want your reverse proxy to work correctly in Chrome over a secure connection.

Luckily, Modlishka is open source so we can dig through the source code and remove the functionality that removes the Secure flag from cookies. In proxy.go at line 230, the Secure flag is stripped from the cookies. We can remove this functionality and recompile the application and we are good to go! Cookies are no longer stripped of their Secure flag and the reverse proxy should work in all major browsers.

We now have a proxied login page that looks and functions exactly like the real page. The last thing to do is to develop a regex for collecting login credentials so that Modlishka knows how to collect them for us when victims authenticate to the malicious proxied site. This can be done with the help of Burp Suite and RegExr. Here is a demonstration of the final product compared to the real site.

Modlishka provides a control panel to view captured credentials and tokens.

Note: my password is not “true,”, I just changed the regex to collect garbage data so my password is not shown.

At this point, you may want to redirect the victim to the actual page or a landing page if you are running a phishing awareness campaign. This can be done using Modlishka’s replacement rules.

Modlishka is a great tool that can be used in Red Team engagements or to extend the capabilities of a typical phishing awareness campaign. For more security ops related blogs like this, check out https://redblue42.code42.com/.