Author: Andriy

  • Why a Flooded Inbox is Actually a Major Security Threat

    As a 23 year old studying IT here in Poltava, I spend a large chunk of my day reading about networks and cybersecurity trends. A lot of the threats we learn about are incredibly complex and rely on unpatched exploits or advanced malware. But recently I came across a fascinating article by Dalia Schonfeld that focuses on an attack that is surprisingly basic but highly effective. It is called subscription bombing.

    If you have never heard of the term, subscription bombing is exactly what it sounds like. Someone takes your email address and plugs it into thousands of automated signup forms across the internet. Suddenly your inbox is flooded with newsletter confirmations, mailing list welcomes, and promotional emails from legitimate websites you have never even visited.

    The most interesting part to me is the actual motive behind the flood. When we see thousands of junk emails arrive all at once, we usually assume it is just an aggressive spam campaign. But subscription bombing uses volume as a weapon of distraction. The attacker is not trying to trick you into buying a fake product. They are trying to hide something very specific.

    For example, imagine a hacker gets into your online shopping account and buys an expensive laptop using your saved credit card. The retailer will automatically send you an order confirmation. To stop you from seeing that single critical email and canceling the order, the hacker triggers a subscription bomb. Your legitimate fraud alert gets completely buried under thousands of random newsletter signups. By the time you notice what happened, the stolen item has already shipped. They also use this trick to hide alerts for password resets, new device logins, and bank transfers.

    Schonfeld points out some really practical advice on how to respond if this ever happens to you. The natural instinct is to panic and select everything for mass deletion. You might also be tempted to open every email and click unsubscribe. But doing either of those things plays right into the hands of the attacker.

    Deleting everything means you might delete the exact security alert they are trying to hide. Clicking unsubscribe on hundreds of emails is also dangerous because attackers might slip actual phishing links into the flood.

    Instead, the article recommends using your email search function immediately. You should look for words like order, purchase, password, or security alert. You also need to check your actual bank accounts and credit cards directly to see if any unauthorized transactions are pending. Another crucial step is checking your email settings for hidden forwarding rules. Attackers often compromise an inbox first and set up rules to forward important emails to themselves before launching the bomb.

    From a developer perspective, this attack is frustrating because it relies heavily on bad web form design. Whenever I build a web project, I try to keep the user experience as smooth as possible. But this article is a great reminder of why we need friction in the right places. Websites that do not use rate limiting or confirmed subscription methods become unwitting tools for these attackers. If every newsletter required a user to actually click a link in a confirmation email before sending more messages, this type of attack would barely work.

    This was a great read that completely changed how I view a messy inbox. It proves that sometimes the most dangerous attacks are the ones hiding in plain sight. Keep your passwords strong, use an authenticator app, and always investigate if your inbox suddenly blows up with random subscriptions.

    https://medium.com/@cyber.basics/subscription-bombing-what-email-bombing-attacks-are-and-how-to-stop-them-d66ff1d2e612

  • Mapping the Hidden Adtech Supply Chain and Why It Is a Real Security Problem

    When most people browse the web, they assume that the primary relationship is between their browser and the website they chose to visit. In reality, modern web publishing is layered on top of an intricate and largely opaque programmatic advertising supply chain. Every page view triggers a rapid series of real-time auctions involving ad exchanges, data brokers, supply-side platforms, and analytics trackers.

    For anyone studying networks and computer systems, it is clear that every external script or network request injected into a page represents an expanded attack surface. I recently read a piece by Brian Krebs detailing a new platform called DecryptAds, which aims to bring transparency to this tangled ecosystem by scraping and cross-referencing public adtech declarations. Looking at how this tool operates and what it exposes provides a fascinating lesson in how ad tech has turned into an unmonitored security risk.

    The Problem with Scattered Ad Files

    Over the past few years, the online advertising industry introduced several standardized text and JSON files to combat basic ad fraud. Publishers host an ads.txt file on their root domain to list authorized sellers, mobile applications use app-ads.txt, and ad networks publish sellers.json files to identify who is buying and reselling their inventory.

    In theory, these files allow buyers to verify whether an exchange actually has the right to sell impressions on a specific site. In practice, they are decentralized and messy. A single large publisher might declare hundreds of partners. Reading one file in isolation tells you almost nothing about the broader network.

    DecryptAds, developed by threat researcher Zach Edwards and his team, bridges this gap by continuously indexing these files, cross-referencing broken declarations, and combining them with state-level data broker registries. When you combine these datasets, you can trace an entire supply path and see which entities are allowed to execute code, serve assets, or harvest telemetry from a given site.

    Geopolitical Risk and Malvertising Vectors

    What makes this cross-referencing so valuable from a security perspective is the insight it gives into data flows and geo-risk. For example, DecryptAds flagged that major sports sites and several defense-focused news outlets list adtech partners with infrastructure linked to Russia, China, or financial entities under international sanctions. A company might list a business address in New York, but its actual backend settlements and operations route through sanctioned financial institutions abroad. When these platforms serve scripts on websites visited by sensitive personnel, it stops being a mere privacy issue and becomes a national security concern.

    Another major threat highlighted in the report is malvertising. Attackers frequently exploit the ad bidding pipeline to distribute zero-click exploits, drive-by downloads, or malicious redirects. High-traffic mainstream websites often pay for third-party security verification tools to filter out toxic ads before they load. However, the web is currently being flooded with low-quality, AI-generated content farms. These sites exist solely to capture search traffic and monetize it with bottom-tier ad networks.

    Because these automated content farms do not invest in ad verification, they serve as open channels for malicious campaigns. If a user lands on one of these pages from a search query, malicious actors can target their browser through unchecked ad slots.

    The industry also suffers from a lack of transparency regarding enforcement. When an ad exchange discovers fraud or malicious activity from a partner, it rarely publishes a public post-mortem. Instead, it quietly removes the offender from its sellers.json file. This practice lets malicious or shady entities move on to other exchanges without public scrutiny. Tracking these quiet removals across multiple exchanges in real time exposes suspicious patterns that would otherwise stay hidden.

    The Missing Piece: The Supply Chain Object

    One technical detail in the article that stood out to me involves the Supply Chain Object, or SCO. In standard OpenRTB bidding protocols, the SCO is a piece of structured data passed with bid requests that records every intermediary, reseller, and final buyer involved in handling an impression.

    Right now, this information is handled server-side and kept proprietary within major ad networks. When an endpoint gets hit with a malicious payload through an ad, incident responders can usually see the malicious redirection in network traffic, but they cannot see the full SCO. Without that server-side supply chain data, it is nearly impossible to pinpoint the exact entity that bought the impression and pushed the exploit. Pushing for broader transparency around SCO data would be a huge step forward for web security research.

    Practical Steps for Network Defense

    Looking at the sheer volume of trackers and data brokers declared across everyday websites reinforces why aggressive blocking is a baseline requirement for cybersecurity.

    From a practical standpoint, browser-based content blockers like uBlock Origin or uBlock Origin Lite remain essential on desktop setups. For broader coverage, implementing DNS-level filtering on your local network using a Raspberry Pi running Pi-hole or using dedicated privacy-focused DNS resolvers is one of the most effective ways to drop tracking queries before they ever leave your local subnet.

    It is also a good reminder to treat mobile apps with caution. Mobile applications frequently bypass standard browser isolation and privacy controls, giving embedded ad SDKs direct access to device telemetry, location data, and network details. Whenever possible, using a well-configured browser is safer than installing dedicated apps for every service you interact with.

    Source: https://krebsonsecurity.com/2026/08/whos-tracking-you-use-this-new-service-to-find-out/

  • Learning IT in Public

    My name is Andriy. I am 23 years old, I am from Poltava, and I am studying IT. Most of my days revolve around computers, code, networks, and trying to get better at cybersecurity. Sometimes that means reading about attacks and defenses. Sometimes that means setting up a virtual machine and breaking stuff just to see what happens. And sometimes that means staring at an error message for way too long before realizing I made a stupid mistake.

    I am not trying to act like I have it all figured out. I am just a dude who is really into this field and wants to document the journey. I like technology, I like solving problems, and I like the feeling when something finally clicks after confusing me for hours.

    This blog is going to be pretty simple. I will write about what I am learning, what I am building, what broke, and what I wish I knew earlier. It might be about cybersecurity basics, IT studies, tools I am testing, or just life as a student in Ukraine who spends too much time online. I want it to feel real, not like some polished corporate tech content.

    Also, I think writing this stuff down will help me get better. If I can explain something in plain English, then I probably understand it better myself. And if somebody else reads it and gets something useful out of it, that is even better.

    So yeah. This is post number one. No huge master plan yet. Just a guy from Poltava trying to learn in public, build something of his own, and see where this goes.

    Thanks for stopping by. I will keep posting when I have something worth saying.