Demystifying Attack Path Mapping

Staying ahead of potential threats for organizations requires a proactive approach. Cybersecurity professionals employ attack path mapping to understand, visualize, and mitigate potential attack vectors within a system or network. Regarding exposure management, APM helps shortlist the most critical findings out of hundreds or thousands of findings and thus reduces the company’s risk level.

At its core, attack path mapping involves the identification and analysis of potential routes that a cyber attacker could take to infiltrate a target system or network. These paths typically consist of a series of interconnected steps or vulnerabilities that, when exploited, enable unauthorized access or compromise of sensitive assets.

The process of attack path mapping begins with thorough reconnaissance and enumeration, where security experts gather information about the target environment, including its infrastructure, applications, protocols, and potential vulnerabilities. This information is the foundation for constructing a comprehensive map of potential attack paths.

Key Benefits

Attack path mapping offers several key benefits in the realm of cyber security defense:

• Risk Assessment: When performing a risk assessment, it’s important to do so in the context of your business, i.e., how critical is the asset for the company, and what is the possible impact? Organizations can assess the likelihood and impact of various cyber threats by visualizing potential attack paths. This allows them to prioritize security measures and allocate resources effectively to mitigate the most critical risks.
• Vulnerability Identification: Attack Path Mapping helps uncover hidden vulnerabilities and weak points within a system or network architecture. By understanding how these vulnerabilities can be exploited in tandem, organizations can take proactive steps to remediate or patch them before malicious actors exploit them.
• Incident Response Planning: With insights from attack path mapping, organizations can develop more effective incident response plans. By anticipating potential attack scenarios and their corresponding paths, security teams can respond swiftly and decisively to mitigate the impact of security breaches.
• Compliance and Regulation: Many industry regulations and compliance standards require organizations to demonstrate a proactive approach to cybersecurity risk management. Attack Path Mapping provides a structured methodology for fulfilling these requirements by identifying and addressing potential security gaps.

Best practices

To effectively leverage Attack Path Mapping in their cybersecurity defense strategies, organizations can follow these best practices:

• Continuous Monitoring: Cyber threats are constantly evolving, making continuous monitoring essential for staying ahead of potential risks. Regularly updating and revisiting attack path maps ensures organizations remain vigilant against emerging threats and vulnerabilities.
• Collaboration and Communication: Attack Path Mapping is a collaborative effort that involves multiple stakeholders, including security analysts, network administrators, and business leaders. Effective communication and collaboration facilitate sharing insights, expertise, and resources necessary for comprehensive threat mitigation.
• Automation and Tools: Automation tools can streamline the Attack Path Mapping process by aggregating and analyzing vast amounts of data more efficiently than manual methods. Investing in advanced threat intelligence platforms and network visualization tools can enhance the accuracy and effectiveness of Attack Path Mapping efforts.
• Adaptability and Flexibility: Cyber attackers are adept at adapting their tactics to circumvent security measures, making it crucial for organizations to remain adaptable and flexible in their defense strategies. Regularly updating attack path maps and reassessing security controls ensures that defenses remain resilient against evolving threats.

The ability to anticipate, detect, and mitigate cyber threats is paramount in today’s interconnected digital landscape. Attack Path Mapping provides organizations with a proactive framework for understanding and addressing potential security risks, enabling them to fortify their defenses against increasingly sophisticated cyber attacks.

By embracing attack path mapping as a core component of their cybersecurity strategy, organizations can enhance their resilience and safeguard their critical assets in the face of evolving threats.

What is the point of a red team?

It’s pretty common for people to ask us for a red team engagement to understand if their organization can be breached.

Well, every organization can be breached – you don’t need an expensive red team to prove that.

Okay, point taken, the client might say. What we actually want to know is how an attacker might breach us.

Excellent. You still don’t need a red team. A red team will always take the path of least resistance and will stop the engagement when they reach a predefined point. You won’t get all the information you need from a red team; a purple team might be better.

At this point, there’s often a bit of a confusion. After all, we’re a cybersecurity company; shouldn’t we want to sell you a red team? Actually, no: we don’t want our clients to waste their money. We want to have an honest discussion and only sell you services that will help solve your problems.

Here are some of the things we look for when we are considering selling a red team service.

Four key reasons to get a red team

1. You want a stress test

