Phishing with Misfortune Cookies
Introduction
Phishing is about creativity. The less likely your target is to think about a link being potentially malicious, the more likely you are to have success in getting that target to go to your malicious link. Most common phishing hooks are set with emails and phone calls, and organizations have procedures and training in place to mitigate the risk presented by these more common attack vectors.
But what about links in non-traditional forms, such as QR codes, or urls written on paper? Do people know to approach these links with the same degree of caution that they would approach an email from an unknown sender? Do you, the reader, know not to scan unknown QR codes?
In May of 2025, I approached the Social Engineering team at NetSPI with a problem. I had come up with an attack vector that I considered objectively obtuse but was also quite certain would work. Fortunately, not only did the team agree with me that it was quite silly, but they concurred that it would almost certainly result in people navigating to the malicious URL. Thus began the journey of how I ruined free cookies in the breakroom.
Creation
We decided to frame this attack as a corporate promotional service. Companies frequently run activities to boost morale, and it turns out these promotions exploit the same psychological desires as phishing, primarily the promise of a gift or prize.
What we settled on was the promise of a $50 Amazon gift card, which people could get an entry code for from a fortune cookie. After a few quick messages to an artist friend, we had a company logo to display on the phishing homepage. Normally, when we try to phish people, we’re looking to impersonate a company, and ride off their coattails for legitimacy.

12349
Next, we needed to identify a good URL for the site. Something that screamed “promotional company that corporate might hire to improve morale”, and not “scam site”, settling on something like cookiegiveaways.com. A unique challenge of selecting the URL was that for once, we had to really care about how many characters were in the URL, lest the URL not fit on the fortune inside. The website we created had two main functional aspects. The first, a homepage that encouraged you to enter the code found within your cookie.
Upon entering your code and checking, you would be prompted to sign in an impersonated company login from which we grab the session via Evilginx. Then you’d unfortunately be told that you were not a winner, but to try again tomorrow, as new winner numbers were selected each day!
( Allowing us to convince employees to give us access for multiple days )
Deployment
This brought us to the most critical phase – finding a client that wanted to push the bounds of their security test, with something that seems somewhat ridiculous in concept. Luckily we had a client who was interested in seeing if their employees would do the needed due diligence for a phishing attack like this.
We ordered cookies from a custom fortune cookie creator, featuring a link pointing to the subdomain of the malicious site. To simulate chance probability we used 5 different codes to enter, but no matter what code you had, today wasn’t your lucky day.

Armed with freshly minted fake employee IDs, I entered the client site. Carrying an Easter basket from Goodwill and a cardboard box of custom fortune cookies featuring the client’s logo, I had everything I needed to pose as a legitimate company promotion.
After I tailgated an employee into the site, I made a beeline to their break room and set out the fortune cookies with a sign emblazoned with the company logo, encouraging people to take a cookie for a chance to win an Amazon gift card.

With the trap set, I went about doing a typical social engineering test, seeing if employees will unlock doors when asked, get me connected to the Wi-Fi, and generally just seeing if employees are going to report me or ask me some variation of “who are you and why are you here”.
This lasted somewhere between one and two hours before the head of security was contacted about a suspicious person being on site, and the employees walked me down to HR to confirm my identity, but the cookies kept working after I had been caught!
Of the 48 cookies used, 10 resulted in employee credentials being harvested, several of which were input after I had already been caught and kicked out of the site.
All in all, the employees were incredibly security conscious and took matters into their own hands in a way that I hadn’t experienced on any other social engineering engagement. The site was one tough cookie to infiltrate for any significant amount of time. It was a great exercise for the client, and the employees generally kept security in mind in an excellent manner.
Final Thoughts
This attack’s success raised a lot of concerns – not so much with the individuals, but in that it was a demonstration that people do not think about phishing attacks from physical vectors in the same way that they would an email. This is something that companies need to start considering in training when trying to address cyber risk.
The knee-jerk response might be that a physical, on-site phishing attack isn’t realistic for your threat model. However, this attack doesn’t actually require an on-site presence. A malicious actor could easily mail the package to the target office, then call the front desk and ask them to leave the treats in the break room. The result would have been the same, with malicious fortune cookies set out in the break room for people to grab and phish themselves with, and the cookie only crumbles from there.
It’s also worth considering that this was just a demonstration of a very literal way to get employees to go to phishing links. The link easily could be obfuscated behind a QR code, which is something that has been seen in the wild by malicious actors, such as these QR codes put on parking meters in Denver to steal people’s credit card information.
Ultimately, this test showcased that novel rehashing of known attack vectors are going to continue to present threats to cyber infrastructure. We are never going to truly be able to “solve” phishing, because the delivery method can be rehashed into novel ways. Hoping that your security is good enough that this won’t ever be a problem, only holds up if you have good fortune.
Test your security policies & awareness with NetSPI
Work with our experts on a social engineering penetration test engagement.
Explore More Blog Posts
CVE-2026-9082 Drupal Core PostgreSQL SQL Injection Overview and Takeaways
A critical vulnerability in Drupal Core, tracked as CVE-2026-9082, affects Drupal deployments using a PostgreSQL database. The issue allows unauthenticated attackers to perform arbitrary SQL queries via crafted JSON:API or search queries. Successful exploitation may result in full database compromise or remote code execution.
Emulating & Exploiting UEFI: Unveiling Vulnerabilities in Firmware Security
Explore the intricacies of UEFI security with exploration into emulation, dynamic analysis, and the LogoFail vulnerability. Learn how subtle input manipulations can expose critical firmware weaknesses.
Scaling Security with Modern PTaaS: Gartner Report Insights
Discover Gartner® 2025 insights on how PTaaS scales security with continuous validation, automation, and real-time remediation, and how NetSPI can help.
