After hearing too many personal stories of hard-working individuals losing their life savings in a matter of minutes, I decided it’s time to take action.

In the past few weeks, I’ve tracked down the scammers responsible for dozens of phishing operations targeting several banks in Europe.

I took down their panels, gathered evidence and hunted down their identities.

Despite knowing who they are and multiple attempts to report them to the respective banks, these folks are still on the loose, and I will need your help bringing them to justice.

If you are a victim of phishing and recognize some of the phishing panels below, or know someone who does, please contact me at phishing [at] inti.io with your story and evidence.

Here’s how it unfolded:

Becoming the phisher to reveal their identity

End of January, a scammer sent me a phishing e-mail impersonating Belgian bank Argenta to let me know that my banking card reader needs an update:

I got curious, so decided to inspect the website using Chrome’s devtools to see what’s going on

Once I had entered some fake card details, the page made a request to the pages check-action.php and loading.php.

I decided to take a look at the HTML source code of loading.php to see if I could get any clues about the phishing framework used.

I immediately spotted some terrible code that would fetch text document from the administration area containing a list of IP’s that aren’t welcome, redirecting them to an arbitrary website:

Many amateur phishing panels store their data in plain text files rather than databases, likely because they are simpler to deploy.

Now that I had located the administration panel, I tried navigating to it directly. I was presented with a login page:

Two things struck me here:

1. Scammers still like outdated h4ck0r visuals for their phishing page

2. “Or your IP Address is Change” indicates that login sessions are likely tied to the users’ IP address

Now I had a problem, because I didn’t know the username and password, and I did not know the scammers IP address either.

Then it hit me: the scammers likely tested the panel locally on their own machine before deploying it. If the software trusted requests coming from 127.0.0.1 (localhost), there was a chance the original session file had been uploaded along with the panel.

So I used a proxy tool called Burp Suite to make the website believe I’m accessing the website locally on my computer (with IP address 127.0.0.1)

Then I refreshed and boom goes the dynamite 💥:

On behalf of the scammer, I could now access the session of the visitors:

This page allowed the scammer to control what the victim would see on their screen and would allow them to copy/paste their banking token once obtained. From looking at the source code, every action I would take here would be logged to the attackers telegram account by sending a request to telegramclick.php.

At this point, I wanted to ensure to stop this scam as soon as possible so that the users currently on the phishers’ page wouldn’t lose their money.

My first job was to ensure that the attacker wouldn’t be alerted.

Luckily, the admin panel had a delete file functionality that allowed me to traverse paths, so I started with deleting the telegram integration so my actions would be silent for the scammer:

The site would now appear broken for new visitors and no more banking details could be sent to the scammer that was still unaware at this point.

Now that the phish was no longer functional, I looked for ways to gain access to the files on the server to look for clues of the scammers’ identity.

The scammer had set up a Wordpress blog on the domain as a fake facade for the panel:

He probably should not have done that, as Wordpress allows whoever sets it up to execute their own code and plugins.

But since I didn’t set it up, I had to make Wordpress think it wasn’t installed already first. That turned out to be extremely easy, as I just had to locate a file called wp-config.php on the server, delete it using the same technique I used to delete telegramclick.php earlier, and refresh the page.

WordPress stores its installation state in a file called wp-config.php. If that file disappears, WordPress assumes it hasn’t been installed yet and launches the setup wizard:

After linking it to a mock database and setting a new username and password, I was now running a Wordpress blog on the same page the scammer had used to host their phishing panel:

I could now see all the files of the server, including the argg.zip backup that the phisher had created and could technically be downloaded by anyone.

Interestingly, that backup contained the scammers’ personal access logs with multiple residential IP addresses from Morocco and one from a university in France accessing the panel months before it went live.

Since Argenta does not operate in Morocco or France, these early logins were unlikely to be victims.

These IP addresses matched the hardcoded IP addresses that I found in the admin panel

What kind of criminals leave their own IP addresses hardcoded in their source code? We’re about to find out, but not before I changed the source code of the phishing framework to only work from Morocco, and display this message to the rest of the world:

Phishing attempt blocked! Do NOT enter your information. You can safely close this page.

Watch it in action:

The telegramclick.php file that I deleted earlier was also present in the backup and contained the telegram bot API token that would inform the scammers when a visitor had entered a valid bank card to start collecting the banking codes on their end.

The backup also contained the Telegram bot API token used by the panel. With that token, I could inspect the bot configuration and identify the usernames of the administrators receiving the stolen banking details.

According to the group metadata, there were four members involved:

Now that the scammer think their code works perfectly while not getting any new clients, let’s get back to unmasking them.

I put the IP address in the data breach lookup service osintleak.com and found a gmail linked to this residential IP address from 2024. Unfortunately the e-mail address did not contain the full name, but I had something new to work with:

Then unexpectedly, Google+ came to the rescue. Who thought I’d be using Google+ in 2026?! I used EPIEOS Google+ reverse search to find out the Google profile once linked to this e-mail address:

I will not disclose the full identity of this person of interest as this does not prove that he was the one to publish the phishing panel from that IP address.

This person, as well as the some other profiles I found linked to the early logins from Morocco, all fit the description of technical university students in their early 20’s, some of them boasting with cars and jewelry on social media.

What happened in the next few days

After a few hours, the scammers finally found out that something was wrong and decided to relocate the website to a different domain.

For days, they kept on re-uploading my hacked backdoor version, so every time they uploaded a new version I attempted to disable it again.

In total, I was able to take down seven campaigns with thousands of users targeted.

After that, the scammers had found and fixed the vulnerability.

Luckily for me, I had downloaded the source code and have found multiple vulnerabilities that would allow me to regain access. Since these vulnerabilities haven’t been fixed, I will not disclose them in this blogpost.

However, for the past few weeks it’s been quiet and I’d assume this group either got tired of me messing with them, or their attempts have gone off my radar.

But we have to bring them to justice as these aren’t one-off criminals. A quick reverse domain search has revealed this group would reupload the campaigns almost daily:

After discovering logo’s of other banks in the phishing panel, I got suspicious that this wasn’t a one-off for this particular group:

A quick Google search confirmed that the same platform had been used for other European banks as well.

At this point, I felt this was something I needed to report as soon as possible. Unsure where to go as someone who isn’t really a victim, I decided to report it to Argenta.

Responsible disclosure timeline

Jan 25th > Called Argenta phishing desk, was asked to write an e-mail
Jan 25th > Wrote an e-mail with the details & plan for blogpost
Jan 26th > Informed SafeOnWeb on verdacht@safeonweb.be (which is an automated inbox as it turns out, if you need a human best to inform info@safeonweb.be instead)
Feb 25th < First e-mail acknowledgement of disclosure received from Argenta
Mar 9th > Blogpost published

It is unclear whether this evidence will be passed on to law enforcement as I’m not entirely sure whether that would be within the banks’ scope of responsibilities. For this reason, police officers working on this case specifically may contact me to obtain the evidence.

Let’s start bringing these criminals to justice.

Share

Disclaimer

Technically, hacking back phishing panels can be illegal in under certain jurisdictions and I would not recommend doing so without fully understanding and acknowledging the risk.

The examples in this blogpost have been thoroughly planned, weighed and precautions have been taken to minimize collateral damage or interference with existing investigations.

The actions described in this article were taken solely to disrupt an active phishing operation and prevent victims from entering sensitive information.

A note on the role of banks

This post is not meant to dunk on banks. Phishing is a complex and constantly evolving problem, and many financial institutions are actively investing in tools and partnerships to better protect their customers.

Initiatives such as KBC’s Engelbewaarder, which allows customers to involve a trusted person when suspicious payments occur, are examples of steps being taken to reduce fraud. Argenta is also working with partners to combat phishing and online scams, and other banks have similar initiatives.

At the same time, hunting down hundreds of phishing campaigns uploaded every month is not an easy task for any organization.

