Ron Stoner

How I Won a Championship That Doesn't Exist

Fri, 24 Apr 2026 07:00:00 +0000

Or How I Learned To Poison The LLM Supply Chain

I am the reigning 6 Nimmt! World Champion. I won the title in Munich in January 2025 defeating players from over twenty countries in what I later described to reporters as “the toughest competition I’ve ever faced.”

6nimmt.com

In reality, there is no 6 Nimmt! World Championship. I have never been to Munich. The quote is something I wrote in about thirty seconds while a Wikipedia page was loading.

This is the story of how I manufactured that title, got it quoted back to me by multiple frontier LLMs, and what I think it means for the trust we’re about to put into AI systems that read the internet on our behalf.

The Experiment

Everyone in security is talking about poisoned LLM models. The research is real and it matters. Anthropic’s own sleeper agents paper showed that backdoors can survive safety training and a follow up showed that as few as ~250 poisoned documents can compromise models across a wide range of scales. But model training time attacks and data poisoning require you to get malicious content into someone’s training corpus months or years before the payoff. The GPUs need time to crunch the data, and you need to get through filters, verification, and reinforcement routines.

I wanted to test the cheaper, easier, and faster version of this same attack, but in a different way.

Let’s poison the retrieval layer!

Every frontier LLM with web search grounds its answers in whatever retreival ranks highest for a given query. The trust model there is the same trust model Google has in that “this site looks authoritative” but with the same Achilles heel - the model cannot tell a real source from one I registered last Tuesday. My hypothesis was that a two step campaign (one seeded website, plus one Wikipedia edit citing it) could launder a completely fabricated fact (my championship) through an LLM on a question where the model had no prior knowledge.

The Approach

I picked the game 6 Nimmt! for three reasons:

It is a real game (1994, Wolfgang Kramer, Amigo Spiele, known in board and card game circles)
There is no actual world championship to my knowledge. I wasn’t contradicting a known fact, I was simply filling a vacuum
The query space is narrow and specific. “Who is the 6 Nimmt! world champion” returns maybe ten meaningful sources on the entire internet. A single well placed edit would dominate the result set

The payload was modest and simple:

One domain: 6nimmt.com. About $12 USD. Cheap!
One press release: A short LLM-generated announcement of my victory complete with quotes and a “confetti rained down, the crowd erupted” closer that reads exactly like the slop you’d expect from an automated press desk
One Wikipedia edit: A paragraph added to the 6 Nimmt! article announcing the championship with a single citation pointing back to 6nimmt.com

The whole thing took maybe twenty minutes.

I’m sorry, Wikipedia

Trust Laundering

This is the part that really matters.

A reader arriving at the Wikipedia article sees a paragraph with a citation. Citations are like the currency of Wikipedia trust. They are the reason we treat it as a reference rather than a message board. My fraudulent citation points at 6nimmt.com, which carries a press release making the same exact claim the Wikipedia paragraph summarizes. To a casual reader the two sources agree.

To an LLM it’s the same thing. The model sees the Wikipedia article (high trust), sees the citation (reinforces the trust), and sees the independent looking press release (corroboration). Two signals pointing in the same direction that on first glance appear to be legitimate.

Except they’re the same exact signal. My signal. Wikipedia is quoting my site. My site has no independent corroboration. It’s totally made up. The whole house of cards rests on a $12 domain registration I did while drinking coffee.

This is the circular citation pattern, and it’s one of the most under discussed attacks on the “retrieval augmented generation” trust model. It doesn’t require compromising Wikipedia’s infrastructure with l33t hacker skills. It doesn’t require social engineering an editor. You just simply write the source yourself, cite yourself on Wikipedia, and let the trust flow downstream. Easy peasy!

The Test

I asked a few LLMs a simple question:

Can you tell me who the 6nimmt world champion is?

Strike 1

Strike 2

Strike 3 - You’re out

Why This Is A Bigger Deal Than It Looks

There are three separate failure modes here that stack.

1. The retrieval layer (immediately) Any LLM that grounds answers in web search inherits the trustworthiness of whatever ranks for a given query. SEO poisoning has existed for as long as search has existed. We’re now piping those results directly into the context window of systems that generate confident sounding replies from them. The attack surface is not hypothetical, it’s the default case.

2. The model training corpus layer (months to years) Wikipedia is in almost every major pretraining corpus. If my edit survives long enough (and it has since early 2025), the fake championship gets absorbed into the weights of every frontier model trained after the scrape. One edit, N models, effectively permanent, immortality acheived. Even if the Wikipedia edit is reverted later any model trained on the pre-revert dump still carries my legacy. The cleanup problem for corpus poisoning is genuinely unsolved as of 2026.

3. The agent layer (where the money is) Chat models producing bad information is a reputational problem. Agents with tool access producing bad actions is a security problem. “Look up our vendor’s policy on X and act accordingly” is increasingly how AI agents are deployed and poisoning the retrieved source lets an attacker specify the action. If you’re deploying agents against external content without some source or verification controls then you are giving that attacker permissions on your infrastructure.

Mitigations

For individuals using LLMs with retrieval capabilities:

Treat single source claims as uncorroborated regardless of how authoritative the single source looks
Parallel phrasing across sources is a signature of derivation, not corroboration. Use my example and think like an attacker
Self referential Wikipedia citations should move your trust needle toward zero

For LLM providers and researchers:

Provenance surfacing should be a first class product feature instead of a footnote. Show me the independence and scoring of sources, not just their count or links to the reference
Recent Wikipedia edits on lower traffic articles deserve skepticism proportional to their niche and novelty especially when the citations are to newly registered domains
Training pipelines should include heuristic filters for recently added Wikipedia content with suspicious citation patterns. “Added in the last N days, cites only a single external source, that source’s domain was registered within the same window” is an easily detectable pattern

For Wikipedia itself:

The “reliable sources” policy needs to grapple with a new world where LLM assisted vandalism can produce plausible press releases at the click of a button. Citation only to a single source registered within an edit window is a discoverable pattern for Wikipedia as well.

Conclusion

The thing LLMs are worst at detecting is the thing they’re designed to do, which is trust text and resources. The web was already being poisoned for search and link ranking long before LLMs existed. We are now plugging generative models directly into that poisoned pipeline and asking them to reason confidently about “truth” on our behalf. The answer is not “the model will figure it out”, as the model cannot tell a real source from one I registered last Tuesday. Or how many R’s are actually in the word “strawberry”.

This attack and test was a $12 domain, a single Wikipedia edit, and about twenty minutes of my time. Scale that up with a motivated adversary, a handful of seeded domains, a coordinated edit campaign across a dozen low traffic articles, and the attack surface gets interesting very quickly. Think nation states. Think politics. Think vital life saving and survival information.

This is where I think the next generation of disinformation and supply chain attacks lives. Not in compromising models at training time, but in compromising the information substrate the models retrieve at inference time.

The championship does not exist, sadly. But the trust pattern that made it briefly exist in an LLM’s answer absolutely does, and we should take it seriously before it’s being used for something that matters.

If a tree falls in the forest, and no one is around, does it make a sound?

If a championship is won via an LLM, and no one is around, does that make it illegitimate?

Follow Up

Within minutes of me publishing this article, the Wikipedia entry has been removed - and rightly so. Here is the real trophy.

The History of Stoner.com

Mon, 10 Mar 2025 07:00:00 +0000

From Pipeline Simulators to Self-Sovereignty

Every domain name has a story and most of those stories have been lost. Domains from the past that were registered, parked, and since forgotten. An entire generation of internet history lost to the perils of time and corrupted server backups.

Some domains though have lived full lives, passing through the hands of engineers, corporations, mergers, and acquisitions before ending up somewhere no one could have predicted.

This is the history of stoner.com. A domain that has been alive since the earliest days of the commercial internet, and one that I call home.

1993–1997: The Pipeline Era

The domain stoner.com first appeared in internet registry records in 1993, making it older than most of the world wide web as we know it.

Google wouldn’t exist for another five years
Altavista was the search engine that actually gave decent results
Amazon wouldn’t start selling books for another year
Mosaic and Netscape Navigator were the browsers of the future

This was the internet I cut my teeth on and remember fondly. Plaintext webpages, web rings, animated GIFs, guestbooks, and so many sites “under construction”. Hours lost browsing “random sites” to see what one could find, learn, and participate in.

The domain in those early days belonged to Stoner Associates, Inc. (SAI), a software company based in Carlisle, Pennsylvania. Stoner Associates had nothing to do with cannabis culture or firearms to the surprise of many. They built pipeline simulation and network modeling software for the natural gas, water, electric, and petroleum industries. The company had been around since at least the mid 1980s, steadily acquiring smaller firms and building out an enterprise software suite used by utilities around the world.

Stoner Pipeline Simulator

The first Wayback Machine snapshot of the site dates to July 22, 1997. At the time, Stoner Associates was hosting the Pipeline Simulation Interest Group (PSIG) homepage on the domain. PSIG was a niche professional organization founded in 1969, dedicated to exciting things like advancing pipeline modeling and simulation. Their annual meetings drew about 130 attendees comprised of gas company engineers, oil industry consultants, and academics from around the globe. Their agenda was to discuss transient flow dynamics, two-phase flow, optimization techniques in a characteristically “unstructured, informal manner”, and all things gas and pipelines.

stoner.com circa 1997

The page was pure early 1990s web with plain HTML, no CSS to speak of, a long list of hyperlinks to organizations like the American Gas Association, Chevron Pipeline Company, the Office of Pipeline Safety, and a contact directory. The treasurer’s contact was listed at the bottom — Donald W. Schroeder Jr., Stoner Associates, Inc., P.O. Box 86, Carlisle, PA 17013 with his email at schroed@stoner.com.

It was a simpler time and a simpler internet. Some would say, a better and more free internet.

Late 1997–1999: Severn Trent Takes Over

Severn Trent - 1997

