Send Crypto: An OSINT Investigation into a Government Domain

Two government URLs appeared in Google under the title “Send crypto”. What DNS, HTTP responses and search-index evidence can establish — and what they cannot.

The investigation began with a simple Google query: site:transportes.gob.es "send crypto". The results were unexpected. Two URLs under Spain’s Ministry of Transport domain appeared with the title Send crypto, while their snippets displayed the generic message “You need to enable JavaScript to run this app”.

The mismatch was worth investigating. A page about sustainable mobility and a route named /snapshots/cubes do not appear, from their URLs alone, to have an obvious relationship with cryptocurrency. But a search result is not a forensic finding. The task was to establish what could be observed independently, separate those observations from interpretations, and avoid turning a plausible security hypothesis into a claim of compromise.

The anomaly was visible in the index. Its cause was not.

This is a case study in practical OSINT and open-source intelligence analysis: turning an anomalous public signal into a bounded requirement, collecting independent observations, testing competing explanations and producing a judgement that is useful without overstating certainty.

1. The initial signal

The starting query was:

site:transportes.gob.es "send crypto"

Google displayed two results. Both had the title Send crypto, and both showed the same JavaScript application-shell snippet. The URLs were:

• /movilidad-sostenible/semana-europea-movilidad
• /snapshots/cubes

Google results for “site:transportes.gob.es "send crypto"”

The first URL resembles a public-facing institutional page. The second is more technical in appearance. That difference is useful for prioritising follow-up, but URL naming is not proof of function, ownership or malicious intent.

2. Intelligence question and scope

The core question was deliberately narrow:

Why does Google associate two URLs on a government domain with the title “Send crypto” when the visible snippet is a generic JavaScript application message?

The objective was not to prove an intrusion from the outside. It was to establish whether the anomaly was reproducible, identify what the public-facing infrastructure disclosed, and define what additional evidence would distinguish the leading explanations. No authentication was attempted, no security control was bypassed, and no state-changing request was sent.

Collection boundary

Public Google results, DNS lookups, and ordinary HTTP GET/HEAD requests to the supplied URLs and the www host.

Not available to the investigator

Origin-server logs, CMS records, deployment history, Google Search Console, the Ministry’s CDN/WAF configuration, and the actual current page source from a successful response.

Assessment date

24 October 2026, based on the timestamps shown in the collected terminal output and search material.

3. Intelligence framing: from signal to assessment

In intelligence terms, this is an externally observed anomaly with potential security relevance, not yet an incident attribution. The search result is the initial indicator; DNS and HTTP checks are separate collection streams that help describe the environment, but they do not automatically corroborate the same underlying cause. The central analytical task is to determine whether the observations are causally connected.

The case is best handled as a small intelligence requirement with three questions: is the title anomaly persistent; is it reflected in the live page or only in the search index; and can the site operator identify an unauthorised change in content, metadata or deployment history? Each question requires a different source. Public OSINT can establish the external symptom and its persistence. The operator’s logs and change records are needed to determine cause.

Observed indicator

Two URLs on a government domain were returned by a targeted search with the same unexpected cryptocurrency-related title.

Potential significance

If the title reflects unauthorised content or metadata, it could indicate SEO abuse, reputational misuse of an official domain, or a wider compromise. If it is stale or automatically generated, the security significance may be limited.

Key intelligence gap

The current page content could not be retrieved, and no privileged evidence was available to establish whether the title was ever present on the live site.

Decision relevance

The evidence is sufficient to justify a bounded, responsible notification to the website operator. It is not sufficient to describe the site as compromised or to infer an actor, motive or impact.

This framing separates indicator, interpretation and judgement. It also prevents a common analytical failure: allowing a technically unusual observation, such as a DNS response or a CDN error, to lend unearned certainty to a separate hypothesis about malicious activity.

4. DNS: the root host and www were not equivalent

The first network test failed with curl: (6) Could not resolve host: transportes.gob.es. A control request to Google succeeded, showing that the machine had general connectivity. The next step was to compare the local resolver with public resolvers.

