"The quieter you become, the more you are able to hear." - Rumi

Series Introduction

In this series we will take a look at each step in the methodology listed below. This article will describe a high-level overview of the steps and subsequent articles will jump into the technical details of each step.

This series is only intended for ethical hacking, meaning your target is a willing participant and all boundaries have been established. HOWEVER, I will NOT skip details that a black-hat hacker would be considering.

Methodology

What separates a casual script-kiddie from an effective hacker? We're not talking about the savants here - the people that can just pick up anything and know how to break it immediately. Those folks are in our midst, but for the average Joes - you, dear reader, and myself - how does one become truly effective at hacking? And how does one do it in such a way that is beneficial to others?

Methodology. A systematic and thorough approach to breaking in. Note that this process is not always linear, but every good hacker uses a systematic approach in one form or another. As you sharpen your skills, you'll learn what can be skipped and refined.

• Step 1: Reconnaissance - Learn everything you can about the target.
• Step 2: Scanning and Enumeration - Perhaps one of the most important steps. List out every service and device you can find. This is the step you are most likely to be detected. Quietly, now.
• Step 3: Gaining Access - Find or develop an exploit that works. Most likely you will be adapting an already existing exploit.
• Step 4: Maintaining Access - Make sure you can get back. I.e. installing backdoors, listeners, or rootkits.
• Step 5: Covering Tracks - Time to think like a forensics person. What captured your activity? Remove it. Carefully.

Step 1: Reconnaissance

Step 1 is always reconnaissance. You have your target, now what can you find out about them? Remember, the more you find out, the more surface area you have to exploit. Here are some common things you might want to know:

• Who works there. Check LinkedIn.
• Do they have an office or multiple offices? Where are they located?
• Is there security?
• How do you gain access to the building? Badging? Badging plus pin codes? Walk right in?
• Location of web server target (if that's your target). This can perhaps be found in the next step of enumeration. Perhaps the web server lives in AWS or Azure. Or perhaps it's in a broom closet of a poorly guarded building.
• Social media presence
• Publicly accessible information on their website or through other sources. Check public records. Google their name, see what comes up.
• Naming conventions. Do they have a naming convention for email addresses? Most companies use first.lastname@companyname.com. You can use this to extrapolate email addresses from names found on their website or social media.
• Naming conventions of websites. This can be more useful in the next step for scanning.
• IP Addresses
• Domain name ownership. Run a whois on the domain name. Usually it's protected through a third-party registration service. But sometimes it's not. And if that's the case, you've just found out some useful information. Some domain name extensions do NOT ALLOW third-party registration. WINK WINK. If you're slick, find my personal email, and send me an email. :)
• Does their website have a robots.txt file? If so, what's it hiding? More information
• Again, NAMING CONVENTIONS. Are there naming conventions for login credentials?
• Check out the public authentication methods on their website. What is the registration process like, does it require MFA, how do you reset your password?
• If your target is a website, look at the source code. How much client-side validation is happening? Where are the inputs?

Step 2: Scanning and Enumeration

Step 2 is arguably the most important step. This is the step that you start determining the attack surface and find the interesting things that may allow you to gain a toehold. A toehold leads to a foothold leads to lateral movement leads to persistence leads to complete takeover. Like I said before, this can be the noisiest. Many of these tools have various quiet modes.

Port Scanning

Port scanning is the bread and butter of enumeration. Use this to identify potentially insecure services/versions running. Some tools for port scanning:

• nmap
• Zenmap (nmap with GUI)
• AutoRecon
• Sparta

Network Mapping/Subdomain Enumeration

Another thing you need to know is what devices/endpoints are on the network you're targeting. Look for hidden domains and resources. Some popular tools:

• Netdiscover
• Dnsrecon
• DnsEnum
• Fierce
• amass
• Wireshark (more for traffic analysis, but throwing it here under networking)

Vulnerability Scanning

Why should you try to find every vulnerability yourself? See what tools can automate this process:

• Nessus
• Nikto
• Skipfish
• Wapiti
• OpenVAS
• Unicornscan

Directory Sweeping

Many websites have directories that are not directly accessible through the web interface. See what you can find using these tools:

• dirbuster
• Ffuf
• gobuster
• dirb

Step 3: Gaining Access

Now that you have all this information, how do you get in? Take a close look at what your reconnaissance and scanning revealed. Some questions to ask that can determine your attack vector:

• Is it easy to gain access to the building?
• Did you identify any gullible looking targets?
• Did you identify any naming conventions?
• What services are running? What version are they?
• Did you find any developer resources hidden in subdomains?
• Any hidden login pages on the website?
• Where can you input data into the website?
• Did you find a domain server? What services are running on it? What version are the services?
• Did the vulnerability scans yield anything?

After you review your enumeration and reconnaissance, it's time to decide how to get in. One of these may work. These may have to be chained together. Here are some attack types, but not even close to an exhaustive list. Many of these are subcategories within another attack type and vice versa:

• Social Engineering
• DoS/DDoS
• Phishing/Whaling/Spear Phishing
• Man-In-The-Middle (MITM)
• Ransomware
• Broken Authentication
• Password Attacks
• Birthday Attacks
• SQL Injection
• Spoofing
• Brute Forcing
• Session Hijacking
• Web attacks such as Cross-site scripting (XSS) and cross-site request forgery (CSRF)
• Trojan Horse
• Rootkits

Once you decide what route to take, here are some tools for gaining access:

• Metasploit
• sqlmap
• Hydra
• Medusa
• aircrack-ng

Step 4: Maintaining Access

Now that you've got access and escalated your privileges to root/Administrator (you have done that, haven't you?), it's time to make sure you can get back in. Oftentimes hackers create what's called a "backdoor," which allows them to log back in. It can be difficult to maintain backdoors through software patches, assuming there is patching happening, so a rootkit may be necessary. Backdoors are often created using reverse shells. Some tools for creating backdoors:

