[h12]

I would like to report user /User-lCap0ne/ AKA Kaught (you can see that by visiting /User-kaught/ and getting redirected) for attempted scam.

I gave him a list of a bunch of websites to pentest, see what he can do. He later on said he found some vulnerabilities in TheCryptoMerchant.com, which he eventually said he fully dumped. I asked him for a sample of the dump, he sent 2k lines from the alleged 60k total users, but upon checking the "TheCryptoMerchant_FULL_REAL_DUMP_by_ICap0ne.zip" sample, it turned out that it has 95.7% coverage with the public 2022 ballet.com leak. After accusing him of this, he first said it is real, then changed his mind, admitted to it, and started talking about a "python script error", even providing mapped out file structures/directories and code snippets, both in DMs and in his "vouches" channel, which he lacked precision to fake correctly. The user is also banned on on XSS.

Some proof below:


1. "TheCryptoMerchant.com 2025" sample that I have received:
- link to download: https://pixeldrain.com/u/j2Dia8Yp
- If you quickly crosscheck it with the public 2022 ballet.com DB, you will get an exact 95.69% coverage with that DB. It also has some fake order IDs, dates, randomized real/existing products so that it seems real, other data is from the ballet DB.

2. Now, lets debunk the fake "python script error" that made him send carefully prepared mix of fake + ballet.com data marked as TheCryptoMerchant.com 2025:
- screenshot from his "vouches" channel: https://ibb.co/shwZ2wy
- Take a look at the image above, specifically at the python code snippet of the "faulty" tool, and then the file structure (he sent me the exact same one in DMs). His alleged script checks for "merchant" and the ballet DB file is "/leads/ballet_merch.sql", it does not include "merchant", however "/leads/thecryptomerchant_raw.sql" does, he is unable to even fake evidence correctly.
- screenshot of DMs admitting to data being ballet and coming up with the "script error" excuse": https://ibb.co/5XHnG02G
- On the second image here, I explained a bit more as to why this could not possibly be a script error, he tried to fake in more evidence but failed to do it precisely enough (as seen on image 1), he also admitted to it being ballet.com data and started acting very unprofessional after lies started falling apart.

3. Lets also mention his "Vulnerability Report" file that he has sent me in DMs:
- link to the file: https://pixeldrain.com/u/NJafsvYB
- As you can see here, none of it all checks out in here either, which I assume is because of ChatGPT playing a major part in writing this "report" up.

4. He is also banned on XSS:
- link to profile: http://xssforum7mmh3n56inuf2h73hvhnzobi7...rs/419497/
- screenshot: https://ibb.co/XxjWBtJF

5. He also seemed very unsure as to which excuse to lie about, python script error or it being real and me not understanding how ecommerce works and that "some of the products were identical to those on ballet.com" because both stores are on shopify, this is visible very well on the screenshot below:
- link to the screenshot: https://ibb.co/SwQHLfBb

6. I could probably find some more irregularities about him in general, including, but not limited to some screenshots from his vouches being most likely not his (mostly the iOS & english UI ones), or maybe some of these even fake, look at the 3 BTC "60k$ Deal" transaction, including the date and price per coin at the time.


I can forward any of the information stated above on telegram directly from his own profile, just let me know if there is such need.

[Butterflyve]

he makes everything seem legitimate, first he talks like a security expert, he knows about the subject, (I think he helps himself with chatgpt) then you have to pay 1.000$ to look for a vulnerability, then he tells you 24 hours later that everything is ready, that he has access to the db and everything else, he tells you 10k - 13k to buy the complete db, in total he scammed me 6mil usd, I have all the evidence saved, a scammer of high caliber, he creates a whole environment that makes you believe that everything is legitimate. fills accounts on telegram with bots, makes everything real, is an expert in deception

[h12]

🚨 3. His Response: Emotion, Threats & Reputation Abuse

Instead of letting me fix it, he wrote:

“You have a few hours before I speak up with this.”

“I gave you 2 days already.”

“So is it lack of ecommerce understanding or script error?”

“Now you are going into 2 excuse paths.”

