Updated August 17, 2026, shortly after publication: an earlier version of this post said no personal data was held at all. That was wrong. Our website stores nothing, but messages sent through our contact forms are recorded in a database, and that database sits within the account that was compromised. The section below has been corrected. We would rather flag the change than quietly amend it.

Between August 12 and August 17, 2026, anyone who visited rit-tech.org was sent somewhere else.

Instead of our site, visitors landed on a page impersonating a well-known internet security service — the kind of “verify you are human” screen you have clicked through a hundred times. It was not real. It was designed to look routine enough that you would follow its instructions.

We found it, removed it, and closed the way in.

We are writing this up in detail for a reason that goes beyond disclosure. RIT exists to make technology legible to people who were never handed the manual. We spend a lot of time explaining how systems work in the abstract. This week we got handed a real one, with real stakes, that we lived through start to finish. That is a better teacher than any hypothetical we could invent, and it would be strange to run an organization about technology literacy and then decline to teach the most instructive thing that happened to us all year.

So: what happened, then what it teaches.

What Actually Happened

Someone gained access to the account we use to manage our domain — the service that tells the internet where rit-tech.org lives. They did not break into our website. They did not need to.

Once inside that account, they added rules instructing the network to send every visitor to their page instead of ours. Then they came back and did it again, every day, for five days. The pattern was automated: log in, add a rule, leave. Each visit took under fifteen seconds.

The rules were given innocuous names — the sort of thing that reads like security tooling if you glance at a list rather than examine it.

What Was Not Affected

Our website itself stores nothing. It is static — no user accounts, no login system, no server-side code that could be compromised. Simply visiting the site creates no record of you anywhere.

Messages sent through our contact forms are stored, and we want to be precise about those. When you submit a form, your name, email address, and message are recorded in a database, so that a message is never lost if a notification fails. That database sits inside the same provider account the intruder had access to.

So we went and checked, rather than reasoning about it.

The database keeps its own record of every query run against it, independently of anything the intruder could see or edit. Across the entire five days of the intrusion, it logged zero queries — nothing read, nothing written, nothing at all. The first activity in that record is hours after their final visit, and it is our own software doing its normal work. The behaviour matches everything else we saw: an automated process that logged in six times, spent under fifteen seconds each visit changing the redirect setting, and never went anywhere near stored data.

We are not going to claim absolute proof, because access to an account is access to an account. But this is not us hoping. If you have written to us through this site, the evidence says your message was not read, and we would rather show you the reasoning than ask you to take our word for it.

Donations were not affected. We do not process payments ourselves. Donation links hand off to a dedicated payment processor, which was never involved.

Our source code and published site were never touched. We verified every published version against its history. Every change was ours.

Our domain registration was never at risk. Ownership, transfer locks, and the underlying records were intact throughout.

The compromise was confined to one account. What we can demonstrate it was used for is redirecting traffic. What we cannot completely rule out is access to stored contact messages. We would rather draw that line honestly than round it down to something more comfortable.

What You Should Do

If you visited rit-tech.org between August 12 and 17 and were sent somewhere else, please read this part.

The redirect was of a type that browsers deliberately remember. Your browser may keep sending you to the malicious page even now that our site is fixed. That is not the problem returning — it is your browser using its saved copy. Clearing your cached files resolves it: Settings, then Privacy, then “clear browsing data,” choosing cached files with the range set to all time. You do not need to clear passwords or sign out of anything.

If that page asked you to copy and paste anything — into a terminal, a Run box, or any system dialog — and you did it, treat that seriously. Run a full antivirus scan and change passwords for important accounts from a different device. If you are unsure whether what you saw qualifies, contact us and we will help you work it out. There is no embarrassment in asking. These pages are convincing by design.

What This Teaches

Here is the part we actually want you to keep.

Nobody broke into the building. Someone changed the street signs. This is the single most useful idea in the whole incident. Our website was never touched — it sat there the entire week, intact, serving the correct content to anyone who reached it. What changed was the directions. People asking “where is rit-tech.org?” got the wrong answer. Most of us picture a compromise as an intruder inside the vault, but a great many real attacks work like this instead: nothing valuable is taken, the signposts are simply moved. If you only ever inspect the building, you will not find it.

