4 ms·

You're right from the start. Obviously, this is a PoC tool that is not mature enough to be used in a real-world and big-enterprise scenario. I have some ideas o

You're right from the start. Obviously, this is a PoC tool that is not mature enough to be used in a real-world and big-enterprise scenario. I have some ideas on how to make it more usable, like the automatic analysis of all emails by the tool and the creation of a case only when necessary. However, these last ideas will be only implementable when the API for TheHive 5 becomes stable, because of the many new features the latest version of TheHive offers. However, as you may agree, phishing is one of such things that cannot be completely automated. If this wasn't true, there would be no need for a tool like this, since the big tech companies that run email services would have already solved the problem with their automated inbox scanners. Those scanners can help filter some attacks, but they are far from being perfect, and this is why you receive phishing emails in your inbox in the first place. A human analyst should always be needed if you wanted to analyze incoming emails, and this tool is just a way to simplify the job of that analyst, not to completely replace him.

jaclaz 4y ago
I think you had a little slip of the fingers, you mean anti-phishing, phishing in itself is already automated enough ;). I don't want to seem (more than what I actually am) an old, grumpy, bastard and I actually like your idea, it seems to me a very good one in the context of its original development (your dissertation), only that attempting to actually implement it (even once the automation of the analysis will be possible) in the real world is impossible/cost prohibitive for any organization and the few (government?) high risk ones (with unlimited budgets) probably already have something similar. When/if the human analyst will be replaced by some more sophisticated automatic method (maybe the Artificial Intelligence that everyone is babbling about lately) it might become affordable to have this kind of added protection, but until then (as said assuming that my calculations are roughly correct) noone can possibly use this approach as it simply would cost way too much.
- emalderson 4y ago
  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 4y ago

I think you had a little slip of the fingers, you mean anti-phishing, phishing in itself is already automated enough ;). I don't want to seem (more than what I actually am) an old, grumpy, bastard and I actually like your idea, it seems to me a very good one in the context of its original development (your dissertation), only that attempting to actually implement it (even once the automation of the analysis will be possible) in the real world is impossible/cost prohibitive for any organization and the few (government?) high risk ones (with unlimited budgets) probably already have something similar. When/if the human analyst will be replaced by some more sophisticated automatic method (maybe the Artificial Intelligence that everyone is babbling about lately) it might become affordable to have this kind of added protection, but until then (as said assuming that my calculations are roughly correct) noone can possibly use this approach as it simply would cost way too much.

emalderson 4y ago
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.