Skip to content
New issue

Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.

By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.

Already on GitHub? Sign in to your account

adding support for static locations #227

Open
wants to merge 1 commit into
base: master
Choose a base branch
from

Conversation

ImpostorKeanu
Copy link
Contributor

Hi,

I recently wanted to chain two Modlishka instances together to form an authentic ruse but there was a problem that resulted in a functional patch. I've tested it on an active engagement without issue and thought it would be beneficial to contribute.

The Problem

  • The first Modlishka server proxied for a Citrix ShareFile service
  • During SSO authentication, the victim's browser was redirected from ShareFile to Microsoft
  • I wanted to proxy for this domain as well while maintaining authentic hosts as opposed to encrypted hostnames
  • Current logic did not facilitate updates the FQDN of the Location header while rewriting the HTTP response
  • This broke the man-in-the-middle position, resulting in the victim's browser being redirected to login.microsoftonline.com

The Solution

  • A new configuration parameter, staticLocations, was added that allows configuration of allowed FQDNs in the Location header that will not be converted to the current phish domain via runtime.RealURLtoPhish
    • This allows us to control which upstream locations the Modlishka proxy will forward to
  • A patch to the function that rewrites the response body was applied that:
    • Updates the location header with all values in runtime.ReplaceStrings
      • This allows one to update the FQDN in the location header to the desired host
    • Searches through each static location and determines if the Location header should be updated via runtime.RealURLtoPhish
      • If a match on a static location is observed then it will not be updated to match the phish FQDN
  • Once authentication is finished, a termination is triggered that results in the victim being redirected back to the ShareFile page to download a malicious payload :)

The Outcome

I refer to each Modlishka server as a stage to make this easier to digest. The sections below describe each server configuration and the final request flow.

Server Configurations

This configuration allowed me to chain two Modlishka servers:

Stage Alias Phish Domain Origin Domain
1 S1M SharFile.com ShareFile.com
2 S2M Ophish365.com MicrosoftOnline.com

Note: Alias S1M reads like "Stage 1 Modlishka"

S1M Configuration File

{
    ...
    "rules":"bWljcm9zb2Z0b25saW5lLmNvbQ==:b3BoaXNoMzY1LmNvbQ==",
    "staticLocations":"login.ophish365.com",
    ...
}

S2M Configuration File

{
    ...
    "rules":"d3d3LnNoYXJlZmlsZS5jb20=:d3d3LnNoYXJmaWxlLmNvbQ==",
    "staticLocations":"www.sharfile.com",
    ....
}

Final Request Flow

  1. Victim clicks phishing link; lands on www.sharfile.com
  2. Clicks "Sign In"
  3. S1M rules configuration changes login.microsoftonline.com to login.ophish365.com
  4. S1M observes that login.ophish365.com is a staticLocation value, redirects to S2M
  5. S2M receives redirect; renders login.ophish365.com
  6. Victim submits valid credentials
  7. Victim's browser lands on the /kmsi resource, provoking termination and redirect back to www.sharfile.com
  8. Profit by injecting static HTML page with link to MalDoc

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
None yet
Projects
None yet
Development

Successfully merging this pull request may close these issues.

1 participant