How do spammers do this??

Server1 is getting the connection from the Russians.
Yes well, to be fair, it's .ru and .cz mail addresses and now .it too, but it's all kind of ip's, Russion, mainly Chinese, Brazilian, India and others trying this. It's coming from all over the world.

I would understand your thought that I would have a verify = recipient/callout in there somewhere, however this can not be the case as I'm using a default exim.conf and never did changes in there.

Last night we discovered something odd. In the named query log, we had a query to the customerdomain.nl (the attacked domain) on server 1, and this query was every second. So I rebooted the server and then it was silent.
So I thought maybe they managed to create some dns cache somehow and were able to do it that way.
But at this moment the secondly queries are not present anymore, still for some reason, server 1 is calling out to server 2 but only from this botnet. Both mxroute and myself tested from other servers and were not able to get through.

you can put your own blocklist URL
Yep I know, I already have a couple active. Bot this botnet only contains over 10.000 ip addresses. And I already blocked complete airtail india ip ranges already on the server's router.
For the main server this might not be a very big thing, but for the VPS, this is probably a no go.

The ip's are massive and change every time.
Little impression from ip's used only the last hour:
2.55.65.70
38.146.70.108
43.130.32.108
61.160.114.34
109.103.24.40
122.114.192.168
140.246.231.36
177.33.75.74
182.70.252.174
183.230.197.49
188.126.60.175
190.244.124.230
194.186.138.214
203.124.61.141
209.97.143.188
211.216.58.204
218.156.36.147
243.144.180.122
 
The ip's are massive and change every time

Last time I checked deeply it was:

- 96 recipients per IP, IP never seen twice
- mostly the same .ru and .cz sender domains with the occasional addition to their sender domain list
- Never, EVER, targeted to a server that actually houses the recipient domain. Never. Not once, that I saw. BUT, it was always to a domain that USED to reside on that server.

That last point is interesting to me because it's almost like they had a list of former customers, and were able to sort them out differently than current customers. Even if the former customer still had their MX pointed to the server, and they usually did.

It really feels like they're exploiting something, the variables are so strange. But if it were some kind of spam reflection attack, we'd have abuse complaints. But since they never email anyone I can actually deliver to, I've never once been able to collect a spam sample. If I add a domain with a catchall that they were trying to hit, they never try that domain again.
 
- mostly the same .ru and .cz sender domains with the occasional addition to their sender domain list
I'm sometimes seeing ip's twice or more and next also switching .ru and .cz addresses and now also using .it and .com addresses in my log.
So it looks as if they are trying to change things.

It really feels like they're exploiting something, the variables are so strange.
I had something in my logs which was very odd. Maybe by mistake, that it went in there. If I encouter it again I will post it. If I remember correctly it was a refusal because too many different variables were used. I didn't see that before either, but maybe you did.
 
Interesting. They are not really hiding. After blocking this 172.70.255.196 ip, I get this info.
Code:
2023-09-03 19:10:11 BlacklistCheck: Blacklisted address - 182.70.255.196
2023-09-03 19:10:11 H=(abts-mp-dynamic-196.255.70.182.airtelbroadband.in) [182.70.255.196] F=<[email protected]> rejected RCPT <[email protected]>: authentication required
International people. India dynamic user, logging in to probably botnet in South Africa, which sends mail supposingly coming from .ru to our server1.
 
Well if I put:

warn verify = recipient/callout=use_sender

Just before the section:

accept hosts = +auth_relay_hosts
endpass
message = AUTH_REQUIRED
authenticated = *


In the exim.conf file of Server1 - restart exim on that server - and I am able to duplicate this.


With the above recipient callout in place on Server1, if I connect to Server1 from Server3

telnet Server1 25

EHLO something.tld
mail from: <[email protected]>
rcpt to: <[email protected]>
quit


Then the logs on Server1 will show:

2023-09-03 15:16:26.621 [199394] SMTP connection from [Server3IP]:60046 I=[Server1IP]:25 (TCP/IP connection count = 1)
2023-09-03 15:16:47.768 [199489] H=Server3 [Server3IP]:60046 I=[Server1IP]:25 F=<[email protected]> rejected RCPT <[email protected]>: authentication required
2023-09-03 15:16:49.499 [199489] H=Server3 [Server3IP]:60046 I=[Server1IP]:25 incomplete transaction (QUIT) from <[email protected]>
2023-09-03 15:16:49.500 [199489] SMTP connection from Server3 [Server3IP]:60046 I=[Server1IP]:25 closed by QUIT


And the logs on Server2 will show:

2023-09-03 13:16:47.478 [17710] H=Server1 [Server1IP]:46946 I=[Server2IP]:25 X=TLS1.2:ECDHE-RSA-AES128-GCM-SHA256:128 CV=no F=<[email protected]> rejected RCPT <[email protected]>: Unrouteable address
2023-09-03 13:16:47.530 [17710] H=Server1 [Server1IP]:46946 I=[Server2IP]:25 incomplete transaction (QUIT) from <[email protected]>


Of note - I am using log_selector = +all in my exim configuration - I tend to like it because it gives a lot of logging verbosity. But this appears to be duplicating what you are seeing.

That doesn't necessarily mean that it is what's happening in your case, but it does appear to show a duplication of this.
 
