General Remote Desktop connection troubleshooting

Use these steps when a Remote Desktop client can’t connect to a remote desktop but doesn’t provide messages or other symptoms that would help identify the cause.

Check the status of the RDP protocol

Check the status of the RDP protocol on a local computer

To check and change the status of the RDP protocol on a local computer, see How to enable Remote Desktop.

Note

If the remote desktop options are not available, see Check whether a Group Policy Object is blocking RDP.

Check the status of the RDP protocol on a remote computer

Important

Follow this section’s instructions carefully. Serious problems can occur if the registry is modified incorrectly. Before you start modifying the registry, back up the registry so you can restore it in case something goes wrong.

To check and change the status of the RDP protocol on a remote computer, use a network registry connection:

First, go to the Start menu, then select Run. In the text box that appears, enter regedt32.
In the Registry Editor, select File, then select Connect Network Registry.
In the Select Computer dialog box, enter the name of the remote computer, select Check Names, and then select OK.
Navigate to HKEY_LOCAL_MACHINE\SYSTEM\CurrentControlSet\Control\Terminal Server and to HKEY_LOCAL_MACHINE\SOFTWARE\Policies\Microsoft\Windows NT\Terminal Services.
- If the value of the fDenyTSConnections key is 0, then RDP is enabled.
- If the value of the fDenyTSConnections key is 1, then RDP is disabled.
To enable RDP, change the value of fDenyTSConnections from 1 to 0.

Check whether a Group Policy Object (GPO) is blocking RDP on a local computer

If you can’t turn on RDP in the user interface or the value of fDenyTSConnections reverts to 1 after you’ve changed it, a GPO may be overriding the computer-level settings.

To check the group policy configuration on a local computer, open a Command Prompt window as an administrator, and enter the following command:

Windows Command PromptCopy

gpresult /H c:\gpresult.html

After this command finishes, open gpresult.html. In Computer Configuration\Administrative Templates\Windows Components\Remote Desktop Services\Remote Desktop Session Host\Connections, find the Allow users to connect remotely by using Remote Desktop Services policy.

If the setting for this policy is Enabled, Group Policy is not blocking RDP connections.
If the setting for this policy is Disabled, check Winning GPO. This is the GPO that is blocking RDP connections.

Check whether a GPO is blocking RDP on a remote computer

To check the Group Policy configuration on a remote computer, the command is almost the same as for a local computer:

Windows Command PromptCopy

gpresult /S <computer name> /H c:\gpresult-<computer name>.html

The file that this command produces (gpresult-<computer name>.html) uses the same information format as the local computer version (gpresult.html) uses.

Modifying a blocking GPO

You can modify these settings in the Group Policy Object Editor (GPE) and Group Policy Management Console (GPM). For more information about how to use Group Policy, see Advanced Group Policy Management.

To modify the blocking policy, use one of the following methods:

In GPE, access the appropriate level of GPO (such as local or domain), and navigate to Computer Configuration > Administrative Templates > Windows Components > Remote Desktop Services > Remote Desktop Session Host > Connections > Allow users to connect remotely by using Remote Desktop Services.
1. Set the policy to either Enabled or Not configured.
2. On the affected computers, open a command prompt window as an administrator, and run the gpupdate /force command.
In GPM, navigate to the organizational unit (OU) in which the blocking policy is applied to the affected computers and delete the policy from the OU.

Check the status of the RDP services

On both the local (client) computer and the remote (target) computer, the following services should be running:

Remote Desktop Services (TermService)
Remote Desktop Services UserMode Port Redirector (UmRdpService)

You can use the Services MMC snap-in to manage the services locally or remotely. You can also use PowerShell to manage the services locally or remotely (if the remote computer is configured to accept remote PowerShell cmdlets).

Remote Desktop services in the Services MMC snap-in. Do not modify the default service settings.

On either computer, if one or both services are not running, start them.

Note

If you start the Remote Desktop Services service, click Yes to automatically restart the Remote Desktop Services UserMode Port Redirector service.

Check that the RDP listener is functioning

Important

Follow this section’s instructions carefully. Serious problems can occur if the registry is modified incorrectly. Before you starty modifying the registry, back up the registry so you can restore it in case something goes wrong.

Check the status of the RDP listener

For this procedure, use a PowerShell instance that has administrative permissions. For a local computer, you can also use a command prompt that has administrative permissions. However, this procedure uses PowerShell because the same cmdlets work both locally and remotely.

To connect to a remote computer, run the following cmdlet:PowerShellCopyEnter-PSSession -ComputerName <computer name>
Enter qwinsta.
If the list includes rdp-tcp with a status of Listen, the RDP listener is working. Proceed to Check the RDP listener port. Otherwise, continue at step 4.
Export the RDP listener configuration from a working computer.
1. Sign in to a computer that has the same operating system version as the affected computer has, and access that computer’s registry (for example, by using Registry Editor).
2. Navigate to the following registry entry:
  HKEY_LOCAL_MACHINE\SYSTEM\CurrentControlSet\Control\Terminal Server\WinStations\RDP-Tcp
3. Export the entry to a .reg file. For example, in Registry Editor, right-click the entry, select Export, and then enter a filename for the exported settings.
4. Copy the exported .reg file to the affected computer.
To import the RDP listener configuration, open a PowerShell window that has administrative permissions on the affected computer (or open the PowerShell window and connect to the affected computer remotely).
1. To back up the existing registry entry, enter the following cmdlet:PowerShellCopycmd /c 'reg export "HKLM\SYSTEM\CurrentControlSet\Control\Terminal Server\WinStations\RDP-tcp" C:\Rdp-tcp-backup.reg'
2. To remove the existing registry entry, enter the following cmdlets:PowerShellCopyRemove-Item -path 'HKLM:\SYSTEM\CurrentControlSet\Control\Terminal Server\WinStations\RDP-tcp' -Recurse -Force
3. To import the new registry entry and then restart the service, enter the following cmdlets:PowerShellCopycmd /c 'regedit /s c:\<filename>.reg' Restart-Service TermService -Force Replace <filename> with the name of the exported .reg file.
Test the configuration by trying the remote desktop connection again. If you still can’t connect, restart the affected computer.
If you still can’t connect, check the status of the RDP self-signed certificate.

Check the status of the RDP self-signed certificate

If you still can’t connect, open the Certificates MMC snap-in. When you are prompted to select the certificate store to manage, select Computer account, and then select the affected computer.
In the Certificates folder under Remote Desktop, delete the RDP self-signed certificate.
On the affected computer, restart the Remote Desktop Services service.
Refresh the Certificates snap-in.
If the RDP self-signed certificate has not been recreated, check the permissions of the MachineKeys folder.

Check the permissions of the MachineKeys folder

On the affected computer, open Explorer, and then navigate to C:\ProgramData\Microsoft\Crypto\RSA\.
Right-click MachineKeys, select Properties, select Security, and then select Advanced.
Make sure that the following permissions are configured:
- Builtin\Administrators: Full control
- Everyone: Read, Write

Check the RDP listener port

On both the local (client) computer and the remote (target) computer, the RDP listener should be listening on port 3389. No other applications should be using this port.

Important

To check or change the RDP port, use the Registry Editor:

Go to the Start menu, select Run, then enter regedt32 into the text box that appears.
- To connect to a remote computer, select File, and then select Connect Network Registry.
- In the Select Computer dialog box, enter the name of the remote computer, select Check Names, and then select OK.
Open the registry and navigate to HKEY_LOCAL_MACHINE\SYSTEM\CurrentControlSet\Control\Terminal Server\WinStations\<listener>.
If PortNumber has a value other than 3389, change it to 3389. ImportantYou can operate Remote Desktop services using another port. However, we don’t recommend you do this. This article doesn’t cover how to troubleshoot that type of configuration.
After you change the port number, restart the Remote Desktop Services service.

Check that another application isn’t trying to use the same port

Open a PowerShell window. To connect to a remote computer, enter Enter-PSSession -ComputerName <computer name>.
Enter the following command:PowerShellCopycmd /c 'netstat -ano | find "3389"'
Look for an entry for TCP port 3389 (or the assigned RDP port) with a status of Listening. NoteThe process identifier (PID) for the process or service using that port appears under the PID column.
To determine which application is using port 3389 (or the assigned RDP port), enter the following command:PowerShellCopycmd /c 'tasklist /svc | find "<pid listening on 3389>"'
Look for an entry for the PID number that is associated with the port (from the netstat output). The services or processes that are associated with that PID appear on the right column.
If an application or service other than Remote Desktop Services (TermServ.exe) is using the port, you can resolve the conflict by using one of the following methods:
- Configure the other application or service to use a different port (recommended).
- Uninstall the other application or service.
- Configure RDP to use a different port, and then restart the Remote Desktop Services service (not recommended).

Check whether a firewall is blocking the RDP port

Use the psping tool to test whether you can reach the affected computer by using port 3389.

Go to a different computer that isn’t affected and download psping from https://live.sysinternals.com/psping.exe.
Open a command prompt window as an administrator, change to the directory in which you installed psping, and then enter the following command:Copypsping -accepteula <computer IP>:3389
Check the output of the psping command for results such as the following:
- Connecting to <computer IP>: The remote computer is reachable.
- (0% loss): All attempts to connect succeeded.
- The remote computer refused the network connection: The remote computer is not reachable.
- (100% loss): All attempts to connect failed.
Run psping on multiple computers to test their ability to connect to the affected computer.
Note whether the affected computer blocks connections from all other computers, some other computers, or only one other computer.
Recommended next steps:
- Engage your network administrators to verify that the network allows RDP traffic to the affected computer.
- Investigate the configurations of any firewalls between the source computers and the affected computer (including Windows Firewall on the affected computer) to determine whether a firewall is blocking the RDP port.