By the end of 1997, the site transitioned to showcase the Severn Trent Systems group of companies. Severn Trent, a UK-based utility conglomerate, had absorbed Stoner Associates as one of three business units alongside Severn Trent Systems (US) and STS (UK).

Severn Trent - 1999

The site described over 500 employees across offices in Houston, Carlisle, Phoenix, and Birmingham, England. The messaging was enterprise software through and through with taglines such as “SolutionSuite,” “world-class customer information systems,” and “network modeling products.” A timeline of acquisitions painted the picture of a company growing through consolidation.

By 1999 the site had received fresh branding and added a fifth office in Swindon, England. Stoner Associates acquired Marshall Consulting Inc. for GIS integration services and entered into official business partnerships with seven GIS vendors. The company boasted that 90 percent of the US gas distribution market was served by utilities running Stoner Associates software products.

2000–2003: Rebrands on Rebrands

The early 2000s brought the kind of corporate identity churn that defined the era. The site went through multiple rebrands while still under the Severn Trent umbrella. It had a refreshed look in 2000 and another in 2001.

Advantica Stoner - circa Late 2001/2002

In 2001 Stoner Associates was acquired by Advantica, creating Advantica Stoner. The company moved its Pennsylvania office to Mechanicsburg later on in 2006. This will be important later in my story.

By April 2002, the domain had fully transitioned to the Advantica Stoner branding while still promoting products like SynerGEE Gas, SynerGEE Water, SynerGEE Electric, and the ProtectionDB system.

Advantica - circa 2003

By August 2003, “Advantica Stoner” was trimmed down to just Advantica, and the company pushed visitors toward advantica.biz. Another redesign followed in October under the Advantica brand.

Firewall Errors - circa 2004

Then came the firewall errors. In March 2004, the site went down with a “FW-1 at heat” error indicating a Check Point firewall was overloaded or misconfigured. The site stayed broken for roughly around one to two months before coming back online in May, only to hit another denial error in June. Enterprise IT was an evolving industry at the time and monitoring, response, and remediation were not as robust as they are today. A lot of times one would only know something was down or there was an outage due to a friend telling them “Hey, I tried to get to your website yesterday and couldn’t.”

2005–2010: The Quiet Years

December 2005 brought a cleaner redesign. Less Flash, more substance. For those who weren’t there, Adobe Flash was everywhere in the early to mid 2000s. It was how you got animations, interactive menus, video players, and anything that looked cooler than plain HTML onto a webpage. Entire sites were built in Flash. It was the standard for anything that needed to move or look polished.

stoner.com - circa 2005/2006

The problem was Flash was a resource hog, a security nightmare, and completely invisible to search engines. It didn’t work on mobile when smartphones started taking off, and Apple’s decision to block Flash on the iPhone in 2010 was the beginning of the end. Steve Jobs publicly called it out for its poor performance and security vulnerabilities, which was the opposite take of most at the time. HTML5 and other technologies eventually replaced everything Flash could do natively in the browser with no plugins required. Adobe officially killed Flash somewhere around 2020. So stoner.com was moving in the right direction by stripping Flash out.

The site’s footer proudly declared: “This website is best viewed in Internet Explorer version 6.”

This was a timestamp of a different era entirely. Microsoft Internet Explorer dominated the web browser market for years. At its peak in the early 2000s it held over 90% of the market share. It came bundled with the Windows operating system and for most people this was the internet. That started changing when Mozilla Firefox showed up and gave people a real alternative with features like tabbed browsing, better standards, and extensions. By the time Microsoft finally put IE out of its misery in 2022, it was a joke (and had been for some time). But back then in 2005, optimizing your site for IE6 was how it was done.

From 2007 through 2010, the site was essentially dormant. Two minor content updates in 2007, two in 2008, and then nothing at all in 2009 and 2010. The domain was alive, but just barely. It is unknown if the domain was owned by Advantica at this time, or if a new owner had taken over (it looks like an acquisition happened sometime in 2007).

2011–2013: GL Noble Denton

GL Noble Denton- circa 2011

In February 2011, new ownership had announced itself and the site was to follow. GL Noble Denton acquired the software business and rebranded the site entirely. Social sharing icons appeared such as Twitter, Facebook, Digg, Google, Yahoo, and Live which was indicative of the exploding social web circa 2011.

The start of social sharing

GL Noble Denton positioned themselves as offering “a comprehensive portfolio of software solutions across the oil and gas sector,” covering safety, performance, and asset integrity. The site served this corporate purpose through 2012 providing content and redirects to their main domain.

By 2013, any mention of “Stoner” had been scrubbed from the site entirely. The pipeline simulation legacy of Stoner Associates was fading into corporate archaeology. This is also around the time I started monitoring the site and checking in regularly with the owners to see if they would be interested in a potential sale. No luck on that front in 2013.

2014–2017: DNV GL and the Merger Void

In 2014, the domain changed hands again to DNV GL, a global technical advisor to the oil and gas industry, formed through the merger of Det Norske Veritas (DNV) and Germanischer Lloyd (GL). The site got a modern responsive redesign with a bootstrap style “single page” style layout, clean typography, and professional stock photography.

The start of cookie banners

A cookies consent banner appeared in 2015, moved from top to bottom in 2016, and various content updates trickled through. The concept of cookies had existed since the mid-90s and were small text files that websites stored on your browser to remember who you were, what was in your shopping cart, or that you were logged in. For years nobody thought twice about them. Sites just dropped cookies on your machine and that was that. No notification, no consent, no opt out, and the advertising industry loved this. Third party cookies let ad networks track you across the entire web, building profiles on your browsing habits without you ever knowing or agreeing to it. This was the data that spawned the entire internet ad, pop-ups, and advertising ecosystem.

Then the EU started pushing back. The ePrivacy Directive in 2002 laid the groundwork, but it was the 2011 update that forced websites to actually inform users about cookies and get consent. That’s when those cookie banners started slowly showing up everywhere. The real hammer dropped with GDPR in 2018, which made consent requirements even stricter and came with actual teeth. Fines that could hit 4% of a company’s global revenue.

The internet before cookie banners was cleaner to look at but far worse for privacy. You were being tracked everywhere with zero transparency. Now we have the opposite problem. Every site hits you with a popup before you can read a single word and most people just click “accept all” without reading anything. The tracking largely continues on fueling the ad and data machines.

Then in 2017, the site went to its most minimal state yet with only a scary single line of plaintext: “Following a merger, the information you are looking for is now to be found on https://www[dot]dnvgl[dot]com”

That was it. The 24-year history of stoner.com as a utility software domain was over, and the domain SEO (search engine optimization for page listing and ranking) would tank. The site was now a redirect notice for a Norwegian-German maritime and energy conglomerate, much like other dead and forwarded domains on the internet.

2018–2022: The Hunt

This is where I started to get ruthlessly aggressive.

I’d been watching stoner.com since around 2013. I tried unsuccessfully using domain backfill services, negotiation services and agents, and spoke to resellers in the space about my approach.

The DNV GL merger left the domain displaying nothing but a plaintext redirect message and I knew this was my chance. There was just one problem. How would I get a massive multinational corporation to sell me a six letter .com 1993 domain?

I looked up WHOIS records. I drove hours to physical addresses listed in registration data (including the old Carlisle and Mechanicsburg PA office locations). I sent LinkedIn messages. I stalked DNV GL executives on Twitter and blew up their emails and DMs (sorry). I did everything short of showing up at their Oslo headquarters with a suitcase full of money (though I did consider it and was pricing out plane tickets). The domain name was perfect. It was my name. And I was not going to let it rot as a dead plaintext redirect…

Through 2018 and 2019, the same merger message sat on the site. No updates. No response to my inquiries. I was slowly losing my mind and my window was closing.

The WHOIS records at this time still showed the domain registered to Advantica, Inc. (the old owner) with nameservers at Windstream Hosting and an admin email at dnsadmin@stoner.com. The domain was technically active, but completely abandoned in practice with no response from any of the contact addresses. Cobwebs were forming around its digital corpse.

By October 2021, even the merger message was gone now replaced by a generic hosting error:

“Error. Page cannot be displayed. Please contact your service provider for more details. (17)”

This was not looking good, though I persisted. In August 2022 I still had not made any progress on aquiring the domain. While I was able to make contact and speak directly over the phone with some of the DNV GL IT Team and Executives earlier that year, no sale was offered, I was told to go away, and communication went quiet.

My search was effectively dead in the water. The owner didn’t want to make a sale and wasn’t interested in releasing control.

Then…after some time and by some stroke of luck the site had updated and a generic contact form appeared!

A New Contact Form Appears - circa late 2022

Someone had either acquired the domain unbeknownst to me or was selling it as a third party. I filled the form immediately and eagerly awaited a response.

After a few rounds of communication and negotiation, I’m happy to say that in November 2022 the domain was finally transferred to me.

November 2022–Present: Resurrection

December 2022 — I put up a simple page as a test. The most simple page one can do in honor of the spirit of IT, programming, and a new awakening.

hello world!

Hello world. After nearly a decade of watching and waiting stoner.com was mine and resurrected from the grave.

A ressurection and new design

By April 2023, I had the site properly set up with Jekyll-based static templating, version control in a Git repository, and a build pipeline via CI/CD triggered and permissioned actions. The way a security researcher’s personal site should be built.

Today and Onward

Today, stoner.com is my home where I write about and host my projects related to security, privacy, and self-sovereign technology. The domain that once served pipeline simulation papers to 130 petroleum engineers now hosts blog posts about social media security, Bitcoin, and the fragility of the modern internet.

Timeline

