When I first arrived in Porto, I assumed the biggest local threat model would be cobblestones, pastry temptation, and the extremely organized seagulls patrolling the rooftops.

I was wrong.

Well, perhaps not wrong.
Let’s say: the investigation remains open.

For the last several weeks, I have been keeping one suspicious flamingo eye on the waterfront and the other on my WordPress honeypots. The seagulls are growing in power and sneakiness, yes, but the internet remains its own flock of tiny chaos birds. And unlike the seagulls, the bots do not even have the decency to scream before attacking.

My honeypots are built to behave like real hosts. They respond enough to be interesting. They block IPs temporarily when attacks cross the line. And, because I enjoy a little carefully controlled weirdness, the WordPress “forgot password” flow is configured to sometimes allow resets even for users who do not exist.

Before anyone panics: the reset does not work.

But if an attacker enters an email address, the system may send a reset email anyway. The goal is to see whether they come back and try to complete the loop. Do they test the mailbox? Do they try to replay the reset? Do they change behavior after getting a response?

In other words: are they just rattling the door handle, or are they listening to hear whether the house makes noise?

That is where honeypots get fun.
Not safe fun.
Security researcher fun.

Which is a very specific flavor of fun involving logs, caffeine-adjacent beverages, and occasionally saying “well, that’s interesting” to absolutely no one.

The first round of suspicious feathers

One snapshot of the honeypot data showed a few extremely noisy sources.

The top blocked IPs included:

• 91.92.243.234 from the United States: 1,924 blocks
• 34.79.95.85 from Belgium: 1,310 blocks
• 35.189.167.34 from Taiwan: 1,155 blocks
• 85.11.167.118 from Bulgaria: 354 blocks
• 91.92.40.173 from Bulgaria: 353 blocks
• 62.60.130.239 from Iran: 272 blocks
• 161.118.222.149 from Singapore: 253 blocks

That first dataset was weirdly lopsided. The United States had 104 blocked IPs and 2,543 total blocks, but Belgium and Taiwan each had only one blocked IP while still generating huge block counts. Belgium alone showed 1,310 blocks from a single IP. Taiwan showed 1,155 from a single IP.

At first glance, this looked like one of those classic “a few loud São João hammers hitting the same door” patterns. Or, as we say in Porto: one seagull screaming from a rooftop while pretending it is not the lookout.

I am not saying one of the seagulls looked Belgian.
I am simply saying one of the seagulls looked Belgian.

The second round: now the flock gets interesting

A later snapshot shifted the picture.

This time, the top blocked IPs included:

• 104.194.8.156 from the United States: 592 blocks
• 170.245.120.186 from Brazil: 300 blocks
• 111.95.62.43 from Indonesia: 257 blocks
• 49.37.66.15 from India: 169 blocks
• 143.198.220.109 from Singapore: 168 blocks
• 85.11.167.118 from Bulgaria: 156 blocks
• 157.22.102.245 from Seychelles: 153 blocks
• 217.142.21.131 from the United Kingdom: 150 blocks
• 83.22.231.253 from Poland: 150 blocks
• 102.213.176.14 from Kenya: 150 blocks

This time, the country totals were much more spread out and much more suggestive of rotating infrastructure:

• India: 53 IPs blocked, 5,714 total blocks
• Brazil: 40 IPs blocked, 1,489 total blocks
• Pakistan: 14 IPs blocked, 1,185 total blocks
• United States: 104 IPs blocked, 1,174 total blocks
• Philippines: 5 IPs blocked, 701 total blocks
• Indonesia: 6 IPs blocked, 676 total blocks
• Vietnam: 13 IPs blocked, 541 total blocks
• Kenya: 4 IPs blocked, 520 total blocks
• Nepal: 4 IPs blocked, 473 total blocks
• United Kingdom: 165 IPs blocked, 330 total blocks

That last one is especially interesting: the United Kingdom showed 165 blocked IPs but only 330 total blocks. That is a very different shape from Belgium’s earlier single IP with 1,310 blocks.

