Cybersecurity Advisories

Spring4Shell Detection & Mitigation CVE-2022-22965


Spring4Shell, or CVE-2022-22965, is a RCE (remote code execution) flaw in the “Spring framework”. Spring, as it is commonly known, is an open-source application framework that provides infrastructure support for developing Java applications. Basically, it helps you write Java applications. According to :

“…Spring is infrastructural support at the application level: Spring focuses on the “plumbing” of enterprise applications so that teams can focus on application-level business logic, without unnecessary ties to specific deployment environments.”

Currently, all versions of Spring are impacted, but the web application must be running on JDK version 9 (the local Java installation) for the application to be vulnerable.

The application must also be running on top of Apache Tomcat.

The impact here is that an application running on a web server will have certain permissions. Those permissions will vary greatly, depending on how the application is built and installed. You should always assume that the web services is running with root privileges until proven otherwise. With that in mind, this Remote Code Execution vulnerability would allow an unauthenticated attacker to run commands on the underlying web server with the permissions of the web service.

Image 1: Bad bad bad!

Detecting Exploitation

Understanding the Exploit

The vulnerability relies on the ability to traverse the properties of a java class from a query parameter and locate a file that the attacker can both write to and has meaning to the execution of the program.

You would then make a request like such:


Example exploit code:!%3D-1)%7B%20out.println(new%20String(b))%3B%20%7D%20%25%7Bsuffix%7Di




The above creates a file called shell.jsp in the webapps/ROOT folder. One final command can be used to exploit the vulnerability:

curl http://localhost:8080/shell.jsp?cmd=whoami

Understanding Detection

Filename/Web Shell
The initial PoC used a filename called tomcatwar.jsp, however, this is trivial to change so any new .jsp files should be scrutinized.

Log sources: Web server OS-level logs, Web server (e.g. Apache Tomcat) logs, EDR logs


POST Requests
It may be possible to detect by inspecting POST requests. Look for requests that contain class.module.classLoader.resources.context.parent.pipeline.first in the url.

Generically, looking for *.jsp or *.class* may also help detect.

Log sources: Web server (e.g. Apache Tomcat) logs


Yara Rule
This yara rule is designed to detect JSP webshells and in particular references the possibility to detect webshells found after exploiting the Spring4Shell PoC:

SecurIT360 SOC Managed Services

If you utilize our SOC Managed Services, here are the actions we are taking to help detect this activity:

MDR Services

  • There is an MDR rule in place looking for traffic associated with known IP addresses, we are pulling from a GreyNoise Trends list.
  • A firewall block list is available if you would like to proactively block these IPs at your firewall –
  • Nessus has released some plugins to help detect systems vulnerable to this exploit and we have incorporated these into your External Vulnerability Scans over the weekend. If we detect internet facing vulnerable systems in your environment, we will contact you directly.

EDR Services

  • We have incorporated known IOC information to help with detection, if we see activity related to this exploit, we will contact you directly.

Vulnerability Discovery

Here we are identifying affected systems.

For Nessus plugin ID 159374, “Spring Framework < 5.2.20 / 5.3.x < 5.3.18 Remote Code Execution (CVE-2022-22965),” users are required to enable the “Show potential false alarms” setting, also known as paranoid mode, in their scan policy in order to enable this plugin in a scan. In addition, the “Peform thorough tests” setting must be enabled as well.

We also recommend enabling only this specific plugin in a paranoid scan. Scan policies configured to have all plugins enabled will see an increase in the number of triggers, as it will include all paranoid plugins during the scan.

Enabling Paranoid and Thorough Tests Modes

To enable this setting for Nessus and users:

  1. Click Assessment > General > Accuracy
  2. Enable the “Show potential false alarms” option
  3. Enable the “Perform thorough tests (may disrupt your network or impact scan speed)” option

Plugin ID 159374 is available in feed serial 202203311743.


Temporary mitigation

To apply the temporary mitigation, applications could extend RequestMappingHandlerAdapter to update the WebDataBinder at the end after all other initialization. In order to do that, a Spring Boot application can declare a WebMvcRegistrations bean (Spring MVC) or a WebFluxRegistrations bean (Spring WebFlux). More details here:


Computer & Network Security

A Vulnerability Assessment is NOT a Penetration Test


Understanding the difference between a penetration test and a vulnerability assessment is critical to understanding security posture and managing risk. Vulnerability assessments and Penetration tests (pen test for short) are very different from each other in objectives, processes, and outcomes. However, sometimes the terms are incorrectly used interchangeably. In this article, we will explore the differences between the two as well as how they relate to each other.

First, what do we mean by objectives, processes, and outcomes? Put simply, objectives are specific and measurable goals which are desired to be achieved. Processes are the steps required to achieve an outcome and accomplish an objective. An outcome is the benefit gained from achieving said objective.

The first way vulnerability assessments and pen tests differ are their objectives.


The objective of a vulnerability assessment is to identify, rank, and report vulnerabilities or potential vulnerabilities that, if exploited, may result in system compromise. This is a broad stroke kind of assessment. You want to discover any and all vulnerabilities.

With penetration testing, there can be numerous objectives because there are various types of pen tests. Organizations that have never had a pen test performed or ones that are focused on compliance should start with a conventional pen test. This is typically designed to discover and exploit vulnerabilities that could allow access to sensitive information or resources.