Boring architecture is a security feature. The reason this was an inconvenience rather than a catastrophe is that we had nothing worth taking. No database, no accounts, no stored personal information. That was a deliberate choice made long before this attack, and it did more to protect people than any security product could have. The most reliable way to safeguard sensitive data is to never collect it. Organizations routinely gather information because gathering is easy, then discover they have taken on a liability they cannot defend. Ask what happens to any piece of data you collect on the worst day, not the ordinary one.

The lock was not picked. A key was copied. There was no clever exploit here. Someone had valid credentials and simply logged in. That is how the overwhelming majority of real compromises happen — not through brilliance, through access. Which is why two-factor authentication matters so disproportionately: it is unglamorous, it takes ten minutes, and it defeats the actual thing that actually happens. We did not have it enabled on that account. We do now. If you read one sentence of this and act on it, make it that one.

The fake security check works by borrowing trust. The page visitors saw impersonated a routine verification screen precisely because you have been trained to click through those without thinking. That trained reflex is the vulnerability. Worth internalizing: a legitimate security check never asks you to copy text and run it on your own computer. None of them. Not ever. The moment any page asks you to paste something into a terminal or a Run box, you have left the space of real security checks entirely, no matter how official the logo looks.

Names are camouflage. The malicious rules were labeled to resemble protective tooling. Anyone scanning that list quickly would have read the names, thought “that looks like security,” and moved on. Attackers know you will skim. In any system you administer, the label is a claim, not evidence — check what a thing does, not what it is called.

Detection matters as much as prevention, and gets a fraction of the attention. This ran for five days. We found it because a visitor experience broke badly enough to investigate, not because anything told us. That is the real failure in this story, and it is the common one: enormous effort spent on keeping people out, almost none on noticing when someone gets in. Prevention eventually fails for everyone. What separates a bad afternoon from a bad quarter is how fast you find out.

Separately: Our Email Was Down

While investigating, we found an unrelated problem. A billing transition on our email provider lapsed before it completed, so messages sent to our addresses were rejected rather than delivered.

If you emailed one of our addresses directly between roughly August 1 and August 17 and never heard back, we did not receive it. That was not you being ignored. Please send it again. Email is working now, and we have tested it end to end.

Contact form submissions are a different story, and a better one: none were lost. Messages sent through the forms on this site are recorded the moment you submit them, separately from email. We have every one of them. What broke was the notification that tells us a new message has arrived — so submissions were sitting safely in a place nobody was watching closely enough. If you wrote to us through a form and never got a reply, we do have your message, and we will follow up. That one is on us.

There is a lesson in this one too, and it is less dramatic than the attack: infrastructure fails quietly. The redirect was loud and obvious the moment anyone looked. The email outage produced no error on our end at all — mail simply stopped arriving, and silence looks exactly like nobody writing to you. The failures that hurt small organizations most are rarely the visible ones.

What We Have Changed

The account has new credentials and two-factor authentication. Every access key and token has been rotated. All sessions were terminated and audited.

The more important change is automated monitoring. Our site is now checked on a schedule from outside our own infrastructure: does rit-tech.org still return our actual content, does it still resolve to where it should, and are the records governing our domain and email unchanged? If any of that stops being true, we are told immediately instead of finding out days later.

Worth being specific about a limitation, since it is instructive in itself. We looked for an alert that would fire the moment someone changes a setting in our provider account — the exact thing that happened here — and no such notification is available at our service tier. So we monitor the symptom rather than the cause: we cannot always be told when something is changed, but we can continuously verify that the result is still correct. That turns out to be the more robust choice anyway, because it catches any cause, including ones we have not thought of.

Why We Published This

We are a very small nonprofit. One person maintains this infrastructure. It would have been easy to fix this quietly, and most organizations our size would have.

But an organization built to teach technology does not get to only teach the parts where it looks competent. The week we got compromised, camouflaged rules sat in our own account for five days, and we did not have two-factor authentication turned on where it mattered most — that is worth considerably more to you than another explainer written from a position of safety. Real examples teach. Sanitized ones do not.

If you were affected, or you have questions about anything here, contact us. We will answer honestly.