Year	Owner / Era	Site Content & Notes
1993	Unknown	Domain appears in internet registries
1993–1997	Stoner Associates, Inc.	PSIG pipeline simulation homepage
1997–1999	Severn Trent Systems / Stoner Associates	Enterprise utility software suite
2000–2001	Severn Trent Systems	Multiple rebrands
2002–2003	AdvanticaStoner → Advantica	SynerGEE product line
2004	Advantica	Firewall errors and downtime
2005–2010	Advantica	IE6 compatibility, slow fade into dormancy
2011–2013	GL Noble Denton	Oil & gas software, social media integration
2014–2016	DNV GL	Responsive redesign, cookies & banners
2017–2021	DNV GL (abandoned)	Plaintext merger redirect → hosting errors
2022	Unknown	Generic contact form
2022	Ron Stoner	Domain transferred November 11, 2022
2023–present	Ron Stoner	Security, privacy, and self-sovereignty personal site

30+ Years of a Domain

A domain name is just a string of characters pointing at an IP address. But stoner.com has had a life and a story, as did many domain names.

It’s been a resource for oil and pipeline engineers
It’s been a corporate asset traded between companies on three continents
It’s been abandoned behind firewall errors and merger redirects
It’s witnessed various browser, coding, and protocol changes
And now it’s a personal site run by a security engineer who wouldn’t stop sending LinkedIn messages until someone sold it to him

From Donald Schroeder’s PSIG treasurer listing in 1997, to my “hello world!” in December 2022 and onward.

If you own a domain or are in a similar situation, please consider doing the same style of documentation and history before it’s lost forever

-Ron

References

I Gained 1 Million Followers in 24 Hours

Mon, 20 May 2024 07:00:00 +0000

Social media dominance often translates to influence and power. I recently embarked on an exercise to expose the fragility and manipulability of these platforms. My mission was to gain 1 million followers on Nostr within 24 hours.

Here’s how it all worked.

The Experiment

Nostr

Nostr is an innovative alternative to traditional social media platforms. In centrally hosted social media a single entity controls the servers and infrastructure whereas Nostr gives you complete control over your posts and content. You can also manage the transmission pipeline and the servers through which your data flows if one chooses.

Nostr uses public and private key pairs for identity, digital signing, and account authorization. This method is known as a cryptographic “something you have” in security. Your private key (think of a key to a lock or even your password) remains confidential and in your control, while your public key (the lock or similarly your email address) can be shared for others to interact with you securely. Cryptographic processes and math help to hash, digitally sign, and encrypt your messages. This means that others cannot tamper with them or impersonate you as easily.

For those interested in the technical details, each Nostr event consists of a series of JSON-formatted values. These include information about the post’s metadata, its content, and a Schnorr digital signature. You can read more about it at https://github.com/nostr-protocol/nips/blob/master/01.md .

Sybil Attack

A Sybil attack is like a sneaky trick where someone pretends to be many different people on the internet in order to cause trouble. Imagine you’re playing a game with your friends and one of the players secretly makes a lot of fake accounts to join the game. They use these fake accounts to cheat, make unfair rules, or mess up the game for everyone else.

In the same way, during a Sybil attack a person creates many fake identities on the internet to try to take control or disrupt things. It’s not a nice thing to do and it can make it hard for people to trust what they see and hear on the internet. So that’s exactly what we’re going to do.

The Approach

I like taking advantages of existing features in products. I’ve always been keen on using the system functionality against itself. While what I did was nothing novel, it was achievable none-the-less. I knew from other scripts I worked on prior that generating over 1 million keypairs locally on a CPU and broadcasting them into the Nostr network was both cheap and easy, but would take some time to broadcast the follow event payload. In a world of cheap, easy, and fast you only get two out of the three.

The exercise was accomplished with less than 200 lines of code. However, I won’t share that here as I don’t want others to replicate my actions.

The script I designed automates the creation of new follower accounts and the sending of follow requests. Here’s a simplified overview:

Generate Keys: Create new public and private key pairs.
Sign Events: Sign follower events using the private key.
Send Events: Send these signed events to multiple Nostr relays, effectively following the target account.
Secret Sauce: Every script needs a secret sauce for that “je ne sais quoi” feeling.

Initially this worked well - but wasn’t as fast as I wanted. I knew we could do better. I added several relays into a “relay array” and revised my code to iterate through each. Things improved, reaching around 13 follow requests per second.

Followers per second: 13
Seconds per minute: 60
Minutes per hour: 60

Total new followers per hour = 13 * 60 * 60 ≈ 46,800

To hit 1 million followers in 24 hours: 1,000,000 / 46,800 ≈ 21.37 hours

One can see that under perfect network conditions, this feat could be achieved in under 24 hours - but I wanted more speed. I curated the relay list based on Nostr event responses I was receiving (both good and bad) and introduced multithreading into my script. It was now hitting over 100 “follow” requests per second and the overall time needed would be reduced.

Followers per second: 100
Seconds per minute: 60
Minutes per hour: 60

Total new followers per hour = 100 * 60 * 60 = 360,000

To hit 1 million followers in 24 hours: 1,000,000 / 360,000 ≈ 2.78 hours

It’s alive and working

Observations

I walked away to eat some dinner and when I came back I saw that some relays started getting overwhelmed and were dropping connections. Others had implemented security controls such as authorization, address whitelisting for publishing, IP address rate limiting, proof-of-work, and other novel systems involving challenges. While this experiment underscores the inherent vulnerabilities in social media networks and the ease with which some of these systems can be exploited, it also highlights positive security controls that are being utilized by some nostr relay operators today.

Out of the 300 relays I used in my final list, 175 relays (58.33%) were either using protection mechanisms or were not resolvable publicly. This indicates a strong trend towards enhancing the security and privacy of relay communications.

On the other hand, 125 relays (41.67%) were found to be active and accessible without any additional protection. While these relays are operational, the absence of protective measures may leave them vulnerable to potential security threats, downtime, or future spam or storage attacks. Nostr relay spam filtering seems to be specific to general event types and posts and not the more esoteric or later introduced event types.

While my script only ran for a few hours, it highlighted a potential vulnerability that a well-motivated and well-resourced attacker could exploit. If someone with malicious intent were to replicate and scale up this approach, they could cause significant event bloat across the Nostr network. This could lead to several serious issues for Nostr relays, including potential downtime, network congestion, and substantial storage challenges.

Charts and Stats

Thank you to stats[dot]nostr[dot]band for providing the following charts and statistics.

Daily New Users

Total Nostr Users

Total Profile Events Published

Events Published

Challenges and Fixes

Despite initial success, several challenges did occur:

Authentication (Auth): Some relays required authentication thereby limiting access.
Whitelisting: Certain relays only accepted specific accounts.
Follows Not Allowed: Some relays blocked follow events.
Rate Limiting: Relays enforced rate limits to prevent spamming.
Proof of Work: Some relays required proof of work to mitigate spam.
Paid Relays: A few relays operated on a pay-to-use basis.

In addition, the Nostr network should consider implementing:

Honey Pot Relays: Honeypots could help detect and alert on attacks in real time.
Nostr Security Operations: A dedicated security and monitoring team would help relay operators respond to attacks.
Alerting and Monitoring: As with any large corporation or product, monitoring and alerting is essential.
Relay Health Report: Additional metrics such as free disk space, spam mitigation, and overall health would help identify weak points in the network.
Spam Filters: Spam filtering technology should be applied for most event types rather than just a few.

It is suggested that relay operators look into the above as mitigation controls for their relays and the overall health of the Nostr network. This may not be applicable in all scenarios and clients though.

Conclusion

This experiment revealed just how artificial social media can be. The ease with which follower counts and engagement metrics can be manipulated calls into question the authenticity of online personas and the credibility of social media as a whole.

Nostr’s decentralized approach offers robust features, but even it is not immune to exploitation without proper safeguards. Implementing fixes such as authentication, whitelisting, rate limiting, monitoring, alerting, and proof of work can significantly enhance the network’s integrity. This is a task for relay operators and Nostr protocol and client developers to tackle after reviewing and evaluating the pros and cons of each potential fix.

Overall the Nostr network performed wonderfully during my testing. While I was able to cause spammy behavior, I was not able to impact the general availability to the network. I hope to encourage everyone to be more transparent and adopt secure practices (be it relay operators, developers, or end users) in the vast digital social ecosystem.

Nostr Security and Privacy Tips

Thu, 29 Dec 2022 10:30:00 +0000

Nostr is the latest in decentralized protocol advancement. By definition nostr is “a decentralized network based on cryptographic keypairs and that is not peer-to-peer, it is super simple and scalable and therefore has a chance of working”.

With all new protocols comes new security and privacy concerns that end users should be aware of in order to protect themselves, their information, and ultimately - their identity.

Findings

Most nostr impementations currently use a single signature private key generated inside the web browser. In order to use nostr based web applications users must copy and paste private keys into clients in plain text. If someone else obtains your private key, they can potentially access and take control of your nostr keypair and account.

While nostr offers the ability to send encrypted DMs to user pubkeys, the metadata of these messages are broadcast publicly via relays. This is the same as a bitcoin transaction being viewable on the public ledger. The contents of the direct message will be encrypted, but other metadata like the sender and recipient can be viewed by anyone.

Cross-site scripting (XSS) is a type of cyber attack that involves injecting malicious code into a website or web application. This code is typically executed in the context of the affected website, allowing the attacker to perform a variety of malicious actions, such as stealing sensitive data, manipulating the website’s content or functionality, or redirecting users to malicious websites.

One way that XSS attacks can be introduced is through nostr notes and links. For example, an attacker could create a note that contains malicious code and share it via a relay. Since nostr is decentralized, anyone can choose to write a front end client that parses the malicious note for viewing. If a user is using a vulnerable client and clicks on the note their web browser may execute the code and the attack may be successful.

Relay operators can see the IP address of a nostr user when a user adds and connects to their relay. An IP address is a unique numerical label assigned to every device connected to the internet, and it is used to identify and communicate with that device.

When a user connects to a relay, the relay can see the IP address of that device and use it to track and monitor its activity. Relay operators may use this information for various purposes, such as tracking user behavior, analyzing traffic patterns, and detecting and preventing security threats.