nslookup transportes.gob.es
dig +short transportes.gob.es

dig transportes.gob.es A @1.1.1.1
dig transportes.gob.es A @8.8.8.8
dig transportes.gob.es NS @1.1.1.1

Both public resolvers returned NOERROR with zero answers for the root host’s A record. The authority section contained an SOA record naming ns1.age.gob.es and the contact field dns.mitma.es. The NS query returned ns1.age.gob.es and ns2.age.gob.es. Direct queries to both authoritative nameservers also returned no A record.

dig transportes.gob.es AAAA @1.1.1.1
dig transportes.gob.es CNAME @1.1.1.1
dig @ns1.age.gob.es transportes.gob.es A
dig @ns2.age.gob.es transportes.gob.es A

The AAAA and CNAME queries also returned no answer. This establishes what those resolvers returned at the time of testing; it does not establish why the root host had no A/AAAA answer, nor whether that state was intentional or transient.

The www hostname behaved differently:

dig www.transportes.gob.es A @1.1.1.1

The response showed a CNAME to a CloudFront hostname and multiple IPv4 addresses. This is consistent with the www host being served through a content-delivery network. It does not, by itself, reveal the origin server or the application architecture.

DNS comparison: apex domain and www host

5. HTTP: a shared blocking page

Requests to three paths on www.transportes.gob.es returned HTTP 403:

curl -sS -D - -o /dev/null --max-time 15 \
  https://www.transportes.gob.es/

curl -sS -D - -o /dev/null --max-time 15 \
  https://www.transportes.gob.es/movilidad-sostenible/semana-europea-movilidad

curl -sS -D - -o /dev/null --max-time 15 \
  https://www.transportes.gob.es/snapshots/cubes

The responses shared several characteristics: HTTP/2 403, server: CloudFront, x-cache: Error from cloudfront, a content length of 2,970 bytes, and the same ETag. The returned HTML title was Página web bloqueada.

curl -sS -o cloudfront-error.html \
  https://www.transportes.gob.es/snapshots/cubes

wc -c cloudfront-error.html
grep -inE 'bloque|motivo|contacto|solicitud|referencia|deneg|prohib|identificador|error' \
  cloudfront-error.html

The body included this message:

Lo sentimos, los sistemas de seguridad han bloqueado la web a la que intenta acceder por motivos de seguridad. Por favor, intente acceder nuevamente más tarde.

It also loaded a Ministry-branded logo from cdn.transportes.gob.es. This establishes that the tested requests received a branded blocking page. It does not identify which component made the blocking decision. A 403 can be generated by a CDN configuration, a web application firewall, access policy, or the origin. The response alone cannot distinguish those causes.

HTTP 403 and institutional blocking page

6. Competing hypotheses

The evidence supports several explanations. They are not mutually exclusive, and the current data does not select one conclusively.

H1 — SEO spam or injected metadata

A page title or other search-facing signal may have been altered to promote cryptocurrency-related content. Google documents page injection, content injection and cloaking as possible forms of hacked content. This hypothesis fits the title mismatch, but the current HTML could not be retrieved successfully, so injection has not been demonstrated.

H2 — Stale or rewritten Google title

Google may be displaying an older title, or may have generated the title link from other page signals rather than the current <title>. Google explains that title links are automated and may use page headings, prominent text, links and other sources. This remains a credible alternative.

H3 — Shared application shell or metadata configuration

The repeated “You need to enable JavaScript to run this app” snippet is compatible with a single-page application shell. A shared template or metadata configuration could explain similar results on two paths. This does not explain the “Send crypto” title on its own, but it is a technical possibility worth testing.

H4 — Route or deployment artefact

/snapshots/cubes could be a valid route, an obsolete path, a test artefact, or an application route that is not meant to be directly browsed. The path name is not enough to establish which. The 403 responses prevent a useful inspection of its current content.

H5 — Infrastructure access policy or configuration issue

