SecurityTrails Blog

Note: The audio version doesn't include code or commands. Those parts of the post can be seen in the text version.

IP and DNS intelligence gathering has become a critical part of any organization's cybersecurity outlook.

The process of discovering "what service is hosted where" can prevent most common causes of security-related incidents. Things like outdated installs, abandoned installations and in-development software running on publicly accessible domains are a major source of such attacks. Domain and specially subdomain discovery is a critical skill for hackers, security researchers and pentesters. Therefore, using different recon strategies and software is essential, no matter if you are a beginner or an infosec veteran. Today we will introduce you to a handy tool we discovered recently, called Asset Finder.

What is Asset Finder?

Asset Finder is an open source project aimed at simplifying information gathering for subdomains and domains of an organization. Asset Finder leverages many publicly available data sources to help you during your asset discovery process. It does so by building a list of subdomains related to a domain, sourced from popular data sources such as crt.sh, certspotter, HackerTarget, Threat Crowd, Wayback Machine and more, all of which give Asset Finder multiple data sources to fetch data from.

Asset Finder installation

Installing Asset Finder is pretty straightforward. This solid tool provides pre-compiled binaries for multiple operating system platforms including Darwin (OSX), Windows, Free BSD and Linux, along with the ability to also compile a build of Asset Finder straight from source. To grab the latest build binaries available, head over to. At the time of this article, Asset Finder v0.1.1 is the latest available version, which is the version we'll use in our guide below. To begin with, download Asset Finder with the following command:

Next, extract the file:

To verify if Asset Finder runs fine on your system, run the command:

This should then give you the following output:

Testing and Results

Using Asset Finder is quite easy. It utilizes the following command syntax:

For example, to find both subdomains and domains associated with GE.com, use:

If you wish to find only the subdomains associated with GE.com, use:

Popular Asset Finder alternatives

Asset Finder can certainly help during your reconnaissance process, but if you ever feel this tool comes up short for your domain and subdomain gathering needs, you can always rely on other DNS discovery apps and tools. Let's now explore the leading Asset Finder alternatives.

DNS Map

DNS Map is a popular tool that's frequently included in the Kali Linux operating system toolkit, relying on built-in word lists to map and list subdomains belonging to a domain. To install DNS Map execute the following commands:

Using DNS Map:

Replace domain.com with the domain for which you're seeking subdomains. For example:

Subfinder

Subfinder is another popular Asset Finder alternative, which allows you to find and list subdomains associated with a domain. Installing Subfinder is easy, you just need to download the latest release of Subfinder from GitHub:/

At the time of this writing, the latest version is 2.4.8:

Extract the downloaded archive:

The syntax to run Subfinder is as follows:

For example:

Security Trails API

The Security Trails API allows you to perform information gathering and asset discovery tasks with ease. As seen with the tools detailed above, most rely on 3rd-party datasets and inbuilt wordlists. And while these tools may cover most of your attack surface, a single undetected asset can lead to serious security implications. One single undetected and vulnerable domain or subdomain in your organization can lead to further intrusions. Another notable advantage of the Security Trails API is its ability to filter out inactive subdomains, as larger organizations frequently create multiple subdomains when working on deploying web applications being tested. F...

For years now, network security has been one of the main investments organizations of all sizes make to protect their networks, users and data.

Much of this focus has come about to address the sheer volume and sophistication of cyber threats in today's landscape. The rise of malicious actors seeking to compromise data, steal information, disrupt services and cause damage has led to the implementation of numerous defense strategies, practices and technologies. Encrypting data, using firewalls to prevent unauthorized traffic entering the network, employing anti-malware solutions and a variety of other tools are upheld as a standard for more or less every organization, and are used to detect cyber attacks and ultimately stop them. Another tool that is just as universal is the IDS, or intrusion detection system. Next to packet analysis, log aggregation, proxy firewalls and similar blue team tools, IDS is an indispensable tool for defense teams to detect and prevent attacks.

Intrusion detection systems have been around for decades, and while they've gone through many iterations and innovative advancements, the IDS still stands as a fundamental part of good cyber hygiene. Just as a home alarm system is designed to alert you to an intruder's attempt at breaking in, an IDS will in the same way monitor network traffic and notify you of suspicious activity. In this post we'll explore the history and concept of intrusion detection, its importance in network security, the different types and detection methods of IDS, as well as some of the challenges they face that may require solving with next-gen technologies.

