{"id":9818,"date":"2019-03-26T14:22:49","date_gmt":"2019-03-26T18:22:49","guid":{"rendered":"https:\/\/www.thesslstore.com\/blog\/?p=9818"},"modified":"2023-03-20T14:32:25","modified_gmt":"2023-03-20T18:32:25","slug":"how-to-read-an-email-header","status":"publish","type":"post","link":"https:\/\/www.thesslstore.com\/blog\/how-to-read-an-email-header\/","title":{"rendered":"How to read an Email Header"},"content":{"rendered":"\n<h2 class=\"wp-block-heading\" id=\"h-not-sure-if-an-email-is-legitimate-check-the-email-header\">Not sure if an email is legitimate? Check the email header!<\/h2>\n\n\n\n<p class=\"wp-block-paragraph\">Hey friends! There is some unfinished business in my <a href=\"https:\/\/www.thesslstore.com\/blog\/email-security-part-1-certificate-signed-emails\/\">blog series about email security and verification<\/a>. This topic was considered during that timeframe but seemed to be too technical. However, in recent times, there has been some need to review and explain what and why to some co-workers, so I figure I\u2019ll write an article that all my co-workers will read with vigor and retain the information I\u2019m trying to convey. <\/p>\n\n\n\n<p class=\"wp-block-paragraph\">The topic? Email headers. The reason? Further identification\nof spam and phishing attacks. It also is extremely important for one\nrecommendation that I have mentioned on a few different occasions: Scrutinize.\nAlways report. Jump through the hoops. Stop the bad guys. Slay the dragon. Profit\n(Queue Steve Nash). <\/p>\n\n\n\n<p class=\"wp-block-paragraph\">Email headers are sort of the paper trail (and more) that is attached to each email and shows the actual source, hops and how it ended. It also has certain things such as \u2018Return Path\u2019, Spam Score, DKIM Public signature, and various other tidbits. We\u2019ll go over most of it, but the takeaway should be to have further confidence if email is spam or legitimate and the path it took to get to you. Let us hash this particular topic out.<\/p>\n\n\n\n<figure class=\"wp-block-embed is-type-video is-provider-youtube wp-block-embed-youtube wp-embed-aspect-16-9 wp-has-aspect-ratio\"><div class=\"wp-block-embed__wrapper\">\n<iframe loading=\"lazy\" title=\"Email Header Analysis and Forensic Investigation\" width=\"960\" height=\"540\" src=\"https:\/\/www.youtube.com\/embed\/nK5QpGSBR8c?feature=oembed\" frameborder=\"0\" allow=\"accelerometer; autoplay; clipboard-write; encrypted-media; gyroscope; picture-in-picture\" allowfullscreen><\/iframe>\n<\/div><\/figure>\n\n\n\n<h2 class=\"wp-block-heading\" id=\"h-components-of-email-headers\">Components of Email Headers<\/h2>\n\n\n\n<p class=\"wp-block-paragraph\">Email headers contain a lot of information and not just\nnecessarily the logistical audit of who and how the email made it to the end\nuser. Although, that information is very useful and provides insight into origin,\npath and potential security processes. <\/p>\n\n\n\n<p class=\"wp-block-paragraph\">Some of the other things one may see in an email header:<\/p>\n\n\n\n<ul class=\"wp-block-list\">\n<li>Spam identification scores and thresholds to flag\nemails as spam which allow client spam filters to easily sort bad emails out of\nusers\u2019 inboxes. <\/li>\n\n\n\n<li>There are fields that indicate a \u2018Return Path\u2019\nwhich is essentially a bounce back address. Often, the return path is the\nsender\u2019s email but it might make sense to have an email that will collect\nbounces and do something if there is high volume. <\/li>\n\n\n\n<li>DKIM public key and results are also found right\nin the email headers which indicate if there was a pass\/fail. What happens to a\nfailed (or soft fail) message depends on the policy action set in the DNS\nrecord (See previous post about DKIM).<\/li>\n\n\n\n<li>Some common information can also be found such\nas date\/timestamps, MIME types, version, email format (HTML, plaintext), etc.<\/li>\n<\/ul>\n\n\n<span style=\"--tl-form-height-m:150.25px;--tl-form-height-t:121.4583px;--tl-form-height-d:121.4583px;\" class=\"tl-placeholder-f-type-shortcode_12753 tl-preload-form\"><span><\/span><\/span>\n\n\n<h2 class=\"wp-block-heading\" id=\"h-dissecting-a-phishing-email-header\">Dissecting a (Phishing) Email Header <\/h2>\n\n\n\n<p class=\"wp-block-paragraph\">Now that we have an idea of what an email header may or may\nnot contain, let us now look at a bad email header and some of the flags that\nindicate it is, uh, bad. <\/p>\n\n\n\n<p class=\"wp-block-paragraph\">So, this phishing email was found in my email client\u2019s junk\nfolder as it should be. I have moved it to my inbox to show what it would like\nin an inbox. By default, any email in my junk box is converted to plain text,\nso, I wanted to show the ripped off graphic that can be seen with HTML. <\/p>\n\n\n\n<p class=\"wp-block-paragraph\">I\u2019d also like to point out that not all mail comes from a\nMicrosoft Exchange Server\/Environment. Many do and while some of the stuff\nwe\u2019ll look at will be specific, other indicators and header information might\ncome through regardless of the mail processing platform. <\/p>\n\n\n\n<figure class=\"wp-block-image\"><img loading=\"lazy\" decoding=\"async\" width=\"1024\" height=\"556\" src=\"https:\/\/www.thesslstore.com\/blog\/wp-content\/uploads\/2019\/03\/Rackspace-1024x556.png\" alt=\"\" class=\"wp-image-9819\" srcset=\"https:\/\/www.thesslstore.com\/blog\/wp-content\/uploads\/2019\/03\/Rackspace-1024x556.png 1024w, https:\/\/www.thesslstore.com\/blog\/wp-content\/uploads\/2019\/03\/Rackspace-300x163.png 300w, https:\/\/www.thesslstore.com\/blog\/wp-content\/uploads\/2019\/03\/Rackspace-768x417.png 768w, https:\/\/www.thesslstore.com\/blog\/wp-content\/uploads\/2019\/03\/Rackspace.png 1245w\" sizes=\"auto, (max-width: 1024px) 100vw, 1024px\" \/><\/figure>\n\n\n\n<p class=\"wp-block-paragraph\">Suspicious from the get-go. I didn\u2019t even have to look at\nthe email headers to determine (obviously, because the email got flagged and\nthe spam filter moved it out). But, let\u2019s take a look at the email headers and\nsee what makes this email so bad:<\/p>\n\n\n\n<figure class=\"wp-block-image\"><img loading=\"lazy\" decoding=\"async\" width=\"732\" height=\"898\" src=\"https:\/\/www.thesslstore.com\/blog\/wp-content\/uploads\/2019\/03\/email-header.png\" alt=\"\" class=\"wp-image-9820\" srcset=\"https:\/\/www.thesslstore.com\/blog\/wp-content\/uploads\/2019\/03\/email-header.png 732w, https:\/\/www.thesslstore.com\/blog\/wp-content\/uploads\/2019\/03\/email-header-245x300.png 245w\" sizes=\"auto, (max-width: 732px) 100vw, 732px\" \/><\/figure>\n\n\n\n<p class=\"wp-block-paragraph\">One thing to point out immediately is that we kinda need to\nread the header information upside down. That is, you start on the upsidedown\n(shout out to Stranger Things) and work your way to the top. <\/p>\n\n\n\n<p class=\"wp-block-paragraph\">Much of what we\u2019ll see is mail exchanges (relays) that simply\nhelp pass the message along but does no real scrutinization. <\/p>\n\n\n\n<p class=\"wp-block-paragraph\">Look. The next few pages are arduous. This is kind of the\nlast exit warning sign before a long bridge. But, instead of turning back, you can\nmove forward, skip these next few pages and there is a good summary of which\nlines of the header to look at that will almost always help you scrutinize\naccurately. <\/p>\n\n\n\n<p class=\"wp-block-paragraph\">Each line is numbered for easier reference.<\/p>\n\n\n\n<ul class=\"wp-block-list\">\n<li><strong>Line 61<\/strong>: The\nvalue for \u2018AuthAs\u2019 is listed as \u2018Anonymous\u2019. Right here, this is a flag. We\nshould be looking out for a value as \u2018Internal\u2019, \u2018External\u2019 or \u2018Partner\u2019. According\nto <a href=\"https:\/\/support.microsoft.com\/en-us\/help\/2663556\/email-messages-that-are-sent-from-the-on-premises-environment-to-offic\">Microsoft<\/a>,\n\u201cIf&nbsp;X-MS-Exchange-Organization-AuthAs&nbsp;is listed as &#8220;anonymous&#8221;\nor if it&#8217;s missing, this indicates an incorrect configuration or an incorrect\nmail route.\u201d <\/li>\n\n\n\n<li><strong>Line 60<\/strong>: \u2018AuthSource\u2019\nis the server that checked the authentication of the email for the email\ndomain. &nbsp;I happen to know that domain = \u2018mlsrvr.com\u2019\nis of RackSpace which is an email service provider.<\/li>\n\n\n\n<li><strong>Line 59<\/strong>:\n\u2018Organization-SCL\u2019 is the Spam Confidence Level (hence, SCL) is how that\n\u2018AuthSource\u2019 grades the message as spam. The scale is 0, which is clean, and 9,\nwhich is bad. Basically, this is a very computer-y way of saying 1-10. The\nvalue here is \u20185\u2019.&nbsp; Doing the math, er,\nbasic counting, this errs to the side of bad. It is certainly not absolute or\nnearing absolute, but it is certainly leaning to bad. In my mind, this is a\nflag. Note: a value of -1 means that it was not analyzed here because the value\nof \u2018AuthAs\u2019 was \u2018Internal\u2019. This could certainly be considered a flaw that\nwould be very difficult to exploit. <\/li>\n\n\n\n<li><strong>Line 57 \u2013 58<\/strong>:\nThis is a combo line that just states the method of the AV scanning on the\nserver side. Standard and nothing indicative here. <\/li>\n\n\n\n<li><strong>Line 56<\/strong>: The\n\u2018Network-Message-ID\u2019 is a unique hash that sort of serializes the message.\nStandard and nothing indicative here. <\/li>\n\n\n\n<li><strong>Line 55<\/strong>: Here\u2019s\na flag, alright. Simply labeled \u2018To\u2019, the value here is \u2018Undisclosed\nrecipients:;\u2019 That means the destination fields, \u2018To\u2019, \u2018CC\u2019, and \u2018BCC\u2019 have\nbeen gamed. For example, it can be done through GMail by typing \u2018Undisclosed\nRecipients &lt;emailaddress@emaildomain.com&gt;\u2019. The email was supposedly sent\nfrom Rackspace, a legitimate business, and they just don\u2019t do that. This smells\nbad. If I didn\u2019t already know better, I\u2019m already questioning this.<\/li>\n\n\n\n<li><strong>Line 54<\/strong>: \u2018X-Mailer\u2019\nis indicating what method was used to send the email. The value is listed as\n\u2018Webmail\/16.2.0-RC\u2019. This is a little phishy in that RackSpace would likely not\nuse WebMail to send the message as they are a mail service and have access to\nthe \u201ccleaner\u201d backend of Exchange. Not a huge indicator typically but\nconsidering this is supposedly from RackSpace, it can be rightly scrutinized. <\/li>\n\n\n\n<li><strong>Line 53<\/strong>:\n\u2018Message-ID\u2019 is some unique hash from RackSpace. Nothing here. <\/li>\n\n\n\n<li><strong>Line 52<\/strong>:\n\u2018Type\u2019 is the format of the message. Most messages are HTML. This is fine. <\/li>\n\n\n\n<li><strong>Line 51<\/strong>:\n\u2018Priority\u2019 is just that: priority of message to be processed based on the mail\nservice. Value of \u20183 (Normal)\u2019 is, you guessed it, normal and standard. Nothing\nto see here. Moving along. <\/li>\n\n\n\n<li><strong>Line 50<\/strong>:\n\u2018Importance\u2019 is a flag set on the user end. It indicates if an email is of high\nor low importance. Nothing here detracts from the legitimacy of the message. <\/li>\n\n\n\n<li><strong>Line 48-49<\/strong>:\n\u2018Content-Type\u2019 specifies the kind of content that can be found in an email\nmessage. Many emails have the combination of HTML, Text, Image attachments,\netc. Many emails have this combination of things so I would say that this is\nnon-indicative. <\/li>\n\n\n\n<li><strong>Line 47<\/strong>:\n\u2018MIME-Version\u2019 has a value of \u20181.0\u2019. Basically, indicates that the message was\ncreated in compliance with the standardized \u201cemail structure\u201d. Also, clean. <\/li>\n\n\n\n<li><strong>Line 46<\/strong>: The\nvalue of the \u2018From\u2019 field here is quite indicative. The email address is listed\nas \u2018noreply@mailbox-services.com\u2019. A quick search on <a href=\"https:\/\/mxtoolbox.com\/SuperTool.aspx?action=mx%3amailbox-services.com&amp;run=networktools\">MXToolBox<\/a>\nshows that RackSpace has no affiliation with that email domain. This is a red\nflag for me. <\/li>\n\n\n\n<li><strong>Line 45<\/strong>: \u2018Subject\u2019\ncan certainly be indicative. We\u2019re looking for misspellings and bad grammar\nthat most legitimate companies are very capable of keeping that clean. The\nsubject here is a little wordy for a warning. I\u2019m giving this verbiage, \u201cWe\nnoticed an unusual sign in attempt from an unknown location\u201d, a warning going\non red flag. <\/li>\n\n\n\n<li><strong>Line 44<\/strong>:\n\u2018Date\u2019 and timestamp is pretty straightforward. Nothing here.<\/li>\n\n\n\n<li><strong>Line 43<\/strong>: \u2018X-Auth-ID\u2019\nis a big one here. This field is stating the authentication ID for the email\naccount. I almost always look for values like this (and\/or \u2018Return Path\u2019 which\nis often the same address and\/or \u2018X-Sender-ID\u2019 which is probably the most\ntelling field) to tell me if this is a legitimate email. The value,\n\u2018mbabauta@ibssguam.com\u2019, screams fake. I took this a step further and looked up\nthe domain of \u2018<a href=\"https:\/\/www.ibssguam.com\/\">ibssguam.com<\/a>\u2019. Just so\nyou know, the site seems legit though it is literally a company based in Guam.\nThis tells me that their account was hacked and is being used to send spam\n(poor Island Business Systems &amp; Supplies of Guam\u2026.) In a real-world\napplication, this ends my investigation. That\u2019s about as much proof as I need.\nReddest of red flags. <\/li>\n\n\n\n<li><strong>Line 40-42<\/strong>: \u2018Received\nBy\u2019 is where the actual path starts being laid out. All the information before\nthis is basically received\/recorded\/generated from this first \u2018hop\u2019. The value\nis \u2018apps.rackspace.com\u2019 which, as mentioned earlier, is Rackspace\u2019s webmail\naddress. The other values, on line 41, just reiterates the authenticated user\nand the from user. This also indicated a red flag, so it is telling. <\/li>\n\n\n\n<li><strong>Line 37-39<\/strong>:\n\u2018Received From\u2019 is kind of the extension of the previous line block. It also\nshows that \u2018user from\u2019 is of poor IBSSGuam email address. We know this is a red\nflag. <\/li>\n\n\n\n<li><strong>Line 34-36<\/strong>: \u2018Received\nFrom\u2019 here indicates a relay in the value field. This does not immediately jump\nout at me considering we are not sure of the path and it could potentially\nchange depending on many factors of general internet routing. <\/li>\n\n\n\n<li><strong>Line 33<\/strong>: Much\nlike line 43, this is what I am looking for. This is often the first thing I\nlook for as this is all telling and basically seals the deal for me. The reason\nwhy this is more important is because this is the actual sending email address\nand not just the authentication that is seen on line 43. So, the display name\nfor email might say \u2018RackSpace Support\u2019 but this field is hard (not impossible\nto spoof) and is not done often enough. For instance, it was not done here!\nMuch like the value found in line 43, this is about as much proof as I need.\nRedder than the reddest of red flags (AKA bad). <\/li>\n\n\n\n<li><strong>Line 30 \u2013 32<\/strong>:\nSee info for line 34-36. This is for the outbound (SMTP), though. But the same\nprinciple can be applied. We don\u2019t know the route. It can be traced but there\nis a lot of work that would have to go into that. <\/li>\n\n\n\n<li><strong>Line 27 \u2013 29<\/strong>:\nSee previous. Same thing (SMTP, too).<\/li>\n\n\n\n<li><strong>Line 23 \u2013 26<\/strong>:\nSee previous which makes you see previous heh. There is some added transport\nencryption information that doesn\u2019t mean much to anyone at a glance. <\/li>\n\n\n\n<li><strong>Line 22<\/strong>: \u2018Classification-ID\u2019\nis a random hash and this is another unsuspecting value. This does nothing for\nour scrutinization. <\/li>\n\n\n\n<li><strong>Line 21<\/strong>:\n\u2018Suspicious-Flag\u2019 is set to \u2018No\u2019 as the value. I am not sure what causes this\nflag to be set to \u2018Yes\u2019. But, I would have. With all its suspicion just\nsuspicioning around\u2026.<\/li>\n\n\n\n<li><strong>Line 18 \u2013 20<\/strong>:\nThis is a very telling few lines right here. Welcome in our old friends SPF,\nDKIM, and DMARC. The MailFrom is still from our other friends selling printers\nin Guam. There are no DKIM signatures, no DMARC and the SPF is \u2018Neutral\u2019 which\nmeans there is referencing from the same domain as the receiver. In other\nwords, the sending domain is in the same domain as the receiving domain\n(emailsrvr.com). My street smarts would tell me that if Rackspace were to send\nan email, they would pass SPF, DKIM and DMARC. Kinda important for them\nconsidering they do lots of email hosting. Red Flag.<\/li>\n\n\n\n<li><strong>Line 17<\/strong>:\n\u2018Originating-IP\u2019 can be telling if you do the research but at a glance, it\ndoesn\u2019t mean much. I\u2019d be more interested in some of the other fields that were\nmentioned in the previous lines. At a glance, this is a fine. Note: For the\nrecord, this IP is from RackSpace so this would favor a \u201cclean\u201d message despite\nit being a, well, you know.<\/li>\n\n\n\n<li><strong>Line 16<\/strong>: \u2018Orig-To\u2019\nis the destination email address. Nothing wrong here.<\/li>\n\n\n\n<li><strong>Line 15<\/strong>:\n\u2018Virus-Scanned\u2019 is referring to the email server scanning for a virus. The\nvalue of the filed is \u2018OK\u2019. There was no real virus on the email, per se, but I\nwouldn\u2019t click on the link. That would seemingly be a digital petri dish of\nbad. <\/li>\n\n\n\n<li><strong>Line 14<\/strong>: \u2018Spam-Flag\u2019\nis set to value \u2018YES\u2019. Boom. This field though makes a bit more sense by\nlooking at the next few fields. Seemingly, this section would be best read in a\ndifferent order. Red flag. <\/li>\n\n\n\n<li><strong>Line 13<\/strong>:\n\u2018Precedence\u2019 has value \u2018junk\u2019. It\u2019s junk, aright. Right on the nose.<\/li>\n\n\n\n<li><strong>Line 12<\/strong>:\n\u2018Spam-Score\u2019 has a value of \u2018100\u2019. That is on a scale of 1 \u2013 100. Guess which\nend is bad? <\/li>\n\n\n\n<li><strong>Line 11<\/strong>:\n\u2018Spam-Threshold\u2019 is basically the score that must be met in order for an email to\nbe flagged as Spam. The value is set to \u201895\u2019. I\u2019m no mathematician but I\u2019m 95%\nsure that 100 &gt; 95. Threshold met. \u2018Spam-Flag\u2019 is set to \u2018YES\u2019. <\/li>\n\n\n\n<li><strong>Line 10<\/strong>:\n\u2018Return-Path\u2019 is a big one for me. Maybe one of the biggest flags, in my\nopinion. The \u2018Return-Path\u2019 is an email address that will is also called a\n\u2018Bounce-Address.\u2019 When an email address gets bounced, this is the email address\nthat the bounce goes to. More often than not, this is the same address as the\nsender email address. So, here, we have that same sender address value which is\n<a href=\"mailto:mbabauta@ibssguam.com\">mbabauta@ibssguam.com<\/a>. This is\ntelling to me. <\/li>\n\n\n\n<li><strong>Line 1 \u2013 9<\/strong>: I\u2019m\ncondensing the last 9 lines into this last one which is basically 3 hops.\nBasically, from Rackspace and back to Rackspace. Nothing weird here. <\/li>\n<\/ul>\n\n\n\n<h2 class=\"wp-block-heading\" id=\"h-zzzzzzzz-huh-i-m-awake-i-m-awake\">ZZZZZZZZ\u2026. Huh?! I\u2019m Awake. I\u2019m Awake\u2026.<\/h2>\n\n\n\n<p class=\"wp-block-paragraph\">Whew. We made it through. Look at all that red. A clean\nmessage will have very, very little if at all red. Let\u2019s examine a clean\nmessage\u2019s headers. Kidding. <\/p>\n\n\n\n<p class=\"wp-block-paragraph\">The main point of this is that someone should be able to\nlook at 1 or 2 things within an email\u2019s headers and have a really good idea if\nthere is shadiness surrounding an email. <\/p>\n\n\n\n<p class=\"wp-block-paragraph\">The \u2018Return-Path\u2019, <strong>line 10<\/strong>, as\nmentioned, is a big one to me. Since it can be spoofed, it is not fool-proof.\nOften times, it is not spoofed so that is very indicative. In a sense, this can\nshow the true originating email address. There are other fields that may\nindicate the true email address, such as the authentication, and that can\nappear different. Certainly, the display name can be spoofed so that should\nalmost never be considered when starting the scrutinizing process. <\/p>\n\n\n\n<p class=\"wp-block-paragraph\">Also, the results from things like SPF, DKIM and DMARC, <strong>line 18 &#8211; 20<\/strong> is very telling. It all depends on the\ncontext. Seemingly, a legitimate entity will have their email security and\nverification processes tuned up so if there is failure or none at all, that is\na red flag. <\/p>\n\n\n\n<p class=\"wp-block-paragraph\">Finally, the spam flag and spam score, <strong>lines 14 and\n12<\/strong> respectively, is also a big indicator. This can and has produced\nfalse positives so I will often look at the other signs in order to determine\nan email\u2019s legitimacy.<\/p>\n\n\n\n<p class=\"wp-block-paragraph\">There a lot of other possible fields that one could find in\nan email header. So may be indicative and others may just be some metadata-ish\ntype information that just help with organizing\/tracing. <\/p>\n\n\n\n<p class=\"wp-block-paragraph\">Finally, and as I have said over and over, and even wrote a post about it, use your best judgement. Understand your contacts, look for the obvious stuff, question any and all information that anyone is asking for. Businesses WILL NOT ask for certain sensitive information via email. Keep an eye out for other email header fields, try to understand the context and, of course, Happy Scrutinizing!<\/p>\n\n\n","protected":false},"excerpt":{"rendered":"<p>Not sure if an email is legitimate? Check the email header! Hey friends! There is some unfinished business in my blog series about email security and verification. This topic was&#8230;<\/p>\n","protected":false},"author":11,"featured_media":9821,"comment_status":"open","ping_status":"open","sticky":false,"template":"","format":"standard","meta":{"inline_featured_image":false,"footnotes":"","tve_updated_post":"","tve_custom_css":"","tve_user_custom_css":"","tve_globals":{},"tcb2_ready":0,"tcb_editor_enabled":0,"tve_landing_page":"","_tve_header":"","_tve_footer":""},"categories":[16],"tags":[7970],"class_list":["post-9818","post","type-post","status-publish","format-standard","has-post-thumbnail","hentry","category-hashing-out-cyber-security","tag-email-security","post-with-tags"],"views":35453,"jetpack_featured_media_url":"https:\/\/www.thesslstore.com\/blog\/wp-content\/uploads\/2019\/03\/Email-Header-Feature.jpg","_links":{"self":[{"href":"https:\/\/www.thesslstore.com\/blog\/wp-json\/wp\/v2\/posts\/9818","targetHints":{"allow":["GET"]}}],"collection":[{"href":"https:\/\/www.thesslstore.com\/blog\/wp-json\/wp\/v2\/posts"}],"about":[{"href":"https:\/\/www.thesslstore.com\/blog\/wp-json\/wp\/v2\/types\/post"}],"author":[{"embeddable":true,"href":"https:\/\/www.thesslstore.com\/blog\/wp-json\/wp\/v2\/users\/11"}],"replies":[{"embeddable":true,"href":"https:\/\/www.thesslstore.com\/blog\/wp-json\/wp\/v2\/comments?post=9818"}],"version-history":[{"count":0,"href":"https:\/\/www.thesslstore.com\/blog\/wp-json\/wp\/v2\/posts\/9818\/revisions"}],"wp:featuredmedia":[{"embeddable":true,"href":"https:\/\/www.thesslstore.com\/blog\/wp-json\/wp\/v2\/media\/9821"}],"wp:attachment":[{"href":"https:\/\/www.thesslstore.com\/blog\/wp-json\/wp\/v2\/media?parent=9818"}],"wp:term":[{"taxonomy":"category","embeddable":true,"href":"https:\/\/www.thesslstore.com\/blog\/wp-json\/wp\/v2\/categories?post=9818"},{"taxonomy":"post_tag","embeddable":true,"href":"https:\/\/www.thesslstore.com\/blog\/wp-json\/wp\/v2\/tags?post=9818"}],"curies":[{"name":"wp","href":"https:\/\/api.w.org\/{rel}","templated":true}]}}