For organizations that have established security programs there is another type of pen test that provides additional value above and beyond simply finding and exploiting vulnerabilities. This is called Assumed Breach. Assumed Breach pen tests are internal penetration tests that are typically designed to blend real attacks with pen testing techniques. It’s common on Assumed Breach pen tests to use the same tools and techniques used by actual attackers. This type of penetration test, depending on the organization’s goals, may also include defeating or bypassing security controls and may even include attempts to evade detection.


Another major difference between the two is in the process. Penetration testing requires the use of varying toolsets and an experienced, skilled security professional to conduct the test. During the engagement, the pen tester may modify tools or change parameters of an attack in order to customize the use of an exploit for the environment. Penetration testing is a more hands-on process, one that’s tailored to the company and the environment, in comparison to a vulnerability assessment.

The SecurIT360 Offensive Security Team uses a combination of industry standard penetration testing methodologies such as the OWASPv4 Web Testing Methodology and the Penetration Testing Execution Standard as well as internally developed playbooks to perform highly comprehensive and effective penetration tests.

A vulnerability assessment, on the other hand, includes more automated processes that do not require real-time management. The vulnerability scan itself is automated and is generally conducted using a single tool. Vulnerability scans can be scheduled to run automatically without manual intervention or manipulation. It does, however, require specific knowledge of the products/systems and the environment being scanned. Interpreting the results can also be difficult for those who are not familiar with the output of a vulnerability scanner or have experience evaluating vulnerabilities as a whole. Here, vulnerability assessments and pen tests are similar in that an experienced, skilled analyst is required to assist in the assessment.

Desired Outcome

While both are point in time assessments there are various reasons for an organization to conduct vulnerability assessments and pen tests. The outcomes identified below are of course not exhaustive but are meant to describe some of the more common reasons for each.

Vulnerability assessments may assist in satisfying compliance standards, defining security posture, and identifying known vulnerabilities against a system or number of systems. Like I said earlier, the purpose is broad strokes, to find all the vulnerabilities we can.

With a penetration test, we are still looking for all of the vulnerabilities that we can with the intention of exploiting that vulnerability to compromise an account, a system, a domain, gain access to sensitive data, etc. A properly performed pen test may help determine the effectiveness of security controls, identify how long a threat may be able to remain in the system undetected, or test an incident response program, for example.


Even though they are accomplished using different toolsets, processes or even people, both pen tests and vulnerability assessments serve important functions for protecting your environment and reducing risk.

I hope this article has been helpful to you in learning the difference between vulnerability assessments and penetration tests. If you got value from this blog post, consider subscribing to our blog. We are regularly publishing new blog posts and sharing new information from all across the security landscape, with the goal of keeping you up-to-date on the latest security news.

If you would like to learn more about vulnerability assessments, penetration testing, assumed breach or discuss in greater detail how these assessments could benefit your business, please contact us.

SecurIT360 services include Security Assessments and Audits, Vulnerability Assessments, Penetration Testing, Managed Detection and Response, and Incident Response. SecurIT360 works with businesses across multiple industries including legal, financial, utilities, and healthcare. Let us help you determine where you should spend your time and money protecting your information.

Computer & Network Security

How to Prepare Your Firm For a Business Email Compromise in Office 365

This is part 1 of a 3 part series on preparing for, preventing, and responding to Business Email Compromise

Part 2 – Business Email Compromise Prevention and Mitigation

Part 3 – Coming Soon: Responding to Business Email Compromise

The BEC Problem

Since 2014, the FBI’s Internet Crime Complaint Center (IC3), has recorded over $6.2 Billion dollars in losses as a result of Business Email Compromise, with $1.8 Billion dollars in losses in 2020 alone. For perspective, 100 one dollar bills stacked together is about 1 inch high. Can you guess how high a billion dollars stacked together is? 10,000,000 inches or 83,3333 feet or 157 miles! For more perspective, the tallest mountain in the world is Mount Everest, with an elevation of just over 29,000 feet or about 5.4 miles.

Chances are good if you’re reading this you may have some idea of what Business Email Compromise (BEC), sometimes called Email Account Compromise (EAC), actually is. Perhaps, you’ve even fallen victim to this type of scam. For those that are less familiar, and very generally, BEC is a type of scam that targets businesses and individuals and, using a combination of simple but extremely effective techniques, convinces an employee to fraudulently transfer funds to a bank account the threat actor controls.

How to Prepare

The goal of this article is to help your Firm prepare for BEC scams in Office 365.

“The time to have the map is before you enter the woods.” – Brendon Burchard

In this article, we identify three key components of Office 365 that, if put in place prior to a BEC, are extremely helpful when the unfortunate circumstance, a BEC scam, arises. Now, this is by no means an exhaustive list, however, these are things we often see are lacking and/or missing during our Microsoft 365 Security Assessments as well when we begin log collection for BEC incident response cases.

Note, if you have not yet enabled and enforced Multifactor Authentication (MFA) for all users, we highly recommending doing that now. MFA is single handedly one of the most important things you can do to prevent BEC.

Quick Warning
Running scripts or code you copy from the internet or from articles like this is at your own risk. It’s always a good idea to review, test and make sure you know and understand what something is going to do before you run it, especially against a production tenant.

1. The Unified Audit Log (UAL)

The UAL records user and admin activity from your organization for a number of Microsoft products including Azure Active Directory, Exchange Online, SharePoint, OneDrive and more.

