How a Spy Pixel Crashed Into My Friend's Vacation

 

         So it goes.

 

A friend of mine, a freelancer, recently went on a much-deserved vacation. Like most of us in today's always-on culture, she left an automated "I'm away" response on her email.

One day, she received a message from a client. Curious whether it might be urgent, she opened the email — but chose not to reply. A few hours later, she received another email from the same client:

"I know you opened our email. Can you please answer to our job offer?" 

Creepy material right there.

How in two hecks did the client know that she had opened their email and read their message, without her replying? The answer is tiny, technically invisible, and fascinating — a spy pixel!

 

                 There's totally a Spy Pixel there, trust me bro.

 

---

But what are they?

 

A spy pixel is a tiny, invisible image that gets embedded in emails. Usually just a 1x1 pixel, fully transparent, and basically impossible to spot by just looking at the email.

The moment your email app loads it — boom — it sends a signal back to whoever embedded it.

What's in that signal? Well, I'm glad you asked. It can include, at the very least:

- Your IP address (which can give away your rough location),

- The exact time when you opened the email,

- Your device type, OS, maybe even your browser,

- Whether you opened it multiple times or forwarded it to someone else.

 Here's her little spy:

<img src=3D"https://app.frontapp.com/api/1/noau= th/companies/5faa110782efdfc2d885/seen/msg_uugvds6/0/0a5b6123.gif" alt=3D"S= ent from Front" aria-hidden=3D"true" style=3D"width: 1px; height: 1px">

That image isn't there to show anything. It's there to quietly send metadata back to the pixel's creator.

---

Where and when are these buggers used?

 

You might be surprised — they're everywhere in digital communications. Here are some common uses:

• Email newsletters and marketing campaigns, to track open rates,

• Sales outreach tools, for engagement tracking,

• Transactional emails, just to confirm delivery.
  

But also in more questionable cases:

- Stalking or surveillance by controlling or manipulative individuals,

- Aggressive sales tactics, that cross boundaries (case in point: my friend),

- Phishing campaigns, to confirm which addresses are active.

And, for the most part — barring some exceptions — this stuff is completely legal.

---

Fear-mongering

 

I love some areas of cybersecurity, but I'm definitely not a fan of the constant fear-mongering I see everywhere.

This stuff is genuinely cool! And interesting. And did I say cool? But it has its downsides. Serious ones, especially when you are on the receiving end of it. Most people don't know these pixels exist, let alone how to block them.

 

                         I B Nautghy!

 

---

Action.

 

Are we allowed to lie to protect our privacy or avoid annoying people? I think we are. But that becomes hard when someone throws back:

• "We know you were at your computer yesterday."
•  "You say you didn't see our message, but we know you did."
• Or you try to browse anonymously, and the pixel exposes your location

This little guy can enable social engineering attacks by confirming your device type, when you were online, even whether you forwarded the email.

And, all that advice about "not clicking suspicious links"?

You didn't! You just opened the email. And that's all it takes

---

You gotta fight, for your right. (to party)

 

Thankfully, we've got defenses. Here are some of the basics:

• Block remote images in your email client (Thunderbird, ProtonMail, and others do this by default),

• Use privacy-focused email services that prevent images from auto-loading,

• Browser plugins like uBlock Origin can help if you're using webmail,

• Use a VPN to mask your IP and location,

• Or go hardcore and view emails in plain text only.

Just a heads-up: many mobile apps load images by default unless you manually turn that off. And in some cases, you can’t.

 

         Oops...

---

DIY Spy Pixel.

 

Want to try one for fun? Here’s a simple experiment:

1. Host a transparent 1x1 GIF or PNG on your own server.

2. Log image requests using your server (e.g., Apache, nginx, or a basic Flask script).

3. Add this to an HTML email:

<img src="https://yourdomain.com/tracker.gif" width="1" height="1" />

1. Send it to yourself.

2. Open it and check your logs — you'll probably see something like:

   • IP address

   • User-Agent string (your OS, browser, etc.)

   • Timestamp

Research how to do this stuff if it’s new to you. It’s a great little exercise and can be done in an afternoon.

---

Beyond the Pixel

 

Our tiny spy pal isn’t alone.

There’s a whole army of sneaky tools out there:

• Link shorteners with tracking redirects,

• Invisible iframes embedded in webmail,