That doesn't necessarily mean that it is what's happening in your case, but it does appear to show a duplication of this.
First of all, thank you for thinking with me on this. I'm sure you are right and the test is correct.
But it's indeed not happening in my case, as I've got a default exim.conf and if it was the case, the test of either mxroute or me would show the same thing.
Ofcourse to be sure I did doublecheck, just to prevent some malware wouldn't have adjusted my exim.conf file, but I don't have any warn verify setting present in the exim.conf.
It's not quite the same, as server 2 does not state any "unrouteable address", but that could be caused because the domain is in fact existing on server 2 in my case. It looks indeed fairly the same.

However with this test you made me thinking, and you still might be on to something.
I have encountered some lines in the logfile like this:
Code:
2023-09-03 03:35:13 SMTP call from [205.210.31.157] dropped: too many unrecognized commands (last was "")
Now I do have the "normal" attacks to local and non existing domains on server 1.
And we do have the test from ourselves, that we did not get any link to server 2. No odd things so far.

But when looking at this line, combined with the test that you did, I'm wondering if they found a method somehow, to add some commands in the smtp string (dns or other commands, I don't know) which could cause Exim to indeed use this verify callout, even if not configured in exim.conf.
Because if that is the cause, that would explain a lot of things.

Because it's only that botnet which achieves this issue, all other attacks do not get to server 2.
Could this be the case @mxroute? It would explain why they achieve this, and we don't with our telnet tests and others also will be blocked as should be.

Edit: Found some more of these notices in the Exim mainlog, from China mainly, now more specific:
Code:
2023-08-31 05:40:30 SMTP call from [36.150.60.24] dropped: too many unrecognized commands (last was "Accept-Encoding: gzip, deflate")
2023-08-31 05:41:48 SMTP call from [205.210.31.4] dropped: too many unrecognized commands (last was "")
2023-08-31 05:42:03 SMTP call from [36.150.60.24] dropped: too many unrecognized commands (last was "Accept-Encoding: gzip, deflate")
2023-08-31 06:15:54 SMTP call from [36.150.60.24] dropped: too many unrecognized commands (last was "Accept-Encoding: gzip, deflate")
2023-08-31 13:35:15 SMTP call from [36.150.60.24] dropped: too many unrecognized commands (last was "Accept-Encoding: gzip, deflate")
2023-08-31 13:35:31 SMTP call from [36.150.60.24] dropped: too many unrecognized commands (last was "Accept-Encoding: gzip, deflate")
2023-08-31 13:37:01 SMTP call from [36.150.60.24] dropped: too many unrecognized commands (last was "Accept-Encoding: gzip, deflate")
2023-09-03 03:35:13 SMTP call from [205.210.31.157] dropped: too many unrecognized commands (last was "")

and one like this on server 2:
Code:
2023-08-27 18:49:03 SMTP call from [183.136.225.42] dropped: too many unrecognized commands (last was "Accept: */*")

And these on server 2:
Code:
2023-09-03 19:40:23 SMTP call from soda.census.shodan.io [71.6.135.131] dropped: too many syntax or protocol errors (last command was "?", NULL)
2023-09-03 19:40:23 SMTP call from soda.census.shodan.io [71.6.135.131] dropped: too many syntax or protocol errors (last command was "<C0>+<C0><AE>
<C0><AC><C0>#<C0>   <C0>\b?<9A>?<C4>?<88>?<BE>?E?<9F><C0><A3><C0><9F>?k?9?<9E><C0><A2><C0><9E>?g?3?\026\001??<CF>???\022?\020??\r161.xx.xx.xx?\027???
\001?\001\001<FF>\001?\001??", NULL)
2023-09-03 19:40:24 SMTP call from soda.census.shodan.io [71.6.135.131] dropped: too many syntax or protocol errors (last command was "?\b?\035?\027?\
030?\031?\v?\002\001??#???\020?0?.\bhttp/0.9\bhttp/1.0\006spdy/1\006spdy/2\006spdy/3\003h2c\002hq?\r?\024?\022\004\003\b\004\004\001\005\003\b\005\005
\001\b\006\006\001\002\001?3?&?$?\035? <B4>E<94>+<E9><8F><DD>`<E1><F3>ڬ<CF>i'<F8><92>\032<DA>\022$<97><B2>`<C9><F5>\022<85><9D>\026", NULL)
2023-09-03 19:40:24 SMTP call from soda.census.shodan.io [71.6.135.131] dropped: too many syntax or protocol errors (last command was "?", NULL)
2023-09-03 19:40:24 SMTP call from soda.census.shodan.io [71.6.135.131] dropped: too many syntax or protocol errors (last command was "?", NULL)
2023-09-03 19:40:25 SMTP call from soda.census.shodan.io [71.6.135.131] dropped: too many syntax or protocol errors (last command was "?", NULL)
I really wonder if that is related somehow.

Edit: That one line with code has some \r161.xx.xx.xx which is the secondary ip of server 2, just noticed that.
 
Last edited:
@mxroute
I've just seen this yesterday.

Could this be related to the odd thing we were investigating?
That they could relay to another server using arbitrary code, while it was refused when we tried?
 
@mxroute
I've just seen this yesterday.

Could this be related to the odd thing we were investigating?
That they could relay to another server using arbitrary code, while it was refused when we tried?

While that was always one of my concerns with this activity, I just don’t think the pieces fit to show that they were exploiting anything. You just can’t silently relay that many emails through our servers without every one of us standing up and saying “Why am I getting abuse complaints for spam that isn’t in my logs?”

If it were of deeper significance than relaying spam, I just don’t see the evidence for it yet either.
 
Back
Top