rydonahue

Preface This article was inspired by recent investigative reporting of  Brian Krebs , whose December 2025 analysis, Most Parked Domains Now Serving Malicious Content , synthesizes empirical research demonstrating a decisive shift in how parked and typo-derived domains are used in practice. That work, drawing on large-scale measurements by Infoblox researchers, establishes that domain parking is historically a low-risk monetization practice which has become a dominant vector for malware delivery, scams, and traffic laundering. This article extends that finding by placing it within a broader technical, economic, and defensive framework, with the goal of informing both operational security teams and policy-oriented stakeholders. Abstract Typographical squatting (typosquatting) is a long-standing abuse of the Domain Name System (DNS) in which adversaries register domains that are visually or syntactically similar to legitimate ones in order to exploit human error. While traditionall...

As a technical leader, one of the most consequential mistakes we can make is equating engineering value with the volume of code produced. That equation was already flawed before the rise of AI-assisted development and today is actively misleading. Code is becoming cheaper to generate, easier to scaffold, and faster to refactor. Understanding why systems fail , however, remains scarce. In this environment, the engineer who can reliably diagnose, localize, and explain failures is often more valuable than the engineer who can rapidly produce new features. When mentoring young engineers, I encourage them to see themselves as debuggers first and authors second. Writing software is an act of construction while debugging is an act of understanding. Okay, maybe that's harsh but if we assume most creation hides in a veil of generated slop you may see my point more clearly. Construction can be accelerated with templates, frameworks, and generative tools. Understanding cannot. It requires me...

Incident write-ups and postmortems are not administrative paperwork. At their best, they are teaching moments creating historical narratives future engineers will rely on when systems fail (they will). They promote accountability without blame, growth without defensiveness, and shared understanding without finger-pointing. A well-written postmortem signals that the goal is not to protect reputations but to improve reasoning.  Too often, incident reports devolve into short timelines followed by a list of fixes. This structure satisfies process requirements but leaves little intellectual residue. It documents what changed, but not what was learned. The real value of a postmortem lies not in the remediation section but in the narrative of discovery: how uncertainty was reduced, which signals mattered, which assumptions failed, and how the team converged on an explanation of reality.  When done correctly, it becomes one of the most effective tools for developing engineering judgm...

  The Problem with Blind Bastion Hosts Run SSH bastion hosts long enough and you'll start asking uncomfortable questions. Who's connected right now? What certificate are they using? Did someone just attempt a brute force from that sketchy IP range? How many sessions does that contractor have open? Traditional SSH logging wasn't built to answer these questions. You get disconnected log events scattered across auth.log. You grep through files trying to correlate usernames with source IPs. You have no real-time view of what's actually happening on your infrastructure right now. Sure, you can piece together a timeline after an incident, but that's cold comfort when you're trying to detect an ongoing attack. SSHadow changes this by giving you a live feed of SSH connections with full authentication context. This is not a replacement for traditional logging. This is a real-time intelligence layer that makes sense of what's happening as it happens. What SSHadow Does...

The first week is usually quiet. A new engineer joins the team, their laptop freshly provisioned, their calendar suspiciously empty. They clone the repositories, follow the setup guide, and eventually reach out with a familiar message:  “I think I’m missing something. The service won’t start.”   Someone responds with a workaround. Another suggests a different environment variable. A third offers to hop on a call and “just get them unblocked.” By the end of the week the engineer is running the system but nothing about that success is repeatable, documented, or intentional. The team moves on, unaware they have just taught their newest member that survival depends on tribal knowledge. Furthermore there is lost cadence and opportunity amongst the wider team during the distracting episode of onboarding. That moment is where onboarding either becomes an investment or a slow, compounding failure. Onboarding a new software engineer into a mature team is not a clerical exercise. It is ...

Preface This document is a manifesto, not a tutorial. It is written for practitioners who live inside systems rather than around them. It is for those who build, test, trace, break, and repair complex machinery at scale. It is not concerned with tools, techniques, or exploits, but with the way of seeing that precedes all of them. The worldview here is neither criminal nor romantic albeit a bit poetic and whimsical in my own way. It is operational. It emerges naturally in those who understand that modern systems fail not because they are attacked, but because they are misunderstood. What follows is a statement of posture, responsibility, and discipline for those who recognize that sight itself is the rarest capability on the Grid. Cybermancers are not defined by exploits, hardware, or street legend. Those tangentials  are the residue and not the essence. A cybermancer is defined by how they see the Grid  not as fortresses, maps, gates, and walls, but as a breathing lattice of...