• Email fingerprinting, using subtle code to track opens,

• Read receipts in platforms like Slack, Notion, and LinkedIn.

Once you notice this stuff, it’s everywhere.

---

A final dot.

Have fun exploring. Even if this isn't your favorite cybersec topic, it's a fun rabbit hole and might lead you to some unexpected discoveries.

 

And as always — enjoy the ride.

 

 

Securing Your Website (Part 2): Cloudflare Tunnels, WAF Traps, and More Hands-On Security

 

            So it goes...

 

 

After setting up my website with Cloudflare Tunnels to bypass ISP restrictions and adding some basic WAF rules, I kept hounding up Cloudflare's security features. It turns out there's a whole world out there, and there's much more you can do. So, be advised, this blogpost won't even touch upon 1% of what you can really pull given enough time and effort.

Let me be clear—I’m no expert. I’m just learning by doing, breaking stuff, re-making the configs, fixing what can be fixed, and documenting most things as I go along. You can too. This is not a deep technical dive, it’s a hands-on log of things I found fun and useful. YMMV.

📌 Step 1: Making Sure the Tunnel Survives Reboots

If you recall, in the last post, I set up a Cloudflare Tunnel to keep my server accessible and bypass my ISP blocking inbound traffic. But the tunnel was running manually. If the machine rebooted, the tunnel wouldn’t come back up unless I started it again.

That’s where systemd comes in.

With a systemd service, we can make sure the tunnel starts automatically when the machine boots, and even gets restarted if it crashes.

Here’s the basic idea:

• We create a service file that tells the system how to run cloudflared

• We point it to the tunnel config and credentials file

• We enable the service so it runs at startup

   

                Ain't much, but it's enough.

It’s fairly straightforward, really. If you haven’t used systemd before, it’s just a way for Linux to manage long-running background tasks. And a whole can of worms if you're, say, over 30 years old or so.

Now, every time my server restarts, the tunnel comes back automatically. No more downtime.

📌 Step 2: WAF Traps and Custom Blocks

I started testing different WAF rules to create little security tripwires—fake URLs and suspicious patterns that only bots or scanners would trigger.

✅ Honeypot Rule: I created a fake path (/admin-panel) that doesn’t actually exist on my site. Then I wrote a rule:

(http.request.uri.path eq "/admin-panel")

Action: Block

Any legit user would have little reason to visit that URL. If something does, it’s (likely) a scanner or a bot poking around for admin panels. This gets blocked, and the event is logged in Cloudflare for review. Nifty!

 ✅ Blocking curl POSTs to /submit. Because why not?

(http.request.method eq "POST" and http.request.uri.path eq "/submit")

Action: Block

This is another tripwire. I can still use GET on that path, but any POST—especially from a script—is blocked. I tested this with curl -X POST and saw the request get blocked. 

✅ Country WAF Rule vs. Tor: I also blocked a specific country and then tested the rule using Tor Browser. Guess what? Tor got through. This was a cool discovery because it shows how Tor exit nodes might evade country-based blocking unless you explicitly block Tor IPs using Cloudflare’s $tor variable (aaand, you totally can do just that). So, while regular Proxy sites were getting Captcha challenged (and failing), Tor got through squeeky clean.

 

                Nope. And Bot Protection will not let you verify. Go figure.

                   Yup.

📌 Step 3: Cloudflare Logs and Visibility

Cloudflare gives you a lot of visibility into what’s hitting your site:

• What paths are being accessed

• Whether the traffic was challenged, blocked, or allowed

• Which rule triggered

• What country, ASN, and IP the request came from

You can see all this under Security → Events. I reviewed the logs and noticed traffic from VPNs, proxies, and scrapers. I had seen this before, over one year ago, when my website actually existed. At that time, I hashed an impromptu firewall and logging system and was totally amazed at the amount of automatic attempts at entering my website, or specific pages of it.

As for Cloudflare, you have that and a lot other tools, like Cloudflare API or GraphQL queries to pull logs automatically, and which I totally need to get into as soon as I get the time.

📌 Step 4: You Don’t Have to Be an Expert

If there’s one thing I want you to take from this, is that we're all ignorant, or at least we start ignorant, and we just keep on learning and learning.