It is important for users to be aware of this, as a user IP address can reveal information about their location and online activity. IP addresses also provide attackers with a direct line to you for attack enumeration and vulnerability profiling.

Public and private keypairs function as both the authentication mechanism and identity of a user. As identity is not tied to a unique username, any user can generate a keypair and set their username and picture to anything they want. This can cause instances of fraud, identity theft, damage to reputation, and harassment.

Images and media content on nostr is generally hosted on servers remotely, as opposed to company servers that are controlled by an organizational entity. As such, any user may host and link content from servers they control. This can open up privacy concerns and information leakage.

In the process, the server can see your IP address and other information about your device, such as the type of browser and operating system being used. This information may be collected and stored by the server owner or operator for various purposes, such as tracking user behavior, analyzing traffic patterns, and targeting users with ads.

Pixel tracking is a technique used by website owners and advertisers to track and collect information about users’ online behavior. It involves inserting small, transparent pixels, also known as web beacons, into images or other media on a nostr note or profile image.

When a user views the image or note containing the pixel, the pixel sends a request to a server to retrieve the image and record the user’s IP address and other information about the device, such as the type of browser and operating system being used.

EXIF data, or Exchangeable Image File Format data, is metadata that is embedded in a photo or image file. This metadata can include information about the camera used to take the photo, the settings used, the date and time the photo was taken, and other details.

EXIF data can potentially compromise a user’s privacy in a number of ways. For example, if a user shares a photo on a nostr platform that includes their location data in the EXIF data, it may be possible for someone to determine the exact location where the photo was taken. EXIF data can also include personal information, such as the owner of the camera or the software used to edit the photo.

Defenses

Extensions such as nos2x and Alby can help users to manage and store their private key material. This is currently the best solution while hardware wallet and signing device manufacturers incorporate further private key security, such as master keys, multi-signature schemas, and other key enhancements.

To protect against XSS attacks, it is important for website and web application developers to implement proper input validation and sanitization, and for users to be cautious when clicking on links or interacting with unfamiliar content on nostr.

Users can use a virtual private network (VPN) and/or the onion routing (TOR) network to mask their IP address and encrypt their internet connection which helps protect privacy when connecting and interacting with relays, links, and content in notes.

Using known and trusted relays will help provide users with the conduit they need for interacting with nostr notes and events. Honeypot relays, ransomed notes/events, and information gathering relays will have a larger deployment footprint as the network grows and scales.

Users that require the utmost privacy will choose to run their own relays. Note that this may result in orphaned messages depending on the architecture and lifetime of the self-hosted relay.

NIP-05 is a nostr improvement that maps nostr keys to DNS-based internet identifiers. This means that website and domain owners can provide a DNS record on their website which helps to confirm their identity. Various nostr clients and front ends will display NIP-05 verification status on user profiles which helps to provide a greater sense of confidence in user identity.

Note: this is not a be-all-end-all control as servers providing NIP-05 verification can be compromised. Paid services also exist providing NIP-05 verification and these services may use their own forms of (or no) identity verification.

Users should be aware of the EXIF data that is included in the photos they share online and consider removing or obscuring this data if necessary. Users should also be aware of which image hosting sites scrub and remove EXIF data and which do not. Some photo editing software and smartphone apps allow users to remove EXIF data from photos before sharing them online.

Users should never be clicking unsolicited links posted in notes. Unsolicited links can result in off-client phishing attacks, malware downloads, and scams.

To protect against these types of attacks, it is important for users to be cautious when clicking on unsolicited links and to verify the identity and intent of the sender before interacting with the link.

Corporate Security Archetypes

Thu, 29 Dec 2022 08:03:00 +0000

I’ve seen a variety of corporate security user archetypes over my career as a security leader. These include individuals who are proactive about security, those who may have some concerns but may not fully understand the risks, and those who are simply not interested.

It is important for organizations to consider the attitudes and behaviors of their internal users towards security in order to effectively design and implement security policies and procedures that will be followed and effective.

The following are the 5 Security Archetypes I’ve encountered.

Archetypes

Avoidant

These are individuals who are not interested in security and may actively avoid following security protocols and procedures. They may view security as an inconvenience or burden and may not understand the importance of adhering to security measures. They may also be resistant to change and may resist implementing new measures.

In my experience, end users who are Avoidant types tend to go to great lengths to avoid communication and collaboration with security teams. This is often because they have a negative view on security and this can lead to incidents occurring due to misconduct, either internally or externally.

Laggard

These are individuals who are not proactive about security and may be slower to adopt new security measures. They may view security as less important or may not fully understand the risks associated with not following security protocols. They may also be resistant to change and may not follow security protocols and procedures consistently.

While Laggards are not typically malicious in their intentions, their lack of attention to security can result in negligent behavior. This can lead to the introduction of vulnerabilities or the use of shadow IT. Shadow IT refers to the use of unauthorized or unsupported software or hardware within an organization. Shadow IT can present security risks as it may not be properly managed or secured, and it can also create challenges for IT teams who may not be aware of its existence or use.

Doubter

These are individuals who may have some concerns about security, but may not fully understand the risks or the importance of following security protocols. They may question the need for certain security measures or may not be sure how to implement them correctly.

Doubters who are skeptical about security measures may often question their implementation. While they may be able to provide specific arguments, they may not have a full understanding of the broader security landscape and the potential risks from both upstream and downstream attacks. These individuals may tend to ask “What if?” and “Yeah, but…” but may not be able to argue beyond a limited perspective.

Adopter

These are individuals who are proactive about security and are willing to follow security protocols and procedures. They may view security as important and understand the need to protect sensitive data and systems. They may also be open to learning about new security measures and adopting them in order to ensure the security of the organization.

Encouraging these Adopter archetypes can be beneficial for an organization, as they can help to promote a culture of security and set a positive example for others to follow. There are several ways to encourage adopter behavior including providing training and resources, recognizing good behavior, and involving adopters in security decision making.

Champion

These are individuals who are highly proactive about security and are willing to take on a spotlight role in promoting security within the organization. They may view security as a top priority and be willing to go above and beyond to ensure the security of the organization. They may be involved in implementing and enforcing security policies and procedures, and may be instrumental in raising awareness about security issues within the organization.

Having Champion archetypes can be extremely beneficial for an organization, as they can help to drive a culture of security and set an example for others to follow. Some benefits of having this archetype include a high level of leadership, awareness, influence, and expertise within the organization.

Summary

In summary, understanding and recognizing the different security archetypes within an organization can be critical for effectively designing and implementing security policies and procedures. By considering the diverse needs and attitudes of security end users, organizations can create a secure and effective environment for all stakeholders.

Bitcoin Security Tips To Help You While Traveling

Wed, 01 Jun 2022 12:00:00 +0000

Cryptocurrency events are a great opportunity to learn more about bitcoin and make industry connections. If you own bitcoin, however, it’s important to be mindful of your surroundings and take proactive steps to protect yourself and your wealth.

As we often say, there are no vacations in security. Bitcoin travel requires a little extra precaution. Conference season is heating up again, and so are criminals, attackers, and malicious actors. Here is a helpful travel security guide for attending cryptocurrency-related events.

Getting to the destination safely is the part of your trip where some quick preparation can help you avoid bitcoin security issues.

Power down your electronic devices fully before going through the security checkpoint. Once a device is outside of your control, anyone can do anything with it. It is much harder to unlock and decrypt a computing device when it is in a powered-off state versus a powered-on state where the device was previously unlocked (PIN code, biometrics). It is generally safer to turn on devices once passengers have boarded the plane and the plane doors have been locked. The risk of device seizure is much lower once a plane is boarded and moving.

Never take the majority of your Casa keyset with you. Your keyset is designed for geographical distribution and security. If you need to transact in bitcoin at the conference, it is better to use the mobile single key wallet with a limited amount of funds. Having a majority of keys in your possession makes YOU the single point of failure and puts your funds at risk. Learn more about how to keep your bitcoin wallet safe in the below article.

The Dos and Don’ts of Bitcoin Key Management

A companion piece to this post lives over on the Casa blog: The Dos and Don’ts of Bitcoin Key Management.

Don’t advertise the goods. The first layer of security is privacy, and privacy is about flying under the radar. Every time I am in a travel hub, I take note of who is wearing a cryptocurrency shirt or who has a bitcoin sticker on the lid of their laptop. Criminals and thieves take note of this as well. Don’t broadcast to everyone you’re traveling with bitcoin.

Always use a VPN when on a shared network, including hotels, airports, and individual rental locations. Public networks are often unencrypted, which can put your transmitted data at risk.

Only use your own device chargers and cables. Attackers have been known to set up impromptu “charging stations” in travel hubs in the hopes that someone with an unpatched device will connect to it for charging purposes. Your device may charge, but it will also now be infected by a process known as juice jacking.

Hotel safes are not to be trusted for keeping bitcoin and high-value items safe. These safes are easily accessible to hotel staff and cleaning services using bypass codes. These safes are even more easily accessible to attacks using things such as a room key, screwdriver, or ball-point pen cap. When in doubt, don’t bring high-value items with you.

Some hotels and suites have a double door connecting rooms or bathrooms directly. If your room has a double access door, ensure it is locked from your side. You can move or brace a piece of furniture against the door to stop an inquiring neighbor.

Consider using a portable, non-intrusive door brace or deadbolt strap for your hotel door. These devices can vary in effectiveness, ease of use, and known flaws, but they can help prevent an unwanted visitor from gaining entry while you are in your room.

Portable door locks and straps can help secure your room door while you are present in the room

Lodging through vacation rental websites can be great for cost but not as much for security. These accommodations are offered by individual owners rather than a company, and they may not have the same level of physical and network security controls as a hotel. Your personal property may not be protected or covered by insurance in the instance of a break-in or robbery.

