topic SMTP attachment analysis on Firepower in Network Security

SMTP attachment analysis on Firepower

HQuest — Tue, 12 Mar 2019 13:26:40 GMT

I have set up a lab with a fully licensed ASA+FP device in front of a TLS enabled SMTP server. Created a rule to decrypt SSL traffic using its own certificate+key, to a set of TCP ports to this SMTP server IP address. I also turned on file detection and SSL decryption on the ACL policies applied in the device. IPS/NAP policies are the default Balanced ones.

However when I email the EICAR file to an account on this server, I have no records on FMC that this file went thru. I was expecting, as FMC records a malware entry when I download the EICAR file from a web server, to have an entry recorded for the SMTP session as well.

Anyone could provide me more info on this?

Last but not least, I fully understand the performance limitations and impact of such scenario.

Appreciated for any hints/guidance.

Are you seeing a connection

Marvin Rhoads — Mon, 03 Jul 2017 08:58:41 GMT

Are you seeing a connection event at all? If not, make sure the routing is via the ASA and that the ASA class-map / policy-map redirects the traffic to the module.

If so, then what does it show?

I do see all the connection

HQuest — Mon, 03 Jul 2017 11:48:02 GMT

I do see all the connection events being logged whenever the remote server talks to my internal SMTP server, so routing does not seems to be an issue.

I can see on the connection events basically a confirmation that all my rules are applied and matched, however the mail client still receives the eicar file.

[Edit] attached a picture instead of a clunky table - easier on the eyes.

[Edit 2] seems I forgot a few keywords on my OP. The file inspection do record a malware entry found during the HTTP transfer of the eicar file, but not from a SMTP attachment. This makes a world of a difference from my original question. Updating it accordingly to be clear should anyone else browses it.

I see the logic and would

Marvin Rhoads — Mon, 03 Jul 2017 13:27:44 GMT

I see the logic and would think it should all do as you originally intended.

This is a good question and I have sometimes wondered about the distinction myself - i.e., "If I have AMP for Networks on the FirePOWER device or module then why do I also need AMP licensing on an ESA?".

I'm moving this thread into the FirePOWER forum in hopes that one of the Cisco TAC staff who monitor that forum will chime in with an answer.

Hi Alexandre,

Massimo Baschieri — Mon, 03 Jul 2017 15:06:41 GMT

Hi Alexandre,

I've no idea why you your sensor is not intercepting the malware, but if were you I try to make things simple: have you tried to send the same attachement from a non SSL enabled mail server, in order to exclude decryption from the equation?

Hello Massimo.

HQuest — Mon, 03 Jul 2017 15:56:16 GMT

Hello Massimo.

Yes, I did. It does not change anything. See below for a plain SMTP session (no STARTTLS) output. And yet, FMC has the packets listed in the Connection Events, but no Malware has been recorded by the Files dashboard.

3 10:36:30.00 INFO: Opening connection to (mx.example.com) port (25)
3 10:36:30.00 <-- 220 *****************************************************
3 10:36:30.00 --> ehlo me.com
3 10:36:30.00 <-- 250-mx.example.com Hello netwin.netwinsite.com [198.1.73.205], pleased to meet you
3 10:36:30.00 <-- 250-ENHANCEDSTATUSCODES
3 10:36:30.00 <-- 250-PIPELINING
3 10:36:30.00 <-- 250-8BITMIME
3 10:36:30.00 <-- 250-SIZE
3 10:36:30.00 <-- 250-DSN
3 10:36:30.00 <-- 250-ETRN
3 10:36:30.00 <-- 250-AUTH DIGEST-MD5 CRAM-MD5
3 10:36:30.00 <-- 250-STARTTLS
3 10:36:30.00 <-- 250-XXXXXXXXA
3 10:36:30.00 <-- 250 XXXB
3 10:36:30.00 --> mail from:<hquest@example.com>
3 10:36:30.00 <-- 250 2.1.0 <hquest@example.com>... Sender ok
3 10:36:30.00 --> rcpt to:<hquest@example.com>
3 10:36:31.00 <-- 250 2.1.5 <hquest@example.com>... Recipient ok
3 10:36:31.00 --> DATA
3 10:36:31.00 <-- 354 Enter mail, end with "." on a line by itself
3 10:36:31.00 --> From: hquest@example.com
3 10:36:31.00 --> To: hquest@example.com
3 10:36:31.00 --> x-test-header: Test message from http://reputation-email.com
3 10:36:31.00 --> Mime-Version: 1.0
3 10:36:31.00 --> Content-Type: application/octet-stream;
3 10:36:31.00 --> Content-Disposition: attachment; filename="eicar.com";
3 10:36:31.00 --> Subject: Test message from reputation-email.com - EICAR test virus attached
3 10:36:31.00 -->
3 10:36:31.00 --> X5O!P%@AP[4\PZX54(P^)7CC)7}$EICAR-STANDARD-ANTIVIRUS-TEST-FILE!$H+H*
3 10:36:31.00 --> .
3 10:36:31.00 <-- 250 2.0.0 v63FaU5D098202 Message accepted for delivery
3 10:36:31.00 --> quit
3 10:36:31.00 <-- 221 2.0.0 mx.example.com closing connection

