Category: Computer & Network Security

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

The Ultimate Guide to Backup Strategy: 7 Essential Best Practices for Ensuring Data Safety

Safeguarding valuable data is paramount for businesses and individuals. A robust backup strategy prevents data loss and ensures business continuity. This comprehensive guide will discuss the top 7 best practices for creating a reliable backup strategy to keep your data safe.

  1. Develop a Comprehensive Backup Plan

A well-crafted backup plan is the foundation of a secure backup strategy. Begin by identifying the critical systems and data that require protection. Then, consider the Recovery Time Objective (RTO) and Recovery Point Objective (RPO) to establish the desired frequency of backups and the acceptable amount of data loss.

  1. Utilize Diverse Backup Types, Including Air-Gapped and Immutable Backups

Optimize your backup strategy by combining full, incremental, differential, air-gapped, and immutable backups. Full, incremental, and differential backups balance storage space and recovery time, while air-gapped and immutable backups enhance security by protecting against unauthorized access and data alteration.

  1. Ensure Data Encryption and Secure Transmission

To protect sensitive data, implement encryption both at rest and during transmission. Encryption ensures that only authorized individuals can access the data. Use strong encryption algorithms, such as AES-256, and secure transmission protocols, like SFTP or HTTPS, to maintain the highest level of security.

  1. Store Backups in Multiple Locations

Storing backup data in multiple locations is vital for disaster recovery. Create at least three copies of your data, with one stored onsite for easy access and two stored offsite for added security. Consider using a combination of physical and cloud storage solutions for increased redundancy and accessibility.

  1. Regularly Test Your Backup and Recovery Process

To guarantee the effectiveness of your backup strategy, routinely test your backup and recovery process. This ensures that your data can be restored quickly and accurately during an emergency. Schedule regular tests and document the results, making any necessary adjustments to your strategy based on the findings.

  1. Monitor and Maintain Backup Systems

Continuous monitoring and maintenance of your backup systems are crucial for optimal performance. Implement monitoring tools to check the status of your backups, identify any issues, and generate reports. Regularly update software, firmware, and hardware components to prevent system vulnerabilities.

  1. Educate and Train Your Team

Lastly, investing in the education and training of your team is essential for maintaining a successful backup strategy. Provide regular training sessions and workshops on backup procedures, best practices, and disaster recovery. Encourage a culture of responsibility and vigilance to ensure that your entire organization is dedicated to protecting your data.

Conclusion

Following these seven essential best practices can create a robust and reliable backup strategy to safeguard your valuable data. Developing a comprehensive backup plan, utilizing multiple backup types, ensuring data encryption, storing backups in numerous locations, regularly testing your backup and recovery process, monitoring and maintaining backup systems, and educating your team are all critical components of a successful backup strategy. With these practices in place, you can rest assured that your data will remain secure and accessible in the face of any disaster.

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

Categories
Computer & Network Security

Ransomware Resilient Backups

Every day we see evidence of bad actors attacking various sized companies with ransomware. A commonly agreed upon defense mechanism that offers a good chance to recover your data without paying the ransom is a robust backup strategy. With federal entities considering the idea that victims paying the attackers ransom a crime, now is a great chance to get ahead of any possible criminal action to getting your firm back online. The strategy we outline here will help your organization build a resilient backup strategy for protection from ransomware or any other incident.

Attackers Are Going After Your Backups

We know without a doubt that attackers are going after primary datastores and servers to encrypt companies’ data, and as the business of ransomware evolves, these attack strategies continue to become more successful. According to Revil, targeting backups has become a key element in an attacker’s strategy, and they are focusing efforts on encrypting or neutralizing backups. If a company has tested backups that are resilient to attacks, there is a lower chance they will be forced to make ransomware payments.

Snapshots Are Not Backups

Snapshots are great, no way around it, for IT services and operations this may be one of the greatest tools since sliced bread. However, snapshots should not be considered a replacement of a solid backup strategy. Now, that is not to say that snapshots don’t have a place in a solid backup strategy. Snapshots are great if you need to restore from the past few hours; however, in some cases, we need to know our backups are safe and clean from previous days or even weeks. While snapshots can do this, it is not the most effect mechanism. Especially as we consider replication to multiple locations and offline, air-gapped backups.

It’s not just me saying this checkout what VMWare has to say on why snapshots are not backups.

3-2-1- Strategy

Backups are as simple as 3-2-1, right? This sounds very simplistic, and in reality, it is a simple plan; however, it can be hard to execute. The idea is simple. Create 3 copies of your backups, across 2 different media types, and at least one offsite backup. Let’s break this down to a real-world example to contextual this for practicality.

3 Backups might look like this at a high level. With backups to Disk, which could be a SAN, you have backups that are quickly accessible for most recovery needs. Backups to cloud gets the data offsite to another location. Backups to tape satisfies our two media types strategy. Of course, you can mix and match other medias, locations and methods but the idea to have a diverse strategy so you have options when you lose confidence or access to other backups.

