A 9.5-Second Robocall Came Through Four Times in 1 Minute 40 Seconds

Suppose you get a call from a number you don’t know. You pick up, and it isn’t a person — it’s a recording. “Hello, valued customer. Please download and install the app from the address below.” You hang up, and in less than a minute it comes again. Same voice, same sentences. Even the same length.

A call placed by a person is a little different each time. They speed up, they sigh, they swap a word. A recording doesn’t do that. No matter how many times you play it, the same sentences finish inside the same number of seconds.

Yesterday our server got four calls like this. We picked up all four times, and all four times we did exactly what the recording told us to do. Today’s story is about the length of that recording.

Our Phone Does Everything It’s Told

FACT We run a honeypot. A honeypot is a decoy server deliberately left loosely open. We keep it there to watch who comes and what they do. In phone terms, it’s a phone that answers every unknown number and does everything it’s asked. In exchange, we write down everything said on the call. What follows is not actual damage but an observation record.

FACT There are two servers. The first (sensor 01) can actually be entered if the password matches. It even records what the party who got in did. The second (sensor 02) never opens. It only writes down who knocked on which door and how many times. Today’s protagonist came from the first server.

Four Calls, Looked at Second by Second

FACT The party placing the calls is ATK-713362. Names beginning with ATK- are aliases we assign to each source. The actual address is written with the trailing digits hidden, like 172.166.x.x.

FACT This source came in over Telnet. Telnet is an old passageway for entering a distant computer and typing commands. It does not wrap what passes through in encryption. Even passwords are visible as-is. These days it mostly survives on routers, internet cameras, and older equipment.

Lining the four calls up side by side looks like this. Scan the “call length” column up and down.

FACT All four logins succeeded. That means the phone was answered. From the start of the first call to the end of the last took 1 minute 40.73 seconds. There were 36 commands in all, and 4 file downloads.

FACT Look at the call lengths. The first and second are both 9.54 seconds. The third and fourth are both 9.68 seconds. The difference between the two pairs is 0.14 seconds. About the span of a single blink.

FACT Nine commands in 9.54 seconds is almost one line per second. That is a tight pace for reading a command line, thinking, and typing it by hand. And yet that pace was the same across all four calls.

INFERRED If a person had typed it directly, it would be hard for four calls to line up this closely in length. It is likely a tool that automatically replays a fixed sequence. It is closer to a recording played four times.

FACT All four calls were classified with the same four behaviors: system reconnaissance, file download, granting execute permission, and execution after download.

• System reconnaissance is looking around to see what kind of machine the computer it entered is.
• Granting execute permission is attaching the mark “this is a program that may be run” to the file it received.
• Execution after download is actually running the file it received.

INFERRED What we don’t know is in what order these four happened. The classification record does not carry order. It’s tempting to write “looked around → downloaded → marked → ran.” But all we can say is “all four were observed.” Quietly hanging someone else’s key on the door (persistence) or erasing records (trace deletion) did not appear in this source’s calls. So today’s story goes only as far as getting in, downloading, and running.

The Address the Recording Gave Out

FACT The file pulled down on every call is wget.sh. It is a shell script. A shell script is a note with several command lines written in a single file. Its size is 1,670 bytes. That’s about 1,670 English characters. Roughly the length of ten text messages (160 Latin characters each).

FACT This note came down from hxxp://143[.]20[.]154[.]42/bins/wget.sh. A place that hands out files like this is called a distribution point. The hxxp at the front of the address and the [.] in the middle are deliberately broken notation so that it won’t connect even if clicked by mistake.

FACT Over the course of yesterday this note was downloaded 15 times. All 15 times, the one doing the downloading was ATK-713362 alone. In effect, the same robocall read out the same address fifteen times.

FACT But the four calls in the table above account for 4 downloads. That’s a gap of 11 from 15.

INFERRED Judging by that gap, this source appears to have placed more calls beyond the four we focused on. How many more and when are not in the record.

FACT So what came after the note? Usually a note like this serves as an installation guide that fetches the real program (an executable). Yet among the 5 kinds of files left on the first server yesterday, there was not a single executable. The contents of the note are not in the brief either. So we cannot know what this note was going to call next.

