The mind can be strong or weak, organized or chaotic. Every day, it challenges us to think differently, take different actions, and analyze situations, people, and events. It moves us through segments of memory and urges us to predict the future.

Thoughts in my head rarely sit still — they dart like sparrows, hopscotch from one idea to the next, and sketch half-formed maps across a dozen mental whiteboards. One moment I’m tracing a DNS chain, the next I’m replaying an old VAX routine or imagining how a tired admin chose convenience over security; my mind constantly stitches technical breadcrumbs into human stories.

As an ethical hacker, I live in those jumps: pattern recognition at speed, relentless curiosity tempered by rules, and a habit of turning chaos into a checklist. This article is a walk-through that restless landscape — the flashes of insight, the doubts, the late-night grind, and the ethics that tether everything — so you can see not just the tools I use, but the way I think.

When I step into a new engagement, I don’t only see servers and IP addresses; I see people, processes, and the business that depends on them. Ethical hacking is not about showing off tools; it’s about understanding what matters to a client and exposing threats before someone with malicious intent does. Over the years, I’ve built a mental checklist and a working methodology that turns chaos into a map — and this is how my mind navigates a project.

The first step is to understand clients’ needs and pain points. Why are we doing, e.g., pen testing? Is there a legal obligation, like NIS2 or GDPR, or was there a misconfiguration? Have they already been hacked? If I don’t understand the needs, the results will most likely not match the client’s expectations. The challenge is to connect technical information with the business environment, so it is important to understand the full project landscape and each detail relevant to it.

My background helps here, after all, I’m a proud “Commodore 64 kid.” I grew up learning BASIC on the C64 and later dove into its 6510 processor and assembler commands. Some of you might even remember setting interrupt vectors at addresses $0314 and $0315. As I got older, I moved on to the Motorola 68000 and 68020 processors, and eventually, in the early ’90s, the first 80486 appeared on my desk.

The point is this: I’ve always believed that understanding the low-level details matters, down to why I’m XOR-ing or ROL-ing bits in a register. Maybe I’m going too deep here, but that’s simply how my mind works.

Delving back into the topic, the next thing is to create the client’s landscape; in a way, it is the battlefield that we will be on. How they authenticate, what is being exposed to the internet, what kind of servers do they have and why, there could be databases, different Windows or Linux machines, file servers. I ask many questions, even the simplest and stupid ones, to paint a full picture of what is inside. I learned to never be afraid of asking a question; most of my mistakes, not only in hacking, happened while I presumed something. I usually carry a pencil into meetings, just a good old graffiti pencil that I use to sketch and draw, write questions and answers with. I consider it to be one of the best tools in my hacking arsenal, next to Metasploit, Burp Suite, and others.

Agreeing about the expectations is next. We, technical people, often face significant challenges in communicating. Even if something looks simple and clear to us, that doesn’t mean it is the same for our interlocutor; the goal is to be fully aligned. Having this in mind, we must communicate expectations and outcomes in a simple and clear way, and be fully aligned on the goals and outcomes of a project. I always send a follow-up email to clearly define the project scope in writing.

When the project starts, I usually choose a methodology for execution. It helps me stay on a proven path, but in many cases, I will go off it as well, depending on the circumstances. Validating the client’s information is necessary, using different tools to inspect the environment and gather technical details, e.g., network range, live devices, OSes, services, open  ports (never forget UDPs!), domain(s), etc.

It becomes so simple once you learn how to read it, like LEGO parts being put together, but at times, there is a blackout on my side where I can’t put it all together. There are cases when the pattern just won’t emerge — the outputs pile up and my brain loops on the same possibilities. I call that the spinning effect. It is important to recognize times when my brain is overloaded, and it a huge effort to connect the dots, but with no success. For sure, we all experienced this “spinning effect” when we lose it, and we get back on a thought, running the same cycle and expecting a different result.

To break away from this loop, breaks are good and necessary for my mind to stop and approach a problem from a different perspective or starting point. The best remedy is deliberate detachment: I step away, sometimes I sleep on it, or I do something completely unrelated, like a short walk, a piece of nut cake, and a glass of milk to reset the cognitive load.

Often, the problem cracks open from a different perspective upon return. Over time, I realized it is perfectly normal to have these blackouts and not consider them to be some kind of enemy in my head, but rather a pointer that something is missing, a piece of information, or so.

Back to ethical hacking, after understanding the full landscape, usually I have “suspects,” which refers to devices and services that I believe could be potential targets. Also, as humans, we tend to take the shortest paths, seeking the best return on investment. In this case, my return on investment is finding vulnerabilities and validating exploits.

Just for those not familiar with the differences, vulnerability is a weakness within a system, while an exploit is the code or action a hacker uses to take advantage of a vulnerability. I was probably most successful in the past with similar “suspects,” which is why I treat them the way I do; however, this is not a good strategy.

Each IT system is different; it may be running on the same hardware and the same or similar software, but the environment around it is very different, so each new project shall be treated as a black box, no matter what. A black box is a system we have no clue about, the one we must investigate.

