Skip to main content

Command Palette

Search for a command to run...

Overheard at Breakfast: OSINT - image x Gmail x Gravatar profile & Base64 (TryHackMe)

Updated
6 min readView as Markdown
Overheard at Breakfast: OSINT - image x Gmail x Gravatar profile & Base64  (TryHackMe)
J
Software Developer | Learning Cybersecurity | Open for roles * If you're in the early stages of your career in software development (student or still looking for an entry-level role) and in need of mentorship, you can reach out to me.

Link to the CTF challenge on TryHackMe: Overheard at Breakfast

Concierge Briefing

The breakfast terrace is loud this morning, clinking cutlery, espresso machines, the usual chatter. One guest couldn't help but linger at a nearby table, seeing more of a conversation than they were meant to.

When the table's occupant stepped away for a refill, they seized the moment and grabbed a screenshot before it could disappear. Somewhere in that conversation is enough to track down an account nobody was supposed to find.

TODAY'S ITINERARY

  • [ ] Analyze the provided conversation for identifying details

  • [ ] Extract the relevant clues

  • [ ] Locate the hidden account

  • [ ] Submit the flag

  • OSINT

  • Social Media

  • Hashing

  • The above image was attached to the challenge. This is an OSINT challenge; we're supposed to use the screenshot to help us find any information that can lead us to the flags. From the screenshot, we can see the email and a little information about Lambo, their avatar (people tend to reuse one on different platforms), and the fact that they're visiting the resort.

  • From a previous OSINT challenge, I learned about this platform called epieos, where you can search emails and find some OSINT information

checked epieos

lambobytelotushotel@gmail.com 2 results(7.8 seconds)Mon, 03 Aug 2026 12:40:35 GMT

!Epieos logo

Google account finder will show you if the requested email is linked to a Google account and/or if the person left reviews on Google Maps.

lambobytelotushotel@gmail.com

img/profile/fake/vonneumann.jpg

Sign up

109541557676124188877

1777-04-30

Sign up

https://www.google.com/maps/contrib/109541557676124188877

https://calendar.google.com/calendar/u/0/embed?src=lambobytelotushotel@gmail.comCopy URL

https://web.archive.org/web//plus.google.com/109541557676124188877Copy URL

  • This tool allows you to find a gravatar account linked to an email address.

lambobytelotushotel@gmail.com

img/profile/fake/euler.jpg

Sign up

314159265359

Sign up

https://example.com/longhiddenlink

Sign up

Edsger Wybe Dijkstra

Sign up

Carl Friedrich Gauss

Sign up

Leonhard Euler

Sign up

Transia

Sign up

echo -n "lambobytelotushotel@gmail.com" | md5sum
d4a5fc5d3128890778667e24617d7cc0  -

curl -s https://api.gravatar.com/3/profiles/d4a5fc5d3128890778667e24617d7cc0
{
    "errors": {
        "error": "Unsupported version"
    }
}%                                                                                                                                                                                                      

curl -s https://www.gravatar.com/d4a5fc5d3128890778667e24617d7cc0.json

curl -s -o /dev/null -w "%{http_code}\n" "https://www.gravatar.com/avatar/d4a5fc5d3128890778667e24617d7cc0?d=404"
200

Conclusion

Overheard at Breakfast is a clean example of OSINT correlation through identifier reuse: no exploitation, no injection, just patient pivoting from one leaked data point (a screenshot) through multiple public services that all key off the same underlying identifier: the email address.