• netcat
• pwnat
• weevely
• powersploit
• sbd (Shadow integer Backdoor)

Step 5: Covering Tracks

Now that you've pwned the system, it's time to hide yourself. Some actions that can be taken/considered:

• Clearing logs. Or, better yet, only clearing the log of the evidence that you were there. It's awfully suspicious if log files mysteriously disappear. Most standards call this out specifically (See NIST 800-53 AU-9.b)
• Uninstall any scripts or applications used to carry out attacks
• Delete folders created during attack
• Delete evidence of any application installation

A Special Mention - Burp Suite

I bet you're wondering why I didn't mention Burp Suite? Well, that's because I'd have to mention it at every step of the way. Burp Suite supports the entire process from enumeration and analysis to attack. It's an incredible tool that deserves its own series.

Closing

In this article we've covered a very high level methodology required to systematically pwn a system. Most, if not all, line items in this article can have 10,000+ words written about them. Not everything is in perfect order. Not everything is going to be perfectly accurate - there are gaps in my knowledge that I strive to lessen daily. This is just the beginning.

General Disclaimer

The information provided in this article is intended for educational purposes only. The author does not condone or endorse any illegal activities, including hacking, unauthorized access, or any other activities that violate applicable laws. The content is meant to raise awareness about potential cybersecurity threats and promote responsible and ethical use of technology. Readers are advised to use the knowledge gained from this article responsibly and within the boundaries of the law. The author and publisher are not liable for any misuse or legal consequences resulting from the application of the information presented herein.

Best Practices for Logging and Monitoring

• Capture log files (obviously) and centralize those log files for systems and applications
• Have the ability to search and analyze the log files. Your log files are useless if you don't know what they mean.
• Implement monitoring and alarming. You want to know about time-sensitive events as they happen.
• Have the ability to trace what applications are doing what through the logs. "This Lambda event caused this EC2 instance to crash which caused X"
• Create dashboards and visualizations for easy viewing.

AWS Documentation

Amazon CloudTrail

CloudTrail is an AWS service that records activity on the AWS account. It provides history of API and non-API account activity. You can keep logs as long as you want as well as configure it on a per region basis or across all regions. It also offers multiple levels of encryption. For log file integrity validation, it uses SHA-256 hashing and RSA signing. By default, when you enable Amazon CloudTrail, it enables the following:

• Saves 90 days of history
• Logs stored in S3 bucket
• Encrypted using S3 SSE
• Delivery of logs within 15 minutes of API call

Amazon CloudTrail has 3 types of events: Management Events, Data Events, and Insight Events.

Management Events

• When security objects are configured, aka AWS Identity and Access Management (IAM)
• When devices are registered
• When rules are configured for routing
• When setting up logging (I wonder if that means any events related to CloudTrail will be captured? I bet it does!)

Data Events

• S3 activity (Get, Put, Delete). Want to know who's trying to delete your valuable S3 data?
• Lambda function execution activity
• AWS Systems Manager activity

Insight Events

• Unusual API call rate activity (Who in the world is trying to hit my API 10,000 times per second?)
• Unusual error rate activity (Who is trying to login 500 times in the past minute?)

AWS Documentation

Amazon CloudWatch

