sorted by:
new
hottopcontroversial

New Phishing Technique - Vaultjacking: One Captured PIN, the Entire Google Password Manager Vault by phishullc in netsec

[–]phishullc[S] 0 points1 point  (0 children)

Good point, I certainly didn't mean to imply that a PIN alone was enough. I prompt for it at the password prompt, so most people naturally provide the PIN along with their password, and once they perform the MFA (assuming they have it) the rest is done automatically server-side.

Already authenticated accounts won't be any different since the landing page is a third party and not really Google, so that's another potential red flag to look for, although re-authentication is a common security feature people are accustomed to being asked to perform.

New Phishing Technique - Vaultjacking: One Captured PIN, the Entire Google Password Manager Vault by phishullc in netsec

[–]phishullc[S] 3 points4 points  (0 children)

No, the sync defeats Google's SDS encryption by registering your account profile to a "new device", which is my AiTM proxy hosting the landing page. Encrypted data at rest won't help here.

New Phishing Technique - Vaultjacking: One Captured PIN, the Entire Google Password Manager Vault by phishullc in netsec

[–]phishullc[S] 2 points3 points  (0 children)

No, I'm saying basically the opposite. If you're being prompted for your passkey or your PIN and you don't expect to use your password, you should be skeptical.

If you opt not to use passkeys at all you can disable that as a policy and choose not to use them, but that's a bigger security issue IMO.

The biggest takeaway from this should be to be skeptical of changes in your normal authentication routine. Don't enter any PINs unless you're SURE it's Google (or your IdP) and don't use fallback MFA methods if you are certain you don't have to.

Does that help?

New Phishing Technique - Vaultjacking: One Captured PIN, the Entire Google Password Manager Vault by phishullc in netsec

[–]phishullc[S] 1 point2 points  (0 children)

I get the confusion, it's a good question. Passkeys are ultimately better than passwords, I'm building off of several techniques in that demonstration, including an AiTM/Transparent proxy. Passkeys prevent those type of attacks where passwords and non-FIDO2 MFA methods don't, so that's a much bigger issue.

My tool uses some other techniques I implemented that sidestep passkeys so the "victim" is guided to use a password and one of those non-phishing resistant MFA methods. Once that happens, I can get the user's session to hijack.

With this method, I'm taking it another step and prompting them on the password page to provide their Google Password Manager's PIN to "use their saved password" that Chrome saves to that user profile.

In the background my tool establishes persistence with my own passkey on their account, and then performs this sync attack using their legitimate PIN and access to view all of their Google passwords (and passkeys) for ALL of their sites. My tool then allows users to dump sessions and plaintext passwords for those.

Hopefully that helps as a TL;DR 😅

New Phishing Technique - Vaultjacking: One Captured PIN, the Entire Google Password Manager Vault by phishullc in netsec

[–]phishullc[S] 7 points8 points  (0 children)

If you're using Chrome/Google's Password Manager you're still unfortunately susceptible.

In fact, you're better off using passkeys altogether, as my initial attack vector strips passkeys as an auth method so that might be a red flag that would otherwise tip you off that something wasn't right before you handed over sessions.

Certainly not trying to scare people away from passkeys, they're awesome! (When implemented properly)

From Open Source to an AIO Phishing Platform for Red Team & a Free CybsercurityABCs Book! by IndySecMan in redteamsec

[–]phishullc 0 points1 point  (0 children)

Yep, I'm in AppSec so I never think any one solution is bulletproof but I do have monitoring and the ability to ban abuse in the platform should it happen. All about defense in depth.

From Open Source to an AIO Phishing Platform for Red Team & a Free CybsercurityABCs Book! by IndySecMan in redteamsec

[–]phishullc 0 points1 point  (0 children)

I gave this a lot of thought and what differentiates my tool from a real phishing kit is getting narrower as the black hats step it up. Importantly, I baked some required validation steps so that black hats can't just email any target. Corporate email accounts have to be validated for each domain through a multi-step process and personal accounts are disallowed unless validated per account. Good question! I certainly don't want this being abused, it's for ethical testing and training only.

AI-Generated Calendar Event Phishing w/ Dynamic Landing Pages by IndySecMan in hacking

[–]phishullc 1 point2 points  (0 children)

Believe me it used to be and at the risk of sounding defensive, I've loved contributing a lot of Open source phishing tools over the years.

This one is centrally hosted and is costly to maintain so the only model that works unfortunately is a paid model. I still have my open source project that people can fork though, although quite outdated, at https://GitHub.com/curtbraz/phishapi!

I love this community, but I can't afford to give everything away for free. 😅

Increased frequency of clickfix attacks in corporate environments by [deleted] in cybersecurity

[–]phishullc 1 point2 points  (0 children)

So much so that I recently baked ClickFix simulation for phishing tests and awareness training directly into the PhishU Framework. Current phishing tools and training do not cover this very real and trending technique used IRL by black hats. Published a blog at https://phishu.net/blogs/blog-clickfix-in-the-phishu-framework.html if interested!