Author Topic: Compromised mail  (Read 4561 times)

0 Members and 1 Guest are viewing this topic.

Offline
*
Compromised mail
« on: March 27, 2020, 10:58:08 AM »
Hello, how do I know if my mail server is compromised?
If you write an email to one of my clients, you will always get an email from a Russian server, which I have nothing to do with.
This is the message it sends back.

forward2office@mail.ua
Remote Server returned '554 5.4.0 < #4.4.1 X-Postfix; connect to mxs.mail.ru[94.100.180.104]:25: Connection timed out>'
 
Encabezados de mensajes originales:
 
Return-Path: <withheld for security reasons>
Received: by host.bytecanarias.work (Postfix, from userid 101)
        id 69878900BC7; Thu, 26 Mar 2020 20:00:20 +0000 (GMT)
X-Sieve: Pigeonhole Sieve 0.4.24 (124e06aa)
X-Sieve-Redirected-From: withheld for security reasons
Delivered-To: withheld for security reasons
Received: from localhost (unknown [127.0.0.1])
        by host.bytecanarias.work (Postfix) with ESMTP id 59EBC9005D5
        for <withheld for security reasons>; Thu, 26 Mar 2020 20:00:20 +0000 (UTC)
X-Virus-Scanned: amavisd-new at bytecanarias.work
Received: from host.bytecanarias.work ([127.0.0.1])
        by localhost (host.bytecanarias.work [127.0.0.1]) (amavisd-new, port 10024)
        with ESMTP id hs_r8si4EHlt for <withheld for security reasons>;
        Thu, 26 Mar 2020 20:00:14 +0000 (GMT)
Received: from smtpout1.r2.mail-out.ovh.net (smtpout1.r2.mail-out.ovh.net [54.36.141.1])
        (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits))
        (No client certificate requested)
        by host.bytecanarias.work (Postfix) with ESMTPS id AD0609005D7
        for <withheld for security reasons>; Thu, 26 Mar 2020 20:00:14 +0000 (GMT)
Received: from ex3.mail.ovh.net (unknown [10.109.143.189])
        by mo511.mail-out.ovh.net (Postfix) with ESMTPS id 5BB53D1C926B
        for <withheld for security reasons>; Thu, 26 Mar 2020 21:00:14 +0100 (CET)
Received: from DAG5EX3.indiv3.local (172.16.2.20) by DAG5EX3.indiv3.local
 (172.16.2.20) with Microsoft SMTP Server (version=TLS1_2,
 cipher=TLS_ECDHE_RSA_WITH_AES_128_GCM_SHA256) id 15.1.1913.5; Thu, 26 Mar
 2020 21:00:13 +0100
Received: from DAG5EX3.indiv3.local ([fe80::a912:a56d:69ec:3645]) by
 DAG5EX3.indiv3.local ([fe80::a912:a56d:69ec:3645%2]) with mapi id
 15.01.1913.007; Thu, 26 Mar 2020 21:00:13 +0100
From: =?iso-8859-1?Q?Direcci=F3n?= <withheld for security reasons>
To: CARUMAQ SL <withheld for security reasons>
Subject: CERTIFICADO
Thread-Topic: CERTIFICADO
Thread-Index: AdYDqRkq9c7lIpW8RjKQwcNtrIYHZw==
Date: Thu, 26 Mar 2020 20:00:13 +0000
Message-ID: <7e3fe5605ee64234b9f6b09e29d5e1a1@gestidoasesores.com>
Accept-Language: es-ES, en-US
Content-Language: es-ES
X-MS-Has-Attach: yes
X-MS-TNEF-Correlator:
x-originating-ip: [83.40.14.70]
Content-Type: text/plain
MIME-Version: 1.0
X-Ovh-Tracer-Id: 706502192279941469
X-VR-SPAMSTATE: OK
X-VR-SPAMSCORE: 0
X-VR-SPAMCAUSE:

Re: Compromised mail
« Reply #1 on: March 27, 2020, 11:16:04 AM »
A quick scan, makes me notice quite a few private IPs. I assume that you're using an external SMTP service (at OVH?).
(Check your /root/.forward)

Is forward2office@mail.ua an intended recipient?

