Kevin Beaver

This All-in-One gathers the expertise of the leading For Dummies authors in the world of cybersecurity, including Joseph Steinberg, author of Cybersecurity For Dummies; Kevin Beaver, author of Hacking For Dummies; Ted Coombs, author of Cloud Security For Dummies; and Ira Winkler, author of Security Awareness For Dummies.

Articles From Kevin Beaver

page 1
page 2
12 results
12 results
Cybersecurity All-in-One For Dummies Cheat Sheet

Cheat Sheet / Updated 01-10-2023

To cyber-protect your personal and business data, make sure everyone at home and at work recognizes that they are a target. People who believe that hackers want to breach their computers and phones and that cyber criminals want to steal their data act differently than people who do not understand the true nature of the threat. Many businesses use security awareness programs to improve security related behaviors.

View Cheat Sheet
4 Ways Hackers Crack Passwords

Article / Updated 06-23-2022

Hackers use a variety of means to gain passwords. One of the most common ways for hackers to get access to your passwords is through social engineering, but they don’t stop there. Check out the following tools and vulnerabilities hackers exploit to grab your password. Keystroke logging One of the best techniques for capturing passwords is remote keystroke logging — the use of software or hardware to record keystrokes as they’re typed. Be careful with keystroke logging. Even with good intentions, monitoring employees raises various legal issues if it’s not done correctly. Discuss with your legal counsel what you’ll be doing, ask for her guidance, and get approval from upper management. Logging tools used by hackers With keystroke-logging tools, you can assess the log files of your application to see what passwords people are using: Keystroke-logging applications can be installed on the monitored computer. Check out Veriato's Cebral, as one example. Dozens of such tools are available online. Hardware-based tools fit between the keyboard and the computer or replace the keyboard. A keystroke-logging tool installed on a shared computer can capture the passwords of every user who logs in. Countermeasures against logging tools The best defense against the installation of keystroke-logging software on your systems is to use an antimalware program or a similar endpoint protection software that monitors the local host. It’s not foolproof but can help. As with physical keyloggers, you’ll need to inspect each system visually. The potential for hackers to install keystroke-logging software is another reason to ensure that your users aren’t downloading and installing random shareware or opening attachments in unsolicited emails. Consider locking down your desktops by setting the appropriate user rights through local or group security policy in Windows. Alternatively, you could use a commercial lockdown program, such as Fortres 101 for Windows or Deep Freeze Enterprise for Windows, Linux, and macOS X. A different technology that still falls into this category is Carbon Black’s “positive security” allow listing application, called Cb Protection, which allows you to configure which executables can be run on any given system. It’s intended to fight off advanced malware but could certainly be used in this situation. Weak password storage Many legacy and stand-alone applications — such as email, dial-up network connections, and accounting software — store passwords locally, which makes them vulnerable to password hacking. By performing a basic text search, you can find passwords stored in clear text on the local hard drives of machines. You can automate the process even further by using a program called FileLocator Pro. How hackers search for passwords You can try using your favorite text-searching utility — such as the Windows search function, findstr, or grep — to search for password or passwd on your computer's drives. You may be shocked to find what’s on your systems. Some programs even write passwords to disk or leave them stored in memory. Weak password storage is a criminal hacker’s dream. Head it off if you can. This doesn’t mean that you should immediately run off and start using a cloud-based password manager, however. As we’ve all seen over the years, those systems get hacked as well! Countermeasures against weak passwords The only reliable way to eliminate weak password storage is to use only applications that store passwords securely. This practice may not be practical, but it’s your only guarantee that your passwords are secure. Another option is to instruct users not to store their passwords when prompted. Before upgrading applications, contact your software vendor to see how it manages passwords, or search for a third-party solution. How hackers use network analyzers to crack passwords A network analyzer sniffs the packets traversing the network, which is what the bad guys do if they can gain control of a computer, tap into your wireless network, or gain physical network access to set up their network analyzer. If they gain physical access, they can look for a network jack on the wall and plug right in. Finding password vulnerabilities with network analyzers The image below shows how crystal-clear passwords can be through the eyes of a network analyzer. This shows how Cain & Abel can glean thousands of passwords going across the network in a matter of a couple of hours. As you can see in the left pane, these clear text password vulnerabilities can apply to FTP, web, Telnet, and more. (The actual usernames and passwords are blurred to protect them.) If traffic isn’t tunneled through some form of encrypted link (such as a virtual private network, Secure Shell, or Secure Sockets Layer), it’s vulnerable to attack. Cain & Abel is a password-cracking tool that also has network analysis capabilities. You can also use a regular network analyzer, such as the commercial products Omnipeek and CommView, as well as the free open-source program Wireshark. With a network analyzer, you can search for password traffic in various ways. To capture POP3 password traffic, for example, you can set up a filter and a trigger to search for the PASS command. When the network analyzer sees the PASS command in the packet, it captures that specific data. Network analyzers require you to capture data on a hub segment of your network or via a monitor/mirror/span port on a switch. Otherwise, you can’t see anyone else’s data traversing the network — just yours. Check your switch’s user guide to see whether it has a monitor or mirror port and for instructions on how to configure it. You can connect your network analyzer to a hub on the public side of your firewall. You’ll capture only those packets that are entering or leaving your network — not internal traffic. Countermeasures against network analyzers Here are some good defenses against network analyzer attacks: Use switches on your network, not hubs. Ethernet hubs are things of the past, but they are still used occasionally. If you must use hubs on network segments, a program like sniffdet for Unix/Linux-based systems and PromiscDetect for Windows can detect network cards in promiscuous mode (accepting all packets, whether they’re destined for the local machine or not). A network card in promiscuous mode signifies that a network analyzer may be running on the network. Make sure that unsupervised areas, such as an unoccupied lobby or training room, don’t have live network connections. An Ethernet port is all someone needs to gain access to your internal network. Don’t let anyone without a business need gain physical access to your switches or to the network connection on the public side of your firewall. With physical access, a hacker can connect to a switch monitor port or tap into the unswitched network segment outside the firewall and then capture packets. Switches don’t provide complete security because they’re vulnerable to ARP poisoning attacks. How hackers break weak BIOS passwords Most computer BIOS (basic input/output system) settings allow power-on passwords and/or setup passwords to protect the computer’s hardware settings that are stored in the CMOS chip. Here are some ways around these passwords: You usually can reset these passwords by unplugging the CMOS battery or by changing a jumper on the motherboard. Password-cracking utilities for BIOS passwords are available on the Internet and from computer manufacturers. If gaining access to the hard drive is your ultimate goal, you can remove the hard drive from the computer and install it in another one, and you’re good to go. This technique is a great way to prove that BIOS/power-on passwords are not effective countermeasures for lost or stolen laptops. Check cirt.net for a good list of default system passwords for various vendor equipment. Tons of variables exist for hacking and hacking countermeasures depending on your hardware setup. If you plan to hack your own BIOS passwords, check for information in your user manual, or refer to the BIOS password-hacking guide. If protecting the information on your hard drives is your ultimate goal, full (sometimes referred to as whole) disk is the best way to go. The good news is that newer computers (within the past five years or so) use a new type of BIOS called unified extensible firmware interface (UEFI), which is much more resilient to boot-level system cracking attempts. Still, a weak password may be all it takes for the system to be exploited. Weak passwords in limbo Bad guys often exploit user accounts that have just been created or reset by a network administrator or help desk. New accounts may need to be created for new employees or even for security testing purposes. Accounts may need to be reset if users forget their passwords or if the accounts have been locked out because of failed attempts. Password weaknesses in user account Here are some reasons why user accounts can be vulnerable: When user accounts are reset, they’re often assigned an easily cracked or widely-known password (such as the user’s name or the word password). The time between resetting the user account and changing the password is a prime opportunity for a break-in. Many systems have default accounts or unused accounts with weak passwords or no passwords at all. These accounts are prime targets. Countermeasures against passwords in limbo The best defenses against attacks on passwords in limbo are solid help-desk policies and procedures that prevent weak passwords from being available at any given time during the new-account-generation and password-reset processes. Following are perhaps the best ways to overcome this vulnerability: Require users to be on the phone with the help desk or to have a help-desk member perform the reset at the user’s desk. Require that the user immediately log in and change the password. If you need the ultimate in security, implement stronger authentication methods, such as challenge/response questions, smart cards, or digital certificates. Automate password reset functionality via self-service tools on your network so that users can manage most of their password problems without help from others.