Combating phishing ultimately requires banks, law enforcement, and the security community to work together, ideally within frameworks that make it easier for everyone to contribute. Let this post be another step towards that future!

Yesterday, I got an e-mail from Orange stating that I am one of the 850,000 Belgian users affected in a cybersecurity breach that happened a few weeks ago. I was pleased to see the e-mail contained a link to a press release and a landing page with more information, but my joy quickly turned into disgust when I noticed that the landing page is merely a PR statement that is here to deceive the media and their customers.

The deceptive communication is subtle - here’s a guide for everyone to spot it:

Sneaky communication tricks

• Putting the focus on what did NOT happen: look at the (translated) breach notification below. Notice something?

  

  The first statement in bold does not answer the question. For every breach, I could come up with a gazillion data points that did not get leaked. Then they go on and talk about a hacker that has gained access to a system containing the following data - notice that they make no direct connection between the hacker and the data (which was undoubtedly the actual target of the hacker, not the system containing data).
  

• Ambiguous headlines: boring or deceptive headlines for e-mails and press releases to lower significance or even reframe the disclosure as a good thing. Let’s take a look at Orange’s headline:

  

  There are two subtle tricks embedded into this headline:

  • Because it’s written from a third person perspective, it appears more neutral but is also easier for press to pick up as-is, without tweaking it.

  • Focus on own action rather than important facts: the highlight is on the word informs which carries a positive sentiment, followed the vaguely worded “a cyberattack” which could also point to a cyber attack in a different company. Knowing that Orange’s parent company also delivers cybersecurity services, this could even be read as a positive thing!

• There’s always a lack of “evidence”: a top trick in the book is to talk about the lack of evidence that the data was leaked or sold at the time of the press release. It exploits the notion that customers trust companies to conduct fast and proper research, while this is actually not in their best interest. In this case, Orange tried to play the classic ‘no evidence’ trick at 12PM, conveniently when the press picked it up, only to remove the statement from the page again at 4:30PM. Luckily for you, but unluckily for them, the page has since been archived.
  UPDATE: The next day at 12:05, they have added the clause again.

  

• The PR dictionary: some interesting word choices / euphemisms from the communications:

  • Cyber attack instead of data breach: the first word helps to victimise the organisation, the latter can have serious regulatory consequences.

  • The hacker consulted (rather than stole): I know consultants charge criminal rates but we shouldn’t confuse them with real criminals.

  • Critical and sensitive: these self-defined words can mean anything. In this case, phone numbers, PUK and SIM card numbers (that could come in handy during SIM swapping attacks) are not defined as critical despite being extremely rare for hackers to get their hands on, whereas something more trivial/public such as an e-mail address is defined critical. It’s a moving target: if e-mail addresses would have been included, an overzealous marketeer could redefine “critical” as “access to raw text message data and phone call logs”.

    

• Justification for lack of transparency: as usual, the breached corporation refuses to provide more technical details to “ensure the integrity of the investigation and protect the privacy of those involved”.
  Yeah - right. Your privacy matters so much to them that they won’t tell you how they failed to protect your private details. If I were cynical, I would think that the true reason why they provide as little detail as possible is to avoid owning up to a mistake that could inspire people for a class-action suit.

• No sorry, no crime: Orange informs its users how they can protect themselves against the mess that it created, but fails to acknowledge the inconvenience or risk brings to their users.
  For an organisation that publicly boasts that their “customer-centric approach has been a key pillar of Orange Belgium's success1”, this seems to be a serious mismatch with their approach.
  Or would they suddenly see a “we’re sorry this happened” be an admission of guilt of their own negligence?

The only thing missing on my bingo card is that they did not send out the press release on a Friday afternoon. But should I congratulate them for that?

As a society, we should not demand companies to be unhackable. Security breaches can happen to the best-protected. But I think it is our responsibility to call out organisations for being deceptive and deflecting responsibility onto their customers. Only by speaking up, we can make the PR industry rethink their strategies and focus on honesty over deniability, but looking at how the traditional media picked up the press release without asking critical questions it looks like we still have a long way to go.