It's difficult to debug with so many redacted recipients in the email chain - it maybe that one of the forwarders has the compromised transport. Try to use a different external SMTP service, if indeed that is what you have setup.

Offline
*
Re: Compromised mail
« Reply #2 on: March 27, 2020, 11:30:51 AM »
Hi, the OVH server is from a client who has written to my client who is hosted in my VPS, the coincidence that both clients work with me, then the OVH client has forwarded me the message that has arrived. Which is the one I posted.

No this is not a forward2office@mail.ua intended recipient, but I am in Spain and my clients also have no relationship with that server.

A quick scan, makes me notice quite a few private IPs. I assume that you're using an external SMTP service (at OVH?).
(Check your /root/.forward)

Is forward2office@mail.ua an intended recipient?

It's difficult to debug with so many redacted recipients in the email chain - it maybe that one of the forwarders has the compromised transport. Try to use a different external SMTP service, if indeed that is what you have setup.
« Last Edit: March 27, 2020, 11:37:06 AM by bytecanarias »

Re: Compromised mail
« Reply #3 on: March 27, 2020, 12:22:42 PM »
You still haven't said whether local email server or a remote one.  :-\
Determine which application the sender is using to send email. If web-based, look for changes to the email portions of the program.
Can they send direct to you via the same method? Can they send via roundcube?
In essence, you are going to have to try various tests and debug/check logs along the way.

Offline
*
Re: Compromised mail
« Reply #4 on: March 27, 2020, 12:37:31 PM »
The mail server is local and my client uses it to send Outlook. They don't use the Webmail version

They can send normal, without any problem, but those who send emails to them always receive a response from that Russian server, saying that it is spam, but the email to my client is delivered correctly.
But whoever sends it is left wondering if it has been delivered or not.
So I don't know who is compromised if my server or my client, because of the 17 clients that I have in the same vps, it only happens to me with 1.

You still haven't said whether local email server or a remote one.  :-\
Determine which application the sender is using to send email. If web-based, look for changes to the email portions of the program.
Can they send direct to you via the same method? Can they send via roundcube?
In essence, you are going to have to try various tests and debug/check logs along the way.

Re: Compromised mail
« Reply #5 on: March 27, 2020, 12:55:59 PM »
The mail server is local and my client uses it to send Outlook...
So I don't know who is compromised if my server or my client, because of the 17 clients that I have in the same vps, it only happens to me with 1.
Sounds to me like the issue is only with that single client then.
Get them to send out an email with webmail - if that works then it looks like their local PC (Outlook) is compromised. Windoze/Mac luser? :-p

Offline
*
Re: Compromised mail
« Reply #6 on: March 27, 2020, 01:00:32 PM »
Well I have checked one thing, of the 17 email accounts you have, for now I have only done the test with two.
If I write to one of those accounts it doesn't return the damn Russian message.
But if I write to the administration account of the company if it returns the message of Spam.
At this time, the computer that receives the administration emails is turned off, so I also rule out that it is the client's computer.
But still I will review it just in case.

The mail server is local and my client uses it to send Outlook...
So I don't know who is compromised if my server or my client, because of the 17 clients that I have in the same vps, it only happens to me with 1.
Sounds to me like the issue is only with that single client then.
Get them to send out an email with webmail - if that works then it looks like their local PC (Outlook) is compromised. Windoze/Mac luser? :-p

Re: Compromised mail
« Reply #7 on: March 27, 2020, 01:35:18 PM »
Well I have checked one thing, of the 17 email accounts you have, for now I have only done the test with two.
If I write to one of those accounts it doesn't return the damn Russian message.
But if I write to the administration account of the company if it returns the message of Spam.
At this time, the computer that receives the administration emails is turned off, so I also rule out that it is the client's computer.
Check for a forwarder/alias on the administrator email.

Offline
*
Re: Compromised mail
« Reply #8 on: March 27, 2020, 09:07:00 PM »
No forwarder/alias


Well I have checked one thing, of the 17 email accounts you have, for now I have only done the test with two.
If I write to one of those accounts it doesn't return the damn Russian message.
But if I write to the administration account of the company if it returns the message of Spam.
At this time, the computer that receives the administration emails is turned off, so I also rule out that it is the client's computer.
Check for a forwarder/alias on the administrator email.