If you only take one thing away from this article, make sure it is this. Even though Microsoft documentation says that “Basic Audit is turned on by default for all organizations with an appropriate subscription” its one hundred percent a really good idea to verify this. We have seen it time and time again. We begin an investigation with log collection, only to find out the Unified Audit Log has not been enabled, leaving us with few artifacts that are helpful for BEC investigations.

The second piece of advice is to determine if the default retention period is enough for your Firm. By default, with Basic Audit, audit data is kept for only 90 days. You can extend this by subscribing to a subscription that comes with Advanced Audit. This is typically included with Microsoft’s E5 line or similar. With Advanced audit, you can retain audit logs for longer periods of time such as 1 year or 10 years. You also get access some additional, but very crucial, Mailbox Audit Log items we will discuss in the next section such as, MailItemsAccessed and Send. Oh and yes, unfortunately Microsoft is pay walling this absolutely critical audit log items behind their E5 subscriptions.

Verify that the Unified Audit Log is Enabled
The Unified Audit Log can be verified and enabled two different ways. With the Microsoft Admin console and with PowerShell. Chose the option that is most comfortable for you.

Using the Microsoft Admin Console

  1. Go to and sign in.
  2. In the left navigation pane of the Microsoft 365 compliance center, click Audit.
    1. If auditing is not turned on for your organization, a banner is displayed prompting you start recording user and admin activity.

3. Click the Start recording user and admin activity
4. It may take up to 60 minutes for the change to take effect.

Note, We created a PowerShell script to assist in identifying the Microsoft 365 components that are commonly missing. If you want to check that out and run it on your environment, see here: BEC-Preparation script. Use at your own risk.

Using PowerShell

  1. Launch PowerShell as an Administrator
  2. Run the commands:
    1. Install-Module ExchangeOnlineManagement
    2. Import-Module ExchangeOnlineManagement
    3. Connect-ExchangeOnline
    4. Get-AdminAuditLogConfig | FL UnifiedAuditLogIngestionEnabled
  3. If you see UnifiedAuditLogIngestionEnabled : True then the Unified Audit Log is enabled and you don’t need to do anything else.
  4. If you do not see a value of True, enable the Unified Audit Log with
    1. Set-AdminAuditLogConfig -UnifiedAuditLogIngestionEnabled $true
  5. A message is displayed saying that it may take up to 60 minutes for the change to take effect.
2. Mailbox audit Logs (MAL)

The MAL records activity by mailbox owners, delegates, and admins for things such as when an item was created in the Calendar, when an item was deleted or moved, etc.

The second most important thing you can do related to your Office 365 tenant is to make sure that Mailbox Audit Logging is enabled for all users. It is also pretty handy to have the MailboxLogin action enabled. More on that below. Now, according to Microsoft starting in January 2019 Microsoft was going to be turning on mailbox audit logging by default for all organizations, for all new mailboxes that were created.

Again, my recommendation is to verify that Mailbox Audit Logs are enabled for all of your users and add the MailboxLogin action to each user. The first step to doing that is to verify that the setting AuditDisabled is False. I know, pretty straightforward right. Then you want to check each user to ensure mailbox audit logs are being recorded for their account. Finally, consider enabling MailboxLogin for each user. This is helpful because it gives you a SessionId with which to track user logins with.

These setting can only be verified using PowerShell, sorry to those who prefer the GUI.

Note, We created a PowerShell script to assist in identifying the Microsoft 365 components that are commonly missing. If you want to check that out and run it on your environment, see here: BEC-Preparation script. Use at your own risk.

Verify that Mailbox Audit Logging is Enabled

  1. Launch PowerShell as an Administrator
  2. Run the commands:
    1. Install-Module ExchangeOnlineManagement
      1. Only if you have not already installed this module
    2. Import-Module ExchangeOnlineManagement
    3. Connect-ExchangeOnline
    4. Get-OrganizationConfig | Format-List AuditDisabled
  3. If you see AuditDisabled : False then “mailbox auditing on by default” is enabled for your organization. Which means you’re good to go, Microsoft is logging mailbox audit events for your tenant.
  4. If you do not see a value of False, enable “mailbox auditing on by default” with
    1. Set-OrganizationConfig -AuditDisabled $false

Verify All Users Have Mailbox Audit Logging Enabled

  1. Launch PowerShell as an Administrator
  2. Run the commands:
    1. Install-Module ExchangeOnlineManagement
      1. Only if you have not already installed this module
    2. Import-Module ExchangeOnlineManagement
    3. Connect-ExchangeOnline
    4. Get-EXOMailbox -ResultSize Unlimited -Filter “RecipientTypeDetails -eq ‘UserMailbox'” -Properties AuditEnabled | Select-Object Name,AuditEnabled | Export-Csv csv -NoTypeInformation
  3. Review the CSV file that was created. Any user who has a value of False in the AuditEnabled column should be reviewed.
  4. To enable mailbox audit logging for a user run
    1. Set-Mailbox -Identity “Ben Smith” -AuditEnabled $false
      1. Where “Ben Smith” is the name of the user you want to enable mailbox audit logging for

Add MailBoxLogin to Each User