3 Overlooked Cybersecurity Breaches

Here are three of the worst breaches, attacker tactics and techniques of 2022, and the security controls that can provide effective, enterprise security protection for them.

#1: 2 RaaS Attacks in 13 Months#

Ransomware as a service is a type of attack in which the ransomware software and infrastructure are leased out to the attackers. These ransomware services can be purchased on the dark web from other threat actors and ransomware gangs. Common purchasing plans include buying the entire tool, using the existing infrastructure while paying per infection, or letting other attackers perform the service while sharing revenue with them.

In this attack, the threat actor consists of one of the most prevalent ransomware groups, specializing in access via third parties, while the targeted company is a medium-sized retailer with dozens of sites in the United States.

The threat actors used ransomware as a service to breach the victim’s network. They were able to exploit third-party credentials to gain initial access, progress laterally, and ransom the company, all within mere minutes.

The swiftness of this attack was unusual. In most RaaS cases, attackers usually stay in the networks for weeks and months before demanding ransom. What is particularly interesting about this attack is that the company was ransomed in minutes, with no need for discovery or weeks of lateral movement.

A log investigation revealed that the attackers targeted servers that did not exist in this system. As it turns out, the victim was initially breached and ransomed 13 months before this second ransomware attack. Subsequently, the first attacker group monetized the first attack not only through the ransom they obtained, but also by selling the company’s network information to the second ransomware group.

In the 13 months between the two attacks, the victim changed its network and removed servers, but the new attackers were not aware of these architectural modifications. The scripts they developed were designed for the previous network map. This also explains how they were able to attack so quickly – they had plenty of information about the network. The main lesson here is that ransomware attacks can be repeated by different groups, especially if the victim pays well.

“RaaS attacks such as this one are a good example of how full visibility allows for early alerting. A global, converged, cloud-native SASE platform that supports all edges, like Cato Networks provides complete network visibility into network events that are invisible to other providers or may go under the radar as benign events. And, being able to fully contextualize the events allows for early detection and remediation.

#2: The Critical Infrastructure Attack on Radiation Alert Networks#

Attacks on critical infrastructure are becoming more common and more dangerous. Breaches of water supply plants, sewage systems and other such infrastructures could put millions of residents at risk of a human crisis. These infrastructures are also becoming more vulnerable, and attack surface management tools for OSINT like Shodan and Censys allow security teams to find such vulnerabilities with ease.

In 2021, two hackers were suspected of targeting radiation alert networks. Their attack relied on two insiders that worked for a third party. These insiders disabled the radiation alert systems, significantly debilitating their ability to monitor radiation attacks. The attackers were then able to delete critical software and disable radiation gauges (which is part of the infrastructure itself).

“Unfortunately, scanning for vulnerable systems in critical infrastructure is easier than ever. While many such organizations have multiple layers of security, they are still using point solutions to try and defend their infrastructure rather than one system that can look holistically at the full attack lifecycle. Breaches are never just a phishing problem, or a credentials problem, or a vulnerable system problem – they are always a combination of multiple compromises performed by the threat actor,” said Etay Maor, Sr. Director of Security Strategy at Cato Networks.

#3: The Three-Step Ransomware Attack That Started with Phishing#

The third attack is also a ransomware attack. This time, it consisted of three steps:

1. Infiltration – The attacker was able to gain access to the network through a phishing attack. The victim clicked on a link that generated a connection to an external site, which resulted in the download of the payload.

2. Network activity – In the second phase, the attacker progressed laterally in the network for two weeks. During this time, it collected admin passwords and used in-memory fileless malware. Then on New Year’s Eve, it performed the encryption. This date was chosen since it was (rightfully) assumed the security team would be off on vacation.

3. Exfiltration – Finally, the attackers uploaded the data out of the network.

In addition to these three main steps, additional sub-techniques were employed during the attack and the victim’s point security solutions were not able to block this attack.

“A multiple choke point approach, one that looks horizontally (so to speak) at the attack rather than as a set of vertical, disjointed issues, is the way to enhance detection, mitigation and prevention of such threats. Opposed to popular belief, the attacker needs to be right many times and the defenders only need to be right just once. The underlying technologies to implement a multiple choke point approach are full network visibility via a cloud-native backbone, and a single pass security stack that’s based on ZTNA.” said Etay Maor, Sr. Director of Security Strategy at Cato Networks.

How Do Security Point Solutions Stack Up?#

It is common for security professionals to succumb to the “single point of failure fallacy”. However, cyber-attacks are sophisticated events that rarely involve just one tactic or technique which is the cause of the breach. Therefore, an all-encompassing outlook is required to successfully mitigate cyber-attacks. Security point solutions are a solution for single points of failure. These tools can identify risks, but they will not connect the dots, which could and has led to a breach.

Here’s Watch Out for in the Coming Months#

According to ongoing security research conducted by Cato Networks Security Team, they have identified two additional vulnerabilities and exploit attempts that they recommend including in your upcoming security plans:

1. Log4j#

While Log4j made its debut as early as December of 2021, the noise its making hasn’t died down. Log4j is still being used by attackers to exploit systems, as not all organizations have been able to patch their Log4j vulnerabilities or detect Log4j attacks, in what is known as “virtual patching”. They recommend prioritizing Log4j mitigation.

2. Misconfigured Firewalls and VPNs#

Security solutions like firewalls and VPNs have become access points for attackers. Patching them has become increasingly difficult, especially in the era of architecture cloudification and remote work. It is recommended to pay close attention to these components as they are increasingly vulnerable.

How to Minimize Your Attack Surface and Gain Visibility into the Network#

To reduce the attack surface, security professionals need visibility into their networks. Visibility relies on three pillars:

Actionable information – that can be used to mitigate attacks
Reliable information – that minimizes the number of false positives
Timely information – to ensure mitigation happens before the attack has an impact

Once an organization has complete visibility to the activity on their network they can contextualize the data, decide whether the activity witnessed should be allowed, denied, monitored, restricted (or any other action) and then have the ability to enforce this decision. All these elements must be applied to every entity, be it a user, device, cloud app etc. All the time everywhere. That is what SASE is all about.

Found this article interesting? Follow us on Twitter  and LinkedIn to read more exclusive content we post.

Source :
https://thehackernews.com/2023/02/3-overlooked-cybersecurity-breaches.html

VMware Security Solutions Advisories VMSA-2021-0002

Advisory ID: VMSA-2021-0002
CVSSv3 Range: 5.3-9.8
Issue Date: 2021-02-23
Updated On: 2021-02-23 (Initial Advisory)
CVE(s): CVE-2021-21972, CVE-2021-21973, CVE-2021-21974
Synopsis: VMware ESXi and vCenter Server updates address multiple security vulnerabilities (CVE-2021-21972, CVE-2021-21973, CVE-2021-21974)

1. Impacted Products

VMware ESXi
VMware vCenter Server (vCenter Server)
VMware Cloud Foundation (Cloud Foundation)

2. Introduction

Multiple vulnerabilities in VMware ESXi and vSphere Client (HTML5) were privately reported to VMware. Updates are available to remediate these vulnerabilities in affected VMware products.

3a. VMware vCenter Server updates address remote code execution vulnerability in the vSphere Client (CVE-2021-21972)

Description

The vSphere Client (HTML5) contains a remote code execution vulnerability in a vCenter Server plugin. VMware has evaluated the severity of this issue to be in the Critical severity range with a maximum CVSSv3 base score of 9.8.

Known Attack Vectors

A malicious actor with network access to port 443 may exploit this issue to execute commands with unrestricted privileges on the underlying operating system that hosts vCenter Server.

Resolution

To remediate CVE-2021-21972 apply the updates listed in the ‘Fixed Version’ column of the ‘Response Matrix’ below to affected deployments.

Workarounds

Workarounds for CVE-2021-21972 have been listed in the ‘Workarounds’ column of the ‘Response Matrix’ below.

Additional Documentation

None.

Notes

The affected vCenter Server plugin for vROPs is available in all default installations. vROPs does not need be present to have this endpoint available. Follow the workarounds KB to disable it.

Acknowledgements

VMware would like to thank Mikhail Klyuchnikov of Positive Technologies for reporting this issue to us.

Response Matrix:

Product	Version	Running On	CVE Identifier	CVSSv3	Severity	Fixed Version	Workarounds	Additional Documentation
vCenter Server	7.0	Any	CVE-2021-21972	9.8	Critical	7.0 U1c	KB82374	None
vCenter Server	6.7	Any	CVE-2021-21972	9.8	Critical	6.7 U3l	KB82374	None
vCenter Server	6.5	Any	CVE-2021-21972	9.8	Critical	6.5 U3n	KB82374	None

Impacted Product Suites that Deploy Response Matrix 3a Components:

Product	Version	Running On	CVE Identifier	CVSSv3	Severity	Fixed Version	Workarounds	Additional Documentation
Cloud Foundation (vCenter Server)	4.x	Any	CVE-2021-21972	9.8	Critical	4.2	KB82374	None
Cloud Foundation (vCenter Server)	3.x	Any	CVE-2021-21972	9.8	Critical	3.10.1.2	KB82374	None