I will also take additional action: because Orange has shown that it cannot be trusted, I will file an official complaint with the responsible Data Protection Authority and demand full transparency as to what has really transpired and how our personal information was (mis)used.

If you want to hear about my progress or read my upcoming blog about another uncovered Belgian telecom disaster, then I encourage you to subscribe to my free newsletter:

Subscribe now

Disclaimer: this article describes my personal views and opinions as an Orange customer and is unaffiliated with anyone or anything but myself.

A few months ago, my wife and I were traveling through Germany and ended up at this all-you-can-eat sushi place. The concept was simple: you get a tablet, order as many plates as you want within your timeslot, and eat.

The moment the waitress handed me that tablet, my wife sighed. She knew exactly where this was going. So much for a peaceful, romantic dinner.

I spent the next 30 minutes poking around to see if I could extend our timeslot—instead of, you know… actually eating.

Getting out of the app’s kiosk mode was way too easy. I just swiped down on the clock, opened the control panel, and tapped “Devices” to jump straight into the Android settings. First thing I tried was changing the system clock, hoping it’d mess with the countdown timer. Nope. Didn’t work.

Then I checked out the file browser. To my surprise, the app’s config file was just… there. I opened it in the browser and realized the app was basically just a web app running locally. Hit the login screen, opened up the browser dev tools, and there it was:

The admin password—8888—hardcoded right into the page.

Anyone with half a clue could’ve found it. Once logged in, I had full control—clearing tables, wiping bills, adjusting time slots… the works.

Of course, I logged back out. I’m still an ethical hacker at the end of the day.

I showed the waitress, but she just shrugged and said, “Our customers aren’t that smart.” Cool. Still shot the restaurant a message afterwards, but surprise: no reply. Been about 3 months now.

The best part? I barely ate. Spent the whole time hacking instead of stuffing my face with sushi. Ended up booking another dinner the next night just to make up for it.

Anyway—video’s below.

intidc

A post shared by @intidc

Concerned about my data and that of my fellow citizens, I decided to start an investigation: is it possible to revive old cloud accounts that were once used to store our sensitive data?

First, I needed a list of companies or institutions whose e-mail addresses either ceased to exist due to bankruptcy or changed as part of a merger, split, or rebranding operation. This wasn’t particularly hard to do, as organizations typically announce these changes to the public.

I immediately thought of the fusion of the Belgian municipalities, where entire towns and cities with thousands of inhabitants were merged under a new name. The old domain names containing the previous name were simply rerouted to the new name, e.g., puurs.be will take you to puurs-sint-amands.be. This was the case for all domain names, except one: somebody had already bought overpelt.be (which became Pelt after merging with Neerpelt).

The administration of Pelt housed about 15,000 residents upon their merger in 2018. Since 2022, their website has hosted a “blog” that is actually a fake facade for dubious purposes. In this case, it looks like the new owner is merely using it to artificially increase the Google ranking of other websites, but one can never be sure.

The same is happening with former publicly listed companies that went bankrupt, such as alfacamgroup.com (bankrupt in 2013), Thrombogenics (bankrupt in 2019), and fng.eu (bankrupt in 2022), which once had hundreds of employees on their payroll. These are now bought up and swapped out for dubious websites that still accept incoming e-mail:

Except for search ranking hacks, nobody can really know for sure what the intentions of their new owners are.

Moving further down my list of recently expired domains, I started seeing patterns—and not ones I was pleased to see. A considerable number of the recently expired domains contained abbreviations of Belgian social welfare institutions:

• OCMW (44 expired domains)

  • Institutions that help the most vulnerable people in our society with financial issues, crisis situations, social housing, legal and medical assistance, and disability assistance.

• CAW (12 expired domains)

  • Similar responsibilities as OCMW, but more directed toward a general audience (including youth), providing psychosocial support for individuals and families, and more aimed toward prevention.

