Diagrams: Timelines

Aren’t timelines great?!

Anyone who has spoken with me will know that I am a huge fan of diagrams as a way of breaking down complex topics into easier to understand concepts. Over the past few months and years at $dayjob, I have produced a number of diagrams during the reporting phase of our internal testing. Over this post, Im going to focus on one particular type of diagram – the mighty timeline. Bear in mind that these timelines work well from both an offensive and defensive standpoint!

There are several key benefits to producing these timelines, in no particular order:

It ensures that you fully understand the order in which activity occurred. For example:
- Do we know exactly where we obtained credentials X?
- Where did they attempt to use them?
- Do we know all of the hosts which a threat actor moved laterally onto?
If you make this timeline during the live testing window, it serves as an excellent tool for deconfliction between red team activity and the blue team.
These timelines can be given as part of an executive overview without having to dig into vast levels of detail and can help to visualise the stages of an attack

For context, my role at $dayjob is more of a white-team role, where I organise and co-ordinate red team testing – so I often have to do debriefs on the output of red team testing!

More Timelines!

For this post, I will be using the GDPR report into the British Airways hack. As a public document, we can use this to produce a potential timeline of the incident by reading between the lines of the content included in the report. I will emphasise that I have no idea on the detail behind the BA hack, all the detail in this post is from the ICO ruling. Any detail which is actually true is purely by coincidence (a.k.a. Please don’t sue me).

Throughout this, I will be using Draw.io which is a free alternative to Visio. If you have the option, I would recommend Visio as it does have some nice extra features.

Typically, I produce 4 diagrams for any complex red team engagement:

Low-Level Diagram
Medium-Level Diagram
High-Level Diagram
Defensive Improvement Opportunities

Low-Level Diagrams are typically shared with our trusted agents, or the defensive teams following any testing. High-level diagrams & ‘Defensive Improvement Opportunities’ diagrams are used extensively for stakeholder debriefs or in PowerPoint presentations. Medium-level diagrams tend not to be used all that much in my experience, but still have their place!

Low Level Diagrams

For these low level diagrams, I feel that there is basically no limit to how detailed they can be. From my experience, these are what I use on a day to day basis through the live testing period. These are eventually shared with the blue teams in order for them to learn from and to correlate any alerts and detections – so the more detail the better!

They also serve as an excellent tool for deconfliction, so I would recommend producing them as you go if at all possible. The process of making these diagrams often reveals any areas which you don’t fully understand, so you can clarify your knowledge with the red team lead before the reporting stage begins in anger.

An example could be the following, focusing on the initial days of the attack on BA:

There are a few features of this diagram which I find have been useful, going from top to bottom in the diagram:

Adding a few brief summaries of key points can help to draw attention to key events. I tend to keep these key milestones the same across all of the diagrams I produce, from the low-level to the high-level diagrams. This helps to highlight the key moments in what can sometimes be quite complex diagrams!

A rough summary of the kill-chain steps can help to indicate what was happening at the given time.

Again, splitting the background colours up into individual days will help to distinguish each days activities. I find this also helps to indicate how much activity occurred. For example, the 22nd was clearly a very busy day for Magecart in the diagram above.

Highlighting SOC tickets or other defensive actions can help to tell the story of any near misses, and show potential areas for improvement. Again, these are totally fictitious SOC tickets (Please don’t sue me)

High Level Diagrams

For these diagrams, I normally try to be quite succinct in the comments made on the diagram. As you’ll see below, there are far less boxes, and they contain less technical information. This is intentional, as this sort of high-level diagram is more likely going to be viewed by less technical stakeholders, who (unfortunately) wont care about the leet techniques used to gain initial access. This also has the added advantage that these diagrams will then tend to fit into a PowerPoint slide without having to be split up.

In order to maintain consistency, I have again included the key milestones and kill chain elements, and am instead using a scale of weeks instead of days.