Backup to Disk > Backup to Cloud > Backup to Tape

Test, Test, and Retest

Backups are only great when they work and are ready. Develop a strategy to regularly test your backups AND your process! Restoring a file, application, or server for a ticket or service issue, while technically is a test, for those of us with compliance requirements this generally does not satisfy our requirements. Testing regularly has a few advantages to help you when you need them.

1. You know your backups are available.

2. Your team knows how to restore from backups.

3. Your team knows where to find your backups.

4. You know how long it takes to recover.

If you have a large environment consider a sample testing method where you test your high risk systems every time, with a set of lower risk systems to go along.

Separately, you should test your disaster recovery plan either with a table top or actual execution of the plan including failover to recovery location or backups.

Feel free to contact us if you’d like to review and reinforce your backup strategy.

Sources:
https://blog.cyble.com/2021/07/03/uncensored-interview-with-revil-sodinokibi-ransomware-operators/
https://www.vmwareblog.org/snapshots-checkpoints-alone-arent-backups/
https://www.veeam.com/blog/321-backup-rule.html

Categories
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”)

$Acl.AddAccessRule($Ar)

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.

Resources

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

Categories
Computer & Network Security

7 Questions to Ask Before Deciding Whether to Pay a Ransomware Attacker

Intro

  • Ransomware is on the rise, owing to the pandemic. In 2020, ransomware exceeded $1.4 billion in the US alone, according to an estimate from Emsisoft.
  • Definition: When threat actors prevent a company from accessing their systems, network, or data until a demand is met.

7 Questions to Ask Before Deciding Whether To Pay a Ransomware Attacker

  • 1. & 2. Do You Have a Backup? Will it Work?
    • Today’s ransomware groups take backups into account. Even if you have backed up your critical files, it’s important to know the capabilities and functionality of your restoration services. If a threat actor has access to your backups, there is a good chance they will attempt to encrypt or even delete them. If you haven’t done so before and haven’t deeply investigated your capabilities, you won’t know how lengthy or difficult such a restore could be. You may also not understand whether there are backdoors in your restores or whether attackers have accessed any online backups.
  • 3. How Much Will the Ransom Really Cost You?
    • Many organizations wind up making the calculus that making the ransom payment is cheaper than losing data and/or business continuity. How badly does your company need the impacted system or the data stored on that system? if the machine is integral to business operation? There is also a cost to public perception and reputation. Paying ransoms may cast your organization in a negative light.
  • 4. Do I Call Law Enforcement?
    • Statistically speaking, law enforcement faces a low chance of catching ransomware groups. They also may not have the capacity to crack encryption or obtain decryption keys. However, that doesn’t mean there’s no utility to the act. One may reach out to law enforcement because it may be more likely the perpetrator will be caught, for the possibility that technical assistance from law enforcement may help, or because it helps show regulators and the public that you took all reasonable actions. It may also fulfil a requirement in cyber insurance coverage.
  • 5. Have You Considered the Risk of the Ransom Being Reneged?
    • Threat actors must maintain credibility in their claim that receiving the ransom payment will restore the victim’s systems. For the most part, that’s been the case, but further deception has occurred on more than a few occasions (Such as demanding another payment). Given that possibility, it’s in your interest to speak with ransomware experts about how your particular group has handled ransom payments.
  • 6. Have You Considered Law Enforcement Guidance?
    • Anyone who’s seen an action movie knows that the US doesn’t negotiate with terrorists. Perhaps surprisingly, the FBI doesn’t require or encourage not paying a ransom under any circumstances. What do they say?
      • “Whether to pay a ransom is a serious decision, requiring the evaluation of all options to protect shareholders, employees and customers. Victims will want to evaluate the technical feasibility, timeliness, and cost of restarting systems from backup.”
  • 7. Can You Forstall The Attack on Your Own
    • Ransomware attackers use many of the same methods as typical attackers. It’s possible that there’s guidance out there that could help you resolve the hack on your own. 
      • The “no more ransom” project, a collaboration between European law enforcement and cybersecurity companies Kaspersky Lab and McAfee, offers decryption tools for more than 85 ransomware varieties.

Conclusion

  • Deciding to pay a ransom or not is a difficult question to answer. Ultimately, it should be an informed and calculated decision based on due diligence and support from internal and external parties. However, if we want to do our part to try and curb ransomware attacks, we should design our systems and protect our organizations such that paying the ransom is left as a last resort.
Categories
Computer & Network Security

Best Practices for Privileged Account Management – Part 2

Privileged and Service Account Management

We spoke previously on the management of privileged accounts and how important it is to keep them accountable. Privileged accounts are one of many different types of accounts that should fall under your organizations Account Management Program and another one to add to that would be service accounts.