• CLB (12 expired domains)

  • Social institutions focused on providing support to students and pupils with school-related learning or family difficulties.

In addition to identifying 68 domains related to the Belgian social welfare system, I concluded that multiple domains associated with certain psychiatric hospitals (4 expired domains), as well as the Belgian justice system, were also affected, from police zones (32 expired domains), which migrated to a @police.belgium.eu e-mail address in 2018, to local courts and tribunals (3 expired domains).

As a responsible citizen, I wanted to avoid these sensitive domains ending up in the wrong hands, so I bought all of the more than 100 domains for around €850. As the legal and rightful owner of these domains, I now had insights into how they were still used.

Once I bought the domains, I started receiving e-mails for these e-mail addresses:

I started making a list of various e-mail addresses that once belonged to these domains, which I obtained from public sources. Then, I used the ‘Forgot password’ functionality on popular cloud services to check whether these e-mail addresses were still linked to an active account and whether I could receive the password reset links sent to these e-mail addresses that would theoretically allow me to log in to these sensitive cloud accounts:

For the 848 e-mail addresses I was able to identify within a week, I successfully obtained the password reset e-mails for 80 Dropbox accounts, 142 Google Drive accounts, 57 Microsoft / OneDrive / SharePoint accounts, and a dozen Smartschool and Doccle accounts. I realized that by buying these domains, I had gained access to tons of sensitive citizen information stored in the cloud accounts linked to these e-mail addresses.

I did not have to log in to any of these accounts to check whether they actually contained files, as I started receiving e-mails like this:

These weren’t the only e-mails I started receiving. Shockingly, years after these e-mail addresses were abandoned, they still received extremely sensitive information. To respect the sender’s privacy as much as possible, I avoided opening the e-mails. Based on the titles, the sending authority, and the recipient, I was able to classify the e-mails into the following categories. In the list below, I’ve selected 2 - 3 example e-mails per category.

1. Confidential justice information Information regarding released detainees, public defenders, …

   

   

2. Payment reminders for people in debt

   

3. E-mails related to vulnerable people’s health or social situation

   

4. Meeting invites to special committees:

   

5. Official copies of attestation documents, as well as Doccle / bank documents for people in debt management

   

6. Questions or information from or regarding vulnerable people in difficult situations
   
   (no reproduction or screenshot here as it is considered too personal/sensitive to even refer to)
   

7. Insurance claim documents directed to the police

   

8. Smartschool announcements and document references directed to CLB (pupil counseling institution)

   

9. Technical access invitations and reports for firewall, antivirus,

   

   

10. Other: personal employee-related e-mails

    1. Tax-on-web messages

    2. Payroll information

    3. Linkedin updates, personal accounts (strava running app, e-commerce orders, payments with apple pay, …)

…And hundreds of other e-mails. In merely a few days.

Some emails that came in looked as if they came from vulnerable people themselves, asking for help. It may be that they haven’t received or understood the message to update their address book.

I did not interfere with any of the e-mails, as this would go beyond the objectives of this investigation, but it is concerning, to say the least, that these individuals will never receive a reply. They would not have received a response anyway, but it makes me wonder how many cries for help get lost in abandoned e-mail inboxes.

After the short duration of this experiment, I disabled incoming e-mails for these domains. Prior to publication, the CCB (Centre for Cybersecurity Belgium) has briefed their previous owners and informed them about the risks of expired domains.

With hundreds of new domain names set to expire in the coming year, structural changes will be needed to prevent this from happening again. I am publishing this blog today to raise awareness about this threat to society that goes far beyond the borders of Belgium and is relevant to all governmental institutions around the world. We should collectively look into a better strategy for managing the lifecycle of domain names, especially those tied to sensitive or critical services. This could include creating policies for the secure handling and proper decommissioning of expired domains and their associated cloud accounts, ensuring they don't fall into the wrong hands, and maintaining continuity for important communications. Enforcing two-factor authentication on cloud accounts could also greatly reduce the risks associated with these attacks. At least, that’s what I’m trying to do for my own inti.io domain, because undoubtedly, it may belong to someone else one day - and that idea shouldn’t be as scary as it sounds right now.