The repeated 403 responses and missing root A/AAAA answers could reflect configuration or access-control behaviour unrelated to the title anomaly. These observations should be investigated separately unless further evidence connects them.

Hypothesis matrix

Hypothesis	Supporting observation	Missing evidence	Next discriminator
SEO spam / injection	Both results show “Send crypto”	Current HTML or server-side evidence of unauthorised content	Compare index, rendered page and origin logs
Stale or rewritten title	Search title differs from generic snippet	Current title and last crawl details	Recheck results and inspect an authorised current response
Shared SPA shell	Same JavaScript-required snippet on both paths	Successful page source and app configuration	Compare HTML and metadata when access is available
CDN / access policy	Same branded 403 on three www paths	WAF, CDN and origin logs	Operator-side request tracing

7. What the evidence does — and does not — establish

The strongest finding is narrow: on 24 October 2026, a Google query was observed to show two URLs on transportes.gob.es with the title “Send crypto”. Separately, DNS queries returned no A/AAAA answer for the root host, www resolved through CloudFront, and HTTP requests to three www paths returned a common branded 403 page.

These facts establish an anomaly worth reporting. They do not establish unauthorised access, a successful compromise, the presence of cryptocurrency functionality, a malicious payload, or a causal relationship between DNS behaviour and the Google titles.

An anomaly is a collection requirement, not a verdict.

This distinction matters in OSINT. A good investigation does not reward the most dramatic explanation; it tests which explanation survives the evidence. Correlated observations should not be counted as independent confirmations. The same CDN error across three paths may be one configuration behaviour, not three separate security signals.

8. What would resolve the case?

1. Preserve the original Google result screenshot, the exact query, the observation time and the two destination URLs.
2. Repeat the search later to determine whether the title persists, changes or disappears.
3. Compare the current page title, metadata and rendered content with the indexed title when an authorised response is available.
4. Ask the website operator to review origin, CDN/WAF and application logs for the relevant routes and Googlebot requests.
5. Check CMS history, deployment records, route configuration and any unauthorised changes to metadata or templates.
6. Keep the DNS observations separate from the SEO anomaly until a technical link is demonstrated.

The operator-side evidence is decisive because an external observer cannot inspect deployment history or authoritative logs. The correct next step is responsible disclosure with URLs, timestamps, terminal output and the unedited search screenshot — not attempts to bypass the block or probe hidden endpoints.

Conclusion

The investigation began with two search results that did not fit their apparent context. The follow-up work established a repeatable search-index observation, a difference between root and www DNS behaviour, and a common branded 403 response from the www host. It also established a limit: the current content behind the routes could not be inspected from the tested environment.

Spam SEO or injected metadata remains a plausible hypothesis, not a confirmed incident. Stale indexing, automatically rewritten title links, application-level metadata and unrelated access-control behaviour remain viable alternatives.

The value of the exercise is not that it uncovered a breach. It is that it converted a weak but potentially relevant signal into a documented intelligence product: the observation is preserved, hypotheses are ranked only as far as the evidence allows, collection gaps are explicit, and the next action is tied to the evidence needed to resolve the question.

Intelligence judgement

Judgement: the observed search-index anomaly is credible as a reported external observation, but its cause remains undetermined. Unauthorised SEO manipulation is a plausible explanation, yet the available evidence does not currently make it more than one of several viable hypotheses.

Confidence: high that the reported Google results and the recorded DNS/HTTP responses describe what was observed during this collection window; low regarding the underlying cause; insufficient evidence to assess whether a compromise occurred. These confidence levels refer to different propositions and should not be collapsed into a single rating.

Recommended action: preserve the evidence package and notify the responsible website/security team with the exact URLs, timestamps, query, raw outputs and screenshots. Request verification against CMS history, deployment records, page metadata and CDN/origin logs. Escalation as a confirmed incident should depend on that corroboration, not on the search title alone.

Investigative follow-up: Could PHP2Shell be related?