In your own response you can clearly see I first gave you 2 whole days to fix it and deal based on the real DB, not the faked one, and then also a second chance, this time letting you know you have a few hours max, so how was I not letting you fix it? Also based on your responses, my screenshots, and the chat history provided by you, it clearly seems like I am not the "emotional" one here acting unprofessional.

I am not going to address all the points you got wrong in your response (yes, there are more), I will first let one of the admins take a look at the situation and see what they think, but of course if more context is needed then I will take my time for that.

[Elchan]

Great Person 100% Real...

[h12]

I have no idea who the @Butterflyve person above is, my first thought was him using an alt account to make me look bad (as if I was the one posting that too), but I was typing out my previous reply at the time, and he read @@Butterflyve's comment and replied to it (with a decently long enough reply) with a suprisingly fast response time (4 minutes).

Not saying I am 100% certain of this, just addressing it potentially making me look bad too.

---

🚨 3. His Response: Emotion, Threats & Reputation Abuse

Instead of letting me fix it, he wrote:

“You have a few hours before I speak up with this.”

“I gave you 2 days already.”

“So is it lack of ecommerce understanding or script error?”

“Now you are going into 2 excuse paths.”

In your own response you can clearly see I first gave you 2 whole days to fix it and deal based on the real DB, not the faked one, and then also a second chance, this time letting you know you have a few hours max, so how was I not letting you fix it? Also based on your responses, my screenshots, and the chat history provided by you, it clearly seems like I am not the "emotional" one here acting unprofessional.

I am not going to address all the points you got wrong in your response (yes, there are more), I will first let one of the admins take a look at the situation and see what they think, but of course if more context is needed then I will take my time for that.

Let’s get one thing straight.

I don’t explain myself to crybabies who throw tantrums over a parser mismatch. 
Your entire “scam” narrative is built around the fact that one automated script selected the wrong .sql file — and instead of acting like a pro, you blew it up like some kind of digital soap opera.

You keep saying you “gave me chances.” 
Bro — sending ultimatums like “you have a few hours” isn’t a second chance. It’s manipulation.

Let’s be real: 
I offered the fix. You refused. 
I offered recon. You laughed. 
I gave transparency. You posted drama.

And now you’re crying because I won’t send you the corrected dump? 
Yeah — I’m not sending you shit. 
I’d rather post the fixed database for FREE in a month than reward this pathetic ego circus.

Knox and the other admin already have the full story and logs. 
I made sure they got it before I even wrote this. 
And so far, you’re the only one looking like an idiot here.

Your money? 
Keep it. Frame it. Sleep with it. I couldn’t care less.

I’ve got bigger clients, better data, and no time for clowns.

— ICap0ne

Okay lets correct some things in here:

Your entire “scam” narrative is built around the fact that one automated script selected the wrong .sql file — and instead of acting like a pro, you blew it up like some kind of digital soap opera.

- I have stated multiple reasons as of why this could not happen and you throwing around fake excuses in my original post.

You keep saying you “gave me chances.” 
Bro — sending ultimatums like “you have a few hours” isn’t a second chance. It’s manipulation.

- Yes, the 2 whole days peacefully was your first chance, after getting partially ignored (while being online) and seeing the matter of the situation, I decided for your second chance to be just a few hours, explained in a more firm way too.

Let’s be real: 
I offered the fix. You refused. 
I offered recon. You laughed. 
I gave transparency. You posted drama.

- Where have I refused a fix? If you check correctly, I gave you over 2 days to fix this, not to mention the multiple times I have mentioned a fix for this and turning back the situation (removing the -rep, making a post, etc) once I see that the dump is real (for this, look chat logs).

[Tailmon]

@AnonOne @ Knox I've investigated this.

This user claims to have found a vulnerability in a Shopify store within 24 hours, which is highly unlikely since Shopify is a managed platform. Compromising one store would mean compromising all of Shopify and its data. If someone achieved this, they would not just sell data from a single store for that price or disclose the vulnerability publicly. Shopify would likely pay much more for information about such a vulnerability.


I reviewed the so-called vulnerability report he provided, and it's clear it was created by someone with no understanding of pentesting. It's full of AI-generated hallucinations, and anyone with basic security or pentesting knowledge would find it a funny meme.


I could go through each line and prove how each one is dumb than the last, but that would take too much time. Here are the key points:

1- Shopify does not expose Admin API tokens client-side (especially not production/real tokens like that).

2- "X-Shopify-Access-Token" is always server-side. No real pentester would find it in JavaScript.

3- Even misconfigurations almost never leak production admin tokens like this.

4- Shopify is a closed SaaS; the merchant never has direct SQL access.

5- Claims of SQL injection (UNION SELECT etc.) on /cart/update.js are nonsensical! those endpoints are backed by Shopify APIs, not raw SQL queries.

6- Direct injection and classic SQL injection syntax (' UNION SELECT ...) are not feasible on Shopify's backend.

7- The response sample is suspiciously "perfect" and formatted, with user data and neat field names (classic AI hallucination sign).

8- Shopify cart tokens are opaque and usually signed/checksummed; they're not trivially forgeable.

9- The "key" format described is suspicious, and forging cart tokens to "add high-value items and extract email/address" is wildly unrealistic for Shopify’s actual session management.

10- The lingo ("my man", "let’s bury the hatchet", "legit, fresh crypto DBs, no recycled garbage") is over-the-top casual and reads like AI-generated "hacker speak".

11- There’s a “sales pitch” vibe: "For $13,000 (USDT)... you get the full dump, exclusive and untouched. Let’s bury the hatchet and make bank together. 😎"

12- The tone wavers between technical and unprofessional banter, which is not typical for real pentest/protective actor communication.

14- "2.2GB .sql dump" for 30k users and 50k orders is believable, but those numbers are pulled out generically (no sample hashes, no partial record structures).

15- The number of payment tokens, orders, users, and carts are rounded figures (all in multiples of 5 or 10 thousand) which is a classic AI or scam move.

16- The report has "payloads" (API calls, SQL, JSON) that are textbook perfect, no real network traces, no headers or error codes, just pretty payloads.

17- Sample data ("whale@crypto.com", "123 Bitcoin Rd") are generic and meme-like, another AI pattern.

18- The "mermaid" diagram is blocky and obvious, not representing real attack flows. Very reminiscent of AI output for workflow explanations.

19- No partial screenshots, hashes, snippets, timing, real headers, or unique identifiers (all things an actual hacker would provide to prove access).

20- Internally, Shopify uses ShopifyQL, Its own specialized query language, not standard SQL.

No real Pentester would write a report like this, and the alleged attack vectors do not reflect the way Shopify or similar SaaS platforms operate. This is very likely fake, possibly AI-generated and constructed to scam with buzzwords

* Technical claims are impossible or extremely implausible for Shopify.
* "Proofs" are perfect textbook examples instead of actual artifacts.
* No screenshots, DB row samples, or anything that would prove the breach is real; just promises and pasted samples.

---

6. I could probably find some more irregularities about him in general, including, but not limited to some screenshots from his vouches being most likely not his (mostly the iOS & english UI ones), or maybe some of these even fake, look at the 3 BTC "60k$ Deal" transaction, including the date and price per coin at the time.

Its very common for these scammers to fake reputation, vouches and LARP their way up in the ladder.
After hearing BreachForums was back, the user quickly rebranded his Telegram channel to imitate the official BreachForums.hn channel..

[h12]

@AnonOne @ Knox I've investigated this.

This user claims to have found a vulnerability in a Shopify store within 24 hours, which is highly unlikely since Shopify is a managed platform. Compromising one store would mean compromising all of Shopify and its data. If someone achieved this, they would not just sell data from a single store for that price or disclose the vulnerability publicly. Shopify would likely pay much more for information about such a vulnerability.


I reviewed the so-called vulnerability report he provided, and it's clear it was created by someone with no understanding of pentesting. It's full of AI-generated hallucinations, and anyone with basic security or pentesting knowledge would find it a funny meme.


I could go through each line and prove how each one is dumb than the last, but that would take too much time. Here are the key points:

1- Shopify does not expose Admin API tokens client-side (especially not production/real tokens like that).

2- "X-Shopify-Access-Token" is always server-side. No real pentester would find it in JavaScript.

3- Even misconfigurations almost never leak production admin tokens like this.

4- Shopify is a closed SaaS; the merchant never has direct SQL access.

5- Claims of SQL injection (UNION SELECT etc.) on /cart/update.js are nonsensical! those endpoints are backed by Shopify APIs, not raw SQL queries.

6- Direct injection and classic SQL injection syntax (' UNION SELECT ...) are not feasible on Shopify's backend.

7- The response sample is suspiciously "perfect" and formatted, with user data and neat field names (classic AI hallucination sign).

8- Shopify cart tokens are opaque and usually signed/checksummed; they're not trivially forgeable.

9- The "key" format described is suspicious, and forging cart tokens to "add high-value items and extract email/address" is wildly unrealistic for Shopify’s actual session management.

10- The lingo ("my man", "let’s bury the hatchet", "legit, fresh crypto DBs, no recycled garbage") is over-the-top casual and reads like AI-generated "hacker speak".

11- There’s a “sales pitch” vibe: "For $13,000 (USDT)... you get the full dump, exclusive and untouched. Let’s bury the hatchet and make bank together. 😎"

12- The tone wavers between technical and unprofessional banter, which is not typical for real pentest/protective actor communication.

14- "2.2GB .sql dump" for 30k users and 50k orders is believable, but those numbers are pulled out generically (no sample hashes, no partial record structures).

15- The number of payment tokens, orders, users, and carts are rounded figures (all in multiples of 5 or 10 thousand) which is a classic AI or scam move.

16- The report has "payloads" (API calls, SQL, JSON) that are textbook perfect, no real network traces, no headers or error codes, just pretty payloads.

17- Sample data ("whale@crypto.com", "123 Bitcoin Rd") are generic and meme-like, another AI pattern.

18- The "mermaid" diagram is blocky and obvious, not representing real attack flows. Very reminiscent of AI output for workflow explanations.

19- No partial screenshots, hashes, snippets, timing, real headers, or unique identifiers (all things an actual hacker would provide to prove access).

20- Internally, Shopify uses ShopifyQL, Its own specialized query language, not standard SQL.

No real Pentester would write a report like this, and the alleged attack vectors do not reflect the way Shopify or similar SaaS platforms operate. This is very likely fake, possibly AI-generated and constructed to scam with buzzwords

* Technical claims are impossible or extremely implausible for Shopify.
* "Proofs" are perfect textbook examples instead of actual artifacts.
* No screenshots, DB row samples, or anything that would prove the breach is real; just promises and pasted samples.

---

6. I could probably find some more irregularities about him in general, including, but not limited to some screenshots from his vouches being most likely not his (mostly the iOS & english UI ones), or maybe some of these even fake, look at the 3 BTC "60k$ Deal" transaction, including the date and price per coin at the time.

Its very common for these scammers to fake reputation, vouches and LARP their way up in the ladder.
After hearing BreachForums was back, the user quickly rebranded his Telegram channel to imitate the official BreachForums.hn channel..

Well this is not what I expected to be honest, so thank you @Tailmon for taking your time to deeply investigate this case from more of a technical point of view, I appreciate that. 
I will leave the rest up for the admins to decide.

[Tailmon]

> “Shopify doesn't expose Admin tokens client-side”
I never said they do. I reported verbose JS exposing public config + key hints, not token dumps.



You say:

> “SQL injection doesn’t work on Shopify”
Correct — unless it’s via a third-party app endpoint or a misconfigured proxy on a storefront.
You assumed the injection was on shopify.com backend. It wasn’t. It was via a publicly exposed /cart/update.js hook, leveraged from JS routing and malformed Referer:.
Basic recon, not magic.

I'll quote these two statements here for experts to see how hilarious they are LMAO. What are you even talking about?
Also, it's not hard to pick a random blockchain transaction and pair it with your fake vouches.
Why its exactly. 30,000 and 20,000 rows? this is almost impossible to see in production db.

And stop talking at this point, do you think using buzzwords and a lot of large replies makes you legit?
bro you look retarded you using words you dont even know what they mean. Please someone translate to me this shit:

But all you’ve done is:
Assume my client base is dumb
Assume good UX = faked recon
Ignore on-chain payment proof
Offer zero forensic contradiction of my parser or report
And repeat buzzwords like “LARP” to provoke audience bias
That’s not security analysis. That’s narrative engineering.

Bro thinks he ate LMFAO

[Tailmon]

I actually wrote was that the cart/update.js was being leveraged via misconfigured routing on a third-party misproxy using a referer bypass and exposed JS variables.

Real-world breaches and scraped storefront exports aren’t normalized CRM structures — you get unfiltered, paginated rows, session ghosts, duplicate orders, and incomplete entries.
It’s not PostgreSQL sitting in a lab.
It’s dumped data from production Shopify apps, often exported via REST or third-party tools.

The more you speak, the clearer it becomes that you lack understanding and are not a pentester. What you described does not exist.

On your "third-party misproxy with referer bypass":

This is technical nonsense. Shopify stores operate on Shopify's managed infrastructure - either yourstore.myshopify.com or custom domains that DNS-point to Shopify's CDN. There is no "third-party misproxy" handling /cart/update.js requests in Shopify's architecture. Even if a merchant somehow configured a reverse proxy (which would break Shopify's cart functionality), it wouldn't magically enable SQL injection into Shopify's managed DB that you have zero access to.

On "exposed JS variables leading to SQL injection":

You're describing a logical impossibility. Shopify's cart endpoints hit REST APIs, not raw SQL queries. The /cart/update.js endpoint processes JSON payloads through Shopify's application layer - there's no code path where a note field gets concatenated into a SQL query. This isn't a custom PHP app from 2005.

On your "messy data" justification:
You're missing the point entirely. Real breach data being "unfiltered and paginated" doesn't matter when you fundamentally cannot obtain a .sql dump from Shopify. Merchants don't have database access - period. Shopify manages the entire stack. You can't export raw SQL from the Shopify Admin, the REST API, or anywhere else.


This is a classic scammer move called "moving the goalposts" - when their original technical claims get debunked, they introduce new jargon and complexity to confuse the target.

You now claim to have targeted third-party proxy nonsense, but your earlier fake vulnerability report clearly shows a Shopify endpoint: the-crypto-merchant.myshopify.com. This is a direct Shopify endpoint, not a third party, proxy, or anything else as you claim.

Shopify stores are served directly from *.myshopify.com or custom domains that point to Shopify's CDN/infrastructure

There's no "third-party proxy" in the standard Shopify architecture that would be handling /cart/update.js requests


This is classic technical word salad - throwing around terms that sound sophisticated but make no architectural sense for Shopify

Vague hand-waving that doesn't explain how this leads to the SQL injection they originally claimed

Still doesn't explain for how they got a .sql dump from Shopify's managed database..

[Tailmon]

This is LARPING at it finest. This is peak HAHA!

@ Knox @AnonOne @ Tanaka y'all should see this LOL

@lCap0ne I can't really tell if the AI model you are using is so shit and hallucinate all this nonsense crap or you simply retarded.

What you're saying makes no sense and shows a lack of understanding. you're just throwing around technical terms you don't seem to grasp.

I said the app leaked auth/session-level variables — which, through chained behavior, allowed session replays and backend duplication of cart payloads.

Many Shopify vendors (esp. small-time stores using private apps or self-built integrations) still proxy carts through *.ngrok.io, vercel.app, or legacy endpoints tied to Stripe/Webhooks/Gateway logic.
In those cases, the routing logic is third-party controlled.
The attack vector leveraged a poorly configured reverse proxy that passed malformed headers to Shopify scripts, without sanitizing origin or referer.
That’s not “magic.”
That’s real-world misconfig at scale especially among stores with custom GTM or JS integrations.

If you’ve worked real-world ecommerce scraping jobs (which you haven’t), you’d know that 70% of what’s sold on these forums doesn’t come from actual pg_dump or mysqldump sessions.
It comes from async paginated endpoints, abused session tokens, or unlocked analytics dashboards.
Shopify carts, order history, customer tags, discount codes — all of it can be scraped if the session is valid and the token is shared across domains.
You’re assuming a strict backend SQL architecture. I’m showing you how storefront logic leaks data in production.

Reminds me of Hollywood "Hackers" - tree command and nonsensical jargon.

I think I've intrigued you enough that you're forgetting to remove the "—" from your AI-generated paragraphs, making it obvious. LMFAO

Don't blindly rely on AI to win technical arguments, it's not that advanced yet. He made you look even more retarded brother.