This mailbox action shows you details related to users signing into their mailbox. This can be very helpful for correlating threat actor activity and for distinguishing “good” logins (your user) from “bad” logins (threat actors).

  1. Launch PowerShell as an Administrator
  2. Run the commands:
    1. Install-Module ExchangeOnlineManagement
      1. Only if you have not already installed this module
    2. Import-Module ExchangeOnlineManagement
    3. Connect-ExchangeOnline
    4. $usersWithMailbox = Get-EXOMailbox -ResultSize Unlimited -Filter “RecipientTypeDetails -eq ‘UserMailbox'” | Select-Object DisplayName
    5. $usersWithMailbox | ForEach-Object { Set-Mailbox -Identity $_.DisplayName -AuditOwner @{Add=”MailboxLogin”} }

Advanced Audit

Straight from Microsoft’s documentation, “Advanced Audit helps organizations to conduct forensic and compliance investigations by increasing audit log retention required to conduct an investigation, providing access to crucial events (by using Audit log search in the Microsoft 365 compliance center and the Office 365 Management Activity API) that help determine scope of compromise, and faster access to Office 365 Management Activity API.”

Advanced Audit, unfortunately, is reserved for only those organizations that have an E5 Microsoft subscription. The reason Advanced Audit is a prized commodity during BEC investigations is because Exchange, SharePoint and Azure Active Directory audit logs are stored for 1 year by default and you gain access to several advanced auditing mailbox actions that can really help understand what a threat actor did while accessing a user’s Microsoft account and mailbox. The really important ones are: MailItemsAccess, Send and SearchQueryInitiated.

While it is an increased cost, it’s recommended to at least evaluate the cost vs value of being able to retain logs for a longer period of time and the ability to access some advanced mailbox audit actions, should they be needed.

3. Azure Active Directory Audit & Sign-in Logs

Azure AD Audit & Sign-in Logs records information about sign-ins, how resources are used by users, and information about changes or updates applied to your tenant.

Azure Active Directory (AAD) is third on this list but is by no means the least important. Quite the opposite in fact. Azure Active Directory Sign-in and Audit logs can be vital to a BEC investigation. Why do you need the Azure logs and the Unified Audit Log? Well, that’s because only a subset of Azure log events are ingested into the unified audit log.

The main thing to check with AAD is that you are able to retain the sign-in and audit logs long enough to be able to assist with BEC investigations. If you have Azure AD Free, well, you only get 7 days of Audit and Sign-in logs. You would need to upgrade to Azure AD Premium P1 or P2 to be able to get 30 days of retention on those same logs.

Seven days is simply not long enough for most investigations and 30 days is really cutting it close depending on how quickly an incident is identified and investigated.

You should retain those audit and sign-in logs for longer than the default. There’s a number of ways to do that including using an Azure storage account combined with Azure Monitor, collect them manually by downloading the logs through the Azure Portal or you could even collect them with whatever you’re using for a SIEM. The bottom line is, preserve these logs, they are important, and they will be especially helpful during a BEC investigation.

That’s it for this section, no fancy PowerShell commands for this one. Well, unless you want to view information about your licensing plans, services and/or licenses.

Note, We created a PowerShell script to assist in identifying the Microsoft 365 components that are commonly missing. If you want to check that out and run it on your environment, see here: BEC-Preparation script. Use at your own risk.

  1. Launch PowerShell as an Administrator
  2. Run the commands:
    1. Install-Module AzureAD
    2. Import-Module AzureAD
    3. Connect-AzureAD
    4. Get-AzureADSubscribedSku | Select-Object -Property Sku*,ConsumedUnits -ExpandProperty PrepaidUnits | Format-Table
    5. Get-AzureADSubscribedSku | ForEach-Object {$_.ServicePlans}
  • SkuPartNumber: Shows the available licensing plans for your organization. For example, ENTERPRISEPACK is the license plan name for Office 365 Enterprise E3.
  • Enabled: Number of licenses that you’ve purchased for a specific licensing plan.
  • ConsumedUnits: Number of licenses that you’ve assigned to users from a specific licensing plan.

For more information about the products, features, and services that are available in different Office 365 subscriptions, seeOffice 365 Plan Options.

Summary (TLDR;)

TLDR = Too Long Didn’t Read. For those not in the know.

Business Email Compromise is really big (criminal) business. Billions of dollars annually big. These three steps outline the most common things we see being missed when performing assessments and incident response in Office 365.

Step 1. Ensure the Unified Audit Log is Enabled. If it’s not, enable it now!

Step 2. Ensure Mailbox Audit Logging is enabled, for your tenant and for all users.

Step 3. Ensure you’re preserving Azure Active Directory Audit and Sign-in logs.

Optionally. Consider upgrading to get Advanced Audit and consider enabling the Mailbox Login action item for all users.

Note, We created a PowerShell script to assist in identifying the Microsoft 365 components that are commonly missing. If you want to check that out and run it on your environment, see here: BEC-Preparation script. Use at your own risk.

If you need any help with anything in Step 1, 2 or 3, read the associated sections. And if you’re in the unfortunate situation where your Firm has fallen victim to a Business Email Compromise, we are here to help.

Computer & Network Security

Business Email Compromise Prevention and Mitigation

Executive Summary

Business Email Compromise (BEC) is one of the most financially damaging cybercrimes. According to the Internet Crime Complaint Center (IC3), in 2020 the IC3 saw over $1.8 billion dollars in adjusted losses as a result of BEC.1