A later lead warranted a separate check. On 21 October 2026, the PHP project published fixes for CVE-2026-109618 and CVE-2026-109619. Some public reporting calls the pair “PHP2Shell”; that is not the title used in the PHP advisory. The official descriptions are RCE via OOM corruption and RCE via stale global state.

The PHP project rates both issues critical (CVSS v4.0: 9.2) and says that they can permit unauthenticated remote code execution in PHP installations serving web requests. The first concerns an out-of-memory exit while request data is only partly initialised; the second concerns request-owned state that can survive into a later request handled by the same worker. The fixed releases are PHP 8.2.35, 8.3.36, 8.4.27 and 8.5.12. The project documents a demonstrated HTTP exploit against Apache mod_php, while describing other server interfaces and paths with more qualification. Updating to a fixed release is the only complete remediation.

This makes PHP a reasonable component to rule out where a server-side content or metadata change is being investigated: successful code execution could, in principle, permit such a change. It does not connect these CVEs to the observed search results. The original collection did not identify a PHP runtime, version, server interface, origin host, application or relevant time window on transportes.gob.es. A CloudFront response is evidence of a delivery layer, not evidence of the runtime behind it.

The distinction is therefore straightforward. The Google title, DNS replies and branded 403 page are direct observations from this investigation. The CVE details and fixed versions are public vendor information, checked on 25 October 2026. Any claim that either flaw affected this domain remains a hypothesis. It would require operator-side confirmation of an affected PHP deployment during the relevant period, its SAPI and configuration, patch state, and logs or forensic evidence linking a request to an unauthorised content, metadata or deployment change. The same evidence could exclude the hypothesis if the relevant origin did not run an affected PHP build, or if logs and deployment history attribute the indexed title to another cause.

Current assessment: the PHP disclosures justify a focused validation question, not an attribution. Confidence in a relationship with the observed anomaly is insufficient.

Sources and technical references

- A. R. Brea, written 2026

Send Crypto: una investigación OSINT sobre un dominio gubernamental

Dos URL oficiales aparecieron en Google con el título «Send crypto». Qué permiten establecer el DNS, las respuestas HTTP y el índice del buscador, y qué queda sin demostrar.

La investigación comenzó con una búsqueda sencilla en Google: site:transportes.gob.es "send crypto". Los resultados eran inesperados. Dos URL bajo el dominio del Ministerio de Transportes aparecían con el título Send crypto, mientras que sus fragmentos mostraban el mensaje genérico «You need to enable JavaScript to run this app».

La discrepancia merecía comprobarse. Una página sobre movilidad sostenible y una ruta llamada /snapshots/cubes no parecen tener, por sus URL, una relación evidente con las criptomonedas. Pero un resultado de búsqueda no es una conclusión forense. El objetivo fue determinar qué podía observarse de forma independiente, separar las observaciones de las interpretaciones y evitar convertir una hipótesis plausible en una afirmación de intrusión.

La anomalía era visible en el índice. Su causa, no.

Este es un caso práctico de OSINT y análisis de inteligencia de fuentes abiertas: convertir una señal pública anómala en un requerimiento acotado, recopilar observaciones independientes, contrastar explicaciones y producir una valoración útil sin exagerar la certeza.

1. La señal inicial

La búsqueda de partida fue:

site:transportes.gob.es "send crypto"

Google mostró dos resultados. Ambos tenían el título Send crypto y el mismo fragmento relativo a una aplicación JavaScript. Las URL eran:

• /movilidad-sostenible/semana-europea-movilidad
• /snapshots/cubes

Resultados de Google para «site:transportes.gob.es "send crypto"»

La primera URL parece corresponder a una página institucional de cara al público. La segunda tiene un aspecto más técnico. Esa diferencia ayuda a priorizar comprobaciones, pero el nombre de una ruta no demuestra su función, su propietario ni una intención maliciosa.

2. Pregunta de inteligencia y alcance

La pregunta central se mantuvo deliberadamente acotada:

¿Por qué asocia Google dos URL de un dominio gubernamental con el título «Send crypto» si el fragmento visible es un mensaje genérico de una aplicación JavaScript?

El objetivo no era demostrar una intrusión desde el exterior. Era comprobar si la anomalía podía documentarse, identificar qué revelaba la infraestructura accesible públicamente y definir qué evidencia adicional permitiría discriminar entre las explicaciones principales. No se intentó autenticación, no se eludieron controles de seguridad y no se enviaron solicitudes que modificaran estado.

Límite de la recopilación

Resultados públicos de Google, consultas DNS y peticiones HTTP GET/HEAD ordinarias a las URL proporcionadas y al host www.

Información no disponible

Registros del servidor de origen, registros del CMS, historial de despliegues, Google Search Console, configuración CDN/WAF del Ministerio y contenido actual de las páginas obtenido mediante una respuesta satisfactoria.

Fecha de evaluación

24 de octubre de 2026, según las marcas temporales de los resultados de terminal y el material de búsqueda recopilado.

3. Enfoque de inteligencia: de la señal a la valoración

Desde una perspectiva de inteligencia, se trata de una anomalía observada desde el exterior con posible relevancia para la seguridad, no de una intrusión atribuida. El resultado de búsqueda es el indicador inicial; las comprobaciones DNS y HTTP son líneas de recopilación distintas que ayudan a describir el entorno, pero no corroboran automáticamente una misma causa. La tarea analítica central es determinar si las observaciones están relacionadas causalmente.

El caso puede abordarse como un requerimiento de inteligencia acotado con tres preguntas: ¿persiste la anomalía del título?, ¿aparece también en la página activa o solo en el índice del buscador?, y ¿puede el operador identificar un cambio no autorizado en el contenido, los metadatos o el historial de despliegues? Cada pregunta exige una fuente distinta. El OSINT público puede establecer el síntoma externo y su persistencia. Para determinar la causa hacen falta los registros y los historiales de cambios del operador.

Indicador observado

Una búsqueda dirigida devolvió dos URL de un dominio gubernamental con el mismo título inesperado relacionado con criptomonedas.

Posible relevancia

Si el título refleja contenido o metadatos no autorizados, podría indicar abuso SEO, uso reputacional indebido de un dominio oficial o un compromiso más amplio. Si es un dato obsoleto o generado automáticamente, la relevancia para la seguridad podría ser limitada.

Principal vacío de inteligencia

No fue posible recuperar el contenido actual de las páginas y no se dispuso de evidencia privilegiada que demostrase que el título hubiera estado presente en el sitio activo.

Relevancia para la decisión

La evidencia basta para justificar una comunicación acotada y responsable al operador del sitio. No basta para afirmar que el sitio está comprometido ni para inferir un actor, una motivación o un impacto.

Este enfoque separa indicador, interpretación y juicio analítico. También evita un error habitual: permitir que una observación técnicamente inusual, como una respuesta DNS o un error de CDN, aporte una certeza inmerecida a una hipótesis distinta sobre actividad maliciosa.

4. DNS: el dominio raíz y www no se comportaban igual

La primera prueba de red falló con curl: (6) Could not resolve host: transportes.gob.es. Una petición de control a Google funcionó, lo que indicó que el equipo tenía conectividad general. El siguiente paso fue comparar el resolvedor local con resolvedores públicos.

nslookup transportes.gob.es
dig +short transportes.gob.es

dig transportes.gob.es A @1.1.1.1
dig transportes.gob.es A @8.8.8.8
dig transportes.gob.es NS @1.1.1.1

Ambos resolvedores públicos devolvieron NOERROR y cero respuestas para el registro A del dominio raíz. La sección de autoridad contenía un registro SOA que identificaba ns1.age.gob.es y el campo de contacto dns.mitma.es. La consulta NS devolvió ns1.age.gob.es y ns2.age.gob.es. Las consultas directas a ambos servidores autoritativos tampoco devolvieron un registro A.