What is a service account anyway? In basic terms, a service account is an account that a service on your computer uses to run under and access resources. While they may look the same, the separation of users from services is very important for both tracking and the ability to tighten down what an account can do. A service account could also be an account that is used for a scheduled task (sometimes referred to as a batch job account), or an account that is used in a script that is run outside of a specific user’s context. A scheduled task account should not be a personal user’s account for the same reasons that a service should not run under a personal user’s account.

You may ask what is so important about these? It seems like if it is not a user account, then how would it have access to my organization’s network? On the contrary, these accounts are a favorite target of many malicious actors because they are often implemented in such a way that they have a higher level of access than a user account. These accounts are members of the domain in the same way a user account is. Historically, they also have not changed passwords as often (if ever) as user accounts.

Services are often installed under the built-in Local System account, which gives what are essentially local administrator privileges, so they are more predictable in how they will be able to be used if compromised. While local administrator privileges may seem somewhat harmless since they are not usually useable on other computers on your network, the local administrator privileges can end up granting access to domain username/password combinations. An attacker can use this as a jumping point  leading to account changes that allow for elevated access to other parts of your network. As a result, both locking down a service account and following good password change and audit procedures is an important part of keeping your systems secure.

What can you do?

When it comes to the configuration and management of service accounts, there a few things listed below that can help.

  • Password Management – Some administrators like to set these accounts up with passwords that do not expire or use the same password for all the service accounts. Instead, there needs to be a strategy for managing these passwords and changing them on a regular basis, as well as using unique passwords. Use an encrypted vault to protect, store and generate random passwords for service accounts.
  • Privilege Management – It is best practice to implement the principle of least privilege. Only provide the minimum necessary privileges to service accounts. If your service account must run with administrative privileges, deny that account access to all of the directories besides the one or two that it needs. Creating limited access to systems and denying interactive rights to only what is required reduces exposure.
  • Governance – First inventory all service accounts to know what you have and where. Next establish regular reviews of service accounts in the environment documenting ownership, required access and lifecycle of the account. Enforce these requirements with a workflow to gather these elements for new authorizations.
  • Auditing – Logging and auditing of service accounts, and all accounts in any case, is very important to keep systems secure. Using a SIEM looking for specific events can be helpful in discovering security problems and services that are not working correctly.

Locking down your service accounts should be a basic component of your hardening guide for all computers. While it requires more time to lock down a new service account to allow access only to what it needs, it is well worth the time spent. Defense-in-depth requires that you look at more than the perimeter, and service accounts are one major place where the in-depth strategy can serve you well.

 

Categories
Computer & Network Security

Best Practices for Privileged Account Management – Part 1

Basic Privileged Account Management

Abused and Misused privileges are often seen as being the cause of breaches within organizations around the world.  Privileged account management should be a major focus for Security and IT management who are looking to mitigate the risks of data breaches and insider risks.

What is Privileged Account Management?

Privilege Account Management is the definition and management of policies and processes that define the ways in which the user is provided access rights to enterprise systems.  It governs the management of the data that constitutes the user’s privileges and other attributes, including the storage, organization and access to information in directories (FICAM-09).  In other words, how an organization manages privileged passwords and delegates privileged actions.  Do you delegate, control, and filter privileged operations that an administrator can execute?  Do you audit, record, and monitor privileged access?

Why is it important to an organization?

When it comes to utilizing high business value IT systems, privileged users, such as administrators, typically have the widest operational latitude.  They are typically responsible for deploying and managing functionality on which the business depends, from vital day-to-day functions, to strategic capabilities that enable the business to maintain its competitive edge.

However, there are risks to wielding this power.  IT complexity means that minor changes could potentially have unintended, and severe impacts on availability, performance, and/or integrity.  Malicious attackers, inside and outside of the organization, can capitalize on administrative level access to inflict serious damage to the business.  Given the increasing sophistication and popularity of modern attacks via malware and other methods, it is common for attackers to gain and exploit such privileges by impersonating trustworthy personnel.

What are some common best practices?

There are countless solutions out there for organizations to implement and everyone has their opinion on what is the best way to do it.  Below are a set of common privileged account best practices all organizations should follow:

  • Separate regular access accounts from privileged accounts
  • Inventory all privileged accounts and assign ownership to that inventory
  • Do not use shared accounts
  • Minimize the number of personal privileged accounts
  • Limit scope for each privileged account
  • Use privilege elevation for users with regular access
  • Document policies and processes for the management of privileged accounts
  • Monitor and log all privileged access activity
  • Implement separation of duties model to manage superuser administrative privileges
  • Use default administrator, root, and similar accounts only when absolutely necessary
  • Require multi-factor authentication for all privileged accounts
  • Require complex and long passwords for privileged accounts
  • For service or application privileged accounts store passwords in an encrypted vault with a random password

Read Part 2 of this blog here >>.