What the investigation demonstrates

  1. A single email address is a surprisingly strong pivot point across unrelated services. Once lambobytelotushotel@gmail.com was visible in the screenshot, it became the key that unlocked multiple independent OSINT surfaces:

    • Epieos → Google account correlation: confirmed the email is tied to an active Google account (numeric Google ID 109541557676124188877), exposed a Google Maps contributor profile, and even surfaced a Wayback Machine snapshot of a defunct Google+ profile - showing that deleted platforms can still leak identifying data years later via archives.

    • Gravatar lookup: the same email, MD5-hashed, resolves to an avatar image - Gravatar's whole design assumes the hash of your email is a safe, non-reversible identifier to expose publicly, which OSINT tooling routinely disproves in practice.

  2. Gravatar's hash-as-identifier model is a privacy weak point, not a security control. MD5 of a known/guessed email is instant to compute (echo -n "..." | md5sum), and Gravatar's own API confirms whether that hash has a registered account (200 OK on /avatar/<hash>?d=404 means "this hash has a real avatar," not the default fallback). This turns "does this email have a Gravatar" into a simple oracle - useful for OSINT, but also a reminder that MD5-of-email is not obfuscation; it's a lookup key anyone can compute offline.

  3. API versioning matters when chaining tools. The api.gravatar.com/3/profiles/<hash> call returned "Unsupported version" - a good practical lesson that public OSINT APIs change their versioned endpoints over time, and a failed call doesn't necessarily mean the target has no data; it can mean the wrong API version/endpoint was hit. The correct next step is checking Gravatar's current documented endpoint (their v1/v3 profile API has shifted) rather than concluding the lookup dead-ends there.

  4. Avatar reuse is a durable correlation signal. The briefing's own hint "people tend to reuse one avatar across platforms" is exactly how a defender or investigator pivots from "an email in a screenshot" to "this person's accounts elsewhere," and it's equally exactly how an attacker doing reconnaissance on a real target would work. Reverse image search on a distinctive avatar (TinEye, Google Lens, PimEyes-class tools) is normally the next move here, in addition to hash-based lookups.

Security takeaways

  • Screenshots leak more than intended. The entire chain started from someone glimpsing a screen over someone's shoulder ("shoulder surfing") and capturing an email address: a reminder that visible-on-screen data in public spaces (cafes, terraces, shared workspaces, video calls) is a real reconnaissance vector, not a theoretical one.

  • Email addresses should be treated as quasi-PII even when "just an email." A single address, once known, chains into: real name (via Google account/Maps reviews), Gravatar-hosted avatar and possibly bio/social links, and historical presence on now-defunct platforms via web archives. Anyone provisioning accounts (guest wifi portals, hotel apps, loyalty programs) should assume the email itself is enough to start building a profile of the person.

  • Deleted ≠ gone. The Wayback Machine snapshot of a defunct Google+ profile is the clearest example: platform shutdown doesn't remove archived exposure. Any takedown/deletion request only addresses the live platform, not third-party archives.

  • MD5(email) is not a privacy-preserving identifier. Any system using a hash of a well-known, guessable, or breach-leaked field (email, username) as a "safe" public key is exposed to exactly this kind of dictionary/rainbow lookup. This applies to Gravatar by design, but the same anti-pattern shows up in other systems that hash predictable inputs and assume that's sufficient obfuscation.

Loosely mapped to attacker tradecraft (MITRE ATT&CK / PRE-ATT&CK framing, since this simulates recon against a target)

  • T1589.002: Gather Victim Identity Information: Email Addresses; the entire chain starts here.

  • T1593.001: Search Open Websites/Domains: Social Media, Google Maps contributor profile, Google+ archive.

  • T1596.002: Search Open Technical Databases: WHOIS/Reverse lookups (adjacent), Epieos and Gravatar function as reverse-identifier lookup services in the same spirit.

For your OSINT methodology notes

Worth keeping as a repeatable pivot sequence for any email-first OSINT task:

  1. Epieos (or similar) → check Google account linkage, Maps reviews, calendar exposure.

  2. Gravatar hash lookup (MD5 of lowercased, trimmed email) → check for avatar/profile existence via the current API version.

  3. Wayback Machine on any historical profile URLs surfaced above.

  4. Reverse image search on any recovered avatar to find reused instances elsewhere.