If you want to find out if you are fit, play a game of squash with an experienced player. It’s not about winning: it’s about trying to keep up with the pace.

If you feel like your blue team is ready, you might want to use a red team as a general stress test. If you know your blue team isn’t match fit yet, proceed with caution.

2. The red team isn’t the first test you’ve done

We usually recommend that you pen test individual systems and the corporate network before considering a red team. You should also have a solid strategy around detection and response, including tooling that is already in use, in place.

3. You have a decent threat model

You should know what your highest-value assets are and have a record of likely threats you might encounter, accounting for the type of organization and the industry you operate in.

4. You have budget

You need to have a reasonable budget for a red team, not only because a thorough engagement takes up a lot of consultant time (often 60+ consultant days), but because if you are stretching your budgets to breaking point to pay for a red team, there are probably more valuable things you could buy for the same money. For example, a smaller organization looking to spend money on cybersecurity may be better served by purchasing a year’s worth of managed detection and response if they don’t already use it.

Other good reasons for wanting a red team

Convincing others that you are ready for an engagement, or that you need more investment in security

Experienced regulators and CISOs know that red teams will always breach the organization’s defenses. To assess the strength of a blue team, they look for good detection rates.

A red team engagement is an unequivocal test of a blue team’s capability, much more indisputable than a purple team, for example, and so they can be useful for proving to various stakeholders that the organization is ‘match ready’.

Alternatively, you could take the riskier move of using a red team to demonstrate that the organization is not secure, hoping that this might result in increased investment in security services and resources. The people to be convinced aren’t necessarily sitting around the board room table—they might be internal development teams or a group of particularly confident Cloud architects who think they’ve built something really robust.

Overcoming stage fright

Imagine you’re a new SOC analyst, sitting in a room with screens everywhere, surrounded by people. Suddenly you get an alert: the organization is under attack.

SOC analysts in this position can get very real stage fright. They have trained for three years or so, and suddenly an attack is underway and it’s their job to stop it. They could lose their job if they get it wrong. Everyone else in the room is panicking as their systems crash.

Red teaming is a way to let these SOC analysts rehearse. Practicing their response in a setting that feels real, but that is actually controlled behind the scenes, is somewhat like training firefighters in real burning buildings.

Summary

Everyone wants a red team, but very few organizations need one. Some members of our Sales team at Reversec have estimated that more than half of the red-team enquiries they get eventually turn into discussions about other, more effective (and less costly) engagements for the customer once the client had explained their needs.

This is because red teams, although valuable in some contexts, are not right for everyone. Remember, the real benefits of a red team are not about learning whether and how an attacker could breach your organization; red teaming is about assessing and improving defense, detection and response capabilities, and educating the blue team so that they can operate more effectively in the future.

For more

For detailed insights into red teaming, as well as other solutions like purple teaming and attack path mapping, please visit our service pages.

I’m a red teamer, hired to help my clients understand their own readiness to prevent, detect, and respond to targeted attacks focused on cyber attacks, physical attacks or both. Over the last three days I had broken into my client’s office, stolen a laptop, and penetrated their environment to steal valuable intellectual property.

Wrapping up

My team reconvened on Monday for a short post-mortem. We discussed the tactics, techniques, and procedures that we used and why we used them. We reflected on the indicators of compromise that the client’s security team could have been monitoring for. These, we hypothesized, could have stopped the attack progressing or at least would have given away some aspects of the attack that would have allowed detection by the defenders (otherwise called the blue team). However detection is only the first step; knowing what to do, as well as when and how to do it, is a crucial part of containing a targeted attack and limiting its impact.

Our recommendations were pragmatic and empathetic. We aimed to provide short- and long-term defensive measures that would buy the client time to tackle the deeper root causes and potential mitigation paths for detecting and containing similar attacks. We made sure to discuss the potential impacts of the proposed changes on the day-to-day use of IT systems and the company culture; cybersecurity is about people and the processes they follow as much as it is about technology.

Results workshop

The following day, I sat at a large glass table with the client’s white and blue teams (who were in charge of refereeing the engagement and defending the environment, respectively). Another red teamer had joined me to provide additional thoughts on the outcome of the test. Although I was excited to share the findings of the engagement, I understood the gravity with which they would reach the ears of the attendees.