One pattern says “one loud São João hammer smacking the same door over and over.”

The other says “many smaller hammers, spread across the neighborhood, each pretending they are definitely not part of the same percussion section.” That second pattern is exactly where my flamingo eyebrow starts to rise.

Country maps are NOT attribution

It would be tempting to look at this and start making strong claims about where the attackers are located.

I will not do that.

IP geolocation tells us where traffic appears to come from. It does not tell us who is controlling the attack. It does not tell us whether the traffic came from a cloud instance, compromised host, VPN, proxy, mobile network, or residential proxy.

And that matters.

Attackers know defenders block IPs. They know that if one address hammers a login page 2,000 times, it will probably get punted into the digital canal. So they rotate. Sometimes they use cloud infrastructure. Sometimes they use compromised hosts. Sometimes they use residential proxy networks so the traffic appears to come from ordinary home internet connections.

That is harder to block cleanly. A single cloud IP screaming at your WordPress login page is easy to distrust. A lot of residential-looking IPs each making a smaller number of attempts is sneakier.

It is the difference between one seagull stealing your lunch in broad daylight and a coordinated pastry disappearance across six rooftops.

Both are crimes. One has better operational security.

The usernames were beautifully ridiculous

The failed login attempts told their own little story.

In one snapshot, the top attempted usernames were:

• admin: 29 attempts
• root: 20 attempts
• administrator: 15 attempts
• admin@ezunx.com: 10 attempts
• info@ezunx.com: 10 attempts
• admin@wordpress.com: 4 attempts
• bot: 3 attempts
• ivenyyqszj66: 2 attempts
• adminwp: 2 attempts
• pauldavis: 2 attempts

That is classic WordPress background radiation. “admin” because sometimes “admin” works. “root” because attackers are optimistic in the saddest possible way. “administrator” because apparently subtlety was unavailable.

But the later snapshot got more interesting:

• admin: 179 attempts
• securechicago: 30 attempts
• bsideschicago: 9 attempts
• loggershell443@gmail.com: 6 attempts
• emartin: 5 attempts
• root: 4 attempts
• bot: 4 attempts
• hengker: 3 attempts
• administratoir: 3 attempts
• wadminw: 2 attempts

Now that is a different flavor of noise.

“admin” is still king of the garbage mountain, but “securechicago” and “bsideschicago” suggest the tooling may be trying site-themed guesses instead of only generic defaults. That does not necessarily mean a human is staring dramatically at the site while wearing fingerless gloves. It could be automated username generation based on domain names, page content, branding, email patterns, or scraped public text.

But it is still notable.

Then there is “emartin.”
Five attempts.
No existing user.

Could emartin be a bot artifact? A credential stuffing remnant? A recycled username from some unrelated list? A random guess? A typo? A seagull wearing readers and operating from a tiled rooftop?

The responsible answer is: we do not know.
The Sasha answer is: I have opened a case file.

The typo tells a story too

One attempted username was “administratoir.”

That little typo is delightful.

Not because it is useful on its own, but because attacker data often contains tiny fingerprints of tooling, wordlists, mistakes, translations, old dumps, and automation glue. A typo may be meaningless. Or it may appear across multiple honeypots, campaigns, or payload sets and become useful later.

Honeypots are good at collecting these odd little crumbs.
And sometimes the crumbs become a trail.

And sometimes the trail leads to a seagull with a laptop.
Again, investigation ongoing.

The attacks were not just login attempts

The honeypot also blocked more than simple credential guessing.

In the earlier data, several attacks were blocked for:

• WPGraphQL <= 0.2.3 - Multiple Vulnerable Actions
• And many other known malicious User-Agents

On June 29, there were repeated WPGraphQL-related blocks from Bulgaria, Singapore, and South Korea, along with a burst of known malicious user-agent blocks from the Netherlands.