Another option which can be handy, is to create a diagram which includes every day (or week) for the time period which you are covering. For example, in the diagram above I deliberately didn’t include the 2nd, 9th or 16th July as there was no activity. In the diagram below I have included it, which can put highlight the length of dwell time between periods of activity.

From the below diagram, we can clearly see that there were two significant periods with no major activity – which highlights the length of time from initial access to detection.

In prior tests, I have also taken this time to point out what could have happened during the red team exercise. For example, above I point out that ransomware could have been deployed – an action which would have likely been very damaging for BA’s estate (And arguably financially crippling compared to the GDPR fine they ended up with).

Whilst this is more relevant for tests where I operate as a white team lead, it can be useful to apply some business context to the findings. For example, adding a box to clarify potential business impacts which could have occurred:

“With access as user X, testers could have compromised system ABC but decided on other targets”
“System ABC was compromised, but testers used an alternate route to achieve Objective X”

Defensive Improvement Opportunities

The final ‘style’ of timeline diagram which I will cover is the ‘improvement opportunities‘ diagram. This has been a secret weapon of complex internal debriefs, where suggestions from a red team report can be mapped onto a timeline, showing the potential solutions to the key findings of a red team exercise.

Following the debrief of a test, the next logical question on most people’s mind is “How do we fix this?”. Therefore having a diagram which contains recommendations mapped to the testing timeline is a good starter for this conversation. If a particular event from testing draws a lot of attention, then it can help to direct the discussion. For example below, if the initial access was especially concerning to the audience, then there are 4 potential options which could be discussed to aid remediation (REC01, REC02, REC03, REC04).

Below is a snippet of what could have been produced for the initial stages of the BA report (With several fictitious additions from myself to make it a little more interesting)

The naming of this diagram is admittedly very woolly, but it is very much deliberate (And not me running out of ideas for new timelines). This slide typically will lead to a lot of ‘discussion’, and so it is best to ensure the language used remains neutral and simply presents the facts without any opinion. For example, instead of including a statement of ‘The entire Citrix team effectively have Domain Admin permissions’, I would instead simply suggest an AD permissions review to ensure I don’t see my P45 any sooner than I need to.

As you can see, splitting the findings into procedural and technical ‘improvement opportunities’ can help to distinguish between two common groups for these opportunities. Depending on the test, these groups might change – or you might find that splitting them into groups isn’t that much use!

I would also advise giving a unique reference to each suggestion (e.g. REC01, REC02…) , as it makes it far easier to discuss the suggestions and ensure that everyone is referring to the same item on the diagram! Additionally, it means that any actions or notes can be accurately taken – there’s nothing worse than having to second guess your notes after a debrief!

Timeline Guidelines

As you may have noticed from the diagrams above, I try to be quite consistent with how I lay them out and design them. I find that this consistency makes them easier to read, and means the audience can focus on the content rather than unusual layout or styling choices!

One of the most important things I find is to ensure the direction of the arrows makes logical sense when laying out a timeline. For example, in the high-level view below, I have highlighted the two ‘rows’ of events I created to show the two separate strands of activity:

Red – The potential ransomware angle
Blue – The eventual PII theft angle

This also makes it clear that both of these chains of events stem from the same initial point (Citrix compromise & break-out).

To show why I use these distinct ‘rows’, I have made another diagram below which only uses a single ‘row’ for the events.

This shows how the narrative behind a red team exercise (or incident) can quickly become confusing if we decide to do this, as it is hard to distinguish how each action was achieved. For example:

Did we get Domain Admin privileges from a database server?
Could ransomware have been deployed estate-wide from a database?

I try to use the same font across the entire diagram. In areas where I want to draw attention, I typically make the font bold and increase it by a font size or two. If you need to add more even more detail to an event, I typically just add it into a comment on the shape when I am using Visio – so that I can refer back to it later on. For example, below I make the title of the boxes bold, but keep the text the same size.

In terms of the colours to choose, I would be careful when using shades of red and green, as they have connotations of red being bad and green being good – which you might not want! I have found the following colours to work well for specific events:

Colour	Usage
Dark Pink (Totally not red 😉 )	Key attacker actions/objectives
Orange	Add context to attacker activity
Blue	Defender actions
Green	Key defensive actions

Below is a snippet of the high-level view showing these colours:

Additionally, when it comes to debriefing tests, any red on a report can appear inflammatory to the teams which have to remediate the issue. For example, this would likely not make you many friends in a debrief:

Accessibility

Across all of these timelines, accessibility should be considered the whole time. Generally we want to make them as readable as possible, so ensuring we use a good size font is an obvious place to start, although this can be challenging on complex low-level diagrams which cover a wider timespan.

Additionally, colour-blindness does effect a lot of people, so I would avoid making red and green colours an integral part of the diagram. I tend to use colours to enhance key parts of the diagram, but a colourblind reader should also be able to glean the same information. To take this further, I have previously added a dashed border or patterned background to signify events of interest – as both colourblind and non-colourblind readers will be drawn to those items. This can start to look messy if you aren’t careful, so use it at your own risk!

Finally, try to make the diagrams as uncluttered as possible. Reading diagrams with large amounts of intricate detail and arrows is very difficult to understand (and boring), they can often be simplified, especially when included in a PowerPoint slide! Whilst this is of less concern for the low-level diagrams which contain all of the technical information, I try to always minimise the number of events included in a high-level diagram if at all possible.

Summary

Hopefully this post was of use, I truly think that well-designed diagrams and timelines are a real timesaver when it comes to reporting and debriefing a red team test. With some good thought and planning up-front, they can avoid a lot of confusion and generally lead to better outcomes when doing a debrief.

Attacking Password Managers: LastPass

This is the second post in a series I have done looking at password managers. My first post was on KeePass and covered some techniques which can be used against local password managers.

For this post, LastPass will be used as an example of a cloud-based password manager. In my opinion, these managers often have better UI/UX, so are easier for non-techy people to use.

LastPass has unfortunately had a *pretty rough* history, with several high-profile breaches in 2015, August 2022 and November 2022. Despite this, I would consider it as one of the most popular password managers – so it is worth using for this post!

There are several methods which I will cover here, most of which will apply to any cloud/browser-based password manager:

I was only able to successfully access the vault through the ‘Remote Debugging – Accessing The LastPass Vault’ section. With the other techniques I was able to get to a position where I believe I had the correct cookies or position, but I was unable to successfully load the vault. I suspect this is due to LastPass performing host or session checking – but it could well also be due to me needing to get better at Pass-The-Cookie attacks!

Dumping Saved Credentials

To dump any saved Chrome passwords, we can use SharpChrome with the logins /password:PASSWORD parameters. This does require us to get the plaintext password of the user, but there are many ways of obtaining this 😉

To dump other Chromium based browsers such as Brave or Edge, we can use the /browser flag. For example, we would use the following command to interact with an Edge browser: SharpChrome.exe logins /password:PASSWORD /browser:edge

One thing to bear in mind with this approach is that LastPass will detect new sign in locations, such as different browsers, IP addresses and so on – so we cannot dump creds for LastPass and login directly to it!

Dump The LastPass Vault From Memory

For LastPass to work as an extension, it loads the vault into memory – but there are some weaknesses in the way in which it does this. Notably a BlackHat talk from 2015 covers this in technical detail if you are interested.

Luckily TrustedSec have automated a lot of this with their lastpass BOF, which is covered in an excellent 15-minute demo on YouTube. The BOF is part of their ‘CS-Remote-OPs-BOF‘ repository

To start with, I will ensure that the LastPass extension is logged in but I will not have LastPass.com open in Chrome

I will then use Cobalt Strike to list the processes and pass the PIDs for Chrome processes into the lastpass BOF.

It will begin to parse memory and dump out any relevant strings, for example the master password:

As well as credentials from within the vault:

I did find that the BOF would only pull credentials from the vault after I had specifically searched for them in the extension, though it did appear as if LastPass have altered the way in which the extension works since the BOF was written, as the parsing was a little off when I used it. Nonetheless, this is a great BOF and serves as a very useful starting point for parsing Chrome’s memory.