BEC attacks are all too common and there does not seem to be an end in sight. The question comes up time and time again, in Incident Response tabletop exercises, during penetration tests, in live incidents, and throughout our various security engagements with clients. “What can I do to prevent BEC?”

While we understand there are no silver bullets, the controls listed below are meant to be a detailed list of controls that can reduce the likelihood and impact of Business Email Compromise. These controls are a culmination of our experience working on BEC incidents and security engagements for our clients, our analysts experience and research as well as known industry best practices.

That being said, this list is not exhaustive, and it is not one-size-fits-all. It may not be feasible to implement some of these recommendations for a number of reasons. The controls your company implements should be based on your own risk assessment, your industry, and your data.

Lastly, preventing BEC is not the sole responsibility of IT nor is it the sole responsibility of the business units. Business Email Compromise must be seen as a threat to the company as a whole and must be treated as such. That means IT and business units must come together to design and implement both technical and non-technical controls and senior leadership should be involved in those discussions.

Control Areas

  • IT Controls
    These are the technical controls that we have seen play an important role in preventing BEC. These would typically be implemented and maintained by your IT team or MSP.
  • Business Controls
    The controls in this section pertain to business units and their policies and procedures that promote strong defense against BEC.
  • Financial Controls
    While shorter than the other two sections, it is one of the most important. This section speaks to controls that accounts payable, for example, can implement or improve to prevent BEC.

IT Controls

🔲 IT.1 Using Unique, Strong Passwords and Multifactor Authentication

It is no secret that one of the most critical assets for any company are their credentials. The service Have I Been Pwned, which  allows you to search various data breaches to see if your email address has been compromise, has more than 600 million passwords anyone can sift through.3

One of the most foundational and also highly critical aspects of security is unique and strong passwords. It’s all too common we see passwords reused for multiple sites or services and it’s equally as common that we see weak passwords like ‘Summer2021!’. Multifactor authentication, while not fool proof in of itself, ends up being the last line of defense.

While it’s not perfect and not enough alone, strong, and unique passwords should be used in combination with multifactor authentication for all email, banking software and other online financial services and anything else of value exposed to the internet.

🔲 IT.2 Disable External Email Forwarding & Regularly Review Active Forwarding Rules

Email forwarding can be useful, but it also poses a security risk due to the potential to unknowingly disclose information or perpetuate social engineering attacks against your companies’ clients or partners. It’s recommended that you do not allow forwarding emails to external domains and implement a process for regularly reviewing all active forwarding rules. If external email forwarding is required, it should be allowed on a case-by-case basis and be well documented.

Just as there are a number of ways for users to enable email forwarding there are a number of ways administrators can restrict or prevent external email forwarding rules. If you’re a Microsoft 365 customer, one way this can be done is by using transport rules, which can be found in the Microsoft 365 Admin Center and the Exchange Admin Center.

If you are a Microsoft customer, Defender for Office 365 has some really nice features such as disabling external email forwarding by default as well alerts that detect suspicious forwarding related activity to name a few.

🔲 IT.3 Enable Mailbox Audit Logging for All Accounts

Without logs, it’s very difficult to have a successful investigation of a potential business email compromise. During an investigation, you will need to know what actions a user performed and when. In Microsoft 365 this information is captured in what’s called mailbox audit logs. With mailbox audit logging enabled you will be able to see events for things like when a user creates a new inbox rule.

Check to verify that mailbox audit logging is enabled and if not, enable it. It’s available for all Microsoft 365 licensing levels and there is no impact to users.

🔲 IT.4 Disable Legacy Authentication Protocols

Protocols that use basic authentication typically do not support multifactor authentication. This includes POP3, IMAP, and SMTP. Single-factor authentication (e.g., username and password) should not be considered sufficient for protecting anything of value. In the Microsoft world, you can create Conditional Access policies to govern and/or block legacy authentication protocols.

If these protocols are required for a business purpose, they should only be granted as needed for specific users. This should be well documented and reviewed periodically to ensure such access is still required.

🔲 IT.5 Configure Centralized Logging & Create Alerts for Suspicious Activity

You want to make sure you’re collecting logs and sending them to a centralized location, preferable to a Security Information and Event Management (SIEM) tool where you can build alerts when suspicious activity is detected. What logs you may ask? Well since we’re talking about BEC you definitely want to be sending Microsoft 365 logs to your SIEM. You also want to include logs from other sources as well such as your Firewalls, workstations, and endpoint protection product.

Suspicious activity related to BEC you may want to alert on would be things like successful logins from out of the country, a new external email forwarding rule created, or authentication using legacy protocols.

Business Contols

🔲 BUS.1 Implement a Security Awareness Training Program

If we had to pick one thing to start doing immediately if you’re not already, it would be to implement a security awareness training program for all users, especially those who deal with finances and other sensitive information.

In order for users to not fall victim to BEC, they first must be aware of the threat. They must then learn what the red flags are through educational content and simulated phishing. Finally, they must be trained on what to do when they see something suspicious. Only with those three components can you begin to see behaviors change and only then will you be able to spot business email compromise early on.

🔲 BUS.2 Determine Wire Transfer Authority

Determining authority is all about defining who can do what, when and when it comes to wire transfers, how much. This should be simple and straightforward and should be documented and sent to everyone involved in payment processes, wire transfers, etc.