Back when I was an acting teacher, I was asked about being an actor, and how to become good. My answer then is the same I have for you today: "You fall in love with what you do. You do it every day, whenever you have the time, and little by little you become good."

📌 Step 5: Secure Remote Access with Tailscale (or WireGuard)

When you’re running your site from your own machine (or a Raspberry Pi), you probably want a way to connect to it remotely and securely.

As far as I know, you can do it with Cloudflare Enterprise (Zero Thrust), but I haven't explored that (yet). 

Another way is Tailscale, or tunneling from your router, with Admiral, for example. The one I picked is Wireguard.

This blogpost has been long enough. So here’s the basic idea:

• Install WireGuard on both your server and client devices to generate the necessary private and public key pairs.

Set up the client config to ensure secure connections through the VPN.

Access SSH through the WireGuard VPN by connecting to the server’s internal VPN IP address.

Like I said, you don't lack options on how to configure and access you server. You just need to pick one, understand why it works and use it.

📌 What’s Next?

Heck if I know. I'm just here for the ride.

Happy Father's Day.

Securing Your Website: Cloudflare Tunnels, WAF, and Bypassing ISP Restrictions

 

 

            *Poo-Tee-Weet?*

 

Following some really great advice from someone who was kind enough to give it, I decided to devote some time to Web Application Firewalls (WAF), IP masking, and network security, particularly using Cloudflare’s free tier.


Over a year ago, as part of my course's challenge at ATEC, I launched my own website: www.kernelcoredive.org (don’t rush to open this link—it's still under construction). It was a small space where I documented low-level programming concepts, mostly focusing on Assembly and computer architecture.

As time went on, I got caught up in my internship and stopped updating the site, shifting my focus to both LinkedIn and this blog.
But as this challenge came up, I went ahead and renewed my domain name on Namecheap.

This post (and the next one) will document my process, some issues I found and the subsequent solutions. If you’ve ever wanted to host your own website, this should help you get started. It’s surprisingly easy, costs about €15/year, and might introduce you to essential networking and security concepts.

---

📌 Step 1: Registering a Domain

First things first—you will need a domain name. This was done through a domain registrar. You can pick one from providers like GoDaddy, Namecheap, or the Cloudflare Registrar.

Once you choose a name and pay a small yearly fee, the domain is yours (and will be as long as you pay up). Now, we need a web server to actually host the website.

---

📌 Step 2: Setting Up an Apache Server

I set up an Apache web server on my machine to host the website. Since I don’t want to clutter this post with step-by-step Apache setup instructions, I'll just point you to an excellent guide: Server World.

Follow that documentation, and you’ll have Apache running locally in no time.
And do take a look at the site. I found it really helpful a year ago during my Linux classes.

---

📌 Step 3: Connecting My Domain to Cloudflare

Next, I signed up for a free Cloudflare account. This gives me access to DDoS protection, caching, and security tools.

Adding my domain was pretty simple—you just have to follow Cloudflare’s setup guide, and it will automatically scan your DNS records.

At this stage, I also updated my domain registrar’s DNS settings to use Cloudflare’s nameservers (again, follow the instructions set up by Cloudflare). This ensures all traffic is routed through Cloudflare before reaching my server.

---

🫢 Step 4: Issue: My ISP Blocks All Inbound Traffic

This is where I got to metaphorically bang my head against a wall and was failing at reaching my server.

I needed to link my public IP address to my domain—something I had done in the past without issues. But this time, no matter how hard I tried, I couldn’t access my public IP.

After testing with nmap and other tools, I confirmed that my ISP was blocking all inbound traffic. My router was not allowing requests to reach my server, no matter what ports I used.

 I also couldn’t simply port-forward my way out of this. After carefully checking my ISP router settings, I found that port forwarding wasn’t available at all.

A possible solution? Creating a Cloudflare Tunnel.

---

📌 Step 4: Setting Up a Cloudflare Tunnel

A Cloudflare Tunnel allows outbound connections from my server to Cloudflare, bypassing ISP restrictions entirely.

I installed it with:

curl -fsSL https://github.com/cloudflare/cloudflared/releases/latest/download/cloudflared-linux-amd64 -o cloudflared
chmod +x cloudflared
sudo mv cloudflared /usr/local/bin/
cloudflared tunnel login

