Create a Post
cancel
Showing results for 
Search instead for 
Did you mean: 
Shahar_Grober
Advisor

Sandblast and .msg attachments

Hi, 

Can it be that Check Point Threat Prevention and Sandblast in MTA doesn't scan "*.msg" attachments inside an email?

I did the following tests:

First Test (Baseline)

I sent a malicious .doc file attached to an email via the MTA 

Result: email is scanned and find malicious by the Gateway AV which is great!

Second Test 

I took the same malicious doc file and attached it to a message. Then I took the message saved it as a .msg file and attached it to another email so the attachment in the mail is .msg and not .doc file. 

Result: when I send the email, it is not scanned by AV or Threat Emulation, file is completly bypassed by AV/TE and arrives at the recipient mailbox with the infected .msg

Is it a configuration issue, a bug or a really simple way to evade Check Point Threat Prevention?

(Mime Nesting is configured on the Threat Prevention profile)

17 Replies
G_W_Albrecht
Legend
Legend

I would involve TAC here...

CCSE CCTE CCSM SMB Specialist
0 Kudos
Shahar_Grober
Advisor

Already did (please avoid generic answers)

Does anybody know what is the default behavior?

scanning files inside .msg should be a basic thing

0 Kudos
G_W_Albrecht
Legend
Legend

Then include that fact in your question, please ! .msg are just not supported as attachement file types for TE. Looks like a RFE is needed. Refer to sk106123 - File types supported by SandBlast Threat Emulation

CCSE CCTE CCSM SMB Specialist
Shahar_Grober
Advisor

Can anyone confirm that AV is not supported with MTA on R80.10?

If This is true then the .msg attachments will not be scanned by the MTA+TE. 

This is still basic feature that should be supported by TE 

0 Kudos
Thomas_Werner
Employee Alumnus
Employee Alumnus

Hi Shahar,

in general the "old" AB blade (which is streaming network traffic inspection BEFORE the MTA) is supported.

That said with R80.20 or R80.10 and latest MTA take we added AV support INSIDE MTA.

Mail Transfer Agent Update - What's New 

Regards Thomas

Shahar_Grober
Advisor

Thanks for the confirmation Thomas, 

This is a major improvement in R80.20. 

Is there a way to test if or confirm with R&D if .msg attachments are scanned by AV in this configuration?

0 Kudos
G_W_Albrecht
Legend
Legend

Do you already know sk112240: How to add support for new file types in Threat Extraction ?

CCSE CCTE CCSM SMB Specialist
Shahar_Grober
Advisor

Hi Günther,

This is an interesting information, but it doesn't address my question. 

I just want to know if a simple word doc or pdf attachments are scanned by AV/TE in MTA mode when nested inside a .msg file. this is not related to scrubbing additional file types. 

0 Kudos
Thomas_Werner
Employee Alumnus
Employee Alumnus

Hi Shahar,

so I learned from our MTA guys that we are already awesome 🙂

Our MTA parses attached .eml and .msg files, extracts and scans links and attachments.

Here a test I did with a GoldenEye ransomware attached to a .eml attached to an email:

GoldenEye inside .EML - Logcard

This is the scanned email arriving at the recipient with removed GoldenEye attachment

I also tested recursive .eml in .eml with GoldenEye attachment successfully:

Recursive .eml in .eml with GoldenEye removed

Regards Thomas

0 Kudos
Benoit_Verove
Contributor

Hi Thomas,

I'm running TE on a R80.20 gateway (jumbo take 33, MTA take 24).

Content of the EML attachement is extracted and  analysed. However, if it is a MSG attachement (with exactly same content), the attachments are not extracted nor analysed

In ted.log in debug mode, nothing about my .MSG tests

Do I miss something ? Could you please confirm that the MTA extracts content from the .MSG attachement ?

If so, I will contact TAC.

Regards,

Benoit

Shahar_Grober
Advisor

Thanks Thomas,

I see it is R80.20, should it work with R80.10 as well? 

0 Kudos
PhoneBoy
Admin
Admin

I think as long as you're running the latest engine updates, yes.

Shahar_Grober
Advisor

Thanks Dameon,


How can I see which mta version I have?

According to SK123174 the version should be in $FWDIR/conf/mta_ver but I couldn’t find the file on the gateway


0 Kudos
Thomas_Werner
Employee Alumnus
Employee Alumnus

Hi Shahar,

have you installed one of the updated R80.10 MTA takes ?

You should have similar in R80.10 when accessing the GAiA portal on https://<gwip>:

Afterwards you should get a populated $FWDIR/conf/mta_ver.

Regards Thomas

Shahar_Grober
Advisor

Hi Thomas,

I see that I have an update on my GW (T25 for R80.10), it wasn't there before I activated the MTA 

I have a few questions:

1. Why it is not updated automatically as with the TE engine?

2. Why the MTA is not automatically updated when activating the blade?

2. I guess the MTA update cause downtime? does it requires reboot?

4. is there a way to see the MTA version from tecli?

Thanks for the helpful information!

0 Kudos
Thomas_Werner
Employee Alumnus
Employee Alumnus

Hi Shahar,

1. Why it is not updated automatically as with the TE engine?

It is because it is a significant infrastructur part where you may want to have control.

Currently, also as this updateable MTA mechanism has been introduced only weeks ago, we implemented it as a manual CPUSE update process.

It may change in the future.

2. Why the MTA is not automatically updated when activating the blade?

See 1)

2. I guess the MTA update cause downtime? does it requires reboot?

No reboot required. I also have not experienced downtime so far.

But in production environments with redundant MTAs you may choose to take one offline during the update process.

4. is there a way to see the MTA version from tecli?

tecli is the Threat Emulation Daemon interface. It is not aware of the MTA other than knowing from which context a file arrived.


Regards Thomas

0 Kudos
Shahar_Grober
Advisor

Thanks again Thomas for the information,

I will update the MTA and test the AV functionality. 

I think that TECLI is a great tool and should have some reference to the MTA (postfix) since they are working dependently 

Leaderboard

Epsum factorial non deposit quid pro quo hic escorol.

Upcoming Events

    CheckMates Events