dig transportes.gob.es AAAA @1.1.1.1
dig transportes.gob.es CNAME @1.1.1.1
dig @ns1.age.gob.es transportes.gob.es A
dig @ns2.age.gob.es transportes.gob.es A

Las consultas AAAA y CNAME tampoco devolvieron respuesta. Esto documenta lo que respondieron esos resolutores en el momento de las pruebas; no demuestra por qué el dominio raíz carecía de respuestas A/AAAA ni si el estado era intencionado o temporal.

El host www se comportó de otra manera:

dig www.transportes.gob.es A @1.1.1.1

La respuesta mostró un CNAME hacia un nombre de CloudFront y varias direcciones IPv4. Esto es compatible con que el host www se sirva mediante una red de distribución de contenidos. Por sí solo, no revela el servidor de origen ni la arquitectura de la aplicación.

Comparativa DNS: dominio raíz y host www

5. HTTP: una página de bloqueo compartida

Las peticiones a tres rutas de www.transportes.gob.es devolvieron HTTP 403:

curl -sS -D - -o /dev/null --max-time 15 \
  https://www.transportes.gob.es/

curl -sS -D - -o /dev/null --max-time 15 \
  https://www.transportes.gob.es/movilidad-sostenible/semana-europea-movilidad

curl -sS -D - -o /dev/null --max-time 15 \
  https://www.transportes.gob.es/snapshots/cubes

Las respuestas compartían varias características: HTTP/2 403, server: CloudFront, x-cache: Error from cloudfront, una longitud de contenido de 2.970 bytes y el mismo ETag. El título del HTML recibido era Página web bloqueada.

curl -sS -o cloudfront-error.html \
  https://www.transportes.gob.es/snapshots/cubes

wc -c cloudfront-error.html
grep -inE 'bloque|motivo|contacto|solicitud|referencia|deneg|prohib|identificador|error' \
  cloudfront-error.html

El cuerpo incluía este mensaje:

Lo sentimos, los sistemas de seguridad han bloqueado la web a la que intenta acceder por motivos de seguridad. Por favor, intente acceder nuevamente más tarde.

También cargaba un logotipo del Ministerio desde cdn.transportes.gob.es. Esto demuestra que las peticiones probadas recibieron una página de bloqueo con identidad visual institucional. No identifica qué componente tomó la decisión. Un 403 puede generarse en la configuración de una CDN, un cortafuegos de aplicaciones web, una política de acceso o el servidor de origen. La respuesta por sí sola no permite distinguirlos.

HTTP 403 y página institucional de bloqueo

6. Hipótesis alternativas

La evidencia permite plantear varias explicaciones. No son mutuamente excluyentes y los datos disponibles no permiten elegir una de forma concluyente.

H1 — Spam SEO o metadatos inyectados

Se podría haber alterado el título de una página u otra señal visible para los buscadores con el objetivo de promocionar contenido sobre criptomonedas. Google documenta la inyección de páginas, la inyección de contenido y el cloaking como posibles formas de contenido pirateado. Esta hipótesis encaja con la discrepancia del título, pero no se ha demostrado una inyección porque no fue posible recuperar el HTML actual de las páginas.

H2 — Título obsoleto o reescrito por Google

Google podría estar mostrando un título antiguo o haber generado el enlace de título a partir de otras señales de la página en lugar del elemento <title> actual. Google explica que los títulos se generan automáticamente y pueden basarse en encabezados, texto destacado, enlaces y otras fuentes. Es una alternativa creíble.

H3 — Plantilla de aplicación compartida o configuración de metadatos

El mismo fragmento «You need to enable JavaScript to run this app» es compatible con una plantilla inicial de una aplicación de página única. Una plantilla o configuración común podría explicar fragmentos similares en dos rutas. No explica por sí sola el título «Send crypto», pero merece comprobarse.

H4 — Artefacto de ruta o despliegue

/snapshots/cubes podría ser una ruta válida, una ruta obsoleta, un artefacto de pruebas o una ruta de aplicación que no esté pensada para abrirse directamente. El nombre no basta para determinar cuál. Los 403 impiden inspeccionar su contenido actual de forma útil.