3b. ESXi OpenSLP heap-overflow vulnerability (CVE-2021-21974)

Description

OpenSLP as used in ESXi has a heap-overflow vulnerability. VMware has evaluated the severity of this issue to be in the Important severity range with a maximum CVSSv3 base score of 8.8.

Known Attack Vectors

A malicious actor residing within the same network segment as ESXi who has access to port 427 may be able to trigger the heap-overflow issue in OpenSLP service resulting in remote code execution.

Resolution

To remediate CVE-2021-21974 apply the updates listed in the ‘Fixed Version’ column of the ‘Response Matrix’ below to affected deployments.

Workarounds

Workarounds for CVE-2021-21974 have been listed in the ‘Workarounds’ column of the ‘Response Matrix’ below.

Additional Documentation

None.

Notes

[1] Per the Security Configuration Guides for VMware vSphere, VMware now recommends disabling the OpenSLP service in ESXi if it is not used. For more information, see our blog posting: https://blogs.vmware.com/vsphere/2021/02/evolving-the-vmware-vsphere-security-configuration-guides.html

[2] KB82705 documents steps to consume ESXi hot patch asynchronously on top of latest VMware Cloud Foundation (VCF) supported ESXi build.

Acknowledgements

VMware would like to thank Lucas Leong (@_wmliang_) of Trend Micro’s Zero Day Initiative for reporting this issue to us.

Response Matrix:

Product	Version	Running On	CVE Identifier	CVSSv3	Severity	Fixed Version	Workarounds	Additional Documentation
[1] ESXi	7.0	Any	CVE-2021-21974	8.8	Important	ESXi70U1c-17325551	KB76372	None
[1] ESXi	6.7	Any	CVE-2021-21974	8.8	Important	ESXi670-202102401-SG	KB76372	None
[1] ESXi	6.5	Any	CVE-2021-21974	8.8	Important	ESXi650-202102101-SG	KB76372	None

Impacted Product Suites that Deploy Response Matrix 3b Components:

Product	Version	Running On	CVE Identifier	CVSSv3	Severity	Fixed Version	Workarounds	Additional Documentation
[1] Cloud Foundation (ESXi)	4.x	Any	CVE-2021-21974	8.8	Important	4.2	KB76372	None
[1] Cloud Foundation (ESXi)	3.x	Any	CVE-2021-21974	8.8	Important	[2] KB82705	KB76372	None

3c. VMware vCenter Server updates address SSRF vulnerability in the vSphere Client (CVE-2021-21973)

Description

The vSphere Client (HTML5) contains an SSRF (Server Side Request Forgery) vulnerability due to improper validation of URLs in a vCenter Server plugin. VMware has evaluated the severity of this issue to be in the Moderate severity range with a maximum CVSSv3 base score of 5.3.

Known Attack Vectors

A malicious actor with network access to port 443 may exploit this issue by sending a POST request to vCenter Server plugin leading to information disclosure.

Resolution

To remediate CVE-2021-21973 apply the updates listed in the ‘Fixed Version’ column of the ‘Response Matrix’ below to affected deployments.

Workarounds

Workarounds for CVE-2021-21973 have been listed in the ‘Workarounds’ column of the ‘Response Matrix’ below.

Additional Documentation

None.

Notes

The affected vCenter Server plugin for vROPs is available in all default installations. vROPs does not need be present to have this endpoint available. Follow the workarounds KB to disable it.

Acknowledgements

VMware would like to thank Mikhail Klyuchnikov of Positive Technologies for reporting this issue to us.

Response Matrix:

Product	Version	Running On	CVE Identifier	CVSSv3	Severity	Fixed Version	Workarounds	Additional Documentation
vCenter Server	7.0	Any	CVE-2021-21973	5.3	Moderate	7.0 U1c	KB82374	None
vCenter Server	6.7	Any	CVE-2021-21973	5.3	Moderate	6.7 U3l	KB82374	None
vCenter Server	6.5	Any	CVE-2021-21973	5.3	Moderate	6.5 U3n	KB82374	None

Impacted Product Suites that Deploy Response Matrix 3c Components:

Product	Version	Running On	CVE Identifier	CVSSv3	Severity	Fixed Version	Workarounds	Additional Documentation
Cloud Foundation (vCenter Server)	4.x	Any	CVE-2021-21973	5.3	Moderate	4.2	KB82374	None
Cloud Foundation (vCenter Server)	3.x	Any	CVE-2021-21973	5.3	Moderate	3.10.1.2	KB82374	None

4. References

VMware ESXi 7.0 ESXi70U1c-17325551
https://my.vmware.com/group/vmware/patch
https://docs.vmware.com/en/VMware-vSphere/7.0/rn/vsphere-esxi-70u1c.html

VMware ESXi 6.7 ESXi670-202102401-SG
https://my.vmware.com/group/vmware/patch
https://docs.vmware.com/en/VMware-vSphere/6.7/rn/esxi670-202102001.html

VMware ESXi 6.5 ESXi650-202102101-SG
https://my.vmware.com/group/vmware/patch
https://docs.vmware.com/en/VMware-vSphere/6.5/rn/esxi650-202102001.html

VMware vCloud Foundation 4.2
Downloads and Documentation:
https://docs.vmware.com/en/VMware-Cloud-Foundation/4.2/rn/VMware-Cloud-Foundation-42-Release-Notes.html

VMware vCloud Foundation 3.10.1.2
Downloads and Documentation:
https://docs.vmware.com/en/VMware-Cloud-Foundation/3.10.1/rn/VMware-Cloud-Foundation-3101-Release-Notes.html

vCenter Server 7.0.1 Update 1
Downloads and Documentation:
https://my.vmware.com/web/vmware/downloads/details?downloadGroup=VC70U1C&productId=974
https://docs.vmware.com/en/VMware-vSphere/7.0/rn/vsphere-vcenter-server-70u1c-release-notes.html

vCenter Server 6.7 U3l
Downloads and Documentation:
https://my.vmware.com/web/vmware/downloads/details?downloadGroup=VC67U3L&productId=742&rPId=57171
https://docs.vmware.com/en/VMware-vSphere/6.7/rn/vsphere-vcenter-server-67u3l-release-notes.html

vCenter Server 6.5 U3n
Downloads and Documentation:
https://my.vmware.com/web/vmware/downloads/details?downloadGroup=VC65U3N&productId=614&rPId=60942
https://docs.vmware.com/en/VMware-vSphere/6.5/rn/vsphere-vcenter-server-65u3n-release-notes.html

Mitre CVE Dictionary Links:
https://cve.mitre.org/cgi-bin/cvename.cgi?name=CVE-2021-21972
https://cve.mitre.org/cgi-bin/cvename.cgi?name=CVE-2021-21973
https://cve.mitre.org/cgi-bin/cvename.cgi?name=CVE-2021-21974

FIRST CVSSv3 Calculator:
CVE-2021-21972: https://www.first.org/cvss/calculator/3.1#CVSS:3.1/AV:N/AC:L/PR:N/UI:N/S:U/C:H/I:H/A:H
CVE-2021-21973: https://www.first.org/cvss/calculator/3.1#CVSS:3.1/AV:N/AC:L/PR:N/UI:N/S:U/C:L/I:N/A:N
CVE-2021-21974: https://www.first.org/cvss/calculator/3.1#CVSS:3.1/AV:A/AC:L/PR:N/UI:N/S:U/C:H/I:H/A:H

5. Change Log

2021-02-23 VMSA-2021-0002
Initial security advisory.

6. Contact

E-mail list for product security notifications and announcements:

https://lists.vmware.com/cgi-bin/mailman/listinfo/security-announce

This Security Advisory is posted to the following lists:

security-announce@lists.vmware.com

bugtraq@securityfocus.com

fulldisclosure@seclists.org

E-mail: security@vmware.com

PGP key at:

https://kb.vmware.com/kb/1055

VMware Security Advisories

https://www.vmware.com/security/advisories

VMware Security Response Policy

https://www.vmware.com/support/policies/security_response.html

VMware Lifecycle Support Phases

https://www.vmware.com/support/policies/lifecycle.html

VMware Security & Compliance Blog

https://blogs.vmware.com/security

Twitter

Tweets by VMwareSRC

Source :
https://www.vmware.com/security/advisories/VMSA-2021-0002.html

The Definitive Browser Security Checklist

Security stakeholders have come to realize that the prominent role the browser has in the modern corporate environment requires a re-evaluation of how it is managed and protected. While not long-ago web-borne risks were still addressed by a patchwork of endpoint, network, and cloud solutions, it is now clear that the partial protection these solutions provided is no longer sufficient. Therefore, more and more security teams are now turning to the emerging category of purpose-built Browser Security Platform as the answer to the browser’s security challenges.

However, as this security solution category is still relatively new, there is not yet an established set of browser security best practices, nor common evaluation criteria. LayerX, the User-First Browser Security Platform, is addressing security teams’ need with the downable Browser Security Checklist, that guides its readers through the essentials of choosing the best solution and provides them with an actionable checklist to use during the evaluation process.

The Browser is The Most Important Work Interface and the Most Targeted Attack Surface #

The browser has become the core workspace in the modern enterprise. On top of being the gateway to sanctioned SaaS apps and other non-corporate web destinations, the browser is the intersection point between cloud\web environments and physical or virtual endpoints. This makes the browser both a target for multiple types of attacks, as well as a potential source of unintentional data leakage.

