Welcome to watchTowr vs the Internet, part 68.

That feeling you’re experiencing? Dread. You should be used to it by now.

As is fast becoming an unofficial and, apparently, frowned upon tradition - we identified incredible amounts of publicly exposed passwords, secrets, keys and more for very sensitive environments - and then spent a number of months working out if we could travel back in time to a period in which we just hadn't.

Remember, kids - a problem shared is a problem that isn't just your problem anymore. It's the Shared Responsibility model(tm).

You might remember some of our previous Internet-wide disasters - but if not, here’s a refresher:

We wouldn't blame you for being slightly hopeful after reading our previous monologues into the void and thinking: "Wow, hopefully watchTowr learned something from those experiences - like, stop going on stupid adventures."

Unfortunately, while we symapthise - you would be wrong and, in fact, we continue to prove that we have learnt nothing. Truly nothing.

So today, armed once again with the aftermath of several highly questionable decisions and our continued inability to properly assess risk, we’re dragging you on another journey with us.

While conference halls continue to insist that AI threats, and of course AI solutions, have put the world on the brink of implosion - “Jimmy” over at MSSP-123 (our favourite MSSP) continues to post their Active Directory credentials for a bank on a public website, possibly on their first day (we can’t knock the bravery).

Exposing secrets in truly impressive ways to absolutely everyone is not a new phenomenon in cyber, we’ve all seen this before (and, naturally, we have all learnt nothing!). For those that aren't yet jaded, the phenomenon we allude to includes (but is by no means limited to):

• GitHub repositories,
• Postman workspaces,
• DockerHub containers

Following this chain of thought, we wondered: how will 2 (maybe 3) teenagers, between homework, outsmart this multi-billion-dollar industry next week?

TL;DR: we’ve been rifling through platforms that developers use to quickly format their input - like JSONFormatter and CodeBeautify. And yes, you are correct - it went exactly as badly as you might expect.

STOP PUBLISHING CREDENTIALS IN RANDOM ONLINE TOOLS.

For Many Of You, It's Too Late

Iterating through JSONFormatter and CodeBeautify, we captured a dataset of 80,000+ saved pieces of JSON - and then parsed this dataset (using internal apparatus) to identify secrets, credentials, keys, and other types of data with acronyms beginning with P (such as PII).

Amongst thousands of secrets, the following types were noteworthy:

• Active Directory credentials
• Code repository authentication keys
• Database credentials
• LDAP configuration information
• Cloud environment keys
• FTP credentials
• CI/CD pipeline credentials
• Full, and sensitive API requests and responses
• Private keys
• Card payment gateway credentials
• RTSP credentials
• Administrative JWT tokens
• Helpdesk API keys
• Meeting room API keys
• SSH session recordings
• PII, including the following types:
• An entire export of every single credential from someone's AWS Secrets Manager??

If the idea of thousands of these secrets in our hands wasn’t scary enough, the affected organizations leaking these things certainly were:

• Critical National Infrastructure
• Government
• Finance
• Insurance
• Banking
• Technology
• Cyber Security
• Retail
• Aerospace
• Telecoms
• Healthcare
• Education
• Travel

and honestly.. too many more

As always, we want to remind everyone - if we can pull this off with our combined brain cell count of 1 (one, singular), anyone can.

Luckily, Quantum Computing is coming soon to solve these problems. And a robotaxi.

Where It All Went Wrong

Yes, like you, we’re screaming at our screens - and fairly perplexed at the reality we find ourselves in.

So, before we begin crying together and pooling our tears to trade for 0dayz, let’s set the scene and explain what we’re actually up to.

Our research today focuses on two (out of the many) online code formatter tools:

These tools are extremely popular, often appearing near the top of search results for terms like “JSON beautify” and “best place to paste secrets” (probably, unproven) - and used by a wide variety of organizations, organisms, developers, and administrators in both enterprise environments and for personal projects (as we’ll soon see).

The popularity is so great that the sole developer behind these tools is fairly inspired - with a typical visit to any tool homepage triggering 500+ web requests pretty quickly to generate what we assume is some sweet, sweet affiliate marketing revenue.

Anyway, our jealousy aside, the concept of online code formatters is relatively simple: put unstructured and ugly code/strings in, get beautiful and beautified and formatted art as output.

“How could this possibly go wrong?!” I hear you, the ever-so-innocent reader asking.

If you’re just prettifying:

{"first_name": "JSON", "last_name": "Bourne"}

0 shareholder value

to

