Monday, November 21, 2022

Looking for EvilProxy - Notes

Introduction:

This started with someone asking about EvilProxy and any signatures for detecting it. 

EvilProxy is a phishing as a service (PhaaS), which can be used to capture credentials and cookies from a user auth, which also also works with MFA being enabled. It's essentially a reverse proxy that captures information for the attacker when you auth/start a session on a service that's doing reverse proxy for.

More information can be found here: https://resecurity.com/blog/article/evilproxy-phishing-as-a-service-with-mfa-bypass-emerged-in-dark-web

Similar projects include evilnginx, modlishka, and muraena.


Usually for http/https traffic signature, we may want to look for status code, post/get parameters & pattern, URI pattern, JA3/JA3S, cert properties, html properties/body, and etc

Here's an example for evilnginx:


https://github.com/kgretzky/evilginx2/blob/master/core/certdb.go#L400

https://twitter.com/malwrhunterteam/status/1354039003121647624


There can be multiple types of detections as well. For example, detection of a service by utilizing scanning/scan response (shodan/censys) and detection from traffic monitoring (zeek extracting cert info and logging).


In this post, I'm just documenting just methods and what I've found researching EvilProxy. I don't have anything conclusive and from screenshots/videos the EvilProxy looks pretty thought-out and I'm sure it's easy for the devs to change behavior. They let you customize pretty much everything.

Notes:

Looking at the video shared by Resecurity, I see the following:


subdomain is set to lmo by default. 


Stream BotGuard redirects to brave.com by default. Later on there is also redirect to example.com and office.com


URL GET query can have username=email@example.com but that seems optional.

URL with eqp=base64_email_address is also supported.


Some of the interesting IOC's listed by Resecurity are:

  • 147[.]78[.]47[.]250
  • 185[.]158[.]251[.]169
  • 194[.]76[.]226[.]166
  • msdnmail[.]net
  • evilproxy[.]pro
  • top-cyber[.]club
  • rproxy[.]io
  • login-live.rproxy[.]io

The other IOC comes from ThreatInsight/Proofpoint posting a domain and attributing it to EvilProxy phishing kit

  • hxxps://auth[.]royalqueenelizabeth[.]com/?

Status Code:

Searching for some of the IP's on Shodan and viewing history shows this:



Looking at webpage scan runs on Anyrun shows this:


This is what URLScan shows as well:



Maybe we can look for servers being used for EvilProxy phishing sites by looking for "444 Unknown Status Code"?

Censys Query: (services.http.response.status_code:444 and services.http.response.status_reason:"Unknown Status Code") and services.software.vendor=`nginx`

Shodan Query: http.status:444 "Unknown Status Code" "nginx"

URLScan Query: page.status:444 AND server:"nginx"

Shodan & Censys: out of 5 & 4 results, 2 IP's were publicly known for phishing.

URLScan showed a ton of data and it's easy to tell from the domain & subdomain names which sites are phishing:

The searching for 444 approach works fine but it doesn't seem to be too accurate when it comes to Shodan and Censys. It's much more useful when looking at URLScan though. 

Also, 444 doesn't show up for everything. It may have shown up for some of the domains due to misconfiguration possibly? i don't know.

Subdomain name:

The other approach for looking for EvilProxy domains could be using subdomain names (with maybe additional queries). This will likely have false positives and since EvilProxy offers a lot of configuration options, if the user changed the default settings, you wouldn't have too much success.

Some of the subdomain names EvilProxy has used are (based on VT & videos): lmo (microsoft), auth, login-live, wwwofc, accounts (google), mso (microsoft), github (github).

URLScan can be queried with: page.domain:(login-live.* OR accounts.* OR lmo.* OR auth.* OR wwwofc.* OR mso.* OR github.*) but github, auth, and accounts might lead to false positives.

This might be much better: page.domain:(login-live.* OR lmo.* OR wwwofc.* OR mso.*)


Crt.sh can also be searched for certs issued for some of the subdomains, however, that may not work very well since it looks like in the past wildcard certs were issued.

URL parameters/pattern:

One of the things we see above (in urlscan screenshot) is and in ThreatInsight/Proofpoint example is question mark '?' at the end of the URL. That could be searched for. Additionally, username= or eqp= can be searched for. Searching for /? and username= will lead to a lot of false positives. The search could be combined with some of the URLScan queries to potentially get less false positives.

URLScan query would look like this: page.url:"/?eqp=" NOT page.domain:ups.com


It kinda shows some malicious sites with some false positives. Also this search doesn't produce many results. At the time of writing, there were only 49 results.

Again, since EvilProxy is customizable, the parameters can be changed by the user. 

Redirects:

From the streams feature that was shown in the video, EvilProxy can perform actions such as redirect based on rules regarding the traffic source. Some of the defaults included brave.com, google.com and example.com. I'm sure other configuration settings include more redirections.

Only problem with this is, many sites might be doing these redirects, including other phishing kits so this doesn't mean source site is EvilProxy. The previous query for default subdomains can be combined to potentially get better results.

In URLScan this query provides results for any redirects to brave.com: page.redirected:off-domain AND ("brave.com") AND task.url:(login-live.* OR lmo.* OR wwwofc.* OR mso.*)

HTML Body:

One of the things I noticed while doing the following query: page.redirected:off-domain AND page.domain:(login-live.* OR lmo.* OR wwwofc.* OR mso.*) is that some of the screenshots for malicious websites look like this:



This results from some javascript which can be found here: https://urlscan.io/responses/e85dcff15d140f96a949d9a186c44edb2723e90073bc902d5e278ecad0d1661a/ 

I didn't spend too much time researching it but it looks like it may be trying to do fingerprinting. Some of the things in the javascript show up here: https://github.com/fingerprintjs/fingerprintjs/blob/master/src/sources/dom_blockers.ts 

Searching for javascript code that does fingerprinting in network traffic or on URLScan might be useful for hunting, however, I'd assume other people are using javascript to fingerprint so it might not always be useful.

The code kinda looks like this:



Essentially, it's title Wait... /title, script big_js_block /script, script let randomvar = base64 /script

Regex rule applied to http traffic might be able to find this maybe?

HTTP Requests:

While doing research/queries, I found a website that was not doing any redirection and is possibly EvilProxy (getting 444 on one of the pages related to this).

Traffic to this site shows the following POST request after fingerprinting:


The response looks like this:

Once that's done, a cookie with cookiekey:cookievalue get's added to the session.

There is also a websocket connection/heartbeat, which doesn't happen with real microsoft login page:



The request for sending username/password look identical for the phishing site and normal login site.

websocket, fingerprinting POST, and response with cookies might be something that can be detected on wire if TLS/SSL interception and suricata/zeek monitoring is in place.


Conclusion:

EvilProxy offers a lot of customization so a lot of stuff mentioned above can be modified the by user but some users might just use default settings. 

Without a lot of attribution directly to EvilProxy and research out there, a lot of the stuff above is just an educated guess with the information I have available. I could be wrong about a lot of things. These are just notes and not anything conclusive.

Links:

https://resecurity.com/blog/article/evilproxy-phishing-as-a-service-with-mfa-bypass-emerged-in-dark-web

https://twitter.com/JeffreyAppel7/status/1591911982848172032/photo/1

https://www.microsoft.com/en-us/security/blog/2022/07/12/from-cookie-theft-to-bec-attackers-use-aitm-phishing-sites-as-entry-point-to-further-financial-fraud/

https://github.com/kgretzky/evilginx2

https://github.com/drk1wi/Modlishka

https://github.com/muraenateam/muraena