Some of these attacks have been around for more than a decade, exploitation of browser vulnerabilities or drive-by download of malicious files, for example. Others have gained recent momentum alongside the steep rise in SaaS adoption, like social engineering users with phishing webpages. Yet others leverage the evolution in web page technology to launch sophisticated and hard-to-detect modifications and abuse of browser features to capture and exfiltrate sensitive data.

Browser Security 101 – What is It That We Need to Protect?#

Browser security can be divided into two different groups: preventing unintended data exposure and protection against various types of malicious activity.

From the data protection aspect, such a platform enforces policies that ensure sensitive corporate data is not shared or downloaded in an insecure manner from sanctioned apps, nor uploaded from managed devices to non-corporate web destinations.

From the threat protection aspect, such a platform detects and prevents three types of attacks:

Attacks that target the browser itself, with the purpose of compromising the host device or the data that resides within the browser application itself, such as cookies, passwords, and others.
Attacks that utilize the browser via compromised credentials to access corporate data that resides in both sanctioned and unsanctioned SaaS applications.
Attacks that leverage the modern web page as an attack vector to target user’s passwords, via a wide range of phishing methods or through malicious modification of browser features.

How to Choose the Right Solution#

What should you focus on when choosing the browser security solution for your environment? What are the practical implications of the differences between the various offerings? How should deployment methods, the solution’s architecture, or user privacy be weighed in the overall consideration? How should threats and risks be prioritized?

As we’ve said before – unlike with other security solutions, you can’t just ping one of your peers and ask what he or she is doing. Browser security is new, and the wisdom of the crowd is yet to be formed. In fact, there’s an excellent chance that your peers are now struggling with the very same questions you are.

The Definitive Browser Security Platform Checklist – What it is and How to Use It#

The checklist (download it here) breaks down the high-level ‘browser security’ headline to small and digestible chunks of the concrete needs that need to be solved. These are brought to the reader in five pillars – deployment, user experience, security functionalities and user privacy. For each pillar there is a short description of its browser context and a more detailed explanation of its capabilities.

The most significant pillar, in terms of scope, is of course, the security functionalities one, which is divided into five sub-sections. Since, in most cases, this pillar would be the initial driver to pursuing browser security platform in the first place it’s worth going over them in more detail:

Browser Security Deep Dive#

The need for browser security platform typically arises from one of the following:

— Attack Surface Management: Proactive reduction of the browser’s exposure to various types of threats, eliminating adversaries’ ability to carry them out.

— Zero Trust Access: Hardening the authentication requirements to ensure that the username and password were indeed provided by the legitimate user and were not compromised.

— SaaS Monitoring and Protection: 360° visibility into all users’ activity and data usage within sanctioned and unsanctioned apps, as well as other non-corporate web destinations, while safeguarding corporate data from compromise or loss.

— Protection Against Malicious Web Pages: Real-time detection and prevention of all the malicious tactics adversaries embed in the modern web page, including credential phishing, downloading of malicious files and data theft.

— Secure 3rd Party Access and BYOD: Enablement of secure access to corporate web resources from unmanaged devices of both the internal workforce as well as external contractors and service providers.

This list enables anyone to easily identify the objective for their browser security platform search and find out the required capabilities for fulfilling it.

The Checklist – A Straightforward Evaluation Shortcut #

The most important and actionable part in the guide is the concluding checklist, which provides, for the first time, a concise summary of all the essential capabilities a browser security platform should provide. This checklist makes the evaluation process easier than ever. All you have to do now is test the solutions you’ve shortlisted against it and see which one scores the highest. Once you have all of them lined up, you can make an informed decision based on the needs of your environment, as you understand them.

Download the checklist here.

Found this article interesting? Follow us on Twitter  and LinkedIn to read more exclusive content we post.

Source :
https://thehackernews.com/2023/01/the-definitive-browser-security.html

Is Once-Yearly Pen Testing Enough for Your Organization?

Any organization that handles sensitive data must be diligent in its security efforts, which include regular pen testing. Even a small data breach can result in significant damage to an organization’s reputation and bottom line.

There are two main reasons why regular pen testing is necessary for secure web application development:

Security: Web applications are constantly evolving, and new vulnerabilities are being discovered all the time. Pen testing helps identify vulnerabilities that could be exploited by hackers and allows you to fix them before they can do any damage.
Compliance: Depending on your industry and the type of data you handle, you may be required to comply with certain security standards (e.g., PCI DSS, NIST, HIPAA). Regular pen testing can help you verify that your web applications meet these standards and avoid penalties for non-compliance.

How Often Should You Pentest?#

Many organizations, big and small, have once a year pen testing cycle. But what’s the best frequency for pen testing? Is once a year enough, or do you need to be more frequent?

The answer depends on several factors, including the type of development cycle you have, the criticality of your web applications, and the industry you’re in.

You may need more frequent pen testing if:

You Have an Agile or Continuous Release Cycle#

Agile development cycles are characterized by short release cycles and rapid iterations. This can make it difficult to keep track of changes made to the codebase and makes it more likely that security vulnerabilities will be introduced.

If you’re only testing once a year, there’s a good chance that vulnerabilities will go undetected for long periods of time. This could leave your organization open to attack.

To mitigate this risk, pen testing cycles should align with the organization’s development cycle. For static web applications, testing every 4-6 months should be sufficient. But for web applications that are updated frequently, you may need to test more often, such as monthly or even weekly.

Your Web Applications Are Business-Critical#

Any system that is essential to your organization’s operations should be given extra attention when it comes to security. This is because a breach of these systems could have a devastating impact on your business. If your organization relies heavily on its web applications to do business, any downtime could result in significant financial losses.

For example, imagine that your organization’s e-commerce site went down for an hour due to a DDoS attack. Not only would you lose out on potential sales, but you would also have to deal with the cost of the attack and the negative publicity.

To avoid this scenario, it’s important to ensure that your web applications are always available and secure.

Non-critical web applications can usually get away with being tested once a year, but business-critical web applications should be tested more frequently to ensure they are not at risk of a major outage or data loss.

Your Web Applications Are Customer-Facing#

If all your web applications are internal, you may be able to get away with pen testing less frequently. However, if your web applications are accessible to the public, you must be extra diligent in your security efforts.

Web applications accessible to external traffic are more likely to be targeted by attackers. This is because there is a greater pool of attack vectors and more potential entry points for an attacker to exploit.

Customer-facing web applications also tend to have more users, which means that any security vulnerabilities will be exploited more quickly. For example, a cross-site scripting (XSS) vulnerability in an external web application with millions of users could be exploited within hours of being discovered.

To protect against these threats, it’s important to pen test customer-facing web applications more frequently than internal ones. Depending on the size and complexity of the application, you may need to pen test every month or even every week.

You Are in a High-Risk Industry#

Certain industries are more likely to be targeted by hackers due to the sensitive nature of their data. Healthcare organizations, for example, are often targeted because of the protected health information (PHI) they hold.

If your organization is in a high-risk industry, you should consider conducting pen testing more frequently to ensure that your systems are secure and meet regulatory compliance. This will help protect your data and reduce the chances of a costly security incident.

You Don’t Have Internal Security Operations or a Pen testing Team#

This might sound counterintuitive, but if you don’t have an internal security team, you may need to conduct pen testing more frequently.

Organizations that don’t have dedicated security staff are more likely to be vulnerable to attacks.

Without an internal security team, you will need to rely on external pen testers to assess your organization’s security posture.

Depending on the size and complexity of your organization, you may need to pen test every month or even every week.

You Are Focused on Mergers or Acquisitions#

During a merger or acquisition, there is often a lot of confusion and chaos. This can make it difficult to keep track of all the systems and data that need to be secured. As a result, it’s important to conduct pen testing more frequently during these times to ensure that all systems are secure.

M&A also means that you are adding new web applications to your organization’s infrastructure. These new applications may have unknown security vulnerabilities that could put your entire organization at risk.

In 2016, Marriott acquired Starwood without being aware that hackers had exploited a flaw in Starwood’s reservation system two years earlier. Over 500 million customer records were compromised. This placed Marriott in hot water with the British watchdog ICO, resulting in 18.4 million pounds in fines in the UK. According to Bloomberg, there is more trouble ahead, as the hotel giant could “face up to $1 billion in regulatory fines and litigation costs.”

To protect against these threats, it’s important to conduct pen testing before and after an acquisition. This will help you identify potential security issues so they can be fixed before the transition is complete.

The Importance of Continuous Pen Testing#

While periodic pen testing is important, it is no longer enough in today’s world. As businesses rely more on their web applications, continuous pen testing becomes increasingly important.

There are two main types of pen testing: time-boxed and continuous.

Traditional pen testing is done on a set schedule, such as once a year. This type of pen testing is no longer enough in today’s world, as businesses rely more on their web applications.

Continuous pen testing is the process of continuously scanning your systems for vulnerabilities. This allows you to identify and fix vulnerabilities before they can be exploited by attackers. Continuous pen testing allows you to find and fix security issues as they happen instead of waiting for a periodic assessment.

Continuous pen testing is especially important for organizations that have an agile development cycle. Since new code is deployed frequently, there is a greater chance for security vulnerabilities to be introduced.

Pen testing as a service models is where continuous pen testing shine. Outpost24’s PTaaS (Penetration-Testing-as-a-Service) platform enables businesses to conduct continuous pen testing with ease. The Outpost24 platform is always up-to-date with an organization’s latest security threats and vulnerabilities, so you can be confident that your web applications are secure.

