Closed binary-blurb closed 5 years ago
Well, as a quick and dirty fix, you could simply submit the credentials to King Phisher a second time but use the username and password fields differently. Something like {{ request.parameters['username'] }}-mfa
with Jinja then include the authentication token in the password field. That would render as a new credential submission.
It'd be pretty straight forward for us to add an additional column to the credentials table to store this more long term. We'd need to figure out how to associate it with a previously submitted credential but that wouldn't be a big deal.
I would really like to see King Phisher have the ability to then use the authentication information to open an HTTP session and keep it alive by simulated browsing. I don't think that will be a reality any time soon though and we've instead talked about looking into integration with other tools that are purpose built for this type of scenario.
I see the Jinja documentation stuff, but had yet to dive that far into King Phisher beyond using some of the more simple variables in my emails. Would that parameter be embedded within my cloned site and it would pass the parameter username and mfa to KP instead of username and password. Is that right, or is it still passing the password form field ID, which I could clear with an onclick event after cred submission to prep for MFA submission via the same password form field (clear the password but not the username)? I'll check that stuff out to see if I can do what you suggest. That would make my workflow a bit simpler. The new credential submission would be fine as long as the username is the same. I read some other documentation where just the password won't be stored, so the username must be passed with the password and / or MFA code. And to be clear, KingPhisher will not accept WebKitForms in like an XHR, right? Only key value pairs? I tried to make the user experience of getting phished a little cleaner using onSubmit events with some JavaScript to send form contents via XHR so the page doesn't reload, but I haven't been able to get those values into KP.
I agree with that third paragraph. That pie in the sky crossed my mind for automatically relaying creds, scraping auth portal forms, putting in the credentials on the auth portal I'm attempting to gain access to, POSTing them, and then automatically submitting a GET request every 5 minutes or so to keep the session alive. Would be great to not babysit the campaign to ensure the temporal MFA codes can be used... That'd be sick, but complex for all the different portal types.
Yeah, KP only processes data submitted in either GET or POST parameters. Technically you don't need to use the same HTML form, as long as the data gets POST'ed to the KP server with the session cookie, it'll get stored. If you are having the credentials on one page, then an MFA on a second this would be pretty easy, you'd just have the second page reflect the username back in a hidden HTML field via Jinja.
If you wanted to do it in javascript, that should be doable as well, you'd just need to have an event for when the user submits their MFA code and be able to access the username they had in the original login form.
WebKitForms sounds like something we might be able to look into adding, you're the first person to ask about them.
Tagged this as "Feature Request", think the gist is that the Credentials should have optional storage for a second factor authentication token. I say "second" instead of multi because adding an additional property / column to credentials would be the easiest and most straight forward way of addressing this. Truly support an arbitrary number of authentication factors would require us to implement a many (auth factors) to one (credential object) relationship which seems overly complicated given that 99% of what's out there is just going to require a second input of some kind.
We've got this scheduled for v1.13.0 now. It'll be rolled up with a couple of other changes into what will become database schema version 9. Setting the status to in progress since I'm getting started on the initial changes now.
Alright, you can now add mfa-token
parameters to the standard credentials one. See the documented mfa-token parameter aliases. The credentials tab now has "Show Secrets" instead of "Show Password" and when selected it will show the Password and MFA Token columns. See commit 93d73b64ec12f5fd05eae2bd16abba11c8234144.
This feature has now been added to the dev branch. To obtain the changes, you can either wait for them to be merged into the master branch (which will likely take a few weeks) or you can obtain them immediately by opting into beta testing.
Hey KP Team,
First off, thanks so much for putting this software together. I am starting to see multi-factor authentication deployed on more of the services that I am phishing credentials for. I like to do everything in King Phisher when it comes to phishing, so I was curious what the possibility was of having KP not only scrape and store the 'username' and 'password' parameters, but also a parameter like 'mfa'. In practice, this functionality would have the normally cloned web page with the MFA field initially hidden. On click of submitting credentials, some JavaScript or jQuery would be used to reveal the MFA code field and it would prompt the user to enter their MFA code. On the threat actor side, the cred would be received, punched into whatever authentication portal, the user would receive their code to their phone or use their rolling token, punch it into the KP page, and then the attacker would manually relay the MFA code in a time restrictive manner to the authentication portal that they are attempting to gain access to.
Just curious on the potential to put something like this into place. I've been working with the lack of this feature by posting the MFA code to a PHP script that writes it to a file in the interim (similar to setoolkit), but I wanted to hear your thoughts. I'd be happy to throw some coins your way if you'd consider.
Thanks for reading!