Operation Slither

Overview — Operation Slither is an Easy TryHackMe room of the OSINT / SOCMINT kind: starting from a single handle leaked on a forum, we rebuild the social graph of a fictional threat group (Sneaky Viper) and attribute its three operators by pivoting across platforms (Threads, Instagram, SoundCloud, GitHub). Each pivot ends in a hidden flag — usually a Base64 string — and shows how open-source intelligence and OPSEC slips let you deanonymise an actor.

Methodology: the whole investigation relies on open-source intelligence. The recurring technique is handle reuse: the attackers use the same alias across several platforms, which lets us correlate accounts and, by following conversations and links, pivot from one to the next until we find the leaked datum.

Task 1 — The Leader

The starting point is a hacker-forum post advertising leaked company data. The only actionable item is a username:

@v3n0mbyt3_

Handle enumeration. We search the alias across search engines and username lookup engines, aiming to find where the user is active, not merely where an account exists. Attackers tend to reuse the same handle across platforms.

v3n0mbyt3_ social media
"v3n0mbyt3_" profile

Why: tools like sherlock or whatsmyname, or simple Google dorks, cross-reference an alias against dozens of platforms. What matters is not the account's mere existence but its recent activity (posts, replies, conversations).

Beyond the room: Sherlock and WhatsMyName are real, actively maintained open-source projects, not room fiction. Sherlock checks a handle against several hundred sites in one pass; WhatsMyName relies on a community-curated database of per-site fingerprints (the exact "exists" vs. "not found" response for each platform). Neither tool confirms identity on its own — they only shortlist where to look, a human still has to verify the hits actually belong to the same person.

The alias shows up on several platforms, but one stands out for recent activity and casual posting: Threads (alongside Twitter/X).

Q: Aside from Twitter / X, what other platform is used by v3n0mbyt3_?
A: threads

Profile analysis. On Threads we review posts, replies and, above all, the comment threads: sensitive data usually leaks in replies, not in the main post. Inside a thread with another user we spot a long, high-entropy string that looks like Base64:

VEhNe3...

We decode it with a Base64 decoder (CyberChef or the command line):

echo 'VEhNe3...' | base64 -d

The output is a valid TryHackMe-format flag.

Q: What is the value of the flag?
A: THM{sl1th3ry_tw33tz_4nd_l34ky_<REDACTED>}

Resumen — Operation Slither es una room Easy de TryHackMe de tipo OSINT / SOCMINT: partiendo de un único handle filtrado en un foro, reconstruimos el grafo social de un grupo de atacantes ficticio (Sneaky Viper) y atribuimos a sus tres operadores saltando entre plataformas (Threads, Instagram, SoundCloud, GitHub). Cada pivote termina en una flag oculta — normalmente una cadena Base64 — e ilustra cómo la inteligencia pública y los descuidos de OPSEC permiten desanonimizar a un actor.

Metodología: toda la investigación se apoya en inteligencia de fuentes abiertas. La técnica recurrente es la reutilización de handles: los atacantes usan el mismo alias en varias plataformas, lo que permite correlacionar cuentas y, siguiendo conversaciones y enlaces, pivotar de una a otra hasta encontrar el dato filtrado.

Task 1 — El líder

El punto de partida es una publicación en un foro de hacking que anuncia datos filtrados de una empresa. El único dato accionable es un nombre de usuario:

@v3n0mbyt3_

Enumeración del handle. Buscamos el alias en buscadores y motores de búsqueda de usuarios, con el objetivo de encontrar dónde está activo el usuario, no solo dónde existe la cuenta. Los atacantes suelen reutilizar el mismo handle entre plataformas.

v3n0mbyt3_ social media
"v3n0mbyt3_" profile

Por qué: herramientas como sherlock o whatsmyname, o simples dorks de Google, cruzan un alias contra decenas de plataformas. Lo relevante no es la mera existencia de la cuenta, sino la actividad reciente (publicaciones, respuestas, conversaciones).

Más allá del room: Sherlock y WhatsMyName son proyectos open-source reales y activamente mantenidos, no una invención de la room. Sherlock comprueba un handle contra varios cientos de sitios en una sola pasada; WhatsMyName se apoya en una base de datos de huellas por sitio mantenida por la comunidad (la respuesta exacta de «existe» frente a «no encontrado» de cada plataforma). Ninguna de las dos herramientas confirma la identidad por sí sola — solo acotan dónde mirar, y sigue haciendo falta una persona que verifique que los resultados pertenecen al mismo individuo.