FACT The alias ATK-713362, the distribution point 143[.]20[.]154[.]42, and the note’s hash 81a7cdbb… are all values that never once appeared in the 34 briefs accumulated since August 16. A hash is a unique number computed from a file’s entire contents. Change one character and you get a completely different value.

FACT One more thing to note. The incoming address (172.166.x.x) and the distribution point (143[.]20[.]154[.]42) differ in their first two octets. On September 7, September 8, September 15, and October 6, the pattern where the leading parts of the two matched did show up. This time is not that pattern.

A Call With No Caller ID

FACT Programs coming in over SSH reveal a combination of settings when they connect. We use that to build a connection fingerprint (hassh) and group identical tools together. But Telnet produces no such fingerprint. It remains a blank field in the record too.

INFERRED In phone terms, it’s a call with no caller ID. So today we look at this source not by its tool but by the shape of the call. 9.5 seconds, 9 commands, 1 file. That this shape repeated four times is all we have.

FACT The connection port (the door number inside a computer) was not recorded per session. Across the whole day, the count for port 2223 (341) and the Telnet count (341) are exactly the same.

INFERRED So we matched these calls to door 2223 as well. It is an inference drawn from matching numbers.

Laid Out in Time Order

Yesterday’s record laid out in time order looks like this. Times are in Coordinated Universal Time (UTC). For Korean time, add 9 hours. Pay attention to the seconds between the start and end of the top four lines.

1. 11:04:55Z ~ 11:05:04Z (KST 20:04)
   FACT ATK-713362(172.166.x.x) Telnet login succeeded. 9.54 s · 9 commands · 1 download · record density 18. An input record (TTY) exists but its contents are not in the brief
2. 11:05:20Z ~ 11:05:30Z (KST 20:05)
   FACT 15.95 s after the previous session ended, the same alias logged in successfully again. 9.54 s · 9 commands · 1 download. Same length as the first session down to the second
3. 11:05:58Z ~ 11:06:07Z (KST 20:05)
   FACT Third session. 27.83 s gap from the previous one. 9.68 s · 9 commands · 1 download
4. 11:06:26Z ~ 11:06:36Z (KST 20:06)
   FACT Fourth session. 18.51 s gap from the previous one. 9.68 s · 9 commands · 1 download. Over the 1 minute 40.73 seconds from the start of the first session: 36 commands, 4 downloads
5. Common to all 4
   INFERRED The behavior classifications of the four sessions are the same. But this list does not carry execution order. We cannot write that it ran 'reconnaissance → download → permission → execution'; we can only say that the four stages were observed
6. Common to all 4
   INFERRED The session lengths (9.54 · 9.54 · 9.68 · 9.68 s) and the command count (9) repeat. It is likely not typed directly by a person but a tool that automatically replays a fixed sequence
7. Whole day
   FACT wget.sh (81a7cdbb…, 1,670-byte POSIX shell script) was downloaded 15 times from hxxp://143[.]20[.]154[.]42/bins/wget.sh. The only one downloading it was ATK-713362
8. Whole day
   INFERRED There is a gap of 11 between the 15 times and the 4 downloads in the four sessions above. This alias appears to have opened more sessions outside the top 5. How many times and when are not in the record
9. Whole day
   FACT Among the 5 kinds of files stored on the first server, there is no executable. What wget.sh was going to fetch next cannot be known because the script contents are absent
10. 13:08:32Z ~ 13:08:54Z (KST 22:08)
    FACT The session with the highest record density (42) was a Telnet session from ATK-DE3709(123.184.x.x). 21.91 s · 22 commands · 11 downloads · a single behavior classification, 'impair defenses'. The file downloaded was the 1-byte file (01ba4719…) already present in 19 archived briefs
11. Archive comparison
    FACT The incoming address (172.166.x.x) and the distribution point (143[.]20[.]154[.]42) differ in their first two octets. This is not the 'matching leading parts' pattern of 9/7 · 9/8 · 9/15 · 10/6

FACT The four lines above all finished within 10 seconds. All four calls together come to 38.44 seconds. Less than half of the 1 minute 40 seconds. The remaining 1 minute 2 seconds was the span between hanging up and calling again.