Session Theft – Browser Pivoting

If our target has authenticated into LastPass, we can use Cobalt Strike’s Browser Pivot feature to leverage this already-established connection, but the target would have to be using Internet Explorer 😔.

We can use FoxyProxy to route our traffic through the HTTP proxy which CS has established

After adding an exception and relaxing rules on HSTS and the network.stricttransportsecurity.preloadlist option, this did partially load LastPass, but I had issues with it successfully loading the vault.

Session Theft – Cookies via DPAPI

I then turned to dumping values via DPAPI, which was a bit of a struggle. I believe that Chrome has altered the way in which it stores cookies, which prevents some of the ‘older’ tooling from working automagically. To counter this, I went to the Chrome/User Data folder on my test lab and searched for ‘cookie’, revealing the new location!

It turns out that the Cookie DB is within %LOCALAPPDATA%\Google\Chrome\User Data\Default\Network, which isnt where SharpChrome looks – most other blog posts mention to look in the \Default\Cookies folder. We can use this file path in SharpChrome to dump the cookies using the following command:

SharpChrome.exe cookies /target:"C:\Users\vagrant\AppData\Local\Google\Chrome\User Data\Default\Network\Cookies" /password:PASSWORD

Looking at the documentation, we need to provide this with the /statekey:X parameter. We can obtain these values by running SharpChrome.exe statekeys

We will use the value ***EC73E9 for the /statekey parameter, and will also use the /url parameter to only include cookies for lastpass. This leaves us with the final command:

execute-assembly /home/user/SharpChrome.exe cookies /target:"C:\Users\user\AppData\Local\Google\Chrome\User Data\Default\Network\Cookies" /password: /statekey:YADDAYADDA_EC73E9 /url:lastpass /format:json

This /format:json allows us to export directly into the Cookie-Editor extension.

Remote Debugging – Accessing The LastPass Vault

At this point I started looking into the remote-debugging-port technique which has been covered a lot recently. I then stumbled upon MDSec’s post which covered the technique below in far greater (and better) detail – go check out their post!

I found that using a redirector and the CS SOCKS proxy was very slow in my lab, even when using an interactive beacon so is probably too intensive for real world usage unless you absolutely need to! Ultimately I used Chisel to directly connect from the target to my team server, in the real-world you would want to ensure this is way more locked down!

To start, I spawned Chrome with chrome.exe --remote-debugging-port=10999. As covered elsewhere, there is a --headless argument which wont create a GUI window, but I had serious issues getting it to work!

Following a lot of errors, I realised we need to Chrome with the victims own user profile. I didn’t have success specifying a user profile directory, but did have success just using --profile-directory="Default". I believe that this profile directory value can change depending on how the target’s environment is configured – so this might change!

Using Chromium I used the flags described within the MDSec blog post to use the Chisel SOCKS proxy inside Chrome:

--proxy-server="socks5://127.0.0.1:1080" --proxy-bypass-list="<-loopback>"

This did appear to work on Chromium in Ubuntu 22.04 – but it would not successfully load the LastPass Vault for me. Instead I used a Windows VM with Chrome to more closely mimic the target user’s environment.

To get the remote debugging URL, we need to visit http://localhost:10999/json/list and get the devtoolsFrontendUrl value.

Then we can use the following magic URL from MDSec to spawn a new instance of the LastPass vault extension:

localhost:10999/json/new?chrome-extension://hdokiejnpimakedhajhdlcegeplioahd/vault.html

We then visit /json/list to see that it has spawned a new instance

Which we can then visit in our attackers browser which we started earlier.

The demo above will replicate any actions you take onto the targeted users desktop. This is has obvious, significant drawbacks so would require some *heavy* social engineering to work if you pursue this method without using the headless mode or another technique!

Ultimately, I couldn’t get this to work in headless mode through Firefox and Chromium on an Ubuntu machine. I suspect that this is a combination of:

LastPass is likely doing some sort of host checking, which fails when using a different host to the target (Windows/Chrome vs Ubuntu/Chromium&Firefox)
Using headless mode introduced other errors
Lack of ability

Remote Debugging – Accessing Cookies Via The Debug WebSocket

Accessing the vault via a GUI felt like a pretty long winded and noisy way of accessing LastPass. I did some hunting on Google and found a post by SpecterOps on dumping cookies via the debug port which we were using in the previous example.

This post mentions the CookieNapper tool by GreyCatSec, which uses WebSockets exposed by the debug port to simply query for all of the cookies. This has several advantages:

No need to use SharpChromium or load extra binaries
Invisible to the user
Should have less latency as the attack would require less usage of proxies

Using the SOCKS proxy we set up with Chisel, we can use the tool to dump cookies:

From here, we can use the EditThisCookie extension to import the cookies. Again I had issues getting access to the vault, but the cookies did appear to be successfully dumped.

Summary

In summary, I learned a lot digging into these 2 password managers – in no particular order:

KeePass has a number of pretty significant design flaws, even in the latest version
The backdooring of KeePass via the trigger system is pretty neat
Scanning memory is a really handy technique for password managers and programs such as these…
I need to improve at pass-the-cookie attacks
- Or just don’t target LastPass I guess ¯\_(ツ)_/¯
Password managers are still a very good solution, and are hugely more secure than other solutions (Cough passwords.xlsx)

For what its worth, I think LastPass (or more broadly cloud-based password managers) are the best solution for most users. They tend to be much more usable than local applications such as KeePass, which should in theory encourage end users to use it more, thus making their credentials more likely to be more secure. For more technical or computer-savvy users, KeePass is ultimately more secure from an architectural point of view in my opinion.

That being said, cloud-based password managers are a huge target for attackers and you do end up putting a lot of trust into the provider, rather than an endpoint which is under your control. With LastPass now having suffered multiple breaches, this is an area which attackers will continue to target!

Attacking Password Managers: KeePass

In this two-part blog post, Ill be taking a look into attacks password managers to improve my knowledge on techniques which can be used against them. To start with, I will take a look at local password managers by looking at the sort of techniques which can be used against KeePass. The second post covers some attacks against LastPass.

Ill start by covering some generic attacks against password managers (Both local and cloud-based), before moving onto KeePass-specific attacks.

Generic Password Manager Attacks

Monitoring/Grabbing the Clipboard contents

We can do this within Cobalt Strike using the clipboard command. This is only a point-in-time grab of the data, and will not actively monitor it!

We can also use Mimikatz to do this with misc::clip, but this is way overkill for most situations

Keylogging

If we are feeling patient (or want to coerce the target into opening their password manager), we can grab the master password by keylogging their system to capture the main password.

KeePass Attacks

Now lets look into some KeePass-specific attacks. This was all performed against v2.52 which was the latest at the time! This was installed with all the default settings, and the TopSecretStuff.kdbx file is using a password of ‘infected‘.

And lets add a password or 2 to our KeePass database

KeeThief

KeeThief is another great tool from GhostPack. It was originally released 7 years ago and targets .NET 3.5, which meant I had to install the framework on my test system. For real-world usage, make sure you adapt this to your target environment!

I then had to combine the Microsoft.Diagnostics.Runtime.dll DLL into the KeeThief executable and make the entry point public to avoid getting an “Invoke_3 on EntryPoint failed” error in Cobalt Strike. To do this, I used ILMerge which was downloaded as part of building KeeThief. Using the csproj file from KeeThief for guidance, the final command was:

PATH_TO_KEETHIEF\KeeTheft\packages\ILMerge.2.14.1208\tools>ILMerge.exe /target:winexe /targetplatform:"v2,C:\Windows\Microsoft.NET\Framework\v2.0.50727" /target:exe /out:test.exe "PATH_TO_KEETHIEF\bin\Release\KeeTheft.exe" "PATH_TO_KEETHIEF\bin\Release\Microsoft.Diagnostics.Runtime.dll"