H5 — Política de acceso o configuración de infraestructura

Los 403 repetidos y la ausencia de respuestas A/AAAA para el dominio raíz podrían deberse a una configuración o política de acceso no relacionada con la anomalía del título. Conviene investigar ambas observaciones por separado salvo que aparezca evidencia que las conecte.

Matriz de hipótesis

Hipótesis	Observación compatible	Evidencia que falta	Siguiente comprobación
Spam SEO / inyección	Ambos resultados muestran «Send crypto»	HTML actual o evidencia del servidor de contenido no autorizado	Comparar índice, página renderizada y registros de origen
Título obsoleto o reescrito	El título difiere del fragmento genérico	Título actual y detalles del último rastreo	Revisar de nuevo los resultados e inspeccionar una respuesta actual autorizada
Plantilla SPA compartida	Mismo fragmento de JavaScript en ambas rutas	Código fuente accesible y configuración de la aplicación	Comparar HTML y metadatos cuando el acceso esté disponible
CDN / política de acceso	Mismo 403 institucional en tres rutas de www	Registros de WAF, CDN y origen	Trazabilidad de peticiones por parte del operador

7. Qué demuestra la evidencia y qué no

El hallazgo más sólido es acotado: el 24 de octubre de 2026 se observó una búsqueda de Google que mostraba dos URL de transportes.gob.es con el título «Send crypto». Por separado, las consultas DNS no obtuvieron respuestas A/AAAA para el dominio raíz, www resolvió mediante CloudFront y las peticiones HTTP a tres rutas de www devolvieron una página de bloqueo común.

Estos hechos documentan una anomalía que merece comunicarse. No demuestran acceso no autorizado, un compromiso exitoso, la presencia de funcionalidad de criptomonedas, una carga maliciosa ni una relación causal entre el DNS y los títulos de Google.

Una anomalía es un requisito de recopilación, no un veredicto.

Esta distinción importa en OSINT. Una buena investigación no premia la explicación más dramática: comprueba cuál resiste la evidencia. Las observaciones correlacionadas no deben contarse como confirmaciones independientes. El mismo error CDN en tres rutas puede responder a una única configuración, no a tres señales de seguridad separadas.

8. Qué permitiría resolver el caso

1. Conservar la captura original de Google, la consulta exacta, la hora de observación y las dos URL de destino.
2. Repetir la búsqueda más adelante para comprobar si el título persiste, cambia o desaparece.
3. Comparar el título, los metadatos y el contenido renderizado actuales con el título indexado cuando exista una respuesta autorizada accesible.
4. Solicitar al operador que revise los registros del origen, CDN/WAF y las peticiones de Googlebot a las rutas afectadas.
5. Comprobar el historial del CMS, los despliegues, la configuración de rutas y los cambios no autorizados en metadatos o plantillas.
6. Mantener las observaciones DNS separadas de la anomalía SEO hasta demostrar una relación técnica.

La evidencia del lado del operador es decisiva porque un observador externo no puede inspeccionar el historial de despliegues ni los registros autoritativos. El siguiente paso adecuado es una comunicación responsable con URL, marcas temporales, salidas de terminal y la captura original sin editar; no intentar eludir el bloqueo ni sondear endpoints ocultos.

Conclusión

La investigación empezó con dos resultados de búsqueda que no encajaban con su contexto aparente. Las comprobaciones posteriores documentaron una observación reproducible en el índice, una diferencia de comportamiento DNS entre el dominio raíz y www, y una respuesta 403 institucional común desde el host www. También establecieron un límite: no fue posible inspeccionar el contenido actual de las rutas desde el entorno probado.

El spam SEO o la inyección de metadatos siguen siendo hipótesis plausibles, no un incidente confirmado. La indexación obsoleta, la reescritura automática de títulos, los metadatos de una aplicación y un comportamiento de control de acceso independiente siguen siendo alternativas viables.