Manual and automated pen testing: Outpost24’s PTaaS platform combines manual and automated pen testing to give you the best of both worlds. This means you can find and fix vulnerabilities faster while still getting the benefits of expert analysis.
Provides comprehensive coverage: Outpost24’s platform covers all OWASP Top 10 vulnerabilities and more. This means that you can be confident that your web applications are secure against the latest threats.
Is cost-effective: With Outpost24, you only pay for the services you need. This makes it more affordable to conduct continuous pen testing, even for small businesses.

The Bottom Line#

Regular pen testing is essential for secure web application development. Depending on your organization’s size, industry, and development cycle, you may need to revise your pen testing schedule.

Once-a-year pen testing cycle may be enough for some organizations, but for most, it is not. For business-critical, customer-facing, or high-traffic web applications, you should consider continuous pen testing.

Outpost24’s PTaaS platform makes it easy and cost-effective to conduct continuous pen testing. Contact us today to learn more about our platform and how we can help you secure your web applications.

Found this article interesting? Follow us on Twitter  and LinkedIn to read more exclusive content we post.

Source :
https://thehackernews.com/2023/01/is-once-yearly-pen-testing-enough-for.html

Windows Update Commands – USOClient, Powershell, WUAUCLT

The windows Update CLI commands are useful for troubleshooting Windows Update errors. And they are helpful when you need to automate the windows update tasks. In newer versions of windows, the WUAUCLT command has been deprecated and replaced with the usoclient. In this article we have included the options and syntax for using wuault, usoclient, and powershell to detect and install windows updates

WUAUCLT

The windows update command utility in windows is: WUAUCLT. This stands for Windows Update Automatic Update Client. This client has been deprecated in windows 10 and server 2016. Howeve,r it is still available through windows 7 and server 2012R2.

Below is a list of arguments you can pass to the WUAUCLT commands and a short explanation of what each argument does.
Search:

Command	Description
/DetectNow	Detect and download updates that are available (will vary by system settings)
/ReportNow	Tell the client to report its status back to the WSUS server
/RunHandlerComServer
/RunStoreAsComServer
/ShowSettingsDialog	Show Windows Update settings dialog
/ShowWindowsUpdate	Shows the windows update dialog box or web page (depending on windows version)
/ResetAuthorization	when an update check occurs a cookie is stored that prevents a new update or check for 1 hour. So, you should use this to delete this cookie
/ResetEulas	Resets the accepted EULA’s
/ShowWU	Shows the windows update dialog on windows vista and above. Opens Windows update on XP
/SelfUpdateManaged	Scan for windows updates using WSUS
/SelfUpdateUnmanaged	Triggers a windows update scan using the windows update website
/ShowOptions	Open the windows update settings window
/ShowFeaturedOptInDialog	Show Opt-In dialog for featured updates
/DemoUI	Show the icons for windows update
/ShowFeaturedUpdates	Open windows update dialog and shows the featured updates
/ShowWUAutoScan
/UpdateNow	Install updates now

Showing 1 to 17 of 17 entries

Examples

See below for some examples of running the wuauclt. All examples should be run from an elevated/administrative command prompt

If all you want to do is detect and install updates right now, you would run:

Wuauclt /dectectnow /updatenow

If it is refusing to install, you can run:

Wuauclt /resetauthorization

If you want to have the client report its status back to the WSUS server, you would run:

Wuauclt /reportnow

Powershell

Powershell will give you the most flexibility in installing windows updates. The other methods are fine for simply downloading and installing all updates. However, with the powershell cmdlets you can do things like get a list of updates, search for updates with a specific word in them, then only install those updates.

The first step is to download the powershell module here:
https://gallery.technet.microsoft.com/scriptcenter/2d191bcd-3308-4edd-9de2-88dff796b0bc

If you have Powershell verison 5, you can install the module from the gallery by running:

Install-module PSWindowsUpdate

Before you can run any commands, you need to import the windows update module:

Import-Module PSWindowsUpdate

You might need to install the Microsoft Update service. That can be done with this command:

Add-WUServiceManager -ServiceID 7971f918-a847-4430-9279-4a52d1efe18d

You can get a list of available cmdlets in the PSWindowsUpdate module with the following command:

Get-command -module PSWindowsUpdate

I have also included a list of commands below:

Add-WUOfflineSync
Add-WUServiceManager
Get-WUHistory
Get-WUInstall
Get-WUInstallerStatus
Get-WUList
Hide-WUUpdate
Invoke-WUInstall
Get-WURebootStatus
Get-WUServiceManager
Get-WUUninstall
Remove-WUOfflineSync
Remove-WUServiceManager
Update-WUModule

Examples

The most important cmdlet is Get-WUInstall . This will be apparent in the examples below

Download and install updates from Microsoft Update, then reboot:

Get-WUInstall –MicrosoftUpdate –AcceptAll –AutoReboot

**Note, I usually only reboot if required. For that reason, I don’t like to use the AutoReboot flag.

Check if a reboot is required

Get-wurebootstatus

List available updates on Microsoft Update

Get-WUInstall –MicrosoftUpdate –ListOnly

USOClient

The USO client is new to windows 10 and Server 2016. This replaces the wuauclt command in these Operating systems. I would recommend using powershell instead of this client when you are doing automation, since it will work on newer and older clients. However, this client is very simple to use. and is useful for one-off purposes. See the table below for all of the command arguments:
Show 102550100 entriesSearch:

startscan	scan for updates
startdownload	download updates
startinstall	install updates
Refreshsettings	Refresh settings if any changes were made
StartInteractiveScan	Open a dialog and start scanning for updates
RestartDevice	Restart computer to finish installing updates
ScanInstallWait	Scan, Download, and install updates
ResumeUpdate	Resume installing updates on next boot

Showing 1 to 7 of 7 entries

Previous Next

Examples

See below for some examples of how to use the USO client. All of these examples should be run in an administrative command prompt

Scan for updates

usoclient startscan

Download updates

Usoclient startdownload

Install updates

usoclient startinstall

Here are other related links

In case you would like to see some additional information, I hae included some links to good resources on these topics:

WSUS Server Cmdlets http://technet.microsoft.com/en-us/library/hh826166.aspx

http://blogs.technet.com/b/heyscriptingguy/archive/2012/01/16/introduction-to-wsus-and-powershell.aspx

Powershell Execution Policy:http://technet.microsoft.com/en-us/library/ee176961.aspx

Troubleshoot computers not in WSUS:
http://msmvps.com/blogs/athif/archive/2005/09/04/65174.aspx

Client Side Powershell Module:
http://gallery.technet.microsoft.com/scriptcenter/2d191bcd-3308-4edd-9de2-88dff796b0bc

Powershell FAQ
http://gallery.technet.microsoft.com/scriptcenter/2d191bcd-3308-4edd-9de2-88dff796b0bc/view/Discussions#content

Source :
https://www.idkrtm.com/windows-update-commands/

Guide: How to Install Active Directory in Windows Server 2019 Using PowerShell

In a previous article, I showed you how to install Active Directory (AD), the first domain controller (DC) in a new forest and domain, using Server Manager in Windows Server 2019. But if you’re not afraid of the command line, there’s a much quicker way to get Active Directory up and running in Windows Server. In this article, I’ll show you how to configure AD using PowerShell.

There are two steps to installing AD in Windows Server 2019. The first is to install the Active Directory Domain Services (AD DS) server role. The second step is to configure your server as a domain controller. An AD domain must have at least one DC. Your server will be the first DC in a new AD forest and domain.

To complete the instructions below, you will need to have an account with administrator privileges in Windows Server 2019. I will also assume that you are using Windows Server 2019 with the Desktop Experience role installed. If you are using Server Core, the instructions vary a little but are more or less the same.

Active Directory prerequisites

Before you install your first domain controller in the new AD domain, there are a couple of things you should do to prepare the server. While it’s not absolutely necessary, I recommend giving the computer a name that makes it easy to identify. For example, I usually call the first domain controller in a new domain DC1. Secondly, you’ll need to set a static IP address and configure the network adapter’s DNS server.

Let’s start by renaming the server.

Log in to Windows Server 2019 as an administrator.
Open the Start menu and click the Windows PowerShell
In the PowerShell window, run the command below and press ENTER. Replace ‘DC1’ with the name that you would like to use for your domain controller.

Rename-Computer -NewName DC1

Restart the server.

Once the server has rebooted, we can configure the network adapter. Your DC will need to communicate with other devices on the local network, so it’s important to speak to whoever oversees your network and get them to provide you with a static IP address that isn’t already in use. On my network, I will assign a static IP address of 192.168.1.10/24 and the default gateway is 192.168.1.1.

Log in to Windows Server 2019 as an administrator.
Open the Start menu and click the Windows PowerShell
In the PowerShell window, run the New-NetIPAddress command below and press ENTER. Replace the values for IPAddress, DefaultGateway, and PrefixLength to those provided by your network administrator.

New-NetIPAddress –IPAddress 192.168.1.10 -DefaultGateway 192.168.1.1 -PrefixLength 24 -InterfaceIndex (Get-NetAdapter).InterfaceIndex

The above command is designed to work on servers that have only one network adapter installed. If you have more than one adapter, you’ll need to enter the interface number instead of (Get-NetAdapter).InterfaceIndex. You can get the interface index number (ifIndex) for each adapter using Get-NetAdapter.