FACT Look at the second line from the bottom too. ATK-DE3709 was yesterday’s most densely recorded session. But the file it took away was 1 byte — exactly one character long. And it was a file that has already appeared in 19 briefs. So we left it out of today’s lead role.

All of Yesterday

Now let’s widen the view to the whole day on the first server. The “for comparison” column on the right makes the numbers tangible.

FACT SSH is a passageway that does the same job as Telnet. The difference is that it wraps the contents in encryption. The Telnet side came to 341 for the day, not even one in ten of the total. And yet today’s protagonist came in through the smaller side.

FACT Commands classified by intent numbered 3,532. Of those, 3,161 (89.5%) were system reconnaissance. That means nine times out of ten they came in and only looked around. ‘SSH key planting’ came to 35. That is quietly hanging a key that lets you get in without a password. The same 389-byte key (a8460f44…) was downloaded 33 times. That’s about the size of two or three text messages. This is a number from other connections, not today’s protagonist.

FACT Unique sources across both servers come to at most 494. We write only ‘at most’ because we cannot tell which ones came to both servers. We do not add session counts because the two servers count in different units.

Are You Using This Password?

FACT Of the ID/password combinations tried yesterday, 19 kinds are reproduced verbatim in this post. The criterion is one thing. Only combinations entered identically from three or more different IPs get written down. If several places carry the same number around identically, it is likely a factory default belonging to no one. Look at the numbers in the third column.

FACT Combinations that fell short of this criterion are only counted. Yesterday there were 3,212 kinds. They could have leaked from someone’s real account, so we do not write the values. For each combination written in the table, there were roughly 170 we did not write.

FACT 3,212 kinds is the highest number among the 34 briefs. The recent trend is October 1: 1,608 kinds → October 4: 3,026 kinds → October 6: 2,213 kinds → yesterday: 3,212 kinds. About double a week ago.

FACT We do not know which of these combinations today’s protagonist used to get the phone answered. The information linking a connection to a password is not in the record.

In Front of the Second Server

FACT On the second server, which never opens, all that remains is who knocked on which door and how many times.

FACT Of the total 37,395 contacts, VNC is 96.4%. At 36,037 a day, that’s about once every 2.4 seconds. One source knocked about 600 times on average. The share of the version string 003.008 presented on connection was 98.0%. Following 63.2% on October 1 and 94.1% on October 4, it grew again.

FACT The six most frequent sources are evenly divided at 4,780–5,338 each. The six together come to 29,492.

INFERRED Judging by how even the numbers are, it looks like scanners with the same configuration split the work similarly among themselves. But which door these contacts were aimed at is not in the record.

FACT On the SMB side, apart from a single SMB 2.???, only SMB1-family names appeared. SMB1 is a very old form of Windows file sharing.

INFERRED It looks like requests hunting for servers that still accept this outdated form.

FACT The tag (cookie) attached when connecting over RDP came to 655. This tag is text the other party fills in freely, so we do not group it with a specific tool. All 4 kinds of files left on this server are hashes we have seen before. Only the sending alias ATK-E2D202 was a value we had not seen.

Values That Appeared Yesterday — Write These Down

We reproduce these as-is so you can use them for defense. Values like these are called IOCs (indicators of compromise). They are markers that say “if you see this value, be suspicious.” Click a value to copy it. Addresses are left in their broken notation. Look at ‘the one downloading it’ in the description column.

FACT Both lines are values seen for the first time yesterday. Because only one place downloaded it, these two lines are in effect the signature of a single source. The new distribution point 143[.]20[.]154[.]42 is subject to C-TAS reporting. C-TAS is the threat information sharing framework of the Korea Internet & Security Agency (KISA). What has been confirmed is only that transmission succeeded. Whether it was actually ingested on KISA’s side has to be confirmed separately.

Mapping the Attacker’s Techniques to the International Classification

MITRE ATT&CK is an international list that assigns a number to each attack technique. Matching yesterday’s observed behaviors to those numbers looks like this. Click an ID to go to the original description.

