Scribd
Upload
2 views

JMR Group2

The document outlines an investigation into mail issues at JMR Group, focusing on mail spoofing, SPF and MX records, malware, email security, and domain computers. Key findings include issues with email authentication, potential vulnerabilities on user machines, and the need for a secure mail facility. Recommendations include improving password policies, ensuring all computers are domain-configured, and considering a comprehensive infrastructure review.

Uploaded by

jkruger40
Copyright
© © All Rights Reserved
Available Formats
Download as PDF, TXT or read online on Scribd
2 views

JMR Group2

The document outlines an investigation into mail issues at JMR Group, focusing on mail spoofing, SPF and MX records, malware, email security, and domain computers. Key findings include issues with email authentication, potential vulnerabilities on user machines, and the need for a secure mail facility. Recommendations include improving password policies, ensuring all computers are domain-configured, and considering a comprehensive infrastructure review.

Uploaded by

jkruger40
Copyright
© © All Rights Reserved
Available Formats
Download as PDF, TXT or read online on Scribd
You are on page 1/ 4

Hi Barend/Sebastian

The below is a breakdown of the investigation into mail issues experienced currently at JMR Group

1. Mail “Spoofing”
2. SPF records
3. MX Records
4. Malware/Spyware
5. Email passwords
6. Mail security vendor
7. Domain computers

Mail “Spoofing”
I looked at the original email received by Vanessa. The headers, provides all the info regarding and email.
(where it came from, to who, what server was used etc.)
The headers provided me with the following information:

Received: from AM0P193MB0434.EURP193.PROD.OUTLOOK.COM (2603:10a6:3:fa::12) by


HE1P193MB0186.EURP193.PROD.OUTLOOK.COM with HTTPS via
HE1PR05CA0212.EURPRD05.PROD.OUTLOOK.COM; Tue, 5 Mar 2019 09:28:54 +0000
Authentication-Results: jmrgroup.co.za; dkim=none (message not signed)
header.d=none;jmrgroup.co.za; dmarc=none action=none
header.from=jmrgroup.co.za;
Received: from AM0P193MB0372.EURP193.PROD.OUTLOOK.COM (52.134.95.30) by
AM0P193MB0434.EURP193.PROD.OUTLOOK.COM (52.134.92.14) with Microsoft SMTP
Server (version=TLS1_2, cipher=TLS_ECDHE_RSA_WITH_AES_256_GCM_SHA384) id
15.20.1665.16; Tue, 5 Mar 2019 09:28:51 +0000
Received: from AM0P193MB0372.EURP193.PROD.OUTLOOK.COM
([fe80::c9ef:1f5:4b5a:4ab2]) by AM0P193MB0372.EURP193.PROD.OUTLOOK.COM
([fe80::c9ef:1f5:4b5a:4ab2%3]) with mapi id 15.20.1665.020; Tue, 5 Mar 2019
09:28:51 +0000
Content-Type: application/ms-tnef; name="winmail.dat"
Content-Transfer-Encoding: binary
From: Barend Buys <[email protected]>
To: Vanessa Kompire <[email protected]>
Subject: TAX INVOICE - INV2019040321
Thread-Topic: TAX INVOICE - INV2019040321
Thread-Index: AQHUuD9hEAmxVJPeXUmKaHTaqMSTEw==
Disposition-Notification-To: Barend Buys <[email protected]>
Return-Receipt-To: <[email protected]>
Date: Tue, 5 Mar 2019 09:28:51 +0000
Message-ID:
<AM0P193MB037245ABD383F2A42D216631F9900@AM0P193MB0372.EURP193.PROD.OUTLOOK.COM>
Accept-Language: en-ZA, en-US
Content-Language: en-ZA
X-MS-Has-Attach: yes
X-MS-Exchange-Organization-SCL: -1
X-MS-TNEF-Correlator:
AM0P193MB037245ABD383F2A42D216631F9900@AM0P193MB0372.EURP193.PROD.OUTLOOK.COM

 Sender: [email protected]
 Recipient: [email protected]
 Sending Server: AM0P193MB0434.EURP193.PROD.OUTLOOK.COM
 Security: Authentication-Results: jmrgroup.co.za; dkim=none (message not signed)
The above seems to be correct and in line with expected results when looking at an email sent within the
company.
The security line is the one that seems to be an issue. The emails are not being digitally signed which
means the SPF records were not correct at the time or not working correctly.
We need to discuss this with the current mail provider and see if they can shed some light on why the SPF
records are not producing the correct results.
An Example of the correct result should be:
Authentication-Results: spf=pass (sender IP is ???.???.???.???) your domain; dkim=pass (signature was verified)
This may also be the result of a “spoofed” email, but I would have expected a different sending mail
server if this was the case.

SPF records
I have checked the SPF records and found the following:
jmrgroup.co.za text =

"MS=ms25024245"
jmrgroup.co.za text =

"v=spf1 include:spf.protection.outlook.com include:spf-za.rocketseed.com ~all"

I am not sure what rocketseed.com is. I have included a URL for your information.
https://www.rocketseed.com

MX Records
Hetzner handles the MX records
primary name server = ns1.host-h.net
jmrgroup.co.za MX preference = 10, mail exchanger = jmrgroup-co-za.mail.protection.outlook.com

These seem to be correct.

Malware/Spyware
Although the machines were scanned with a virus scanner, in this case ESET. Barend’s machine still has
the following vulnerability on the machine. I have deleted this file.
There may be a reason for the above being on the machine but Malware/Spyware uses torrents to
spread. The use of torrents should not be allowed with-in the JMR Group domain.

Email passwords
Email passwords is one of the best ways to protect your email. These should be at least 8 char long,
included numeric, special char and capitals. The default 365 password profile should be used if a proper
password policy is not in place.

Mail security vendor


JMR Group should consider the possibility of a secure mail facility which will scan email for all mail
vulnerabilities. These include providers like Mimecast, SecureMail etc. The most popular is Mimecast

Domain computers
All computers should be included in the domain configuration, which will help maintenance and support. I
know there is some computers, which are not part of the domain, which means they do not get the
domain policies that could lead to “un- protected” machines.
Members: JC Kruger, R Crichton
Fees
It is very difficult to provide timelines and pricing to get all of the above setup “correctly”. I suggest we
work on a normal T/M basis. Most of the issues could be resolved by Sebastian, which may need some
input for us but does not require us to be onsite for extended periods.
I am also of the opinion that the infrastructure should be looked into as a whole and not just a portion i.e.
JHB branch, the reason is that “un-protected” access to the system could compromise all the good work
done in JHB.

Regards

Jacob Kruger

You might also like