Suspected Bot List [2020-04-10]

detection period: 2020-04-10 00:00-23:59 UTC
number of suspected bots' IPs listed here: 1483

IP addresses listed here all exhibit strange network behavior. As I could not notify the victims for various reasons (no working abuse contact, mailbox over quota, etc.), I list them here instead. I have to emphasize that those are just *suspected* to be malware-infected computers.

List from fake open relays:

country code	IP address	Country

List from greylisting:

country code	IP address	Country

List from SSH probes:

country code	IP address	Country

List from TCP port scans:

Suspected Bot List [2020-03-09]

detection period: 2020-03-09 00:00-23:59 UTC
number of suspected bots' IPs listed here: 1924

IP addresses listed here all exhibit strange network behavior. As I could not notify the victims for various reasons (no working abuse contact, mailbox over quota, etc.), I list them here instead. I have to emphasize that those are just *suspected* to be malware-infected computers.

List from fake open relays:

country code	IP address	Country

List from greylisting:

country code	IP address	Country

List from SSH probes:

country code	IP address	Country

List from TCP port scans:

ZBTrap: a Virtual Appliance for Botnet Detection

I have created a Virtualbox VM named "ZBTrap" (shortened from ZomBie Trap), which can be used to detect spam sending computers with greylisting. Anyone can download and configure this VM, and then start detecting malware-infected computers themselves.

ZBTrap is licensed under Creative Commons Attribution-ShareAlike 4.0 International License.

Warning: Even though this appliance seems to work correctly when I create and test it, I can not guarantee it will work for you. Use at your own risk.

Prerequisite: ZBTrap's operation is based on greylisting, so one or more heavily spammed domains with no active mail accounts are necessary for it to work. All incoming mail will be discarded, so don't use this for any domain which you intend to receive mail.

Built-in accounts/password:

root/cbf7b598 (root account)
zbtrap/8ad49a99

"zbtrap" is the account used for retrieving IP list of suspected zombie computers and associated spam mail headers.

Here is how to set up your own ZBTrap:

• Download the "ZBTrap" virtual appliance (download link here). That file is almost 600MB, so be patient.
• The appliance is in OVA format. Import it (File/Import Appliance...) into your Virtualbox manager.
• Configure the network setting of your ZBTrap so that it is able to accept incoming SMTP connections. There are many ways to achieve this. When I tested it at home, I configured my ZBTrap to be "bridged" within my Virtualbox, so that it gets its own IP address. Then I set up my gateway to forward TCP port 25 (SMTP) of its external IP to my ZBTrap.
• Start your ZBTrap VM. For each domain you use to detect botnets, you have to add one line to /usr/exim/grey_domains as the root user (here I assume that the domain to be added is "spammeddomain3.com"):
  
  echo spammeddomain3.com >> /usr/exim/grey_domains
  
  likewise, one line has to be appended to /usr/exim/domain_aliases, too:
  
  echo "*@spammeddomain3.com: greyhole" >> /usr/exim/domain_aliases
  
  
• Point the MX of your mail domain(s) to your ZBTrap, and it should be the sole MX for those domains. In my case described above, I created a domain name mapping to the public IP of my gateway, then used that for the MX.
• Start the SMTP daemon with the root account by issuing this command:
  
  /usr/exim/bin/exim -bd

Now your ZBTrap is ready to collect malware-infected computers' IP addresses.

The VM's timezone is currently set to UTC, which is important when you want to generate the IP list of the malware-infected computers for the previous day. Follow the procedure below to get the information you want.

• If you want the IP list for a certain day, issue the following commands the next day as the zbtrap user.
  
  cd;
/bin/sh ~/bin/get_expired_entries.sh > ~/expired_list.txt
  
  The file "expired_list.txt" contains the md5 string, message accepting time in UNIX epoch and source IP of expired messages (blocked by greylisting) from the previous day. If you are only interested in botnets' IPs, the 3rd column is what you want.
• If you want to report these suspected bots to someone who can check and clean them, you will need the mail header. I have recorded the header data in the mail server's mainlog file, located under /var/spool/exim/log. At 00:00 UTC, log rotation script will rename the old mainlog to mainlog.01, which is our input data. Issue the following commands to match the expired_list's md5 strings to the corresponding mail headers from mainlog.01, and print them out.
  
  cd;
