SecurityTrails Blog

SecurityTrails Blog

By SecurityTrailsTechnologyTech News
Download on the App Store

SecurityTrails Blog episodes

  • The Equinix Attack: Understanding Ransomware Behavior
    According to the United State's Cybersecurity and Infrastructure Security Agency (CISA), the number of ransomware attacks around the world has increased, and the Computer Emergency Response Team (US-Cert) states that this sort of breach hits a target every 14 seconds.
    As stated in the above September 9, 2020 status report, **Equinix was internally compromised with ransomware**. To provide some context, we're talking about an American multinational company that holds multiple data centers in the Americas, Europe and Asia, with an increasing-over-the-years NASDAQ stock value.
    And to show you just how big this company's digital fingerprint is, we sought an overview of their assets by entering the domain name equinix.com into Surfacebrowser. The output looked like this:
    But as you may know, they're not the only large business being targeted. There's a huge economy behind ransomware that makes these activities very profitable for criminals. Usually, everything starts with an in-depth malicious asset discovery.
    The Equinix attack
    According to an unknown source that reported to BleepingComputer, this attack was perpetrated by the infamous **Netwalker ransomware**.
    Despite this claim, we haven't found any official statements about it. The source also shared that there was a message sent to Equinix with the usual ransom note as well as a screenshot listing the stolen assets.
    The more sound theory regarding the possible entry point of this attack states that there were multiple remote desktop protocol (RDP) instances running at the time. There's even a test in the previously mentioned blog post that shows multiple listening RDP servers within Equinix's different public IP spaces.
    While we'll confirm this in a few moments, it's still hard to say that this was the actual attack vector used by the ransomware creators. We'll show you why, by giving you some information to analyze so you can draw your own conclusions.
    To analyze Equinix's digital assets, we can extract the whole set of autonomous systems (ASN) by doing an ASN lookup filtered by the company's name. Below you'll see the list of all registered ASN at the different regional internet registries (RIR's).
    Taking for granted that the actual description is correct (as this could be forged in case they're trying to obscure something), the amount of ASNs and total number of IP range sizes they advertised makes the quest for internal-only IP ranges quite difficult when the actual customer space is so large.
    For this you'll need to rely on certain additional characteristics such as reverse DNS (rDNS) records, DNS records holding names that give clues about internal border-ish infrastructure, and the like; the vector we found is, at the very least, tricky.
    Despite all this, we're linking related information from a past blog, in case you want to know more about how to find IP addresses owned by a company.
    Now we're using Surfacebrowser again—to find not only the company's IP space but also those addresses that have actually been seen with the TCP3389 port open (which corresponds to the standard Microsoft RDP port).
    In this SQL Explorer query, we're doing the following:
    Getting all IP addresses, hostnames pointing to those IP addresses, reverse pointer records that these IP addresses point to plus the correspondent ASN that's announcing them.
    Getting all IP addresses that match "Equinix, Inc." as the nominated ASN Owner.
    Getting all IP addresses with a history of opened TCP ports number 3389 (RDP default port).
    Results as follows:
    As you can see, multiple results match the mentioned criteria. Yet it's quite probable that this is the way they were entered (although a piece of this puzzle remains unseen).
    To help us dig a little deeper, let's cover a few basics on what ransomware is, how it operates and how to deal with such attacks if you ever find yourself compromised.
    The ransomware ecosystem
    While ransomware attacks are nothing new, their inc...
    15 min
  • Reblazing Web Security, Announcing a New Product, and Listening to Records with Tzury Bar Yochay from Reblaze
    Web applications contain sensitive data like user information, financial data, and intellectual property. That data is valuable and alluring to malicious attackers. Cyber attackers looking for vulnerabilities and weak spots to gain unauthorized access for stealing data keep web applications under constant threat.
    Web applications have had security issues since their beginning. The deployment of new protocols and technologies circumvented many of them, but an alarming number of applications are still unprotected from an even more alarming number of vulnerabilities.
    Protecting web applications and traffic is imperative in the current threat landscape. A solution that encompasses different approaches is crucial in web application security. Tzury Bar Yochay recognized the issues that come with existing web application security solutions and set out to create a single-tenant cloud-based platform that provides next-gen WAF, DDoS protection, bot management, and API-security.
    Reblaze started 10 years ago in Tel Aviv, Israel, and now has offices in the US and Singapore. While working with bigger companies, they continue to bring innovation to the web security field. We met with Tzury (while social distancing) to learn more about the vision behind Reblaze and how they were able to "Reblaze" web security. We even got to be the first to hear about an exciting new project - Curiefense and got a glimpse into Tzury's impressive record collection.
    **Securitytrails: Hi Tzury! Tell our readers a little bit about yourself and your background. (We here at ST already know, since you have been here from the start, as far back as one of the early ST meetups in LA!)**
    **Tzury Bar Yochay:** Right on, that was the Manhattan Beach take on Silicon Valley. An AirBnB apartment where the ST team gathered to work on the product in its early days.
    I started Reblaze after several intensive years as a cybersecurity consultant in the intelligence community, working for three-letter agencies. Back then, setting up a WAF was a complex process, installing an appliance within the datacenter. Maintaining it was an even more complex task.
    For DDoS protection you needed a different vendor, and the solution was either an appliance or a scrubbing center. Unfortunately, even the best solutions weren't providing full protection against attackers. For example, DDoS solutions tended to perform poorly on layer 7 (HTTP), and true human/bot detection did not exist. My idea was to set up a PaaS platform that would provide all those capabilities on top of a reverse proxy, while leveraging cloud capabilities just emerging at that time.
    We looked around and found there were only two companies with a similar concept, CloudFlare and Incapsula. However, we compared them to our prototype design and saw they had three key deficiencies — they deployed their own stacks on data centers, their systems were multi-tenant on both ends (runtime and management console), and they had only rudimentary bot-detection capabilities. Conversely, our system deploys on public clouds (for example, AWS), is single-tenant (each customer gets a dedicated Virtual Private Cloud), and at the time, seemed to be the only one that could detect headless browsers and analyze user-generated events, such as mouse movements, keyboard strokes, and touch-screen taps.
    Even though there was competition, we knew we could do better, and we created the Reblaze platform.
    **While bootstrapping sounds like a risky thing to do for many companies just starting out (and it is), most companies we know bootstrapped at some point. Reblaze did as well. What have you learned and what were the key takeaways from the experience?**
    **Tzury:** I can't speak for others, but for us it was the organic path to walk. We saw a problem, a growing problem, that we wanted to solve, so we dedicated ourselves to solving it. Once we had an MVP, we wanted to test it and get immediate real-world feedback. We found the new paying ...
    19 min
  • SSL TLS History: Discovering Service Encryption
    Note: The audio version doesn't include code or commands. Those parts of the post can be seen in the text version.
    Privacy in peer-to-peer communications throughout the World Wide Web has become an extremely widespread issue, especially over the last few years.
    Secure socket layers (SSL) and its evolutionary descendant, Transport Level Security (TLS), are the most widely used protocols for ensuring confidentiality among service information exchanges. Despite this fact, their implementation is one of the most misunderstood, misconfigured, and prone-to-human-error options available.
    "Why?" you may ask. Opinions on the matter differ greatly, but generally, when implementing SSL TLS encryption you're facing a life-like organism that continuously mutates and needs constant re-evaluation and caring.
    Remarkably, cryptanalysts such as Elizabeth Friedman (pictured above) did this in the past with only the use of pen and paper (no modern Osint tools to crack such things at the time!).
    In the tradition of greats like Friedman, a vast number of mathematicians and codebreakers are constantly testing different cryptography algorithms for strength, usability, and any problems that could possibly arise if used broadly.
    This is true not only for brand new encryption algorithms (as we featured before in "All Things Quantum") but also for currently used ciphers that are broken or will be at any point in the future. They leave room for misconfigurations, deprecated implementations (such as expired certificates), and other problems to be addressed.
    Do I have SSL certificates deployed?
    This is a valid question, especially if you're not running your infrastructure and want to analyze for any possible attack vector that could allow a posterior compromise.
    To address this, we'll show you how to check for the history of deployed certificate records using Surfacebrowser, by performing a certificate discovery starting from your company's name or a desired hostname.
    Then, we'll use our SecurityTrails API to show how you can do nearly the same thing using different tools and interfaces.
    Scraping your company’s certificates using Surfacebrowser
    After logging into the interface you'll find the text box with the option **Company Domain** selected. Enter your desired hostname, then check the results:
    Results for this or any other desired hostname will be displayed in the following fashion, as a listing with all recovered digital assets ordered by categories. On the left menu, you can find the SSL label and click into it to get all certificate-related information.
    Here you can see all the certificates found, and you can order them by different criteria such as expired and valid dated registries.
    By clicking on the certificate name you can go one step further and visualize particular information about every certificate—such as hashing fingerprints, creation and expiration dates, issuer, and subject information among others.
    In case you want to play around and do cross-checks of information by using an SQL-syntax, we invite you to check out our latest post, Product Update: SurfacebrowserTM SQL-explorer: SSL Certificate Scraping Showcase.
    Find your company's SSL historical records with SecurityTrails API
    API documentation is available here and you can also find SSL-related functionality at **Domains, SSL Certificates (Pages) and Domains, SSL Certificates (Streams)**.
    These pages will provide all the certificate information related to a certain hostname you enter, and below you can see the query results, which are output in JSON format.
    Every record will be separated and you can browse between all options, labels, and results information.
    Streams, on the other hand, will output everything together and you'll have to take care of every corresponding label identification. Here's what it looks like:
    We've covered how to get all of your certificate's information using SecurityTrails API. Now let's go a little further and c...
    10 min
  • Cats, Board Games, and Analyst-Centric Threat Intelligence: Speaking with Pulsedive Co-founders, Dan Sherry and Grace Chi
    Two heads are better than one, and the same rings true when starting a company. You can have the idea, the entire business plan set out, the drive and desire needed, but there might be something missing. This is where most founders turn their focus to the search for a perfect co-founder. A co-founder that complements their skills, helps them turn their ideas into reality, brings a fresh perspective, and is there to support them.
    Dan Sherry started Pulsedive with the goal of combating the sensory overload that comes with the noise generated by open source threat intelligence. The growing wealth of open source intelligence data doesn't necessarily make Osint easier. On one hand, you can access almost any information you need, but on the other hand, you must also navigate and discern the relevant data, essentially finding a needle in the ever-growing haystack.
    After looking for someone to help him shape his idea from the ground up, Dan, who is more tech-oriented, found Grace Chi with her vast experience in product marketing and related fields. With their two starkly different backgrounds, but entirely complementary expertise and skills, Dan and Grace were able to shape Pulsedive into what it is today.
    We had a chance to chat with Dan and Grace and hear about their experiences working as co-founders, their biggest strengths and how exactly they complement each other, as well as their business philosophies on building both an analyst and community-centric platform. You'll also find out what the early start of Pulsedive looked like, the differences between well-run and poorly-run S O Cs and the common challenges they face, and how cats can, in fact, be very good business advisors.
    **SecurityTrails: Dan, you began Pulsedive as a solo founder and then Grace joined you as a co-founder. How did this journey go?**
    **Dan Sherry**: I spent a period of time at the start looking for a co-founder, long before Grace joined, but finding the right person is tougher than it sounds. First, you need to get them on board with your vision, because they will likely need to leave their day job to earn less than the market average, building something that is statistically likely to fail. Second, they ideally need to complement your skills, which might mean searching outside the industry. If they aren't already in your network, you might need to put your trust in a total stranger, and they would need to put their faith in you, your experience, and your observations about the market landscape.
    **What is some advice you would give to entrepreneurs that are looking to find a co-founder or partner? What is something nobody tells you about the process of finding and having a co-founder?**
    **Dan**: It's more likely you already know someone who would make a good fit than finding someone. Because you are giving them significant equity, you have to really trust that person. I've found that you don't really know someone until you've actually worked with them. Working at the same company as someone is not the same as working on a project together.
    Additionally, try to gain some knowledge of the domain you're looking for a co-founder to cover. Consuming business knowledge, learning from others, and teaching myself marketing and design, helped me recognize people who know what they're talking about.
    The hardest part, that nobody tells you, is once you find the right fit, you need to convince them to join your tiny company, in a crowded market, for not that much pay.
    **Grace comes from marketing related-positions, and Dan from a technical background. How do two stark backgrounds actually work for you and bring such positive outcomes in running a company?**
    **Dan**: Our approach from the start was to build the marketing right into the product. People could jump into the experience we were aiming to deliver, rather than hitting just the marketing content. This choice is a challenge because it's hard to balance what each user might be looking for...
    19 min
  • ReVolte Attack: Encrypted Voice Calls Interception
    Without a doubt, telecommunications have evolved beyond the imagination. We can now do things on our smartphones and personal computers that we once saw only in the realm of science fiction.
    Yet despite the technological approach applied to every stage of telecommunications, there have always been specific designs regarding the information exchanging protocols used to set up a standardized language that allows devices to speak to each other.
    As history has repeatedly taught us, this is where most security issues occur. We've seen it throughout history, from Caesar's ciphers through World War II's Enigma machine all the way to today's methods of high-speed communication, including virtual private networks, secure shells, voice over IP, and video calls.
    Today's topic covers a specific, recently discovered flaw by David Rupprecht, Katharina Kohls, Thorsten Holz, and Christina Pöpper (Ruhr University Bochum & New York University Abu Dhabi) which involves one of these communications protocols, Voice over LTE (Volte for short). LTE stands for Long Term Evolution and is a modern communications standard used by many companies to provide different services (using additional technologies) to customers.
    What is Voice over LTE (Volte)?
    Voice over LTE-networks (also known as HD voice) are basically an additional feature to the whole LTE/4G stack that brings high-quality voice communications to LTE-networks by using the actual LTE frequency bands. You may have noticed that when communicating by phone and your device or provider doesn't have Volte enabled, there is a signal downgrade to a lower technology (such as 3G) to establish your voice connection.
    Usually, these voice channels aren't great, and call quality has been lagging behind Internet speed improvements for years. Volte has improved this by taking advantage of the LTE-reserved spectrum and by sending voice in a voice over IP fashion.
    Unveiling the ReVolte attack
    The "Re" part of ReVolte indicates the attack technique used to deceive this technology's protection measures, as in "Key Reuse". This type of attack takes advantage of the kind of cipher implementation most popularly used for network transfers called stream cipher. Stream ciphers are commonly implemented by utilizing a shared secret key to encrypt information, by using a secret key that's at least the same size as the actual ciphertext.
    As shown in the example below, this method usually involves the fragmentation of every piece of information into frames that are encoded separately, then decoded in the same fashion. Here you can see the fragmentation of a certain two-letter plaintext into two different to-be-encoded pieces of information. Once every byte is encoded, the ciphertext is built.
    Notice that the flow of an XOR stream cipher works in a simplified way, which is very efficient for network transmissions. And that's what we all want when transmitting information between remote parties.
    Once the transmission arrives its destination, it needs to be decoded. For that, it uses the exact same shared key to perform a Xor operation again, this time between the ciphertext's frames and the key.
    Modern communications are more complex, but these are the main components and functionality that involve this kind of stream cipher encryption.
    Keystream reuse problems
    The main issue with XOR keystream operations is that you can recover the actual key by operating the plaintext against the ciphertext. This means that an attacker who manages to sniff the encrypted message and obtains portions of the sent information could potentially discover the key that's making the stream encryption possible.
    In this next image, we follow the previous example and operate our plaintext separated frames against the resulting ciphertext, as if it was obtained by sniffing into network traffic.
    This XOR permutation allows us to recover our secret key. With that, we'll be able to decrypt the whole communication.
    For ...
    9 min
  • DNS-map: an Old-School Network Recon Tool
    Note: The audio version doesn't include code or commands. Those parts of the post can be seen in the text version.
    When it comes to the vast array of open source tools available to the infosec community in 2020, one could say we're spoiled.
    Installing Kali Linux or any other pentesting distro reveals the massive amount of tools in today's infosec landscape that make the work of researchers, analysts and other security professionals easier, faster and more accurate.
    This certainly wasn't the case 14 years ago, when DNSmap was released. Tools like DNSmap marked the beginning of the ever-growing toolset we now find ourselves privileged to have.
    Although many of the older tools remain limited in their capacity, their simplicity provides an opportunity for beginners or even those with limited time to conduct research swiftly.
    What is DNSmap?
    ** DNSmap** provides the ability to find Osint data like subdomains and IP addresses associated with each domain.
    This can help researchers discover tests or other subdomains that should not necessarily be exposed to the Internet, increasing the attack surface area within an organisation.
    For a broader picture of DNSmap's effectiveness, we've listed a few of its pros and cons:
    **Features**:
    **Easy installation**: If you're using Kali Linux, DNSmap already comes pre-installed. If you're using any other Linux distro, installing DNSmap takes less than a minute.
    **Simplified usage**: DNSmap focuses on a narrow set of objectives and does it well. This makes learning and using the tool easy.
    **Vintage**: DNSmap is battle-tested—it's been around for years and is still available on many pentesting distros.
    **Drawbacks**:
    **Archived**: The software is no longer actively maintained, so new bugs in the software might not get patched.
    **Features**: This is subjective, but if you prefer tools that do a lot, DNSmap might feel somehow limited.
    Who is DNSmap for?
    Like many of the other open source tools we've reviewed, DNSmap is suitable for both blue and red team investigations during the reconnaissance or data-gathering phase.
    It is highly recommended that beginners or junior analysts test out DNSmap to see what it can do. Once an analyst understands how DNSmap works, they can also compare the results with those of other tools that perform similar tasks.
    Installing DNSmap on Linux
    DNSmap comes pre-installed as a package on Kali Linux. We also investigated other Linux distros, and found it available on BlackArch and ParrotSecurity OS as well. We suspect that if the package is available on Kali, then it's probably available on other infosec distros through their software managers—but that's unverifiable, owing to the lack of documentation from various pentesting distros. You can, however, find more information about the Kali package here.
    We will now install DNSmap on a fresh Ubuntu installation. As it's always important to use some type of sandboxing environment when installing new software, you can opt for a virtual machine (VM), container or a remote test server.
    We're using the latest Ubuntu version, 20.04, for this review, and any commands used here should apply to Debian-based distros (and with a few minor tweaks, to other distros as well).
    DNSmap is written in C, so we'll install the required packages to compile the software:
    Next we'll clone the repo, then proceed to compile it:
    Unlike the installation of Masscan (which also required compiling), compiling DNSmap goes quickly and results in no warnings.
    Testing / usage
    Now we'll run a few tests to see DNSmap in action.
    Our first test will be to run a vanilla scan to see what results we get:
    DNSmap searched for subdomains on nytimes.com using the tool's built-in wordlist. We added a 100-millisecond delay to avoid our test IP getting blocked and we saved the output data to `testdata/`.
    Taking a look at the output, we can see that 37 subdomains and 74 IP addresses were found.
    We took a sample...
    7 min
  • Product Update: SurfaceBrowser - SQL Explorer: SSL-Certificate Scraping Showcase
    One of our newest SurfaceBrowser features is **SQL Explorer**. This cool new feature allows you to combine the power of structured query language with our huge records database, allowing you to extract the most information possible.
    Today we'll share some easy-to-follow examples that can help you find interesting, and even unusual, data on SSL certificates issued around the world.
    In case you want more information regarding this and other helpful innovative features, join the loop and keep track of new products in our changelog page.
    Let's dive in!
    Listing SSL-certificates issued by location
    As you may know, the Vatican City is the smallest country in the world, but is it so small that nobody issues certificates there? We can find out by querying with two different properties: **ssl.subject.country** and **ssl.issuer.country**
    This query shows several items that are very common in SQL language, and a few extra properties like **ssl.domains** (which shows the actual domains covered by the certificate) and **domain.hostname** (which shows the fully-qualified name of the device). You can order the results by the property you want, in an ascendant or descendant fashion.
    Finding self-issued certificates
    Self-issued certificates are intriguing. Occasionally they reveal long-forgotten systems that can be investigated, compromised, then maybe even exploited and used as a lateral-movement platform.
    For this example, **ssl.is_self_signed = true** shows all results of certificates that are not being signed by a certificate authority, commonly known as a CA. The result we see above is the combination of these self-signed certificates plus **ssl.subject.country = “CN”** (which filters all results to those certificates that claim to belong to a Chinese entity).
    Searching coronavirus-related domain certificates
    In this example, to complement our previous article on finding coronavirus domains we're looking for a specific keyword inside **ssl.domains** to find suspicious targets, or to track anything you like. Additionally, we'll query all the certificates that are self-signed and expired (using 2020-09-01 formatted as yyyy-mm-dd in Unix timestamp).
    Above you can appreciate the different possible results and query combinations used to achieve this.
    Finding certificates with misconfigured dates
    Going one step further, we wanted to showcase examples of certificates invalid on both dates. Its **ssl.not_before** and **ssl.not_after** dates should not be outside boundaries; meaning that **not_before** shouldn't be in the future (or before Jan 1st, 1970) and **not_after** shouldn't be a date before our current date.
    Oddly enough, we found a few certificates published throughout the internet that fall exactly in between these cases. Check out the results below:
    As you can see, this new feature is quite powerful—it can help you with finding complex situations regarding certificates.
    Downloading query results
    Once you have your desired results, you can simply click **Add to downloads** and place the result in your list of downloadable results. For added convenience, you can select **Json** or **CSV** to obtain the information in either of those available formats.
    Once downloaded, you may delete your results or leave them there as you add others to your collection.
    How to access SQL Explorer
    SQL Explorer is a preview feature we're making available to interested users. Want to be among the first line of researchers using this brand new interface? Request a demo.
    4 min
  • Common Cyber Security Risks to Watch Out For
    Data and information are power. From private companies and enterprises to government agencies, schools, health care organizations and non-profit foundations, every type of business or institution regards its data as its greatest treasure. That treasure can contain personally identifiable information (PII) such as names, addresses, birth dates, social security numbers, and medical records, as well as intellectual property—including patents, trademarks, financial information, and more.
    With this in mind it's safe to assume that organizations are highly interested in protecting their data; after all, it's at constant risk. If it's valuable to the organization, it will surely be valuable to malicious actors, whether to be sold on the black market, used for market advantage, leveraged to ruin reputations, or just because.
    To protect ourselves against risks, we should first know what they are, and understand them. While every organization has an abundance of risks (including competitive, economic, operational and strategic risks), they tend to put less focus on **security risks**. This is unfortunate, as security risks could impact and heighten other risks: **loss of data can impact reputations and cause operational issues such as downtime**, not to mention the substantial financial losses organizations suffer due to data breaches.
    We mentioned security risks when we talked about risk assessment and risk management, and how we use the two to lead better-informed decision-making when understanding and mitigating security risks. Additionally, we went over what constitutes a risk in cybersecurity, but we're now due for a deeper dive into the security risks that plague the current threat landscape.
    The 7 most popular security risks across all organizations
    Before we explore today's most common security risks, let's reiterate what a security risk actually is. Security risk is the likelihood of financial, operational and reputational damage resulting from the failure of an organization's IT systems as a result of a cyber incident, such as a data breach or other type of cyber crime.
    We can recognize several sources of security risks. These can be:
    Insider threats, such as competitors engaging spies among your own team members, disgruntled employees, or simple human error
    Outsider threats, such as cyber criminals, hacktivists, and nation states
    Third-party providers and suppliers
    Data breaches and cyber attacks can be perpetuated for different reasons. These can include financial gain by selling the data on the black market, identity theft, disruption of services, activism, or even as the result of sheer negligence. While there are a number of reasons for them and different organizations face different risks, there are some that affect all industries and organizations of all sizes.
    Last week, we ran a poll on our Twitter account to see what our followers have to say about the most prolific security risk they've encountered at their workplace, and in general. Here are the results:
    As per our results as well as current news and research, we've compiled a list of the 7 most common security risks that all organizations should be aware of:
    1. No backup and recovery plan
    Surprisingly or not, our followers did say that the **lack of a backup and recovery plan** is the number one risk for organizations today. Statistics support this claim, too: a survey of SMEs by Riverbank IT Management found that 46% of SMEs don't have a backup and recovery plan, and for those that do have it, 23% have never actually tested it.
    Recovery plans are designed to protect organizations in times of disaster, including security incidents and data breaches. A backup and recovery plan focuses on the policies and procedures organizations should follow in certain scenarios to protect their most valuable assets and systems and reduce downtime, financial impact and reputational loss.
    While every organization will have a unique backup and reco...
    14 min
  • Rust Scan: Empowering N-map One Scan at a Time
    We all love Nmap, we really do. It's one of the first and most famous Osint-like security tools created, written almost 23 years ago (at the time of this writing) by Gordon "Fyodor" Lyon.
    Since September of 2007, it's been maintained and upgraded by Lyon and a number of developers, many from Google's Summer of Code program. And on top of its long history, it continues to offer many cool features that are still extremely helpful when conducting mapping of network-facing services, for all sorts of assessments that can improve your attack surface reduction tasks.
    So this is a post about Nmap? No! Actually, today we're featuring Rust Scan, an Nmap enhancer that helps you avoid time-wasting by rapidly discovering a target's open ports and combining that with the power of Nmap.
    Rust Scan's inner workings
    When running, Rust Scan conducts a preliminary scan using its own internal discovery technique: it creates sockets against its targets and waits for their responses.
    Once this first scanning stage is completed it executes a second round using Nmap as the tool with specific tags that, by default, aim to discover the targets' operating systems.
    These settings are configured by default and can be tweaked if necessary on every scan. You can also run scans without using Nmap if you like.
    How is this done? As its name suggests, Rust Scan is coded in the Rust programming language sponsored by Mozilla, and offers to be your go-to solution for speed, process parallelism, and memory safety.
    Let's explore how to use this tool.
    Installing Rust Scan
    To keep installation as simple as possible for this article, we've decided to use the docker image. You can, however, check out the different options on the GitHub official docs.
    For our example, we'll do a docker pull command to download the image to our operating system, plus a simple shell alias to use the whole environment as if it were installed locally.
    To install, we'll use the stable version of the docker image Rust Scan:alpine
    Once it's downloaded you can check to see if everything is downloaded properly, by doing:
    Then we can add a simple alias line to our favourite profile file. For our case we'll use the **.bash_profile** file:
    Then (in case you're running bash as a shell) you can run the **alias** directly with the specified line or simply run the following to make it work:
    Your Rust Scan installation is now ready to use. Note that using the --help flag will show every option, as there are a few (especially compared with Nmap itself). This helps make learning as simple as possible.
    Running a scan
    Starting the scanning is easy and straightforward. Simply place your desired target after the command name and this alone will activate the first round of analysis.
    When running the tool with the **-q** flag we see Rust Scan at a more basic level of function. This will create a port scanning task against a desired target and show the open ports found.
    As shown above, the output shows a comma-separated list of ports being discovered by Rust Scan's internal port-scanning engine, demonstrating how quick this tool can be.
    One important detail to note is that all these scans are being made using TCP connections, with no UDP capabilities so far. Once the scan is completed it will stop, and there will be no data exchange between the tool and Nmap.
    As shown above, the scan starts and once the first phase is finished with the list of the open ports it shows the **"Starting Nmap"** message. Then the second phase initiates.
    Analyzing results
    As the tool claims to speed up Nmap scanning times, we made some simple comparisons to find out if this is true, and to see how these two ways of "invocation approaches" can be compared.
    For the first test, we tried scanning a host with some TCP ports open and checked the time declared by the tool. See the output below:
    As shown above, Rust Scan found two open ports which were delivered to the Nmap executable and w...
    6 min
  • Risk Assessment vs Risk Analysis vs Risk Management: When Being Optimistic Isn’t Ideal
    Life is about taking risks. Business is about taking risks. Heck, anything you do involves taking risks. But you wouldn't jump right off a cliff into unknown waters, would you? You'd want to know: How deep is the water? Are there sharks? Is there anyone around you who could help if you needed it? Are you even ready to make the jump?
    While yes, there are adrenaline seekers among us who would gladly take the plunge, let's look at it from a non thrill seekers' perspective: you would only jump if you knew you had the skills to do it safely, consider all the circumstances, assess the terrain, enlist someone to help out if necessary; essentially, prepare yourself for everything that comes with taking a risk.
    And putting our exaggerated example aside, running any modern business or enterprise is all about taking risks. Information technology has brought on a new dawning of conducting business (and even our everyday lives)—as well as a whole new set of risks.
    You've certainly stumbled upon terms like **risk assessment, risk analysis and risk management**, and quite possibly heard them used interchangeably. While there is an overlap in the actual functionality of these terms and what they consider, there are a few differences worth pointing out, to help those involved in these processes avoid misunderstanding and wrong expectations. That's why today we'll examine these terms and what they mean from a strategic standpoint.
    Let's begin by learning what "risk' actually is, in the context of cyber and information security.
    What constitutes a risk in cybersecurity?
    Put simply, a risk is generally any situation that involves exposure to danger. When speaking in cybersecurity terms, we can translate this as a likelihood of damage both to finances and reputation, resulting from the failure of an organization's information technology systems upon suffering a cyber attack or data breach.
    Think of cybersecurity risks as the intersection of threat, vulnerability and **assets**: the **assets** are what we're trying to protect, the **threat** is what we're protecting them from, and the **vulnerability** is a gap in that protection. This puts risk in the middle of the action, as it entails the damage or loss of an asset as the result of a threat exploiting a vulnerability.
    Cybersecurity risks are inherent in the current threat landscape, and no one is immune to them. Nearly every business faces cyber risks, and they can come from different places. Among these risks are:
    Outsider threats such as different types of cybercrime, advanced persistent threats, network security threats, and the like.
    Insider threats, which can range from cyber espionage to employees unwittingly clicking on a wrong link.
    Third parties with sub par cybersecurity posture working with the organization.
    There are plenty of ways in which cyber attackers can strike, and many ways in which you can unintentionally put your organization at risk. So what can we do about it? Assess, analyze and manage!
    What is cyber risk assessment?
    To explore these terms and their relationship to one another, let's take a hierarchical perspective: risk analysis is part of risk assessment, and risk assessment is part of risk management.
    While it might be logical to start from the bottom (if we're still looking at it from a hierarchical viewpoint), it's more telling to start with risk assessment, and in going through its steps, arrive at its most crucial: risk analysis.
    Risk assessment is exactly what it sounds like—identifying the risks, their likelihood of happening, and estimating their consequences.
    All of this leads to better decision making towards understanding and mitigating said security risks. Specifically in cybersecurity, **risk assessment identifies and analyzes security risks posed from both external and internal threats that can be damaging to organizations' critical data and infrastructure**. We can also look at risk assessment as a strategic cybersecu...
    13 min

About SecurityTrails Blog

From the publisher's feed

Listen to all the articles we release on our blog while commuting, while working or in bed.