I also did the same for the associated PowerShell file which this should produce, using the command:

PATH_TO_KEETHIEF\PowerShell>powershell -exec bypass -File Out-CompressedDll.ps1 KeeThief.exe KeeThief.ps1

The commands are covered in the README of KeeThief

Finding KeePass files

Using the pre-built KeePassConfig.ps1 file, we can hunt in a system for KeePass XML files. These XML files contain the configuration data for KeePass which we will modify later on as part of an attack!

Stealing the master password from memory

We can now simply run the KeeThief tool against our system, and so long as KeePass is running, we can steal the plaintext master password. Notably KeePass just needs to be running on the system and be unlocked with the main password – a pretty typical arrangement for most users who use KeePass!

We can also do this using the KeeThief.ps1 script if we want to throw it back to 2017, with the Find-KeePassDatabaseKey cmdlet.

From this point, we could steal the TopSecretStuff.kdbx file, and interact with it away from the host.

Backdooring the trigger system

As mentioned in an older Mandiant report, KeePass includes a ‘trigger’ system which can be exploited. In short, this trigger system allows specific actions or commands to be run when specific criteria are met in KeePass. Mandiant’s example is to dump out the KeePass DB whenever KeePass is opened. On the 23rd January 2023, CVE-2023-24055 was released for this, but is disputed by KeePass.

As covered in the comments of KeePassConfig.ps1, we need to pipe the output of Find-KeePassConfig into Get-KeePassConfigTrigger for it to work.

This didn’t work with me, after a bit of debugging I believe the structure of the KeePass config has likely changed since the tool was created, or the tool had revealed a false positive file. Below is an example of the error within the Add-KeePassConfigTrigger function

After manually creating a Trigger on the target system, the C:\Program Files\KeePass Password Safe 2\KeePass.config.xml file had not changed and was essentially an empty XML file

<?xml version="1.0" encoding="utf-8"?>
<Configuration xmlns:xsi="http://www.w3.org/2001/XMLSchema-instance" xmlns:xsd="http://www.w3.org/2001/XMLSchema">
  <Meta>
   <PreferUserConfiguration>true</PreferUserConfiguration>
  </Meta>
</Configuration>

This would explain why PowerShell was throwing an error, as there were no XML elements for it to add nodes onto! With a bit of hunting, I found the file at %APPDATA%/Roaming/KeePass/KeePass.config.xml

We can now pipe this file path into Find-KeePassConfig and then into Add-KeePassConfigTrigger like so:

"C:\Users\vagrant\AppData\Roaming\KeePass\KeePass.config.xml" | Find-KeePassConfig | Add-KeePassConfigTrigger -Verbose

We can confirm this by looking at the KeePass.config.xml file after running the command

Before we restart KeePass, note that there are no files in the %APPDATA%/Roaming/KeePass folder

After signing into KeePass, a file named TopSecretStuff.csv is dropped into the folder

Which we can open to reveal our passwords

We can then remove our configuration change by running Remove-KeePassConfigTrigger

Cracking A KeePass file

The above attacks have relied on us compromising a system where the user is either actively using KeePass, or will routinely use it. What if we come across a user which only infrequently uses it, or find a *.kdbx file on a share?

For this, we can use the keepass2john executable from John The Ripper – which is built into Kali. If you are using a different OS, then Harmj0y has made a Python script to do this!

We now have our hash:

Looking at the example hashes from Hashcat (Mode 13400), we can see that we will need to remove the database name ‘TopSecretStuff‘ from the beginning of this string

We can then run Hashcat using mode 13400 to try and crack this

hashcat.exe -a 0 pass.txt rockyou.txt -m 13400

Additional Persistence Methods

Something which I read about, but didn’t attempt was obtaining persistence via the KeePass plugins, which is covered by @two06 on Medium, they also have another post which covers another way of abusing the trigger system to execute arbitrary code, in a similar way to KeeThief’s persistence method.

In my second post in this series, I will take a look at LastPass as an example of a cloud/browser-based password manager!