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.comURL 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:
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.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.
Subdomain name:
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:
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://twitter.com/JeffreyAppel7/status/1591911982848172032/photo/1
https://github.com/kgretzky/evilginx2
https://github.com/drk1wi/Modlishka
https://github.com/muraenateam/muraena