We have an existing workflow that successfully generates investigations whenever there is an defender incident that is for phishing reports.
What we are trying to do is add a step that goes to our secops (phishing report) mailbox gets the email report and digs into the attachment (the actual email that was reported) and then prints its body to an artifact.
We are almost there in that we are successfully pulling in the reporters email from the phishing report mailbox but …
Two problems we have at the moment
The ‘get email from user’ functionality of the MS Office 365 plugin allows you to specify from, subject and body. We can successful pull in emails based on from (we get reporters address from incidents plugin) but when we try and put the suspicious sender into ‘subject’ or ‘body’ it fails. After a bit of testing it seems like it does like special characters like @ so ‘joe@example.com’ fails but ‘example’ works. We can launch without this but it would be great to have it as it would reduce chances of pulling in the wrong email when one reporter reports multiple.
No error message it just comes back with nothing if we try and specify the suspicious sender as subject . Reason we do that is because our reports come in with these subjects. Numbers changed. At the end you see the subject and sender of the suspicious email.
UPDATE: okay found a passable workaround for this. where i specify the suspicious emails subject in this case “for report notification test) 27/11/2023”. That’ll help cut down the chances of pulling in the wrong email at least. So yeah the second issue is the big one that’s stopping us going ahead.
Looking at the job output it seems convinced that none of these emails have attachments but they do! Because the email report comes into the phishing inbox as an email from the reporter with the suspicious email attached this means we can’t read the body of the suspicious email
I use the Trigger of a new message in folder, and I flatten the email that comes it.
This gives me the email to process by subject, and provides information about the attachments that I can investigate with things like VT. I think the key is flatting the message.
Thanks. I saw that suggestions elsewhere but weirdly can’t see the option to flatten though i vaguely remember seeing it in the past.
I’ve run tests now just emailing the mailbox normally (not through phishing report) and attaching emails or just a .png and yeah picks up on none of them.
Issue may be that i’m using it here without using it as a trigger. The trigger here is instead Microsoft Incidents. I’ll look around to see if I can find a flattening option.
edited to add: okay is see the option in another workflow i have that uses it as a trigger … looking in my current workflow too.
edited again to add: okay had a look at the two workflows where i use it and also again at the docs. It looks like flattening is only available if you are using it first as a trigger. Weird. Also weird that it doesn’t return it as a nested list as docs suggest it would. Will try and poll the mailbox first before getting email to see if that helps. Worried i won’t be able to have a trigger halfway through a workflow though.
edited yet again: Okay some progress using the ‘get email from user’ step just to get the email ID and then using that in a second ‘get MIME of email’ step. This seems to give me what i want but annoyingly seems to encode it in base 64! Will see if that’s a one off. If not i’ll have to try and use a decoding base 64 step.
Edited again: unfortunately the MIME route doesn’t work as the EML route refuses to parse the file saying “‘list’ object has no attribute ‘replace’”
Another update: okay seems best way forward is to use the existing workflow i have that starts with an email trigger to flatten the email and then store the suspicious email body in a variable using the storage set. I can then pick this up from my Defender Incidents workflow.
