4 ms·

Actually, in a hypothetical corporate environment,if you go for the "safer" approach (ALL mails go through the mechanism) the whole stuff would (should) be inte

by jaclaz 3y ago

Actually, in a hypothetical corporate environment,if you go for the "safer" approach (ALL mails go through the mechanism) the whole stuff would (should) be integrated in the corporate mail server and mails would be analyzed BEFORE reaching the end user mailbox. For the "other" approach (only analyze the suspect ones submitted manually by the user) it would make more sense (to me) to have a portal (on the intranet) where you upload (safely) the suspect mail, rather than using a mailbox for the service. I am probably way too old in these times of "cloud everywhere" but if data remains "internal" it should be safer, at least in theory.

emalderson 3y ago
Sure. Regarding the second approach, however, it may be difficult for a normal user to download the source code of the email and upload it on a server, or at least tedious. Regarding the first approach instead, I should find a way to intercept the emails and send the EML content directly to the application, then find a way to send the email to the recipient after the analysis... I don't know if it's possible to do that due to the architecture of the tool. For example, if an email was suspicious and required the analyst's intervention, then the email could be delayed indefinitely. This way you suggest may be more successful in a fully-automated detection approach IMHO.
- jaclaz 3y ago
  I don't know. The final user should (somehow) create a .eml file of the suspect e-mail, then (in your current setup/workflow) send this .eml file as an attachment to the e-mail address of the service. I don't see the difference, once the .eml file is available, between sending it via e-mail as attachment and uploading it to a portal. On second thought, there is (in the second approach) another risk , the "original" suspect e-mail remains in the final user inbox, and in theory should be left alone until a verdict arrives, then the user should either delete the e-mail (if found to be a phishing attempt) or open it normally, but this is left to the care and diligence of the final user. It won't work, before or later the user will mis-read a notification from the system or couple it with the "wrong" e-mail. Imagine that the user receives 10 suspect e-mails, duly uploads (or sends) all of them to the service and waits diligently for the verdicts. The verdicts are 10 different e-mails from the service, 7 positives and 3 negatives, it would be easy to mismatch these notifications against the messages in the inbox, possibly interspersed with non-suspect ones.
  - emalderson 3y ago
    Well, the user doesn't create any .eml, he just selects "forward as attachment" on the email, so the .eml file creation is transparent to him. For everything else, you're right. Unfortunately, the practice of leaving the responsibility to the user is too risky, but it's ok for a PoC. In a production environment, as we were saying in the previous comments, there should be a way to intercept the email before it reaches the user's inbox, make the analyst analyze it timely and then make the email arrive to the user's inbox afterwards. I don't think that's possible with a human-in-the-loop approach, but only in a fully automated scenario, which will never work as intended.
    - jaclaz 3y ago
      >Well, the user doesn't create any .eml, he just selects "forward as attachment" on the email, so the .eml file creation is transparent to him. Hmmm, I believe it's not so given that an e-mail client (or web-mail interface) has such "forward as attachment" feature. Anyway, for the PoC anything goes, while for a possible future practical application this whole stuff must be automated and placed "before" the final user mailbox, I think we are fully agreeing on this.

by jaclaz 3y ago

emalderson 3y ago

Sure. Regarding the second approach, however, it may be difficult for a normal user to download the source code of the email and upload it on a server, or at least tedious. Regarding the first approach instead, I should find a way to intercept the emails and send the EML content directly to the application, then find a way to send the email to the recipient after the analysis... I don't know if it's possible to do that due to the architecture of the tool. For example, if an email was suspicious and required the analyst's intervention, then the email could be delayed indefinitely. This way you suggest may be more successful in a fully-automated detection approach IMHO.

jaclaz 3y ago
I don't know. The final user should (somehow) create a .eml file of the suspect e-mail, then (in your current setup/workflow) send this .eml file as an attachment to the e-mail address of the service. I don't see the difference, once the .eml file is available, between sending it via e-mail as attachment and uploading it to a portal. On second thought, there is (in the second approach) another risk , the "original" suspect e-mail remains in the final user inbox, and in theory should be left alone until a verdict arrives, then the user should either delete the e-mail (if found to be a phishing attempt) or open it normally, but this is left to the care and diligence of the final user. It won't work, before or later the user will mis-read a notification from the system or couple it with the "wrong" e-mail. Imagine that the user receives 10 suspect e-mails, duly uploads (or sends) all of them to the service and waits diligently for the verdicts. The verdicts are 10 different e-mails from the service, 7 positives and 3 negatives, it would be easy to mismatch these notifications against the messages in the inbox, possibly interspersed with non-suspect ones.
- emalderson 3y ago
  Well, the user doesn't create any .eml, he just selects "forward as attachment" on the email, so the .eml file creation is transparent to him. For everything else, you're right. Unfortunately, the practice of leaving the responsibility to the user is too risky, but it's ok for a PoC. In a production environment, as we were saying in the previous comments, there should be a way to intercept the email before it reaches the user's inbox, make the analyst analyze it timely and then make the email arrive to the user's inbox afterwards. I don't think that's possible with a human-in-the-loop approach, but only in a fully automated scenario, which will never work as intended.
  - jaclaz 3y ago
    >Well, the user doesn't create any .eml, he just selects "forward as attachment" on the email, so the .eml file creation is transparent to him. Hmmm, I believe it's not so given that an e-mail client (or web-mail interface) has such "forward as attachment" feature. Anyway, for the PoC anything goes, while for a possible future practical application this whole stuff must be automated and placed "before" the final user mailbox, I think we are fully agreeing on this.