Concept of intrusion detection

The earliest concept of intrusion detection systems was set forth in 1980 by James Anderson at the NSA with his "Computer Security Threat Monitoring and Surveillance" report. Then, in 1986, Dorothy E. Denning wrote "An Intrusion-Detection Model", an academic paper that shaped the foundation for many systems still in use today. The model presented in the paper was used to develop the Intrusion Detection Expert System, or IDES. The IDES model detected behavior patterns of a potential intruder by using statistics for anomaly detection based on profiles of users, host systems, and target systems. From the 1980s all the way to the early 2000s, IDS was considered a security best practice. But, at that time, the noisy and turbulent nature of networks led to many false positives from IDS, labeling it unreliable in the eyes of many.

In recent years, however, their dominance and the challenges of cloud computing have shined a new light on intrusion detection systems, a longtime staple of enterprise security. And while many organizations invest in proactive security measures and other preventative strategies, they can still fail. Detecting attacks that may occur afterwards remains crucial.

What are intrusion detection systems?

The term IDS itself refers to the processes used for the detection of unauthorized access to and intrusive activities on a network. An intrusion detection system, therefore, is a tool that monitors network traffic for potential intrusions that may indicate malicious activity or a breach of policies. Intrusions in this sense can be defined as any type of unauthorized access with the potential to harm the confidentiality, integrity and availability of data. An IDS issues alerts when such activity is discovered, which is then either reported to an admin or collected through a security information and event management system (SIEM). Often compared and confused with a firewall, an IDS doesn't sit on the perimeter of a network and monitor traffic with the goal of determining what should be allowed into the network the way a firewall does.

An IDS is ideally placed at strategic points within a network, where it monitors and analyses traffic to and from endpoints on the network to detect any malicious activity. This allows an IDS to act as a second layer of security, in case a threat slips thro...

Note: The audio version doesn't include code or commands. Those parts of the post can be seen in the text version.

IP intelligence involves information gathering on the IP addresses used to provide access to web applications and web services within an organization.

It provides a modern perspective for securing one's virtual organization, in the same way that an organization's physical office and assets are secured. And with the increasing frequency and sophistication of internet attacks, the need to secure one's organization becomes more important every day. With the rise of IPv6 and the shortage of IPv4, newly deployed services are often seen running dual-stack with both IPv4 and IPv6. However, IPv4 is usually accounted for and firewalled while IPv6 isn't. This leads to your services being protected over IPv4 but accessible over the public internet for IPv6. Thus, information gathering leads to asset discovery, which includes various software stacks including web servers, web applications, databases and even physical devices such as IoT devices and much more.

Why IP discovery is important for organizations

With organizations running multiple software stacks and internal teams running different versions of the very same software, it's important to understand and track what runs where. Consider the following: often, software is tested on legacy platforms to ensure compatibility for long term support (LT-S) software versions. In this scenario it's imperative to know whether the test platform itself is secure or not, as vulnerabilities can enter into the test platform itself, opening the software being tested to the threat of malicious code injections. Maintenance is another important aspect to consider. Public internet-facing web applications are frequently set up and left running without maintenance, meaning components of the web application (such as the web server or database) can become out of date, left to run with vulnerabilities present. And these vulnerabilities can be further exploited by attackers to enter your organization's network.

Simply put, IP reconnaissance is key-to know what service runs under your organization, for maintenance purposes and for security purposes.

IP discovery using Nmap