Now configure the adapter’s DNS settings. We’ll set the preferred DNS server to be our domain controller’s IP address because the domain controller will also perform the function of DNS server for the domain. So, replace 192.168.1.10 with the same IP address you configured for the adapter. Run Set-DNSClientServerAddress as shown, and press ENTER.

Set-DNSClientServerAddress –InterfaceIndex (Get-NetAdapter).InterfaceIndex –ServerAddresses 192.168.1.10

Again, the command is designed to work on servers that have only one network adapter installed. If you have more than one adapter, you’ll need to enter the interface number instead of (Get-NetAdapter).InterfaceIndex.

How to Install Active Directory in Windows Server 2019 Using PowerShell (Image Credit: Russell Smith)

Install the Active Directory Domain Services role

The next step is to install the AD DS server role. It’s easy to do using the Install-WindowsFeature cmdlet as shown below. If you are using Server Core, remove the -IncludeManagementTools parameter.

Install-WindowsFeature -name AD-Domain-Services -IncludeManagementTools

Once the AD DS server role is installed, you’ll get a message in the PowerShell window. The Success column should read True.

Configure the first domain controller in a new Active Directory forest

Before you continue, you should decide on a Fully Qualified Domain Name (FQDN) for your new domain. I’m going to use ad.contoso.com in this example. Where ‘ad’ is the name of my new domain and contoso.com is the top-level domain (TLD). You should make sure that you own the public TLD. In this example, I should own the contoso.com domain name. AD in the FQDN defines my internal DNS namespace for Active Directory.

To configure Windows Server 2019 as a domain controller, run Install-ADDSForest as shown in the example below. Replace ad.contoso.com with your chosen FQDN. DomainNetBIOSName is usually set to the part of your FQDN that identifies your internal AD DNS namespace. So, the part that comes to the left of the first period. In this case, ‘ad’.

Install-ADDSForest -DomainName ad.contoso.com -DomainNetBIOSName AD -InstallDNS

You should note that Install-ADDSForest is only used when you are installing the first domain controller in a new AD forest. Install-ADDSDomain and Install-ADDSDomainController are used respectively to create a new domain in an existing forest and install a new DC in an existing AD domain.

DomainName and DomainNetBIOSName are the only two compulsory parameters for the Install-ADDSForest cmdlet. If you want to explore what other options you can configure, run the command line below:

Get-Help Install-ADDSForest

When you run the Install-ADDSForest cmdlet, you’ll be prompted to enter a password for Directory Services Restore Mode (DSRM). Or Safe Mode password as it’s sometimes referred to. Enter a password and confirm it when prompted.

You’ll then see a message:

The target server will be configured as a domain controller and restarted when this operation is complete.
Do you want to continue with this operation?

Type y in the PowerShell window and press ENTER to confirm that you want to configure the server as a domain controller.

As AD is configured, you’ll see some yellow warnings appear in the PowerShell window. They are normal and you can safely ignore them. The server will automatically reboot. Once Windows Server has rebooted, you will need to log in with the domain administrator account. The domain administrator account is assigned the same password as the built-in administrator account.

On the sign-in page, type administrator in the User name field. Type the password for the administrator account, which is the same as the password for the previous built-in administrator account, and press ENTER.

And that is it! You are now logged in to your AD domain’s first domain controller. You can access Server Manager from the Start menu. In Server Manager, click the Tools menu and then select Active Directory Users and Computers to start managing your domain.

Source :
https://petri.com/how-to-install-active-directory-in-windows-server-2019-using-powershell/

Active Directory: harden the security of your environment

In this tutorial dedicated to Active Directory and security, I will give you some tips to harden the level of security in order to be less vulnerable to attacks.

The different configuration points, which will be discussed, simply allow attacks to be made more difficult and longer internally, in no way will they guarantee that you are invulnerable.

What you need to know is that your first ally is time, the more “difficult” and longer it will be, the more likely you are that the attacker(s) will move on.

Before applying the settings, they should be tested in a restricted environment so as not to create more problems, especially on Active Directory environments that are several years old.

Disable SMBv1 support

One of the first points is to disable support for the SMBv1 protocol on all computers (servers and client workstations).

Since Windows 10 and Windows Server 2019, SMBv1 support is disabled by default.

To find out if the SMBv1 protocol is enabled, use the following command:

Get-SmbServerConfiguration | Select EnableSMB1Protocol

Before disabling SMBv1, it is possible to check if it is still used on a server.

To do this, use the command below:

Get-SmbSession | Select-Object -Property ClientComputerName, ClientUserName, Dialect

This command returns the device IP address, username, and SMB version used to access the shares.

If you have “old” equipment (copiers, scanners …), it is possible that they do not support a higher version of SMB.

It is also possible to enable SMBv1 access auditing:

Set-SmbServerConfiguration -AuditSmb1Access $true

Once activated, you must search for events with ID 3000 in the log: Microsoft-Windows-SMBServer\Audit.

To disable the SMBv1 protocol, there are several solutions.

Disable the SMBv1 protocol, this solution is effective immediately and does not require a restart (Windows 8.1 / Server 2012R2 or newer):

Set-SmbServerConfiguration -EnableSMB1Protocol $false

To disable the SMBv1 protocol on later versions of Windows (7, Vista, Server 2008 and Server 2008R2), modify the registry:

Set-ItemProperty -Path "HKLM:\SYSTEM\CurrentControlSet\Services\LanmanServer\Parameters" SMB1 -Type DWORD -Value 0 -Force

To take an account a restart is necessary.

For Windows 8.1 / Server 2012R2, it is also possible to uninstall the SMBv1 protocol support, here a restart is necessary:

Disable-WindowsOptionalFeature -Online -FeatureName SMB1Protocol

I also wrote a tutorial on disabling SMBv1 protocol (Server/Client) by group policy: https://rdr-it.com/en/gpo-disabled-smbv1/

Enable signing on the SMB protocol

In order to “protect” against Man-in-the-middle (MITM) attacks, it is possible to activate the signature on SMB protocol exchanges.

SMB signing works with SMBv2 and SMBv3.

The configuration of the signature can be done:

at the client level
at the server level

From the moment one of the two negotiates the signature, the SMB flow will be signed.

The configuration is done at the level of group policies: Computer configuration / Windows settings / Security settings / Security options. The two parameters to activate:

Microsoft network client: digitally sign communications (always)
Microsoft network server: digitally sign communications (always)

Again, I advise you to test on a few computers before applying this to your entire fleet, for my part, I had problems with RDS servers in terms of access to shares.

For more information I invite you to read this page : https://docs.microsoft.com/fr-fr/windows/security/threat-protection/security-policy-settings/microsoft-network-client-digitally-sign-communications-always.

Disable LM and NTLMv1 authentication

Still in the “old” protocols, it is necessary to disable the LM and NTLMv1 protocols which have password hashes that are very easy to brute force.

Once again, deactivation can be done by group policy at: Computer Configuration / Windows Settings / Security Settings / Security Options

You need to configure the parameter: Network Security: LAN Manager Authentication Level.

To do this, check Define this policy parameter and select: Send NTLM version 2 responses only\Refuse LM and NTLM

This setting is in an ideal world, if NTLMv1 should still be used, use this setting to disable LM: Only send NTLMv2 responses\Refuse LM

If you must use this parameter, NTLMv1 HASHes can still circulate on the network and are vulnerable to brute force attacks faster than NTLMv2.

It is possible to audit NTLM traffic by enabling settings to identify where NTMLv1 is being used

Network Security: Restrict NTLM: Audit Incoming NTLM Traffic
Network Security: Restrict NTLM: NTLM authentication in this domain

The NTLM configuration allows quite a bit of flexibility in terms of configuring it and adding exceptions.

Disable LLMNR and NBT-NS

LLMNR (Link-Local Multicast Name Resolution) and NBT-NS (Netbios Name Service) are two broadcast/multicast name resolution “protocols” that are enabled by default, they are used when dns name resolution fails.

If you use Wireshark type software to listen to the network, you will see that there is a lot of LLMNR and NBT-NS traffic.

The main danger of LLMNR and NBT-NS is that it is easy to send a false response with another computer in order to retrieve an NTLM hash of the requesting client.

Below are screenshots of the responder which allows you to respond to LLMNR and NBT-NS requests

Now we will see how to deactivate LLMNR and NBT-NS

Disable LLMNR

Good news, LLMNR is disabled by group policy in configuring the DNS client of computers.

To disable LLMNR, you must enable the Disable multicast name resolution setting located at: Computer Configuration / Administrative Templates / Network / DNS Client.

After applying the GPO on the computers in the domain, they will no longer use LLMNR.

If you have non-domain computers, it will be necessary to do this on them.

Disable NBT-NS

Here it gets a little complicated because NBT-NS is configured at the NIC level and there is no applicable group policy. The good news is that for client computers (mainly workstations), it is possible to do this by an option on the DHCP server.

At the options level (extended or server), option 001 Microsoft Options for disabling NetBios must be configured in the Microsoft Windows 2000 Option vendor class. The value 0x2 must be entered to disable NBT-NS.

For computers that are not in automatic addressing, Netbios must be disabled on the network card(s).

Open network card properties.

Select Internet Protocol Version 4 (TCP/IPv4) and click Properties.

From the General tab, click on Advanced.

Go to the WINS tab, and select Disable NetBIOS over TCP/IP.

Close the different ones by validating the configuration.

It is possible to disable Netbios by GPO using a PowerShell script run at startup.

Here is the script:

ps-disable-netbios.ps1 248 Bytes