El alias aparece en varias plataformas, pero una destaca por su actividad reciente y conversaciones casuales: Threads (además de Twitter/X).

Q: Además de Twitter / X, ¿qué otra plataforma usa v3n0mbyt3_?
A: threads

Análisis del perfil. En Threads revisamos publicaciones, respuestas y, sobre todo, los hilos de comentarios: los datos sensibles suelen filtrarse en las respuestas, no en el post principal. Dentro de un hilo con otro usuario aparece una cadena larga, de alta entropía y con aspecto de Base64:

VEhNe3...

La decodificamos con un decoder Base64 (CyberChef o línea de comandos):

echo 'VEhNe3...' | base64 -d

El resultado es una flag válida con formato TryHackMe.

Q: ¿Cuál es el valor de la flag?
A: THM{sl1th3ry_tw33tz_4nd_l34ky_<REDACTED>}

Task 2 — The Sidekick

A second forum post appears, but this time the operator handle is hidden. The hint is clear: reuse what we learned in Task 1.

Social-graph pivot. Rather than starting fresh, we go back to the Threads conversation from Task 1 and identify a recurring user who interacted directly with v3n0mbyt3_, spoke as an insider and referred to shared operations — clearly a second operator.

Q: What is the username of the second operator talking to v3n0mbyt3 from the previous platform?
A: _myst1cv1x3n_

Second-alias enumeration. We search _myst1cv1x3n_ across platforms and find an active Instagram profile using the same handle. Reviewing bio, captions, comments and external links, we notice two things:

• A comment with an encoded string claiming to be a flag.
• An external link to a SoundCloud profile.

Beware the decoy: the comment string is too obvious — placed right under a «Flag is here» note and requiring no pivot. It is a decoy. In OSINT, what is served on a plate is usually fake; the real flag lives deeper in the chain.

SoundCloud pivot. We follow the bio link to a profile with four audio tracks. We enumerate every track — description, comments and metadata — because real flags hide deeper than the first asset. In the description of Prototype2 we find a Base64 string embedded naturally in the text; decoding it yields the real flag.

Q: What is the value of the flag?
A: THM{s0cm1nt_00ps3c_f1ng3r_<REDACTED>}

Task 3 — The Last Operator

A new post advertises advanced phishing infrastructure and mentions Terraform, Evilginx, GoPhish, MFA bypass and red-team tooling. The profile points to a technical, infrastructure-focused operator.

Technical-platform pivot. We search for aliases tied to phishing frameworks, Terraform repositories and red-team infrastructure. The trail leads to a GitHub profile linked to the operation, hosting several phishing-infrastructure repositories.

Q: What is the handle of the third operator?
A: sh4d<REDACTED>

Q: What other platform does the third operator use?
A: github

Repository analysis. We focus on the original repository (not forks) and review the commit history and infrastructure files. The critical OPSEC failure: the history contains a Terraform state file committed by mistake:

terraform.tfstate

Terraform state files often contain secrets, passwords and output variables in cleartext. Inspecting the outputs we find a Base64 value labelled as a password; decoding it reveals the final flag.

Beyond the room: this isn't a room-only contrivance. HashiCorp's own documentation warns that Terraform state can hold resource attributes — including passwords, keys and connection strings — in plaintext, and explicitly advises against committing state to version control. In production, teams keep state in a remote backend (S3+DynamoDB, Terraform Cloud, etc.) encrypted at rest, mark sensitive outputs with sensitive = true, and run pre-commit secret scanners such as gitleaks or trufflehog so a stray tfstate never reaches a public repo in the first place.

git log --all --oneline
git show <commit>:terraform.tfstate | grep -i password

Q: What is the value of the flag?
A: THM{sh4rp_f4ngz_l34k3d<REDACTED>}

Investigation summary

Key takeaways

• Handle reuse kills anonymity: one alias across several platforms lets you correlate accounts and map an entire group from a single datum.
• The gold is in the replies: comments, replies and descriptions leak more than main posts. Enumerate every asset, not just the first.
• Recognise decoys: a flag served on a plate with no pivot is usually fake; the real one demands following the chain of links.
• Dev OPSEC hygiene: never commit terraform.tfstate or state files to a repo — they hold cleartext secrets. Always review the commit history, not just the latest state.
• Base64 everywhere: long high-entropy strings starting with VEhN decode to THM — an unmistakable tell during triage.

Task 2 — El compinche

