In this blog in the “IT security under attack” series, we wanted to shed some light on an unfamiliar and seldom discussed topic in IT security: the default, out-of-the-box configurations in IT environments that may be putting your network and users at risk.
Default settings, and why the initial configuration is not the most secure
The quickest and easiest way to start up a device or software is with the default settings. They no doubt make the lives of everyone in IT easier, and the default configurations give us the satisfaction of experiencing the product firsthand, without having to undergo all the trouble with the initial configuration. Unfortunately, just because these settings are default does not mean they are recommended. Are they secure? No, not by a long shot.
Manufacturers and vendors always provide the default settings, placing customer experience and usability first. For instance, when you set up a new smartphone, there’s always an option to skip the security features, right? Like face ID or perhaps fingerprint security? The default configuration is only meant to be temporary, to jump-start you into experiencing the product. This configuration must be upgraded or changed, otherwise you risk the security of your network and the privacy of your users.
Let’s take a look at various areas in your network that contain dangerous defaults and how you can correct them before it’s too late.
-
Dangerous default passwords
-
It is almost like a ritual to discuss healthy password usage and rotation when it comes to security defaults, but it is also important to realize that passwords are not just for users:
-
Administrator passwords: As ironic as it may sound, the most powerful accounts are generally the ones with weak passwords. For instance, the local admin accounts in networks are used to configure servers in a network. However, most of the time, that’s where their role ends. These accounts are left unchanged with default or predictable passwords, which makes them a prime target in attacks. In environments like Active Directory (AD), Azure, or Amazon Web Services (AWS), the passwords of admin accounts may be secure, but they are still liberally reused or shared amongst people in the network.
-
Router passwords: Routers are the main gateway, and someone who has your router’s key could change its settings and hijack the network, leaving you without access. Anyone with certain know-how will also be able to access WiFi-connected devices and steal confidential information.
-
Local user passwords: Passwords for local accounts of devices (just like local admins) are often the same across servers. These passwords are generally shipped as default from the manufacturer but remain unchanged after initial configuration.
-
Database passwords: For instance, these are the passwords of accounts that were used to configure or manage your in-house database servers (like MSSQL or Oracle) but were never changed!
-
You get the point—watch over your passwords! Update them if they’ve been stagnant for a long time.
2. Dangerous default policies
The security polices in the network are crucial to control user access and dictate what a user can do in your network. There are a few security polices that may not be configured by default and must be enabled, or even vice versa!
For instance, if you have an on-premises AD infrastructure, there are several security policies in Group Policy Objects that must be configured.
For instance: 
When the above option is disabled, Windows stores password hashes of users in the local Security Account Manager database of Windows systems or AD. The hash can be extracted from memory and cracked by attackers to get the plaintext password.
Here are a few more default security policies that when misconfigured can put your organization at significant risk:
-
Do not allow storage of passwords and credentials for network authentication: Enable this policy, because when a user authenticates to a network share or proxy, or uses a piece of client software and ticks the “Remember my password” box, the password is typically stored in a vault, and the saved passwords can be seen via the credential manager, which can be broken into!
-
User Account Control: Only elevate executable files that are signed and validated: When this setting is enabled, admins can control and allow only legitimate and authorized apps to be run with admin privileges.
-
Control access to CMD (Command Prompt): Enable this policy to prevent command-line attacks and network information gathering attempts.
- All removable storage classes: Deny all access: Enable this setting to prevent your users from plugging USB drives into their workstations.
Similarly, if you use cloud infrastructures like Azure AD, every tenant has certain default security policies applied to it. However, it is important to realize that policies in Azure only ensure that an organization has a basic level of security; these policies are not a complete security strategy.
Azure does offer more granular and secure conditional access policies to resolve this issue, but you have to purchase a premium license to achieve tighter control over Azure security.
Similarly, users in an Azure tenant can invite “guest users,” and even invited guests can invite other guests.
And this is the default configuration! Although guests do not have permissions equal to that of a user who is a member of the organization, they still have read access to sensitive Azure resources—like user details, members of admin groups, and enterprise apps.
3. Dangerous “public” defaults in your network
In every IT environment, there are a few parts of the network that are public for users to access and modify, like the shares in your file servers. These public locations can also be referred to as dangerous defaults. For instance, once shares are created, the data in them is seldom monitored for changes. Since shares are accessible even by users with zero privileges, it makes them a sweet spot for attacks.
For example, an attacker may place malware with a clickbait file name in a share and leverage your end users as catalysts to spread the malware in the network.
Similarly, your system files and folders responsible for network configuration may also be deleted, or permissions could be modified by threat actors. However, this is not a default setting, and in most cases only admins or authorized users can access these system files (by default). Because of that, these files are seldom monitored for changes, and this is a classic example of an unmonitored default that may become a security threat.
It’s also good practice to monitor your cloud environments that have public storage locations, such as AWS and Azure AD.
An AWS S3 bucket’s configuration may be set to public (refer to the image above). Whether the public configuration was authorized or not, it is crucial to monitor the objects inside the bucket for changes and maintain a checklist of all public buckets just to be on the safe side.
In Azure, by default all users can register applications and set consent permission on their behalf.
Attackers often trick end users into providing consent to illicit apps via phishing attacks.
Img source: Microsoft
Once the user has granted consent, the attacker has account-level access without stealing credentials or infecting a user’s device. A user attack without compromising the password! Disable the policy that allows users to register and grant consent to apps. If that’s not an option, monitor user consent granted to new apps.
Dangerous defaults exist in many forms
And we’re only getting started! Dangerous defaults can manifest in many forms at various locations in a network, and you must be prepared. You must update these dangerous defaults or at the very least monitor them for changes. Other examples of dangerous defaults include:
-
Unused (inactive) users with outdated permissions
-
Sudo commands executed across Linux systems (otherwise only to be used by the default root user) or unscheduled cron jobs (scripts scheduling jobs)
-
Changes to the default registry keys, such as HKEY_LOCAL_MACHINE\Software\Microsoft\Windows\CurrentVersion\Run, which should only be modified by an admin or authorized user
-
Unchanged firewall inbound and outbound rules, or unauthorized changes to rules
-
Computer state changes (forced reboots), which could indicate a brute-force attack
-
A system service stopping (such as backup services or event log services), which could signal a ransomware attack
-
Default disk partitions modified across your virtual machines, or Network File System mounts or unmounts
-
Unauthorized network connected apart from the default networks
The goal of this blog was to show you the various ways default configurations can be exploited and the need to upgrade these settings. For the times when upgrading these configurations is not the answer, have a monitoring strategy in place to monitor them for unauthorized changes.
Visit our “IT security under attack” page to learn more about the various ways default configurations can be misused in a network. For a comprehensive solution that can help you gain insight on default configurations and monitor them for changes 24×7, check out ManageEngine Log360.
Nice Article! It gave me a new view about default policies.