1234

# Get network cards
$regkey = "HKLM:SYSTEM\CurrentControlSet\services\NetBT\Parameters\Interfaces"
# Disable Netbios on each
Get-ChildItem $regkey |foreach { Set-ItemProperty -Path "$regkey\$($_.pschildname)" -Name NetbiosOptions -Value 2 -Verbose}

Some additional tracks

Here are some additional tips:

Deploy LAPS on computers and servers in order to have different local administrator passwords.
Sign your DNS zone (DNSSEC)
Regularly audit privileged accounts.

It is also important to follow some simple “hygiene” rules:

Limit privileged account usage (domain admins)
Do not use domain admin accounts on workstations
Update servers and computers regularly
Update applications (Web server, database, etc.)
Make sure you have up-to-date antivirus
Learn about security bulletins

Regarding the last point that I will address, it is passwords, for domain administrator accounts, privileged long passwords (20 to 30 characters) which will take much longer to be “brute-forced” than an 8-character password even with complexity.

Don’t forget to audit your Active Directory for free with Ping Castle.CategoriesActive DirectoryTagsActive Directory, Security

Source :
https://rdr-it.com/en/active-directory-harden-the-security-of-your-environment/

What wireless cards and USB broadband modems are supported on Sonicwall firewalls and access points?

Description

The latest version of SonicOS firmware provides support for a wide variety of USB and Hotspot devices and wireless service providers as listed below.

Resolution

Broadband Devices

USA & Canada
Gen7		5G/4G/LTE			SonicOS 7.0
CARD REGION	OPERATOR	NAME	GENERATION	TYPE	SONICOS VERSION	SONICWAVE
USA	AT&T	Nighthawk 5G Mobile Hotspot Pro MR 5100	5G	Hotspot	7.0.1	No
USA	AT&T	NightHawk LTE MR1100	4G/LTE	Hotspot	7.0.0	No
USA	AT&T	Global Modem USB800	4G/LTE	USB	7.0.1	Yes
USA	AT&T	iPhone 11 Pro	4G/LTE	Hotspot	7.0.0	No
USA	AT&T	iPhone 12 Pro	4G/LTE	Hotspot	7.0.1	No
USA	Verizon	M2100	5G	Hotspot	7.0.1	Yes
USA	Verizon	M1000	5G	Hotspot	7.0.0	Yes
USA	Verizon	Orbic Speed	4G/LTE	Hotspot	7.0.0	No
USA	Verizon	MiFi Global U620L	4G/LTE	USB	7.0.0	Yes
USA	Sprint	Netstick	4G/LTE	USB	7.0.0	No
USA	Sprint	Franklin U772	4G/LTE	USB	7.0.0	No
USA	T-Mobile	M2000	4G/LTE	Hotspot	7.0.1	No
USA	T-Mobile	Link Zone2	4G/LTE	Hotspot	7.0.0	Yes
Gen6/Gen6.5		4G/LTE			SonicOS 6.x
CARD REGION	OPERATOR	NAME	GENERATION	TYPE	SONICOS VERSION	SONICWAVE
USA	AT&T	Global Modem USB800	4G/LTE	USB	6.5.4.5	Yes
USA	AT&T	Velocity (ZTE MF861)	4G/LTE	USB	6.5.3.1	Yes
USA	AT&T	Beam (Netgear AC340U)²	4G/LTE	USB	5.9.0.1	Yes
USA	AT&T	Momentum (Sierra Wireless 313U)	4G/LTE	USB	5.9.0.0	Yes
USA	Verizon	MiFi Global U620L	4G/LTE	USB	6.5.0.0	Yes
USA	Verizon	Novatel 551L	4G/LTE	USB	6.2.4.2	Yes
USA	Verizon	Pantech UML290	4G/LTE	USB	5.9.0.0	No
USA	Sprint	Franklin U772	4G/LTE	USB	6.5.3.1	No
USA	Sprint	Netgear 341U	4G/LTE	USB	6.2.2.0	Yes
Canada	Rogers	AirCard (Sierra Wireless 330U)	4G/LTE	USB	5.9.0.0	No
Gen5		3G			SonicOS 5.x
USA	AT&T	Velocity (Option GI0461)	3G	USB	5.8.1.1	No
USA	AT&T	Mercury (Sierra Wireless C885)	3G	USB	5.3.0.1	No
USA	Verizon	Pantech UMW190	3G	USB	5.9.0.0	No
USA	Verizon	Novatel USB760	3G	USB	5.3.0.1	No
USA	Verizon	Novatel 727	3G	USB	5.3.0.1	No
USA	Sprint	Novatel U760	3G	USB	5.3.0.1	No
USA	Sprint	Novatel 727U	3G	USB	5.3.0.1	No
USA	Sprint	Sierra Wireless 598U	3G	USB	5.8.1.1	No
USA	T-Mobile	Rocket 3.0 (ZTE MF683)	3G	USB	5.9.0.0	Yes
Canada	Bell	Novatel 760	3G	USB	5.3.1.0	No
International
Gen7		5G/4G/LTE			SonicOS 7.0
CARD REGION	Manufacturer	NAME	GENERATION	TYPE	SONICOS VERSION	SONICWAVE
Worldwide	Huawei	E6878-870	5G	Hotspot	7.0.0	No
Worldwide	Huawei	E8372H**	4G/LTE	USB	7.0.0	No
Worldwide	Huawei	E8201	4G/LTE	USB	7.0.0	No
Worldwide	Huawei	E3372	4G/LTE	USB	7.0.0	No
Worldwide	ZTE	MF833U	4G/LTE	USB	7.0.0	Yes
Worldwide	ZTE	MF825C	4G/LTE	USB	7.0.0	Yes
Worldwide	ZTE	MF79S	4G/LTE	USB	7.0.0	Yes
Gen6/Gen6.5		4G/LTE			SonicOS 6.x
CARD REGION	Manufacturer	NAME	GENERATION	TYPE	SONICOS VERSION	SONICWAVE
Worldwide	Huawei	E8372 (Telstra 4GX)	4G/LTE	USB	6.5.3.1	Yes
Worldwide	Huawei	E3372	4G/LTE	USB	6.5.3.1	Yes
Worldwide	Huawei	E3372h (-608 variant) 6	4G/LTE	USB	6.5.3.1	Yes
Worldwide	Huawei	E3372s (-608 variant) 6	4G/LTE	USB	6.5.3.1	Yes
Worldwide	Huawei	E398 (Kyocera 5005)	4G/LTE	USB	5.9.0.2	Yes
Worldwide	Huawei	E3276s	4G/LTE	USB	No	Yes
Worldwide	D-Link	DWM-221	4G/LTE	USB	6.5.3.1	Yes
Worldwide	D-Link	DWM-222 A1	4G/LTE	USB	6.5.3.1	Yes
Worldwide	ZTE	MF825	4G/LTE	USB	6.5.3.1	Yes
Worldwide	ZTE	MF832G	4G/LTE	USB	No	Yes
Worldwide	ZTE	MF79S	4G/LTE	USB	No	Yes
Gen5		3G			SonicOS 5.x
Worldwide	Huawei	E353 7	3G	USB	5.9.0.2	Yes
Worldwide	Huawei	K4605	3G	USB	5.9.0.2	Yes
Worldwide	Huawei	EC169C	3G	USB	5.9.0.7	No
Worldwide	Huawei	E180	3G	USB	5.9.0.1	No
Worldwide	Huawei	E182	3G	USB	5.9.0.0	No
Worldwide	Huawei	K3715	3G	USB	5.9.0.0	No
Worldwide	Huawei	E1750	3G	USB	5.8.0.2	No
Worldwide	Huawei	E176G	3G	USB	5.3.0.1	No
Worldwide	Huawei	E220	3G	USB	5.3.0.1	No
Worldwide	Huawei	EC122	3G	USB	5.9.0.0	No
		LTE Cellular Extender			SonicOS 6.x
Worldwide	Accelerated	6300-CX LTE router	4G/LTE	SIM	6.5.0.0	No

¹ Cellular network operators around the world are announcing their plans to discontinue 3G services starting as early as December 2020. Therefore LTE or 5G WWAN devices should be used for new deployments. Existing deployments with 3G should be upgraded soon to LTE or 5G in preparation for the imminent discontinuation of 3G services.
² Refer to AT&T 340U article for more info
³ Multiple variations of the Huawei card: E8371h-153, E8372h-155, & E8372h-510
⁴ Huawei Modem 3372h and 3372s have been released by Huawei in multiple variants (i.e. -608, -153, -607, -517, -511) and with different protocols. At the moment, SonicOS does not support Huawei Proprietary protocol so all the variants using a non-standard or proprietary protocol are not supported or require the ISP to provide a PPP APN Type.
⁵ Huawei Modem E353 is not compatible with SOHO 250. Also note that it is not an LTE card
⁶For customers outside of the 90-day warranty support period, an active SonicWall 8×5 or 24×7 Dynamic Support agreement allows you to keep your network security up-to-date by providing access to the latest firmware updates. You can manage all services including Dynamic Support and firmware downloads on any of your registered appliances at mysonicwall.com.

Ubiquiti UniFi – Backups and Migration

Migration is the act of moving your UniFi devices from one host device to another. This is useful when:

You are replacing your UniFi OS Console with a new one of the same model.
You are upgrading your UniFi OS Console to a different model (e.g., a UDM to a UDM Pro).
You are offloading devices to a dedicated UniFi OS Console (e.g., moving cameras from a Cloud Key or UDM to a UNVR).
You are moving from a self-hosted Network application to a UniFi OS Console.