View Article
Hacking For Dummies Cheat Sheet

Cheat Sheet / Updated 02-24-2022

Not all hacking is bad. It reveals security weaknesses or flaws in your computing setups. This Cheat Sheet provides you with quick references to tools and tips and alerts you to commonly hacked targets — information you need to make your security testing efforts easier.

View Cheat Sheet
Validate Data to Prevent Web Attacks: Input Hacks

Article / Updated 12-15-2021

Websites and applications are notorious for taking practically any type of input, mistakenly assuming that it’s valid, and processing it further. Not validating input is one of the greatest mistakes that web developers can make and one of the finest tools in a hackers toolkit. Several attacks that insert malformed data — often, too much at one time — can be run against a website or application, which can confuse the system and make it divulge too much information to the hacker. Input attacks can also make it easy for the bad guys to glean sensitive information from the web browsers of unsuspecting users. Buffer overflows hacks One of the most serious input attacks is a buffer overflow that specifically targets input fields in web applications. A credit-reporting application, for example, might authenticate users before they’re allowed to submit data or pull reports. The login form uses the following code to grab user IDs with a maximum input of 12 characters, as denoted by the maxsize variable: <form name="webauthenticate" action="www.your_web_app.com/ login.cgi" method="POST"> <input type="text" name="inputname" maxsize="12"> A typical login session involves a valid login name of 12 characters or fewer, but the maxsize variable can be changed to something huge, such as 100 or even 1,000. Then an attacker can enter bogus data in the login field. What happens next is anyone's call. The application might hang, overwrite other data in memory, or crash the server. A simple way to manipulate such a variable is to step through the page submission by using a web proxy, such as built into the commercial web vulnerability scanners or the free Burp proxy. Web proxies sit between your web browser and the server you’re testing and allow you to manipulate information sent to the server. To begin, you must configure your web browser to use the local proxy of 127.0.0.1 on port 8080. To access this proxy in Mozilla Firefox, choose Tools →   Options, scroll to the bottom of the Options dialog box, and select Settings in the Network Proxy section, Next, select the Manual Proxy Configuration radio button. In Internet Explorer, click the gear icon and choose Internet Options from the drop-down menu; in the resulting dialog box, click the LAN Settings button in the Connections section, select the Use a proxy server for your LAN radio button, and enter the appropriate host name/IP address and port number. All you have to do is change the field length of the variable before your browser submits the page, and the page is submitted using whatever length you give. You can also use Firefox Web Developer add-on to remove maximum form-field lengths defined in web forms. URL manipulation hacks An automated input attack manipulates a URL and sends it back to the server, telling the web application to do various things, such as redirect to third-party sites or load sensitive files from the server. Local file inclusion is one such vulnerability. This vulnerability occurs when the web application accepts URL-based input and returns the specified file’s contents to the user, as in the following example of an attempted breach of a Linux server’s passwd file: https://www.your_web_app.com/onlineserv/Checkout.cgi?state= detail&language=english&imageSet=/../..//../..//../..//../ ..///etc/passwd It’s important to note that most recent application platforms, such as ASP.NET and Java, are pretty good about not allowing such manipulation of the URL variables, this vulnerability can still be found from time to time. The following links demonstrate another example of URL trickery called URL redirection: http://www.your_web_app.com/error.aspx?URL=http://www. bad~site.com&ERROR=Path+'OPTIONS'+is+forbidden. http://www.your_web_app.com/exit.asp?URL=http://www. bad~site.com In both situations, an attacker can exploit the vulnerability by sending the link to unsuspecting users via email or by posting it on a website. When users click the link, they can be redirected to a malicious third-party site containing malware or inappropriate material. If you have nothing but time on your hands, you might uncover these types of vulnerabilities manually. In the interest of accuracy (and sanity), however, these attacks are best carried out by running a web vulnerability scanner, which can detect the weakness by sending hundreds of URL iterations to the web system very quickly. Hidden field manipulation hacks Some websites and applications embed hidden fields in web pages to pass state information between the web server and the browser. Hidden fields are represented in a web form as . Because of poor coding practices, hidden fields often contain confidential information (such as product prices on an e-commerce site) that should be stored only in a back-end database. Users shouldn't see hidden fields (hence, the name), but a curious attacker can discover and exploit them. To do so yourself, follow these steps: View the HTML source code. To see the source code in Internet Explorer and Firefox, right-click the page and choose View Source or View Page Source from the contextual menu. Change the information stored in these fields. A hacker might change a price from $100 to $10, for example. Repost the page to the server. This step allows the attacker to obtain ill-gotten gains, such as a lower price on a web purchase. Such vulnerabilities are becoming rare, but like URL manipulation, the possibility for exploitation exists, so it pays to keep an eye out. Using hidden fields for authentication (login) mechanisms can be especially dangerous. An ethical hacker once came across a multifactor authentication intruder lockout process that relied on a hidden field to track the number of times the user attempted to log in. This variable could be reset to zero for each login attempt and thus facilitate a scripted dictionary or brute-force login attack. It was somewhat ironic that the security control designed to prevent intruder attacks was vulnerable to an intruder attack. Several tools, such as the proxies that come with commercial web vulnerability scanners and Burp Proxy, can easily manipulate hidden fields. If you come across hidden fields, you can try to manipulate them to see what can be done. It’s as simple as that. Code injection and SQL injection hacks Similar to URL manipulation attacks, code-injection attacks manipulate specific system variables. Here’s an example: http://www.your_web_app.com/script.php?info_variable=X Attackers who see this variable can start entering different data in the info_variable field, changing X to something like one of the following lines: http://www.your_web_app.com/script.php?info_variable=Y http://www.your_web_app.com/script.php?info_variable=123XYZ This example is rudimentary. Nonetheless, the web application may respond in a way that gives hackers more information than they want, such as detailed errors or access to data fields that they're not authorized to access. The invalid input may also cause the application or the server to hang. Attackers can use this information to find out more about the web application and its inner workings, which can lead to a serious system compromise. If HTTP variables are passed in the URL and are easily accessible, it’s only a matter of time before someone exploits your web application. A web application used to manage personal information once presented this very problem. Because a "name" parameter was part of the URL, anyone could gain access to other people’s personal information by changing the "name" value. If the URL included "name=kbeaver", a simple change to "name=jsmith" would bring up J. Smith's home address, Social Security number, and so on. Ouch! The system administrator was alerted to this vulnerability. After a few minutes of denial, he agreed that it was indeed a problem and proceeded to work with the developers to fix it. Code injection can also be carried out against back-end SQL databases in an attack known as SQL injection. Malicious hackers insert SQL statements — such as CONNECT, SELECT, and UNION — into URL requests to attempt to connect and extract information from the SQL database that the web application interacts with. SQL injection is made possible by applications' failure to validate input properly combined with informative errors returned from database servers and web servers. Two general types of SQL injection are standard (also called error-based) and blind. Error-based SQL injection is exploited based on error messages returned from the application when invalid information is input into the system. Blind SQL injection happens when error messages are disabled, requiring the hacker or automated tool to guess what the database is returning and how it’s responding to injection attacks. A quick (although not always reliable) way to determine whether your web application is vulnerable to SQL injection is to enter a single apostrophe (’) in your web form fields or at the end of the URL. If a SQL error is returned, odds are good that SQL injection is present. You’re definitely going to get what you pay for when it comes to scanning for and uncovering SQL injection flaws with a web vulnerability scanner. As with URL manipulation, you’re much better off running a web vulnerability scanner to check for SQL injection, which allows an attacker to inject database queries and commands through the vulnerable page to the back-end database. The image below shows numerous SQL injection vulnerabilities discovered by the Netsparker vulnerability scanner. The neat thing about Netsparker is that after it uncovers SQL injection, you can use the built-in tool Execute SQL Commands to further demonstrate the weakness. A screens hot of SQL injection in action is about as good as vulnerability and penetration testing gets! When you discover SQL injection vulnerabilities, you may be inclined to stop there without trying to exploit the weakness. That’s fine. But you may as well see how far you can get. Try using any SQL injection capabilities built into your web vulnerability scanner if possible so that you can demonstrate the flaw to management. If your budget is limited, consider using a free SQL injection tool such as SQL Power Injector. Cross-site scripting hacks Cross-site scripting (XSS) is perhaps the best-known and most-widespread web vulnerability that occurs when a web page displays user input — typically via JavaScript — that isn’t validated properly. A hacker can take advantage of the absence of input filtering and cause a web page to execute malicious code on any computer that views the page. An XSS attack can display the user ID and password login page from another rogue website, for example. If users unknowingly enter their user IDs and passwords in the login page, the user IDs and passwords are entered into the hacker’s web server log file. Other malicious code can be sent to a victim’s computer and run with the same security privileges as the web browser or email application that’s viewing it on the system. The malicious code could provide a hacker full read/write access to browser cookies or browser history files, or even permit him to download or install malware. A simple test shows whether your web application is vulnerable to XSS. Look for any fields in the application that accept user input (such as in a login or search form), and enter the following JavaScript statement: <script>alert('XSS')</script> If a window pops up that reads XSS, the application is vulnerable. The XSS-Me Firefox Add-on is a novel way to test for this vulnerability as well. There are many more ways to exploit XSS, such as those requiring user interaction via the JavaScript onmouseover function. As with SQL injection, you really need to use an automated scanner to check for XSS. Both Netsparker and Acunetix Web Vulnerability Scanner do a great job of finding XSS, but they tend to find different XSS issues — a detail that highlights the importance of using multiple scanners when you can. Check below to see some sample XSS findings in Acunetix Web Vulnerability Scanner. Another web vulnerability scanner that's good at uncovering XSS that many other scanners won’t find is AppSpider (formerly NTOSpider) from Rapid7. AppSpider works better than other scanners at performing authenticated scans against applications that use multifactor authentication systems. AppSpider should be on your radar. Never forget: When it comes to web vulnerabilities, the more scanners, the better! If anything, a hacker may end up using one of the scanners that you don’t use. Countermeasures against input attacks Websites and applications must filter incoming data. The sites and applications must ensure that the data entered fits within the parameters that the application is expecting. If the data doesn’t match, the application should generate an error or return to the previous page. Under no circumstances should the application accept the junk data, process it, and reflect it to the user. Secure software coding practices can eliminate all these issues if they’re critical parts of the development process. Developers should know and implement these best practices to avoid input hacks: Never present static values that the web browser and the user don’t need to see. Instead, this data should be implemented within the web application on the server side and retrieved from a database only when needed. Filter out script tags from input fields. Disable detailed web server and database-related error messages if possible.

