blog.securityhero.site
Real attacks our honeypot caught. Every morning.
Observed 2026-10-18 · Yesterday's observations
The same '559 commands' intrusion that has been repeating since October 13 from shifting origins came back on the night of October 18. Within 1 hour and 8 minutes, four places pulled down the same two files. The install script came from an address we had never seen. The device executable was the same size as last time, but its hash was a value we had never seen.
Text messages impersonating crypto exchanges and wallet companies use 'protect your assets' as the hook to get you to tap a link. Follow the link and you land on a screen asking for your wallet recovery words. Based on the advisory KISA issued on October 16 and a case reported by AhnLab ASEC, here is what to do right now.
An address that had only sent down a tiny installer script on October 8 sent down three kinds of executables 44 times on October 15. All three appear to be built for the chips in small devices like routers, not the computers we use. The same day, screen-sharing (VNC) contacts hit 84,222 — once again breaking the record set two days earlier.
You tapped 'Update' in a short-drama app — and a few days later your banking app has become a tampered build that only looks the same. Here is a rundown of Hirudo, the Android malware disclosed by security firm ThreatFabric: why it works, and what you can check right now.
On October 13, three sources came in over Telnet and ran through the same 559 commands five times. Each run pulled down 22 files and left within a minute and a half, and at 4:50 PM two of them arrived 0.9 seconds apart and did the same work side by side. The address that served the install script is the fourth one to show up from the same address range.
A Ledger hardware wallet sold at nearly half the list price was reported to contain a chip the manufacturer never made. According to researchers' analysis, that chip sent out the 24 recovery words that appear during initial setup. Here's why where you bought your device is itself a security question, and what to do right now.
On October 11, 255 sources touched the remote desktop door (3389) — the most in a single day since we began keeping records. Yet contacts per source were just 4.15, the fewest ever. The same day, on our other server, a session came back using the same tool we saw 46 days ago and attempted key planting, a scheduled job, and trace removal all within one minute.
Some of the ultra-cheap Android phones carrying Samsung and Apple names had malicious apps inside them from the moment they left the factory. Because the apps sit inside the system, they are hard to delete, and a factory reset does not get rid of them. Based on a Bitdefender report, here is who is affected and what you can do right now.
On the evening of October 8, the same source logged into our server over Telnet four times. All four times it finished 9 commands in 9.5–9.7 seconds, and each time it pulled down a 1,670-byte installer script. This file was downloaded 15 times that day, and all 15 times the one doing the downloading was this single source.
You clicked 'Sign in with Google' and a window appeared whose address was genuinely Google's. But that window was a fake the phishing page had drawn inside its own screen. Behind it, a human operator was taking the password and the verification code in real time. Based on a report from the security firm Island, here is the one place that separates a real window from a fake one.
On the morning of October 6, a single source logged into our SSH server five times over 8 minutes and 37 seconds. Each time it ran exactly two commands, and across all visits it pulled down 24 files. Those executables were built for ARM 32-bit devices, not servers — and the client fingerprint, the distribution hosts, and the hashes were all values we had never seen before.
All nine file types left on our two honeypots on October 4 were hashes we had seen before. One session even came back matching a visit from 42 days earlier down to 32 seconds, 48 commands, and 12 files. Only one number set a record. Password combinations whose values we withheld — because they could be someone's real account — numbered 3,026 types, the most we have ever recorded.
Apple's official preorder opens on October 16. Ahead of that, a fake preorder page dangling a '$500 coupon' has been found. According to the analysis, on an iPhone that has put off updating, merely opening this page starts the attack.
On October 1 there were 43,402 screen-sharing (VNC) connection attempts — within the normal range. But the version string offered on connect was a new one that had never once held a majority across 21 days, and it accounted for 63.2%. The same day, on our other server, a file named — literally — 'backdoor.sh' came down from an address we had never seen.
Reports say the names, phone numbers, annual incomes, and loan limits of roughly 25,000 people who inquired about loans at Shinhan Bank have leaked. The fact that a caller knows your information precisely is not proof that they work at the bank. Here are the two things to do now, and what we still don't know.
A technique has been disclosed in which ChatGPT, Gemini, and Google's AI Overviews hand out fake customer support numbers as if they were real. The researcher found at least 374 companies whose names were impersonated and tens of thousands of fake contact pages. Here is how the AI was fooled, and what to check before you dial.
On September 27, a malware distribution address we had noted five days earlier served files again. The lead installer script has not changed a single bit in 37 days since August 21. All nine executables that followed were files we had never seen before, and three of them matched their earlier sizes down to the byte while differing in content.
Level13, the operator of the men's fashion app Lookpin, has admitted to a hack. Beyond the email addresses and phone numbers it first disclosed, addresses, refund account numbers, order histories, and even personal customs clearance codes for overseas direct purchases have been confirmed as leaked. We separate what cannot be changed from the number you can have reissued, and lay out what to do today.
On September 22, files came down again from a malware distribution address we first wrote down on August 21. The installer script at the front was not a single character different from a month ago, but all six executables — one per CPU type — were files we had never seen before. Five of those six carried exactly the names we had once learned only by unpacking a compressed sample.
On September 20, a single 389-byte public key that had appeared daily since August 16 was registered on our server from 41 different sources. That is 2.4 times the previous high of 17 among the days we compared — and there is no record that ties it in one line to the three other numbers that jumped alongside it the same day. Next to it, the executable we wrote 'was not rebuilt' three days ago came back to the same address, 1,696 bytes larger.
It was reported that the test-reservation site of 'Thinking Bull' (생각하는황소), a math academy with branches nationwide including Daechi-dong, was breached and that student names, schools, grades, dates of birth, and parents' phone numbers may have leaked. Here is what to do when someone holding that information calls to say 'your child has been hurt' — and what has not yet been confirmed.
On September 17, a third address appeared sharing its first three octets with the address that handed out files twice in August. All seven files that came from it are absent from 27 days of records, and five of them carry name tags resembling programs Linux runs on its own. Yet the intrusion that brought these seven files appears in none of the five sessions recorded that day.
You clicked an ad from an official account with a verified badge, and instead of an installer, a box popped up telling you to paste a command. The hand doing the pasting is yours, but what leaves is your passwords, notes, and crypto wallet. We unpack this technique — 108 ads posted in two days — with a single school locker.
At 12:07 PM on September 15, a Telnet intrusion ran 7 commands in 7 seconds and pulled down 2 files. The address the files came from and the address the intruder came from shared their first two octets — a shape we also saw on September 7 and 8, making this the third time in nine days. And 6 hours 59 minutes later, the same thing happened once more from the same place.
A 100GB-plus file is circulating in search results, communities, and torrents as a 'leaked build' of an unreleased game. Click install and it seems to end with an error — but behind that, remote-control, password-stealing, and file-destroying programs all install at once. We've laid out what to do before downloading, and what to do if you've already run it.
On September 13, contacts hitting the remote desktop port reached 42,578 in a single day, surpassing the previous high of 34,811 set three days earlier. The top sender was the same alias as before, and the name tag 'hello', which had dropped to 16 three days ago, came back at 7,039. All four file types received by the neighboring server were hashes we had seen before.
It has been reported that the information of some 219,000 users of Gangnam Unni, a cosmetic-medicine app, was leaked. Not just names and phone numbers, but which clinic they consulted, which procedure they discussed, and even consultation photos. Here is what to do when someone holding that information calls and pretends to be the clinic.
On September 10, knocks on the remote desktop port came to 34,811 in a single day. That is 1.62× the 21,483 from all 14 days between August 26 and September 8 combined — yet the number of places knocking was 109, inside the usual range. This is not a record of more visitors arriving; it is a record of one place pressing the button 319 times.
An investigation found that the discount shopping sites you see in ads lifted their photos, their product descriptions, and even their customer service numbers straight from the real brands. 119,000-plus confirmed addresses, 44,000 brands whose names were stolen. Here's what to look at before you type a card number into a checkout page.
On September 8, an address absent from 23 days of records dropped nine executables at once, differing only in CPU type. The intrusion that collected them typed exactly three commands and was over in 33.25 seconds. Then, 1 minute 12 seconds later, a 33.26-second run came through again.
You clicked a link, a real Google sign-in page appeared, and after signing in you pressed a blue 'Allow' button once. This is the technique the FBI's IC3 warned about on September 1. The password never reaches the attacker, yet mail and files keep leaking out.
On September 7, an address that had never appeared in 22 days of records showed up for the first time. The two executables downloaded from it are nearly identical in size and do the same thing — two builds differing only in the order they read numbers. Whoever made them sent them out without stripping the labels inside the files.
On September 6, the number of places knocking on the screen-sharing door went from 100 to 264 in a single day. But the number of knocks only rose 1.4x, which means the knocks per source were cut in half. This is the record of a day when a thin, wide-spread crowd was layered on top of the few who hit hard.
On September 5, five of the six files that landed on our server were names already written down for 20 days running. But while cross-checking the records, we found the error was on our side. A field we'd logged as 'so far, 50 sources' had read 35 the day before — and that wasn't because the attacks had let up.
On September 4, 233 of the 419 sources that visited our server arrived carrying the same client-program marking. But those 233 didn't drop a single file, and the only marking that actually delivered a sample that day came from just 2 IPs. This is the record of a day when the most-stamped footprint and the footprint that left something behind were not the same.
On September 3, four files we had written down on a blocklist five days earlier came back in. But when we fingerprinted them, three were new files that had never appeared once in 18 days of archives, and exactly one was the same file, unchanged down to the bit, for the sixth day running. What doesn't change even when the clothes do — that day's data showed it in four lines.
On September 2, the doorknobs on our server turned 44,140 times in a single day. But only one 'thing we'd never seen before' actually made it inside, and it came through a passage that opens just 23 times a day. Everything else was the same rerun, on day 17 and day 18.
On September 1, the commands entered into our server went from 760 to 14,085 in a single day. But only 422 of them (3.0%) had a classified intent, and the act of actually leaving someone else's key behind happened 13 times. A bigger number and a more dangerous number are not the same thing, so on this day we broke down what the bigger number actually was.
On August 31, four numbers that yesterday read 107, 107, 106, and 116 all dropped to 8 in unison. That they rose together and fell together points strongly toward their having been one cluster, but the data has still never tied the four together. Instead, 324 distinct sources knocked on the door — the fourth highest of the sixteen days — while sessions per source hit a low of 2.40.
On August 30, 107 different sources arrived carrying the same username and the same single password. Yet the average number of knocks per source was 1.05. Nine sources yesterday became 107 in a single day, and the same 389-byte key file came from the same 107 sources.
On August 29 there was not a single thing our honeypot had never seen before. The same 389-byte file showed up for the 14th day running, this time from nine different places, and the two distribution sites were unchanged too. 'Nothing happened' and 'the same thing happened again today' are not the same sentence, so on this day we wrote down the fact that nothing changed.
On August 28, a server that had caught nothing for two days produced four files all at once. 773,937 bytes in total, all from the same single source. But these files have no field at all for recording 'where it came from,' so we're left with no address to add to a blocklist and no distribution site to report.
On August 27, the commands run on our server numbered 2,313 — one-sixth of the previous day's total. Yet the number of distinct source locations hit 442, setting a new high for the third day running, and exactly one behavior set a high alongside it: planting someone else's public key. The same 389-byte file appeared for the 12th consecutive day, this time from 26 different sources.
On August 26, our two servers received 42,000 and 5,000 contacts. The noisiest one didn't leave behind a single file, and one session that lasted 12.5 seconds left ten. That day's data showed us twice over that measuring risk by volume of noise flips the order.
EU NIS2, DORA, ISO 27001, Korea's ISMS-P, Japan's APPI, Singapore's CII. The names of the documents they ask for are all different, but the underlying substance overlaps. We've laid out in a table what each regulation requires and which of those slots a risk assessment report fills.
The number of times someone knocked on our server's door yesterday was perfectly ordinary. But three behaviors that happen *after* the door opens all hit ten-day highs on the same day. Adding someone else's name to the standing-access list: 69 times. Erasing the record of having been there: 70 times — a difference of exactly one.
"Your data never crosses a border" is not a story about patriotism. It is a question of whose storage the assessment results sit in and who holds the key. We unpack BYOK and adequacy decisions through the analogy of a bank safe deposit box.
Mirai was a program three college students built to attack a game server. The day they dumped the source code onto the internet, the story changed — and ten years later it is still knocking on our servers' doors.
Yesterday our honeypot received files with the same names from the same address as the day before. But all three executables had entirely different contents, and only the loader script at the front was identical for a second day. Yesterday's data measured, directly, that every value you write into a blocklist has a different shelf life.
It's easy to assume that inspecting something means installing something. Agentless goes the other way. Instead of searching the house, it reads the blueprint. Here's how much you can learn from a single read-only permission.
An executable came back to our honeypot yesterday, two days after the last one. It came from a neighboring address sharing the same leading digits as the distribution host from two days earlier, with the entire file-naming convention swapped out. Not one of the twelve malicious file names we had written down in advance matched. What we got instead was a five-second routine repeated three times in one day.
The ER doesn't call people in the order they arrived. It calls them in order of danger. When your vulnerability list runs thousands of lines long, that sorting is what EPSS does. Part 3 of the RMF·NIS2 series.
Yesterday our honeypot was the busiest it has been since we started recording. 3,553 sessions, 7,574 commands. And yet not a single malicious executable came down to the server, and one session matched a record from four days earlier on seven separate values. The only difference was how long it took.
A health checkup report doesn't say 'you're healthy' — it lists numbers and grades. Risk assessment works the same way. Here's how NIST SP 800-30 and ISO 27005 turn risk into numbers. Part 2 of the RMF·NIS2 series.
Yesterday a new address showed up on our honeypot — one that had not appeared once in five days of records. But the folder name and the file-naming scheme were identical to an older address. Here is why we recognized a first-time address on day one, and what that does and does not let us say.
Like the hygiene grade posted on a restaurant door, the EU judges security by paperwork, not by what you say. What NIS2 is, and why the word 'evidence' comes up at the contract table. Part 1 of the RMF·NIS2 series.
Four completed telnet sessions from yesterday's honeypot matched right down to the numbers: 31 commands, 1 download, dwell time in the 68-second range. Telnet has no client fingerprint, so the grouping method we normally rely on didn't apply. Here's what we grouped them by instead, and exactly how far that grouping goes.
A single 63-second session left behind zero samples and planted nothing but an SSH public key. The same key hash showed up three days running — 8/16, 8/17, 8/18 — and the number of sources planting it grew from 10 to 12 to 16. Here's how to notice a compromise when there's no file for antivirus to catch.
Three days straight the completed sessions were Telnet; on the fourth day it switched to SSH. The intruder stayed 3.6 seconds, and ran exactly one command.