El valor del ejercicio no es haber descubierto una intrusión. Es haber convertido una señal débil pero potencialmente relevante en un producto de inteligencia documentado: la observación queda preservada, las hipótesis solo se priorizan hasta donde permite la evidencia, los vacíos de recopilación son explícitos y la siguiente acción depende de la evidencia necesaria para resolver la cuestión.

Juicio de inteligencia

Juicio: la anomalía del índice de búsqueda es creíble como observación externa documentada, pero su causa sigue sin determinarse. La manipulación SEO no autorizada es una explicación plausible, aunque la evidencia disponible no permite situarla por encima de las demás hipótesis viables.

Confianza: alta en que los resultados de Google y las respuestas DNS/HTTP registradas describen lo observado durante esta ventana de recopilación; baja respecto a la causa subyacente; evidencia insuficiente para valorar si hubo compromiso. Estos niveles se refieren a proposiciones distintas y no deben reducirse a una única calificación.

Acción recomendada: conservar el conjunto de evidencias y notificar al equipo responsable del sitio o de seguridad con las URL exactas, marcas temporales, consulta, salidas originales y capturas. Solicitar que se contraste con el historial del CMS, los despliegues, los metadatos y los registros de CDN/origen. La escalada como incidente confirmado debe depender de esa corroboración, no únicamente del título mostrado por el buscador.

Nueva línea de investigación: ¿podría estar relacionado con PHP2Shell?

Una línea posterior justificaba una comprobación independiente. El 21 de octubre de 2026, el proyecto PHP publicó correcciones para CVE-2026-109618 y CVE-2026-109619. Algunas publicaciones se refieren al conjunto como «PHP2Shell», pero esa no es la denominación del aviso de PHP. Las descripciones oficiales son RCE mediante corrupción por OOM y RCE mediante estado global obsoleto.

El proyecto PHP califica ambas vulnerabilidades como críticas (CVSS v4.0: 9,2) e indica que pueden permitir ejecución remota de código sin autenticación en instalaciones PHP que atienden peticiones web. La primera se produce al salir por falta de memoria mientras los datos de la petición están parcialmente inicializados; la segunda, cuando estado propio de una petición persiste hasta una petición posterior atendida por el mismo worker. Las versiones corregidas son PHP 8.2.35, 8.3.36, 8.4.27 y 8.5.12. El proyecto documenta un exploit HTTP demostrado contra Apache con mod_php; para otras interfaces y rutas describe condiciones más específicas. Actualizar a una versión corregida es la única remediación completa.

Esto hace razonable descartar PHP como componente cuando se investiga un posible cambio de contenido o metadatos en servidor: una ejecución de código lograda podría, en principio, permitirlo. No conecta estas CVE con los resultados observados. La recopilación original no identificó un runtime PHP, versión, interfaz de servidor, host de origen, aplicación ni ventana temporal relevante en transportes.gob.es. Una respuesta de CloudFront acredita una capa de distribución, no el runtime situado detrás.

La separación es, por tanto, concreta. El título de Google, las respuestas DNS y la página 403 institucional son observaciones directas de esta investigación. Los detalles de las CVE y las versiones corregidas son información pública del proveedor, comprobada el 25 de octubre de 2026. Cualquier afirmación de que una de las vulnerabilidades afectó a este dominio sigue siendo una hipótesis. Requeriría confirmación del operador de un despliegue PHP afectado en el periodo relevante, su SAPI y configuración, estado de parcheado, y registros o evidencia forense que vinculen una petición con un cambio no autorizado de contenido, metadatos o despliegue. Esa hipótesis también quedaría descartada si el origen relevante no ejecutaba una versión PHP afectada, o si los registros y el historial de despliegues atribuyen el título indexado a otra causa.

Valoración actual: las divulgaciones de PHP justifican una pregunta de validación concreta, no una atribución. La confianza en una relación con la anomalía observada es insuficiente.

Fuentes y referencias técnicas

- A. R. Brea, escrito en 2026