An authority list typically contains the names of people who can perform certain actions, such as a wire transfer. It will describe the amounts those people can request and/or approve, if they need additional approval and if there are any threshold amounts that invoke additional controls such as verification or approval by senior leadership.

This control ties directly into FIN.1 and FIN.2 because you should be reviewing this list regularly and you should have dual control, at least for transactions over a certain threshold.

🔲 BUS.3 Follow a Standardized Process, No Exceptions

Bad actors who are attempting to defraud your company are hoping that you will succumb to the pressure and urgency of their request and deviate from your process. It’s all too easy to fall victim to BEC when you do not have a well-defined process, that is followed vigilantly, without exception. That sounds great on paper, but in reality, sometimes exceptions are made, but they should not be made lightly or without documentation and additional oversight.

Your process should include how vendor setup is done including a vetting & approval process. All of which should have supporting documentation. This should all happen prior to paying any disbursements.

🔲 BUS.4 Report BEC to The Internet Crime Complaint Center

The IC3 Recovery Asset Team (RAT) was established in 2018 to streamline communication with financial institutions and assist FBI field offices with the freezing of funds for victims who made transfers to domestic accounts under fraudulent pretenses. Through the RAT, IC3 worked with its partners to successfully freeze approximately $380 million of the $462 million in reported losses in 2020, representing a success rate of nearly 82%.1

According to the 2021 Verizon Data Breach Investigations Report, when the IC3 RAT acts on BECs, and works with the destination bank, half of all US-based business email compromises had 99% of the money either recovered or frozen, whereas only 11% had nothing at all recovered.2

🔲 BUS.5 Check Your Business Insurance

Cyber liability insurance commonly covers costs related to data breaches, however, fraud is another question altogether. While cyber liability insurance can help cover costs related to data restoration, loss of income and possibly even extortion, you may need specific coverages or even a separate policy to cover cyber fraud. In the insurance world, you may hear this referred to as “computer fraud”, or “funds transfer fraud” or even “social engineering fraud.” Provisions in these policies cover different types of fraud and contain different types of exclusions.

Some questions to ask when reviewing your insurance policies are: Does my insurance cover financial loss due to cyber fraud or business email compromise attacks? How do I know? Do I understand what is covered and not covered by my insurance policies? Do I understand what my reporting requirements -are when something bad happens?

Check your insurance policies to ensure you have adequate coverage and make it a regular event on your calendar to review your policy every year to ensure those coverages continue to be adequate.

Financial Controls

🔲 FIN.1 Implement Dual Approval

One of the most important financial controls for preventing BEC is the concept of dual approval. Dual approval is a process by which one person initiates or requests a wire transfer and a separate person approves the transaction. It sounds simple, and it is, but there are some key components that we see are often missing.

There should always be documentation to support the transaction. The vendor should already be set up, see BUS.3. The person responsible for approving the transaction (see BUS.2) should review the initial request and the supplied documentation. Next, and this is the most important part, they should confirm the transaction with the requester. The recommended method to do this is through verbal communication. For example, the approver could call the requester using the phone number on record, not one provided by the requester, to approve the transaction.

🔲 FIN.2 Audit & Verify Permissions Regularly

As they say, trust but verify. Regularly reviewing access to banking and payment processing applications as well as application permissions is important in order to validate that only users with a business need have access and that their permissions are correctly defined for their role and responsibility.

It may seem trivial, but what we have found is that it’s easy for access control and permissions to go awry. Maybe you have users out on vacation or maybe paternity leave, and you need to have some people fill in temporarily. It’s easy to forget to remove users once they no longer need access. It’s also equally easy to not be as diligent as you should because of the “they may need to help again, so I will just leave it for now” mentality.

🔲 FIN.3 Review Bank Activity More Frequently

The sooner you identify fraud, the easier it is to recover from it. Your company may have thousands of transactions per day, maybe more. If that’s the case and you wait until the end of the month to review those transactions, you could be sifting through tens of thousands of transactions. Waiting this long means you may not be aware of fraudulent transactions until weeks after they occur. At that point, it could be more difficult to recover lost funds.

Review and understand your banking activity and transaction volume. Consider if you may be able to increase how often you review banking activity. Try weekly or maybe even daily.

Also, keep in mind that your banking institution could also fall victim to fraud and scams. Reviewing banking activity more regularly is a check and balance for your company just as much as it is for your bank.


Computer & Network Security

PrintNightmare: What We Know And What To Do Now

On July 1st Microsoft issued a new advisory regarding the Windows Print Spooler Remote Code Execution vulnerability and has assigned it a new CVE: CVE-2021-34527

On July 6th Microsoft issued an emergency, out of band security update, to address the Windows Print Spooler Remote Code Execution vulnerability, dubbed PrintNightmare.

What is PrintNightmare?

There exists a critical vulnerability in the Windows Print Spooler, CVE-2021-34572 (previously identified as CVE-2021-1675), that researchers and the security community have been calling “PrintNightmare.”

This vulnerability could allow an attacker to perform privilege escalation, or remote code execution, which could result in a full domain compromise.

The vulnerability itself was thought to have been patched by Microsoft on June 8th. They even considered it low severity. However, according to researchers it was not fully resolved in Microsoft’s patch release.

For details on the technical components of this vulnerability, see the resource section below.

Why is it making headlines?

