Showing posts with label spamtraps. Show all posts
Showing posts with label spamtraps. Show all posts

Wednesday, January 1, 2025

A Suitably Bizarre Start of the Year 2025

© 2025 Peter N. M. Hansteen

Already somewhat blasé from life in the honeypots, yours truly registers an even more bizarre level of events after a some routine logs spelunking

If you're reading this soon after the piece is published, 2025 is a fresh new year, and I would like to wish you all the best for the year ahead.

Then I want to relate what happened here (or rather at the Internet facing network interface of the server in question) during the initial few hours of the new year 2025.

Note: This piece is also available without trackers but classic formatting only here.

If you are a returning reader, you will be familiar with my ongoing experiment and studies of Internet miscreants and how to thwart their efforts as effectively as possible while expending no more than absolutely necessary in terms of time or energy on our end. Central to those efforts are the greytrapping based blocklist and the ever-growing list of spamtraps, which late in 2024 passed the half a million mark, right now numbering 568212 entries of known bad, not deliverable email addresses in our domains (almost certain to have increased by the time you read this).

I have written about the daily maintenance tasks for the lists, such as they are, in previous entries such as the list homepage pointed to in the previous paragraph and the traplist ethics page as well as the blog post Goodness, Enumerated by Robots. Or, Handling Those Who Do Not Play Well With Greylisting (November 2018, also here) or for that matter the piece I wrote about the arrival of the three hundred thousandth spamtrap, The Things Spammers Believe - A Tale of 300,000 Imaginary Friends (also here).

All of those pieces show that the original emphasis was to keep the working environment sane for the local users, and the fact that I could generate resources that I could make available for others to use was really just a byproduct of that work, while of course a welcome one for its users.

After some years, and certainly around the time the list of spamtraps had reached the hundreds of thousands, the "salt the mine and poison the well" part (the fourth principle listed on the ethics page) part had subtly slid more into central focus, and I was adding incrementally to my arsenal of scripts and one-liners to expand the list of "imaginary friends" as I came to think of new angles.

Most of these would involve fishing out potential local parts to (the parts before the '@') from the din of spamd log entries. Some of these are hinted at in Harvesting the Noise While it's Fresh, Revisited (also here).

The pace of growth for the spamtraps list did pick up as a consequence, and as I reported in a fediverse post, the total made the half millon mark at some point in December of 2024.

Part of the updating procedure is to search logs for addresses not already in the spamtraps list. One of the things I tend to do after extracting the list of addresses somebot tried to deliver to and that we have not been included already in the spamtraps is to extract the log entries involving those supposedly new addresses for further processing. The output from that grep centered one liner from the overnight run taken during the late morning of January 1st, 2025 can be found here.

Take a few moments to look at that one if you want.

You will be looking at the output of a series of grep searches for destination addresses.

The bulk of the data shows that hosts not in our local networks tried to deliver largish numbers of messages to third party domains such as qq.com and gmail.com, using our spamtrap addresses as the purported sender addresses, only of course to be added to the set of greytrapped addresses.

Making up addresses in other people's domains to use as From or Reply-to addresses on your spam messages is not a new thing, of course, as long as you do not care to get any feedback on what actually happened with those attempted deliveries.

What baffled me more than a little was that the addresses were apparently used in the exact sequence they would have been found at this site after a fairly recent update run.

Apart from the sheer number of addresses and their freshness, the only item of interest was that behind each of the IP addresses involved there appears to be a number of hosts -- likely virtual machines -- with distinct identifiers in their HELO/EHLO sequence, likely generated strings of a handful of characters such AXBPvDt.

These quasi-random, generated IDs were of course soon made into local parts for new spamtraps. As would, at times some other items it is possible to extract from logs with common unix commands.

So as a start to the new year, this was surprisingly fitting. The general insanity we have seen in this particular field continues, but appears to have reached a new level at the tail end of the tumultous year just past, possibly heading for new levels still.

Good night and good luck.

Addendum 2025-01-13

For those so inclined, it is perhaps worth noting that after a bit of pondering some time after writing this other piece (also here), I started looking at extracting other items from the spamd logs log entries.

I ended up with extracting the local parts for new spamtraps from the purported sender addreses of entries for trapped delivery attempts some time mid-2024. This made for a significant increase in the number of new imaginary friends, and by the final months of that year I had also started extracting similarly from the string offered by the spam senders as their host name in the EHLO/HELO exchange, which of course swelled the population further.

The effect is clearly to be seen in the file that records the number of spamtraps added per year, updated via trivial scriptery roughly daily.

I hope this article and its addenda helps inspire others in our efforts of green cybercrime prevention by giving the actually intelligent detection methods less work to do.

Addendum 2025-03-20

Only a couple of weeks after the previous addendum was written, it was outdated. Due to some trivial resource restraints lead do a slightly different organization of the log data, now as per year files up to and including 2024, and per month from 2025 onwards, in this directory, while the main traplist page still has the list of spamtraps itself in one piece.


Upcoming Events to watch for:
BSDCan 2025 June 11 through June 14th 2025, in Ottawa, Canada. The Call for papers is active, with February 12 2025 as the deadline for submissions.

EuroBSDCon 2025 September 25-28, 2025 in Zagreb, Croatia.

Wednesday, January 24, 2024

A Simpler Life: Trapping Spambots Based on Target Domain Only

© 2024 Peter Hansteen

If you want to hurt spammers, you can get away with maintaining a list of domains you want to receive mail for in your spamd.alloweddomains.

I have at times written at length about spam countermeasures, and I must take responsibility for sometimes going into too much detail about options and nuances that are on offer if you enjoy fighting back at the spammers and watching them fail.

So it was a bit refreshing to be reminded that you can, in fact, make good use of the OpenBSD spam deferral daemon spamd(8) without maintaining lengthy lists of anything or even pulling in externally generated data, unless you want to.

The key to the simplest version of spam fightng life with spamd(8) is to put a list of the domains you do want to receive mail for in a file called spamd.alloweddomains, in /etc/mail/ if your system runs OpenBSD, and in /usr/local/etc/spamd/ if you are setting up on a FreeBSD system. Make sure the file is readable for the user that runs the spamd(8) process, and restart or reload your spamd.

The result will be that any host that tries to deliver mail to addresses that are not listed in spamd.alloweddomains will be greytrapped and added to your spamd-greytrap. The host will be stuttered at until it gives up.