Walking through the attack scenarios in detail, I explained every technical action and decision, inviting questions as I went.

The client asked some good questions, including some that we get in almost every workshop. They asked:

• How did we perform compared to other organizations in our sector?
• What was your plan B if your techniques had not worked?
• Where do you think our strengths lie?
• What did we do defensively that slowed you down or made you concerned about being detected?
• What would you choose as your primary target if you were to run another engagement?
• Are our physical security and network security teams collaborating?
• Is our cybersecurity department collaborating with our network department?
• Are our third-party products increasing our risk?
• Did our security products stop you or slow you down?
• Did you notice a security culture or a sense of shared responsibility among our colleagues?

I answered these questions fully while describing my general approach to the attack narrative, including the attack paths I took, the obstacles I observed and how they were circumvented, and how each attack was performed and structured.

Recommendation

Make the most of having your consultants in the room with you. Ask how the recommendations they are making will affect your business, including how long they will take to implement and what the next targets should be. 

Ensure you leave the meeting with a good understanding of where the real root causes lie when it comes to the things the red team saw and experienced. 

Ultimately, every technical vulnerability is a process problem. So ask questions that are focused on how processes can change to increase resilience against targeted attacks.

This was followed by a deep-dive analysis of the attacks I’d prepared but not attempted (and thus could be input for a follow-up simulation or remediation project, should there be a risk of exploitation). I presented my analysis of the client’s security posture and awareness, as well as observations of the actions taken by the blue team around detection, containment, and the time frames in which responses were received.

A strong overall security posture is one in which security controls are working with each other and not against each other. We look for a culture of security, where best practices are considered and defensive actions are based on accurate information and well-defined priorities.

Finally, we gave an overview of remaining attack artefacts, including what data was accessed and where, how the data was kept safe and secure during and after the test, and how the anonymity of individual employees or departments had been upheld.

Some of the findings we discussed immediately gained traction, and several good ideas were put forward as solutions to the problems we had identified, including:

• Removing the availability of certain services and ensuring they can only be used after a VPN connection had been established on internal networks as well as internet facing hosts and services
• Ensuring that successful access attempts are logged and acted upon as much as unsuccessful ones
• Setting up network security controls inside the building in a way where a breach is assumed and where your physical location (such as meeting rooms, the CEO’s office, or the IT administrators’ department) does not automatically dictate your network or application privileges
• Enabling multi-factor authentication for internal and relevant services
• Ensuring that application servers and virtualization services are segregated as much as possible based on risk and threat modelling.

Some of our other findings, however, were less well received. Some post-engagement briefings can involve heated conversations, especially when there is political tension within the client organization. It’s not every day you experience a targeted attack simulation that shows just how disastrous a real attack can be. But ultimately, it’s my job to align the room behind a common goal, because improving the client’s security posture is always a team effort.

The workshop became increasingly collaborative as we progressed, with everyone at the table talking through the indicators of compromise that could have been identified, what measures could be built for future detection, and where the client could create additional strategic detection choke points to obtain greater transparency across network activity.

Red teamer job satisfaction comes from everyone learning from each other, where everyone’s daily work and lives become a little bit easier, and when everyone can focus on relevant threats and what it takes to reduce risk while helping the organization grow.

Recommendation

Not every recommendation is fit for every organization; there are many paths towards lowering risk, so make sure you get tailored recommendations from your consultant and understand how they address your specific needs while understanding the impact those recommendations will have on your technical landscape and the company culture.

My timeline of events was compared with the client’s, and all measures and tactics were debated in the context of the organization’s risk appetite, technical roadmap, and upcoming developments in the business.

Final thoughts

Whatever a client expects from the results, the outcome of a red team engagement is never ‘pass’ or ‘fail’. It’s a stress test designed to highlight how much control is really present across the organization and how fast a targeted attack can be detected and contained, and the attacker eradicated. The only way to really understand your own security posture is to perform these stress tests regularly so that you can compare your results over time.

Red teaming provides a unique opportunity to test critical assets in production, as well as how well security controls, training and processes can work together to defend your business so that a breach, downtime or ransomware attack can ultimately be just another Tuesday and not a newspaper headline with long term impact. 

Checking-in

I had just stolen two laptops from my client’s office. After days of research and surveillance, I had made it past their physical security with relative ease. My next task was to tell the client about the breach.