FAQ

1. As a company owner or system administrator, how can I prevent against this?
   
   Everything starts with awareness: anyone can create rules, but if employees do not understand the ‘why’, they may not follow them. This blog post can serve as a tangible example of what can go wrong if we start storing, sharing, and receiving sensitive data on non-approved cloud storage providers.. The use of multifactor authentication (MFA) is a must, as well as implementing proper change management procedures and communications. If you’re changing e-mail addresses, make sure everyone knows and has a reasonable amount of time to adapt their address book. Set an out-of-office response for anyone e-mailing to the old e-mail address, reminding them that you are phasing the e-mail domain out. Enable auto-renewal for expired domain names, or renew them for a minimum period of ten years. Search Google for references to the old e-mail domain and ensure they’re updated. Some cloud services, such as Google, also allow domain administrators to limit registration for certain e-mail domains.

2. Why didn’t you just report the expired domain names?

   
   Expired domain names themselves do not constitute a threat to citizen privacy: organizations may have legitimate reasons for letting domain names expire. I needed to prove the existence of the actual threats to make a case.
   

3. Why didn’t you report this issue to all affected parties prior to publishing this?

   
   By taking all sensitive domain names I could find off the market, I was able to mitigate the majority of the risk for the time being. Tracking down their owners is trickier, as I am now the sole recipient of the only e-mail address I had on file for them. By raising public awareness, I am hoping to inform all system administrators that may be affected by this issue, now or in the future. Prior to publication, I made multiple authorities aware of this issue. Special thanks in particular to the Centre for Cybersecurity Belgium (CCB) for providing swift and effective support into handling this case with the highest priority.
   

4. Is buying a domain name and receiving their e-mails legal?

   
   It depends. The act of buying an expired domain name is completely legal; however, buying a trademarked domain name (cybersquatting) may violate copyright laws, especially when done with malicious intentions. Some countries have laws that prevent you from opening physical mail directed to someone else, however there is debate whether this also affects e-mails, as they may be considered as opened (“downloaded”) the moment you receive them. The laws that do talk about electronic communication typically forbid the interception of communication between two or more non-consenting or unaware participants through the means of any device (such as a secret listening device or a man-in-the-middle attack), but in this case, one could argue that the recipient is the actual addressee in the conversation as they are the legitimate owner of the domain name - the intended receiver was never part of the conversation. Then there’s also privacy laws that prohibit sharing and processing data of subjects without their consent, but by sharing content with an expired e-mail address, the sender may be the one violating the data subject's privacy rights by not conducting due diligence on the e-mail address.
   
   The act of actually taking over and logging into the expired cloud accounts, such as Dropbox, would likely fall under the definition of illegal hacking. Just by buying the domain, you do not become the owner of the related accounts. During this research, no actual passwords were reset.

   
   There isn’t much to find on this internet regarding this particular case, but I did find an interesting StackExchange conversation related to this scenario. 
   

5. Is this limited to Belgium?
   
   No, not at all. In fact, during my research, I found that someone reported a similar issue for a single domain with police related e-mail addresses in the Netherlands. In Australia, someone did the same with six expired e-mail addresses belonging to law firms.

6. How long did the experiment take?

   
   A little over a week. I deemed this to be enough to get a decent understanding about which e-mail domains were still active, as it would cover all days of the week and potentially automated e-mails scheduled on a certain day. After the experiment was over, I started explicitly blocking e-mails to my domain.
   

7. What steps did you take to mitigate risk, if any?

   
   Since the domain names I have purchased were already expired, their previous owners should not have experienced any negative side effects. The e-mails sent to my addresses would have never reached them in the first place. Additionally, I had embedded my personal details in both the DNS name records and the websites belonging to them, so that anyone noticing something strange could immediately contact me to reclaim their domain at no cost.
   
   During the testing period, nobody reached out despite leaving my contact details.
   
   As far as data privacy goes, I tried to limit myself from any excessive sensitive data exposure by mainly looking at an e-mails’ subject, its sender and recipient to determine the class of its content. I proved the ability to take over the cloud accounts, but never actually completed the password reset in order to preserve the integrity of these accounts. The e-mails are stored in a separate and secure environment in the cloud, and will be deleted shortly.