CloudWatch allows you to get advanced metrics from your AWS resources. It aggregates the logs, allows you to query, analyze, and create insights and alarms. It can also be used to enable other services like Athena and OpenSearch as discussed below.

AWS Documentation

Amazon Athena

Amazon Athena can access an S3 bucket which Amazon CloudWatch has put there. From there, it can be queried using standard SQL. It is also serverless, fast, and inexpensive. Compared to OpenSearch, it's also far easier to set up. It also scales automatically.

AWS Documentation

Amazon OpenSearch

Amazon OpenSearch is an open-source alternative to Athena. Because it's open-source you don't have to pay for a license. It's also very fast and has more features than Athena. Athena also doesn't have visualization built in, but OpenSearch can aid you in visualizing your data right out of the box. A disadvantage is that it requires a bit more set up to get functional as it is required to pull from a Lambda function.

• AWS Documentation
• OpenSearch Documentation

Metrics and Alarming

Using Amazon CloudWatch and AWS EventBridge together, you can create alarms and rules that trigger certain actions. You can do things such as shutting down EC2 instances (Oh no, somebody's hacked it! Shut it down now!), scale instances up and down, and notify the team via email or your favorite chat client. I don't think it supports AOL Instant Messenger (AIM)...bummer.

AWS X-Ray

AWS X-Ray allows you to get a complete view of requests as they travel through your application. It traces through payloads, functions, services, APIs, and more. This isn't necessarily a required service in any infrastructure, but it can be immensely helpful in debugging. I highly recommend reading further in the documentation below. While I don't personally have experience with this (yet!), it will be something I keep in my back pocket.

AWS Documentation

AWS Security Hub

AWS Security Hub provides a compact view of your security posture within AWS. You can use it to run automated checks and prioritize and remediate security issues. The security hub can utilize multiple different security standards such as Center for Internet Security (CIS), or, if you're in the banking industry, Payment Card Industry Data Security Standard (PCI DSS), or, even more broadly, the National Institute of Standards and Technology (NIST). (Repeat after me, "We love NIST 800-53, we love NIST 800-53...")

In addition to supporting multiple standards, AWS Security Hub can also receive findings from other AWS services such as Config, GuardDuty, Inspector, and Macie. Now, what do you do with those findings? How do you get alerted? Luckily, as always, AWS has thought of that. You can utilize the Security Hub to send the findings to the AWS Audit Manager or to AWS Chatbot which can send a message to Teams or Slack or whatever your messaging service.

Official AWS documentation

AWS CloudWatch

AWS CloudWatch is your first stop for monitoring your AWS resources. It is a repository that collects different metrics and logs from AWS resources. CloudWatch has alarm features, correlation features, and various dashboards to view your data quickly. CloudWatch can alert you when, say, your super duper software goes rogue and decides to use 100% of your EC2 instance's CPU. Oh, yours doesn't do that? Well, clearly you're the superior programmer. Anyway, for those of us with less than perfect programming skills, CloudWatch can be beneficial to ensure your AWS resources don't go rogue.

Official AWS documentation

AWS GuardDuty

Amazon GuardDuty is a machine learning (See xkcd 1838) backed threat detection service. When you set it up, you leave it running for a week or so and it builds a baseline of expected activity for your environment. Behind the scenes, GuardDuty uses VPC Flow Logs (network traffic logging), DNS Logs, CloudTrail, and S3 events.

Of course, there are elements you should trust inherently, such as a scanner running on your infrastructure. For this reason, you can add trusted IPs. Conversely, if you have a known threat, you can add an IP as an untrusted IP. Even further, GuardDuty has a malware detector that can detect malware on your EC2 instances.

Official AWS documentation

Amazon Inspector

Amazon Inspector is a vulnerability management service that continually scans your AWS resources such as EC2 instances, containers in the ECR (Elastic Container Registry), and Amazon Machine Images (AMIs). It scans for CVEs and unintended network exposure. Because who hasn't created an EC2 instance that you couldn't access, so you just configured a 0.0.0.0/0 inbound rule, and voila! Access! Oh, wait...that opened it up to the entire web! Amazon Inspector catches those things and more.

Official AWS documentation

AWS IoT Device Defender

AWS IoT Device Defender helps you audit configurations, detect anomalies, and authenticate your IoT (Internet of Things) devices. Like all other AWS services, it will send alerts based on findings. It audits those resources based on security best practices. It has a couple of detection methods such as rules-based detection and machine learning based detection. Machine learning based detection checks metrics such as packet count, number of messages sent, authorization attempts, etc.

Official AWS documentation