I am a red-teamer, hired to test clients’ readiness to prevent, detect, and respond to targeted cyber attacks. Stealing those laptops was phase one of my work; the physical prelude to the true test of cyber security.

My client wanted to understand the severity of the risk should a malicious actor acquire one of their laptops. They were not only worried about laptops being stolen, but also about laptops being lost in public places like trains and taxis (which happens roughly as often as true thefts).

Phase one had gone well. I updated the client’s “white team” (the internal stakeholders refereeing the engagement) over the agreed encrypted channel. This is a critical part of the red team service, which is all about collaboration, communication, and education. A red team engagement needs to be an authentic test, but it should never be unsafe or add risk to the business. I always contact white teams regularly and at a frequency they are happy with.

I was about to start phase two: penetrating the client’s computer network to steal their high-value trading algorithms and workflows.

The laptop whisperer

Double shot black coffee. Really black. So black, light cannot escape the cup. This is the best way to start.

Encryption

Back in my own office, I flipped the contractor’s laptop upside down and opened the back to get to the Trusted Platform Module (TPM) chip.

Many organizations use full disk encryption to secure their devices. This is a good move, but users are often lazy—they prefer to skip the authentication step that make this setup secure.

When an encrypted computer equipped with a TPM chip starts, the BIOS chip in the computer asks the TPM chip “got a decryption key for me?” and the TPM chip complies and sends the key.

Users should be required to put in a PIN or password before the key is sent from the TPM chip to the BIOS chip. However, companies will often disable that requirement because employees will complain if they have to punch in a PIN every time they start the computer. This lack of authentication is a golden ticket for attackers.

If you look in the right places on the laptop’s circuitry, you can eavesdrop on the communication of the TPM chip transmitting the decryption key across the motherboard. All you need is the right equipment.

Recommendation

Encryption on its own is not enough to secure a laptop. You might have a decent lock on your front door, but it doesn't really matter if the door unlocks automatically or if you keep the key under the doormat.

If a laptop is stolen, best practice is to assume that the security on it is going to be breached. Perform threat modeling to understand what the impacts of that would be for your organization.

I used a USB device, a ‘logic sniffer’, the size of a credit card. It records activity passing between the BIOS chip and the TPM chip on the motherboard. After the eavesdropping device located the key, I disconnected it and began the recovery process using software written by one of my colleagues.

Backdoor

My next priority was to install a backdoor on the main machine so that I would still be able to access it, even if someone restarted the computer, ran software updates, or changed the password. This is known as maintaining persistence. This backdoor would work the moment the laptop was powered on and connected to the client’s VPN infrastructure.

Recommendation

Backdoors can be detected by a blue team, but if the attacker has full access to the complete disk, they tamper with things that are not normally changeable. Blue teams often forget to look in these places because they assume the end-user does not have those privileges.

Backdoors are usually subtle and dig themselves into existing software or house-keeping scripts so as to ‘LoL’ or ‘Live Off the Land’, as we say in offensive security terminology.

Administrator

I already knew that the client’s remote workers were automatically connected to the VPN when logging on to their device, so I launched my own custom code that I had hidden inside a common tool that runs at startup to piggy-back onto the VPN connection, which allowed me to connect with the client’s main corporate network.

Recommendation

Users should have to log in or otherwise authenticate every time they connect to a VPN or access a secure area. This will annoy them, but it is more secure.

As far as the laptop was concerned, I was the HR contractor from whom I had stolen the laptop. A bit more than that, actually: with my full, backdoored access and the laptop in my possession, I’d achieved administrator-level access to the laptop’s hard drive. Despite this, without the user’s main password (which was stored in Active Directory), I could not reach my objective in the virtualized application environment that housed the client’s critical intellectual property.

Password

After some searching and another coffee, I found a local HR application that I suspected the original owner of the laptop would have used regularly. I was right, and he had even saved his password to autofill. He seemed like the type to reuse passwords across applications, so I thought that, if I could recover it, this one could be used to unlock multiple accounts.

Recommendation

In general the option to autofill passwords should be disabled, but this is hard to implement without some form of centralized credential management service.

Companies need to make the trade-off between users mistyping their passwords and being locked out of their devices versus having cached credentials.