As indicated by Kevin Beaumont @GossiTheDog, since releasing the June 8th patch, researcher Zhiniang Peng tweeted out proof of concept exploit code, which was hosted on GitHub, that indicated privileged escalation and remote code execution are possible. The tweet was deleted shortly after posting it. However, the repository was forked before it was deleted. There are now several other PoC variants floating around GitHub.

This prompted Microsoft to modify their advisory on June 21st, to include the correct impact: privilege escalation and remote code execution and increase the severity from low to critical. Microsoft has since released another advisory, on July 1st, related to the remote code execution vulnerability.

The PoC code is one reason for the headlines, the other reason is because of the scope of this vulnerability. The Windows Print Spooler is enabled by default on Windows 7, 10, and 11 as well as on Domain Controllers. Many servers also have the Print Spooler enabled.

What are the real-life implications?

As of right now, it’s believed the vulnerability is only possible post-authentication. Meaning, you must first have access to a valid account before you can exploit this.

As stated previously, there are two attack vectors:

  1. Privilege escalation – this is a ‘local’ privilege escalation which means that a threat actor, who has accessed a machine on your network using even a low privileged user account could easily elevate their privileges to Administrator or SYSTEM on that same machine. This would be a full compromise of the affected machine.
  2. Remote code execution – this means that a threat actor can exploit this vulnerability without having access to the targeted/vulnerable machine. This attack vector could be used to enable a threat actor to move, machine to machine, throughout the environment. This is commonly called lateral movement. This is often done by threat actors in order to find and gain access to high value targets such as Domain Controllers.

This is a very serious vulnerability, one that affects even patched versions of Windows 7, 10 and the insider build of Windows 11, Windows Server 2008, 2012, 2016 and 2019. By design it also affects Domain Controllers.

Exploitation of this vulnerability in an environment could result in full domain compromise.

Can this be patched?

At the time of posting this, the June 8th patch is believed to not fully remediate this vulnerability. Your efforts are better spent on mitigation and detection.

As of July 6th, Microsoft now has an emergency out-of-band security patch for the PrintNightmare Remote Code Execution vulnerability. Unfortunately, just how well KB5005010 protects against both the RCE and LPE vulnerabilities is questionable. Additionally, according to researchers, the additional hardening measure to restrict printer driver installations to administrators only and signed drivers only (RestrictDriverInstallationToAdministrators registry value), appears to not be working as Microsoft intended. The key component here seems to be Point & Print. Even after patching if Point & Print is enabled, non-administrators may still be able to use an unsigned DLL to achieve Local Privilege Escalation.


How do I mitigate it?

There are a couple options for mitigation depending on your level of comfort with disrupting printing across your organization. Bear in mind, this is a double edge sword situation. Even though this is a very serious vulnerability, for many businesses, disabling printing may not be the best option. Printing, for many, is a core business process. On same note, some temporary interruption to business process while waiting for Microsoft to issue a hotfix could be very well worth it.

Option 1 – ACL Restriction

The first option is to restrict the ACL (access control list) on a specific windows folder to prevent the SYSTEM account from modifying its contents. For more details on this approach, see this blog post by TrueSec. The PowerShell code below, reproduced from the TrueSec blog post, will do just that:

$Path = “C:\Windows\System32\spool\drivers”

$Acl = Get-Acl $Path

$Ar = New-Object  System.Security.AccessControl.FileSystemAccessRule(“System”, “Modify”, “ContainerInherit, ObjectInherit”, “None”, “Deny”)


Set-Acl $Path $Acl

Option 2 – Disable the Print Spooler Service

The other option is to stop and disable the Print Spooler service. To do this you can use the commands below:

Using The Command Line

net stop spooler && sc config spooler start=disabled

Using PowerShell

Stop-Service -Name Spooler -Force Set-Service -Name Spooler -StartupType Disabled

Alternatively, you can configure the Print Spooler with Group Policy found here:

Policies/Windows Settings/Security Settings/System Services/Print Spooler

Option 3 – Disable inbound remote printing through Group Policy

According to Microsoft, this policy will block the remote attack vector by preventing inbound remote printing operations. The system will no longer function as a print server, but local printing to a directly attached device will still be possible.

Configure Group Policy as follows:

Computer Configuration/Administrative Templates/Printers

Disable the “Allow Print Spooler to accept client connections” policy to block remote attacks.

You must restart the Print Spooler service for the group policy to take effect.

Additional hardening

Local privilege escalation is still possible under certain circumstances even with the Print Spooler service disabled thanks to Point and Print technology. The flow chart below, shared by @gentilkiwi, is a great illustration you can use to determine when the PrintNightmare vulnerability can be used.

To harden Point and Print make sure that warning and elevation prompts are shown for printer installs and updates. These are the default settings but verify or add the following registry modifications:

HKEY_LOCAL_MACHINE\SOFTWARE\Policies\Microsoft\Windows NT\Printers\PointAndPrint

NoWarningNoElevationOnInstall = 0

UpdatePromptSettings = 0

Microsoft also recommends explicitly listing specific print servers which should be used by clients.

In additional to the UAC prompt settings above it may also be a worthwhile endeavor to restrict Point & Print further to only allow users to connect to specific print servers you trust. This can be done with Group Policy located here:

Computer Configuration\Policies\Administrative Templates\Printers: Point and Print Restrictions

How do I detect it?

Unfortunately, Windows machines do not have visibility into exploitation of this vulnerability by default. In order to monitor event logs to find possible exploitation you must have appropriate logging enabled.

