[rpd] Abuse reporting addresses in WHOIS records (?)

[Frank Habicht]

Hi Ronald.

[if not forged...]
the first 'Received' header suggests that the email was submitted into
the email system with authentication. As user 'brett' which was at that
time likely a compromised account.

It was submitted from an IP in Norway, but that could be by a machine
not completely under the control of the owner of the physical machine.

It was submitted to server 'sec-mgp-spt01.e-purifier.com' and the driver
(i mean sysadmin) of that one should (at the time) urgently change the
password for user 'brett'.

Who is the sysadmin?
I don't know, but I know Andrew should know who it is, or at least know
someone who knows who it is, or at least be able to get you into contact
with people who can get you in contact with people....
[yes, doesn't sound like pure fun]

$ dig sec-mgp-spt01.e-purifier.com +short
41.168.2.14
$ whois -h whois.afrinic.net -- 41.168.2.14 | egrep '^person'| head -n 1
person:         Andrew Alston
$

So, enough picking on Andrew.
Since he's in Kenya and the IP is in Zimbabwe, you could also try
another person in the list from
$ whois -h whois.afrinic.net -- 41.168.2.14

I get an email address, if I run:
whois -h whois.afrinic.net -- -B KR12 - AFRINIC
... with the last 2 spaces in that line removed!
So I'd suggest emailing Keith (apparently in ZW) with Andrew in CC.

One of them should really be able to get you into contact with the
sysadmin of the server.
Note: which might be an employee of the same company, or a customer...!
[or a contractor of a customer!]

And if you include headers or pastebin into the first email to them, the
sysadmin can possibly already act before the first email round-trip.
[time is of essence when accounts are compromised and used for spamming,
and 'owners' of affected IPs have an interest to keep them as clean as
possible.]


But, this is all assuming that the first (lowest) Received header was
not put in there for confusion and false accusation by someone later in
the email path!!!


To find out about that you'd have to try to contact in a similar way the
operator of the server that sent the email directly to your first
machine in the path.

If you had multiple machines in the path (which seems not the case
here), you would check the machine that got the email from a place
outside your control.

Received:  from delivery.imss.mtnbusiness.co.za
(delivery.imss.mtnbusiness.co.za [196.7.236.20])
	by segfault.tristatelogic.com (Postfix) with ESMTP id 6255F4E635
  	for <mrt at monkeys.com>; Wed, 29 Jul 2020 03:24:47 -0700 (PDT)

Anyone in the world _could_ point the reverse DNS for their IP to
'delivery.imss.mtnbusiness.co.za' - so i prefer not to look at the name,
but at the IP that sent to you: 196.7.236.20

Following the AS that is right now originating the (smallest) covering
prefix: 2905
Iana says check ARIN.
ARIN redirects to AfriNIC
AfriNIC has an ORG responsible for this AS and the ORG has 2 tech contacts.

$ whois -h whois.afrinic.net -- -B AT32 - AFRINIC
and
$ whois -h whois.afrinic.net -- -B AM158 - AFRINIC
[remove the last 2 spaces in these lines]
give email addresses.
Don't look at the changed: field - look at the e-mail: field.

Good news: both of these person objects have been updated less than a
year ago, so you have fresh data there.
The ORG object also updates 2020-04-01  :-)
... hopefully not as an April fools joke....

So they should be able to get you to the driver (sysadmin) of the email
server at IP 196.7.236.20
That person should be able to see in the logs that it really got the
email from IP 192.168.3.254  --  and we hope that they'd know that this
is a machine in the same organisation.
Either the same person administers 192.168.3.254, or can find out who
does ....

It's a guess whether the first Received header was forged and thus
whether the first method or the second get you faster to your goal.

This is how I'd do it, there might be better ways.
There will be no refunds, even if any kittens get hurt by this method.

Frank

PS: I believe there's a good chance that the issue was discovered
between 29 Jul 2020 and now, and also fixed.
if you don't do above research and send them notifications in 24 or 48
hours, i don't know ..... the issue might not exist any more.

email accounts get compromised.... all the time.
And then anyone who has the credentials can use any machine they control
(possibly illegally and remotely) to submit emails with authentication :-(


On 15/08/2020 19:34, Ronald F. Guilmette wrote:

> Is AFRINIC ever going to follow the lead of ARIN, RIPE, and APNIC and start

> putting network abuse contact email addresses into its various ASN and IP

> block WHOIS records?

> 

> I recieved the following spam awhile back and it isn't the least bit clear

> from the relevant AFRINIC WHOIS records (for *either* the ASN or the IPv4

> block) where I should report this.

> 

> https://pastebin.com/raw/D0YbsjCa

> 

> 

> _______________________________________________

> RPD mailing list

> RPD at afrinic.net

> https://lists.afrinic.net/mailman/listinfo/rpd

>