However, I ran into a DNS conflict issue. While cloudflare had created a couple of A records for my server, I needed in fact a CNAME record instead. While A records point towards an IP, a CNAME record would allow for cloudflare to route traffic through the tunnel. So, I deleted the A records and created the necessary CNAME record.

This is all done under the DNS tab on cloudflare, btw.

---

📌 Step 5: Enabling HTTPS with Free SSL

With my tunnel working, my website was now accessible over HTTP. But I wanted encryption (HTTPS), so I added a free SSL certificate from Let’s Encrypt. I had done this a year ago, and it was as simple as it was before.

Again, I won’t bore you with the step-by-step setup—Let’s Encrypt is easy to install, free, and a game-changer for web security.

Then, I went to Cloudflare > SSL/TLS > Edge Certificates and enabled:
✅ Always Use HTTPS
✅ Full (Strict) SSL mode

 

---

📌 Step 6: Configuring Apache & Cloudflare

Cloudflare was now handling HTTPS redirection, so I had to disable Apache’s HTTPS redirect to prevent a redirect loop.

I edited /etc/apache2/sites-available/kernelcoredive.conf and commented out these lines:

RewriteEngine On
RewriteCond %{HTTPS} !=on
RewriteRule ^ https://%{HTTP_HOST}%{REQUEST_URI} [L,R=301]

And restarted Apache.

Note that these lines might not be exactly like this in your setup. Look for any lines handling redirection in your configuration file and comment them out to avoid conflicts with Cloudflare’s HTTPS enforcement.

Now, my website was fully accessible, bypassing my ISP’s filtering.

---

🔒 Step 7: Adding Security – WAF & Bot Protection

With my site running through Cloudflare, I started testing Web Application Firewall (WAF) rules.

I created two rules:
1️⃣ Blocking a specific country (e.g., blocking all traffic from a particular region).
2️⃣ Configured a CAPTCHA challenge for any requests using the python-requests User-Agent.

I tested this out with:

curl -A "python-requests" https://kernelcoredive.org

You might be a bit more refined in your tastes, and have a test that actually addresses the Captcha part. Either way, and as you can see, the logs can show us these failed communication attempts.

I also enabled Cloudflare’s basic bot fight mode, which is included in the Free Tier: 

---

📌 Step 8: Next Steps

Right now, the Cloudflare Tunnel is running manually, meaning if my machine reboots, or if I close the service, the tunnel stops.

Tomorrow, I’ll create a systemd service to keep my tunnel online 24/7 on a Raspberry Pi.
I'm also going to subscribe to the pro tier, in order to practice with these and other concepts for the next month. This stuff is fun, and gives us a ton of flexibility on what and how many tiers of protection we want to implement.I also want to explore the Cloudflare API to see what kind of automation and security controls I can implement.


Fun! There's more tomorrow.

I Dislike Soft Skills Talk—So Hear Me Out on Soft Skills.

 

                    "Where be yer low level ramblings, ye heathen?"

技 (Waza) – technique, skill, or ability

Lacking the time to properly organize my thoughts on malware and cybersecurity (or whatever strikes my fancy), I might as well put forth something else that's been dangling in my mind, persistently nagging to come out and play: the importance of soft skills in IT in general (cybersecurity included).

Being a techie myself, loving all (yeah, right) most things technical, and truly an introvert at heart, I can say without hesitation that I don't really appreciate the constant call for newcomers in both IT and cyber to focus hard on the "soft" side of their skills.

We're led to believe that these skills are oh-so-fundamental, to the point where instead of drilling into the technical basics and particulars of each profession, we get video after video, article after article, and mouthpiece after mouthpiece telling us to prioritize social aspects. I've even seen cybersecurity folks claim that if they could redo their path to cyber mastery (or whatevs), they'd go back to college and focus much more on networking (the human kind) while paying less attention to the technical side.

I take a hard stance against this.

• Our fields are highly technical in nature.

• We DO have a significant technical knowledge gap.

• Most of this knowledge takes years to grasp, master, and apply.

• These so-called soft skills are actually quite easy to learn and deploy.

Sure! You won’t become a master speaker or the next Shakespeare in a couple of months, but you don’t need to be. You just have to be able to communicate clearly—enough that those less technically inclined can understand you.

 