• T1078Valid Accounts — presumed use of a default account. Which credentials ATK-713362 came in with is not in the recordINFERRED
• T1082System Information Discovery — behavior classification 'reconnaissance — system'INFERRED
• T1105Ingress Tool Transfer — behavior classification 'file download', wget.sh 15 times in a dayINFERRED
• T1222.002Linux and Mac File and Directory Permissions Modification — behavior classification 'granting execute permission'INFERRED
• T1059.004Command and Scripting Interpreter: Unix Shell — behavior classification 'execution after download', the downloaded file being a shell scriptINFERRED

FACT All five lines are [INFERRED]. What we have in hand goes as far as behavior classifications, counts, and files. The original text of the 36 command lines is absent. So assigning numbers is always interpretation. The line to watch is T1105. That number is the stage of fetching the note from the address the recording read out.

There Was a Shape Like This Before

FACT Mirai botnet (2016). An incident in which IoT devices were logged into with Telnet default accounts and infected. IoT devices are small internet-connected devices like routers and CCTV cameras. A botnet is a swarm that controls huge numbers of such infected devices all at once. (Source types: government security alert US-CERT TA16-288A · academic paper USENIX Security 2017 ‘Understanding the Mirai Botnet’)

INFERRED The flow of coming in over Telnet, downloading a file from outside, attaching an execute mark, and running it is the same. Combinations in the password table above like root/vizxv and root/anko are also the same form as values in the default account list of Mirai’s public source. But we could not confirm the contents of yesterday’s note or the program that came after it. So we do not judge this to be the Mirai family.

So What Should You Do

Coming back to the phone story, the things to do gather into three. Make it so unknown numbers don’t get answered. Even if they do, don’t leave the lock password at the factory default. Don’t let an app be installed from the address the recording read out. Let’s take the five items the brief listed in turn.

FACT 1. An administration port (Telnet) was opened directly to the internet · high likelihood Over the day there were 341 Telnet contacts. Among them, one source succeeded at logging in four times within 1 minute 40 seconds.

INFERRED If a production server had Telnet open, it would have received the same calls the same number of times. Telnet doesn’t wrap its contents, so the account information passing through is exposed as-is. Turning Telnet off in a router’s or camera’s settings screen means the phone never rings in the first place.

FACT 2. Default accounts and easy passwords are used as-is · high likelihood admin/admin came from 14 places; root/admin, root/123456, and root/12345 from 5 places each; root/root and guest/guest from 3 places each.

INFERRED Devices using a password in this table get knocked on by different sources with the same combination on the same day. Once it opens, reconnaissance, downloading, marking, and execution finish within 10 seconds, as happened yesterday. But we do not know which combination yesterday’s protagonist came in with.

FACT 3. Password login is allowed and key authentication is not used · high likelihood 3,436 login attempts, and 3,212 kinds of combinations whose values alone we did not write down.

INFERRED Key authentication is a method of getting in with a key file that exists only on your own computer, instead of a password. A server that opens with a password alone has to face this entire list. And Telnet has no key method at all. As long as Telnet is in use, this item applies as well. If an employee account of ours is mixed into a leaked list, it could match on the first try rather than after thousands.

FACT 4. The server’s outbound connections are not blocked · high likelihood Over the day, ‘file download’ was classified 65 times and ‘execution after download’ 28 times. wget.sh was downloaded 15 times.

INFERRED Phones have a setting called “block installation of apps from unknown sources.” Servers have the same mechanism. It blocks the server from connecting to just any outside address. Had that been in place, even if the recording read out the address fifteen times, the flow would have broken at the stage of fetching the note. What the note was going to call next, we could not confirm.

FACT 5. Records are not collected off-box · medium likelihood Across the whole day, ‘trace deletion’ occurred 37 times and ‘impair defenses’ once. Neither appeared in today’s protagonist’s calls.

INFERRED That’s why it’s ‘medium’. It is a risk from other sources targeting the same server. If you keep call records only inside the phone, it’s over the moment they’re erased. Only records sent outside in real time remain. The reason we could say “a value absent from the 34 briefs” yesterday was also that past records had been accumulated separately.

We also made a 60-second video about the same day. The video focused on one thing: “a first-time visitor came and went 15 times.” This post unfolds how many seconds that visitor stayed each time and what they took away.

What We Don’t Know

This is where this blog differs from others. There is as little that we know as there is that we don’t.

