Operation: The Missing Pieces
Tracing a digital trail through cryptography, identity research, GitHub and network artifacts.
Operation: The Missing Pieces is an OSINT challenge centred around the investigation of a person of interest known as Sierra-7, who disappeared after leaking classified corporate information.
The challenge started with a small piece of encrypted information and a number of objectives that required me to identify different parts of the subject’s digital footprint. What initially looked like a simple cryptographic problem eventually turned into a broader investigation involving email intelligence, online identity correlation, username enumeration, GitHub reconnaissance, repository analysis, network artifacts and geolocation.
For this investigation, I did not want to rely on a single tool or accept every result at face value. I started by examining the information provided in the challenge, working through the first problem manually, and then using different OSINT tools to follow the leads that emerged from each finding.
Some of the pivots produced useful information immediately, while others led to dead ends and forced me to return to earlier evidence and look at it from another angle.
This article documents how I approached the investigation, the observations that influenced my next steps, the tools I used along the way, and how the different pieces eventually connected.
For Analysts that might be interested in the Challenge
Operation The Missing Pieces
Project Overview
The investigation required several different types of information to be established about the person of interest.
The main objectives were to identify:
- The POI’s email address
- The POI’s complete name
- The creation timestamp of their GitHub account
- A MAC address associated with their primary workstation
- Their last known location, including coordinates, city and country
What made the challenge interesting was that these objectives were not presented as separate tasks with obvious answers. The information had to be discovered progressively.
A finding from one stage could become the starting point for the next stage. An email address could lead to an account, an account could lead to a username, a username could lead to another platform, and a repository could contain information that was no longer visible in its current state.
That meant the investigation was less about running a long list of tools and more about knowing when to pivot and what to investigate next.
The challenge scenario introduced Sierra-7, a notorious hacktivist who disappeared after leaking classified corporate data.
Alongside the scenario, an encrypted authentication artifact was provided:
svaabfpne.znk@tznvy.pbzThe challenge required several pieces of information to be uncovered from the available digital traces.
Before searching for anything externally, I decided to start with the artifact itself.
Starting With the First Artifact
The first thing that caught my attention was the structure of the string.
Although the characters did not immediately form a meaningful email address, the @ symbol and the period were still present in positions where they would normally appear in an email address.
That suggested that the string might not be random. The surrounding structure was still intact, while the alphabetic characters appeared to have been transformed.
Since I already had some background in cryptography, I started thinking about simple substitution techniques that could produce this kind of transformation.
One of the first possibilities that came to mind was ROT13.
Breaking the Cipher
Instead of immediately putting the string into an online decoder, I decided to work through it manually.
ROT13 replaces each letter with the letter thirteen positions away in the alphabet. Applying that transformation to the beginning of the string gave me:
s → f
v → i
a → n
a → n
b → o
f → s
p → c
n → a
e → rContinuing the same process through the remaining characters produced:
svaabfpne.znk@tznvy.pbz
↓
finnoscar.max@gmail.comAt this point, I had my first usable piece of information and could begin the OSINT part of the investigation.
Confirming the Result With CyberChef
Although the manual result made sense, I wanted to verify it independently.
I opened CyberChef, entered the original artifact and applied the ROT13 operation. The output matched the result I had obtained manually.
I used CyberChef here as a verification tool rather than relying on it as the initial method of discovery.
With the first artifact resolved, I now had an email address that could be used as my first OSINT pivot.
Moving From the Email to an Identity
The next step was to determine whether the email address was associated with any publicly available accounts or identity information.
I used Epieos to investigate the email address and look for account associations that could provide a useful lead.
The search returned an account association that provided my first useful identity lead.
I followed this information toward the associated Google account and then examined the publicly available activity connected to it.
At this stage, I was not treating a single result as conclusive. I was looking for additional information that could either support or challenge the identity I had found.
Following the Google Account
The Google account provided another interesting direction.
While reviewing the publicly available activity associated with the account, I came across a hotel review that immediately caught my attention.
The review contained several details that looked potentially useful for the investigation, including references to waterfront access, a dock and the hotel’s storytelling concept.
I did not immediately treat the hotel as the final location.
Instead, I recorded it as a potential location lead and continued investigating the identity through other sources. I wanted to see whether another independent source could connect the same identity to additional accounts.
Expanding the Email Investigation
I returned to the email address and performed another email-based search using IntelBase.io.
The purpose of this step was to identify additional services or profiles associated with the same email address.
The results contained two account associations. One of them provided a particularly useful pivot into GitHub.
This gave me another direction to investigate and also provided an opportunity to compare the identity information I had already collected with information available on another platform.
GitHub Reconnaissance Using the API
After identifying the GitHub profile, I wanted to collect some information that was not immediately obvious from the profile page itself.
Since GitHub exposes public account information through its API, I used it to inspect the account metadata associated with the profile.
I queried the public GitHub user endpoint and reviewed the returned JSON response.
One of the fields I was particularly interested in was created_at.
The timestamp provided the account creation date and time in UTC. I recorded this because the challenge specifically required the GitHub account creation timestamp.
I also used the API response as another way of confirming that the GitHub username I had identified matched the account I was investigating.
This was useful because it gave me structured account metadata rather than relying only on what was displayed on the GitHub profile page.
Moving Into GitHub
I followed the GitHub lead and examined the profile associated with the username.
The profile displayed an identifiable name and contained a repository that immediately caught my attention:
network-scanner-toolThe subject of the repository was particularly relevant to the challenge because it involved scanning nearby Wi-Fi networks and working with network information such as BSSID, SSID and signal strength.
Get Azutech’s stories in your inbox
Join Medium for free to get updates from this writer.
That made the repository worth investigating more closely.
Looking Inside the Repository
I started by examining the repository’s README and the information available in the current version of the project.
The project described functionality related to Wi-Fi scanning and logging network information.
At this point, I was particularly interested in the network-related artifacts because one of the challenge objectives involved identifying a MAC address associated with the subject’s workstation.
Rather than stopping at the current repository contents, I decided to examine the project’s history.
Going Through the Commit History
The repository contained several commits, so I opened the commit history and reviewed the changes individually.
network-scanner-tool repository.This was an important part of the investigation.
The current state of a repository does not necessarily contain everything that has previously been committed. Information can be modified or removed while still remaining accessible through the Git history.
I therefore went through the historical commits looking for anything that could relate to the challenge objectives.
Finding an Encoded Artifact
One of the historical commits contained a block of information that stood out:
{
"network_name": "Alpha_Omega",
"location": "QTA6MjE6Qjc6QTg6N0Y6RDM=",
"debug_mode": false,
"log_level": "INFO",
"notes": "Remember to rotate weekly"
}The location value immediately looked unusual.
Rather than treating it as a normal location string, I examined its encoding.
The presence of characters commonly associated with Base64, together with the trailing = padding, made Base64 one of the first possibilities I considered.
Decoding the Network Artifact
I worked through the value as a Base64-encoded string.
The encoded value was:
QTA6MjE6Qjc6QTg6N0Y6RDM=
Decoding the Base64 value produced:
A0:21:B7:A8:7F:D3After decoding it, the resulting value followed the familiar structure of a MAC/BSSID identifier.
I did not rely solely on the decoder, though. I wanted to make sure the interpretation was correct, so I repeated the process using CyberChef.
The CyberChef result matched the manually obtained result.
At this point, I had recovered a network identifier that could potentially be relevant to the MAC-address objective.
Trying to Geolocate the BSSID
The next question was whether the recovered network identifier could also provide a physical location.
I decided to investigate it using WiGLE, which provides information about observed wireless networks.
The search did not return a useful observation.
Rather than assuming that the absence of a result meant something about the location, I treated this as an unsuccessful pivot.
This was one of the points where I had to step back and reconsider the investigation instead of continuing to force the same lead.
Checking the OUI
I also examined the first three octets of the recovered network identifier.
The purpose was to determine which manufacturer had been assigned the corresponding OUI.
The lookup provided manufacturer information about the hardware.
However, this did not give me a reliable physical location for the POI. Manufacturer registration information identifies the organisation associated with the hardware address range; it does not establish where a particular device is physically located.
So I recorded the result as supporting network information rather than using it as the location answer.
Returning to an Earlier Lead
At this point, the direct network-based location investigation had not produced anything useful.
Instead of continuing to search the same BSSID through different services indefinitely, I returned to one of the earlier leads I had deliberately kept aside: the hotel review.
The review had already provided several location-related clues, but I had not yet established whether the location could be independently verified.
I therefore went back to the identity information surrounding the review and compared it with the other information I had gathered throughout the investigation.
This was where the separate identity and location clues began to make more sense when viewed together.
Verifying the Location
The next step was to independently verify the location rather than relying only on the original review.
I searched for the identified hotel using Google Maps.
Once the location was identified, I used the map to obtain the geographic coordinates.
I recorded the latitude and longitude separately so that they could be used as the final geographic coordinates required by the challenge.
For the Medium article, I have redacted the exact location details so that the challenge’s final answers are not exposed.
Bringing the Investigation Together
Looking back at the investigation, the important part was the sequence of pivots rather than any individual tool.
The investigation started with a cryptographic artifact and gradually developed into a much broader identity investigation.
The overall path looked roughly like this:
Initial encrypted artifact
↓
Cryptographic analysis
↓
Email identification
↓
Email intelligence
↓
Identity lead
↓
Google account / public activity
↓
Additional email intelligence
↓
GitHub account
↓
GitHub API reconnaissance
↓
Username investigation
↓
Repository analysis
↓
Git commit history
↓
Encoded network artifact
↓
Base64 analysis
↓
BSSID investigation
↓
Location investigation
↓
Independent verificationThe investigation was not completely linear. Some pivots produced useful information, while others did not. The ability to return to an earlier lead was just as important as finding new information.
Tools Used During the Investigation
The tools were used at different points in the investigation rather than all at once.
CyberChef | Verified ROT13 and Base64 decoding |
Epieos | Investigated the identified email address |
IntelBase.io | Looked for additional account associations |
GitHub | Investigated the profile, repository, and commit history |
GitHub API | Retrieved account metadata and creation timestamp |
WiGLE | Investigated the recovered BSSID |
OUI Lookup | Identified the registered hardware manufacturer |
Google Maps | Independently verified the location |
A Few Things I Took Away From the Investigation
One of the biggest things this challenge reinforced for me was that OSINT investigations rarely follow a straight line.
I initially expected the recovered network identifier to potentially give me a location, but that route did not produce a useful result. Instead of forcing the evidence, I returned to an earlier lead and continued investigating from there.
The challenge also reinforced the importance of looking at historical information. The current state of a GitHub repository did not tell the whole story. Going through the commit history exposed information that had been removed from the current version of the project.
Another thing I found useful was verifying results independently. When I manually decoded the initial artifact, I used CyberChef to confirm it. I followed the same approach with the Base64 artifact. For the location, I used Google Maps as an independent verification source rather than relying entirely on the original public activity.
So that was one of the more valuable parts of the challenge: finding information is only one part of the investigation; understanding how reliable that information is and how it connects to other findings is just as important.
Conclusion
Operation: The Missing Pieces was a good practical exercise in following a digital trail across different sources.
What started with a small encrypted artifact eventually led through cryptographic analysis, email intelligence, identity research, username enumeration, GitHub reconnaissance, repository history, network artifacts and location verification.
I enjoyed the fact that the investigation required me to change direction when a particular lead stopped producing useful information. It made the challenge feel less like following a predefined checklist and more like an actual OSINT investigation.