In the later data, on July 13, one United States IP triggered repeated blocks for known malicious user agents. A Vietnam IP was blocked for the same old WPGraphQL vulnerability probe, with dozens of additional attacks nearby.

That matters because it shows the traffic is not only trying passwords. It is also probing for vulnerable plugins, old software, exposed functionality, and recognizable weak spots. This is normal internet scanning behavior. The attacker does not need to know your site personally. They throw a giant net across the internet looking for anything that answers.

• WordPress?
• Try common logins.
• WPGraphQL?
• Try known vulnerable actions.
• Password reset?
• See if it behaves like a real site.
• User-agent block?
• Try anyway because bots are not known for shame.

Most of this is automated. Some of it may be chained. A little of it may be watched by a human after the automation finds something juicy.

And somewhere in Gaia, a seagull looks very busy near a chimney.

Why the fake password reset behavior is useful

The fake password reset behavior is one of my favorite parts of this setup. A normal failed login tells you someone tried a username and password.

A password reset attempt can tell you something slightly different: whether the attacker is testing account existence, whether they are probing the reset workflow, whether they control or monitor the email address they entered, and whether they return after receiving a response.

• It creates a small interaction loop.
• Not enough to put anything real at risk.
• Enough to see whether the attacker reacts.

That distinction matters because some automated attacks are fire-and-forget. Others adapt. If a honeypot can safely create moments where attackers have to reveal whether they are paying attention, the data becomes more useful.

• The reset email is bait.
• The reset link is harmless.
• The behavior afterward is the interesting part.

What I think is happening

My current theory is that the honeypot is seeing a mix of:

• Generic WordPress login spraying
• Site-themed username guessing
• Vulnerability scanning for known plugin issues
• Malicious or suspicious user-agent activity
• Rotating infrastructure to work around temporary blocks
• Possible residential proxy use to make traffic look more distributed and less obviously malicious

The two datasets show different shapes of attacker behavior. Some IPs are noisy and repetitive. Some countries show many IPs with lower counts. Some usernames are generic. Some appear customized. Some attacks are credential-focused. Some are vulnerability probes.

That mix is very normal for exposed internet services. It is also exactly why honeypots are useful. They turn the endless static of internet background noise into patterns you can study.

The lesson is not “block one country” or “panic because admin was tried again.”
The lesson is: attackers adapt to friction.
So should defenders.

Defensive takeaways from the flamingo desk

For real WordPress sites, this is the boring-but-important part:

• Do not use obvious usernames like admin.
• Use strong, unique passwords.
• Enable MFA wherever possible.
• Keep WordPress, themes, and plugins updated.
• Remove plugins you do not need.
• Watch for vulnerability-specific probes, not just failed logins.
• Rate-limit authentication and sensitive workflows.
• Log enough to see patterns over time.
• Be careful with country-based conclusions.
• Assume attacker infrastructure rotates.

And if your defenses only work against one noisy IP, remember that attackers can bring more IPs.

Possibly many more.
Possibly wearing little hats.

What I am watching next

For now, the honeypot is doing what a good honeypot should do: attracting noise, shaping it into data, and giving me a place to observe attacker behavior without putting a real production site at risk.

The things I care about most are:

• Which usernames keep showing up.
• Which IPs come back after temporary blocks expire.
• Whether password reset emails create follow-up behavior.
• Whether attacks shift after blocks.
• Whether vulnerability probes arrive in clusters.
• Whether user agents, IP ranges, timing, and payloads suggest shared tooling.
• Whether site-themed usernames increase.
• Whether emartin returns.

And, of course, whether any of the seagulls have recently subscribed to a residential proxy service.

I am not saying the Seagull Syndicate is behind the WordPress attacks.
I am simply saying the evidence is not yet conclusive.
The logs continue.
The honeypots continue.
The rooftops are under observation.

And if emartin turns out to be three seagulls in a trench coat with a botnet, I will not be surprised.
Stay patched. Stay curious. Watch the birds.

Sasha

This should pair beautifully with the image as the “field notes from Gaia” debut.