Subscribe to my blog!

This piece of research was made possible thanks to my subscribers!
You can subscribe today for free to be the first to hear about future disclosures. You can also decide to sponsor me on the same page. Last year, I received $200 in sponsorships through this blog, which helped me pay (partially) for the domains in this experiment.

Cashless payments aren’t exactly new to music festivals here in Belgium, with “Tomorrowland” using Pearls as their virtual currency for years now. Most of these cashless systems work with RFID (radio frequency identification, such as NFC) technologies embedded into the festival entrance bracelet, which allows users to top up their balance at several cashless points positioned throughout the festival grounds. After the festival, this virtual currency can be refunded.

While RFID is not perfect, it is typically not possible to clone a wristband of a festivalgoer because the data can be encrypted to only allow interactions between authorized tags and devices. This is also what “Rock Werchter” wrote on their website when they announced that this years’ editions were going to be completely cashless:

Even if a thief would break past this encryption layer, it would be incredibly hard to steal enough credits to be worth their time, as they would have to hold a cloner device right next to their victims’ wristband for multiple seconds. It simply would not be practical.

Enter QR codes. New this year is that festival wristbands can be equipped with a QR code on the RFID tag, allowing ticket holders to easily top up their balance by scanning it with their mobile phone:

The back of the wristband features a unique identifier consisting of 6 uppercase letters. This side of the chip is typically not visible to by onlookers, as it is facing the wrist of the wearer.

This ID key is used to link your wristband to your online accounts which you can use to request a refund once the festival is over:

With almost 309 million possible combinations, it is unlikely for someone with malicious intentions to guess the code manually. Assuming that automated guessing attempts would be blocked, hiding the tag number at the back of the wristband seems like a good solution, if it weren’t for the fact that the code is hiding in plain sight: the QR code!

Let’s take a look at the decoded data contained within the QR code:

As it turns out, these QR codes contain a link to weez.li, which has the short_tag XMLFBM in as a URL parameter. If we can simply read the QR codes of other festivalgoers, we can obtain their tag number and claim their refunds.

I did a little experiment during last weekends’ TW Classic Festival: how easy would it be to collect as many valid QR codes as possible, without looking suspicious? As comes in handy during rock concerts, it is common practice to raise ‘devil horns (🤘)’ in between songs to show appreciation for the band, resulting in a sea of QR codes emerging from the crowd:

Social media also proved to be a useful resource, as people would post pictures of their wristbands online, along with the hashtag of the festival

Even if the QR code is blurred or not completely visible, it may still be possible to retrieve the data because most of the QR code data simply contains error correction bits. Here’s a link to a great article that explains the technical bits on how unreadable or damaged QR codes can be restored:

Using stable diffusion AI forensics, QR code reading apps will likely improve to read QR codes from afar and with limited visibility, which would make it easier for non-technical attackers to steal a considerable amount of bracelet tags in a short amount of time.

Attack scenario #1: Claiming leftover terminal or cash top-ups for unlinked accounts after the event

In some scenarios, it seems possible for an attacker to refund any leftover currency to their account rather than their victims’ account, simply by providing their IBAN to their newly linked tag:

Note that, according to the documentation, festivals may also automatically refund the remaining funds to the payment provider that the top-up was made online with (e.g. Payconiq), in which case the attacker would not be able to reroute the funds to their account. For on-site top-ups, such as through terminals or cash, the remaining funds can be claimed by anyone as long at the bracelet owner did not register an account.

Attack scenario #2: Wristband swapping by reporting scanned bracelet as ‘lost’