{
	"first_name": "JSON",
	"last_name": "Bourne"
}

so much shareholder value

The answer is "not much".

However, if you’re a “power user” (aka a super nerd), you’ll notice extra functionality - like the SAVE button in the top-right corner.

Click it, and you get a semi-permanent, shareable link to whatever you just formatted - making it easy to share with your colleagues, friends, a client, a newly onboarded user, or your favourite Tamagotchi.

In fairness, it is already clear how this went horribly wrong.

You see, it is fairly apparent that the word ‘SAVE’ and being given shareable link was not enough to help most users understand that, indeed yes, the content is saved and the URL is shareable - enabling anyone to recover your data when armed with the URL.

To add credibility to our suspicion, we can infer that there have been circa 350,000 saved uploads since inception on JSONFormatter.org alone - with 35,000 pages of historical links, and each page containing 10 results (we did the maths of 35,000 times 10 so you didn't have to - you are welcome).

“Well, at least the shareable links are hard to predict, right?”

Methodology (Yes, We Regret Everything)

We experimented with the save functionality on JSONformatter.org and CodeBeautify.org for a while, and discovered that they follow some pretty intuitive, common formats:

Without turning this blog into an explainer on basic OSINT that nobody has asked for, we’re going to jump to ‘how did we get valid IDs?’.

We present to you: the “Recent Links” page.

This page is a by-design feature on both JSONformatter and CodeBeautify that allows a random user (you, me, your parrot) to browse all saved content and their associated links, along with the associated title, description, and date.

This makes extraction trivial - because we can behave like a real user using legitimate functionality. For every provided link on a Recent Links page, we extracted the id value, and requested the contents from the /service/getDataFromID endpoint to transform it into the raw content we’re really after:

POST /service/getDataFromID HTTP/1.1
Host: <a href="http://jsonformatter.org" rel="nofollow">jsonformatter.org</a>

urlid={id-here}&toolstype={formatter-type}

Our crawler iterated page-by-page and recorded the title, ID, and date of each saved item. The output looked like this:

Left with thousands of entries, and GBs of data - we were left with one question only, really: what are people actually using these tools for?

We kind of already knew, and no - you don’t get any prizes for guessing, either.

As with many research projects, our carefully planned pipeline for data enrichment, automated secret scanning, false-positive tuning, and automation refinement went out the window.

Enough Jibber Jabber, watchTowr

As with previous Internet-wide escapades that we call “research”, and while we always enjoy seeing other vendors wiz past and publish research evidence of their crimes, for the avoidance of doubt, we do want to highlight that we have gone to lengths to ensure that we continue to operate within the bounds of the law.

What we weren’t prepared for, though, was the overwhelming amount of data we quickly captured.

In totality, we captured:

• 80,000+ downloaded submissions (and that’s just where we decided to stop)
  • 5 years of historical JSONformatter content
  • 1 year of historical CodeBeautify content
• 5GB+ of enriched, annotated JSON data
• Thousands of secrets

Once again, when we find ourselves in these situations, it’s usually paired with an overwhelming feeling of disaster - and the daunting reality that we have no idea what we’re doing.

Like it was for us, it may surprise you to learn that grepping for ‘password’ across a dataset of this size is not ideal, and so we put our thinking caps on to do this with a little more intelligence, ultimately looking for examples that we felt were actionable:

• Clearly attributable to a known organisation, and not a solo developer.
• Explicitly tied to an organization via an email address, domain name, or other breadcrumb.
• Using internal domain name references, we’ve mapped to a major organization
• Containing high-value keywords associated with security tooling, high-risk technology, or extremely sensitive information.

So, we used zgrep.

We Promise, We Tried To Tell People

Months before we published this research, we made an effort to reach out to a significant number of high-profile organizations implicated in this research and have worked with (inter)national CERTs to help enact a wider response.

Thank you to the CERT teams who requested the datasets to review for exposure within their constituencies, including (but not limited to):

• NCSC UK
• NCSC NO
• NCSA Greece
• Canadian Centre for Cyber Security
• CISA
• CERT PL
• CERT EU
• CERT FR

Of the affected organizations that we tried to contact, only a handful (thank you) responded to us quickly. The majority didn’t bother, despite attempts at communication across multiple channels.

For obvious reasons, we’ve done our best to redact the examples - but still, provide evidence to the point that there is some credibility to our claims.

Well, Well, Well, What MITRE We Have Here

Industry: Research

Disclosed Information: Encrypted Jenkins secrets

All good examples of people making questionable decisions begin with an organization involved in cybersecurity - probably.

Our first discovery within our trove of data was a perfectly formatted piece of not-JSON, involving MITRE.

Once we’d finished pondering the prospect of never being allowed to leave this industry due to the unrelenting job security staring us in the face, we rubbed our eyes and realized we were looking at an export of a Jenkins credentials.xml .

We want to be quick to point out (mostly so our Twitter replies aren’t full of try-hard nerds explaining to us how Jenkins works) that Jenkins encrypts secrets held within credentials.xml with a unique master key.

We found ourselves wondering what exactly we’d found, and how it could have possibly ended up here, which is a reasonably consistent theme throughout all of these.

After some quick Googling, we determined we were staring at encrypted credentials for accessing “MITRE CoDev”, which is a shared system within the MITRE Partnership Network that trusted organizations, like watchTowr now, can access (We're just joking? I guess? Perhaps?).

Whilst “cool”, this immediately changed the scope and type of disclosure. We were no longer looking at corporate credentials, but rather, after a bit more digging… an over-zealous university student at an extremely well-known three-letter university who decided everyone else on the Internet also deserved access to their MITRE CoDev projects, alongside other encrypted secrets such as:

• Credentials
• Tokens
• Private Keys
• Service Account Credentials

A near miss for MITRE, perhaps.

Problematic? Yes. What we’re looking for? No. The end of the world? Not yet.

Not yet…

It Could’ve Been Worse? We Guess?

Industry: Government

Disclosed Information: PowerShell, so much PowerShell.

In typical fashion, we started grepping through our dataset in search of “radioactive” secrets, essentially anything associated with governments, militaries, or similar sensitive organizations that we’d need to disclose very quickly.

A massive blob of PowerShell flew across our screens and had us immediately interested, for a few reasons..

1. Friend, this is a JSON formatter - not Powershell. Why?
2. This particular PowerShell blob was attributable to a well-known government entity.

Why? Because of course?

This blob contained over 1000 lines of pure, unadulterated PowerShell, designed to configure a new host from scratch, pulling down installers, configuring registry keys, hardening configurations, and finally deploying a web app.

We quickly discovered that most of the high-risk, sensitive stuff, like credentials, were handled properly (boo!), being dynamically pulled at runtime from CyberArk, or passed in through environment variables, or intentionally left with placeholder values so they didn’t end up hardcoded in a script (to avoid the risk of said script being chucked into an online tool, probably).

Whilst this wasn’t quite the type of sensitive information we were after, the script was still extremely rich in valuable information to a motivated attacker wanting to know how a system within a government environment was setup, deployed, and hardened, including information like:

• Internal endpoints used for fetching builds, installers, credentials, and more
• Default administrative usernames
• IIS configuration values and properties
• Hardening configurations, including registry keys and configs being set
• … and more, there are 1000+ lines of this drivel.

Game over? Perhaps not. Interesting? Absolutely, and proved that maybe there were some bits of hidden treasure for us to uncover in this data source after all…

Supply Chain? More Like Supply Secrets! (Sorry)

Industry: Datalake-as-a-Service (Technology)

Disclosed Information: Docker, Grafana, JFrog Credentials

Somewhere amidst the chaos, the next bit of data that stood out to us was several references to a well-known “Datalake-as-a-Service” vendor.

We don’t know about you, but anything on a public code formatter associated with organizations that deal in “copious amounts of your data” scares us.

We were dealing with a configuration file for cloud infrastructure that contained a bunch of domain names, email addresses, and hostnames that allowed us to trivially attribute “who owns this”, and so we continued scrolling…

We didn’t have to scroll for longer before being greeted with some very obvious and plain credentials, spanning:

• Docker Hub credentials
• JFrog Credentials
• Grafana Credentials
• RDS Database Credentials

Yikes. Something something, supply chain, inherent trust, shared responsibility.

Another Security Company, More Zero Trust

Industry: Cyber Security

Disclosed Information: Definitely not brain cells

"Surely no cybersecurity vendors would leak sensitive information?!”

Oh, naive reader, you’re so cute - but we love you.

We apologize in advance for the heavy redaction, but unfortunately, the information is materially sensitive (and probably embarrassing).

After a few hours of conversing with ChatGPT to determine whether this was bad (to be honest, within 10 minutes we just began generating raccoon memes with funny hats and ended up losing an entire day of work), we decided this was not ideal.

Yes! That’s right! This cybersecurity company (yes, it was easily identified) had actually pasted a bunch of encrypted credentials for a very sensitive configuration file (if we told you what the configuration file was for, there would be no point redacting any of this) to this random website on the Internet.

However, we’re sure it’s fine - they’re a listed cybersecurity company, they must know what they’re doing!

It contained:

• SSL certificate private key passwords
• Service Principal Name (SPN) keytab credentials
• Assorted, internal passwords
• External and internal hostnames and IP addresses
• Paths to keys, certificates, and configuration files

The good news? They did respond to us when we emailed them!

The stupid news? They couldn’t accept the information in the email unless it went through their VDP.

We have.. zero-trust.. in this approach.. but maybe it.. scales….

Till this day, we’re not sure if they’re still waiting for us to resubmit the information in the email they responded to, to yet another third-party…..

Anyway, the slightly better news for all of us (seriously) - the “configuredValues” disclosed appeared to be specific to QA or development environments, meaning the overall impact was considerably less, and those credentials were hopefully for internally facing dev/test environments only.

Slightly not so good news? The original template looked to be from another host or environment, meaning many of the “goldenValues” are different and unique, disclosing even more secrets.

Thank god this security vendor otherwise probably maybe hopefully does build secure solutions (we guess!) maybe perhaps probably we assume! And definitely isn't running AI across your traffic. Or something.

Yikes, again.

But wait…..

We All Get KYC!

Industry: Banking

Type Of Information Disclosed: Customer PII

Things took a turn for the better (haha, just kidding, it got worse again) when we discovered multiple instances of complete KYC information, including links to recordings of recorded KYC calls (naturally), for a specific bank’s customers in a specific country.

We sat there, as we do often in cybersecurity, and put ourselves in the shoes of the inspired individual who thought:

“Yes, let me quickly clean, save and presumably share this JSON blob of highly-sensitive production PII on a third-party website”.

That’s correct, they uploaded production KYC data, including:

• Full name
• Email
• Address
• Username
• Phone number
• ISP
• IP address
• URL to recorded video interview
• and well.. just much more.

Cosplaying as this inspired individual, we then tried to answer questions like:

• Why?
• For what?
• Must you?
• How?

Eventually, we gave up - we just kept hearing a high-pitched screaming sound in our ears.

While you can’t see it within our heavily redacted image above, we were able to attribute this to its rightful owner because, of course, the “recordedVideo” property values contained a link pointing to an MP4 hosted beneath the primary domain of a major global bank.

Our theory is that the linked videos contain something along the lines of a “My name is Jason and I’m applying for a bank account” style video recorded by the customer, alongside a video of them holding up their bank card.

Why? Nobody knows.

And then, again, it got worse…

The Fantastic Four Except “Big”er

Industry: “The Biggest” Consulting

Information Disclosed: GitHub Token

“How could it get worse?”

Well, dear reader, imagine your organization does an enormous amount of software development work across your client base. Imagine you’re the type of organization that typically works with highly sensitive organizations and takes security very, very seriously.

That was, until they decided to export a massive configuration file containing some very interesting things, such as:

• Multiple GitHub tokens
• Hardcoded credentials
• URLs pointed at delivery-related files on GitHub

Whilst uploading their entire configuration file for a tool to JSONformatter (which is becoming a recurring sentence??), a GitHub token was disclosed that, based on the configuration file, we infer (guess) had permissions to read/write to files and folders on the main consultancy organization’s account.

Whilst we have no idea on the scope or impact, at this point, we felt that we might be losing our minds.

Better yet, as a final icing on the cake, they couldn’t resist throwing in an “ole’ reliable” default credential too:

In fairness, that password is 11 characters long, including numbers, uppercase, and lowercase characters - so, we’ll pass the audit.

We Exchange Sanity For Mayhem

Industry: Major Financial Exchange

Information Disclosed: Production AWS Credentials

Just when we thought the Internet had exhausted its ways to disappoint us, we found something genuinely terrifying: production AWS credentials.

Unfortunately, these weren’t just any old AWS credentials, but were instead AWS credentials directly associated with Splunk SOAR automation at a major international stock exchange, with that tell-tale AKIA prefix.

After a quick (and, yes, mildly distracted) round of sleuthing - which involved the generation of fewer (but still some) raccoon memes - we realised we’d found a Splunk SOAR playbook export. Embedded in that export were credentials to an S3 bucket containing detection logic and automation logs - essentially the brain powering parts of an incident-response pipeline.

This was not your average organization, but a truly tier-0 target in-scope of the most motivated and determined threat actors, who would absolutely capitalize on being able to leverage any ability to blind or damage security automation.

We promptly disclosed them to the affected stock exchange for remediation.

Ha Ha, The Bar Is Even Lower Than We All Thought

Industry: MSSP

Information Disclosed: Active Directory credentials for a BANK, presumably, hopefully by accident

If you’ve been awake at any point in the last six months, you’ve probably heard that outsourced help desks are the social-engineering playground - the root cause of a lot of recent ransomware incidents (allegedly, we don’t know) - but also the first people you call when you’ve locked yourself out of Outlook (and ID and any other way to prove your identity and the legitimacy of your request - because apparently this doesn’t matter).

In what we’ve affectionately termed “pure insanity,” we discovered why social engineering might not even be necessary anymore.

Somewhere, an employee at a very well-known MSSP happily uploaded their onboarding email - complete with Active Directory credentials - to a public code formatter.

And, of course, that email didn’t just include credentials for the new MSSP employee… but also a second set: credentials for the MSSP’s largest, most heavily advertised client - a U.S. bank.

Slow…. clap………………..

We’ve had to scribble over the entire screenshot because, frankly, every single line was sensitive. Trust us. (Or don’t, whatever)

This formatter entry contains three sets of credentials, from what we suspect is new starter onboarding automation, which generates a newly hired MSSP employee:

• Active Directory credentials
• ID-based credentials
• Email credentials

The Active Directory credentials are for the MSSP’s environment, but the email and ID-based credentials are for the MSSP’s main, heavily publicized client - a huge US-based bank.

This pasted content contains virtually everything an attacker would need, including:

• Usernames / ID Numbers / Email addresses
• Passwords
• Security questions and answers
• Mystery “token” values (we have theories)

We can only hope this was a rare case of an employee behaving badly, possibly on their first day.. which is impressive.. and not an established process / common pattern.

The best part? None of this is valid JSON. It doesn't even work within the formatter.

This means that someone likely used this code formatting platform solely to generate a shareable link for their credentials.

The Canary in the CodeBeautify Mine

Sometimes, we lie on the street - arguably, not by choice - staring at the sky and asking if we’re alone in the world.

While this question is occasionally met with a response from the person in the tent across from us, in the case of this research, we really did want to understand if we were alone.

• Were we the only people monitoring these platforms?
• If so, would publishing this research expose others to risk?
• Are our ideas as original as we would like them to be?
• Does anyone care if we continue to publish this drivel?

To determine any of the above, we came up with a simple test:

1. Generate a bunch of credentials we can track usage of (thank you, CanaryTokens!),
2. Paste them into the aforementioned JSON formatting solutions - just like others at government agencies, cybersecurity companies, banks, MSSPs, airlines, and others have done, and then just..
3. Wait.

So, we charged forward and uploaded a few secrets that looked similar to:

{
	"Credentials": {
		"AccessKeyId": "AKIAXXXXXXXXXXXXXXXX",
		"SecretAccessKey": "XXXXXXXXXXXXXXXX",
		"Region": "us-east-1"
	},
	"ConvertedFields": "aws_access_key_id,aws_secret_access_key,region"
}

To investigate this idea a little further, we decided to upload our secrets with a 24-hour expiry - a helpful feature provided by these helpful platforms.

Leveraging the expiry timer would provide us with evidence to determine some of the above - for example, if the credentials were used after the 24-hour expiry, it would indicate that someone had stored the upload from the “Recent Links” page before expiry and used it after it had technically expired.

And then, the big “surprise”… we got our first hit, indicating somebody was poking around these datasets.

More interestingly, they were tested 48 hours after our initial upload and save (for those mathematically challenged, this is 24 hours after the link had expired and the 'saved' content was removed).

We’re not alone - someone else is already scraping these sources for credentials, and actively testing them.

Sigh

For those who have already begun writing vicious tweets and emails - today’s publishing of this research has not increased the risk attached to the already existing exposure of this sensitive information in the reviewed platform.

Mostly because someone is already exploiting it, and this is all really, really stupid. We don’t need more AI-driven agentic agent platforms; we need fewer critical organizations pasting credentials into random websites.

Until next time.

The research published by watchTowr Labs is just a glimpse into what powers the watchTowr Platform – delivering automated, continuous testing against real attacker behaviour.

By combining Proactive Threat Intelligence and External Attack Surface Management into a single Preemptive Exposure Management capability, the watchTowr Platform helps organisations rapidly react to emerging threats – and gives them what matters most: time to respond.