With fall approaching, many of us will be stocking up on lawn bags in anticipation of scooping up what will seem like an endless wave of leaves. This serves as a nice reminder to do routine maintenance of your Active Directory “Tree” as well. Bust out the rakes and remove your disabled accounts that are no longer needed. It is important to ensure previous employee accounts have been bagged and tossed out as well. Unnecessary accounts can clutter your Active Directory configuration and add confusion to basic administrative tasks. In addition, accounts that are no longer needed, but left active can allow potentially unwanted access. As a rule of thumb, if you have accounts that need to be disabled for periods of time when unused, make sure you have a clearly defined comment to state the accounts purpose.
A common weakness we encounter on Internal Penetration Tests is not what you may expect. It is not the latest 0-day vulnerability, nor is it a hard to exploit vulnerability. Sometimes all it takes is a web browser to result in a simulated (or real) attacker gaining full control over your entire network: Default Credentials. While simple and seemingly a “no brainer” to fix, the reality of modern production networks is that even with mature change control, devices and applications still configured with default credentials can happen. An example that this engineer has seen on multiple engagements is a trial or demo of a systems management solution still configured with its default logon of “admin/admin” (or something similar). These solutions often offer a pre- configured VM (virtual machine) “appliance” that you download and run in your environment. Because it isn’t in “production” yet, many IT folks don’t see a reason to change this default username/password. Why would they? They are just taking it for a test drive! The problem becomes quickly clear as many of these management tools will need domain administrator privileges to perform their functions, e.g. deploy patches, inventory remote systems, etc. These domain admin credentials are entered to see how well the solution works. Many times, the system works great, is purchased, and goes from testing to production - many times the default logon is never changed! Or, just as common, the software isn’t purchased, and the VM is left on by accident, still configured with default credentials. As an attacker, gaining access to management or monitoring solutions is almost always a sure-fire way to gain domain admin level privileges. If you can’t use the software to create your own domain admin logon, you can use its management features to deploy software, run remote consoles on servers (as a domain admin level user), or sometimes just view clear-text or easily decryptable passwords. While easy to overlook, and extremely dangerous, the fix is still simple, change credentials on any devices or software that get deployed into your environment…even for testing. Some other recommendations include:
- Change control processes should include a step to change default credentials on any new systems. It is also important to read the documentation. Often the “admin” user isn’t the only privileged user pre-configured in a system. All built-in users should have their passwords changed, disabled, or removed if not needed.
- Make sure change control applies to test, development, or evaluation systems as well.
- Track deployment of trial software from implementation, to retirement/decommissioning if the trial does not transition into a purchase.
- Sometimes a complete reinstallation, or application of large updates, or repair of malfunctioning software can wind up resetting a logon back to a default password. Again, change control can help ensure that a system is still in a secure state after an upgrade or repair.
We currently have an old 15 year old sound system in our meeting room. Anyone have one that works well when listening and speaking? thanks
OK, Almost every time. You have all heard of Tailgating or Piggybacking, where someone follows someone through a secure door. The reverse tailgate is simply the reverse of that; someone sneaks through a door someone else has just come out of by catching the door before it closes. If done right the person leaving never sees or hears what has happened, so it is highly successful. Recommendation: When training on physical security, instill in your staff that they are responsible for witnessing the closing of the secure door they have opened, both inbound and outbound.
You’re sure you printed off those confidential documents, but you got distracted and didn't grab them. When you finally made it to the printer, they were gone! Many printer and multifunction devices (copy/scan/print) offer private printing. Private printing allows you to enter a code when printing a document, and then reenter the code on the printer’s keypad once you reach the printer. Every printer manufacturer does the task a little differently, but the basic premise is to look for a “Private Print” selection in the various printer settings when you File > Print a document. Practice private printing using a test document, making sure you understand the process before you print something important. If your printer does not support private printing, make sure that you don’t get sidetracked when printing important information - choose the closest printer and walk/run to it as soon as you click “Print”. Remember, leaving sensitive documents unattended on the printer can lead to unintended information and risk exposure!