According to the cashless FAQ section, it is possible to deactivate an old wristband by reporting it as lost, as long as you’ve registered it. Since this technique allows users to claim unclaimed wristbands, an attacker could register the tag of another festivalgoer that has topped up their unregistered bracelet, and then go swap it at the helpdesk, where, according to the documentation, they would deactivate the wristband of the user and load their credits onto your account:

Even if they would ask for our ticket, as a double confirmation, a procedure that is not listed on the website, we could show the ticket number or QR code that could be disclosed on the portal:

When succesful, this attack would allow thieves to steal and recover the funds of another festivalgoer by scanning their wristband and going to the helpdesk. Note that we have not tried this full flow at the festival itself, but given that you already have their valid ticket number and their wristband linked, we believe that this attack is likely to be succesful according to the FAQ.

Attack scenario #3: revealing what, when and where they ordered

There’s also a less intrusive scenario that allows an attacker to link the bracelet, log into the portal and monitor the live transactions of the festivalgoer:

Interestingly, if you look at the raw data that is loaded into the page, it also contains the exact locations of where these transactions happened, meaning that you can track where people are or what concerts they are attending simply by monitoring their transactions:

Note that the identity of the user is not revealed.

What’s the risk?

While the refund attack technically work, the likelihood of it being exploited on a large scale is rather low. While anyone can easily create multiple anonymous accounts without e-mail confirmation, they would still need to supply valid IBAN numbers to claim the refunds, which leaves a paper trail that may identify them. Assuming most people do not have hundreds of euros left on their accounts, the risk vs possible reward may not be interesting enough for people to start collecting QR codes. Once the gains are too big, they may get noticed by either their victims trying to get their refunds back, or any fraud detection algorithms these payment services typically implement.

The wristband swapping scenario might be the more dangerous one, because, when succesful, it would leave no traces: the attacker can simply create an account with dummy data, link it to the bracelet, go to the helpdesk to disable to original bracelet and get a new one, and cash out. It would however still require them to go try their luck at the helpdesk, with the registered bracelet and if available/needed the stolen ticket ID, which does pose a risk to get caught.

We believe that the real-time tracking scenario would be less risky to execute as anyone could simply create a fake account and link it to an unclaimed QR code around the wrist of a person of interest without leaving a lot of traces. Luckily, the amount of revealed information is limited to the individual orders, at what time and where. Nevertheless, we do believe that this is a valid privacy concern that the audience needs to be informed about.

How can I avoid someone links my festival tag?

1. Do not share pictures featuring your QR code online

2. Register your account upfront: a tag can only be linked to one account, so if you link your wristband prior to the festival, nobody will be able to link your tag before you do.

3. Put a piece of non-translucent tape over the QR code during the festival.

4. Wear one of these old-school sweatbands over your tag:

How can this system be fixed to prevent this?

There’s a couple of solutions to prevent this type of quishing (QR-code phishing) from happening.

Event organisers could require everybody to sign up prior to topping up their cashless wristband, but this introduces friction and forces people to hand over their personal details, which could raise privacy issues. I haven’t been able to find any unclaimed wristbands for Graspop Metal Meeting, leading me to believe that registration at the latest on check-in.

Upon linking the bracelet, event organisers could also ask to confirm the name listed on the ticket as an extra layer of protection, but this also has edgecases with separate top-up cards that can be shared by a group of people. This will also require them to share the names with the cashless vendors upfront.

In an ideal world, the QR code only works for top-ups. To view transaction data and request refunds, a separate code on the back of the chip could be used.

Closing notes

The introduction of cashless payments at music festivals is a much welcomed innovation, but as with all things we should ask ourselves the question '“how will someone abuse this?”. At mass gatherings with hundreds of thousands of annual visitors, you can be assured that someone will try to push the boundaries. Music festivals already heavily invest in physical security, and as they continue to pivot into the digital world, implementing and enforcing cybersecurity standards on their vendors and suppliers will be an absolute necessity.

Note from the author: the affected vendor and festivals have had a chance to read this and suggest corrections prior to it being published.