There’s a small window of time during which applications process passwords in a readable format. For an attacker in possession of a victim’s device, this is an opportunity to snatch the information without brute force.

I loaded the HR application on a second computer so that I could work with my own virtualized setup, including certain useful programs and files. As soon as the HR application tried to read the cached password and decode it in memory, I paused the process, freezing the flow of data.

The decoded password was now somewhere in the HR application memory space; all I had to do was find it. I made a copy of the working memory and saved it to file. The client had a legacy 8-character password policy, so I sieved through the data, concentrating on any line of data that was 8 characters or more. In minutes, I saw it: Superm4n.

I could see dozens of applications through the virtualized application environment. After a few attempts, I logged into one with the password, then broke out of the virtualized environment onto the underlying operating system.

Recommendation

Passphrases that are long and unique are much more secure than shorter passwords that are artificially complex (such as by having capital letters and symbols). A passphrase like ’medievalstrawberryatthemovies’ is uncrackable (so long as the words in the phrase are chosen randomly).

Another benefit is that passphrases like this do not have to be rotated every three months, which means that users do not have to remember new passwords every few months (which can result in them writing passwords down or storing them somewhere on their device).

DLL side-loading

After a night’s rest, I returned to work. I was under the proverbial floorboards of the virtualized environment; I could see which applications were being used, as well as by whom and from where. Employees were busy at work across different regions and time zones, all accessing different applications. I didn’t have Active Directory privileges to access the restricted network housing those critical assets, so I needed to use lateral movement and pivot to another account that did have access.

Software is modular; it relies on different software libraries to perform tasks. A risk arises when applications start looking for external files in locations that the end-user and thus also an attacker can access and change. If an attacker controls the location where these files are stored, they can respond to this request, presenting whatever file the application is expecting alongside malicious code. This type of attack is known as DLL side-loading. The attacker places a spoofed malicious DLL file in a common directory that usually contains system libraries. This triggers the operating system to load the attacker’s file instead of the legitimate one.

Recommendation

To defend against DDL Side-loading, limit end-user write privileges to the relevant folders and have detection and response for directories where the end-user (and thus a would-be attacker) would be trying to manipulate files or introduce new files

Looking across the system, I found six users with access to applications that stored their temporary files in a location that my account could also access. All six could be abused using DLL side-loading. I sprinkled back-doored software libraries in the target locations and, eventually, a file request came through from one user. Now I also have access to that person’s user account and all the files, privileges and access they have access to.

Bullseye

I stole a password from the memory of a local business application, re-used it against the virtualized environment, and broke out of a sandbox application to obtain the access needed to reach the target network. I back-doored a number of utilities in use by the trading team and basically had the trading team open the door with the access needed to get to the file shares holding the trading algorithms.

One of my colleagues passed by my desk, leaving for the day. He asked me if I had found a way in.

“In, out, and everything in between,” I said, smiling.

Final actions

I’d been at my desk for around 48 hours. The finish line was in sight, but I didn’t cross it. First, I had to list the files and other assets I had access to and take screenshots of my privileges to prove to the client that we had reached the critical post-exploitation stage of the attack. I also exfiltrated example source code files and selected copies of the development environment and its key assets, but only after checking in with the customer and proving that I had access and control, and vetting the files for exfiltration so as to not introduce any unnecessary risk.

In a second browser window I notified the white team of the engagement status: complete, objective achieved. It was time to make another ultra-black coffee before writing the client’s report; I wanted to start when the engagement was still fresh in my mind. The report contained an executive summary of the engagement and including the results as far as observations and risk, the technical details of the attack narrative, as well as detailed mitigation paths and suggestions for additional controls to ensure that next time things are a little bit harder and new processes and infrastructure can be tested.

The rest of my team had dispersed for the weekend. The office was silent. All the motion-activated lights were off, except the ones above my desk.

Read the next installment of this Red Team series ‘Episode 3 – Post engagement’ here.

The mark

Somewhere in Europe, the clock strikes five. It’s raining hard, and an HR consultant has finished work for the day at his client’s office. He carefully tidies the desk he’s been using, then wishes the few other workers present a good weekend. He takes his client-loaned laptop to a small IT room adjacent to the main lobby, using a temporary key card to enter. He closes the door and, after dropping the key card into a mailbox in the lobby, is ready to leave.