Ensure that Microsoft-Windows-PrintService/Operational logging is enabled throughout your environment.

Jake Williams @MalwareJake recently shared a quick and easy way to enable this logging with PowerShell.

Once enabled, you want to monitor for entries to that log that contain error messages indicating a plug-in module failed to load.

Note, threat actors can avoid errors in this event log if they are able to package a legitimate DLL that the Print Spooler would normally use. In that case, errors would not be logged.

If you want to quickly search for exploitation attempts, you can try this code shared by Florian Roth @cyb3rops:

Get-WinEvent -LogName ‘Microsoft-Windows-PrintService/Admin’ | Select-String -InputObject {$_.message} -Pattern ‘The print spooler failed to load a plug-in module’

Quick note about copying and pasting code from the internet. Be sure you understand what this code does and how it will affect your system. Use at your own risk.

Lastly, check with your security vendors and MSPs regarding detection. The security community has banned together to help create and publicly distribute viable detection’s using things such as Sigma rules. Security vendors should do the same.

Florian Roth @cyb3rops, together with @KevTheHermit and @fuzzyf10w, have created some Sigma rules to detect these exploits and shared them with the public. Make sure your vendors and MSPs are working to be able to detect potential exploitation of this vulnerability.

Now what?

The best way to stay up-to-date on the latest with PrintNightmare is by following the twitter thread #PrintNightmare. Also, follow your security vendors blogs/alerts/notifications to learn more about what they are doing to detect and/or mitigate this and other news breaking vulnerabilities.


Updated July 2nd, 2021 – Changed the CVE number and added information about Microsoft’s latest update

Updated July 6th, 2021 – Including option 3, disable inbound remote printing through Group Policy

Updated July 6th, 2021 – Added “Additional hardening” subsection

Updated July 7th, 2021 – Added link to out of band Microsoft patch to address the PrintNightmare RCE

Updated July 13th, 2021 – Updated Point and Print Registry setting in hardening section

Computer & Network Security

How To Check A Sketchy Link Without Clicking It

Let’s say you’re working through your dozens of emails, responding to clients or customers or business partners and you come across this one email from your bank informing you that you need to reset your password. This email comes completely out of the blue and to top it off you don’t recognize the senders email address. Do you click it?

Maybe…maybe not.

Did you know that you can investigate if that link is sketchy or not without clicking on it?

When it comes to hyperlinks, sometime’s it’s really obvious it’s sketchy, but other times, in the case of look-a-like domains, it can actually be a bit tricky.

Here are a few things that make a link sketchy, when visibly looking at it.

  • Links that end in uncommon top level domains (TLD). Because the cost to purchase domains within these TLDs are pretty inexpensive, they are very frequently used for spamming and malicious activity. Aside from which is a web site owned by Google’s parent Alphabet I don’t know of any legit domains with these TLDs.

    • Commonly used for spamming/nefarious activity:
      • .xyz
      • .buzz
      • .live
      • .fit
      • .tk
  • Links that are knock-offs (known as look-a-like domains) of major brands. These are popular because the domain closely resembles that of real brands domains. Depending on how the URL looks in your browser and if you’re on a mobile device or on your computer, you may or may not be able to spot these very easily.

    • Examples:
      • netflix-mail[.]com
      • t-mogbile[.]com
      • googlre[.]com

      Note, these domains may or may not be valid at the time of you reading this

  • Links that contain random numbers and/or letters. These are pretty obvious. Not all are malicious, however, anytime I see a url like this I immediatly get suspicious. It’s not a trustworthy link in my opinion and should be investigated further.

    • Examples:
      • eqbqcguiwcymao[.]info

There is definitely no shortage of URL and website scanners out there. I’ve tried dozens of them. None of them seem as good to me as URLscan. It’s fast, extremely detailed, provides a live screenshot and it allows you to link out to other scans to check them as well.

URLScan –

My go-to move with any sketchy links is to pop them into URLScan and see what comes up. To do that, just head on over to Then just simply copy and paste the link you want to scan into the scan field. Once there you can also click Options and make your scan Private, which sometimes is nice to do, since Public scans will show up on the front page and in searches.

Now that you have your link pasted in, click Scan! Once URLScan is finished checking your link, doing it’s analysis and fingerprinting, it will bring you to a results page that looks something like this.

Note, this is an example results page of a known malicious site.

1. Live Screenshot. This allows you to visibly see if there might be anything weird going on with the site. This is good for sniffing out things like misspelled words on login pages.

2. Google Safe Browsing rating. This is a nice quick view of if the website is safe or potentially nefarious.

3. Lookup the URL with other scanners. The lookup tab allows you to pick any of a number of other website scanners. This can help you glean additional information about the site you’re scanning in case you’re still not sure about it.

Caution when Clicking

It’s a bit cliche by now but, think before you click! It only takes a few minutes to pause, copy and paste the link into URLScan and check it out first before clicking.

If you’re at work and have an IT Department or Security Team, send it over to them and ask them to investigate it for you. It’s better to wait 10 minutes to get a link checked out than spend 10 weeks recovering from a security incident.

Additional Information

I did some googling on this topic and found some good articles related to suspcious and or malicious domains. The articles below go into much more detail on TLDs and their use for malicious or spammy activity. If you’re into the technical nitty gritty these would be great reads.