Research
Technical findings from looking closely at systems.
I write about problems I encounter while examining applications, infrastructure, networks, and security controls.
The useful part of a finding is rarely the vulnerability name by itself. I want to explain the condition that made it possible, what the system allowed, how I established the behaviour, and what a reasonable fix looks like.
Some of the work comes from security assessments. Some comes from infrastructure troubleshooting. Others begin as questions about how a particular system behaves.
The Login Problem That Came Down to One Workstation Setting
An Active Directory login problem that initially appeared to affect the user turned out to be related to a workstation configuration.
Read the case study 02The Client-Side Validation That Cost KSh 50,000
A financial web application was relying on validation performed by the browser. Examining the request rather than the interface showed why that assumption was insufficient.
Read the case study 03Reducing the Attack Surface Without Rebuilding the Server
A Linux server hosting business applications was accessible from the internet with more network exposure than its intended services required. The work focused on understanding which services needed to be reachable, which did not, and how the exposure could be reduced without replacing the server.
Read the case study 04The App That Kept Its Secrets in Plain Sight
An Android application stored sensitive information in locations that made it accessible through inspection of the application and its local data.
Read the case study 05The Network Wasn't Down
A reported network failure was traced to a stale DNS A record. The investigation was a useful reminder that connectivity problems often require examining the name resolution path rather than assuming that the network itself is unavailable.
Read the case study LabTesting an idea before relying on it
I use controlled environments to reproduce configurations, failures, and security findings. The lab lets me change one part of a system, observe the result, and repeat the test without introducing the same uncertainty into a production environment.
Visit the lab