If you have no use for external blocklists or allowlists, you can even empty spamd.conf if you want (or comment out any content with # hash characters). The spamd process will run fine without one.

Here is an example lifted from my nxdomain.no server recently:

Jan 23 15:18:27 skapet spamd[84681]: (GREY) 193.222.96.180: <test@bsdly.net> -> <director_ericmoore@hotmail.com>
Jan 23 15:18:27 skapet spamd[4259]: Trapping 193.222.96.180 for tuple 193.222.96.180 win-4tti4dh7sgh.domain <test@bsdly.net> <director_ericmoore@hotmail.com>
Jan 23 15:18:27 skapet spamd[4259]: new greytrap entry 193.222.96.180 from &kt;test@bsdly.net>M to <director_ericmoore@hotmail.com>, helo win-4tti4dh7sgh.domain

Needless to say I am not Microsoft, so hotmail.com is not in nxdomain.no's /etc/mail/spamd.alloweddomains.

If you want to pull in external blocklists or pass lists, you can pull in a spamd.conf with content. One useful starting point is the default version, or if you want you can stat with mine, which pulls in some other resources.

Finally, if you want to run a mail service, do yourself a favor and not only read the relevant man pages, but also sign up for the mailop mailing list, read the Mailop FAQ and the Best Services for Servers document.

Thanks to Michael Lucas, who wrote a message on the mailop mailing list that spurred me to write this article.


If you want to dig deeper in matters related to spam, greytrapping and the OpenBSD spamd(8) program in general, here are a few resources for you:

In The Name Of Sane Email: Setting Up OpenBSD's spamd(8) With Secondary MXes (also with trackers)

Badness, enumerated by robots (also with trackers)

Goodness, Enumerated by Robots. Or, Handling Those Who Do Not Play Well With Greylisting (also with trackers)

Three Minimalist spamd Configurations for Your Spam Fighting Needs (With Bonus Points at the End) (also with trackers

Maintaining A Publicly Available Blacklist (tracked only, sorry)

Effective Spam and Malware Countermeasures - Network Noise Reduction Using Free Tools (also tracked only, sorry)

The Book of PF, 4th edition

Sunday, December 25, 2022

The Despicable, No Good, Blackmail Campaign Targeting ... Imaginary Friends?

© 2022 Peter Hansteen

Natalia here speaks to our imaginary friend 185.150.184.92

In which we confront the pundits' assumption that the embarrasment-based extortion attempts would grow more “sophisticated and credible” over time with real data.

It's a problem that should not exist. 

It's a scam that's so obvious it should not work.

Yet we still see a stream of reports about people who have actually gone out and bought their first bitcoins (or more likely fractions of one) in order to pay off blackmailers who claim to have in their possesion videos that record the vicim while performing some autoerotic activity and the material they were supposedly viewing while performing that activity.

And occasionally one of those messages actually find their way to some pundit's inbox (like yours truly), and at times some of those pundits will say things like that those messages represent a real problem and will evolve to be ever more sophisticated.

Note: This piece is also available, with more basic formatting but with no trackers, here.

I am here to tell you that

  1. That incriminating video does not exist, and
  2. The pundits who predicted that those scams would evolve to become more sophisticated were wrong.

If you stumbled on this article because one of those messages reached you, it's safe to not read any further and please do ignore the extortion attempt.

I wrote a piece in 2019 The 'sextortion' Scams: The Numbers Show That What We Have Is A Failure Of Education, also available without trackers, where the summary is,

Every time I see one of those messages reach a mailbox that is actually read by one or more persons, I also see delivery attempts for near identical messages aimed at a subset of my now more than three hundred thousand spamtraps, also known imaginary friends.

Over the years since the piece was originally written, I have added several updates — generally when some of this nonsense reaches a mailbox I read — and while I have seen the messages in several languages, no real development beyond some variations in wording has happened.

Whenever one of those things does reach an inbox, my sequence of actions is generally to save the message and add it to the archive, see if the sending IP address has already entered the blocklist that is later exported and add it by hand if not. Then check if the number of trapped addesses has swelled recently by checking the log file from the export script

$ tail -n 96 /var/log/traplistcounts

See if there is a sharp increase since the last blocklist export

$ doas spamdb | grep -c TRAPPED

Then check for related activity in the log

$ tail -n 500 -f /var/log/spamd

Check for the full subject in the same log file

$ grep "You are in really big troubles therefore, you much better read" /var/log/spamd

Then check older, archived logs to see how long this campaign has been going on for

$ zgrep "You are in really big troubles therefore, you much better read" /var/log/spamd.0.gz

This time, the campaign had not gone on for long enough to show traces in the older archive, so I go on to extracting the sending IP addresses

$ grep "You are in really big troubles therefore, you much better read" /var/log/spamd | awk '{print $6}' | tr -d ':' | sort -u

Check for activity from one of the extracted addresses

$ grep 183.111.115.4 /var/log/spamd | tee wankstortion/20221123_trapped_183.111.115.4.txt

Extract the sender IP addresses to an environment variable to use in the next oneliner,

$ grep trouble /var/log/spamd | awk '{print $6}' | tr -d ':' | sort -u | grep -vc BLACK | tee -a wankstortion/20221123_campaign_ip_addresses.txt

which will record all activity involving those IP addresses since the last log rotation:

$ for foo in $troubles ; do grep $foo /var/log/spamd | tee -a wankstortion/20221123_campaign_log_extract.txt ; done

You will find all those files, along with some earlier samples, and by the time you read this, possibly even newer samples, in the archive.

When something of the sort inboxes, I probably will go on adding to the archive, and if I have time on my hands, also run similar extraction activities as the ones I just described. But unless something unexpected such as actual development in the senders' methods occurs, I will not bother to write about it.

The subject is simply not worth attention past persuading supposed victims to not bother to get bitcoins or spend any they might have to hand. None of my imaginary friends have, and they are just as fine as they were before somebot tried to scam them.

Good night and good luck.


You might also be interested in reading selected pieces via That Grumpy BSD Guy: A Short Reading List (also here).

At EuroBSDcon 2025, there will be a Network Management with the OpenBSD Packet Filter Toolset session, a full day tutorial starting at 2025-09-25 10:30 CET. You can register for the conference and tutorial by following the links from the conference Registration and Prices page.

Separately, pre-orders of The Book of PF, 4th edition are now open. For a little background, see the blog post Yes, The Book of PF, 4th Edition Is Coming Soon. We are hoping to have physical copies of the book available in time for the conference, and hopefully you will be able to find it in good book stores by then.


Sunday, April 3, 2022

Spammers in the Public Cloud, Protected by SPF; Intensified Password Groping Still Ongoing; Spamware Hawked to Spamtraps

This past week was truly one for the blooper reel. A public cloud service provider let the great unwashed into the address ranges published as safe mailers via their SPF records, with hilarious if rather predictable results. Next up, we find an intensive advertising campaign for spamware aimed at our imaginary friends. And the password guessing aimed at an ever-expanding dictionary of non-existing users continues.

To the rest of the world, bsdly.net is known variously as a honeypot, a source of various kinds of blocklists or a frequent target of domain joejobs that contribute to the ever-expanding list of imaginary friends also know as spamtraps.

To me and a very small set of other people, it's home on the net, providing a set of services we need fairly painlessly on an OpenBSD platform that rarely requires much work besides the odd pkg_add -u -D snap followed by sysupgrade -s (yes, we jump from snapshot to snapshot on this one).

Then the past week served us with three separate events that, while actually harmless to our side, together serve to show that a certain subset of humans would perhaps be better diverted to activities that do not involve computers.

Note: This piece is also available, with more basic formatting but with no trackers, here.

A Public Cloud Provider Let Spammers Set Up Within Their Published SPF Ranges

The first event started on Tuesday. While looking for something else entirely in my mail server logs, I noticed an unusually high number of delivery attempts to what definitely looked like spamtraps reaching the actual mail server. The earliest entry was from that morning:

2022-03-29 06:28:31 H=ministeriodesanidad34.yomevacunoseguro.com [20.104.226.220] X=TLS1.2:ADH-AES256-GCM-SHA384:256 CV=no F=<root@ministeriodesanidad34.yomevacunoseguro.com> rejected RCPT <claus-leba@ehtrib.org>: Unknown user

There were several thousand entries of that type (full log here, extracted source IP addresses here). My initial impulse was of course to check the logs to see how they got past spamd in the first place. Oddly, I found no trace of any activity involving spamd and a random sampling of those IP addresses. That would in turn indicate that they had been pass-listed, most likely by being included in the permanent nospamd pass list, which we generate here mainly based on the published SPF records of domains we need to communicate with.

Again taking a random subset of the extracted IP addresses and using whois identified the IP address range owner as a large cloud services provider that among other things also provide hosted or hybrid on premise plus hosted email service. This in turn means that domains that use those services also include large segments of that provider's IP address ranges in their SPF records. Not quite knowing what to do I tweeted,

In addition to tweeting and looking for feedback (which was not huge but dominated by Y answers), I notified the relevant abuse@ address by mail, including links to the log data and the IP addresses.

I also tweaked the log reader hinted at in this earlier piece so any attempt at delivering mail from that domain in the future will put the sending IP address safely away both in the spamd blocklist and in the safety of a table that is subject to block drop quick from for six weeks after the activity stops, and exported to downloadable blocklists as described in the article I referenced earlier.

The abuse@ handlers at the company I am not naming explicitly here (yes, there's a unix command you can use to find out who if it matters to you) were quite responsive and said that the activity seemed to be coming from their public cloud section, and yes they were forwarding my data to their internal CERT. As a followup I suggested to them that using our slowly expanding list of spamtraps in their outbound filtering might be a good idea if they intend to offer SMTP-for-hire in the future.

What seems to have happened is that the miscreants here set up using a range of the provider's services including domain registration, DNS hosting, and judging from the consistent use of root@ as the sender addess, set up some number of Linux virtual machines to do the spamming.

Before the activity stopped later in the week, we identified two more campaigns that fit the pattern. The data can be found here: log entries and IP addresses for the second wave, log entries and IP addresses for the third. Each of the campaigns appear to have stopped shortly after their domains were de-registered. I never saw the contents of the messages since not a single one appears to have inboxed here.

The episode has a few teachable items: First, that some subset of our list of spamtraps is indeed incorporated in the address lists used by gullible spammers and their customers, and second, that if you run a public cloud service, you need to pay attention to what your customers do and be wary of letting them use IP address ranges that have been announced as being really safe to accept mail from.

I notified the cloud provider that I would be writing an article about the events and asked them for any and all useful input they could provide. No such information has surfaced by the time of writing. If any useful information turns up from them after publication, I will of course update this piece accordingly.

A Separate Set of Spammers Market Their Spamming Software, Intensively Targeting Our Imaginary Friends

While the public cloud spammers thing was developing, I noticed another campaign that was actively targeting our spamtraps.

Sent from as far as I could tell only three IP addresses and with a total of 58 different subject lines all about spamming tools. It is possible that the campaigns did not target our spamtraps exclusively in our domains, but the log archive (1.5M compressed but expands to 40M raw) serves as testament that our imaginary friends are definitely targeted by some subset of the online marketing community, and they are pouring resources into doing that, one byte per second.

And once again, I have not seen the actual contents of the messages beyond what turns up in the logs after greytrapping kicks in. Not one of those messages found its way to an actual mailbox here.

SSH Password Groping Still High, But Bursty

As noted in a previous article, SSH password guessing activity went up significantly in the days leading up to the Russian invasion of Ukraine in February.

In addition to the data referenced directly in the article, the archived logs and the summaries of numbers of attempts per day (March and subsequent month summaries are archived along with other SSH log data, while the data for the current month so far gets updates several times a day) the number of attempts per day are consistently on a higher level than before the Ukraine war started, with a new higher intensity episode ongoing as I type.

One interesting feature of the password guessing attempts during the last few days is that they feature a much larger number of new user names attempted than usual. This means that the list of spamtraps here is now growing at the highest rate since the episode involving what was likely one or more phishing campaigns targeting Chinese users during early 2019 as mentioned in my 2019 summed up piece published at the end of that year.

If you have further data on these or similar incidents that you are able to share or if you want to look further into these and similar incidents, please let me know.

If you find any errors in the material I publish or disagree with my sentiments, or if you find this article interesting, useful or annoying, please let me know, either in comments or via email.



Friday, February 28, 2020

The 'sextortion' Scams: The Numbers Show That What We Have Is A Failure Of Education

Subject: Your account was under attack! Change your credentials!
From: Melissa <chenbin@jw-hw.com>
To: adnan@bsdly.net

Hello!

I am a hacker who has access to your operating system.

I also have full access to your account.

I've been watching you for a few months now.

The fact is that you were infected with malware through an adult site that you visited.


Did you receive a message phrased more or less like that, which then went on to say that they have a video of you performing an embarrasing activity while visiting an "adult" site, which they will send to all your contacts unless you buy Bitcoin and send to a specific ID?

Note: This piece is also available, with more basic formatting but with no trackers, here.

Note: Due to a recent incident of fatfingering, some log file extracts and other data linked from this piece are no longer readily available. The data may still be partially restorable, and I will attempt to reconstruct data for valid research purposes if there is sufficient interest.

The good news is that the video does not exist. I know this, because neither does our friend Adnan here. Despite that fact, whoever operates the account presenting as Melissa appears to believe that Adnan is indeed a person who can be blackmailed. You're probably safe for now. I will provide more detail later in the article, but first a few dos and don'ts:
  • Whatever some tempting web site tells you in a popup, unless you know what you are doing, do not install software on your devices from any other sources than the official ones. You do not need to install a new video viewer for that site or update your existing one, neither do you need to enter your administrator user name and password along with your credit card details into an unfamiliar-looking dialog box or web form.
     
  • Unless you know what you are doing, stay away from Bitcoin or other cryptocurrencies. If that message is the first you've heard of Bitcoin, you do not know what you are doing, leave it alone. As assets go, there is not much difference between financial derivatives, toxic waste and cryptocurrencies like Bitcoin, in that they should be handled with equal care and only from a distance unless you are in fact an expert in the field.
     
  • If you are not sure about either of the two bullet points before this one, please forget any shame over what you may or may not have done, and contact somebody you trust and who knows the subject better. This may be an adult such as a parent, teacher, social worker or other, a tech-savvy friend, or for that matter law enforcement such as your local police.

The important point is that you are or were about to be the victim of what I consider a very obvious scam, and for no good or even nearly valid reason. You should not need to become the next victim.

And this, dear policy makers and tech heads in general is our problem: A large subset of the general public simply do not know their way around the digital world we created for them to live in. We need to do better.

In that context I find it quite disturbing that people who should know better, such as the Norwegian Center for Information Security, in a recently issued report (also see Digi.no's article (both in Norwegian only, sorry)) predict that the sextortion attacks will become "more sophisticated and credible". Then again at some level they may technically be right, since this kind of activity starts out with a net negative credibility score.

A case in point: Some versions of the scam messages I have been able to study went as far as to claim that the perpetrators had not only had taken control of the target's device, they had even sent that very email message from there. That never happened, of course, and it would have been easy for anybody who had learned to interpret Received: headers to verify that the message was in fact sent from the great elsewhere. Unfortunately the skill of reading email headers is rarely, if ever, taught to ordinary users.

The fact that people do not understand those -- to techies -- obvious facts is a fairly central and burdening problem, and again we need to do better.

Now let me explain. Things get incrementally more technical from here, so if you came here only for the admonitions or practical advice and have no use for the background, feel free to wander off.

I know the message I quoted at the beginning here is a scam because I run my own mail service, and looking at just the logs there just now I see that since the last logs archiving rotation early Saturday morning, more than 3000 attempts at delivery of messages like the one for Adnan happened, aimed at approximately 200 non-existent recipients before my logs tell me they finally tried to deliver one to my primary contact address, never actually landing in any inboxes.

One of the techniques we use to weed out unwanted incoming mail is to maintain and publish a list of known bad and invalid email addresses in our domains. These known bad addresses have then in ways unknown (at least not known to us in any detail) made it into the list of addresses sold to spammers, and we at the receiving end can use the bad addresses as triggers to block traffic from the sending hosts (If you are interested, you can read elsewhere on this blog for details on how we do this, look for tags such as greylisting, greytrapping or antispam).

If it was not clear earlier, those numbers tell us something about the messages at hand. It should be fairly obvious that compromising videos of non-existent users could not, in fact, exist.

Looking back in archived logs from the same system I see that a variant of this message started appearing in late January 2018. The specifics of that message sequence will be interesting to revisit when the full history of sextortion (I still do not like the term, but my preferred alterantive is at risk of being filtered out by polite society-serving robots) will be written, but let us rather turn to the more recent data, as in data recorded earlier this week.

Mainly because I found the media coverage of the "sextortion" phenomenon generally uninformed and somewhat annoying, I had been been mulling writing an article about it for a while, but I was still looking for a productive angle when on Wednesday evening I noticed a slight swelling in the number of greytrapped hosts. A glance at my spamd log seemed to indicate that at least one of the delivery attempts had a line like

       I am a hacker who has access to your operating system.

Which was actually just what I had been pondering writing about.  

So I set about for a little research. I greped (searched) in my yet-unrotated spamd logs for the word hacker, which yielded lots of lines of the type

Feb 22 04:04:35 skapet spamd[8716]: 89.22.104.47: Body: I am a hacker who has access to your operating system.
Feb 22 04:17:04 skapet spamd[8716]: 5.79.23.92: Body: I am a hacker who has access to your operating system.
Feb 22 04:34:03 skapet spamd[8716]: 153.120.146.199: Body: I am a hacker who has access to your operating system.
Feb 22 04:40:30 skapet spamd[8716]: 45.181.93.45: Body: I am a hacker who has access to your operating system.
Feb 22 04:55:04 skapet spamd[8716]: 93.186.247.18: Body: I am a hacker who has access to your operating system.
Feb 22 05:09:39 skapet spamd[8716]: 123.51.190.154: Body: I am a hacker who has access to your operating system.
Feb 22 05:13:22 skapet spamd[8716]: 212.52.131.4: Body: I am a hacker who has access to your operating system.
Feb 22 05:38:02 skapet spamd[8716]: 5.79.23.92: Body: I am a hacker who has access to your operating system.
Feb 22 05:44:39 skapet spamd[8716]: 123.51.190.154: Body: I am a hacker who has access to your operating system.
Feb 22 06:00:30 skapet spamd[8716]: 45.181.93.45: Body: I am a hacker who has access to your operating system.

(the full result has been preserved here). Extracting the source addresses gave a list of 198 IP addresses (preserved here).

Extracting the To: addresses from the fuller listing yielded 192 unique email addresses (preserved here). Looking at the extracted target email addresses yielded some interesting insights:

1) The target email addresses were not exclusively in the domains my system actually serves, and

2) Some ways down the list of target email addresses, my own primary address turns up.

Of course 2) made me look a little closer, and only one IP address in the extract had tried delivery to my email address.

A further grep on that IP address turned up this result.

There are really no surprises to be had here, at least to a large subset of my supposed readers. The sender had first tried to deliver one of the sexstortion video messages to one of the by now more than quarter million spamtraps, and its IP address was still blacklisted by the time it finally tried delivery to a potentially deliverable address.

Doing a few spot checks on the sender IP addresses in recent and less recent logs it looks like the only two things could be mildly exciting about those messages. One is the degree the content was intended to be embarrasing to the recipient. The other is a possible indicator of the campaign's success: Looking back through the logs for the approximate year of known activity, it even looks like the campaign became multilingual, while retaining the word "hacker" in most if (possibly) not all language versions.

Other than that it is almost depressing how normal the sextortion campaign is: It uses the same spam sending infrastructure and the same low quality target address lists (the ones containing some subset of my spamtrap addresses) as the regular and likely not too successful spammers of every stripe. Nothing else stands out.

And as returning readers will notice, the logs indicate that the spambots are naive enough in their SMTP code that they frequently mistake spamd's delaying tactics for a slow, but functional open SMTP relay.

Now to recap the main points:
  • Regular users: The sextortion messages are scams, the videos do not exist. If this quasi-random sample is representative, the scammers are seen to send to 200 non-existing, invalid addresses before lucking on a real one. This alone strongly indicates that no videos exist. There is no reason to send money, bitcoin or otherwise. Look instead to learning how your devices and the networks and services they connect to actually work.
  • Competent mail admins: The tools to stop the flow of sextortion messages or at least slow to a manageable trickle are available today. You simply need to keep your antispam game up to speed with best practices and best of breed tools. If you are a user or someone who manages mail admins, check what your mail service does.
  • Competent authorities: Please step up to the task of educating the public. Sane, fact based approaches to IT security work. While it is easy to get distracted by the potential presence of porn and users' feelings of shame over accessing that kind of material, assigning much weight to that side of the matter is counterproductive. Work to educate the public and please focus on real threats, not imagined ones like the present topic.
Whatever evolves next out of these rather hamfisted attempts at blackmail is unlikely to ever achieve any level of sophistication worthy of the name.

We would all be much better served by focusing on real threats such as, but not limited to, credential harvesting via deceptive content delivered over advertising networks, which themselves are a major headache security- and privacy-wise, or even harvesting via phishing email.

Both of the latter have been known to lead to successful compromise with data exfiltration and identity theft as possible-to-probable results.

To a large extent the damage could could have been significantly limited had the general public been taught sensible security practices such as using multi-factor authentication or at least actually good passwords combined with securely coded password management applications, and insisting that services encourage such practices.

Yes, I know you have been dying to ask: What is the thing about Adnan? According to my activity log, the address adnan@bsdly.net was added as a spamtrap on July 8th, 2017 after somebot had tried to log on as the user adnan, a user name not seen before at bsdly.net,

Jul  8 09:40:34 skapet sshd[34794]: Failed password for invalid user adnan from 118.217.181.8 port 41091 ssh2

apparently from a network in South Korea.

As always, there is more log material available to competent practitioners and researchers with a valid research agenda. Please contact me if you are such a person who could use the collected data productively.


Update 2020-02-29: For completeness and because I felt that an unsophisticated attack like the present one deserves a thorough if unsophisticated analysis, I decided to take a look at the log data for the entire 7 day period, post-rotation.

So here comes some armchair analysis, using only the tools you will find in the base system of your OpenBSD machine or any other running a sensibly stocked unix-like operating systen. We start with finding the total number of delivery attempts logged where we have the body text 'am a hacker' (this would show up only after a sender has been blacklisted, so the gross number actual delivery attempts will likely be a tad higher), with the command

zgrep "am a hacker" /var/log/spamd.0.gz | awk '{print $6}' | wc -l

which tells us the number is 3372.

Next up we use a variation of the same command to extract the source IP addresses of the log entries that contain the string 'am a hacker', sort the result while also removing duplicates and store the end result in an environment variable called lastweek:

 export lastweek=`zgrep "am a hacker" /var/log/spamd.0.gz | awk '{print $6}' | tr -d ':' | sort -u `

With our list of IP addresses tucked away in the environment variable go on to: For each IP address in our lastweek set, extract all log entries and store the result (still in crude sort order by IP address), in the file 2020-02-29_i_am_hacker.raw.txt:

 for foo in $lastweek ; do zgrep $foo /var/log/spamd.0.gz | tee -a 2020-02-09_i_am_hacker.raw.txt ; done

For reference I kept the list of unique IP addresses (now totalling 231) around too.

Next, we are interested in extracting the target email addresses, so the command

grep "To:" 2020-02-29_i_am_hacker.raw.txt | awk '{print substr($0,index($0,$8))}' | sort -u

finds the lines in our original extract containing "To:", and gives us the list of target addresses the sources in our data set tried to deliver mail to.

The result is preserved as 2020-02-29_i_am_hacker.raw_targets.txt, a total of 236 addresses, mostly but not all in domains we actually host here. One surprise was that among the target addresses one actually invalid address turned up that was not at that time yet a spamtrap. See the end of the activity log for details (it also turned out to be the last SMTP entry in that log for 2020-02-29).

This little round of armchair analysis on the static data set confirms the conclusions from the original article: Apart from the possibly titillating aspects of the "adult" web site mentions and the attempt at playing on the target's potential shamefulness over specific actions, as spam campaigns go, this one is ordinary to the point of being a bit boring.

There may well be other actors preying on higher-value targets through their online clumsiness and known peculiarities of taste in an actually targeted fashion, but this is not it.

A final note on tools: In this article, like all previous entries, I have exclusively used the tools you will find in the OpenBSD (or other sensibly put together unixlike operating system) base system or at a stretch as an easily available package.

For the simpler, preliminary investigations and poking around like we have done here, the basic tools in the base system are fine. But if you will be performing log analysis at scale or with any regularity for purposes that influences your career path, I would encourage you to look into setting up a proper, purpose-built log analysis system.

Several good options, open source and otherwise, are available. I will not recommend or endorse any specific one, but when you find one that fits your needs and working style you will find that after the initial setup and learning period it will save you significant time.

As per my practice, only material directly relevant to the article itself has been published via the links. If you are a professional practitioner or researcher with who can state a valid reason to need access to unpublished material, please let me know and we will discuss your project.

Update 2020-03-02: I knew I had some early samples of messages that did make it to an inbox near me squirreled away somewhere, and after a bit of rummaging I found them, stored here (note the directory name, it seemed so obvious and transparent even back then). It appears that the oldest intact messages I have are from December 2018. I am sure earlier examples can be found if we look a littler harder.

Update 2020-03-17: A fresh example turned up this morning, addressed to (of all things) the postmaster account of one of our associated .no domains, written in Norwegian (and apparently generated with Microsoft Office software). The preserved message can be downloaded here. 

Update 2020-05-10: While rummaging about (aka 'researching') for something else I noticed that spamd logs were showing delivery attempts for messages with the subject "High level of danger. Your account was under attack."  So out of idle curiosity on an early Sunday afternoon, I did the following:

$ export muggles=`grep " High level of danger." /var/log/spamd | awk '{print $6}' | tr -d ':' | sort -u`
$ for foo in $muggles; do grep $foo /var/log/spamd >>20200510-muggles ; done


and the result is preserved for your entertainment and/or enlightenment here. Not much to see, really other than that they sent the message in two language varieties, and to a small subset of our imaginary friends.

Update 2020-08-13: Here is another snapshot of activity from August 12 and 13: this file preserves the activity of 19 different hosts, and as we can see that since they targeted our imaginary friends first, it is unlikely they reached any inboxes here. Some of these campaigns may have managed to reach users elsewhere, though

Update 2020-09-06: Occasionally these messages manage to hit a mailbox here. Apparently enough Norwegians fall for these scams that Norwegian language versions (not terribly well worded) get aimed at users here. This example, aimed at what has only ever been an email alias made it here, slipping through by a stroke of luck during a time that IP address was briefly not in the spamd-greytrap list here, as can be seen from this log excerpt. It is also worth noting that an identically phrased message was sent from another IP address to mailer-daemon@ for one of the domains we run here.

Update 2021-01-06: For some reason, a new variant turned up here today (with a second message a few minutes later and then a third), addressed to a generic contact address here. A very quick check of logs here only turned up only this indication of anything similar (based on a search for the variant spelling PRONOGRAPHIC), but feel free to check your own logs based on these samples if you like.

Update 2021-01-16: One more round, this for my Swedish alter ego. Apparently sent from a poorly secured Vietnamese system.

Update 2021-01-18: A Norwegian version has surfaced, attempted sent to approximately 115 addresses in .no domains we handle, fortunately the majority of the addresses targeted were in fact spamtraps, as this log extract shows.

Update 2021-03-03: After a few quiet weeks, another campaign started swelling our greytrapped hosts collection, as this hourly count of IP addresses in the traplist at dump to file time shows:

Tue Mar  2 21:10:01 CET 2021 : 2425
Tue Mar  2 22:10:01 CET 2021 : 4014
Tue Mar  2 23:10:01 CET 2021 : 4685
Wed Mar  3 00:10:01 CET 2021 : 4847
Wed Mar  3 01:10:01 CET 2021 : 5759
Wed Mar  3 02:10:01 CET 2021 : 6560
Wed Mar  3 03:10:01 CET 2021 : 6774
Wed Mar  3 04:10:01 CET 2021 : 7997
Wed Mar  3 05:10:01 CET 2021 : 8231
Wed Mar  3 06:10:01 CET 2021 : 8499
Wed Mar  3 07:10:01 CET 2021 : 9910
Wed Mar  3 08:10:01 CET 2021 : 10240
Wed Mar  3 09:10:01 CET 2021 : 11872
Wed Mar  3 10:10:01 CET 2021 : 12255
Wed Mar  3 11:10:01 CET 2021 : 13689 
Wed Mar  3 12:10:01 CET 2021 : 14181
Wed Mar  3 13:10:01 CET 2021 : 15259
Wed Mar  3 14:10:01 CET 2021 : 15881
Wed Mar  3 15:10:02 CET 2021 : 17061
Wed Mar  3 16:10:01 CET 2021 : 17625
Wed Mar  3 17:10:01 CET 2021 : 18758
Wed Mar  3 18:10:01 CET 2021 : 19170
Wed Mar  3 19:10:01 CET 2021 : 20028
Wed Mar  3 20:10:01 CET 2021 : 20578
Wed Mar  3 21:10:01 CET 2021 : 20997

and they attempted to get to mailer-daemon@, as can be seen from this preserved message as well as this one (both of which actually did inbox due to aliases).

Stay safe out there.

Update 2021-04-17: A new variant, somewhat crudely worded, inboxed today. Preserved here, here and here.

Update 2021-05-15: After swelling the list of trapped hosts considerably over the last few days, a sample of the campaign with the most correctly worded Norwegian text inboxed today, and I later found other samples.

From the logs it looks like the campaign started on May 13th:

 Thu May 13 10:10:01 CEST 2021 : 3998
Thu May 13 11:10:01 CEST 2021 : 4064
Thu May 13 12:10:01 CEST 2021 : 7052
Thu May 13 13:10:01 CEST 2021 : 7297
Thu May 13 14:10:01 CEST 2021 : 7474
Thu May 13 15:10:01 CEST 2021 : 10178
Thu May 13 16:10:01 CEST 2021 : 10251
Thu May 13 17:10:01 CEST 2021 : 11150
Thu May 13 18:10:01 CEST 2021 : 12686
Thu May 13 19:10:01 CEST 2021 : 12866
Thu May 13 20:10:01 CEST 2021 : 14708
Thu May 13 21:10:01 CEST 2021 : 14713
Thu May 13 22:10:01 CEST 2021 : 14907
Thu May 13 23:10:02 CEST 2021 : 16336
Fri May 14 00:10:01 CEST 2021 : 16360
Fri May 14 01:10:01 CEST 2021 : 16473
Fri May 14 02:10:01 CEST 2021 : 17608
Fri May 14 03:10:01 CEST 2021 : 17643
Fri May 14 04:10:01 CEST 2021 : 17671
Fri May 14 05:10:01 CEST 2021 : 17763
Fri May 14 06:10:01 CEST 2021 : 18796
Fri May 14 07:10:01 CEST 2021 : 18950
Fri May 14 08:10:02 CEST 2021 : 18972
Fri May 14 09:10:01 CEST 2021 : 18725
Fri May 14 10:10:01 CEST 2021 : 19929
Fri May 14 11:10:01 CEST 2021 : 19942
Fri May 14 12:10:01 CEST 2021 : 17046
Fri May 14 13:10:01 CEST 2021 : 18068
Fri May 14 14:10:01 CEST 2021 : 18619
Fri May 14 15:10:01 CEST 2021 : 16066
Fri May 14 16:10:01 CEST 2021 : 17468
Fri May 14 17:10:01 CEST 2021 : 17297
Fri May 14 18:10:01 CEST 2021 : 15859
Fri May 14 19:10:01 CEST 2021 : 17395
Fri May 14 20:10:01 CEST 2021 : 15934
Fri May 14 21:10:01 CEST 2021 : 15996
Fri May 14 22:10:01 CEST 2021 : 17120
Fri May 14 23:10:02 CEST 2021 : 16238
Sat May 15 00:10:01 CEST 2021 : 16299
Sat May 15 01:10:01 CEST 2021 : 16362
Sat May 15 02:10:01 CEST 2021 : 16346
Sat May 15 03:10:01 CEST 2021 : 16814
Sat May 15 04:10:01 CEST 2021 : 16812
Sat May 15 05:10:01 CEST 2021 : 16787
Sat May 15 06:10:01 CEST 2021 : 16007
Sat May 15 07:10:01 CEST 2021 : 17093
Sat May 15 08:10:01 CEST 2021 : 17101
Sat May 15 09:10:01 CEST 2021 : 17015
Sat May 15 10:10:01 CEST 2021 : 15702
Sat May 15 11:10:01 CEST 2021 : 15637

Update 2021-06-16: Another campaign seems to be under way, with this message sent to an address which I can reveal is simply an alias. 

Update 2021-08-16: Thanks to one particular operator being 'too big to block' this message, apparently part of a campaign that has at least 103 other sending hosts that are currently trapped here, actually inboxed despite being sent to a spamtrap which also corresponded to a forgotten alias for an actual in-use mailbox. 

Update 2021-08-17: By lunchtime the output of 

grep vellykket /var/log/spamd | awk '{ print $6 }' | sort -u | tr -d ':' | wc -l

had reached 471, so I did 

export trash=`grep vellykket /var/log/spamd | awk '{ print $6 }' | sort -u | tr -d ':'`
for foo in $trash ; do grep $foo /var/log/spamd >> vellykket.txt ; done

You can find the result here: vellykket_20210817T1200.txt. It looks like the campaign is still in progress.
 
A few hours later, the number was 570 and the new export looks like vellykket.txt while the most up to date list of IP addresses participating in the campaign is in vellykke_addressest.txt
 
If you're interested in further data, please let me know.
 
Update 2021-09-09: There are signs that another campaign is in progress, with an inboxed sample preserved here. This particular message appears to have been delivered from a Korean network.

Update 2021-10-27: Another sample inboxed overnight, from a campaign that uses a text with only slight edits from eariler.

Update 2021-11-29: Overnight a collection of trimmed-down messages like this one appeared, claiming to have installed a trojan on the supposed victim's phone, but asking the victim to answer the message for further instruction. An attempt to weed out spamtraps from their address lists, perhaps?

Update 2022-02-02: Another campaign is underway, a sample has been preserved here. It makes the usual claims of device takeover. This particular message seems to have been delivered via a Kenyan system.

Update 2022-03-30: A new entry appeared today, with only minor variations relative to earlier campaigns. As expected a log extract shows that the same host had been used in some spamming campaign or other -- possibly even an earlier segment of the same one -- only a few days ago.

Update 2022-04-08: The number of languages used in those messages received here grew by one with today's entry, which seems to be in German. I am not qualified to speak to the quality or lack of same of the translation, but I note that the host that was used to send the message seems to belong in an Indonesian network.

Update 2022-04-09: Yet another German language entry, this on also sent from a system apparently in Indonesia.

Update 2022-08-19: A new Norwegian language campaign is under way, with a handful of new samples available in the archive.

Update 2022-09-18: Another campaign in progress, this time picking up on quasi-recent buzzwords. I offer the evidence so far.

Update 2022-09-24: Yet another campaign, very similar to the last one. This message was apparently sent from a (likely compromised) Kuwaiti system.

Update 2022-10-06: Here we go again. The campaign has been going on for a little while, the first message to inbox (sort of) was this one, apparently delivered from a host located in Korea. The list of identified spam sources (246 hosts at this point) is here, while a log of activity can be found here. Warning: that last one is not a small file.

Update 2022-11-23: Another campaign is underway, with a variety of subjects, all with the word trouble, a full list preserved here. In addition, a few extracts, startin with the list of sending addresses (178 total) the list of target email adddresses (480 total) a full log extract covering the whole campaign while extract per host can be found in this directory.

None of this inboxed, of course, as they could all be found in the list of spamtraps, referenced among other places in my previous article The Things Spammers Believe - A Tale of 300,000 Imaginary Friends (also available without trackers.


If you have further data on these or similar incidents that you are able to share or if you want to look further into these and similar incidents, please let me know.

If you find any errors in the material I publish or disagree with my sentiments, or if you find this article interesting, useful or annoying, please let me know, either in comments or via email.


Saturday, December 28, 2019

The Year 2019 in Review: This Was, Once Again, Weirder Than the Last One

The year is 2019. By now Blade Runner is a movie about the past, but there are still bots out there trying to guess our passwords. It gets betterworse from here while the dictionaries expand.

The year is coming to an end and events during that year, as they happened, somehow lead to me leaving writing mainly to one side and blog posting only until I saw a bigger picture.

Now with only a couple of days left to go, we see that this year began much like the previous, with a not too bright set of bots endlessly trying to guess passwords. But on January 2, a new development caught my eye:


It was fairly obvious that some bot operator had the columns in their database mixed up, and I found the episode so laughable myself that I did not even bother to include it as the local part of a spamtrap. But as we will see later, it was an early sign of things to come. As you have probably suspected, the ssh password guessing activities have continued at pace, yielding this year so far

[Sat Dec 28 17:01:28] peter@skapet:~/website$ grep 2019 spamtraps-dateadded.txt | grep -c SSH
51233


that is, the local part of more than fifty thousand spamtraps.

In addition the early part of the year saw several campaigns of the email scams trying to extort various Bitcoin amounts in return for not publishing supposedly embarrassing videos, one of which I tweeted about:

You should be able to find further absurdities of a similar kind by looking for the hashtags #blooper_reel from that tweet as well ast #turbators. With those hashtags you will notice that there is at least anecdotal evidence that messages of the same kind have been directed at a significant subset of our spamtraps here (which for obvious reasons would not have been used in connection with any actual user login anywhere), evidenced by the spamd(8) log snippet preserved in this tweet:

And as noted in the followup tweet, other weirness was already happening:

More specifically, in the overnight haul on the morning of January 30th, I noticed via my scriptery that reports on such things that a large number of apparent bounce message deliveries to addresses made up of "Western-firstname.Chinese-lastname@mydomain.tld", such as aaron.pu@bsdly.net or abby.na@bsdly.net, had turned up, in addition to a few other varieties with no dot in the middle, possibly indicating separate sources.

That initial overnight batch only had only a couple of hundred new potential spamtraps in it (as evidenced by the spamtraps added log), but even at that point the greylist data seemed to indicate that the bounces were produced by a relatively small set of IP addresses in Chinese networks. We see such bursts at times, but they rarely last long, so at first I did not think much of it before simply adding those addresses as spamtraps.

This was one round that kind of exceeded expectations, in that what we can only conclude was the noise generated by one or more phishing campaigns targeting Chinese users lasted well into April of this year and ended up yielding more than 120,000 "imaginary friends", or spamtraps as others would say. It is likely that each of those fake addresses were used more than once, and in this context we only count new ones, so the actual number of messages and users targeted was probably a lot larger than the number of faked email addresses found in our logs here.

The delivery attempt from this tweet may well have been a product of the same campaigns:


By this time whoever was behind the campaign may have acieved their goals and moved on, or we could hope that they had been shut down by competent authorities.

But back to the password guessers, sometimes referred to as The Hail Mary Cloud. We have seen amazing feats of incompetence on their part before, but I seriously thought we had reached peak when some bot tried to log on a system in my care as the user "*" (yes, asterisk):


It should be noted of course that this confused my very much grep(1)-based script that among other things turns up new candiates for spamtraps. But again it was an early indication that by their incompetence at least some of the bot herders had exposed their methods. Weird things turn up on occasion, but it took until October before it dawned on me that at least some of the password guessing bots could be running with their username and passwords fields swithched around:


A few days later I stopped trying to write a witty article about the phenomenon:

but I kept harvesting new entries for the local parts of spamtraps, while noting that my still grep(1)-centric script for detecting candiates would relatively frequently fail while trying to interpret what looked like regular expressions, with messages such as

grep: repetition-operator operand invalid
-bash: [: ==: unary operator expected


turning up instead.

Some of these entries (this month's worth so far* can be found in this file) were weird enough (would you actually have created a user called !@#$%^&*()dianlut+_ ?) that they had me thinking that the operators of those bots were actually trying to be smart by working from stolen and published collections of password hashes.

The wrinkle to this could turn to our advantage is that some of these operators managed to get the order of their fields wrong and are throwing either raw password hashes or decoded ones at our systems instead of matching user names. By reversing the process we might be able to see which collections are used, or other weird and creative things.

If you are interested in doing further research on this, please contact me by email or the comments. I consider the traplist data, the dates added log and the other material mentioned in this piece and links therein to be public and the data should be available to anyone. Howerer, some data exists only in some more detailed logs that are preserved here only to be seen by competent eyes and used for valid purposes. If you consider yourself such a person (aka a professional), please feel free to contact me.

All the while, we see the dictionaries of user names and passwords expanding, and I for one am more than willing to help out in the effort. It helps us all identify the never-do-wells as early as possible in the game.

The raw numbers for our contributions to the hopefully confusing dictionary as they stand right now are (they will be different when you read this):

We have a total of 242778 spamtraps, with the numbers added according to the dates added log this year at 131195 from SMTP traffic, 51233 from failed SSH login attempts and 11 innovations from POP3 logon attempts.

This means our list of spamtraps did not reach a full quarter milllion this year.

But I already sense that somebody, somewhere is about to say "Hold my beer".



* Update 2020-01-02: This file now has the complete, or as complete as can be with the current scriptery, list of usernames tried during the whole month of December 2019.

Update 2020-01-07: You would probably not notice from looking at the raw listing of attempted usernames so far this month, but the theme so far in 2020 among the new arrivals seems to be, of all things, three letter user names (take a peek at 2020 part so far at the end of the spamtraps added log). Go figure.


Monday, August 8, 2016

Chinese Hunting Chinese Over POP3 In Fjord Country

Yes, you read that right: There is a coordinated effort in progress to steal Chinese-sounding users' mail, targeting machines at the opposite end of the Eurasian landmass (and probably elsewhere).

More specifically, here at bsdly.net we've been seeing attempts at logging in to the pop3 mail retrieval service using usernames that sound distinctively like Chinese names, and the attempts originate almost exclusively from Chinese networks.

This table lists the user names and corresponding real life names attempted so far:

Name Username
Chen Qiang chenqiang
Fa Dum fadum
Gao Dang gaodang
Gao Di gaodi
Gao Guan gaoguan
Gao Hei gaohei
Gao Hua gaohua
Gao Liu gaoliu
Gao Yang gaoyang
Gao Zhang gaozhang
He An hean
He Biao hebiao
He Bing hebing
He Chang hechuang
He Chao hechao
He Chen hechen
He Cheng hecheng
He Chun hechun
He Cong hecong
He Da heda
He Di hedi
He Die hedie
He Ding heding
He Dong hedong
He Duo heduo
He Fa hefa
He Ging heqing
He Guo heguo
He Han hehan
He Hao hehao
He Heng heheng
He Hui hehui
He Jia hejia
He Jian hejian
He Jiang hejiang
He Jie hejie
He Jin hejin
He Juan hejuan
He Kai hekai
He Kan hekan
He Kong hekong
He La hela
He Le hele
He Leng heleng
He Li heli
He Lian helian
He Lie helie
He Mu hemu
He Niang heniang
He Quan hequan
He Ran heran
He Sha hesha
He Shan heshan
He Shi heshi
He Si hesi
He Song hesong
He Xiao hexiao
He Yao heyao
He Yi heyi
He Yin heyin
He Yu heyu
He Yun heyun
He Zeng hezeng
He Zeng hezhan
He Zhang hezhangxxxx
He Zhe hezhe
He Zheng hezheng
He Zhi hezhi
He Zhong hezhong
He Zhuang hezhuang
Li An lian
Li Biao libiao
Li Bin libin
Li Bo libo
Li Cheng licheng
Li Chi lichi
Li Chong lichong
Li Chuang lichuang
Li Chun lichun
Li Da lida
Li Deng lideng
Li Di lidi
Li Die lidie
Li Ding liding
Li Dong lidong
Li Duo liduo
Li Fa lifa
Li Fang lifang
Li Fen lifen
Li Feng lifeng
Li Gang ligang
Li Gao ligao
Li Guan liguan
Li Guang liguang
Li Hai lihai
Li Ka lika
Li Kai likai
Li La lila
Li Le lile
Li Lei lilei
Li Lin lilin
Li Ling liling
Li Liu liliu
Li Long lilong
Li Man liman
Li Mei limei
Li Mu limu
Li Neng lineng
Li Niang liniang
Li Peng lipeng
Li Pian lipian
Li Qian liqian
Li Qu liqu
Li Rang lirang
Li Ren liren
Li Ru liru
Li Sha lisha
Li Shi lishi
Li Shuai lishuai
Li Shun lishun
Li Si lisi
Li Song lisong
Li Tao litao
Li Teng liteng
Li Tian litian
Li Ting liting
Li Wang liwang
Li Wei liwei
Li Wen liwen
Li Xiang lixiang
Li Xing lixing
Li Xiu lixiu
Li Ying liying
Li You liyou
Li Ze lize
Li Zeng lizeng
Li Zheng lizheng
Li Zhong lizhong
Li Zhu lizhu
Li Zhuang lizhuang
Li Zhuo lizhuo
Liang Min liangmin
Liang Ming liangming
Liang Qiang liangqiang
Liang Rui liangrui
Lin Chen linchen
Lin Cheng lincheng
Lin He linhe
Lin Hua linhua
Lin Huang linhuang
Lin Neng linneng
Lin Pian linpian
Lin Qu linqu
Lin Ru linru
Lin Zhang linzhang
Liu Bin liubin
Liu Duo liuduo
Liu Fang liufang
Liu Han liuhan
Liu Hao liuhao
Liu Heng liuheng
Liu Hong liuhong
Liu Hui liuhui
Liu Jia liujia
Liu Jiang liujiang
Liu Jiao liujiao
Liu Ju liuju
Liu Juan liujuan
Liu Kai liukai
Liu Kan liukan
Liu Kang liukang
Liu Ke liuke
Liu Kong liukong
Liu Lang liulang
Liu Long liulong
Liu Mu liumu
Liu Nuo liunuo
Liu Qin liuqin
Liu Qing liuqing
Liu Qiong liuqiong
Liu Rong liurong
Liu Sen liusen
Liu Sha liusha
Liu Shun liushun
Liu Si liusi
Liu Tian liutian
Liu Wang liuwang
Liu Wei liuwei
Liu Xia liuxia
Liu Xiu liuxiu
Liu Yao liuyao
Liu Yi liuyi
Liu Ying liuying
Liu Yu liuyu
Liu Yuan liuyuan
Liu Yun liuyun
Liu Zhen liuzhen
Liu Zheng liuzheng
Liu Zhi liuzhi
Liu Zun liuzun
Lou Liu luoliu
Lu Huang lihuang
Luo Chang luochuang
Luo Chen luochen
Luo Cheng luocheng
Luo Deng luochi
Luo Deng luodeng
Luo Di luodi
Luo Dian luodian
Luo Gao luogao
Luo Guai luoguai
Luo Hang luohuang
Luo Hua luohua
Luo Lie luolie
Luo Neng luoneng
Luo Pian luopian
Luo Qi luoqi
Luo Qin luoqin
Luo Qing luoqing
Luo Qu luoqu
Luo Rong luorong
Luo Ru luoru
Luo Rui luorui
Luo Shuang luoshuang
Luo Ting luoting
Luo Tong luotong
Luo Wang luowang
Luo Wei luowei
Luo Yang luoyang
Luo Ze luoze
Song Chen songchen
Song Cheng songcheng
Song Chuang songchuang
Song Da songda
Song Deng songdeng
Song Dian songdian
Song Die songdie
Song Fei songfei
Song Fen songfen
Song Gang songgang
Song Gao songgao
Song Guai songguai
Song Guan songguan
Song Guo songguo
Song Hai songhai
Song Han songhan
Song Hang songhang
Song He songhe
Song Hei songhei
Song Heng songheng
Song Hu songhu
Song Hua songhua
Song Jia songjia
Song Jiao songjiao
Song Jie songjie
Song Jin songjin
Song Jing songjing
Song Ka songka
Song Kan songkan
Song Kang songkang
Song Kong songkong
Song Lan songlan
Song Le songle
Song Lei songlei
Song Lian songlian
Song Liang songliang
Song Liang songliao
Song Liang songliang
Song Liao songliao
Song Lin songlin
Song Liu songliu
Song Meng songmeng
Song Ming songming
Song Mu songmu
Song Nan songnan
Song Neng songneng
Song Ning songning
Song Pian songpian
Song Pin songpin
Song Qi songqi
Song Qiang songqiang
Song Qing songqing
Song Qiu songqiu
Song Ran songran
Song Rong songrong
Song Rui songrui
Song Sha songsha
Song Shuai songshuai
Song Shuang songshuang
Song Song songsong
Song Song Jun songsongjun
Song Tao songtao
Song Teng songteng
Song Wang songwang
Song Wei songwei
Song Xi songxi
Song Xia songxia
Song Xiu songxiu
Song Ya songya
Song Yang songyang
Song Yong songyong
Song You songyou
Song Yuan songyuan
Song Yue songyue
Song Yun songyun
Song Zhe songzhe
Song Zhen songzhen
Song Zheng songzheng
Song Zhuang songzhuang
Tan Qian tangqian
Tang Bing tangbing
Tang Chi tangchi
Tang Chong tangchong
Tang Chuang tangchuang
Tang Cong tangcong
Tang Di tangdi
Tang Dian tangdian
Tang Duo tangduo
Tang Fa tangfa
Tang Fan tangfan
Tang Fang tangfang
Tang Fei tangfei
Tang Fen tangfen
Tang Feng tangfeng
Tang Gang tanggang
Tang Guai tangguai
Tang Guan tangguan
Tang Guang tangguang
Tang Guo tangguo
Tang Han tanghan
Tang Hao tanghao
Tang Hei tanghei
Tang Heng tangheng
Tang Hong tanghong
Tang Hu tanghu
Tang Hui tanghui
Tang Jie tangjie
Tang Jin tangjin
Tang Jing tangjing
Tang Ju tangju
Tang Ka tangka
Tang Kai tangkai
Tang Kan tangkan
Tang Kang tangkang
Tang Ke tangke
Tang Kong tangkong
Tang La tangla
Tang Lang tanglang
Tang Le tangle
Tang Leng tangleng
Tang Li tangli
Tang Lian tanglian
Tang Lie tanglie
Tang Lin tanglin
Tang Ling tangling
Tang Liu tangliu
Tang Long tanglong
Tang Mei tangmei
Tang Mo tangmo
Tang Mu tangmu
Tang Neng tangneng
Tang Niang tangniang
Tang Nuo tangnuo
Tang Peng tangpeng
Tang Pian tangpian
Tang Ping tangping
Tang Qian tangqian
Tang Qin tangqin
Tang Qu tangqu
Tang Quan tangquan
Tang Quing tangqing
Tang Rang tangrang
Tang Ren tangren
Tang Ru tangru
Tang Ruan tangruan
Tang Rui tangrui
Tang Sen tangsen
Tang Sha tangsha
Tang Shan tangshan
Tang Shi tangshi
Tang Shun tangshun
Tang Song tangsong
Tang Tang Jun tangtangjun
Tang Tao tangtao
Tang Tian tangtian
Tang Tian tangyan
Tang Wei tangwei
Tang Xi tangxi
Tang Xia tangxia
Tang Xing tangxing
Tang Xiong tangxiong
Tang Yan tangyan
Tang Yang tangyang
Tang Yao tangyao
Tang Yi tangyi
Tang Ying tangying
Tang Yong tangyong
Tang You tangyou
Tang Yue tangyue
Tang Yun tangyun
Tang Ze tangze
Tang Zeng tangzeng
Tang Zhang tangzhang
Tang Zhe tangzhe
Tang Zhen tangzhen
Tang Zun tangzun
Xie An xiean
Xie Bin xiebin
Xie Bo xiebo
Xie Chao xiechao
Xie Cong xiecong
Xie Da xieda
Xie Di xiedi
Xie Dian xiedian
Xie Die xiedie
Xie Ding xieding
Xie Dong xiedong
Xie Duo xieduo
Xie Fang xiefang
Xie Fei xiefei
Xie Feng xiefeng
Xie Gang xiegang
Xie Gao xiegao
Xie Guai xieguai
Xie Guan xieguan
Xie Hai xiehai
Xie Hang xiehang
Xie Heng xieheng
Xie Heng xieneng
Xie Heng xieheng
Xie Heng xieneng
Xie Hong xiehong
Xie Hu xiehu
Xie Hui xiehui
Xie Jia xiejia
Xie Jian xiejian
Xie Jiang xiejiang
Xie Jiao xiejiao
Xie Jie xiejie
Xie Jing xiejing
Xie Ju xieju
Xie Kai xiekai
Xie La xiela
Xie Leng xieleng
Xie Liang xieliang
Xie Lie xielie
Xie Lin xielin
Xie Ling xieling
Xie Long xielong
Xie Man xieman
Xie Meng xiemeng
Xie Min xiemin
Xie Ming xieming
Xie Na xiena
Xie Niang xieniang
Xie Peng xiepeng
Xie Pian xiepian
Xie Pin xiepin
Xie Qi xieqi
Xie Qing xieqing
Xie Qiong xieqiong
Xie Qiu xieqiu
Xie Qu xiequ
Xie Quan xiequan
Xie Ran xieran
Xie Ruan xieruan
Xie Rui xierui
Xie Sha xiesha
Xie Shuang xieshuang
Xie Si xiesi
Xie Tao xietao
Xie Ting xieting
Xie Tong xietong
Xie Wei xiewei
Xie Wen xiewen
Xie Xi xiexi
Xie Xiang xiexiang
Xie Xin xiexin
Xie Xing xiexing
Xie Xiu xiexiu
Xie Ya xieya
Xie Yi xieyi
Xie Yin xieyin
Xie Ying xieying
Xie Yong xieyong
Xie Yu xieyu
Xie Yue xieyue
Xie Zeng xiezeng
Xie Zhan xiezhan
Xie Zhang xiezhang
Xie Zhe xiezhe
Xie Zhuo xiezhuo
Zheng Nan zhengnan

That list of some 493 names is up to date as of this writing, 2016-08-23 early evening CEST. A few more turn up with the bursts of activity we have seen every day since June 19th, 2016.

A possibly more up to date list is available here. That's a .csv file, if that sounds unfamiliar, think of it as a platform neutral text representation (to wit, "Comma Separated Values") of a spreadsheet or database -- take a peek with Notepad.exe or similar if you're not sure. I'll be updating that second list along with other related data at quasi-random intervals as time allows and as long as interesting entries keep turning up in my logs.

If your name or username is on either of those lists, you would be well advised to change your passwords right now and to check breach notification sites such as Troy Hunt's haveibeenpwned.com or breachalarm.com for clues to where your accounts could have been compromised.

That's your scoop for now. If you're interested in some more background and data, keep reading.

If you are a regular or returning reader of this column, you are most likely aware that I am a Unix sysadmin. In addition to operating and maintaining variuos systems in my employers' care, I run a small set of servers of my own that run a few Internet-facing services for myself and a small circle of friends and family.

For the most part those systems are roundly ignored by the world at large, but when they are not, funny, bizarre or interesting things happen. And mundane activities like these sometimes have interesting byproducts. When you run a mail service, you are bound to find a way to handle the spam people will try to send, and about ten years ago I started publishing a blacklist of known spamming hosts, generated from attempts to deliver mail to a slowly expanding list of known bad, invalid, never to be deliverable addresses in the domains we handle mail for.

After a while, I discovered that the list of spamtrap addresses (once again, invalid and destined never to be deliverable, ever) had been hilariously repurposed: The local parts (the string before the @ or 'at sign') started turning up as usernames in failed attempts to log on to our pop3 mail retrieval service. That was enough fun to watch that I wrote that article, and for reasons known only to the operators of the machines at the other end, those attempts have never stopped entirely.

These attempts to log in as our imaginary friends is a strong contender for the most bizarre and useless activity ever, but when those attempts were no longer news, there was nothing to write about. The spamtrap login attempts make up sort of a background noise in the authentication logs, and whenever there is an attempt to log in as a valid user from somewhere that user is clearly not, the result is usually that an entire network (whatever I could figure out from whois output) would be blocked from any communication with our site for 24 hours.

There are of course also attempts to log in as postmaster, webmaster and other IDs, some RFC mandated, that most sites including this one would handle as aliases to make up the rest of the background noise.

Then recently, something new happened. The first burst looked like this in my logs (times given in local timezone, CEST at the time):

Jun 19 06:14:58 skapet spop3d[37601]: authentication failed: no such user: lilei - 59.54.197.34
Jun 19 06:15:01 skapet spop3d[46539]: authentication failed: no such user: lilei - 59.54.197.34
Jun 19 06:15:03 skapet spop3d[8180]: authentication failed: no such user: lilei - 59.54.197.34


-- and so on, for a total of 78 attempts to log in as the non-existing user lilei, in the space of about five minutes. A little later, a similar burst of activity came for the user name lika:

Jun 19 14:11:30 skapet spop3d[68573]: authentication failed: no such user: lika - 182.87.253.48
Jun 19 14:12:22 skapet spop3d[22421]: authentication failed: no such user: lika - 182.87.253.28
Jun 19 14:12:26 skapet spop3d[7587]: authentication failed: no such user: lika - 182.87.253.28
Jun 19 14:12:30 skapet spop3d[16753]: authentication failed: no such user: lika - 182.87.253.28


and so on, for a total of 76 attempts. Over the next few days I noticed an uptick in failed pop3 access attempts that were not for valid users and did not match any entry on our spamtraps list. Still, those attempts were for users that do not exist, and would produce no useful result so I did not do anything much about them.

It was only during the early weeks of July that it struck me that the user name attempted here

Jul  8 12:19:08 skapet spop3d[54818]: authentication failed: no such user: lixing - 49.87.78.12
Jul  8 12:19:28 skapet spop3d[1987]: authentication failed: no such user: lixing - 49.87.78.12
Jul  8 12:19:37 skapet spop3d[70622]: authentication failed: no such user: lixing - 49.87.78.12
Jul  8 12:19:49 skapet spop3d[31208]: authentication failed: no such user: lixing - 49.87.78.12


(a total of 54 attempts for that user name) might actually be based on the name of a Chinese person. "Li Xing" sounded plausible enough as a possible real person. It's perhaps worth noting that at the time I had just finished reading the first two volumes of Cixin Liu's The Three Body Problem, so I was a bit more in tune than usual with what could be plausible Chinese names than I had been. (And yes, the books are very much to my taste and I have the yet unpublished translation of the third volume on pre-order.)

Unsurprisingly, a quick whois lookup revealed that the machines that tried reading the hypothetical person Li Xing's mail all had IP addresses that belonged to Chinese networks.

Once I realized I might be on to a new pattern, I went back over a few days' worth of failed pop3 login attempts and found more than a handful of usernames that looked like they could be based on Chinese names. Checking the whois data for the IP addresses in those attempts, all turned out to be from Chinese networks.

That was in itself an interesting realization, but a small, random sample does not make for proof. In order to establish an actual data set, it was back to collecting data and analysing the content.

First, collect all log data on failed pop3 attempts for a long enough period that we have a reasonable baseline and can distinguish between the background noise and new, exciting developements.

The file bigauthlog is that collection of data. Digging through my archives going back in time, I stopped at January 16, 2016 for no other reason than this would be roughly six months' worth of data, probably enough to give a reasonable baseline and to spot anomalies.

If you've read the previous columns, you will be familiar with the scripts that produce various text and CSV reports from log data input: A text report of user names by number of access attempts, a CSV dump of the same, with first and last spotted, a text report of hosts attempting access, sorted by number of attempts, a CSV dump of the same, with first and last seen dates as for the user names.

But what I wanted to see was where the login attempts were coming from for which usernames, so I started extracting the unique host to username mappings. For each entry in this CSV file, there is a host and a user name it has tried at least once (if you import that somewhere, make sure you mark the Username column as text -- LibreOffice Calc at least becomes confused when trying to parse some of those strings). The data also records whether that particular username was part of the spamtrap database at the time. If you want to do that particular check on your own greytrapping database, any matching output from

$ doas spamdb | grep -i username@

on your greytrapper box will mean it is in your list. And then finally for each entry there is the expected extract from available whois info: network address range, the network name and the country.

The most useful thing to do with that little database is to play with sorting on various fields and field combinations. If you sort on the "In spamtraps" field, the supposed Chinese names turn up with "No"s, along with a few more random-seeming combinations.

While I was building the data set I decided to add those new usernames with @bsdly.net appended to the spamtraps, and this is what finally pushed the number of spamtraps past the 30,000 mark.

Just browsing the data or perhaps sorting by IP address will show you that the pop3 gropers are spread across a large number of networks in a number of countries and territories with numbers roughly in proportion to the size of that country or territory's economy. Some, such as a particular Mexican ISP and cable TV operator stand out as being slightly over-represented, and as expected networks in the US and China stand for a large number of the total.

If you sort on the In spamtraps field, you will see that a large number of the entries that were not in the spamtraps are the ones identified as Chinese personal names, but not all. Some of the No entries are the RFC mandated mailboxes, some are aliases that are in use here for other reasons, and finally more than a handful that would fit the general description of the rest of the spamtraps: Strings superficially resembling personal names or simply random strings. These may be parts of the potential spamtraps I missed while fishing  spamtrap candidates out of logfiles some time over the decade of weirdness that has gone into maintaining the spamtraps list.

But if you sort the data primarily on the fields Name, Country, and if you like IP address and User name, you will see that as anticipated the attempts on Chinese-sounding user names come exclusively from Chinese networks, except only the "Fa Dum" (fadum) user, which appears to have been attempted only twice (on June 6th) from an IP address registered in the USA and may very well be a misclassification on my part. That particular sorting, with duplicates removed, is the origin of the list of names and usernames given earlier in this article and this CSV file.

Now that we have established that the attempts at Chinese user names come exclusively from Chinese networks, the next questions become: Who are the cyber criminals behind this activity, and what are their motivations? And why are they bothering with hosts in faraway Europe to begin with?

For the first question, it is hard to tell from this perch, but whoever runs those attempts apparently have the run of large swathes of network real estate and seem to not take any special care not to be detected, other than of course distributing the attempts widely across the network ranges and coming in only in short bursts.

So are those attempts by, let us say the public sector, to steal political dissidents' email? Or perhaps, still with a public sector slant, simply hunting for any and all overseas assets belonging to Chinese nationals? Or are we simply seeing the activities of Chinese private sector cyber criminals who are trying out likely user names wherever they can find a service that listens?

Any of all of these things could be true, but in any case it's not unlikely that what we are seeing somebody trying to find new places where username and password combinations from a recent breach might work. After all, username and password combinations that have been verified to work somewhere are likely worth more on the market than the unverified ones.

Looking at the log entries, there are sequences there that could plausibly have been produced by humans typing at keyboards. Imagine if you please vast, badly lit and insufficiently ventilated Asian cyber-sweatshops, but I would not be too surprised to find that this is actually a highly automated operation, with timing tuned to avoid detection.

Security professionals have been recommending that people stop using the pop3 protocol since as long as I care to remember, but typing "pop3" into shodan.io still produces a whopping 684,291 results, meaning that the pop3 service is nowhere near as extinct as some would have preferred.

The large number of possible targets is a likely explanation for the burstiness of the activity we are seeing: with that many hosts to cover, the groping hosts will need to set up some sort of rotation, and in addition there is the need to stay below some volume of traffic per host in order to avoid detection. This means that what any one site sees is only a very small part of the total activity. The pop3 hunt for Chinese users is most likely not exclusive to the fjord country.

If you run a pop3 service, please do yourself a favor and check your setup for any weaknesses including any not yet applied updates, as you were about to do anyway. Once you've done that, take some moments to browse your logs for strange looking login attempts.

If you find something similar to what I've reported here, I would like to hear from you. Please note that at least one of the pop3 deaemons out there by default does not report the username for failed authentication attempts but notes that the username was unknown instead. Anyway, your war stories will be appreciated in email or comments.

If your name or username appears in the table at the start of this article or in this CSV file, please start checking for unusual activity involving your accounts and start changing passwords right away. Ask your service providers if they offer more secure alternatives, and if they do, consider using these alternatives. And as I mentioned earlier, do check breach notification sites such as haveibeenpwned.com or breachalarm.com for clues to help find out whether your data could be at risk in any of the services you do use. And of course, feedback in comments or email is welcome.

And finally, if you have information on one or more breaches that may have been the source of this list of likely Chinese user names, I'd like to hear from you too.

Good night and good luck.


Update 2016-10-15: The attempts at logging in with Chinese-sounding user names from hosts in Chinese networks became incrementally less frequent over time, and seem to have stopped entirely in early October 2016.

The final entry is this one, from October 6:

Oct  6 18:11:23 skapet spop3d[97769]: authentication failed: no such user: maxiang - 114.99.9.152

That is, an attempt from the IP address range assigned to the Chinanet Anhui province network, for the user name maxiang which may very well map to Ma Xiang (or Xiang Ma) as a person's name.

During the months they were active, the robots or sweatshops in the Chinese networks tried a total of 957 distinct user names, from 3794 distinct hosts for a total of 3998 host-username combinations.

Although the number of failed pop3 attempts have now fallen to almost none (bar a treesome of persistent miscreants in the Quasi Networks, Seychelles IP address range), I will make an effort to publish updates to the data at not too infrequent intervals. You are of course free to use the data in your own analyses, as long as reasonable credit is given for the data collection. If you're unsure what that means, please contact me directly (the address in the whois information works).

Update 2016-12-07: Even though the campaign that prompted me to write this article has ended or moved its attention elsewhere, I do update the data occasionally. Returning readers may be happy to hear about a slight enhancement in presentation of the data: Startiing with today's edition, I've added an 'Attempts'  column to the main .csv file, denoting the number of attempts for each host-username pair.

Update 2017-02-08: Another round of attempts at usernames that are likely Chinese user names started on February 8th, 2017.

The first few hours brought the following user names, with the likely corresponding real life name in the second column:

Name Username
Luo Chun luochun
Luo Fa luofa
Luo Feng luofeng
Luo Hai luohai

These names have been added to the full data as well as the 2017-only portion. The log file (2016 and 2017 version or 2017-only data) contains the entries starting at Feb  8 15:26:45 (times are CET local time). It will be interesting to see how long this cycle lasts. Look for updates to the data at irregular but hopefully frequent intervals.

If you are seeing similar activity, I would like to hear from you, in comments or (these most recent attempts all originate in the 49.64.0.0/11 network (range 49.64.0.0 - 49.95.255.255, also known as  CHINANET-JS or the CHINANET jiangsu province network). The previous cycle involved several distinct Chinese networks, and as we all know, stretched over several months of low intensity activity.


I would like to thank Tore Nordstrand and Øystein Alsaker for valuable input on various aspects of this article.
The data referenced in this article will likely be updated on a roughly daily basis while the Chinese episode lasts. You can fetch them from the links in the article or from this directory, which also contains some trivial data extraction and data massaging scripts I use. If you find any errors or have any concerns, please let me know.