Most phishing simulation platforms stop at the click. A user opens an email, taps a link, and the report says they failed. That may be enough for a compliance dashboard, but it is not enough to show what a real attacker could do next. The PhishU Framework now puts transparent Adversary-in-the-Middle, or AiTM, proxying behind a click of a button. Instead of stitching together separate tools, writing phishlets, and keeping up with browser changes by hand, operators can launch an authorized AiTM assessment from the same platform they already use for domains, landing pages, email delivery, analytics, training, and reporting. That matters because AiTM is where phishing turns from a user-awareness problem into a business-risk problem. If a target signs in through the proxy, the operator can capture the login flow, collect the resulting session material, and demonstrate what actual account takeover risk looks like in practice. Transparent AiTM proxying is configured directly inside the PhishU Framework, not through external phishlets or separate infrastructure. What Transparent AiTM Proxying Means At a high level, transparent proxying places the phishing infrastructure in the middle of the login conversation. The target believes they are interacting with a familiar sign-in experience. The real identity provider still receives the authentication traffic. The difference is that the proxy is in the path, observing the exchange and capturing the pieces that matter for a defender-led assessment. In the PhishU Framework, that capability is built into the product. There is no need to stand up separate infrastructure, babysit configuration files, or bolt on external reporting after the fact. The operator works inside the same interface used for the rest of the phishing workflow. That single workflow is a big part of the value. The hard part has never been understanding what an AiTM proxy is. The hard part has been getting one working reliably, keeping it alive, and integrating it into an engagement that still needs domains, email, tracking, evidence, and training. PhishU handles that end to end. From Click to Session Hijack, in One Workflow When defenders talk about phishing risk, stakeholders often hear one thing: someone clicked. That is not the same as showing that a real account could be taken over. AiTM changes that. If the target successfully authenticates through the proxy, the framework can capture the resulting session data and let the operator demonstrate downstream access risk with a point-and-click session jump. That is a very different conversation with a client, executive team, or internal security stakeholder. A report that says, "an employee entered credentials" gets attention. A report that shows, "this is the inbox, tenant access, or cloud session an attacker could have used next" gets action. Inside the PhishU Framework, that workflow is deliberately simple. The operator sees the captured session appear in the interface, gets a real-time notification that the authentication succeeded, and can use the built-in Session Hijacking option to jump directly into the authenticated session from within the Framework workflow. That one-click handoff is a big part of what makes the capability practical. It turns a technically complex attack path into evidence a client can understand immediately. The Framework alerts the operator as soon as a live session is captured, making it easy to move from delivery to evidence collection in real time. Session Hijacking is exposed as a direct in-product action, so operators can demonstrate real downstream access risk without leaving the Framework. That is also why this capability belongs in a phishing platform built for red teams, pentest firms, MSSPs, and internal security teams. It closes the gap between generic awareness testing and realistic adversary emulation. Support for Major Identity Providers, Including Google The Framework's transparent proxy capability is designed for the identity platforms organizations actually use. That includes major IdPs and cloud login experiences such as Google. For defenders, that matters because the value of a phishing assessment rises sharply when it tests real authentication surfaces instead of toy examples. Google is a good example. Security teams already know Google sign-in flows are not simple static login pages. They involve modern browser behavior, evolving authentication steps, and active anti-phishing controls. Supporting that environment is not a checkbox feature. It is a sign that the platform is being maintained against real-world sign-in surfaces, not abandoned after a demo. PhishU's approach is not to expose all of that complexity to the operator. The point is the opposite. The platform absorbs the complexity so the operator can run an authorized assessment without becoming a full-time Evilginx maintainer. Google is one of the major identity-provider environments the Framework is built to support for authorized phishing assess...