Aparece un segundo post en el foro, pero esta vez el handle del operador está oculto. La pista es clara: reutilizar lo aprendido en el Task 1.

Pivote por el grafo social. En vez de empezar de cero, volvemos a la conversación de Threads del Task 1 e identificamos a un usuario recurrente que interactuaba directamente con v3n0mbyt3_, hablaba como un insider y aludía a operaciones compartidas — claramente un segundo operador.

Q: ¿Cuál es el nombre de usuario del segundo operador que habla con v3n0mbyt3 desde la plataforma anterior?
A: _myst1cv1x3n_

Enumeración del segundo alias. Buscamos _myst1cv1x3n_ entre plataformas y encontramos un perfil de Instagram activo con el mismo handle. Revisamos bio, pies de foto, comentarios y enlaces externos, y detectamos dos cosas:

• Un comentario con una cadena codificada que dice ser una flag.
• Un enlace externo a un perfil de SoundCloud.

Cuidado con el señuelo: la cadena del comentario es demasiado obvia — colocada justo bajo un texto tipo «Flag is here» y sin requerir ningún pivote—. Es un decoy. En OSINT, lo que se sirve en bandeja suele ser falso; la flag real está más abajo en la cadena.

Pivote a SoundCloud. Seguimos el enlace de la bio hasta un perfil con cuatro pistas de audio. Enumeramos cada pista — descripción, comentarios y metadatos—, porque las flags reales se esconden más profundo que el primer recurso. En la descripción de Prototype2 hallamos una cadena Base64 embebida de forma natural en el texto; al decodificarla obtenemos la flag real.

Q: ¿Cuál es el valor de la flag?
A: THM{s0cm1nt_00ps3c_f1ng3r_<REDACTED>}

Task 3 — El último operador

Un nuevo post anuncia infraestructura de phishing avanzada y menciona Terraform, Evilginx, GoPhish, bypass de MFA y tooling de red team. El perfil apunta a un operador técnico, centrado en infraestructura.

Pivote a plataforma técnica. Buscamos alias vinculados a frameworks de phishing, repositorios de Terraform e infraestructura red team. El rastro conduce a un perfil de GitHub ligado a la operación, que aloja varios repositorios de infraestructura de phishing.

Q: ¿Cuál es el handle del tercer operador?
A: sh4d<REDACTED>

Q: ¿Qué otra plataforma usa el tercer operador?
A: github

Análisis del repositorio. Nos centramos en el repositorio original (no en forks) y revisamos el historial de commits y los ficheros de infraestructura. El fallo de OPSEC crítico: en el historial hay un fichero de estado de Terraform incluido por error en un commit:

terraform.tfstate

Los ficheros de estado de Terraform suelen contener secretos, contraseñas y variables de salida en claro. Inspeccionando los outputs encontramos un valor Base64 etiquetado como contraseña; al decodificarlo aparece la flag final.

Más allá del room: esto no es solo un artificio de la room. La propia documentación de HashiCorp advierte de que el estado de Terraform puede contener atributos de recursos — incluidas contraseñas, claves y cadenas de conexión — en texto plano, y desaconseja explícitamente subir el estado al control de versiones. En producción, los equipos guardan el estado en un backend remoto (S3+DynamoDB, Terraform Cloud, etc.) cifrado en reposo, marcan los outputs sensibles con sensitive = true, y ejecutan escáneres de secretos en pre-commit como gitleaks o trufflehog para que un tfstate despistado nunca llegue a un repositorio público.

git log --all --oneline
git show <commit>:terraform.tfstate | grep -i password

Q: ¿Cuál es el valor de la flag?
A: THM{sh4rp_f4ngz_l34k3d<REDACTED>}

Resumen de la investigación

Puntos clave

• La reutilización de handles mata el anonimato: un mismo alias en varias plataformas permite correlacionar cuentas y trazar todo el grupo desde un solo dato.
• El oro está en las respuestas: comentarios, replies y descripciones filtran más que los posts principales. Enumera todos los recursos, no el primero.
• Reconoce los señuelos: una flag servida en bandeja y sin pivote suele ser falsa; la real exige seguir la cadena de enlaces.
• Higiene de OPSEC en desarrollo: nunca incluyas terraform.tfstate ni ficheros de estado en un commit al repositorio — contienen secretos en claro. Revisa siempre el historial de commits, no solo el último estado.
• Base64 en todas partes: cadenas largas de alta entropía que empiezan por VEhN decodifican a THM — una señal inequívoca durante el triage.