A fake Gencat login leaks the password twice

The password leaves the fake Generalitat login twice. First, the browser posts it to Formspark, a service for collecting website forms. Then Formspark puts it into a redirect URL pointing at the real Outlook website. The visitor ends up on Microsoft infrastructure after already giving the credentials away.

That sequence is the most revealing part of the 9th October 2026 capture. The page borrows a government identity, keeps the machinery of a copied Microsoft federation login, and replaces its authentication destination with a general-purpose form collector. An ordinary service default then exposes the password a second time.

Reading the archived HTML also reveals where the imitation breaks: its “Azure Multi-Factor Authentication” option sends an empty username and a method label to the collector. It never starts an MFA challenge in the inspected code. These details explain how little of a real authentication system this deployment needs to imitate.

A Madrid login repainted for Catalonia

At icsgencat-office-portal.vercel.app, the page presents the Generalitat de Catalunya, the Government of Catalonia. Its title is “Gencat Office Portal”. The logo loads from the genuine tramits.gencat.cat host. The visible fields ask for “Correu electrònic” and “Contrasenya”, followed by “iniciar sessió”.

Under that surface, the archived landing page retains a different regional identity. Its stylesheet comes from sts.madrid.org/adfs/portal/css/style.css; the Generalitat logo still has the alternative text “Comunidad de Madrid”; and the HTML retains “Connecting to Comunidad de Madrid”. The MFA link contains a return destination at correo.salud.madrid.org/owa.

Together, these remnants point to reuse of a Madrid health-mail authentication page or a derivative of it. The return destination is a more specific clue than the Microsoft styling alone. It describes the source material's apparent purpose, not proof that the operator previously attacked Madrid or compromised either government's servers.

The adaptation is selective. The visible logo and Catalan labels changed, while English validation errors, AD FS field names, and browser workarounds survived. The source even retains code for an iPhone keyboard and Internet Explorer Mobile 10. These are inherited interface details; they do not date the phishing deployment or identify its author.

This leaves a useful family fingerprint: Catalan branding combined with Madrid federation resources. A government logo on its own is common and easy to copy. The mismatched pieces preserve a more distinctive editing history.

A sign-in button wired to a form collector

The main form's action points to submit-form[.]com/IgF5EFJ68. Its sign-in control runs Login.submitLoginRequest(). That function checks whether the username contains @ or a backslash, whether the password is nonempty, and whether it exceeds 128 characters. It then submits the form.

Those are format checks. They neither verify a government account nor test its password. The captured browser sent the synthetic values directly to Formspark as an ordinary URL-encoded POST. No government authentication response was needed before collection.

The form retains fields that sound like an authentication transaction:

The placeholder is telling: this form does not need a meaningful federation destination to work as a collector. Formspark receives field names and values without turning them into a Microsoft sign-in transaction. The copied interface supplies the appearance of authentication; the changed form action supplies collection.

For this observed path, Vercel serves the page and Formspark handles the POST and return navigation. The page therefore needs no custom credential handler on its own host. That separation makes the landing page replaceable without necessarily changing the collection destination. Whether the earlier deployments actually reused this form ID remains unproven.

Abusing a form backend is an established technique. AhnLab documented Formspree and Formspark abuse in May 2023, including submit-form.com collection URLs. The distinctive detail here is how a copied federation page interacts with the collector's redirect behavior; we found no basis to call the underlying technique new.

The redirect carries the password to Outlook

The archived exchange records three linked events: the credential POST, a Formspark HTTP 302 response, and the browser's request to Outlook. The 302 Location contains the submitted fields, including UserName and Password.

This matches Formspark's documented custom-redirect behavior: it appends submission entries to the destination's query string by default. The inspected form supplies _redirect and omits _append=false, which disables that behavior.

Below is the observed sequence with the credential values removed:

Vercel landing page
  POST -> submit-form[.]com/IgF5EFJ68
          UserName, Password, AuthMethod, destination, flags, forcedownlevel
 
Formspark
  302  -> outlook[.]cloud.microsoft/mail/?...&UserName=[redacted]&Password=[redacted]
 
Browser
  GET  -> that credential-bearing Outlook URL
       -> Microsoft's authentication flow

The leak is not an additional exfiltration script hidden in the page. It results from passing password fields through a service whose redirect default treats them like ordinary form data. The placeholder destination and other copied fields also travel into the URL. This is a mechanical consequence of the integration; we cannot establish whether the operator intended the second exposure.

The password has already reached the collector before Outlook opens. The genuine destination can make the ending look familiar, but it does not authenticate the preceding page. The browser requested the credential-bearing URL; whether Microsoft or another downstream system retained it is outside the capture. The trace does not show a successful login with the submitted credentials.

The MFA option reveals an incomplete imitation

The “Azure Multi-Factor Authentication” link looks more capable than the code behind it. Its href names the Madrid AD FS endpoint, but its click handler calls SelectOption('AzurePrimaryAuthentication') and returns false, suppressing normal link navigation.

SelectOption sets a hidden authentication-method field and submits the separate options form to the same Formspark destination. That form has no password field and no _redirect. Its hidden UserName starts empty, and the inspected code does not copy the visible username into it.

