3 ms·

Of course I forgot the word "detection" after phishing, thanks for pointing that out. Apart from that, I repeat that I'm conscious about what you are saying. T

Of course I forgot the word "detection" after phishing, thanks for pointing that out. Apart from that, I repeat that I'm conscious about what you are saying. This is the fundamental problem of phishing and social engineering techniques detection in general. I just can't think of a better way to solve the problem without a human analyst nowadays. Maybe in the future, with the improvement of the AI engines out there, there will be a new way of handling the problem. I appreciate constructive criticism and I know the problems my tool, which was born out of curiosity to automate a SOC + threat intelligence workflow, is subjected to. I may really appreciate also any suggestion or advice on how the workflow could become more usable in the real world.

jaclaz 4y ago
The workflow seems like fine to me. In the real world you (your users) will probably NOT want to send a copy of all mails (or only the suspect ones) to a gmail address, though. More generally (and IMHO), transmitting unencrypted mail messages to an outside host could be seen as a security issue, as there is the risk that besides the phishing e-mails some of them (good, not phishing) containing some sensitve data are sent as well.
- emalderson 3y ago
  You're right. Maybe, in a production environment, there should be the option to set an internal or corporate email address. Gmail was used only for demonstration purposes in my thesis, since it was originally developed and presented at my degree dissertation.
  - 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 4y ago

The workflow seems like fine to me. In the real world you (your users) will probably NOT want to send a copy of all mails (or only the suspect ones) to a gmail address, though. More generally (and IMHO), transmitting unencrypted mail messages to an outside host could be seen as a security issue, as there is the risk that besides the phishing e-mails some of them (good, not phishing) containing some sensitve data are sent as well.

emalderson 3y ago
You're right. Maybe, in a production environment, there should be the option to set an internal or corporate email address. Gmail was used only for demonstration purposes in my thesis, since it was originally developed and presented at my degree dissertation.
- 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.