Note: This is not meant to be used as a staging file for setting up multiple applications on different hosts.

Types of Backups

UniFi OS Backups

UniFi OS backup files contain your entire system configuration, including your UniFi OS Console, user, application, and device settings. Assuming Remote Access is enabled, UniFi OS Cloud backups are created weekly by default. You can also generate additional Cloud backups or download localized backups at any time.

UniFi OS backups are useful when:

Restoring a prior system configuration after making network changes.
Migrating all applications to a new UniFi OS Console that is the same model as the original.

Note: Backups do not include data stored on an HDD, such as recorded Protect camera footage.

Application Backups

Each UniFi application allows you to back up and export its configuration. Application backups contain settings and device configurations specific to the respective application.

Application backups are useful when:

You want to restore a prior application configuration without affecting your other applications.
You want to migrate a self-hosted Network application to a UniFi OS Console.
You want to migrate your devices between two different UniFi OS Console models.
You need to back up a self-hosted Network application.

Note: Backups do not include data stored on an HDD, such as recorded Protect camera footage.

UniFi OS Console Migration

UniFi OS backups also allow you to restore your system configuration should you ever need to replace your console with one of the same model.

To do so:

First, ensure that you have already generated a Cloud backup, or downloaded a local backup. If not, please do so in your UniFi OS Settings.
Replace your old UniFi OS Console with the new one. All other network connections should remain unchanged.
Restore your system configuration on the new UniFi OS Console using the backup file. This can be done either during the initial setup or afterwards in your UniFi OS settings.

Note: Currently, UniFi OS backups cannot be used to perform cross-console migrations, but this capability will be added in a future update.

If you are migrating between two different console models, you will need to restore each application’s configuration with their respective backups. Please note, though, that these file(s) will not include UniFi OS users or settings.

See below for more information on using the configuration backups during migrations.

Migrating UniFi Network

Before migrating, we recommend reviewing your Device Authentication Credentials found in your Network application’s System Settings. These can be used to recover adopted device(s) if the migration is unsuccessful.

Standard Migration

This is used when all devices are on the same Layer 2 network (i.e., all devices are on the same network/VLAN as the management application’s host device).

Note: If you are a home user managing devices in a single location and have not used the set-inform command or other advanced Layer 3 adoption methods, this is most likely the method for you.

Download the desired backup file (*.unf) from your original Network application’s System Settings.
Ensure that your new Network application is up to date. Backups cannot be used to restore older application versions.
Replace your old UniFi OS Console with the new one. All other network connections should remain unchanged.
Restore the backup file in the Network application’s System Settings.
Ensure that all devices appear as online in the new application. If they do not, you can try Layer 3 adoption, or factory-reset and readopt your device(s) to the new Network application.

If a device continues to appear as Managed by Other, click on it to open its properties panel, then use its Device Authentication Credentials (from the original Network application’s host device) to perform an Advanced Adoption.

Migrating Applications That Manage Layer 3 Devices

This method is for users that have performed Layer 3 device adoption (i.e., devices are on a different network/VLAN than the application’s host device). This may also be useful when migrating to a Network application host that is NOT also a gateway.

Download the desired backup file (*.unf) from your original Network application’s System Settings.
Enable the Override Inform Host field on the original Network application’s host device, then enter the IP address of the new host device. This will tell your devices where they should establish a connection in order to be managed. Once entered, all devices in the old application should appear as Managed by Other.

Note: When migrating to a Cloud Console, you can copy the Inform URL from the Cloud Console’s dashboard. Be aware that you will need to remove the initial http:// and the ending :8080/inform.
Ensure that your new Network application is up to date. Backups cannot be used to restore older application versions.
Restore the backup file in the Network application’s System Settings.
Ensure that all devices appear as online in the new application. If they do not, you can try Layer 3 adoption, or factory-reset and readopt your device(s) to the new application.

If a device continues to appear as Managed by Other, click on it to open its properties panel, then use its Device Authentication Credentials (from the original Network application’s host) to perform an Advanced Adoption.

Exporting Individual Sites from a Multi-Site Host

Certain Network application hosts (e.g., Cloud Key, Cloud Console, self-hosted Network applications) can manage multiple sites. Site exportation allows you to migrate specific sites from one multi-site host to another. To do so:

Click Export Site in your Network application’s System Settings to begin the guided walkthrough.
Select the device(s) you wish to migrate to your new Network application.
Enter the Inform URL of your new host. This will tell your devices where they should establish a connection in order to be managed. Once entered, all devices in the old application should appear as Managed by Other in the new one.

Note: When migrating to a Cloud Console, you can copy the Inform URL from the Cloud Console’s dashboard. Be aware that you will need to remove the initial http:// and the ending :8080/inform.
Go to your new Network application and select Import Site from the Site switcher located in the upper-left corner of your dashboard.

Note: You may need to enable Multi-Site Management in your System Settings.
Ensure that all devices appear as online in the new application. If they do not, you try Layer 3 adoption, or factory-reset and readopt your device(s) to the new application.

If a device continues to appear as Managed by Other, click on it to open its properties panel, then use its Device Authentication Credentials (from the original Network application’s host) to perform an Advanced Adoption.

Migrating UniFi Protect

We recommend saving your footage with the Export Clips function before migrating. Although we provide HDD migration instructions, it is not an officially supported procedure due to nuances in the RAID array architecture.

Standard Migration

Download the desired backup file (*.zip) from the original Protect application’s settings.
Ensure that your new Protect application is up to date. Backups cannot be used to restore older application firmware.
Replace your old UniFi OS Console with the new one. All other camera connections should remain unchanged.
Restore the backup file in the Protect application’s settings.

HDD Migration

Full HDD migration is not officially supported; however, some users have been able to perform successful migrations by ensuring consistent ordering when ejecting and reinstalling drives into their new console to preserve RAID arrays.

Note: This is only possible if both UniFi OS Consoles are the same model.

Remove the HDDs from the old console. Record which bay each one was installed in, but do not install them in the new console yet.
Turn on the new console and complete the initial setup wizard. Do not restore a Protect application or Cloud backup during initial setup!
Upgrade the new console and its Protect application to a version that is either the same or newer than the original console.
Shut down the new console, and then install the HDDs in the same bays as the original console.
Turn on the new console again. The Protect application should start with its current configuration intact, and all exported footage should be accessible.

Source :
https://help.ui.com/hc/en-us/articles/360008976393-UniFi-Backups-and-Migration

Check the status of the RDP protocol

Check the status of the RDP protocol on a local computer

Check the status of the RDP protocol on a remote computer

Check whether a Group Policy Object (GPO) is blocking RDP on a local computer

Check whether a GPO is blocking RDP on a remote computer

Modifying a blocking GPO

Check the status of the RDP services

Check that the RDP listener is functioning

Check the status of the RDP listener

Check the status of the RDP self-signed certificate

Check the permissions of the MachineKeys folder

Check the RDP listener port

Check that another application isn’t trying to use the same port

Check whether a firewall is blocking the RDP port

Recommended content

#1: 2 RaaS Attacks in 13 Months#

#2: The Critical Infrastructure Attack on Radiation Alert Networks#

#3: The Three-Step Ransomware Attack That Started with Phishing#

How Do Security Point Solutions Stack Up?#

Here’s Watch Out for in the Coming Months#

1. Log4j#

2. Misconfigured Firewalls and VPNs#

How to Minimize Your Attack Surface and Gain Visibility into the Network#

1. Impacted Products

2. Introduction

3a. VMware vCenter Server updates address remote code execution vulnerability in the vSphere Client (CVE-2021-21972)

3b. ESXi OpenSLP heap-overflow vulnerability (CVE-2021-21974)

3c. VMware vCenter Server updates address SSRF vulnerability in the vSphere Client (CVE-2021-21973)

4. References

5. Change Log

6. Contact

The Browser is The Most Important Work Interface and the Most Targeted Attack Surface #

Browser Security 101 – What is It That We Need to Protect?#

How to Choose the Right Solution#

The Definitive Browser Security Platform Checklist – What it is and How to Use It#

Browser Security Deep Dive#

The Checklist – A Straightforward Evaluation Shortcut #

How Often Should You Pentest?#

You Have an Agile or Continuous Release Cycle#

Your Web Applications Are Business-Critical#

Your Web Applications Are Customer-Facing#

You Are in a High-Risk Industry#

You Don’t Have Internal Security Operations or a Pen testing Team#

You Are Focused on Mergers or Acquisitions#

The Importance of Continuous Pen Testing#

The Bottom Line#

WUAUCLT

Examples

Powershell

Examples

Check if a reboot is required

List available updates on Microsoft Update

USOClient

Examples

Scan for updates

Download updates

Install updates

Here are other related links

Active Directory prerequisites

Install the Active Directory Domain Services role

Configure the first domain controller in a new Active Directory forest

Disable SMBv1 support

Enable signing on the SMB protocol

Disable LM and NTLMv1 authentication

Disable LLMNR and NBT-NS

Disable LLMNR

Disable NBT-NS

Some additional tracks

Description

Resolution

Related Articles

Categories

Types of Backups

UniFi OS Backups

Application Backups

UniFi OS Console Migration

Migrating UniFi Network

Standard Migration

Migrating Applications That Manage Layer 3 Devices

Exporting Individual Sites from a Multi-Site Host