Freezing rain hammers on the lobby windows. The contractor holds the glass door open with his foot, trying to open his umbrella without getting his suit wet.

“Let me get that for you,” a voice says from the other side of the umbrella. It’s a man, dressed quite casually, who leans in to hold the door. “And have a nice weekend.”

The man pulls the door fully open, smiles, and brushes past into the lobby. The contractor smiles back automatically, barely registering the interaction, and walks towards his car, his mind already on dinner and the weekend ahead.

Recommendation 
Not everyone trying to access a lobby is an attacker, but employees and security teams need to be aware that malicious individuals do exist. Holding the door open indiscriminately and allowing unfamiliar people to ‘tailgate’ should be discouraged.

The red teamer

It can happen to anyone. I’d been shadowing the contractor going in and out for weeks. I knew exactly when he would be leaving. I’d also phoned the reception desk to ask whether I could have a parcel delivered there. I’d asked who would be there to receive it and when I could come to pick it up. More important, when couldn’t I come to pick it up? When was the lobby unstaffed?

I had one goal: to break through the client’s physical security, acquire a laptop, and penetrate the restricted network to access high-value intellectual property.

Recommendation 

Ensure that employees, especially public-facing employees like receptionists and security guards, understand what kinds of uncontrolled information can be useful to attackers so that they can exercise their own judgement when answering questions like those described here.

My name is Tom, and I’m a red teamer. I test clients’ readiness to prevent, detect, and respond to cyber attacks. A red teamer is like a boxer wearing pillows on their hands instead of gloves; red teamers simulate an attack without doing any damage, but with the same stakes. This helps clients to find and fix the gaps in their defenses so that they are ready when they are attacked for real.

This story is about my work with a financial entity, which owns custom-developed trading algorithms and workflows designed to predict trends in certain markets. In the hands of a financially-motivated adversary, this intellectual property could potentially make millions and competing organizations could save years in research and development.

So, that Friday afternoon I was sitting in my car, packing my laptop bag with the compact toolkits I needed for the physical break-in. The HR contractor left dead on time every Friday—sometimes, routine is the enemy. Around 16:55, I locked up and approached the building, walking slowly until I saw him through the glass doors. The moment he stopped to open his umbrella, I knew I was in.

The intruder

With my laptop bag hanging from my shoulder, I walked directly to the key card mailbox. It was the kind available from any standard retailer, making replica keys easy to obtain. I hadn’t bothered to find one though: I could open those simple locks on my own.

I turned my back to the CCTV cameras, making sure my hands were out of view, and slipped a lock-picking tool, a jiggler key, into the lock. I moved it gently. The mailbox opened.

The mailbox was full of access cards that had not yet been deactivated for the day. I slid them into my inside jacket pocket and walked to the IT room that I had seen the HR contractor accessing. The first key card I took out of my pocket unlocked the door.

Recommendation

Temporary key cards should be deactivated automatically after a certain date or time. They should then be stored in a deposit box that is reinforced and can only be accessed from a room that is not a public area and is not directly accessible from the lobby. Some organizations will even automatically blank the card as soon as it is deposited into the safe box, but even deactivated cards can be of use for an attacker if sequential employee or card numbers are used on them.

The HR contractor had left his laptop on the closest table. I felt a pang of excitement. I already knew exactly what laptop models the organization used; I had seen them front and center in corporate videos and under the arms of the workers moving through the building’s lobby. Over the last few days I had researched the potential weaknesses those models have. It pays to be prepared.

Recommendation

Showing any internal information can help an attacker to plan their attack. This includes: What kind of phones and laptops are in use

- How access cards are used
- What the offices look like on the inside
- What physical keys look like (as they can often be reproduced from photos)
- Where the entrances and exits in the building are
- What information ID cards contain
- What computer applications are frequently used
- What appliances and wireless gear is in use
- Which external service the company uses, such as for building security or cleaning.

Organizations cannot hide all this information, but they should understand how attackers may use it to enable their actions.

The HR contractor’s laptop went into my bag, along with a second, different model (just in case). I left the room, posted the stolen key cards back into the mailbox to avoid raising an alarm, and strolled from the building. Easy.

Read the next installment of this Red Team series ‘Episode 2 – Cyber’ here.