Where am I coming from with all this certainty about these much-hyped social skills—the so-called golden key to a successful tech career? Well, before diving into IT, even before working in math, I worked as an actor, director, screenplay writer, and acting teacher for over 15 years. So I might know a thing or two about speaking before a live audience, presenting oneself, and communicating effectively.

 

I don’t claim to be the greatest expert—far from it. But I’ve walked the walk and talked the talk, and now that I’m in IT, I can tell you: the two are not even remotely comparable.

My long-term goals in 'IT' are harsh, to put it mildly. Heck, I must have been very drunk when my brain decided that low-level code, reverse engineering, and poking at weird malware was the greatest invention since sliced bread. But even just talking about mastering the basics needed to apply with any real confidence to cyber positions—the often-mentioned triad of programming, systems, and networking—takes serious effort. To actually understand these fields, to feel comfortable discussing them, to even recognize what’s being said in a conversation? Believe me, acting is easier. Speaking in public, presenting your thoughts in a structured manner—these things are much easier.

Now, granted, you might not want to do it. You might be shy, socially averse, or a bloody introvert like me. But that doesn’t make it difficult. It just makes it uncomfortable.

So, is this blog post just an excuse to ramble against soft skills?

No, not really. Just because I dislike something—or the exaggerated emphasis placed on it—doesn’t mean it’s wrong. Quite the contrary.

Soft skills are, in fact, useful. Knowing how to write, speak, present yourself—in one word, communicate—is undeniably important.

 

Just recently, I had to coordinate a troubleshooting session remotely, where instructions had to be relayed to a team that wasn’t entirely familiar with the technical process—and let’s just say that language barriers didn’t help. Communication isn’t just about simplifying tech for upper management. Sometimes, it’s about conveying precise, critical steps to people who need to act on them immediately, without confusion.

In the end, it worked. But it was quite the ride, and I found myself pivoting, adapting and adjusting, in order to get the troubleshooting steps through and carry on with what we were doing.

So, yeah. There’s that too. Communication takes many forms, and you’ll need it sooner rather than later. Don’t just ignore it. And, to re-iterate some good and bad news: it’s much easier to learn and quicker to grasp than you might think—but that doesn’t mean you’ll enjoy it.

 

Enjoy the ride, though. If at all possible.

 

A former acting colleague once said: life is just the backstage intermezzo you take between being on stage.

 

I don’t like that statement. But he might be right.

Insert Here Joke About The 'S' In IoT: ___________

                    ─ Anne Rice

            "One moment the world is as it is. The next, it is something entirely different. Something it has never been before."


忍耐 (Nintai) – Endurance & Patience

Life has its twists, turns, tugs, and takes, right?

Lately, I’ve been (kind of) ‘forced’ to plunge into radio waves—5GHz, 2.4GHz, channel allocations, and even how certain countries restrict radio some frequencies.

"Woah, so new job and you got more free time to explore stuff?"

No. Not really.

If anything, I have less free time than ever. Firewalls, network congestion, MAC virtualization, plus remembering things I learned over a year ago, while picking up new tricks along the way. But here’s the thing—I get to manage my time better (to a point). 

Not because the workload is lighter, far from it.

The difference? I’m not buried neck-deep under tickets every minute of my working day. Instead of having problems chase me around nonstop, I carve out specific windows to troubleshoot, test, and develop strategies─tackling issues before they spiral out of control. And when the odd danger moment does come up, I can devote my time and energy to it.

A three-hour troubleshoot session? No problem. An endless stream of tickets for three hours? That drains the life out of you.

Drop by drop.

So, I decided to get my hands dirty and learn a bit about IoT hacking. Why the hell not?

I didn't get the luxury of studying computer science or electrical (or-anything-very-technical-really) engineering for 3 years in college─on the other hand, that gave me the privilege of carving out my own study program, and avoiding dumb, mandatory courses.

I started with this Defcon32 talk, which was surprisingly accessible, straight to the point, and fun. After that, I picked a target, got some basic tools, and started tinkering.

                "Nice IoT you got there, friend. T'would be a shame if something happened to it..."

It's not about going uber deep on this, it's about understanding a bit more about the field, getting our hands dirty and seeing if anything clicks. Also, you never know when any of this might come in useful.

Never in my life have I ever wanted to become a DB engineer, or backend mantainer, but I don't know how many times it has been extremely useful to know how to query a DB or create a View.

And always: The journey is the fun part.