Hacking isn’t brute force; it is more lateral thinking, meaning creating your own path, step by step, avoiding pitfalls, like in old text-based adventure games on C64 or ZX Spectrum 48K. When (here a word “when” was used deliberately and not “if”) a wrong path is selected, the way back can be long and could have a serious impact on the project timeline.

A case comes to my mind when I was trying to run an exploit that just didn’t fit, and I was running a web server required to use the exploit. For sure many of us know what I am talking about: “python3 -m http.server 8080”, right? I was setting up LHOST, RHOST, checking if the port was open and if traffic reached my server, opening new Terminal windows, and all the other necessities, just to understand after two hours that the exploit was not useful.

Here, the word “curiosity” comes to my mind, and I see it as being important for hacking. Curiosity gives us a competitive edge, and at the same time, it can be a two-edged sword. Ethical hackers are in love with “what if?” type of questions.

Anyway, the same curiosity is opening my mind to thinking outside the box, trying to put some unusual characters into SQL statements, or forcing a web server to retrieve data from my sources instead of serving data from its own. Sometimes it can be easy, like when your website has a profile section, and you allow me to upload my profile image, expecting it to be in a specific picture format, but there is no code to verify that the file is actually a picture format, or if there is malicious code embedded.

I often tell myself I’ll stop after one more test, and those “one mores” usually stretch into long nights of dead ends — scans that return nothing, payloads that fail, and headers that refuse to make sense. Fatigue builds, fingers blur, and the silence of the room seems louder with every failed attempt, but I keep chipping away, methodically and stubbornly. In ethical hacking, long nights become the norm; this is one of the sole truths presented in hacking movies.

But behind the screens, there’s also silence. Ethical hacking is often a solitary pursuit — headphones on, lights dimmed, thoughts circling between logic and instinct. Limitations that I can’t share most of what I find, not even the victories, because confidentiality is the cornerstone of trust. There’s pride in that secrecy, but also a certain loneliness that comes with it. I celebrate breakthroughs quietly, knowing my best work will likely never be seen by anyone outside the project.

Then, often when exhaustion is highest and hope feels thin, a single line of output or an overlooked response cracks the case wide open: the big finding that makes all those sleepless hours suddenly worth it. Finally, there’s a moment I know too well — that quiet, electric rush when a vulnerability finally reveals itself. It’s like watching a hidden door appear in a wall I’ve been staring at for hours or even days. My pulse quickens, my thoughts race, and for a brief second, I can see the entire network unfolding in front of me.

It is pure adrenaline wrapped in logic. Then comes the doubt. Did I miss something? Is this really exploitable, or am I just seeing patterns that aren’t there? The excitement of discovery quickly turns into a need for validation. I double-check commands, repeat scans, and replay packets, repeatedly, until the data confirms what my instinct already knew. The “AHA!” moment. The log line that suddenly makes sense. The tiny clue that ties the puzzle together.

Still, that’s what makes it meaningful. The emotional cycle; the rush, the doubt, the burnout, the solitude, it is all part of building something bigger than me. I don’t hack to destroy; I hack to understand. To see how fragile systems are, and to make them stronger before someone else finds the same door, for the wrong reasons.

Maybe mentioning the obvious, but a penetration test without aligned expectations is a wasted exercise. Technical reports that overwhelm executives do more harm than good. I always translate findings into business impact: what asset is at risk, how easy the attack path is, and what the likely business outcome is.

Then I provide prioritized remediation — quick wins first, strategic fixes next. The true challenge isn’t finding a vulnerability, it’s explaining to a CEO or to a person responsible why it matters. Over time, I have learned that finding the right person to talk to is extremely hard and important in cybersecurity.

Today’s landscape has become so complex and demanding that it is nearly impossible to have expertise in different technical segments that support daily businesses. In many cases, system administrators do not understand deep cybersecurity-related challenges, keeping systems unpatched and unprotected; on the other hand, there are zero-day exploits that none of us can defend against. Also, we have networking gurus unfamiliar with buffer overflow or a simple SQL injection. The good side is that they know about evil twin, or they have heard of Wireshark but never used it.

Every exploit I find reminds me how human our systems really are — built on trust, habits, and assumptions. Behind every misconfiguration or overlooked port, there’s a person who once made a choice, often under pressure, believing it was the right one at that moment. Technology may evolve, but the weaknesses I uncover almost always trace back to human nature; curiosity, convenience, or simple oversight.

Each vulnerability is a quiet story about how people work, communicate, and sometimes fail to. Ethical hacking isn’t about breaking things; it’s about understanding those fragile connections and making them stronger. I see my work less as destruction and more as translation, taking what machines reveal and turning it into lessons for humans.

In the end, every test is an act of care. I don’t just look for flaws; I look for ways to protect what people have built, often without realizing how exposed it really is. Because when systems fall, it’s not just code that breaks; it’s trust, reputation, and sometimes much more behind the screens. When the screens dim and the last log line falls silent, the work of an ethical hacker is quietly finished, not with fanfare, but with care.

What began as interest and technical curiosity ended as responsibility: a discovered weakness becomes a lesson, a midnight breakthrough becomes a safer morning for someone else. We chase puzzles so others can sleep more easily; that, more than any accolade, is the real measure of the mind behind the keys. That’s why I hack: not to exploit, but to understand, to teach, and to rebuild.