View Article
Best Practices for Minimizing Hacking of Email Systems

Article / Updated 12-14-2021

Although it’s not usually top of mind, people send a ton of good info via email that a hacker can use. Knowing this, you will want to ensure that your email systems are probably warded against hackers. The following countermeasures help keep messages as secure as possible to avoid an email hack. Software solutions that combat email hacking The right software can neutralize many threats against your email system: Use antimalware software on the email server — better, the email gateway — to prevent malware from reaching email clients. Cloud-based email systems such as those offered by Google and Microsoft often have such protection built in. Using malware protection on your clients is a given. Apply the latest operating system (OS) and email-server security patches consistently and after any security alerts are released. Encrypt (where it's reasonable to do so). You can go old-school and use S/MIME or PGP to encrypt sensitive messages, or use email encryption at the desktop level or the server or email gateway. Better (easier), you can use TLS via the POP3S, IMAPS, and SMTPS protocols. The best option may be to use an email security appliance or cloud service that supports the sending and receiving of encrypted emails via a web browser over HTTPS, such as G Suite and Office 365. Don’t depend on your users to encrypt messages. As with any other security policy or control, relying on users to make security decisions often ends poorly. Use an enterprise solution to encrypt messages automatically instead. Make sure that encrypted files and emails can be protected against malware. Encryption doesn’t keep malware out of files or emails. You just have encrypted malware within the files or emails. Encryption keeps your server or gateway antimalware software from detecting the malware until it reaches the desktop. Make it policy for users not to open emails any attachments, especially those from unknown senders or untrusted sources, and create ongoing awareness sessions and other reminders. Plan for users who ignore or forget about the policy of not opening unsolicited emails and attachments. This will happen! Certain software such as Microsoft Outlook and Windows SmartScreen can help alert users to the bad stuff. Operating guidelines for minimizing email hacking in your organization Some simple operating rules can keep your walls high and the hackers out of your email systems: Put your email server behind a firewall on a different network segment from the Internet and from your internal LAN — ideally, in a demilitarized zone (DMZ). Or, use a mail gateway. Harden by disabling unused protocols and services on your email server. Run your email server and perform malware scanning on dedicated servers if possible (potentially even separating inbound and outbound messages). Doing so can keep malicious attacks out of other servers and information in the event that the email server is hacked. Look for solutions that test embedded links and test them and provide safe links. Log all transactions with the server in case you need to investigate malicious use. Be sure to monitor these logs as well! If you can’t justify monitoring, consider outsourcing this function to a managed security services provider. If your server doesn’t need certain email services running (SMTP, POP3, and IMAP), disable them — immediately. For web-based email, such as Microsoft’s Outlook Web Access (OWA), properly test and secure your web server application and operating system. Require strong passwords. For stand-alone accounts as well as domain-level Exchange or similar accounts, any password weaknesses on the network will trickle over to email and be exploited by someone via Outlook Web Access or POP3. Be sure to include your email server(s) in your vulnerability scanning and penetration testing efforts. If you’re running sendmail — especially an older version — don’t. Consider running a secure alternative, such as Postfix or qmail.

View Article
Ethical Hacking: Improving Cybersecurity in Your Databases

Article / Updated 12-14-2021

Database systems — such as Microsoft SQL Server, MySQL, and Oracle — have lurked behind the scenes, but their value, security vulnerabilities and ability to be hacked have finally come to the forefront. Yes, even the mighty Oracle, which was once claimed to be unhackable, is as susceptible to exploits and hacks as its competition. With the slew of regulatory requirements governing database security, hardly any business can hide from the risks that lie within because practically every business (large and small) uses some sort of database, either in-house or hosted in the cloud. Choosing tools for your ethical hack As with wireless networks, operating systems, and so on, you need good tools for your ethical hack if you’re going to find the database security issues that count. The following are some great tools for testing database security: Advanced SQL Password Recovery for cracking Microsoft SQL Server passwords. Cain & Abel for cracking database password hashes. Nexpose for performing in-depth vulnerability scans. SQLPing3 for locating Microsoft SQL Servers on the network, checking for blank passwords for the sa account (the default SQL Server system administrator), and performing dictionary password-cracking attacks. You can also use network vulnerability scanners, such as Nexpose, along with exploit tools, such as Metasploit, for the ethical hack of your database testing. Finding databases on the network to identify vulnerabilities The first step in discovering database vulnerabilities is figuring out where they’re located on your network. It sounds funny, but many network admins aren’t even aware of various databases running in their environments. This situation is especially true of the free SQL Server Express database software editions that users can download and run on your network. It’s very common to find sensitive production data, such as credit card and Social Security numbers, being used in test databases that are wide open to abuse by curious insiders or even external attackers who have made their way into the network. Using sensitive production data in the uncontrolled areas of the network such as sales, software development, and quality assurance is a data breach waiting to happen. The best tool for discovering Microsoft SQL Server systems is SQLPing3. SQLPing3 can even discover instances of SQL Server hidden behind personal firewalls, such as Windows Firewall. This feature is nice, as Windows Firewall is enabled by default in Windows 7 and later. If you have Oracle in your environment, Pete Finnigan has a great list of Oracle-centric security tools that can perform functions similar to those of SQLPing3. Hacking database passwords SQLPing3 also serves as a nice dictionary-based SQL Server password-cracking program. It checks for blank sa passwords by default. Another free tool for cracking SQL Server, MySQL, and Oracle password hashes is Cain & Abel. You simply load Cain & Abel, click the Cracker tab at the top, select Oracle Hashes in the bottom-left corner, and click the blue plus symbol at the top to load a user name and password hash to start the cracking. You can also select Oracle TNS Hashes at bottom left and attempt to capture Transport Network Substrate hashes off the wire when capturing packets with Cain. You can do the same for MySQL password hashes. The commercial product ElcomSoft Distributed Password Recovery can also crack Oracle password hashes. If you have access to SQL Server master.mdf files (which are often readily available on the network due to weak share and file permissions), you can use ElcomSoft's Advanced SQL Password Recovery to recover database passwords immediately. You may stumble across some legacy Microsoft Access database files that are password protected as well. No worries: The tool Advanced Office Password Recovery can get you right in. There are also many end-of-life or unsupported versions of Access still around. Running a vulnerability scanner such as Nexpose to uncover flaws can prove beneficial. Depending on the findings, you might then be able to use Metasploit to demonstrate what can happen. As you can imagine, these password-cracking tools are great ways to demonstrate the most basic of weaknesses in your database security. They’re also nice ways to underscore the problems with critical files scattered across the network in an unprotected fashion. Another good way to demonstrate SQL Server weaknesses is to use SQL Server Management Studio to connect to the database systems you now have the passwords for and to set up backdoor accounts or browse around to see (and show) what’s available. Practically every unprotected SQL Server system ethical hackers come across has sensitive personal financial or healthcare information available for the taking. It simply takes a query such as the following to access the records in any given table: select * from <em>tablename</em> Ethical hacking: Scanning databases for vulnerabilities As with operating systems and web applications, some database-specific vulnerabilities can be rooted out only by using the right tools. You can use Nexpose to find such issues as the following: Buffer overflows. Privilege escalations. Password hashes accessible through default/unprotected accounts. Weak authentication methods enabled. A great all-in-one commercial database vulnerability scanner for performing in-depth database checks — including user-rights audits in SQL Server, Oracle, and so on — is AppDetectivePRO. AppDetectivePRO can be a good addition to your security testing tool arsenal if you can justify the investment. Many vulnerabilities can be tested from both an unauthenticated outsider’s perspective as well as a trusted insider’s perspective. The important thing is to review the security of your databases from as many angles as reasonably possible. If a database is out there and accessible, people are going to play with it.

View Article
How to Prevent Hacker Attacks: 4 Ways to Gather Public Information

Article / Updated 12-14-2021

Hackers often use information that is public to target organizations. The amount of public information you can gather about an organization’s business and information systems from the internet is staggering. To see for yourself how hackers utilize public information to launch an attack, use the techniques outlined below to gather information about your own organization. Using social media to prevent hacker attacks Social media sites are the new means for businesses to interact online. Perusing the following sites can provide untold details on any business and its people: Facebook LinkedIn Twitter YouTube As we’ve all witnessed, employees are often very forthcoming about what they do for work on social media sites like Facebook, details about their business, and even what they think about their bosses — especially after throwing back a few when their social filters have gone off track! You can also find interesting insights based on what people say about their former employers at Glassdoor. Performing a web search to see how hackers find info on an organization Performing a web search or simply browsing your organization’s website can turn up the following information: Employee names and contact information Important company dates Incorporation filings Securities and Exchange Commission (SEC) filings (for public companies) Press releases about physical moves, organizational changes, and new products Mergers and acquisitions Patents and trademarks Presentations, articles, webcasts, or webinars (which often reveal sensitive information — often ironically labeled confidential) Bing and Google ferret out information — in everything from word processing documents to graphics files — on any publicly accessible computer. Also, they’re free. Google is a favorite. Entire books have been written about using Google, so expect any criminal hacker to be quite experienced in using this tool, including against you. With Google, you can search the internet in several ways to see how a hacker might gain intel on your organization: Typing keywords: This kind of search often reveals hundreds and sometimes millions of pages of information — such as files, phone numbers, and addresses — that you never guessed were available. Performing advanced web searches: Google’s advanced search options can find sites that link back to your company’s website. This type of search often reveals a lot of information about partners, vendors, clients, and other affiliations. Using switches to dig deeper into a website: If you want to find a certain word or file on your website, simply enter a line like one of the following into Google: site:www.your_domain.com keyword site:www.your_domain.com filename You can even do a generic file-type search across the Internet to see what turns up: filetype:swf company_name Use the preceding search to find Adobe Flash .swf files, which can be downloaded and decompiled to reveal sensitive information that can be used against your business. Use the following search to hunt for PDF documents containing sensitive information that can be used against your business: filetype:pdf company_name confidential Web crawling as tool against hacker attacks Web-crawling utilities, such as HTTrack Website Copier, can mirror your website by downloading every publicly accessible file from it, similar to the way a web vulnerability scanner crawls the website it's testing. Then you can inspect that copy of the website offline, digging into the following: The website layout and configuration Directories and files that may not otherwise be obvious or readily accessible The HTML and script source code of web pages Comment fields Comment fields often contain useful information such as the names and email addresses of the developers and internal IT personnel, server names, software versions, internal IP addressing schemes, and general comments about how the code works. In case you’re interested, you can prevent some types of web crawling by creating Disallow entries in your web server’s robots.txt file. You can even enable web tarpitting in certain firewalls and intrusion prevention systems. Crawlers (and attackers) that are smart enough, however, can find ways around these controls. Contact information for developers and IT personnel is great for social engineering attacks. Websites that offer public information about organizations The following websites may provide specific information about an organization and its employees: Government and business websites: hoovers.com and finance.yahoo.com give detailed information about public companies. sec.gov/edgar.shtml shows SEC filings of public companies. uspto.gov offers patent and trademark registrations. The website for your state’s secretary of state or a similar organization can offer incorporation and corporate-officer information. Background checks and other personal information: LexisNexis.com ZabaSearch

View Article
The Dangers of Social Engineering

Article / Updated 12-14-2021

Many organizations have enemies who want to cause trouble through social engineering. These people may be current or former employees seeking revenge, competitors wanting a leg up, or hackers trying to prove their worth. In any event, the information gained from social engineering can be useful to someone hoping to launch a hacker attack against your organization. Regardless of who causes the trouble, every organization is at risk to the dangers of social engineering — especially given the sprawling internet presence of the average company. Larger companies spread across several locations are often more vulnerable given their complexity, but smaller companies can also be attacked. Everyone, from receptionists to security guards to executives to IT personnel, is a potential victim of social engineering. Help-desk and call-center employees are especially vulnerable because they’re trained to be helpful and forthcoming with information. Social engineering has serious consequences. Because the objective of social engineering is to coerce someone to provide information that leads to ill-gotten gains, anything is possible. Effective social engineers can obtain the following information: User passwords. Security badges or keys to the building and even to the computer room. Intellectual property such as design specifications, source code, and other research-and-development documentation. Confidential financial reports. Private and confidential employee information. Personally identifiable information (PII) such as health records and credit card information. Customer lists and sales prospects. If any of the preceding information is leaked, financial losses, lowered employee morale, decreased customer loyalty, and even legal and regulatory compliance issues could result. The possibilities are endless. Social engineering attacks are difficult to protect against for various reasons. For one thing, they aren’t well documented. For another, social engineers are limited only by their imaginations. Also, because so many methods exist, recovery and protection are difficult after the attack. Furthermore, the hard, crunchy outside of firewalls and intrusion prevention systems often creates a false sense of security, making the problem even worse. With social engineering, you never know the next method of attack. The best things you can do to counteract social engineering are remain vigilant, understand the social engineer’s motives and methodologies, and protect against the most common attacks through ongoing security awareness in your organization. How social engineers build trust to gain information Trust — so hard to gain, yet so easy to lose. Trust is the essence of social engineering. Most people trust others until a situation forces them not to. People want to help one another, especially if trust can be built and the request for help seems reasonable. Most people want to be team players in the workplace and don’t realize what can happen if they divulge too much information to a source who shouldn’t be trusted. This trust allows social engineers to accomplish their goals. Building deep trust often takes time, but crafty social engineers can gain it within minutes or hours. How do they do it? Likability: Who can’t relate to a nice person? Everyone loves courtesy. The friendlier social engineers are — without going overboard — the better their chances are of getting what they want. Social engineers often begin to build a relationship by establishing common interests. They often use the information that they gain in the research phase to determine what the victim likes and to pretend that they like those things, too. They can phone victims or meet them in person and, based on information the social engineers have discovered about the person, start talking about local sports teams or how wonderful it is to be single again. A few low-key and well-articulated comments can be the start of a nice new relationship. Believability: Believability is based in part on the knowledge social engineers have and how likable they are. Social engineers also use impersonation — perhaps by posing as new employees or fellow employees whom the victim hasn’t met. They may even pose as vendors who do business with the organization. They often modestly claim authority to influence people. The most common social engineering trick is to do something nice so that the victim feels obligated to be nice in return or to be a team player for the organization. How social engineers exploit relationships to gain information for hacks After social engineers obtain the trust of their unsuspecting victims, they coax the victims into divulging more information than they should. Whammo — the social engineer can go in for the kill. Social engineers do this through face-to-face or electronic communication that victims feel comfortable with, or they use technology to get victims to divulge information. Social engineering: Deceit through words and actions Wily social engineers can get inside information from their victims in many ways. They’re often articulate and focus on keeping their conversations moving without giving their victims much time to think about what they’re saying. If they’re careless or overly anxious during their social engineering attacks, however, the following tip-offs might give them away: Acting overly friendly or eager. Mentioning the names of prominent people within the organization. Bragging about their authority within the organization. Threatening reprimands if their requests aren’t honored. Acting nervous when questioned (pursing the lips and fidgeting — especially the hands and feet, because controlling the body parts that are farther from the face requires more conscious effort). Overemphasizing details. Experiencing physiological changes, such as dilated pupils or changes in voice pitch. Appearing rushed. Refusing to give information. Volunteering information and answering unasked questions. Knowing information that an outsider shouldn’t have. Using insider speech or slang despite being a known outsider. Asking strange questions. Misspelling words in written communications. A good social engineer isn’t obvious with the preceding actions, but these signs may indicate that malicious behavior is in the works. If the person is a sociopath or psychopath, of course, your experience may vary. (Psychology For Dummies, 2nd Edition, by Adam Cash [John Wiley & Sons, Inc.] is a good resource on such complexities of the human mind.) Social engineers often do a favor for someone and then turn around and ask that person whether he or she minds helping them. This common social engineering trick works pretty well. Social engineers also use what’s called reverse social engineering. They offer to help if a specific problem arises. After some time passes, the problem occurs (often at the social engineer’s doing), and then the social engineer helps fix the problem. They may come across as heroes, which can further their cause. Social engineers may ask an unsuspecting employee for a favor. Yes, they outright ask for a favor. Many people fall for this trap. Impersonating an employee is easy. Social engineers can wear a similar-looking uniform, make a fake ID badge, or simply dress like real employees. People think, “Hey, he looks and acts like me, so he must be one of us.” Social engineers also pretend to be employees calling from an outside phone line. This trick is an especially popular way of exploiting help-desk and call-center personnel. Social engineers know that these employees fall into a rut easily because their tasks are repetitive, such as saying “Hello, can I get your customer number, please?” over and over. Social engineering: Deceit through technology Technology can make things easier — and more fun — for the social engineer. Often, a malicious request for information comes from a computer or other electronic entity that the victims think they can identify. But spoofing a computer name, an email address, a fax number, or a network address is easy. Fortunately, you can take a few countermeasures against this type of attack. Hackers can deceive through technology by sending email that asks victims for critical information. Such an email usually provides a link that directs victims to a professional, legitimate-looking website that “updates” such account information as user IDs, passwords, and Social Security numbers. They also may do this trick on social networking sites such as Facebook and Twitter. Many spam and phishing messages also employ this trick. Most users are inundated with so much spam and other unwanted email that they often let their guard down and open emails and attachments that they shouldn’t. These emails usually look professional and believable, and often dupe people into disclosing information that they should never give in exchange for a gift. These social engineering tricks can occur when a hacker who has already broken into the network sends messages or creates fake internet pop-up windows. The same tricks have occurred through instant messaging and smartphone messaging. In some well-publicized incidents, hackers emailed their victims a patch purporting to come from Microsoft or another well-known vendor. Users may think that the message looks like a duck and quacks like a duck — but it’s not the right duck! The message is actually from a hacker who wants the user to install the patch, which installs a Trojan-horse keylogger or creates a backdoor into computers and networks. Hackers use these backdoors to hack into the organization’s systems or use the victims’ computers (known as zombies) as launchpads to attack another system. Even viruses and worms can use social engineering. The LoveBug worm, for example, told users they had secret admirers. When the victims opened the email, it was too late. Their computers were infected (and, perhaps worse, they didn’t have secret admirers). Many computerized social engineering tactics can be performed anonymously through Internet proxy servers, anonymizers, remailers, and basic SMTP servers that have an open relay. When people fall for requests for confidential personal or corporate information, the sources of these social engineering attacks are often impossible to track.

View Article
What You Need to Know about Email Hacking: Email Bombs

Article / Updated 12-14-2021

Every system you have in place can be subject to hacking. This includes email hacking, such as email bombs. Email bombs attack by creating denial of service (DoS) conditions against your email software and even your network and Internet connections by taking up a large amount of bandwidth and sometimes requiring large amounts of storage space. Email bombs can crash a server and provide unauthorized administrator access — yes, even with today’s seemingly endless storage capacities. Email hacking: Attachments An attacker can perform an email hack by creating an attachment-overload attack by sending hundreds or thousands of emails with very large attachments to one or more recipients on your network. Attacks using email attachments Attachment attacks have a couple of goals: The email server may be targeted for a complete interruption of service with these failures: Storage overload: Multiple large messages can quickly fill the total storage capacity of an email server. If the messages aren’t automatically deleted by the server or manually deleted by individual user accounts, the server will be unable to receive new messages. This attack can create a significant DoS problem for your email system, either crashing it or requiring you to take your system offline to clean up the junk that has accumulated. A 100MB file attachment sent 10 times to 100 users can take 100GB of storage space, which can add up! Bandwidth blocking: An attacker can crash your email service or bring it to a crawl by filling the incoming Internet connection with junk. Even if your system automatically identifies and discards obvious attachment attacks, the bogus messages eat resources and delay processing of valid messages. An email hack on a single email address can have serious consequences if the address is for an important user or group. Countermeasures against email attachment attacks These countermeasures can help prevent attachment-overload attacks: Limit the size of emails or email attachments. Check for this option in your email server’s configuration settings (such as those provided in Microsoft Exchange), in your email content filtering system, and even at the email client level. Limit each user’s space on the server or in the cloud. This countermeasure denies large attachments from being written to disk. Limit message sizes for inbound and even outbound messages if you want to prevent a user from launching this attack from inside your network. Typically, a few gigabytes is a good limit, but the limit depends on your network size, storage availability, business culture, and so on. Think through this limit carefully before putting one in place. Consider using SFTP, FTPS, or HTTPS instead of email for large file transfers. Numerous cloud-based file transfer services are available, such as Dropbox for Business, OneDrive for Business, and Sharefile. You can also encourage your users to use departmental shares or public folders. By doing so, you can store one copy of the file on a server and have the recipient download the file on his or her own workstation. Contrary to popular belief and use, the email system should not be an information repository, but that’s exactly what email has evolved into. An email server used for this purpose can create unnecessary legal and regulatory risks and can turn into a huge nightmare if your business receives an e-discovery request related to a lawsuit. An important part of your security program is developing an information classification and retention program to help with records management. But don’t go it alone. Get others such as your lawyer, human resources manager, and chief information officer involved. This practice can help ensure that the right people are on board and that your business doesn’t get into trouble for holding too many — or too few — electronic records in the event of a lawsuit or investigation. Email hacking: Connections A hacker can send a huge number of emails simultaneously to hack your email system. Malware that’s present on your network can do the same thing from inside your network if your network has an open Simple Mail Transfer Protocol (SMTP) relay (which is often the case). These connection attacks can cause the server to give up on servicing any inbound or outbound Transmission Control Protocol (TCP) requests. This situation can lead to a server lockup or a crash, often resulting in a condition in which the attacker is allowed administrator or root access to the system. Attacks using floods of emails An email hack using a flood of emails is often carried out in spam attacks and other DoS attacks. Countermeasures against email attachment attacks Prevent email hacks as far out on your network perimeter as you can, ideally in the cloud. The more traffic or malicious behavior you keep off your email servers and clients, the better. Many email servers allow you to limit the number of resources used for inbound connections, as shown in the Maximum Number of Simultaneous Threads setting for the IceWarp email server. This setting is called different things for different email servers and firewalls, so check your documentation. Completely stopping an unlimited number of inbound requests can be impossible, but you can minimize the impact of the attack. This setting limits the amount of server processor time, which can help during a DoS attack. Even in large companies, or if you’re using a cloud-based email service such as G Suite or Office 365, there’s likely no reason why thousands of inbound email deliveries should be necessary within a short period. Email servers can be programmed to deliver emails to a service for automated functions, such as create this e-commerce order when a message from this account is received. If DoS protection isn’t built into the system, an attacker can crash both the server and the application that receives these messages, potentially creating e-commerce liabilities and losses. This type of attack can happen more easily on e-commerce websites when CAPTCHA (short for Completely Automated Public Turing test to tell Computers and Humans Apart) isn’t used on forms. This can be problematic when you’re performing web vulnerability scans against web forms that are tied to email addresses on the back end. It’s not unusual for this situation to generate thousands, if not millions, of emails. It pays to be prepared and to let those involved know that the risk exists. Automated email security controls to guard against email hacking You can implement the following countermeasures as an additional layer of security to guard against email hacks: Tarpitting: Tarpitting detects inbound messages destined for unknown users. If your email server supports tarpitting, it can help prevent spam or DoS attacks against your server. If a predefined threshold is exceeded — say, more than 100 messages in one minute — the tarpitting function effectively shuns traffic from the sending IP address for a given period. Email firewalls: Email firewalls and content-filtering applications from vendors such as Symantec and Barracuda Networks can go a long way toward preventing various email attacks. These tools protect practically every aspect of an email system. Perimeter protection: Although not email-specific, many firewall and intrusion prevention systems can detect various email attacks and shut off the attacker in real time, which can come in handy during an attack. CAPTCHA: Using CAPTCHA on web-based email forms can help minimize the impact of automated attacks and lessen your chances of email flooding and DoS, even when you’re performing seemingly benign web vulnerability scans. These benefits really come in handy when you test your websites and applications.

View Article
How to Use the Vulnerability and Penetration Testing Process to Hack Your Own Systems

Article / Updated 12-14-2021

As with practically any IT or security project, you need to plan security testing. And, since it's been said that action without planning is the root of every failure, strategic and tactical issues in vulnerability and penetration testing need to be determined and agreed on in advance. To ensure the success of your ethical hacking efforts, spend time planning for any amount of testing, from a simple OS password-cracking test against a few servers to a penetration test of a complex web environment. If you choose to hire a “reformed” hacker to work with you during your testing or to obtain an independent perspective, be careful. Formulating your ethical hacking plan Getting approval for ethical hacking and security testing is essential. Make sure that what you’re doing is known and visible — at least to the decision-makers. Obtaining sponsorship of the project is the first step. This is how your testing objectives are defined. Sponsorship could come from your manager, an executive, your client, or even yourself if you’re the boss. You need someone to back you up and sign off on your plan. Otherwise, your testing may be called off unexpectedly if someone (including third parties such as cloud service and hosting providers) claims that you were never authorized to perform the tests. Worse, you could be fired or charged with criminal activity. The authorization can be as simple as an internal memo or an email from your boss when you perform these tests on your own systems. If you’re testing for a client, have a signed contract stating the client’s support and authorization. Get written approval of this sponsorship as soon as possible to ensure that none of your time or effort is wasted. This documentation is your “Get Out of Jail Free” card if anyone — such as your internet service provider (ISP), cloud service provider, or a related vendor —questions what you’re doing or if the authorities come calling. Don’t laugh — it wouldn’t be the first time it has happened. One slip can crash your systems, which isn’t necessarily what anyone wants. You need a detailed plan, but you don’t need volumes of testing procedures that make the plan overly complex. A well-defined scope for an ethical hack includes the following information: Specific systems to be tested: When selecting systems to test, start with the most critical systems and processes or the ones that you suspect are the most vulnerable. You could test server OS passwords, test an internet-facing web application, or attempt social engineering via email phishing before drilling down into all of your systems. Risks involved: Have a contingency plan for your security testing process in case something goes awry. Suppose that you’re assessing your firewall or web application, and you take it down. This situation can cause system unavailability, which can reduce system performance or employee productivity. Worse, it might cause loss of data integrity, loss of data itself, and even bad publicity. It’ll most certainly tick off a person or two and make you look bad. All of these can create business risks. Handle social engineering and DoS attacks carefully. Determine how they might affect the people and systems you test. Dates when the tests will be performed and overall timeline: Determining when the tests are to be performed is something you must think long and hard about. Decide whether to perform tests during normal business hours, or late at night or early in the morning so that production systems aren’t affected. Involve others to make sure that they approve of your timing. You may get pushback and suffer DoS-related consequences, but the best approach is an unlimited attack, in which any type of test is possible at any time of day. The bad guys aren’t breaking into your systems within a limited scope, so why should you? Some exceptions to this approach are performing all-out DoS attacks, social engineering, and physical security tests. Whether you intend to be detected: One of your goals may be to perform the tests without being detected. You might perform your tests on remote systems or on a remote office and don’t want the users to be aware of what you’re doing. Otherwise, the users or IT staff may catch on to you and be on their best behavior instead of their normal behavior. Whether to leave security controls enabled: An important, yet often-overlooked, issue is whether to leave enabled security controls such as firewalls, intrusion prevention systems (IPSes), and web application firewalls (WAFs) so that they block scans and exploit attempts. Leaving these controls enabled provides a real-world picture of where things stand. But there is much more value in disabling these controls (or allowlisting your IP address) so that you can pull back the curtains and find the greatest number of vulnerabilities. Many people want to leave their security controls enabled. After all, that approach can make them look better, because many security checks will likely be blocked. However, this defense-in-depth approach is great, but it can create a serious false sense of security and doesn’t paint the entire picture of an organization’s overall security posture. Knowledge of the systems before testing: You don’t need extensive knowledge of the systems you’re testing — just basic understanding, which protects both you and the tested systems. Understanding the systems you’re testing shouldn’t be difficult if you’re testing your own in-house systems. If you’re testing a client’s systems, you may have to dig deeper. In fact, only one or two clients have asked for a fully blind assessment. Most IT managers and others who are responsible for security are scared of blind assessments, which can take more time, cost more, and be less effective. Base the type of test you perform on the organization’s or client’s needs. Actions to take when a major vulnerability is discovered: Don’t stop after you find one or two security holes; keep going to see what else you can discover. This doesn’t mean that you should keep testing until the end of time or until you crash all your systems; ain’t nobody got time for that! Instead, simply pursue the path you’re going down until you can’t hack it any longer (pun intended).If you haven’t found any vulnerabilities, you haven’t looked hard enough. Vulnerabilities are there. If you uncover something big, you need to share that information with the key players (developers, database administrators, IT managers, and so on) as soon as possible to plug the hole before it’s exploited. The specific deliverables: Deliverables include vulnerability scanner reports and your own distilled report outlining important vulnerabilities to address, along with recommendations and countermeasures to implement. Selecting your ethical hacking tools As in any project, if you don’t have the right tools for your security testing, you’ll have difficulty accomplishing the task effectively. However, just because you use the right ethical hacking tools doesn’t mean that you’ll discover all the right vulnerabilities. Experience counts. Know the limitations of your tools. Many vulnerability scanners generate false positives and negatives (incorrectly identifying vulnerabilities). Others skip vulnerabilities. In certain situations, such as testing web applications, you have to run multiple vulnerability scanners to find all the vulnerabilities. Many ethical hacking tools focus on specific tests, and no tool can test for everything. For the same reason that you wouldn’t drive a nail with a screwdriver, don’t use a port scanner to uncover specific network vulnerabilities. You need a set of specific tools for the task. The more (and better) tools you have, the easier your security testing efforts will be. Make sure that you’re using tools like these for your ethical hacking tasks: To crack passwords, you need cracking tools such as Ophcrack and Proactive Password Auditor. For an in-depth analysis of a web application, a web vulnerability scanner (such as Netsparker or Acunetix web Vulnerability Scanner) is more appropriate than a network analyzer (such as Wireshark or Omnipeek). The capabilities of many security and ethical hacking tools are misunderstood. This misunderstanding has cast a negative light on otherwise excellent and legitimate tools; even government agencies around the world are talking about making them illegal. Part of this misunderstanding is due to the complexity of some security testing tools. Whichever tools you use, familiarize yourself with them before you start using them. That way, you’re prepared to use the ethical hacking tools in the ways that they’re intended to be used. Here are ways to do that: Read the "Readme" and/or online help files and FAQs (frequently asked questions). Study the user guides. Use the tools in a lab or test environment. Watch tutorial videos on YouTube (if you can bear the poor production of most of them). Consider formal classroom training from the security-tool vendor or another third-party training provider, if available. Look for these characteristics in tools for ethical hacking: Adequate documentation. Detailed reports on discovered vulnerabilities, including how they might be exploited and fixed. General industry acceptance. Availability of updates and responsiveness of technical support. High-level reports that can be presented to managers or nontechnical types (especially important in today’s audit- and compliance-driven world). These features can save you a ton of time and effort when you’re performing your tests and writing the final reports of your ethical hack. Executing your ethical hacking plan Good ethical hacks take persistence. Time and patience are important. Also, be careful when you’re performing your tests. A criminal on your network or a seemingly benign employee looking over your shoulder may watch what’s going on and use this information against you or your business. Making sure that no hackers are on your systems before you start isn’t practical. Just be sure to keep everything as quiet and private as possible, especially when you’re transmitting and storing test results. If possible, encrypt any emails and files that contain sensitive test information or share them via a cloud-based file sharing service. You’re on a reconnaissance mission. Harness as much information as possible about your organization and systems, much as malicious hackers do. Start with a broad view and narrow your focus. Follow these steps to begin your ethical hack: Search the internet for your organization’s name, its computer and network system names, and its IP addresses. Google is a great place to start. Narrow your scope, targeting the specific systems you’re testing. Whether you’re assessing physical security structures or web applications, a casual assessment can turn up a lot of information about your systems. Further narrow your focus by performing scans and other detailed tests to uncover vulnerabilities on your systems. Perform the attacks and exploit any vulnerabilities you find (if that’s what you choose to do). Evaluating the results of your ethical hack Assess your results to see what you’ve uncovered, assuming that the vulnerabilities haven’t been made obvious before now. Knowledge counts. Your skill in evaluating the results and correlating the specific vulnerabilities discovered will get better with practice. You’ll end up knowing your systems much better than anyone else does, which will make the evaluation process much simpler moving forward. Submit a formal report to management or to your client, outlining your results and any recommendations you need to share. Keep these parties in the loop to show that your efforts and their money are well spent. Implementing the results of your ethical hack When you finish your security tests, you (or your client) still need to implement your recommendations to make sure that the systems are secure. Otherwise, all the time, money, and effort spent on testing goes to waste. Sadly, this very scenario happens fairly often. New security vulnerabilities continually appear. Information systems change and become more complex. New security vulnerabilities and exploits are uncovered. Vulnerability scanners get better. Security tests provide a snapshot of the security posture of your systems. At any time, everything can change, especially after you upgrade software, add computer systems, or apply patches. This situation underscores the need to update your tools often — before each use, if possible. Plan to test regularly and consistently (such as once a month, once a quarter, or biannually).

View Article
page 1
page 2