We tested both branches in a local browser using the archived HTML. Every request was intercepted and answered locally, so the experiment sent nothing to the collection service. We filled the visible username and password before each click:

This makes the second option evidence of incomplete template adaptation. It preserves the appearance of an alternative authentication method while routing a largely empty form to the collector. The offline test establishes the client behavior, not the live service's response to that branch. The original capture followed the main sign-in path.

Nothing in those branches demonstrates one-time-code interception, session-cookie theft, or a proxy relaying a real identity-provider session. Those would require additional machinery and evidence beyond an MFA label.

What links the ten deployments

On 9th October, two public urlscan searches returned the same 53 record IDs:

page.title:"Gencat Office Portal"
domain:sts.madrid.org AND filename:"Gencat_completo_B_1x.svg"

Grouping the final page hostnames and removing www variants leaves ten Vercel deployment names. The agreement between the title search and the mixed-government resource search supports a shared template family. It does not independently establish a shared account or operator.

The table gives each deployment's earliest matching public observation. Times are UTC; all dates are in 2026.

The first seven names were scanned within roughly forty seconds on 15th September. Their earliest records identify OpenPhish as the submission source. That is consistent with a feed-driven batch of observations, so the tight timing cannot date a coordinated deployment. The public records measure discovery and scanning, not site creation.

There is also evidence against reading the October names as a clean replacement wave. The September host gencat-portal-officedsk.vercel.app appears in matching records through 7th October, the day two newer names first appear. The observations overlap. We cannot infer that each new host replaced a removed predecessor.

We tested a stronger link: searching for the SHA-256 of the preserved landing response. That returned four records, all for the investigated icsgencat-office-portal.vercel.app deployment or its www entry variant. It did not establish byte-identical pages across the other nine names. An exact-hash search also misses any modified copy, so that result does not disprove template reuse.

The form ID offers a different question: do multiple pages feed the same collection destination? Search metadata does not answer it. Full public result and DOM retrieval was unavailable without authorization during this review. We therefore retain a template-family link across ten deployments and an observed collection endpoint for one deployment. Joining those into a single-operator claim would exceed the evidence.

Where the operator's infrastructure begins and ends

This deployment puts different functions under different control. The landing page is a Vercel tenant; the logos and stylesheet are borrowed resources; Formspark receives the fields; Microsoft is the exit destination. Treating every host in the request list as attacker infrastructure would obscure those roles.

For investigation, the specific form ID is more useful than the provider hostname. A match could connect collection paths across changing lures, while submit-form.com alone also matches unrelated customers. Even a shared destination would need time and context: a configured endpoint can be copied with a template.

The public form ID does not reveal the operator's workspace, notification recipients, or submission history. Formspark's API requires a bearer token and a submissions-read scope to retrieve submissions. No private workspace or submission history was accessed in this investigation.

The practical consequence is that the page and the collector are separate investigation targets. A landing-page takedown does not, by itself, establish that the collection destination has been disabled. A preservation request needs the exact form ID and the dated request evidence; a shared hosting IP is a much weaker account-level lead. We have not established what records remain available from either provider.

Indicators

These values distinguish the investigated page, its collector, and its borrowed resources. Government and provider hosts also serve legitimate users and should not be treated as malicious solely because they appear here.

Investigated phishing deployment:
icsgencat-office-portal[.]vercel[.]app
 
Observed credential collection destination:
hxxps://submit-form[.]com/IgF5EFJ68
Formspark form ID: IgF5EFJ68
 
Shared family title:
Gencat Office Portal
 
Borrowed logo resource:
hxxps://tramits[.]gencat[.]cat/web/.content/area-privada/ciutadana/logos/Gencat_completo_B_1x.svg
 
Borrowed authentication stylesheet:
hxxps://sts[.]madrid[.]org/adfs/portal/css/style.css
 
Post-submission redirect destination:
hxxps://outlook[.]cloud.microsoft/mail/
 
Captured landing response SHA-256:
f9e4e613e37c3723a6b35923abb24b99eba1ef68720c1828cee088ce6e2936c4

The response hash identifies the 23,687-byte decoded landing response. The exact-hash search matched four scans of this deployment; the wider family remains linked by metadata. The timeline supplies the other deployment names and their public records.

Method and limits

Expanded on 9th October 2026 after re-reading the archive, reproducing both form branches offline, and testing the public hash and timeline relationships.

The Sandfish analysis ran on 9th October 2026 between 06:48 and 06:49 UTC. We re-read its WACZ, decoded the landing response, checked its SHA-256, and traced the POST, 302, and following request. The synthetic values are omitted here. The later offline form experiment used fresh synthetic values and intercepted all requests; it was not a new live capture.

Public urlscan searches were repeated on 9th October. Both family queries returned 53 records with no further result page; the exact response-hash query returned four. The unauthenticated search window was 30 days. Earlier activity, private scans, and variants outside these queries remain unmeasured. The timeline spans observations 24 days apart and does not establish uninterrupted operation.

The evidence explains the collection mechanism and supports reuse of a distinctive template. The delivery channel, victim count, provider-account ownership, and operator identity remain unresolved. A useful next step is a dated comparison of earlier landing HTML and collection destinations: it could distinguish repeated use of one collector from copies circulating between operators.