Meanwhile, I've been chipping away at Practical Malware Analysis (yikes, he likes books!) but I'm saving that for later. I'll need some time to organize my notes and scribblings into something half-decent, before that becomes a blog post.

Honestly, I kind of envy the people who seem to have all the time in the world to write massive, in-depth blog posts. How do they do it? I guess, like anything else, it comes down to practice—it gets easier the more you do it.

I'm lucky if I manage to put out one of these out every so often.

But hey─if you're deep into your own projects, I hope you're having fun.

Wherein We Forsake: Farewell and Godspeed

棄 - 'to forsake', 'to discard', 'to renounce'

My friends are leaving.

Some were close friends; others were simply colleagues. But if you think about it, we spend so much time with our workmates that they become more than just faces we see at work—they’re part of our daily lives. For many of us, we see our colleagues more often than our families.

I sleep very little, which gives me some extra home time, but still, the reality is that I spend most of my waking hours surrounded by these people. And now, a significant number of them are gone.

I feel sorry for them and for us. I liked many of them, and from what I saw and heard, most were incredibly skilled at what they did. Their departure wasn’t their fault.

So today’s post is a tribute to them.

---

It’s been a month since I’ve written here. In that time, I’ve made a diagonal move in my career (up and to the side) into the role of network specialist. With this role comes a fair amount of autonomy to decide how to implement and secure systems. My onboarding is still ongoing, but I feel the itch to write and return to one of my passions: reverse engineering (RE).

Not today, though. My focus lately has been squarely on network security, and I’ve been wrestling with a thought that might resonate with some of you network addicts:

Network Protection vs. User Accessibility

How do you strike the right balance between keeping a network secure and ensuring it’s user-friendly?

The Freeloader Debate

When managing a network—especially one shared by multiple teams or even public users—you’re forced to ask yourself a tough question:

Do you lock it down, leave it open, or what?

Option 1: Lock It Down?

You could go full-on security mode and control every possible access point. Some options include:

• Blocking unapproved MAC addresses.
• Whitelisting only specific devices.
• Creating VLANs to isolate users and devices.

This approach keeps freeloaders and unauthorized devices off your network. But at what cost?

• Your IT team faces a constant workload managing requests and ensuring critical devices aren’t accidentally blocked.
• Field teams and guests are often frustrated when they can’t connect because their devices are blocked by default, leading to complaints and delays.

Option 2: Leave It Open?

You could take the laissez-faire approach. Just let everyone connect. No restrictions. No extra work.

But this comes with its own set of risks:

• An overloaded network, with too many devices competing for bandwidth and impacting performance for critical systems.
• A wider attack surface, as bad actors could exploit this openness to gain unauthorized access.
• Difficulty in tracing network activity, making it harder to identify devices or users when issues arise.

---

As a wise Jedi once said, “Only Sith deal in absolutes.” Neither extreme is sustainable. A locked-down network might keep freeloaders out, but it also hampers legitimate users from getting their work done. On the flip side, an open network exposes you to security risks and performance issues.

Without going into the nitty-gritty of it all, here are some alternative strategies:

1. Set Up a Guest Network
   A dedicated guest network with bandwidth throttling and basic isolation ensures that guests can connect without overwhelming critical systems.

2. Implement Role-Based Access
   Integrate with RADIUS or Active Directory to dynamically assign permissions based on roles.

3. Use Time-Based Access Policies
   Temporary users (e.g., guests or contractors) can be assigned access that automatically expires after a set period, preventing long-term freeloaders.

4. Monitor and Audit Regularly
   NetFlow or your router’s built-in logging can track activity. This helps detect anomalies before they become bigger issues.

This isn’t just about blocking bad actors—it’s about enabling legitimate users while minimizing risk. It’s a game of checks and balances, not unlike managing resources in an economy or a strategy game.

I can’t go into much detail for obvious reasons, but I wanted to share this small glimpse into a different side of cybersecurity—one that’s as much about people as it is about technology.
I know, I know, too basic: and you're right. Besides, the fun is in the little details, and the clever choices you make. Right? But today is not the day for that.

---

To My Friends

So, to my friends who weren’t freeloaders, who worked hard, and who I’ll miss:

Stay strong in the trenches, stay inspired, stay healthy, and remember—every system, like every farewell, brings its own challenges and opportunities.

Roger and out.