About JStephan

  In this post, I want to take a deeper look into the metadata provided by email. As you may already know, Cortex XSOAR gives you a great tool called Mapping to make sure that certain metadata is stored in the incident fields.   Let’s take a look at the email data.   In order to “make sense” of certain meta-data we need to understand how email communication works.   Let's start with some very basic data points. The good thing is that the email “header” is quite transparent with those data points. Again, I am using Cortex XSOAR’s mapping functional to show you the header information. ‌ Data of an email as seen by XSOAR   In layman's terms, an email will originate somewhere and will be handed over to different systems until it reaches its final destination — just like a traditional letter.   The information “Received” will be the paper trail of this handover between the systems. The servers mentioned in this text will also be in order of the handover. So the first servername and IP are the originating server, indicated as “from” the second “received by” is the destination and should correspond with your email server.   In the example case above “received by” was by smtp.gmail.com, which is expected as the email went into my Gmail account.   Choosing the Right Metadata for Phishing and Email Incidents Example < BYAPR11MB349523A8E7B5DCC69CA7A61F8CF49@BYAPR11MB3495.namprd11.prod.outlook.com >   In another example we can see that only two hops have been between the two email systems in question, if there would have been more we would see that as well.   The next important thing to recognize is the “ message-id” , this is an unique identifier of the email. The one we see above shows the one being assigned by the receiving email server. In this case, lets say someone did send an email to multiple people, we would expect this ID to be the same (if CCed or BCCed). This can be a huge help if you need to delete many of the same emails from different inboxes or need to track them on different systems.   Another data point I like to look into is the Format of the Email, it lets you decide upfront what you can expect from an email. If you hop over to Microsoft ( link ) you will find a list of all the different Content-types an email can have and what you can expect. As an example:   Content-Type: text ‌ ‌The text content type is used for message content that is primarily in human-readable text character format. The more complex text content types are defined and identified so that an appropriate tool can be used to display more complex body parts. Content-Type: image ‌ ‌The image content type allows standardized image files to be included in messages. ‌ Body types and counter for December 2022   ‌Mixed and Multipart messages are basically a combination of more than one type plus additional header fields.   A text/plain email could be considered harmless, or at least less harmful compared to a text/html one, as we can expect that no clickable links (URLs) are present in the email itself.   Before this post gets too long, let's have a look at some personal highlights and ways of getting them out of the data.   My first and favorite is what I call the "First Email Server IP", like we discussed above, this one indicates the origin, the first server which created an email. Especially in a larger campaign that is an IP we would expect to show up frequently and can be a good indicator to look for relations. ‌   The next two are pretty much related, this is the Spam Domain and Top Level domain. To be honest I mainly use those for dashboards and reporting, so I can see any uptick in certain domains.    For the human eye, this email looks like Spam through and through, for a machine and an automated response, not so much. So we need to make sure that we understand the meta data and structure a playbook and methods around it.   Thanks for reading until the end. Be excellent to each other. ... View more

The Traffic Light Protocol (TLP) can play a major role in your XSOAR instance. As you may have seen already, every Threat Intelligence Feed you can add will come with this option to be set.     See MISP in the example above. What does the TLP actually indicate? Well, let me explain.   The traffic light protocol was first developed by  first.org , a security professional community in the area of incident response but actually mainly CERT related.   As you may imagine, when CERT people come together they are keen on sharing knowledge and insights as well as the latest and most urgent events they are facing with each other. But how do you end up not over sharing information while publicly exposing that your company may or may not be affected by a certain threat actor or vulnerability? How can you make sure that your effort of investigating a certain threat gets public knowledge? With this, your advantage point vanishes.   One could imagine that those thoughts have been fundamental to the birth of the TLP protocol. Everybody in the security space should have a basic understanding of the TLP, knowing what green, amber and red mean. Let’s explore further.   White (TLP:WHITE : R=255, G=255, B=255)   White is not really a traffic light, but that is actually the point. Indicators which are TLP:white are sort of public domain in that information shared under this tag can be used however you like. Go home and tell your grandmother about it if you like, or write a fancy blog post. No harm, no foul.   Green (TLP:GREEN : R=51, G=255, B=0)   This already limits the sharing you are allowed to do. Being the lowest entry point to the protocol, information tagged as TLP:green should stay within the shared community and your broader organization. Feel free to tell everyone in your community ( was: company and partners ). You could, for example, shout them out in the cantina of your company and no one will complain.   Amber (TLP:AMBER : R=255, G=192, B=0)   Staying with the examples, the cantina might not be the right place to disclose this one. The new version 2.0 of the TLP protocol includes clients who need to know, so not limited to the “Organization only” which was the phrase you want to keep in mind. TLP: amber tags should be limited to your team meetings, your SOC and board rooms and clients like in an MSSP scenario. Be careful if data tagged this way is to be enriched. Many organizations could see indicator sharing with a 3rd party vendor as breaking the code.   Amber and Strict (TLP:AMBER+STRICT : R=255, G=192, B=0)   Amber+Strict is basically the old amber definition which still means “Organization only”, so make sure to give a suspicious look around the cantina and whisper it to your team members.   Red (TLP:RED : R=255, G=0, B=51)   You and you alone. Remember when your childhood friend took you away from the group and started with “please don’t tell anyone”, that’s exactly TLP:red for you. Mainly meaning “ears and eyes” of the participants only. This is the strictest TLP category you can find and it makes it really difficult to act upon, you could not search it on the SIEM because it would show up in the history. So act with caution.     That’s it for today, please leave a 👏 and be excellent to each other.   ... View more