Attackers Now Build Phishing Pages With AI App Builders

The credential-harvesting page in this campaign had a valid TLS certificate, a clean domain reputation, and a URL that most email filters were happy to wave through. It was not served from a bulletproof host in a sketchy corner of the internet. It was built with an AI app builder, the same kind of no-code tool a marketing team might use to spin up a landing page over lunch.

The domain was lovable[.]app. The subdomain was slide-verify[.]lovable[.]app. And the reason it worked is the reason this keeps happening: a reputation system cannot flag a platform that has not earned a bad reputation yet.

Here is what the pattern looks like, and why it gets worse before it gets better.

• A credential-harvesting page hosted on lovable[.]app, a mainstream AI-powered app builder, passed URL reputation and content-category filtering on the strength of the platform's clean, fast-growing apex domain.
• The lure impersonated the target's own internal IT department and wrapped a fake multi-factor authentication (MFA) "ticket" in the language of a real compliance-automation vendor.
• Every email authentication check passed. SPF, DKIM, and DMARC all aligned, because the message was sent through Amazon Simple Email Service (SES) from a domain the attacker had registered only weeks earlier.
• There was no attachment and no malware. The entire payload was a single link and a single deadline.
• Themis, the IRONSCALES agentic AI analyst, classified the message as credential theft at 90% confidence, on behavioral and community signals rather than domain or URL reputation.

Why a No-Code Builder Was the Perfect Host

AI app builders like Lovable exist to collapse the distance between "I have an idea" and "it is live on the internet." You describe the app in plain language, the platform generates it, and it deploys to a subdomain on the platform's shared apex, complete with automatic TLS. That is a genuinely useful product. It is also, for an attacker, a nearly free credential-harvesting kit with the reputation problem solved in advance.

The phishing page lived at slide-verify[.]lovable[.]app. The subdomain name did the social engineering: "slide-verify" implies a routine slider or CAPTCHA-style verification step, the kind of friction users are conditioned to click through without thinking. Behind it sat a credential capture flow. The technique is textbook spearphishing via link (MITRE ATT&CK T1566.002). What changed is the host.

To a secure email gateway (SEG), the legacy appliance that scores messages on sender and URL reputation, none of this registered as hostile. The apex domain is young, popular, and clean. It hosts thousands of legitimate apps. Blocking lovable[.]app wholesale would break real business tools, so most reputation feeds do not, and the malicious subdomain rides along. The attacker borrowed the platform's trust and paid nothing for it.

The Lure Was Your Own IT Department

The email announced itself as a message from the recipient company's IT department. It referenced a "scheduled update to your login credentials and Multi-Factor Authentication settings" and gave a same-week deadline to complete the steps or risk being "signed out or locked out." One button. One task. Complete MFA/Password update ticket.

The polish went a step further. The footer dressed the request up as a task triggered by a real compliance-automation platform, telling the recipient the ticket existed because their company "is using Vanta to earn and prove trust." That is the language legitimate compliance tooling actually uses, and it is exactly the kind of detail that turns a generic phish into something a busy employee acts on.

No malware was needed. The attack ran entirely on authority and urgency: internal IT, a compliance mandate, and a clock.

The Authentication Trap

Here is the part that should bother anyone still treating an authentication pass as a safety signal. This message passed everything.

The From domain was a healthcare-themed domain the attacker had registered only weeks before the campaign, then wired up through Amazon SES. Because the domain was properly configured, SPF passed, DKIM passed with a valid signature, and DMARC aligned to the header From. Microsoft's own filtering saw a cryptographically authenticated message from a domain with no prior bad history.

Authentication tells you a message was sent by who it claims to be sent by. It tells you nothing about whether that sender is trustworthy. A domain registered last month, sending through a reputable email service, will pass SPF, DKIM, and DMARC every time. Attackers know this, and newly registered domains routed through legitimate mail infrastructure have become a standard delivery pattern. According to the 2026 Verizon Data Breach Investigations Report, credentials are involved in 39% of breaches across the full kill chain, and phishing remains the initial access vector in 16% of breaches. Credential-driven intrusions are also expensive to unwind: breaches that begin with stolen or compromised credentials take the longest of any vector to identify and contain, an average of 292 days, according to the IBM Cost of a Data Breach report.

See Your Risk: Calculate how many threats your SEG is missing

Reputation Lag Is the Whole Game

Strip this campaign down and the technique is not really about Lovable. It is about timing.

Every fast-growing SaaS hosting platform goes through a window where it is popular enough to be trusted and new enough that abuse has not caught up to it. Reputation and threat-intelligence feeds are backward-looking by design. They score a domain on what it has done, and a young app-builder apex with a flood of legitimate deployments looks pristine. Attackers have learned to operate inside that lag, moving from platform to platform as each one's abuse detection matures.

We are seeing the same playbook move onto AI app builders, and the shift matters because the page itself is now faster to produce. You no longer need to clone a login portal by hand. You can describe one and have it deployed, on a trusted apex, in minutes. That is new. The underlying move, though, is old: Microsoft's Digital Defense Report has documented how attackers increasingly abuse legitimate cloud and hosting services to launder trust and dodge reputation controls. AI builders are the newest link in that chain, not a break from it.

This is why URL reputation as a primary control is a losing position. The malicious content is not on a known-bad domain. It is on tomorrow's known-bad domain, today.

The Indicators

What Actually Catches This

If reputation cannot see it, detection has to come from behavior and context. That is where this message fell apart under scrutiny even though every static check passed.

• The destination did not match the sender. The email claimed to be internal IT, but the only actionable link pointed off to a third-party app-builder subdomain with nothing to do with the company's real identity infrastructure. Adaptive AI models weigh that mismatch directly rather than trusting the domain.
• The sender had no history. A first-contact domain issuing an urgent credential request to a finance mailbox is a behavioral anomaly, regardless of how well it authenticates.
• The community had seen the shape before. Across the IRONSCALES network of more than 35,000 security professionals, patterns like this one get reported and correlated in near real time, so a "clean" new domain does not stay unscored for long. That signal is a core part of how the IRONSCALES human element closes the reputation gap.

Themis combined those signals and classified the message as credential theft at 90% confidence, without waiting for lovable[.]app to appear on a blocklist. Detection that leans on Adaptive AI and behavioral analysis is the only thing that reliably sees an attack whose entire strategy is to look new and clean.

A few things worth hard-coding into your program:

• Treat authentication as identity, not safety. SPF, DKIM, and DMARC passing is table stakes, not a verdict.
• Stop weighting URL and domain reputation as a primary block signal for credential-harvesting links. Assume the hosting platform is trusted and the page is not.
• Give users a fast, friction-free way to report the "IT ticket" that feels slightly off, and feed those reports back into detection. This mirrors the network-defender guidance in the joint CISA phishing advisory.
• Layer behavioral credential harvesting protection on top of your existing gateway, so a clean domain and a valid certificate are not enough to reach the inbox.

The next campaign will not use Lovable. It will use whatever platform is popular, clean, and one step ahead of its own abuse team. The defense that survives that churn is the one that stopped trusting the domain in the first place.