About the four calls

• [CANNOT CONFIRM] We do not know which ID and password ATK-713362 came in with. Connections and passwords are not linked.
• [CANNOT CONFIRM] We do not know the contents and order of the 9 commands typed each time. Behavior classification is only a grouping of ‘what was being attempted’, not execution order.
• [CANNOT CONFIRM] Of the 15 wget.sh downloads, we do not know when, or across how many connections, the 11 not captured in the four calls occurred.
• [CANNOT CONFIRM] The connection port per session is not in the record. Treating Telnet as door 2223 is an inference from matching the day’s numbers.

About the note

• [CANNOT CONFIRM] We do not know the contents of wget.sh. Nor do we know what file this note was going to call next.
• [CANNOT CONFIRM] No executable was left on the first server. We cannot distinguish whether the next stage failed, took a different path, or never existed.
• [CANNOT CONFIRM] For the C-TAS report, only transmission success was confirmed. Whether it was ingested on KISA’s side has to be confirmed separately.

About other records from the same day

• [CANNOT CONFIRM] We do not know what ATK-DE3709’s ‘impair defenses’ was trying to turn off. Nor do we know the purpose of downloading a 1-byte file 11 times.
• [CANNOT CONFIRM] We do not know why the VNC 003.008 share grew from 63.2% on 10/1 → 94.1% on 10/4 → 98.0% yesterday. We cannot distinguish whether the other party’s tool changed or our own configuration changed.
• [CANNOT CONFIRM] On the second server, the number of sources that knocked on several doors together cannot be counted. The per-source records do not distinguish which door. Writing 0 would read as ‘there were none’, so we leave it blank.

About the nature of the numbers

• [CANNOT CONFIRM] Among the 3,212 kinds whose values we did not write, we do not know how many are actually leaked accounts. ‘May have leaked’ is a publication criterion, not a judgment.
• [CANNOT CONFIRM] The vulnerability statistics (7,679 CVEs · 413 KEV with confirmed exploitation · 101 confirmed ransomware) are background information based on KISA notices. They do not connect directly to yesterday’s honeypot observations.
• [EXCLUDED] The 12 indicators that only emerge after decompression (31[.]77[.]227[.]121/bins/) are values that have repeated since the August 16 brief, so we did not use them as new material for yesterday.

What we do not judge at all

• Carrier/organization (ASN · ISP) — we have no relevant database. We do not infer.
• Geographic location — unknown for the same reason. IP geolocation is not grounds for identifying who did something in the first place. This post does not name any country, company, or individual as the attacker.
• Whether VPN · Tor · cloud — we have no means of determining this.
• VirusTotal — not integrated. For sample classification we use MalwareBazaar tags.
• Client program string (User-Agent) — neither server is a web (HTTP) server. The first is SSH and Telnet; the second is SMB, RDP, VNC, MSSQL, LDAP, and ADB.
• Vulnerability number (CVE) linkage — SSH and Telnet attacks mostly do not reference a specific vulnerability. The second server is likewise at the stage of matching connection rules.

At 8 p.m. yesterday evening, four calls came from the same number. All four were about 9.5 seconds. Each time it said nine words and had the same note fetched from the same address. That note was downloaded fifteen times in a day, and the one downloading it was that one number.

A robocall does not discriminate among those it reaches. Whoever answers, it plays the same sentences at the same length. So the way to stop it does not lie in recognizing the other party either. Turn Telnet off so the phone doesn’t ring, and keep the server from accepting from just any address. If you have an old router or camera at home, today is the day to check Telnet first in the settings screen.

The observation date is October 8, 2026 (a single day in UTC), and this post was compiled the following day. Source IPs were carried over in the masked form they appear in the brief (172.166.x.x, 123.184.x.x) and were not restored. Addresses were kept defanged (hxxp://, [.]) in both the body and the IOC block so they cannot be connected to by mistake. Credentials were quoted verbatim for only the 19 combinations repeatedly observed from 3 or more different IPs, and for the remaining 3,212 kinds only the count was disclosed, not the values. Items for which we have no means of measurement — carrier, nationality, whether a VPN was used — were not inferred and were left as “we don’t know.”