< /var/spool/exim/log/mainlog.01 awk -v expired_list=expired_list.txt -f bin/generate_daily_logs_gl.awk > ~/conn_log.txt
  
  To view the mail headers from IP xxx.yyy.zzz.www, issue the following commands.
  
  cd;
< ~/conn_log.txt grep xxx.yyy.zzz.www | awk -f bin/show_mail_header.awk

If you encounter any difficulties when using ZBTrap, please post your problem here. I will do my best to answer them.

How could China cut spam so effectively?

This week I have read many articles talking about one thing: spam from China has greatly reduced. Regularly in the top five just two years ago, China is now ranked at number 18 on IronPort's list of spam-producing countries, and at number 20 according to Sophos. For China, a country with internet population bigger than population of the United States, this is no simple feat. In comparison, the U.S. is still the top-spamming country, according to Sophos.

In fact, IronPort's "finding" has lagged by more than a year. Other groups already pointed out similiar facts long ago, for example:

• ICSA Labs reported that "spam originating in China plummeted 65%" (Jan 04, 2010)
• Sophos reported that "China dramatically disappears from list of worse spam-relaying nations for the first time" (Apr 28, 2010)

But most people have no idea how China achieved that. Some refered to an anti-spam initiative in 2006, but it was not until the second half of 2009 when spam from China started to drop off dramatically. Other mentioned the stricter control China put on ".cn" domain registration, but forgot that when talking about spam source, we are only concerned about their IP addresses, which have nothing to do with their domain names. Everyone seems to be a bit clueless, so I might as well give my two cents.

What has caused spam from China to drop did not set out to do so.

DISAN: a proposed framework for botnet mitigation

With the limited experience I gained from botnet detection and notification last year, I am going to propose a botnet mitigation framwork here, in the hope to solve the botnet threat we face currently. While still sounding like a very serious problem today, in reality botnets have shrunk quite a bit, as evident from the global spam drop observed in the second half of 2010. So the framework I am proposing is meant to reinforce what has already been done right.

The primary objective of this framework will be to find out the locations of botnets (that is, their IP addresses), and subsequently notify the unknowning victims. The framework will comprise three parts: detection, information sharing, and notification. Let's just call it "DISAN." The "A" from the word "and" is kept for ease of pronounciation.

The keyword for the detection part is "diversity," which mainly applies to how and where (in the cyber world) to detect botnets. Most detection methods work by monitoring various abnormal network behaviors that botnets exhibit, like sending spam, DDoS, etc. Different monitoring mechanisms are going to uncover differnet botnets, so it is necessary to diversify the detection approaches. As botnets are not evenly distributed in the Internet, it is also better to scatter the detection systems around the globe as diversely as possible. Various VPS offerings can help us achieve that.

The keyword for the information sharing part is "trust." Detection is not needed if you can get information about botnets from somebody else. But if you don't trust them, the usefulness of the information to you will be problematic. Likewise, if the information providers don't trust you, they might be reluctant to share with you the IP addresses of botnets, which are potentially vulnerable computers. So it would be better if information providers and recipients belong to an existing structure (like workgroups, taskforce, etc.), and already have mutual trust among them.

The keyword for the last part, notification, is "awareness." The only reason why botnets are such a formidable threat today, is because the victims do not know that their computers have been compromised. Then as time goes by, botnet herders are destined to have many zombie computers waiting for their commands. Without the victims cleaning the computers and fixing the vulnerabilities, efforts like taking C&C servers offline are futile, as I pointed out in my previous post.

Merely taking C&C servers offline is not going to destroy botnets

Everybody knows that the destructive power of botnets lies in their massive number.  While those malware-infected computers often have unpatched vulnerabilities, which makes them easy to compromise, it still takes a long time to get hold of so many computers.  The only reason hackers can construct botnets is because most victims are completely unaware that their computers have been compromised.

Now most botnet mitigation efforts, from the disconnection of McColo in 2008 to the recent Bredolab takedown by Dutch police, try to bring down botnets by taking C&C servers offline.  While it is a good step, merely doing that is not enough.  They often fail to notify the victims.  Thus the vulnerabilities within those zombie computers will remain unfixed, and it is just a matter of time before hackers take control of those computers again.  In my point of view, botnet notification should be a priority, so victims can fix the security loopholes inside their computers.

Notifying victims also addresses other problems.  For example, botnets can collect data about people, which are sometimes used in phone scams.  If victims know their computers have been compromised, they will beware of suspicious phone calls, and change their passwords as soon as possible.  That helps to limit the scope of damage caused by botnets.