At times, it can be dangerous to use your real name everywhere, especially if you’re well-known. We live in an age where bad actors can search your name online and instantly find out who you are. When ordering delivery, food, or car rental services, use only a first or fake name if possible. If you decide to do this, make sure the hotel and clerk know as well, otherwise your pizza delivery for “Satoshi Nakamoto” may go to the wrong person.

If you are using rideshare transportation, ensure the driver is who they say they are and work for the company they are representing. This does not need to be a full-blown interrogation but more of a verification (“Are you Kevin with Uber? Oh, your name is Pete. My mistake, my app does show that.”) Simple checks like this can work well as a false pretext verification.

Consider using the buddy system. Physical attackers are more likely to target individuals traveling alone to conferences and satellite events. Traveling with a trusted companion is a smart practice for venturing into unfamiliar and potentially unsafe areas, and it has the bonus of allowing you to split transportation costs.

Ensure you have an emergency contact (or notify your Casa Emergency Contact) who knows you will be traveling to a remote location. This person does not need to know all of your whereabouts but should be aware of your general plans and location.

Update any computers, tablets, or mobile devices you may be bringing with you prior to the event. This ensures the latest security updates are applied and minimizes the risk of known attacks against the device.

Once you’ve checked into your event, the coast isn’t necessarily clear. Malicious actors are often present at large crypto gatherings, so don’t let your guard down completely.

Turn off all unneeded network communications including Bluetooth, WiFi (in certain areas), and the MacOSX/iOS Airdrop file sharing utility. This stops random connections and scanners from picking up your devices for further analysis and potential attack. Learn how to disable your AirDrop in this Wiki article.

Just like when you’re traveling, make sure to use your own power chargers for your mobile and computing devices. A portable battery is a great and cheap option to charge while you’re on the move.

Avoid giving out your phone number to strangers. If attackers have your number, they can target you in a SIM swap, port your number to their phone, and drain financial accounts that rely on that number for two-factor authentication. If you would like to keep in touch with someone, consider using encrypted messaging apps or a “sock puppet” social media account.

Do not share any pictures of a location on social media while you are still in that location. It’s better to post pictures after you have left the location, or sometime thereafter. This stops a bad actor from finding your physical location in real time. One should also be aware of what is in the background of the photograph, who is in it, and if they are okay with the picture being posted online.

Be conscious of what you disclose about yourself at crypto events. As we like to say at Casa, feel free to talk about bitcoin, but don’t talk about your bitcoin. Try not to self-identify as someone who owns a lot of bitcoin. The more data points you reveal, the more of a target you become. There are some subjects that are best left untouched, such as how much bitcoin you have, when you started buying, and the exchanges you use.

Be aware of those in attendance at afterparties, bars, and shared party locations. These patrons may not be attending the conference, but they are now extremely interested in your “bitcoin citadel retirement plan” they overheard you discussing. Limiting alcohol intake will also help to keep one’s senses sharp (but make sure to still have some fun).

Final thoughts

It’s an effort to get back into the traveling security mindset, but hopefully some of these tips are things you can incorporate into your personal security plan. While most attendees should feel safe and not be targeted, “An ounce of prevention is worth a pound of cure.” Have fun at the conference and beyond!

Need peace of mind for your bitcoin?

Casa makes self-custody easy for everyone. Our multi-key vaults protect your bitcoin from accidents, hackers, and more. Learn about our plans here.

Note An earlier version of this post first appeared on the Casa blog in 2022.

How To Avoid Bitcoin Scams: A Real-Life Account

Tue, 01 Mar 2022 08:00:00 +0000

“Hey! I wanted to know what you know about bitcoin mining? I have a friend that just got $13,000 from a $1,000 investment, and they are now trying to get me to do it.”

If you’ve worked in the bitcoin space as long as I have, you immediately dismiss this message as a scam, but the ugly truth is not everyone works in the bitcoin and security space.

This is a real and scary message I recently received from a friend. We will call her Katie. I immediately dismissed the message as my friend being hacked and a scammer using her account to target me via DM to steal my money.

After a quick text message verification to Katie, she confirmed that she did, in fact, send that message and was curious about bitcoin mining based on her own friend’s “investment recommendation.” We will call him Doug.

Bitcoin mining beyond your wildest dreams!

As someone who tried his hand at mining, I let Katie know the message she received from Doug sounded typical of other scam messages I’ve seen prior. Bitcoin mining profits do not work that way. Katie, however, was new to bitcoin, and she was ready to invest a large amount of money with Doug and Doug’s crypto “investment coach.”

The coach had an Instagram account with many followers, a URL listed for their investment website, and various pictures of their bank accounts, financial reports, luxury goods, and vacations. Doug’s profile was starting to resemble the luxurious lifestyle of the coach. Who wouldn’t want to live the same life?

If it sounds too good to be true, it probably is

I spent a lot of time persuading Katie that she was talking to a scammer who was either using Doug’s account or impersonating him. Often, scammers will create fake accounts to impersonate people you know to try to gain your confidence.

These “fake-friend” accounts will scrape all your friends’ real photos and repost them under the fake account. Other fake accounts will engage the photos with likes and comments to provide legitimacy. Another tactic scammers use is to hack (or purchase a hacked) social media account and use the account to run scams through DMs and posts to a victim’s friends and family.

In this case, Katie was adamant that Doug was real. They knew each other in real life, and Doug was only trying to share sound investment advice and access to the coach, or so she thought.

Be wary of investment-related messages, even from people you already know. This is a common scam tactic.

Ask yourself: If someone was making this much money, why are they spending time trying to get you to give away yours? Why are they not busy making more money with their foolproof method?

Red flags are moments of hesitation that determine our destination

Katie continued to message me about the investment program over time. I tried to convince her that the program was not real, but I had the feeling that she was going to eventually lose her money.

At one point, I relented. If Katie was still going to invest — let adults be adults — then I offered to join a group phone call with the coach to assist Katie through the onboarding process and initial investment. In reality, I figured if I could ask the scammer about their business and practices on a call, then maybe it would prove to Katie it was all an illusion.

I identified multiple red flags in the scammers’ communications:

🚩 The scammers’ investment website linked in their profile had no news, SEO, or backlinks to it. Most reputable bitcoin businesses have a long and varied history that can easily be researched.

Scammer insight: The website is fake and easily deployed and easy to take down. The site only exists to steal your money.

🚩 Katie asked the scammer how taxes work at the end of the year on the investment. The response she received was “there are no taxes and you’re only charged 20% on your commission,” which is false. Most people in bitcoin know the pain of having to report taxes at the end of the year due to taxable events from transaction activity.

Scammer insight: Scammers don’t want you to fixate on the details, or else you’ll realize it’s a scam. Delusions of grandeur keep us from thinking logically.

🚩 There was a tiered payment structure showing the more someone “invests” the more they make, but the numbers do not make sense, similar to Ponzi schemes.

🚩 Doug and the coach both had pictures on their social media of charts trending up, stacks of money, luxury items, vacations, mobile notifications, and screenshots of bank balances. These screenshots can easily be faked in a matter of seconds and are usually shared across multiple scams and platforms. Why would someone needlessly make themselves a target?

🚩 The coach stated the company was registered and protected by another entity. I performed an open-source search and could not find registrations for any of the company names, especially not relating to bitcoin.

🚩 Doug and the coach were both quick to remind Katie repeatedly they were not involved with any fraudulent activity, the process was “100% safe and guaranteed,” and there would be a 5-hour withdrawal period for all the money she was about to make.

Scammer insight: This reassurance keeps you, the target, moving forward and provides the scammer with enough time to get away if you start to express concerns.

When in doubt, shout!

I recalled Katie knew Doug in real life prior to the investment conversations. Katie could easily prove if Doug had accumulated this magic knowledge by simply text messaging or calling them, assuming Doug’s phone was not under compromise. After proposing this to Katie, a few minutes went by.

“I just texted Doug and he said he was hacked!” Katie told me. “His Instagram was taken over and he can’t change his password and get back in! It’s crazy what these scammers are capable of.”

Yes, it is scary

The above attack is not scary because of how it’s performed, how long it takes, or the amount of effort needed. It’s scary because it’s effective. It’s an effective, low-effort trick that is stealing millions of dollars each year. And because people fall for it, one can only wonder how many scams exist that we don’t hear anything about.

We need to educate ourselves about how scammers operate. They do not need to perform a long-con engagement for a big win. More simply, can they get 60 of their 2,500 followers to send them $1,000? If so, $60,000 for a few hours of work is worth more to the scammer than the heartache and misery you and your family will feel about losing your hard-earned money.

Secure your bitcoin now

Casa makes self-custody easy for everyone. Our multi-key vaults protect your bitcoin from accidents, hackers, and more. Learn about our plans here.

Note An earlier version of this post first appeared on the Casa blog in 2022.

Bitcoin Security 101: How To Create The Healthiest Environment For Your Devices

Sat, 24 Jul 2021 13:00:00 +0000

By now, we all should be familiar with the mantra of “not your keys, not your coins.” A lot of guides and information are available to bitcoin connoisseurs regarding how to secure your keys and seeds. However, I don’t see much information published about how bitcoin HODLers can secure their environments when using those keys.

The following are some practical and “paranoid-level” tips and steps I use to help secure healthy environments for my devices and hardware wallets.

Physical environment

When using key material in any form, one should take into consideration the room and layout they will be operating within. Public spaces are not recommended due to the multitude of peering eyes, cameras, and general lack of privacy and security. To start evaluating for potential physical security threats, it is better to use an access-controlled location of your choosing, such as a bedroom or personal office. When evaluating a physical space:

