If you are casually browsing for ways to improve your cyber security posture, you might not have come across dnssecuritytxt, and it’s understandable because it’s not very famous. But we took a look at it and wanted to share our opinion with you.
Security.txt and dnssecuritytxt
A few years ago, a concept called security.txt became popular in the online community after giants such as Google, Facebook or Dropbox started implementing it. This concept was nothing more than a .txt file that was placed in the /.well-known/ directory of a website. Its contents? Information about who to contact in case a bug is found, what the security policy of the company is, how to encrypt the proof of vulnerabilities before sending them over, and even a job page for those who might be interested. You can read this great article which goes more into the details of security.txt or you can visit our implementation of it to see what it looks like from the URL below:
Context of the Log4Shell Vulnerability to Text4Shell
A year ago, the infamous “Log4Shell” vulnerability on the Log4J logging library of the Apache Logging Services was disclosed. This “Remote Code Execution” (RCE) vulnerability was widely publicized, as the component was widely used and exploiting of the vulnerability was easy. Indeed, Log4Shell was more than just an RCE vulnerability. Depending on the way it was exploited, it could also be used for data exfiltration via protocols such as DNS.
The number of vulnerabilities is growing day by day due to different technologies such Web applications or Cloud Computing, which is increasingly adopted by organizations as well as teleworking, so more assets are exposed and connected to the internet and the attack surface of organizations is getting more and more larger, besides hackers have shifted their focus from high to medium and low CVSS.
In today’s article, we discuss the background of threat intelligence feeds.
Cyber Threat Intelligence (CTI) is stream-based detection of cyber threats, including network anomaly indicators. But this is just the tip of the CTI iceberg, the one consumed by SIEM (Security Information and Event Management) appliances.
It is essential to understand the need to prepare or curate CTI.
At CERT-XLM, we actively refine our CTI feeds. This paper discusses the importance of having usable feeds and how CERT-XLM achieves this..
What is a cyber threat intelligence feed?
Intelligence feeds contain indicators related to an identified or possible threat. CTI indicators are called IoCs (Indicator of Compromise) or IoAs (Indicators of Attack). An IoC is an indicator of a network security breach. They are used to identify malware signatures, known IP addresses or domains, and exploitation of vulnerable products/versions to reactively detect the compromise. An IoA recognizes the intention of attackers as well as suspicious activities that could lead to attacker persistence or lateral movements.
Indicators can be an IP address related to delivering malware, IP addresses corresponding to an attacker’s control servers (hereafter referred to as “C2”), URLs of phishing web pages, names or hashes of malicious files, email addresses, and so on.
Where to get your own cyber threat intelligence feed?
The market for CTI intelligence sources is not consistent. Security solutions such as anti-virus, firewalls, or proxy solutions can include proprietary CTI.
Virus Total [VT], Vx-underground [VX], or Abuse.ch [Abuse.ch] are open or public CTI sources that allow the downloading of a variety of samples or IOCs. These platforms are sometimes crowd-sourced with URLs or files submitted by users worldwide.
Platforms such as PhishTank [PhishTank] or OpenPhish [OpenPhish] allow users to report malicious sites that seek to extract user credentials or other sensitive information.
You can create your own CTI platform, which gathers and stores feeds that are relevant to you; this is what CERT-XLM does.
Some feeds are dedicated to one threat, such as OpenPhish for phishing or a particular family of malware for Abuse.ch. In contrast, others offer a wide variety of known threats, such as Malware Information Sharing Platform (MISP).
“Label all the things!”
The name of a threat is essential information for an analyst. There is no universal CTI naming convention, and each major vendor applies its own. For example, “Emotet” can be found under the name “Feodo,” “Heodo,” or “Geodo .”The Stealer “Pony” may be labelled “Siplog” or “Fareit”. QakBot is also called “Pinkslipbot,” “QBot,” and “Quakbot.”
There are common categories for indicators like “C2”, “phishing”, “malware”, “RAT”, “ransomware”, “scanner”, and “botnet”. Unfortunately, the categories are not universal. The MISP community platform has the concept of “galaxies”,, which each member can define. The result is multiple indicators associated with the same threat.
The CERT-XLM uniformly labels all threats based on MISP classification standards. Our curated CTI is then applied consistently through SIEM Use Cases.
Don’t lose control over your Cyber Threat Intelligence Feeds
Low-quality CTI feeds result in low-quality indicators.
Here is an example of a low-quality CTI indicator due to URL formatting issues:
“http://${ip}:${port}/”
“http://ttp://avorlen.xyz”
“htttp://188.124.36.242:25802/”
Here is an example of a low-quality CTI indicator due to a content issue as it contains an RFC 1918 reserved IP address:
Here is an example of a low-quality CTI indicator based on being too specific. The indicator should not include the email address as this will vary based on the targeted user.
the domain is not valid as is, it is actually decoded as “вода,” a valid domain, but it will have to be encoded in its internationalized form “xn--80adg3b” for a SIEM.
On line 2, the domain is protected by brackets, a common practice but left to individual preferences: one can also find square brackets instead, “hxxp” for “HTTP”.
CERT-XLM thoroughly tests, decodes, reencodes each indicator, and cleans and discards irrelevant ones.
Come on and grab your own!
Generic CTI content can result in the high volume creation of false positives.
Looking at the four examples below:
“http://firebasestorage.googleapis.com”
This example is a well-known content hosting service. This service can be abused, but without the exact page qualification path, the domain itself is not malicious.
“https://forms.office.com/r/”
It is common for attackers to use free online services to host malicious documents. They then invite their victims to download and open them as part of a phishing campaign to avoid detection. Without the identifier (e.g., hxxps://forms.office.com/r/ne89GVwrYE), this is not an indicator of a threat.
“172.67.138.4”
is an internal IP address. It corresponds to countless domains: Not all of these domains are malicious, and the analyst doing reverse DNS research on it must be able to classify the alert.
is a less common example. This CTI content will generate a lot of alerts in most environments.
CERT-XLM takes extra precautions to avoid CTI content that generates a high volume of false positive alerts.
Adapting your cyber threat intelligence feed to your SIEMs capabilities
It is important to have Secure Socket Layer (SSL) decryption as part of your security architecture. Your SIEM will have less useful information if you do not have adequate SSL decryption. Only the visited domains will be recorded.
Your SIEM may also have software limitations. The first limitation could be the number of indicators it can ingest at one time. Other limitations will come from the functionalities of the SIEM, as none of them is perfect.
Unfortunately for some SIEMs, no alert will be raised with a visit to the URL https://walletsdappvalidation.com/ when the indicator is “https://walletsdappvalidation.com/?u” as only exact matches are possible.
Test, test and test again
It is essential to validate your CTI content.
CERT-XLM measures CTI content in an isolated environment to reduce the risk of incidents from establishing connections with the indicators.
We then evaluate:
how redundant the indicators are with the flows we already have. Measuring indicator matches things being blocked by your firewalls, proxies, anti-viruses, and other perimeter security solutions in your environment.
What proportion of these indicators will generate false positives? This can be measured offline by looking for the indicators in the extraction of your traffic.
How much reprocessing is required before ingestion by the SIEM? If there is no SSL termination in your traffic, at a minimum, you will need to extract domains from URLs. You will need to think of strategies to counter false positives as described above. Reprocessing will also involve cleaning up some of the recoverable indicators as described in Section 2.2.
What is the proportion of waste? This involves looking for unusable indicators, as described in paragraph 3, to which you can add those that generate false positives.
Only these quantifiable answers will allow you to conclude whether the feed is worthwhile.
CERT-XLM also recommends the use of a passive DNS database. This approach can allow extended searches to be performed without consuming DSIEM resources. If matches are identified, a short period search in the SIEM will allow concluding with the full indicator if it is a false-positive or true-positive.
Cyber threat intelligence feeds: what to conclude?
There are a lot of details to keep in mind when integrating CTI content with a SIEM. This is why CERT-XLM recommends applying a structured approach to curating CTI content.
A Cyber Security Operations Centre, or CSOC is increasingly recognized as being an essential part of a defence-in-depth approach to cybersecurity, where multiple layers of security controls permeate the IT landscape providing diverse measures that;
Certificate Transparency is a publicly logging of Transport Layer Security (TLS) certificates. This open framework is defined in the experimental RFC 6962 1https://datatracker.ietf.org/doc/html/rfc6962 (Request For Comments).
The ending of the almost eponym 1946 movie finds Frank musing about his own incoming death. You see, he and his beloved Cora escaped justice once after having killed her husband, Nick. But here he is, condemned for murdering Cora, even though her death was accidental. And in his mind, it feels pretty much as if Justice was served in the same way as the postman delivers letters, who rings once, and if nobody answers, rings again for important missives.
Arguably, a lot of drama could have been avoided if Frank had just absconded with Cora straight from the beginning. And instead of a goodbye note left in a cash register for Nick, Cora would have posted a letter from far away. But that would probably not have made an interesting story, apart maybe, the said delivery of the letter by a postman.
That will be the focus of today’s post. Except instead of an envelope, stamps and paper, we will bring it to our digital era and look at how emails travel and what measures can be taken to ensure they are legitimate.
Or even better, what measure can be taken to prevent unauthorized people to send an email seemingly coming from our domains.
Working as a CSOC analyst is becoming more complex, with alert volumes increasing rapidly as perimeters are integrated, tools, regulatory constraints, and the need to detect suspicious behaviour as quickly as possible.
Increasing the number of analysts to solve these problems would seem utopian as cybersecurity skills are increasingly sought after and consequently hard to obtain. Even though attracting talent must continue to be a major challenge, implementing good CSOC tools to simplify daily life is also critical. As is usually the case with the triptych: process, competent personnel, and technology, which must be adjusted to implement an efficient CSOC. As a result, the technology part of this article will focus on the CSOC tooling.
In the hope of preventing a breach, companies deploy various detectors: from border security (firewall, proxies, …) to endpoint protection (EDR, antivirus, …). And, potentially, centralize all these events in a SIEM to correlate and implement Use Cases.
So many solutions and vendors, but yet some questions remain: how well (or not) is your detection against the most common attack vectors for your business sector? Are you able to detect attackers’ activity once they breached your infrastructure? Do you have overlapping sensors?
This article presents a framework, Mitre Att&ck (Adversarial Tactics Techniques & Common Knowledge), which becomes more and more popular and attempts to address the above questions. We will first, remind the existing methods and detail how Mitre Att&ck contributes to improving the understanding of an attack. We will then describe the various objectives achievable with this, as well as the requirements to get the most of it. Lastly, we will consider the interface developed by Mitre to fulfil the objectives efficiently.
Our website uses cookies technologies to assist with navigation and your ability to provide feedback, analyze your use of our products and services, to enable you to use the social media functionalities and assist with our promotional and marketing efforts, and provide content from third parties. You may choose to opt-out from all non-essential cookies or allow them for a better browsing experience.
For more information on the use of cookies, Please check our Privacy NoticeACCEPTREJECTSETTINGS
Privacy & Cookies Policy
Privacy Overview
This website uses cookies to improve your experience while you navigate through the website. Out of these cookies, the cookies that are categorized as necessary are stored on your browser as they are essential for the working of basic functionalities of the website. We also use third-party cookies that help us analyze and understand how you use this website. These cookies will be stored in your browser only with your consent. You also have the option to opt-out of these cookies. But opting out of some of these cookies may have an effect on your browsing experience.
Necessary cookies are absolutely essential for the website to function properly. This category only includes cookies that ensures basic functionalities and security features of the website. These cookies do not store any personal information.
Functional cookies help to perform certain functionalities like sharing the content of the website on social media platforms, collect feedbacks, and other third-party features.
Performance cookies are used to understand and analyze the key performance indexes of the website which helps in delivering a better user experience for the visitors.
Cookie
Duration
Description
SRM_B
1 year 24 days
Used by Microsoft Advertising as a unique ID for visitors.
Analytical cookies are used to understand how visitors interact with the website. These cookies help provide information on metrics the number of visitors, bounce rate, traffic source, etc.
Cookie
Duration
Description
CLID
1 year
Microsoft Clarity set this cookie to store information about how visitors interact with the website. The cookie helps to provide an analysis report. The data collection includes the number of visitors, where they visit the website, and the pages visited.
CONSENT
2 years
YouTube sets this cookie via embedded youtube-videos and registers anonymous statistical data.
MR
7 days
This cookie, set by Bing, is used to collect user information for analytics purposes.
SM
session
Microsoft Clarity cookie set this cookie for synchronizing the MUID across Microsoft domains.
_clck
1 year
Microsoft Clarity sets this cookie to retain the browser's Clarity User ID and settings exclusive to that website. This guarantees that actions taken during subsequent visits to the same website will be linked to the same user ID.
_clsk
1 day
Microsoft Clarity sets this cookie to store and consolidate a user's pageviews into a single session recording.
Advertisement cookies are used to provide visitors with relevant ads and marketing campaigns. These cookies track visitors across websites and collect information to provide customized ads.
Cookie
Duration
Description
ANONCHK
10 minutes
The ANONCHK cookie, set by Bing, is used to store a user's session ID and also verify the clicks from ads on the Bing search engine. The cookie helps in reporting and personalization as well.
MUID
1 year 24 days
Bing sets this cookie to recognize unique web browsers visiting Microsoft sites. This cookie is used for advertising, site analytics, and other operations.
VISITOR_INFO1_LIVE
5 months 27 days
A cookie set by YouTube to measure bandwidth that determines whether the user gets the new or old player interface.
YSC
session
YSC cookie is set by Youtube and is used to track the views of embedded videos on Youtube pages.
yt-remote-connected-devices
never
YouTube sets this cookie to store the video preferences of the user using embedded YouTube video.
yt-remote-device-id
never
YouTube sets this cookie to store the video preferences of the user using embedded YouTube video.
yt.innertube::nextId
never
This cookie, set by YouTube, registers a unique ID to store data on what videos from YouTube the user has seen.
yt.innertube::requests
never
This cookie, set by YouTube, registers a unique ID to store data on what videos from YouTube the user has seen.