Nmap is a handy network-mapping tool which can be used from any Linux- or Windows-powered system to map one's organization. When it comes to mapping larger organizations, however, Nmap does have certain speed and time-related disadvantages. Within each of your organization's IP addresses, Nmap has to "ping" or "probe" each port available to determine whether it is OPEN, FILTERED or CLOSED to access. Multiply this process by 100 or even 1,000 IP addresses, and such a task becomes tedious and time-consuming. And with the rise of IPv6, wherein an organization can easily have 1,000 or 10,000s of IP addresses (with one or more IP addresses allocated to each of the organization's devices or servers), the effort grows even more daunting. Nmap is already shipped in most modern Linux distributions, but if you haven't installed it, check out our Nmap Tutorial Guide, which covers the installation process.

Next, run Nmap to scan a range of IPs, 192.168.0.1 to 192.168.0.100, with the following command. The ultimate "catch" in using Nmap remains that you should already know all of your organization's IP address assets before starting. Only when all of your organization's IP addresses have been scanned can you get complete coverage when searching for out-of-date software, misconfigured private services via public networks, and the like.

What about fping?

fping is another handy tool for discovering active hosts within your organization's IP address space.

Consider the following example:

With the above command, fping sends 1 ping request to each IP address within the subnet 192.168.0.0/24 (that is, from 192.168.0.1 to 192.168.0.254). All active hosts that reply to the ping request get listed on your terminal. The catch with using fping is sim...

With challenges as complex as the myriad of technologies involved, the need for accurate representation regarding all things cyber remains an elusive endeavour.

Consequently, if there's one resounding principle actionable intelligence via internet scanning has taught us, it is that adopting a proactive attitude towards accurate threat identification and correlation is the necessary first step if we are serious (or even care) about evidence-based knowledge and contextualization dictating the flow of any successful investigation. This is particularly true of information delivered in the form of IoCs (Indicators of Compromise) which, for years, have been the cornerstone of many security products based on forensic artifacts and similar intrusion detection mechanisms. Sharing these IoCs in a tokenized and consumable fashion has also ensured that the cyber community at large stays visibly engaged with the latest attack patterns, whatever their origin or level of sophistication may be.

At the heart of this blog post lies yet another attempt, this time by Salesforce researchers John Althouse, Jeff Atkinson, and Josh Atkins, to collect threat information into a new Io-C variant by fingerprinting the initial conditions that dominate TL-S client and server responses regardless of the underlying platform. In fact, JA-3, a fortuitous amalgam of the authors' names, has now been incorporated into a multitude of security tools as a method to detect malicious applications, especially those deployed at mass scale and without regard for trivial detection. We'll begin our journey by briefly examining the determining conditions surrounding TLS's handshake process as it pertains to the set of extensions used by JA-3 to fingerprint associated traffic between client and server, extending our focus to encompass relevant aspects of the hashing and tagging capabilities associated with JA-3 in identifying malware platforms and C2 agents.

Finally, we'll explore some of the shortcomings associated with JA-3 in light of circumventing attempts aimed at the core of its very functionality.

A TL-S, SS-L primer

Sensitive data requires the strongest of protection mechanisms. For a number of years, premier standards and protocols, like Secure Sockets Layer (SS-L), dominated the secure tunneling scene by achieving a suitable interplay between performance and confidentiality, providing secure communications over untrusted media such as the internet.

Despite its early success, SS-L progressively eroded under a plethora of cryptographic weaknesses and statistical biases marked by protocol design flaws that signaled the potential for brute-force attacks, in particular, the AE-S, CB-C and RC-4 implementations were notorious for leaking sensitive cipher material in the presence of weak keys leading up to full plaintext recovery scenarios. Subsequently, as explained in JARM: A Solid Fingerprinting Tool for Detecting Malicious Servers, Transport Level Security (TL-S) became the next evolutionary variant after a long chain of revisions and improvements that entailed adopting newer forms of cryptographic primitives and cipher suites, the negotiation of session keys in lieu of early distributed approaches, and better computation costs. It was precisely this cryptographic agility that gave TL-S its multifaceted quality, covering a wider range of network applications and providing critical services such as confidentiality and integrity.

To understand how JA-3 leverages certain TL-S attributes, let's take a closer look at the protocol's initial connection sequence. Immediately following the TC-P handshake, the client side sends a ClientHello message containing combinations of cryptographic algorithms supported (and preferred) by the caller, versioning details, extensions, a list of compression methods, and other session parameters in blocks of application data. In response, the server sends its own ServerHello message when a satisfactory set of algorithms has been confirmed—t...

A while ago, we wrote about the fantastic Owasp Amass tool, and as we believe in the open source movement as the primary fuel of the Internet, Jeff Foley has since become one of our sponsored open-source developers.

Supporting and giving back to the community has been one of the core values of this company since the beginning. For quite some time, we've been thinking about a solid solution to improve the data about subdomains and domain names on the Internet, in the right way. What if a single user performing scans, could also start sharing this new information with a service provider that can ingest the findings, and then give back to the users so they can perform similar or even improved scans? It's a win-win scenario. Say hello to the new Amass enumeration information sharing feature. Let's find out what the new integration is about.

Send your Amass enumeration results

Owasp Amass has released a new version that includes a community information sharing feature that supports submitting data to the newly created Security trails community data sharing API endpoint. In addition we will show you how many subdomains/domains you contribute with your Amass enumerations right in your account, and according to how many accurate and new findings you contribute, the more chance you have for some great surprises.

How does it work?

Create a free API account. Download the latest version of Owasp Amass. Configure Amass to use your Security trails API key. Start scanning for subdomains and domains with the Amass '-share' flag turned on. Inside your Security trails user account, you'll see how many contributions you have made.

That's it. All your Amass enumerations will help people to expand the accuracy of subdomain and domain results, and at the same time, we are giving back to the infosec community with some awesome surprises...

Join the Amass x Security trails Recon Master Contest

The information sharing feature truly is an effort by the community, for the community but we wanted to up the stakes. From July to August, we will run the Amass x Security trails Recon Master Contest where by sharing your findings and earning points, you will be able to climb on the leaderboard and win awesome prizes, worth thousands of dollars! Prizes for the Top 10 on the Leaderboard will include access to your favorite Security trails tools, cash prizes of up to $5000, monthly API credits and special edition Security trails swag! Sign up to be the first to know when the Amass x Security trails Recon Master Contest starts and get an advantage by being one of the first to submit entries!

Join the contest!

The number of cyberattacks is increasing rapidly, leading to significant losses in businesses' revenue and reputation. According to Cyber Security Ventures, the global cost of cybercrime is projected to reach USD 10.05 trillion by 2025 annually.

Cyber Threat Intelligence (CT-I) is the act of collecting threat data from various sources to help organizations better understand adversaries, their motivations, attack techniques, tactics, and the preferred attack vectors they employ. CT-I will also boost an organization's ability to discover new and unknown threats. By knowing such information, organizations may foster their security defenses by adopting proactive security measures to become more prepared for future attacks. In this post, we'll be shedding some light on popular threat intelligence sources, the threat intelligence lifecycle, CT-I platforms and how to use our own Securitytrails products for threat intelligence data collection.

Threat intelligence sources

A security team should gather threat data (including indicators of compromise) from various online sources, both free and commercial, to ensure the most comprehensive threat intelligence coverage possible. The three primary categories of CT-I sources are:

Vendor data:

Every organization utilizes IT infrastructure and technologies purchased from one or more vendors. For example, routers, switches, server operating systems, and other security appliances such as Firewalls and ID-S,IP-S systems. Most IT vendors have a private threat intelligence feed. Customers can often subscribe to remain up to date with the latest threats, and discovered vulnerabilities, targeting their specific IT infrastructure and deployed software.

Public sources:

Government agencies mainly operate these at no cost. Examples of public CTI sources include:

FB-I.

SANS Internet Storm Center.

US Computer Emergency Response Team (US-CERT).

Private sources:

These are commercial enterprises that provide threat data for a fee, commonly on a subscription basis. Some commercial threat data sources could be Accenture Security Cyber Defense, Booz Allen Cyber Threat Intelligence Services and Crowdstrike.

Cyber threat intelligence lifecycle

For the threat intelligence gathering to be successful, a proper methodology or framework should follow. A general CT-I lifecycle is formed from the following phases:

Requirements:

Defining the goals from collecting the threat intelligence data and the methodology we will use to achieve these goals.

Collection:

Threat data is collected from various sources such as public and private sources, security solutions logs, public posts on social media platforms, darknet forums and websites hosting leaked information. Open Source Intelligence (OSINT) techniques are utilized to discover threat information posted on publicly available sources during this phase.

Processing:

The gathered data is organized into a format to be interpreted easily by the security team.

Analysis:

The security team will analyze collected data and transform raw data into information that can be consumed to make informed decisions to protect the organization's digital assets.

Feedback:

The outcomes are delivered to relevant stakeholders, usually at regular intervals. Reports typically contain recommended courses of action and allow stakeholders to evaluate.

Threat intelligence platforms and tools

The volume of data collected from different threat intelligence sources can be overwhelming. Tools are used to filter results and help the security team keep the most relevant data according to their requirements while discarding the rest. There are different tool sets to aid in CT-I endeavor; however, using a threat intelligence platform is considered the ideal option for organizations to aggregate data from multiple sources in an efficient, organised, and automated manner. A threat intelligence platform is a system that can be deployed either on cloud or on-premises. It helps an organization collect data from vario...

With growing interconnectedness and the amount of information and digital assets organizations store and process, one of today's biggest challenges is protecting that information.

Consequently, cyber attacks have become more widespread and sophisticated, impacting the critical infrastructures of many organizations and gaining access to their most valuable assets. Besides investing in technology, organizations should turn to relevant policies and industry standard frameworks to better inform their practices. It's a critical step toward keeping data and systems secure and managing cybersecurity risk effectively. A cybersecurity framework is a set of standards, guidelines, common language and best practices that organizations use to better manage cybersecurity risks and improve their cybersecurity programs. These highly beneficial tools also help organizations communicate more soundly, both internally and with third parties in areas that include sharing information about attacks.

One such framework is the Nist Cybersecurity Framework, widely considered the gold standard for addressing and managing security risk in a cost-effective way, based on the business needs of an organization. While we mentioned it briefly in our incident response article, today we'll delve deeper into the Nist Cybersecurity Framework and get familiar with its components and guidelines.

Nist Cybersecurity Framework 101

Created by the National Institute of Standards and Technology (Nist), a government agency that works in many areas of technology, this framework for improving critical infrastructure cybersecurity filled the gap created by a lack of unified standards for cybersecurity and risk management across organizations. This particular set of standards, guidelines and practices is considered a staple for any organization working to build or improve its cybersecurity program, as well as its ability to detect, respond, prevent and recover from cyber attacks. Nist describes the Framework as a risk-based approach to cybersecurity risk management and as such, it contains three components: Core, Implementation Tiers and Profiles. Each component fortifies the connection between activities that drive the operational and financial results of a business and cybersecurity activities in that business.

The Framework Core is a combination of cybersecurity activities that presents industry standards, guidelines, practical references and key industry cybersecurity outcomes for managing cybersecurity risk. It's made of five Functions that present a general view of the lifecycle of an organization's risk management process. Each of these Functions consists of Categories and further Subcategories, which are matched with examples, Informative References that contain existing standards and guidelines for each Subcategory.

Implementation Tiers (or just Tiers) provide organizations with a way to evaluate their current cybersecurity posture, how they view risk, and what processes they have in place to manage cybersecurity risk. They reflect approaches to managing risk that range from informal and reactive to more risk-informed and resilient.

Framework Profile components represent the 'outcome' part of the framework, based on the business needs that an organization has chosen from the framework's categories and subcategories. They can be used to detect weak points and opportunities, as a means to improve their security posture by comparing their current profile with a target one.

Framework Core

As mentioned, the Nist Framework Core provides a compilation of activities that help organizations achieve specific outcomes, all with practical examples that will guide them to those outcomes. It contains references to industry standards, guidelines, and practices that allow for the communication of cybersecurity activities and outcomes across the organization. Designed to improve existing cybersecurity practices in an organization, the Core's four elements, Functions, Categories, Su...

Fueled by changes in how people live and work in the post-Covid world, more and more cyber attacks and data breaches are affecting organizations of all sizes. It's crucial to be prepared for the worst.

We often say that in cybersecurity, it's important to think about "when" an attack will occur, not "if" it will occur. And while being proactive is touted as the key to an organization's most effective security posture, one should never dismiss the value of reactive security practices, either. Building up your defences against attacks and cyber risks is important, as is knowing how to detect malicious actors who have breached your systems. Having these strengths can discourage incidents from escalating into major data breaches. And data breaches, as we know, can lead to financial, reputational and legal repercussions that may be detrimental, even devastating, to an entire organization and all of its operations. Organizations may never completely eradicate security incidents, but they can establish procedures to help minimize their effects. Preparing for an incident and knowing how to brace for its eventual impact is a solid method of prevention against cyber attacks.

This is where incident response comes into play.

Difference between a security event and an incident

Before we delve into incident response, let's explore what a "security incident" is, and how it differs from a "security event." These terms can be confusing, and the line that separates them is somewhat blurred. Security alerts help organizations detect cyber attacks and potential malicious behaviour quickly. These alerts are produced by an array of security tools that security analysts ingest for their valuable work. And because these alerts indicate security events which can be false positives or false negatives, they need to be analyzed. For example, if an analyst in the SOC receives an alert from their SIEM, they'll need to determine whether that event is a true positive with a negative impact on the organization, such as a financial or reputational risk. If determined to have a potential impact on the confidentiality, integrity or availability of the organization's information security, it becomes a security incident.

That's when it warrants initiation of the incident response protocol. So, in plain English, a security event is just that, an event that needs further examination. It might be a false alarm, and only becomes a security incident when it's determined to have a potential for damaging effect.

What is incident response (IR)?

When a security incident occurs, it's essential for your organization to be ready for whatever comes next as well as how to respond. Incident response (IR) is a methodical approach, one that includes policies and procedures to prepare for, detect, contain and recover from a security incident. The goals of incident response are to limit damage, reduce recovery time, lessen costs the incident may cause, and for the organization to recover as quickly as possible. Incident response ensures that the organization can get "back to normal", meaning the state the system was in before the incident occurred, and is equipped with the techniques and knowledge needed to prevent the incident's reoccurrence. It also allows organizations to establish best practices for damage prevention while helping to inform other, more proactive security practices.

A rather important note about incident response is that it's not only an IT process, but a business process as well, helping organizations with continuity and quick decision-making. Because security incidents can have both short-term and long-term effects on an organization, incident response can be considered part of the business continuity process, with its goal of maintaining normal business operations and minimizing the impact of unexpected events. Additionally, security incidents carry with them a slew of potential financial losses due to the high data recovery costs, breaches of regulatory co...

A few weeks have passed since our last product update, and for the month of June we're excited to announce several new items for Attack Surface Reduction version 2, Surfacebrowser and our free public application.

Provider Dossier

Surfacebrowser now includes a new provider dossier feature that enables you to get a quick overview of the organization's hosting-related data, such as company type, description, address, and acquisitions over time, as shown in the following screenshot:

New free AS-R version

Over the past few months, our engineers and product team have been working hard to release a free version of our popular Attack Surface Reduction version 2 solution. Now, AS-R Free enables you to check your organization's internet-facing infrastructure instantly by providing exposed ports, public assets, detection of private IPs, hosts pointing local, and more!

Unified product experience

Surfacebrowser as well as our public application have received new UI updates including a fresh new sidebar, light and dark theme, and layouts and buttons with new rounded borders. These and future product design updates share the common goal of unifying the Securitytrails product experience.

Other notable product updates include:

Surfacebrowser , Removed the 10k limit for associated domains in the Surfacebrowser sidebar and also on /app/sb/domain/domain/associated. Attack Surface Reduction , The Explore page can now collapse IPs. More can be shown by clicking the plus n. Attack Surface Reduction , Users can now submit hostnames using the new endpoint. Attack Surface Reduction , Downloads added to AS-R sections for SS-L (/inventory/ssl-certificates) and Apex domains (/inventory/apex-domains). Connect with us on Twitter and let us know what you think about these new features. Stay tuned for further updates!

A few weeks have passed since our last product update, and for the month of June we're excited to announce several new items for Attack Surface Reduction version 2, Surfacebrowser and our free public application.

Provider Dossier

Surfacebrowser now includes a new provider dossier feature that enables you to get a quick overview of the organization's hosting-related data, such as company type, description, address, and acquisitions over time, as shown in the following screenshot:

New free AS-R version

Over the past few months, our engineers and product team have been working hard to release a free version of our popular Attack Surface Reduction version 2 solution. Now, AS-R Free enables you to check your organization's internet-facing assets instantly by providing exposed ports, public assets, detection of private IPs, hosts pointing local, and more!

Unified product experience

Surfacebrowser as well as our public application have received new UI updates including a fresh new sidebar, light and dark theme, and layouts and buttons with new rounded borders. These and future product design updates share the common goal of unifying the Securitytrails product experience.

Other notable product updates include:

Surfacebrowser , Removed the 10k limit for associated domains in the Surfacebrowser sidebar and also on /app/sb/domain/domain/associated. Attack Surface Reduction , The Explore page can now collapse IPs. More can be shown by clicking the plus n. Attack Surface Reduction , Users can now submit hostnames using the new endpoint. Attack Surface Reduction , Downloads added to AS-R sections for SS-L (/inventory/ssl-certificates) and Apex domains (/inventory/apex-domains). Connect with us on Twitter and let us know what you think about these new features. Stay tuned for further updates!