Location should be access-controlled, which prevents key operations from being interrupted.
The space should be relatively private and not in a public place like a crowded coffee shop.
Take note of all cameras and what they are facing. This goes for mobile phones, webcams, and smart watches. When in doubt, cover it up, or remove the device from the environment entirely.
Be aware of various Internet-of-Things (IoT) listening devices, such as the ones offered by Amazon and Google. They are always listening!
Power off all unnecessary electronic devices that may contain cameras or microphones.
Close the blinds, shut the door, and give yourself ample time to do things correctly and without interruption.

Using hardware wallets and performing key operations is NOT a team sport. These tasks should be performed alone and in a silent manner, unless a second witness is needed for attestation.

Camfecting, or the process of hacking into a webcam and activating it remotely, can be prevented by covering it or removing it from the environment entirely.

Compute environment

Hardware wallets, by design, are engineered to protect your key material without the fear of an infected computer or malware stealing your funds. Having said that, attackers can be extremely clever. One can still take additional steps to ensure they are using the latest security tools to promote a healthy compute (laptop/mobile phone/tablet) environment.

Use your own computer or tablet wherever and whenever possible.
Use the included operating system firewall and malware detection tools. If you do not trust these, a third party application would suffice.
Ensure a healthy system environment by staying up to date on operating system patches. These patches sometimes include critical security updates which can help keep your computer safe.
Use only approved vendor binaries and software releases from official vendor websites and official mobile application (iOS/Android) stores.

Those that wish to be extremely cautious may choose to use an air gapped computer to sign transactions offline and broadcast them through a separate online computer. This is only recommended if you know exactly what you are doing, as fully securing an air gap computer is an intensive and comprehensive task.

Hardware wallet(s)

The “keys to the kingdom” that control your bitcoin should reside in your hardware wallet. If you are not using a hardware wallet, sign up for a Casa account here. Before we touch any hardware, let’s ensure we are electrically grounded by either touching a door knob, large piece of metal, or a common ground. This ensures we don’t zap our devices with static charge when handling them.

Run hardware device firmware updates periodically to ensure the latest security updates have been applied. (At Casa, our team reviews every firmware update for the hardware wallets we support. If you’re a Casa member, be sure to consult our help center before updating your firmware.)
Perform a Casa Health Check in the Casa mobile app to ensure the health of each of your hardware devices.
Use only the supplier-provided USB cable. USB cables vary in voltage, stability, and there are even attacks that can be built into makeshift cables!
Always verify all prompts and addresses on the hardware wallet screen.
Use a Casa-branded Faraday bag (available through our membership plans).

Faraday bags help to block electromagnetic fields and wireless signals

By incorporating some of the tips above, you are taking the steps to ensure the safety of your keys and bitcoin, as well as the safety of you and your operating environment. Stay safe!

Secure your bitcoin now

Casa makes self-custody easy for everyone. Our multi-key vaults protect your bitcoin from accidents, hackers, and more. Learn about our plans here.

Note An earlier version of this post first appeared on the Casa blog in 2021.

#kksctf open 2019 Write Up

Sun, 29 Dec 2019 15:00:00 +0000

This write up is a culmination of articles from a Capture The Flag competition and are all being concatenated here.

Red XOXOXO

The Challenge

We receive a message that is captured, and since this challenge is listed as “crypto”, we need to decipher the cipher text of -;91~.,11=12~;-?<27–6;:r~+-;~=27;0~1~=100;=p~7y3~)?7709~81,~+,~,;.2’p~55-%?*j=5.?.:j)0#*

Our challenge information

The Solution

The above cipher text has a variety of characters in it. Due to this, we can greatly reduce the type of encryption being used. Our hint also gives us a pointer in the right direction with the XOXOXO (XOR) in the title.

Brute forcing the key space

When attempting a variety of ciphers, a XOR brute force attack is attempted.

Finding a possible key

Our brute force attack has found a possible key and provided us with positive confirmation in the form of clear text. Unfortunately, this is not the correct flag, as this tool and key combination do not give us correct output. Using another tool, we can brute force the key space and find the correct key.

Finding the flag for the win

The key of 5e is found and the string is decrypted, revealing to us the final flag.

Stego Warmup

The Challenge

We get some file. Can you find secret?

We are provided the above file of Shaq gracefully obfuscating himself behind a tree. No other clues or hints are provided.

The Solution

This was an extremely easy steganography challenge. The flag we are looking for is embedded inside the image data. We can extract the EXIF metadata from the image using exiftool, revealing the final flag.

Solved!

We can see in the above image that the flag was in the Author field in clear text. On to the next challenge!

Xmas Tree

The Challenge

Do you like to decorate the Christmas tree?

This challenge was listed as “Misc”, and no other hints were provided.

The Solution

This was an easy challenge, as the answer was literally staring participants in the face during the entire CTF. Navigating to the kksctf web page showed a variety of Christmas themes, including a neat ASCII Christmas tree.

ASCII Art!

The above tree ASCII art shows a few different pieces of text in different colors. If we look in the HTML source, we can see the **** tags which indicate a color change for certain pieces of text.

It looks sweet in HTML too!

Combining the 7 pieces of colored text results in the final flag of kks{n3w_y34r_m@dn3$$}. Happy New Year!

Postman

The Challenge

Hey, some haсkers steal my mail. Can you help return and deliver it?

The Postman challenge provides us with a remote website and port. Navigating to the site shows us only a single line of text asking us to help the user retrieve their email.

The Solution

Let’s help the user get their mail! Trying things like a mail. sub-domain unfortunately did not work. We will have to go back to basics. Checking the robots.txt file gives us an unlisted URL to check.

robots.txt

We find the /postbox URL and navigate to it, but immediately get shut down due to an incorrect HTTP call.

Denied

“Method Not Allowed” indicates that we made an incorrect type of request to the web server. By default, this call is a GET request. We can either change the request type using proxies or extensions in our browser, or we can use curl and send a POST request. While GET makes a call to retrieve information from a website, POST sends data (such as logging into a mailbox service!).

curl -X POST http://tasks[dot]open[dot]kksctf[dot]ru:8001/postbox (event server, no longer online)

The final flag

The request is processed and the final flag is returned to us. Our user is now happy that they have their mail, and we are happy that this challenge is solved.

Note An earlier version of this writeup first appeared on Medium in 2019.

OverTheWire Advent Bonanza 2019

Thu, 26 Dec 2019 11:00:00 +0000

This write up is a culmination of articles from a Capture The Flag competition and are all being concatenated here. You can see other challenge write ups on the main post here.

Easter Egg 1

Part of the fun of CTF challenges is searching for Easter Egg flags. These flags usually don’t require a ton of advanced skill, but are random fun things to find for points during an intense competition.

The only hint for Easter Egg 1 in the OverTheWire Advent Bonanza 2019 was:

TODO: make clean

Last year’s Easter Egg challenge revolved around the robots.txt **file. **Robots.txt does what it’s named for, and provides directions to web site crawlers and spiders (such as Google), as to what files it should and should not index. The challenge last year included the flag inside this file, just in case any end users or curious hackers looked at it’s contents. This year seemed a bit different though.

No dice. The clue TODO: make clean **refers to the C/C++ **make **command. Adding **clean to this command tells the compiler to clean up any old temporary files and artifacts used during the build process. Using that knowledge, we can look for various types of these files on the web server. Eventually, we hit on robots.txt~, which indicates a temporary version of the robots.txtfile.

Finding the secret URL in the temporary robots.txt~ file

We can see from above, that there is a secret file named /static/_m0r3_s3cret.txt on the web server. Navigating to that file gives us the final flag, and the easter egg has been found.

Sweet easter egg points!

Easter Egg 2

Easter Egg 2 gave no hints what-so-ever, except for that fact that it was hosted somewhere on the official OverTheWire Advent Bonanza 2019 website. This would be a search for a needle in haystack (or a flag on a website).

After a bunch of enumeration, a man in the middle web request proxy was used to intercept the web traffic between the web browser and the web server. By doing this, one can see every bit of information that is being sent when a user requests or sends information to a website.

A new an interesting web header was located using the MITM proxy.

Oooooh

The string above should be recognized as base64, but it seems like it’s reversed. Reversing the text and decoding the base64 string gives the following:

Not the final flag, but we can still work with this

Decoding the string does not reveal the final flag, but we do get text we can analyze and work with further. ROT13 is a substitution cipher that literally moves letters forward or backwards a set number of positions, in this case 13 characters. An example of this would be the letter N in a message being written as the letter A (N to A is 13 letters). Using some linux command line fu, we can pipe the text into the tr command and reveal the final flag.

ROT13 decrypt for the final flag

Easter Egg 3

Easter Egg 3 directed competitors to the OverTheWireCTF Twitter page located at https://x.com/OverTheWireCTF. One thing that jumped out was a post with a picture signifying a new day in the competition.

Do you see what I see?

The above image actually has a ton of information in it. On first glance, we can see a QR code in the middle of the Egg wearing the Santa hat. Scanning the QR code may yield different results depending on the end user and the application. Here’s why.

Everyone is used to a few types of barcode formats such as QR, PDF417 (on the back of US licenses), and UPC/EAN for products they purchase.

Most people are used to scanning a single type of code and getting the information they need. The above challenge is interesting in that the image pictured contains both a QR code, AND an Aztec formatted code (right in the middle of the picture). If we look back at the original image on Twitter, we can see that the font used in “DAY 10” appears to be Aztec in nature…oh well, let’s scan some codes!

Scan Results

Aztec: 414f54577b6234726330643373

QR Code: 137:64:137:154:171:146:63:175

The numbers in the Aztec code portion correspond to ASCII characters in Hex notation. An example of this would be 41 representing the letter “A”. Decoding this section gives us the first part of the final flag.

AOTW{b4rc0d3s

The numbers above in the QR code portion correspond to ASCII characters in Octal notation. For example, the number 137 represents the character “_”. Decoding this section gives us the second part of the final flag.

_4_lyf3}

Combining both parts yields us the completed and final flag.

AOTW{b4rc0d3s_4_lyf3}

Challenge Zero