Can you see the file transfer

Massimo Baschieri — Mon, 03 Jul 2017 16:09:38 GMT

Can you see the file transfer logged in Analysis/files/file events/table view?

Nope. I have a .jar file but

HQuest — Mon, 03 Jul 2017 16:13:53 GMT

Nope. I have a .jar file but not the SMTP attachments.

Sorry if I ask, but are sure

Massimo Baschieri — Mon, 03 Jul 2017 16:20:07 GMT

Sorry if I ask, but are sure that smtp protocol is enabled in your file policy for the right direction?

I think so - see the

HQuest — Mon, 03 Jul 2017 16:37:33 GMT

I think so - see the Inspection policy and file inspection screen capture attachments. More specifically, SMTP is listed under the detailed rule.

That's access policy, can you

Massimo Baschieri — Mon, 03 Jul 2017 16:41:57 GMT

That's access policy, can you check file policy also?

Sorry, I missed file policy

Massimo Baschieri — Mon, 03 Jul 2017 16:46:38 GMT

Sorry, I missed file policy in your previous post.

If file policy is the same applied to http traffic afaik it should work, have you considered to open a tac case?

What about rule 2?

Massimo Baschieri — Mon, 03 Jul 2017 16:53:47 GMT

What about rule 2?

That rule seems to match any kind of traffic, that way rules 3 and 4 should never been matched.

Have tried to disable it?

Rule #2 is a monitor; it logs

HQuest — Mon, 03 Jul 2017 19:11:44 GMT

Rule #2 is a monitor; it logs all traffic and moves down for next rules to be processed. Rule #3 is HTTP/HTTPS traffic only, so SMTP moves down to the next rule. Earlier I've posted another screen capture showing both monitor and mail inspection rules being matched, so I'm pretty certain the rules are being parsed and processed, however the attachment is not being detected/understood.

I will have a TAC case submit and will update later what the outcome is. Thanks anyway for your suggestions.

Well, so far good news and

HQuest — Mon, 03 Jul 2017 21:36:02 GMT

Well, so far good news and bad news.

The good news is, my rules are spot on for what I need.

The bad news is, TAC needs to research why FP is not finding the malware on SMTP traffic. And IMAP traffic. And POP3. Encrypted or not...

More to come.

Thanks again for all the suggestions.

It sounds like a bug at this

Marvin Rhoads — Tue, 04 Jul 2017 08:30:36 GMT

It sounds like a bug at this point. Please do keep us updated with the TAC's findings.

Regards.

- Marvin

You are right, I was doing a

Massimo Baschieri — Tue, 04 Jul 2017 10:19:05 GMT

You are right, I was doing a lot of things at the same time and I replied to quickly.

I agree with Marvin, it sounds like a bug.

Since sometimes bugs are very funny, you can try to move rule 2 below rule 4 and see what happens.

We found out the EICAR is

HQuest — Wed, 05 Jul 2017 22:47:15 GMT

We found out the EICAR is detected via SMTP, when sent as a .txt file attachment. Which is good, the engine is "working".

But if sent as an attachment in an executable file form of "eicar.com" (the way it was originally conceived as), or if inside a compressed file (with no password), it goes un-noticed by the AMP/FP engine. While the email client is smart enough to block certain file extensions, this can be disabled.

More to come...

Ok, this ended in between a

HQuest — Fri, 07 Jul 2017 19:55:34 GMT

Ok, this ended in between a funny and sad resolution.

TAC found out if you email the file (as text or compressed) using Mozilla Thunderbird client, AMP/FP detects the threat. If you use any other ways to send it (via web application connecting directly to your SMTP port or via other SMTP servers delivering a pre-made message), it passes thru. The email client and the desktop anti-virus picks up the threat inside the email message and blocks it. So "The problem is the way in which the page sends the email, the structure of the email." and "The Firepower is working properly.", as they closed my case with such resolution.

At the same time, other firewall products with similar threat detection features detects all kinds of files AMP/FP is missing, so I think we have our answer now.

Thanks all for your time and suggestions. Now I need to make a reminder to malware makers to follow only standard rules when delivering malware so Cisco can catch them...

I agree that sounds like a

Marvin Rhoads — Sat, 08 Jul 2017 11:25:45 GMT

I agree that sounds like a pretty lame reply.

If it were my case, I'd make note of it in the customer satisfaction survey they send after case closure.