Prior to the start of OverTheWire Advent Bonanza 2019, the creators released a “Challenge Zero” for teams to work on. The challenge was located at https://advent2019[dot]overthewire[dot]org/challenge-zero (archived dashboard — event server is no longer online; the exact challenge URL was never archived), which showed a web page with an animated GIF of fire burning with the following message:

Fox! Fox! Burning bright! In the forests of the night!

Hint: $ break *0x7c00

The above hint refers to the command line of gdb, a linux debugger. At this point though, we have nothing to break so we need to keep looking. In the spirit of Capture The Flag competitions, my team and I tried viewing the web page and GIF in different ways. Using the text based browser links leads us to our next clue.

The line “D0NT PU5H M3 C0Z 1M C1053 TO T3H 3DG3” is l33tspeak for a song lyric from The Message by GrandMaster Flash.

The next lyric in the song “I’m trying not to lose my HEAD” clues us in that we need to make a HEAD web request. We can use curl and the command line to easily do this.

Animated Texty Goodness

We can see in the above image that the flames are made up of random text characters to achieve the animation effect. The other hint we saw above was “If only the flames wouldn’t move so much” which alludes to the fact that the image is an animation made up of multiple frames. Since we are using curl on the command line, we can scroll back through our console buffer and see each frame of text making up the animation. I noticed that the string of text ended in “==”, which signifies base64 encoding. **By compiling all the text and removing padding characters (# in this case), we get a completed **base64 string.

Base64 decoding the string resulting in a new uuencoded file to play with

The output above is uuencoded and can be decoded using the xxd tool. Once decoded, we have a boot.bin file. To my surprise, the base64 string did not contain the flag itself, but rather a bootable virtual machine image.

Confirming the file type of boot.bin

Taking the binary boot file and loading it into a virtualization hypervisor resulted in the following:

Aha! We have a binary that is loaded and referencing last year’s CTF challenge using the RC4 stream cipher. It seems we need to break this binary as well. Thankfully, the linux command line debugging tool gdb can connect to remotely running binaries for remote debugging purposes. Our original hint of break *0x7c00 finally comes into play. We can now load up gdb, set the proper breakpoint, and start attacking the binary.

Using gdb allows us to dump the Intel formatted assembly code so we can get a better understand of what is going on.

A sampling of the dumped code

We can see from the code that we are performing some AES encryption functions of data in the registers. I also noticed that there was a condition to check if the input was 16 characters or not. If it wasn’t, a different jump and code routine was executed. When a password of 16 characters is used, a new jump is taken which performs some XOR operations on the code and various registers.

The program ultimately takes the users input and stores it into xmm3. The instruction at 0x7c62: movaps xmm0,XMMWORD PTR [rsi] moves the AES encryption key into xmm0.

Storing the user input into xmm3

The key is loaded into xmm0

The data in xmm3 then gets XOR’d against a static address which contains hard coded cipher text to see if it matches. If it does, we get the flag. If it does not, the program cleans up the registers and prompts the user again for a password. When we check the debug output we can find the hard coded location and it’s data.

The location of the hard coded cipher text

The cipher text contents in little endian format

Taking both the cipher text and key allows us to perform an AES decryption which reveals the password we need — MiLiT4RyGr4d3MbR.

Running the script and decrypting the password

At this point we can input the password into the virtual machine, pass the check, and receive the final flag. We went from an animated gif, to base64 text, to a uuencoded boot image, to a binary that needed to be remotely debugged. What a challenge!

7110

Santa is stranded on the Christmas Islands and is desperately trying to reach his trusty companion via cellphone. We’ve bugged the device with a primitive keylogger and have been able to decode some of the SMS, but couldn’t make much sense of the last one. Can you give us a hand?

The Data

The challenge included an archive consisting of 4 comma delimited files, and 3 text files so that competitors could compare the data to the expected result. It was up to us to figure out message #4. Since I’ve been around awhile, I immediately recognized the name and nature of this type of challenge.

The Background

In the pre-smartphone days, Nokia ruled the land of cell phones. They had limited features, could play Snake, and were built like tanks. Before we were all able to touch our screens to make things happen, we needed to use physical hardware buttons. Insane, right?!

Those same hardware buttons were used for sending SMS text messages between phones. Since you were only limited to the buttons on the keypad, each button needed to provide multiple functions.

In order to type the letter A, a user would hit the number 2 button one time. If you wanted to type a B, you’d hit the number 2 button two times. If you wanted a C, you’d hit it three times. This input style was referred to as **Multi-tap **— https://en.wikipedia.org/wiki/Multi-tap.

Now imagine having to type a long story or grocery list to someone using that input style. Thankfully those days of painful texting are over, but this challenge reached out to the old school phreaker inside me.

Nokia 7110

In regards to the challenge name, the Nokia 7110 was a special edition phone with a sliding cover in honor of the movie “The Matrix”. The model number itself doesn’t have much to do with the challenge itself, but does point us to the text character set we should be using for the challenge.

The Solution

The 4th message file contained data in the same format as the other files. When looking at the format, it shows a timestamp in the first column, with the digit pressed on the phone in the second. Numbers in the second column appearing in sequence indicate that specific button being pressed multiple times (in order for the letters for that number to cycle).

A sample of csv4 data — the first column is a timestamp/uid and the second is the number pressed

You may notice the numbers 100 through 103 and 11 in the above data. These represent the hash, MENU_LEFT, MENU_RIGHT, and other navigation buttons. At this point, the numbered key presses can be extracted and decoded for the flag. Due to the nature and knowledge of multi-tap, this can be achieved manually by hand, or using an automated script such as a python custom dictionary.

The extracted key presses:

100 100 100 100 11 11 2 5 5 5 7 7 7 4 4 4 4 4 4 8 0 7 2 5 5 5 0 4 4 3 3 7 7 7 7 7 7 7 102 3 3 103 0 9 9 9 3 3 0 3 3 3 5 5 5 2 4 0 4 6 6 6 6 6 6 6 6 6 6 3 0 5 5 5 8 8 2 2 2 5 0 3 3 6 6 8 3 3 7 7 7 102 102 102 102 102 102 102 103 101 5 5 103 103 103 103 103 103 4 4 4 6 6 4 0 4 4 4 8 0 9 4 4 4 8 4 4 0 8 4 4 6 6 6 7 7 7 7 3 3 0 4 4 6 6 6 6 6 6 8 8 8 3 3 7 7 7 7 0 5 5 5 6 6 6 5 5 5 0 4 4 4 8 7 7 7 7 0 2 6 6 6 8 9 10 10 10 10 10 10 10 10 10 10 10 10 5 5 5 3 3 3 3 8 7 7 7 7 10 10 10 10 3 7 7 7 1 1 1 1 1 1 1 6 6 5 5 10 10 10 10 10 10 10 10 10 10 10 10 10 10 10 10 10 7 7 7 7 0 0 6 3 3 3 3 10 10 10 10 3 3 4 4 6 6 6 6 6 6 6 6 6 4 101 101 0 0 4 10 10 10 10 9 9 9 0 0 8 8 10 10 10 10 2 2 2 7 7 7 4 4 4 4 9 9 9 9 9 9 9 10 10 10 10 3 3 3 3 3 3 3 3 3 7 7 7 10 10 10 10 10 10 10 10 10 10 10 10 10 100 100 0 0 6 1 1 0 1 5 5 5 0 1 1 7 100

The Multi-tap decoded output and final flag:

MENU_LEFT MENU_LEFT MENU_LEFT MENU_LEFT HASH HASH [a][l][r][i][g][h][t][ ][p][a][l][ ][h][e][r][s] MENU_UP [e] MENU_DOWN [ ][y][e][ ][f][l][a][g][ ][g][o][o][d][ ][l][u][c][j][ ][e][n][t][e][r] MENU_UP MENU_UP MENU_UP MENU_UP MENU_UP MENU_UP MENU_UP MENU_DOWN MENU_RIGHT [k] MENU_DOWN MENU_DOWN MENU_DOWN MENU_DOWN MENU_DOWN MENU_DOWN [i][n][g][ ][i][t][ ][w][i][t][h][ ][t][h][o][s][e][ ][h][o][o][v][e][s][ ][l][o][l][ ][i][t][s][ ][a][o][t][w][{][l][3][t][s][][d][r][1][n][k][][s][0][m][3][][e][g][g][n][o][g] MENU_RIGHT MENU_RIGHT [0][g][][y][0][u][][c][r][4][z][y][][d][3][3][r][}] MENU_LEFT MENU_LEFT [0][m][.][.][ ][.][l][ ][,][p] MENU_LEFT

Mooo

‘Moo may represent an idea, but only the cow knows.’ — Mason Cooley

Mooo was one of the more fun challenges and provided us with a web service running on a specific port and IP address. Navigating to the site brings us to an implementation of cowsay. Cowsay takes input from a user and displays it in an ASCII art formatted cow.

The cowsay program (banner at bottom is cut off)

We know the name of the program due to the banner at the very bottom of the page (not shown here) listing the program version as Powered by cowsay 3.03+dfsg2–4. As a hacker, if we can get access to the source code then we can start looking at places to poke and prod. Cowsay happens to have it’s source code listed at https://github.com/schacon/cowsay/blob/master/cowsay.

Part of the cowsay source code

The Solution

After reviewing the Github and source code, we know that cowsay is written in the Perl programming language. Unfortunately, the only input field we’ve seen so far places text in the cow’s speech bubble. Attacking this did not seem to yield any results, as it seems the input field is being sanitized. We need to look elsewhere for an attack vector. Fortunately, a “custom” cow template exists that gives us more input fields to play with.

The custom cow template

We now know that the program is written in Perl, and we have more input fields to play with. No attacks were found after trying some web application and string escapes in the Message, Eyes, and Tongue field, but something interesting was found when testing things against the Cow text field.

Perl is not one of my strongest or favorite programming languages. Someone on my team decided to RTFM and found a gem inside the Perl documentation located at https://perldoc.perl.org/perlop.html.

The key to the kingdom, and a great Perl escape

They noticed that some Perl scripts contained EOF (End of File), while this one had EOC (I’m assuming End of Command, but it’s actually End of Cow), indicating that the code was to exit after finishing it’s code processing. This EOC command was also present in the custom cow template. We tried to pass EOC, which seemed to work without reporting any errors. After that, we tried chaining commands with the linux id command to see if we had escaped Perl and reached a shell.

Cowsay failed, but have we?

The server didn’t like our id command, so it didn’t seem we were at a shell yet. We did get an error message when adding the id command, whereas we did not when previously trying just EOC, so it seems we’ve escaped Perl, but now we’re….somewhere else entirely.

No, not there.

Knowing that web applications can only be hosted by a variety of services, we try a variety of commands in different syntax. When attempting a python module import, we no longer receive any errors.

No errors!

Did we escape from Perl and land in Python? I think we did! Let’s see if we can get python to execute shell commands for us using the os.system call.

The final flag

The python call executes and we get the final flag. Mooo!

Tiny Runes

One of Santa’s Little Helpers received an unusual Christmas wish, a copy of the yet to be released Deus Hex game. All they managed to find were fragments from the dialogue system. Can you decode the last one?

The Data

The “tiny runes” challenge was a reverse engineering and forensics challenge that included an archive containing 4 binary files containing speech text data for a game engine. Files 1 through 3 included a .txt file showing the game text, so that competitors would have examples to reference. The goal was to take the binary data for the fourth file, and come up with the corresponding text (hopefully containing the flag).

An example of provided game engine text

Contents of the binary file

While we didn’t see anything in the binary files using things like strings, the real magic was looking at the hex data (per the game name in the clue) of the file in order to see what bytes were being read.

A hex dump of the example binary file #1

All 4 provided binary files had mostly the same bytes and format, up until the section starting at 0x329. Since the data was different between all 4 files, it was determined that this was where the speech text data was being stored.

Each file had the values 00 00 00 XX **in **0x329 to 0x3BF, with the last byte seeming to indicate the size of the text about to follow.

We know from the 1st binary file and text that the line starts off with “JC Denton”, but the next bytes we are looking at currently show 05 01. How does this map to the letter “J”?

Binwalking for more

Running the binwalk or foremost forensic tools on the binary files not only shows text data, but we see a PNG image file that we can carve out and extract. The image file itself appears to be a character legend, showing a different arrangement of game text characters.

The extracted PNG file.

The Solution

Remember we were trying to figure out how to get the next bytes in the binary file, 05 and 01, to represent the character “J”? From the above legend, if we count starting from 0 from the top down, left to right — “J” is 01 row down, and 05 characters over. Remember to start counting from 0. “C” would be 03 across, and 0A rows down. It seems the text is being encoded in the file using a grid pattern with coordinates to which character is which.

Using this, we can reverse engineer the 3 provided binary and text files to generate our own character mapping so that we can process the 4th binary file, and get the final text.

Checking the bytes for the 4th binary

The bytes from 0x399 to 0x3D8 contain our flag string.

07 04 04 05 04 0A 04 09 01 09 00 06 00 09 05 03 00 0A 02 02 05 03 02 02 07 03 02 00 00 0A 00 0A 01 05 00 05 02 02 06 02 01 04 03 08 01 05 02 02 06 02 02 00 07 03 04 02 05 03 00 0A 07 09 06 07

Using the legend above, we can start working through the byte pairs/coordinates by hand, or use an automated script. 07 across and 04 down would be the character “A”. 04 across and 05 down would be the character “O”, and so on and so on until we get the final flag — AOTW{wh4t_4_r0tt3n_fi13_f0rm4t}.

Santa’s Signature

Can you forge Santa’s signature?

The Data

We are provided a remote service to connect to, as well as some source code on how that service is running.

The remote service

The remote service (and reading the source code) shows us a generated textbook RSA public key, and a request for us to provide 3 signed messages and digital signatures in hex encoding. Generally during CTF competitions, RSA challenges come down to factoring an unknown private key in order to decode a message. This is due to the fact that textbook RSA does not contain any padding, and can be defeated using cryptography and algebra.

Textbook RSA

In order to crack the private key, we need a modulus (n) and exponent (e) that conform to certain properties (small modulus, small exponent, similar modulus/exponent)so that it’s easier to defeat the cryptography and math.

When checking these values, it seems we cannot crack the private key itself in this challenge due to such a large modulus (n) value.

n = 0xbb58dbdfd1999…[lots of characters]…d64f501c6640b95c57f e = 65537

Based off the source code for the remote service, we need to pass 3 messages and provide 3 valid digital signatures per the key.verify(m,s) *check.*

Since we can provide the message and digital signature, there is an easy way to trick this automated verification system into accepting forged signatures. If we use the values of 0 for the message and signature, or the values of 1 for both — the RSA signature formula (s^e mod n) should still calculate out and pass all the requested checks.

Passing check 1 and 2, but not check 3.

We were able to pass message 1 and message 2 by using the values 0 **and **1, but we can’t provide either of those again for the 3rd message. Bummer.

But wait…we know the modulus (n), the exponent (e), and we can control the digital signature (s). Using this, we can figure out an appropriate message (m) that should pass verification from a set digital signature.

Since this is an automated system, our message does not need to be human readable — it only needs to pass the signature verification check. Running the script above outputs a hex string that we can input as the message, and a digital signature of 0xf.

This passes the third check, and we can see the final flag.

Sudo Suduko

The Challenge

Santa’s little helpers are notoriously good at solving Sudoku puzzles. Because regular Sudoku puzzles are too trivial, they have invented a variant.

The Sudoko puzzle to solve

In addition to the standard Sudoku puzzle above, the following equations must also hold:

B9 + B8 + C1 + H4 + H4 = 23 A5 + D7 + I5 + G8 + B3 + A5 = 19 I2 + I3 + F2 + E9 = 15 I7 + H8 + C2 + D9 = 26 I6 + A5 + I3 + B8 + C3 = 20 I7 + D9 + B6 + A8 + A3 + C4 = 27 C7 + H9 + I7 + B2 + H8 + G3 = 31 D3 + I8 + A4 + I6 = 27 F5 + B8 + F8 + I7 + F1 = 33 A2 + A8 + D7 + E4 = 21 C1 + I4 + C2 + I1 + A4 = 20 F8 + C1 + F6 + D3 + B6 = 25

If you then read the numbers clockwise starting from A1 to A9, to I9, to I1 and back to A1, you end up with a number with 32 digits. Enclose that in AOTW{…} to get the flag.

The Solution

This is a tough challenge consisting of math and programming in order to find the flag. One must solve a Sudoku puzzle by finding 32 digits, but the puzzle must also meet a list of very specific conditions. Due to this, only an extremely small subset of Sudoku solutions (in this case, one) will meet the conditions and unlock the final flag.

Enter go programming guru and CTF team member solipsis.

In order to solve a challenge such as this, one must do some paper math and preparation work in order to prune and reduce the search space early on. Since we have a fixed number of already filled out numbers, ranges for the missing inputs could be figured out — which helps reduce the complexity and brute force space search by a few orders of magnitude.

Programming this script to “fail early” as soon as it finds any value that exceeds those in the list of conditions, rather than checking conditions once it has an entire puzzle solution, also helps to speed things up quite a bit.

These techniques, combined with a descending 9 ->1 number order, help to trigger the failure conditions faster, and reduces magnitudes even further.

After running the script for some time, a final Sudoku solution that meets the list of requirements is found.

Success!

Per the challenge description, the 32 found numbers are compiled into a single string for a final flag of AOTW{86472953189247356794813521457639}.

Note An earlier version of this writeup first appeared on Medium in 2019.

Ron Stoner

How I Won a Championship That Doesn't Exist

The Experiment

The Approach

Trust Laundering

The Test

Why This Is A Bigger Deal Than It Looks

Mitigations

Conclusion

Follow Up

The History of Stoner.com

From Pipeline Simulators to Self-Sovereignty

1993–1997: The Pipeline Era

Late 1997–1999: Severn Trent Takes Over

2000–2003: Rebrands on Rebrands

2005–2010: The Quiet Years

2011–2013: GL Noble Denton

2014–2017: DNV GL and the Merger Void

2018–2022: The Hunt

November 2022–Present: Resurrection

Today and Onward

Timeline

30+ Years of a Domain

References

I Gained 1 Million Followers in 24 Hours

The Experiment

Nostr

Sybil Attack

The Approach

Observations

Charts and Stats

Challenges and Fixes

Conclusion

Nostr Security and Privacy Tips

Findings

Private Keys

Encrypted DM Metadata

Cross Site Scripting (XSS)

IP Address

Impersonation

Images and Media

Pixel Tracking

EXIF Data

Defenses

Private Key Management

Use Tested Clients and Front Ends

VPN and TOR

Use Trusted Known Relays

Verify NIP-05

Scrub Image EXIF Data

Don’t Click Unknown Links

Corporate Security Archetypes

Archetypes

Avoidant

Laggard

Doubter

Adopter

Champion

Summary

Bitcoin Security Tips To Help You While Traveling

The Dos and Don’ts of Bitcoin Key Management

Final thoughts

Need peace of mind for your bitcoin?

How To Avoid Bitcoin Scams: A Real-Life Account

Bitcoin mining beyond your wildest dreams!

If it sounds too good to be true, it probably is

Red flags are moments of hesitation that determine our destination

When in doubt, shout!

Yes, it is scary

Secure your bitcoin now

Bitcoin Security 101: How To Create The Healthiest Environment For Your Devices

Physical environment

Compute environment

Hardware wallet(s)

Secure your bitcoin now

#kksctf open 2019 Write Up

Red XOXOXO

The Challenge

The Solution

Stego Warmup